Ранжирование в Яндексе: как поставить машинное обучение на поток (пост #2)

Мы продолжаем серию публикаций о нашем фреймворке FML, который автоматизировал работу с машинным обучением и позволил разработчикам Яндекса использовать его в своих задачах проще и чаще. Предыдущий пост рассказывал о том, что такое функция ранжирования и как мы научились строить её, имея на входе лишь достаточно большое число оценок от асессоров и достаточно разнообразный набор признаков (факторов) документов по большому количеству запросов.

Из этого поста вы узнаете:

1. почему нам нужно подбирать новую формулу ранжирования очень часто, и как именно нам в этом помогает FML;
2. как мы разрабатываем новые факторы и оцениваем их эффективность.

Подбор формулы ранжирования

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

Как уже было упомянуто, интернет быстро меняется и нам нужно постоянно повышать качество поиска. Наши разработчики непрерывно ищут, какие новые факторы могли бы нам помочь в этом. Наши асессоры каждый день оценивают тысячи документов, чтобы оперативно обучать алгоритмы новым видам закономерностей, появляющимся в интернете, и учитывать изменения в полезности уже оцененных ранее документов. Поисковый робот собирает в интернете массу свежих документов, что постоянно меняет средние значения факторов. Значения могут изменяться даже при неизменных документах, так как алгоритмы расчета факторов и их реализация постоянно совершенствуются.

Чтобы оперативно учитывать в формуле ранжирования этот поток изменений, нужен целый технологический конвейер. Желательно, чтобы он не требовал участия человека или был для него максимально простым. И очень важно, чтобы внесение одних изменений не мешало оценке полезности других. Именно таким конвейером и стал FML. В то время, как Матрикснет выступает «мозгом» машинного обучения, FML является удобным сервисом на его основе, использование которого требует гораздо меньше специальных знаний и опыта. Вот за счёт чего это достигается.

Во-первых, под каждую конкретную задачу, с которой к нам приходит разработчик, FML рекомендует параметры запуска Матрикснета, наилучшим образом соответствующие условиям и ограничениям задачи. Сервис сам подбирает настройки, оптимальные для конкретного объёма оценок — например, помогает выбрать целевую функцию (pointwise или pairwise) в зависимости от размера обучающей выборки.

Во-вторых, FML обеспечивает прозрачную многозадачность. Каждая итерация подбора формулы — это многочасовой расчёт, требующий полной загрузки нескольких десятков серверов. Как правило, одновременно происходит подбор десятка разных формул, а FML управляет нагрузкой и обеспечивает каждому разработчику изоляцию его расчётов от расчётов коллег, чтобы они не мешали друг другу.

В-третьих, в отличие от Матрикснета, который нужно запускать вручную, FML обеспечивает распределённое выполнение ресурсоёмких задач на кластере. Это включает и использование всеми единой и самой свежей версии библиотек машинного обучения, и раскладку программы на все машины, и обработку возникающих сбоев, и сохранение уже проведённых расчётов, и верификацию результатов в случае перезапуска вычислений.

Наконец, мы воспользовались тем, что на вычислительно сложных задачах можно получить весьма существенный выигрыш в производительности, если запускать их на графических процессорах (GPU) вместо процессоров общего назначения (CPU). Для этого мы адаптировали Матрикснет под GPU, за счет чего получили более чем 20-кратный выигрыш в скорости расчётов на единицу стоимости оборудования. Особенности нашей реализации алгоритма построения деревьев решений позволяют нам использовать высокую степень параллелизма, доступную на GPU. Благодаря тому, что мы сохранили программные интерфейсы, которыми пользуется FML, нам удалось предоставить коллегам, работающим над факторами, новые вычислительные мощности, не изменяя привычных процессов разработки.

Разработка новых факторов и оценка их эффективности

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

Их создание — очень сложный процесс. Далеко не любая идея выдерживает в нём проверку практикой. Иногда на разработку и настройку хорошего фактора может уйти несколько месяцев, а процент гипотез, подтверждённых практикой, крайне невелик. Как у Маяковского: «В грамм добыча, в год труды». За первый год работы FML для десятков тысяч проверок различных факторов с разными комбинациями параметров были допущены к внедрению лишь несколько сотен.

Долгое время в Яндексе для работы над факторами нужно было, во-первых, глубоко понимать устройство поиска вообще и нашего в частности и, во-вторых, иметь неплохие знания о машинном обучении и информационном поиске в целом. Появление FML позволило избавиться от первого требования, ощутимо снизив тем самым порог входа в разработку факторов. Количество специалистов, которые теперь могут ею заниматься, выросло на порядок.

Но в большом коллективе потребовалась прозрачность процесса разработки. Раньше каждый ограничивался лишь проверками, которые сам считал достаточными, а качество измерял «на глазок». В результате получение хорошего фактора оказывалось скорее предметом искусства. А если гипотеза фактора отвергалась, то по прошествии времени нельзя было ознакомиться с тестами, по которым было принято решение.

С появлением FML разработка факторов стала стандартным, измеримым и контролируемым процессом в большом коллективе. Появилась и перекрёстная прозрачность, когда все смогли увидеть, что делают коллеги, и возможность контролировать качество проведённых ранее экспериментов. Кроме того, мы получили такую систему контроля качества производимых факторов, которая допускает плохой результат с гораздо меньшей вероятностью, чем на ведущих мировых конференциях в области информационного поиска.

Для оценки качества фактора мы делаем следующее. Разбиваем (каждый раз новым случайным образом) множество имеющихся у нас оценок на две части: обучающую и тестовую. По обучающим оценкам мы подбираем две формулы — старую (без тестируемого фактора) и новую (с ним), а по тестовым — смотрим, какая из этих формул лучше. Процедура повторяется много раз на большом количестве разных разбиений наших оценок. В статистике этот процесс принято называть перекрёстной проверкой (cross-validation). Нам она позволяет убедиться в том, что качество новой формулы лучше старой. В машинном обучении такой метод известен как уменьшение размерности с использованием wrappers. Если оказывается, что в среднем новая формула даёт заметное улучшение качества по сравнению со старой, новый фактор может стать кандидатом на внедрение.

Но даже если фактор доказал свою полезность, нужно понять, какова цена его внедрения и использования. Она включает в себя не только время, которое разработчик потратил на проработку идеи, его реализацию и настройку. Многие факторы необходимо рассчитывать непосредственно в момент поиска — для каждого из тысяч документов, найденных по запросу. Поэтому каждый новый фактор — это потенциальное замедление скорости ответа поисковой системы, а мы следим, чтобы она оставалась в очень жёстких рамках. Это значит, что внедрение каждого нового фактора должно быть обеспечено увеличением мощности кластера, отвечающего на запросы пользователей. Есть и другие аппаратные ресурсы, которые нельзя расходовать безгранично. Например, себестоимость хранения в оперативной памяти каждого дополнительного байта на документ на поисковом кластере составляет порядка 10 000 долларов в год.

Таким образом, нам важно отбирать из многих потенциальных факторов только те, у которых соотношение прироста качества к издержкам на оборудование будет самым лучшим — и отказываться от остальных. Именно в измерении прироста качества и оценке объёма дополнительных затрат и состоит следующая после подбора формул задача FML.

Говоря про аппаратные ресурсы, мы оцениваем три составляющих: вычислительную стоимость, объём диска и объём оперативной памяти. Со временем у нас даже выработались «разменные курсы»: насколько мы можем ухудшить производительность, сколько байт диска или оперативной памяти готовы заплатить за повышение качества на 1%. Расходование памяти оценивается экспериментально, прирост качества берётся из FML, а уменьшение производительности оценивается по результатам отдельного нагрузочного тестирования. Тем не менее, некоторые аспекты не удаётся оценивать автоматически — например, не привносит ли фактор сильную обратную связь. По этой причине существует экспертный совет, который имеет право вето на внедрение фактора.

Когда приходит время внедрения формулы, построенной с использованием новых факторов, мы проводим A/B-тестирование — эксперимент на небольшом проценте пользователей. Он нужен, чтобы убедиться в том, что новое ранжирование «нравится» им больше, чем текущее. Окончательное решение о внедрении принимается на основе пользовательских метрик качества. В каждый момент времени в Яндексе проводятся десятки экспериментов, и мы стараемся сделать этот процесс незаметным для пользователей поисковой системы. Таким образом мы добиваемся не только математической обоснованности принимаемых решений, но и полезности нововведений на практике.

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

Автор: yurkennis

Источник