Мы фанаты машинного обучения. Часть 1.
Допустим, система машинного обучения получила некую небессмысленную зависимость, позволяющую улучшить релевантность запроса по оценке асессоров. Что происходит дальше?
Мы выкатываем это изменение в общей формуле ранжирования на части пользователей и смотрим на их реакцию. Делается это по методике, которую мы сами не так давно разработали, FML (friendly machine learning). Упрощенно говоря, делается это следующим образом: берутся два результата ранжирования, по старой (C) и по новой формуле (Н), и перемешиваются по очереди — примерно так же, как отбираются футбольные команды в дворовом футболе. Получаются два варианта «смеси»: С1, Н1, С2, Н2, … и Н1, С1, Н2, С2, … где С1 — первый URL по старой формуле, Н1 — первый URL по новой формуле, С2 — второй URL по старой формуле и так далее. Какая «смесь» демонстрируется пользователю, определяется случайно. А далее мы фактически имеем дело с голосованием пользователей за ту или иную систему ранжирования, о котором они сами не знают. При этом мы, конечно, проводим статистический анализ и видим, значимо ли улучшение или нет. Потом эти улучшения вносятся в формулу. В год таких поправок мы вносим где-то около сотни, по несколько штук каждые две недели.
Какие из последних поправок в формулу вы можете привести в пример?
Самые последние я, к сожалению, не могу назвать, потому что мы их еще не анонсировали. Но вот из недавних, например: мы научились для запросов класса «смотреть онлайн» оценивать вероятность того, что пользователь действительно что-то посмотрел на данной странице. Для видеохостингов — узнавать, сколько процентов данного ролика просмотрел пользователь, прежде чем закрыть вкладку. Понятно ведь, что если ролик не стали смотреть, значит он не очень соответствовал ожиданиям.
Поправки в вашу формулу ранжирования недавно пыталось внести и государство. Я имею в виду последние предложения Минкульта, от которых оно уже вроде бы отказалось. Такие пожелания поднимать в поисковой выдаче правильные с чьей-то точки зрения ресурсы вообще реализуемы?
Вообще не реализуемы. У нас же машинное обучение, оно, как зеркало, отражает именно то, что хотят найти пользователи. Мы фанаты машинного обучения, мы вообще никогда не вмешиваемся в поиск «вручную».
Если вы не вмешиваетесь в поиск и у вас есть такая замечательная автоматическая методика проверки качества поиска, то зачем вообще использовать ручные оценки асессоров?
На это есть по крайней мере две причины. Во-первых, люди врут. Они могут искать, скажем, реферат по истории, а переходить при этом на порносайты — это же интереснее. Во-вторых, врут авторы сайтов. Они могут создавать видимость того, что на сайте есть какой-то контент, а на самом деле его там нет. Ведь по сниппету, тому окошечку с фрагментом сайта, который выдает поисковая машина, понять, подходящий ли это сайт, не всегда возможно. Пользователь перешел на сайт, потратил там какое-то время. А нашел он там то, что нужно, или нет — мы не знаем и можем только об этом догадываться.
Еще одна важная проблема при оценке качества — редкие запросы, на которые нет статистики, так называемый длинный хвост. Их на самом деле очень много — из всех запросов около30-40процентов приходятся на те, что никто никогда еще не задавал. Поэтому без живых асессоров невозможно понять, насколько качественно работает поиск.
Асессоры оценивают странички выдачи поисковой машины или отдельные URL?
Ни то, ни другое — они оценивают пары запрос-URL, причем в запросе подшита информация о географии пользователя, и эта информация учитывается в оценке. Потому что, условно, релевантный для Екатеринбурга сайт по запросу «ресторан суши» будет нерелевантным для Новосибирска, и наоборот.
Чтобы измерить качество поиска, мы пропускаем случайную выборку запросов через асессоров, которые оценивают пары запрос-URL, выставляя им оценки: «витальный», «важный», «релевантный» или «нерелевантный». Каждой из оценок соответствует некая вероятность того, что человек найдет на этом сайте то, что ему нужно.
И какая страница будет витальной по запросу «погода»? «Яндекс.Погода»?
Нет. На самом деле для такого рода запроса витального URL нет. Под витальным подразумевается страница сети «ВКонтакте» в ответ на запрос «вконтакте». Или соответствующая статья с описанием хоботного млекопитающего на запрос «слон статья из википедии». Витальный URL — это тот, у которого нет разумных альтернативных вариантов, когда совершенно понятно, куда хочет попасть пользователь. На запрос «погода» полезных URL может быть несколько, это и «Гисметео», и «Яндекс.Погода», и несколько других сайтов, каждый из которых получает одинаковую оценку. При оценке сайтов мы ни в коем случае не отдаем предпочтение собственным сервисам.
Что происходит после того, как асессоры оценили релевантность запроса-URL?
Имея ранжированную страницу с результатами поиска, где все URL оценены асессорами, мы оцениваем качество поиска с помощью специальной метрики pfound. Она вычисляет вероятность того, что человек нашел то, что искал на странице выдачи, суммируя такие вероятности для разных URL — каждой из четырех оценок асессора присвоена своя вероятность полезности. При этом в ходе суммирования мы учитываем, что вероятность полезности этой строки нужно умножать на вероятность того, что ее вообще прочитают. То, что нужно пользователю, может найтись в предыдущей строчке, кроме того, он может просто устать и прекратить чтение списка. В общем, получается такая формула суммирования вероятностей, которая и позволяет нам оценивать качество поиска — как своего, так и конкурентов.
Итак, с одной стороны, мы имеем метрику для оценки качества поиска, с другой стороны, имеем систему машинного обучения, которая пытается максимизировать эту метрику. Чем больше оцененных запросов мы будем направлять в «Матрикснет», тем лучше будет работать поиск.
Эта метрика, насколько я понимаю, специфична именно для конкретного запроса. А человек ведь не мыслит запросами, он мыслит задачами. Существуют ли способы измерить, нашел ли человек то, что искал, независимо от запроса?
На нашем сленге эта метрика называется «счастье пользователя». Да, такие опыты мы делаем. Выглядит это так: человеку ставят задачу, скажем, найти героев Куликовской битвы. Он может задавать любые запросы, переформулировать их, читать какую-то новую информацию, снова переформулировать запросы. В какой-то момент он находит то, что нужно, и записывает ответ. Мы со своей стороны пытаемся минимизировать то время, которое человек на это потратил.
Все эксперименты, которые мы проводили, говорят о том, что метрика счастья очень хорошо коррелирует с метрикой pfound. То есть пользователь, конечно, ведет себя сложнее, чем подразумевает модель pfound, но данных настолько много, что вся эта сложность усредняется.
Хорошо, а как же тогда персонализация? Если pfound построена на оценках асессоров, каких-то неизвестных мне людей, то как вы можете оценить качество персонализированной выдачи?
Правильно, pfound и нельзя для этого использовать. Но вы же помните, у нас есть метод смешивания разных результатов ранжирования. Если мы вносим в формулу новые, связанные с персонализацией факторы, их эффективность можно проверить именно таким образом.
Допустим, вы любите слушать музыку на одном сайте, а я — на другом. В персонализованной выдаче, когда вы вводите название песни, то получаете ее на том сайте, который любите вы, а я — на том, который люблю я. Результаты выдачи разные, но в обоих в формулу входит предыдущая история посещений страниц. Результаты поиска с учетом и без учета истории можно смешать и посмотреть, какой из них больше нравится пользователям. Опыт показывает, что обычно очень нравится. Особенно это видно на таких классах поисковых задач, когда человек хочет сделать какое-либо действие на привычном сайте, то есть, например, купить что-то, скачать, поиграть в онлайн-игру. То есть если человек привык смотреть кино на определенном сайте, то он очень хорошо находит его в десятке. Когда поисковая машина начинает такие результаты лично для него поднимать в выдаче, он отлично на это реагирует, быстрее находит то, что ему нужно. А другой любит другой хостинг и находит именно его.
Другие части: