Разрабатывая алгоритмы машинного обучения (ML) в производственной среде, мы обычно оптимизируем функцию или потерю, которая не имеет ничего общего с нашими бизнес-целями. Обычно мы заботимся о таких показателях, как CTR или разнообразие или доход от рекламы, но наши алгоритмы машинного обучения часто минимизируют потерю журнала Или среднеквадратичная ошибка (RMSE) произвольных величин для упрощения вычислений. Часто можно увидеть, что эти метрики машинного обучения не коррелируют с исходными целями, поэтому проведение онлайн-тестов A / B так важно в производственной среде, поскольку позволяет нам проверять наши модели машинного обучения на соответствие истинным целям задачи.

Однако проведение A / B-тестов обходится дорого, потому что для этого требуется некоторая производственная версия эксперимента, который должен выполняться в течение значительного количества времени для получения надежных результатов, во время которых вы рискуете потенциально подвергнуть более слабую систему пользователям. Вот почему надежная автономная оценка абсолютно критична - она ​​побуждает к большему количеству экспериментов в среде песочницы, а также помогает получить интуитивное представление о том, что стоит запускать / тестировать в дикой природе.

Классическая автономная оценка пользовательских интерактивных систем

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

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

Например, представьте, что в задаче рекомендации новостей вы пытаетесь оценить два алгоритма, которые по-разному работают для двух разных типов контента (основная публикация и длинный хвост). На первый взгляд может показаться очевидным, что алгоритм 2, вероятно, «лучше», чем алгоритм 1, но в промышленности часто бывает так, что вы можете иметь Алгоритм 1 запущен в производственной среде, и вы, возможно, поняли, что он плохо работает для содержимого с длинным хвостом и, следовательно, в основном только рекомендуемых статей из основных публикаций и сильно переоценивает истинную производительность алгоритма.

Если бы пользователи были ознакомлены с истинным распределением основных публикаций и длинным хвостом контента с помощью нашего производственного алгоритма, мы могли бы справедливо оценить наши алгоритмы в автономном режиме. Чтобы смягчить предвзятость представления, мы всегда можем выбрать небольшую часть пользователей, которым всегда показываются равномерно случайные результаты, и обратная связь, которую мы наблюдаем по этим результатам, не будет иметь такого же смещения выборки, как существующий алгоритм в производстве. Очевидно, что это может быть чрезвычайно сложно продать любому бизнесу / продукту, чтобы показать некоторым пользователям полностью поддельные результаты. Поскольку показывать равномерно случайные результаты в большинстве случаев непрактично (тем не менее, некоторым компаниям это удалось), в этой публикации исследуются альтернативные возможности автономной оценки с использованием контрфактического мышления.

Автономная оценка как проблема регрессии

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

Учитывая этот набор данных, относительно просто изучить предсказатель вознаграждения в зависимости от пользовательского контекста и рекомендуемых элементов, если мы думаем о проблеме автономной оценки как о классической проблеме линейной / гребенчатой ​​регрессии.

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

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

Контрфактическое мышление

Еще одна причина, по которой обычный предсказатель вознаграждения не работает так хорошо, заключается в том, что автономная оценка по сути является интервенционной проблемой, а не наблюдательной. Мы только наблюдаем за зарегистрированными данными, сгенерированными алгоритмом в производственной среде, и пытаемся оценить, что, если бы пользователям были рекомендованы какие-то другие элементы. Существуют некоторые сложные различия в наблюдении в журналах и настройке на разные значения (контрфакты) и попытке оценить вознаграждение. Ferenc Huszár имеет несколько действительно хороших блогов о сложных различиях по этому поводу, и я настоятельно рекомендую проверить их.

Оценка обратной склонности

Учитывая противоречивую структуру, моделирование систематической ошибки в журналах напрямую, а не моделирование вознаграждения, работает намного лучше для автономной оценки. Одним из классических способов сделать это может быть Оценка обратной склонности (IPS), которая оценивает лечение независимо от записанных искажающих факторов. Ключевой идеей IPS является повторное взвешивание выборок на основе склонностей регистрируемых элементов с помощью выборки важности. Склонность в этом контексте - это просто вероятность того, что элемент будет показан пользователю в момент регистрации.

Если бы склонности к живому алгоритму регистрировались, наш автономный набор данных выглядел бы больше как. На основе этих данных IPS дает нам объективные оценки производительности любого алгоритма с:

Где склонность к тому, чтобы элемент был рекомендован пользователю по новому другому алгоритму. Из-за природы уравнения для любого элемента, рекомендованного новым алгоритмом, склонность к этому элементу должна быть ненулевой. Вот пример кода Python, который позволяет оценить производительность нового алгоритма в автономном режиме.

Практические моменты и ингредиенты для работы

Детерминированные алгоритмы ранжирования

Большинство интерактивных систем, как правило, находятся в режиме полной эксплуатации и оценивают список элементов на основе содержимого или совместной (или обеих) фильтрации, а затем жадно ранжируют / сортируют перед показывая их пользователю. Однако для работы IPS система должна быть стохастической, и многие производственные системы не используют такие стохастические алгоритмы. Функция propensity_production в приведенном выше фрагменте кода в детерминированном алгоритме всегда равна 1, и поэтому она не предоставляет требуемую информацию.

Практический способ обойти это - получить полиномиальные образцы без замены, то есть создать взвешенные кубики на основе результатов и бросить для каждого предмета, повторно взвешивая кубики после каждого броска. Если у нас есть оценка для каждого (user_id, item_id) кортежа, то мы можем просто использовать NumPy's np.random.choice с replace=False. Иногда это также называют методом Плакетта-Люса, и главное преимущество этого решения заключается в том, что режим этого полинома является детерминированной функцией с обратной сортировкой.

Ненулевые склонности к предметам

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

Возможные улучшения - IPS имеет высокую дисперсию и высокую сложность выборки

Хотя IPS позволяет вашему оценщику приблизиться к реальной производительности в пределе, это по-прежнему чрезвычайно требовательный к выборкам алгоритм (требует большого количества журналов), и оценки могут иметь высокую дисперсию с несколькими выборками. Если у вас много журналов, то это вероятно не проблема, но Адит Сваминатан и Торстен Иоахимс разработали лучшую нормализацию проблемы, которая делает IPS немного менее требовательным к выборке и оценивается к:

Обратите внимание, что в Vanilla IPS, чтобы правильно оценить что-то вроде рейтинга кликов, мы могли бы просто взглянуть на клики (при условии, что FEEDBACK_WEIGHT для отсутствия кликов равно 0) и накопить наши utility, но в СНиП, нормализация (знаменатель) должна накапливаться по всей обратной связи. Если вы не работаете с идеальной системой, в которой щелкают по большинству рекомендуемых элементов, для этого требуется значительно увеличенное хранилище регистрируемых событий использования, но утилита сходится намного быстрее. Торт нельзя есть и есть его.

Заключительные мысли

Оценка A / B-тестов в автономном режиме может быть крайне недооцененным инструментом для любого бизнеса. Эти методы оказались весьма успешными для оценки идей в автономном режиме во многих компаниях, таких как Yahoo, Microsoft, Netflix и Pandora, на основе семинара REVEAL на RecSys 2018.

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

Первоначально опубликовано на https://abhadury.com.