Я как раз пытался понять, на чём основаны ваши выводы о равносохранности УК и НПФ. Понял, что это ощущения, а не основанные на фактах выводы. Спасибо за развёрнутый ответ!
Не понял при чём тут ПФР — вы сравнивали вложение в коммерческий НПФ и коммерческую УК, и утверждали, что они равнонадёжны. Пока это утверждение остаётся голословным.
Вы совершенно правы. И у методов основанных на асессорских оценках, и на поведении конечных пользователей, есть масса ограничений — связанных прежде всего с человеческим фактором. Мы их прекрасно знаем и осознаём. Пока в отрасли не найдено более совершенных способов измерения, хотя исследования в этой области активно ведутся.
Из инструментов корректировки и уточнения выдачи мы уже упоминали интентные подсказки — с ними мы собираемся действовать смелее, давая возможность сортировать выдачу не только по интентам пользователя, но и по основным параметрам объекта, например цене, актуальности и т.п. Кроме того, у нас давно есть связные запросы. Этот механизм мы тоже будем развивать, и его репрезентативностью планируем заниматься.
А разве «результативности работы конкретно расширений» может оцениваться иначе, как через влияние на «удовлетворённости пользователя результатами поиска в целом»?
Качество расширений может оцениваться, например, их точностью и полнотой (и, конечно, их комбинацией — мы используем F-меру).
Результативность расширений мы оцениваем как их вклад в совокупное качество поиска.
Для измерения совокупного качества поиска мы используем метрику pfound (см. популярный и подробный рассказ), в ней на расширения приходится несколько процентов. Pfound — не единственная метрика, основанная на оценках асессоров, известны также nDCG и другие.
Используем и анализ поведения пользователей, например метрику TDI и A/B тестирование (совсем популярно про них недавно рассказывал Илья Сегалович).
Подсвечиваться могут любые элементы сниппета, которые, с нашей точки зрения, помогают пользователю выбрать страницы, наиболее полезные в решении его задачи.
Да, имеет место ошибочное автоисправление опечатки. Марка машины редкая, а слово «ставки» очень частотное. Тем не менее, возможность поискать «Ставик» остается за ссылкой:
В запросе «ставик» была исправлена опечатка
Очень тонкое замечание, тут действительно объекты выступают в разных ролях. Немного улучшить выдачу в данном случае помог бы более жесткий приоритет точной формы, но вмешиваются другие факторы ранжирования. Однако данная проблема не связана напрямую с поисковыми расширениями, об учете синтаксических связей в запросе мы расскажем в другой раз.
Совершенно верно, у нас был ошибочный синоним кружки-клубы. Теперь вы даже знаете, что к его появлению привела близость контекстов, в которых эти два слова встречаются.
Мы даем возможность управлять выдачей, когда знаем, что меняем ее радикально — т.е. большинство результатов найдены не по исходным словам запроса, а по расширениям. В этом случае цена ошибки очень велика, и мы даем пользователю поискать точно так, как он нас спросил.
Например, с теми же цвейгами из статьи — в начале выдачи есть приписка:
В выдачу по запросу «конъюнктивит у цвергшнауцеров» были добавлены результаты по похожим запросам. Искать только «конъюнктивит у цвергшнауцеров»
Аналогичные подсказки есть в случае опечаточного исправления.
Но даже такие подсказки оказываются редко востребованы пользователями.
Из перечисленных примеров к расширениям относится разве что стерилизатор. Это хороший пример ошибки на имя деятеля (в данном случае инструмента). Мы расширяем слово, используемое в одном контексте (стерилизатор для бутылочек), другим словом, которое имеет отношение уже ко множеству контекстов (стерилизация кошек, банок). В идеальной ситуации должна была сработать контекстная модель, которая бы исключила это расширение в контексте данного запроса. Но она ошиблась.
Что касается остальных запросов — ошибки выдачи связаны с региональным ранжированием. Чем меньше у Яндекса данных по запросам (мало переформулировок, мало ссылок), тем сложнее сформировать релевантную выдачу. К сожалению, именно этот эффект можно наблюдать на низкочастотных региональных запросах, которые преимущественно и представлены во всех ваших примерах.
Тем не менее, при разработке и совершенствовании поисковых алгоритмов мы пытаемся выделять такие классы запросов, выдачу по которым можно улучшить и на имеющихся данных. Например, с помощью новых факторов машинного обучения — в том числе касающихся тематической рубрикации объектов запроса и определения ролей объектов. В этом направлении мы постоянно совершенствуемся; возможно, при одном из очередных обновлениий выдача по этому классу запросов улучшится.
Отвечает ли страница интенту — Яндекс определяет не по ключевым словам. Поэтому, если вас беспокоит, что конкуренты будут насыщать текст страницы словами интентов, не волнуйтесь — с точки зрения ранжирования это бессмысленно.
Но вообще ваш вопрос относится к интентам — которые похожи на обсуждаемые здесь расширения лишь тем, что тоже подсвечиваются в сниппетах.
В сниппетах действительно подсвечиваются не только слова запроса (вместе с синонимами) — которые поясняют, о каком предмете та или иная страница, но и наиболее типичные намерения пользователя в отношении объекта запроса — которые объясняют, какую задачу он может решить с помощью данной страницы (купить, смотреть, в домашних условиях, отремонтировать).
Наша статья — гораздо больше про подход «как вообще решаются такие задачи», чем про конкретный алгоритм. И цифры в ней — прежде всего чтобы дать представление о том, какими они в такой задаче бывают, на примере нашего сервиса.
Про методику оценки качества. Согласитесь, что не совсем корректно измерять точность такого алгоритма в отрыве от конкретной базы треков и конкретного потока запросов на распознавание. Условно, если алгоритм показывает прекрасное качество на потоке совершенно незашумлённых запросов и на базе в 10 тыс треков — это ведь не значит, что качество будет таким же на 10 млн треков и на потоке очень шумных запросов?
Да, нам важно «совокупное счастье пользователя» — и для этого, согласитесь, наша метрика подходит лучше, чем изолированное качество алгоритма. Тем более, что и полнота базы в наших руках, и экстенсивное увеличение объёма базы вовсе не линейно конвертируется в рост процента успешных распознаваний — вы ведь понимаете почему.
Да, именно совокупного качества сервиса — и считаем это правильным для наших задач. Потому что алгоритм распознавания — лишь одна его часть; вторая, полнота базы, ведь тоже практически полностью в наших руках.
Мы как раз наоборот уверены, что фокусирование на поиске — это хорошо и правильно. Ведь поиск музыки по фрагменту — это тоже вид поиска. И нам важно, чтобы его качество росло с такой скоростью, которая бы нас устраивала — поэтому планируем развивать его сами. И инновации стараемся создавать, прежде всего, на ниве поиска же. Вот недавно Острова анонсировали, например — немаленькая штука.
Я как раз пытался понять, на чём основаны ваши выводы о равносохранности УК и НПФ. Понял, что это ощущения, а не основанные на фактах выводы. Спасибо за развёрнутый ответ!
Можете поделиться пруфлинком, почему считаете равнозначным? Разве гос. требования к НПФ и УК одинаковы?
Из инструментов корректировки и уточнения выдачи мы уже упоминали интентные подсказки — с ними мы собираемся действовать смелее, давая возможность сортировать выдачу не только по интентам пользователя, но и по основным параметрам объекта, например цене, актуальности и т.п. Кроме того, у нас давно есть связные запросы. Этот механизм мы тоже будем развивать, и его репрезентативностью планируем заниматься.
Качество расширений может оцениваться, например, их точностью и полнотой (и, конечно, их комбинацией — мы используем F-меру).
Результативность расширений мы оцениваем как их вклад в совокупное качество поиска.
Для измерения совокупного качества поиска мы используем метрику pfound (см. популярный и подробный рассказ), в ней на расширения приходится несколько процентов. Pfound — не единственная метрика, основанная на оценках асессоров, известны также nDCG и другие.
Используем и анализ поведения пользователей, например метрику TDI и A/B тестирование (совсем популярно про них недавно рассказывал Илья Сегалович).
В запросе «ставик» была исправлена опечатка
Например, с теми же цвейгами из статьи — в начале выдачи есть приписка:
Аналогичные подсказки есть в случае опечаточного исправления.
Но даже такие подсказки оказываются редко востребованы пользователями.
Что касается остальных запросов — ошибки выдачи связаны с региональным ранжированием. Чем меньше у Яндекса данных по запросам (мало переформулировок, мало ссылок), тем сложнее сформировать релевантную выдачу. К сожалению, именно этот эффект можно наблюдать на низкочастотных региональных запросах, которые преимущественно и представлены во всех ваших примерах.
Тем не менее, при разработке и совершенствовании поисковых алгоритмов мы пытаемся выделять такие классы запросов, выдачу по которым можно улучшить и на имеющихся данных. Например, с помощью новых факторов машинного обучения — в том числе касающихся тематической рубрикации объектов запроса и определения ролей объектов. В этом направлении мы постоянно совершенствуемся; возможно, при одном из очередных обновлениий выдача по этому классу запросов улучшится.
В любом случае, спасибо за фидбек!
Но вообще ваш вопрос относится к интентам — которые похожи на обсуждаемые здесь расширения лишь тем, что тоже подсвечиваются в сниппетах.
В сниппетах действительно подсвечиваются не только слова запроса (вместе с синонимами) — которые поясняют, о каком предмете та или иная страница, но и наиболее типичные намерения пользователя в отношении объекта запроса — которые объясняют, какую задачу он может решить с помощью данной страницы (купить, смотреть, в домашних условиях, отремонтировать).
Это часть механизма «интентный поиск»: clubs.ya.ru/company/55417
Про методику оценки качества. Согласитесь, что не совсем корректно измерять точность такого алгоритма в отрыве от конкретной базы треков и конкретного потока запросов на распознавание. Условно, если алгоритм показывает прекрасное качество на потоке совершенно незашумлённых запросов и на базе в 10 тыс треков — это ведь не значит, что качество будет таким же на 10 млн треков и на потоке очень шумных запросов?
Да, нам важно «совокупное счастье пользователя» — и для этого, согласитесь, наша метрика подходит лучше, чем изолированное качество алгоритма. Тем более, что и полнота базы в наших руках, и экстенсивное увеличение объёма базы вовсе не линейно конвертируется в рост процента успешных распознаваний — вы ведь понимаете почему.