Pull to refresh

Comments 14

Будет ли пример признака, который, скажем, выглядит очень специфично, был внедрён недавно и дал прирост качества в x%?
Средняя по словам запроса вероятность скачать файл с хоста (запросный фактор). Профит от этой фичи небольшой, но есть. Смысл как раз в том, что все большие сигналы давно используются в формуле. Интересно находить сигналы небольшие, но ценные в контексте известных факторов.
Конечно запросно/хостовый фактор. Извините.
Прямо сейчас производительность GPU-кластера в Яндексе составляет 80 Tflops, но в скором времени мы планируем расширить его до 300 Tflops.

Сколько биткоинов можно намайнить… </сарказм>
Получается, что сначала пишется сравнительно быстрый расчет фактора, а после одобрения экспертным советом еще «вылизывается» до последнего такта и байта?

Приведите, пожалуйста, пример фактора документа, который рассчитывается в момент поиска.
BM25. Думаю почти все факторы, известные из литературы по IR, тем или иным образом опробованы, многие из них в формуле.
Получается, что сначала пишется сравнительно быстрый расчет фактора, а после одобрения экспертным советом еще «вылизывается» до последнего такта и байта?

Не совсем. Сначала делается «грязная» реализация, демонстрирующая только прирост в качестве — безотносительно вычислительных ресурсов. Если она не вызывает содержательных возражений у экспертов, дальше реализуется «чистая» версия, которая да, предельно оптимизируется по тактам и байтам :-)
Спасибо за внимательность! Исправили.
Приведу пример, когда описанная система не должна работать (поправьте, если это не так):

Пусть я придумал фактор, что если запрос на китайском и документ на китайском, то это сигнал.

Но оценки делали только русскоязычные асессоры. Китайские запросы и китайские документы асессоры не понимали, более того они даже не знали, какой это язык. Оценки ставили — либо случайно, либо в лучшем случае честно говорили, «не могу оценить».

Получается, «проверку практикой» такой фактор не пройдет. И что с того, что точность 0.1 процент?
Эта точность совсем другая. Она не показывает, что асессоры чего-то не знают.

Вот и получается «для десятков тысяч проверок различных факторов с разными комбинациями параметров были допущены к внедрению лишь несколько сотен»

Ты делаешь фактор, который интуитивно должен работать, а Ваша система тебе говорит — «проверка практикой не пройдена» — асессоры не чувствуют этот аспект — идешь гулять.

Ну вы понимаете, что из этого в итоге получается.

Далее IMHO, которое может не совпадать с позицией компании. Вы верно подмечаете, что подбор формулы не возможен без хорошо организованной системы оценки. И факторы, которые разрабатываются, в кренфилдской методике оценки, ловят не напрямую сигнал от пользователя, а сигнал от верифицированного(!) асессора. Проблема построения инструкции, обучения и контроля работы асессора — отдельная интересная тема для обсуждения, но она явно выходит за рамки данной статьи.

Если коротко, то настройка по сигналам от контролируемых экспертов — во многом обдуманный шаг, который позволяет определять внутри компании понятие качественного поиска, а не отдавать его на откуп текущей моде, или большинству пользователей. В качестве иллюстрации, по запросу [ягуар], средний пользователь 2 года назад хотел информацию про «ягу», но нам казалось, что это неверно, и сейчас, когда интерес к напитку пошел на спад мы видим, что были правы:
wordstat.yandex.ru/?cmd=words&page=1&t=%D1%8F%D0%B3%D1%83%D0%B0%D1%80&geo=&text_geo=

Асессоры — один из способов контролировать направление развития формулы ранжирования и разрабатываемые факторы должны соответствовать этому направлению с одной стороны, с другой, приводить к улучшению качества формулы с точки зрения пользователей.
В вашем интересном комментарии явно или неявно содержаться некоторые спорные утверждения:

1) оценку качества поиска на асессорах можно организовать хорошо и недорого
2) асессора можно один раз верифицировать, а потом использовать на других запросах
3) для асессоров можно написать хорошую и правильную инструкцию
4) работу асессора можно контролировать и стоимость этого контроля невелика
5) всегда есть кто-то кто понимает запросы, и знает правильные ответы

и самое главное
6) подход масштабируется и его можно поставить на поток (заголовок Вашей статьи)

Я пожалуй соглашусь, что данные утверждения работают для некоторых ограниченных классов запросов — фильмы, музыка… любые понятные и частотные запросы, где всем понятно, чего хочет пользователь.

Но к сожалению, многие важные запросы (на которых я выбираю себе поисковик) не относятся к этому классу. Все утверждения становятся спорными, как следствие спорным становится главный тезис — «ответ на вопрос, как поставить машинное обучение на поток»

Не исключено, что таких трудных запросов — большинство.

Как следствие — использование кластера 80-300 Тфлопс и самых крутых алгоритмов для таких запросов никак не приводит к росту качества поиска. То есть, скорее всего, при использовании мощностей в 100 раз меньше и числа факторов в 100 раз меньше, мы бы получили то же самое качество. Причина описана — узкое место в другом месте. Но в статье не разобран этот важный момент (как растет качество при росте Тфлопс в кластере, числа факторов и размера формулы машинного обучения). Почему этот момент не разобран? Если опять оффтопик — то ок.

Построение службы асессоров — это небыстрый, недешевый процесс, который масштабируется с потом и кровью. Система сдержек и противовесов для асессора, которая позволяет контролировать качество результатов вырабатывается годами (JFYI: первые оценки в Яндекс появились в 2003 году, если память мне не изменяет). Мы считаем, что этот кирпич у нас есть и мы в него верим, но из-за большого количества know how никому особенно «про это» не рассказываем. Теперь наша цель в том, чтобы как можно точнее отразить полученный от асессоров сигнал. Таким образом, логика следующая:

1) мы верим асессорам (почему — отдельный вопрос);
2) стараемся собрать репрезентативное множество запросов (в том числе тех самых, трудных);
3) нам надо научиться предсказывать тот же порядок документов, что дают их оценки;
4) хотим планомерно улучшать качество п. 3.

И пункт 4 оказался очень нетривиальным, и именно его в рамках FML нам удалось поставить на поток. Что касается того, что узкое место «не там», то мы хотели проиллюстрировать свое утверждение внутренними метриками, но посчитали, что это неповторяемо и некорректно. Посетители доклада Mail.RU на последнем ECIR 2013 должны были наблюдать эффект по их измерителям. К сожалению у меня нету ссылки на их презентацию, если кто-нибудь добавит, буду очень благодарен.
Ваша очень устойчивая позиция основана на Вере в правильность устоявшихся know how и нефальсифицируема.

Надеюсь, вы справитесь с турецким языком и пойдете дальше.
Sign up to leave a comment.