Ну в этом месте я скорее выступаю не только и не столько как «сотрудник Яндекса», скорее как исследователь в этой области и один из основателей РОМИП, целью которого было сравнение поисковых движков на российском рынке. Так что, если тема независимой оценки вам близка, то коллеги из GlowByte устраивают встречу по голосовым технологиям во вторник в 9 вечера (https://t.me/noml_community?voicechat), и можно там продолжить дискуссию.
Интересное сравнение. Хотя и методика вызывает ряд вопросов, выкинув систему авторов можно получить относительно несмещенную картинку. В связи с этим, хочу поздравить коллег из Сбера с удачным релизом! Верно ли я понимаю, что в случае Яндекс использовалась модель general? Надеюсь мы все понимаем, что сравнивать производительность подобным способом — очень спорная идея, так как экспериментатор наблюдает только собственную нагрузку на систему, да и резкие скачки по нагрузке могут привести к троттлингу со стороны сервиса. Что касается данных, то Яндекс собирается опубликовать русскоязычный датасет в этом году.
Построение службы асессоров — это небыстрый, недешевый процесс, который масштабируется с потом и кровью. Система сдержек и противовесов для асессора, которая позволяет контролировать качество результатов вырабатывается годами (JFYI: первые оценки в Яндекс появились в 2003 году, если память мне не изменяет). Мы считаем, что этот кирпич у нас есть и мы в него верим, но из-за большого количества know how никому особенно «про это» не рассказываем. Теперь наша цель в том, чтобы как можно точнее отразить полученный от асессоров сигнал. Таким образом, логика следующая:
1) мы верим асессорам (почему — отдельный вопрос);
2) стараемся собрать репрезентативное множество запросов (в том числе тех самых, трудных);
3) нам надо научиться предсказывать тот же порядок документов, что дают их оценки;
4) хотим планомерно улучшать качество п. 3.
И пункт 4 оказался очень нетривиальным, и именно его в рамках FML нам удалось поставить на поток. Что касается того, что узкое место «не там», то мы хотели проиллюстрировать свое утверждение внутренними метриками, но посчитали, что это неповторяемо и некорректно. Посетители доклада Mail.RU на последнем ECIR 2013 должны были наблюдать эффект по их измерителям. К сожалению у меня нету ссылки на их презентацию, если кто-нибудь добавит, буду очень благодарен.
Одни ресурсы — про кластер разработки (мониторинг), другие про рантайм. Там разные объемы вычислений, в частности, каждый фактор за день вычисляется 200млн запросов * 20к документов = 4трлн раз (это я очень-очень снизу). Мониторинг же задачка сложная, но значительно более «земная» по объемам вычислений и проводить ее можно не так часто, например, в фоне. Ко всему прочему факторы в рантайме — это латентность, которую видят пользователи, а мониторинг — проблема разработки. Пользователей мы любим больше.
Далее IMHO, которое может не совпадать с позицией компании. Вы верно подмечаете, что подбор формулы не возможен без хорошо организованной системы оценки. И факторы, которые разрабатываются, в кренфилдской методике оценки, ловят не напрямую сигнал от пользователя, а сигнал от верифицированного(!) асессора. Проблема построения инструкции, обучения и контроля работы асессора — отдельная интересная тема для обсуждения, но она явно выходит за рамки данной статьи.
Если коротко, то настройка по сигналам от контролируемых экспертов — во многом обдуманный шаг, который позволяет определять внутри компании понятие качественного поиска, а не отдавать его на откуп текущей моде, или большинству пользователей. В качестве иллюстрации, по запросу [ягуар], средний пользователь 2 года назад хотел информацию про «ягу», но нам казалось, что это неверно, и сейчас, когда интерес к напитку пошел на спад мы видим, что были правы: wordstat.yandex.ru/?cmd=words&page=1&t=%D1%8F%D0%B3%D1%83%D0%B0%D1%80&geo=&text_geo=
Асессоры — один из способов контролировать направление развития формулы ранжирования и разрабатываемые факторы должны соответствовать этому направлению с одной стороны, с другой, приводить к улучшению качества формулы с точки зрения пользователей.
Средняя по словам запроса вероятность скачать файл с хоста (запросный фактор). Профит от этой фичи небольшой, но есть. Смысл как раз в том, что все большие сигналы давно используются в формуле. Интересно находить сигналы небольшие, но ценные в контексте известных факторов.
K-means не применим в рантайме, так как стучит минимум кубом и вообще не всегда сходится. Более того, в рантайме очень редко используется кластеризация вообще.
Формула — это набор действий над факторами (числами, характеризующими набор пользователь/запрос/документ), результатом работы которых является число, определяющее порядок ранжирования. Примерами действий могут быть такие: сложить, сравнить с порогом, домножить, заменить и т.п. Мы исходим из того, что размер формулы отражает рост количества этих действий, так как в процессе формат изменяеся не слишком сильно.
Статья, как и ее продолжение, не про поисковую систему в целом, а про то как создавать и улучшать одну единственную ее часть — формулу ранжирования. При этом, мы хотим сосредоточиться не на том, какие конкретно скрипты и с какими параметрами запускать, чтобы сделать так же, а на более общих проблемах с которыми мы столкнулись. В частности речь идет о создании экосистемы разработки вокруг задачи ранжирования, что является довольно сложной задачей, если разработкой занимается более 2-х человек.
Кстати, какого рода сравнение алгоритмов обучения ранжированию с алгоритмами кластеразации вы просите?
Обсуждаемый вопрос — очень сложная, неразрешенная проблема. На данный момент научное сообщество «тренируется» на соц. сетях в выявлении источников трендов/истории ретвитов. 3 или 4 работы на эту тему были на последнем WSDM. Однако, повторюсь, хорошего, применимого на практике решения пока в природе не существует (как минимум не известно авторам данной статьи). Тем не менее, проблема и боль, которая стоит за подобными сообщениями понятна и как только будет найдено хорошее решение оно будет внедрено.
1) мы верим асессорам (почему — отдельный вопрос);
2) стараемся собрать репрезентативное множество запросов (в том числе тех самых, трудных);
3) нам надо научиться предсказывать тот же порядок документов, что дают их оценки;
4) хотим планомерно улучшать качество п. 3.
И пункт 4 оказался очень нетривиальным, и именно его в рамках FML нам удалось поставить на поток. Что касается того, что узкое место «не там», то мы хотели проиллюстрировать свое утверждение внутренними метриками, но посчитали, что это неповторяемо и некорректно. Посетители доклада Mail.RU на последнем ECIR 2013 должны были наблюдать эффект по их измерителям. К сожалению у меня нету ссылки на их презентацию, если кто-нибудь добавит, буду очень благодарен.
habrahabr.ru/company/yandex/blog/175917/#comment_6115823
Если коротко, то настройка по сигналам от контролируемых экспертов — во многом обдуманный шаг, который позволяет определять внутри компании понятие качественного поиска, а не отдавать его на откуп текущей моде, или большинству пользователей. В качестве иллюстрации, по запросу [ягуар], средний пользователь 2 года назад хотел информацию про «ягу», но нам казалось, что это неверно, и сейчас, когда интерес к напитку пошел на спад мы видим, что были правы:
wordstat.yandex.ru/?cmd=words&page=1&t=%D1%8F%D0%B3%D1%83%D0%B0%D1%80&geo=&text_geo=
Асессоры — один из способов контролировать направление развития формулы ранжирования и разрабатываемые факторы должны соответствовать этому направлению с одной стороны, с другой, приводить к улучшению качества формулы с точки зрения пользователей.
Формула — это набор действий над факторами (числами, характеризующими набор пользователь/запрос/документ), результатом работы которых является число, определяющее порядок ранжирования. Примерами действий могут быть такие: сложить, сравнить с порогом, домножить, заменить и т.п. Мы исходим из того, что размер формулы отражает рост количества этих действий, так как в процессе формат изменяеся не слишком сильно.
www.dvery.ru/
www.bronedveri.com.ua/
www.roxter.com.ua/
www.bankproject.ru/
www.mirdverey.com.ua/
komplekt-opt.ru/
www.superdver.ru/
www.npp-modul.ru/
www.super-dveri.ru/docs?nart=58
www.testroy.ru/
Итого 3 совпадения с текущей выдачей.
Кстати, какого рода сравнение алгоритмов обучения ранжированию с алгоритмами кластеразации вы просите?