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

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

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

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

Обновление обычных счетчиков за конечный период (временной интервал) не совсем просто. Автономная обработка может просто пересчитать значение для нового периода, но в режиме реального времени количество старых событий, выходящих за пределы окна вычислений, необходимо вычесть и добавить новые. Для этого необходимо хранить эти старые события или их совокупности в течение более коротких периодов времени (например, каждые 5 минут или полчаса). С другой стороны, экспоненциальные счетчики легко обновлять:

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

Как улучшить функции CTR

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

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

Признавая, что не все показы одинаковы и некоторые из них могут быть «хорошими», а другие — «плохими», в сфере поиска информации был разработан показатель CoEC, то есть кликов по сравнению с ожидаемыми кликами. Вместо базового соотношения клики/показы CoEC использует клики/(ожидаемые клики), где ожидаемые клики – это сумма независимых от документа показателей. вероятность кликов для всех показов. Документ, получивший больше кликов, чем ожидалось, считается хорошим; меньшее количество кликов указывает на плохой документ. Средний документ будет иметь CoEC, равный 1.

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

Это широко используемый вариант CoEC, который эффективно борется с предвзятостью позиции. Позиция может быть не просто числом; это может означать местоположение на странице, размеры, устройство и т. д. Главное — точно рассчитать кривую кликов. Но вы можете пойти еще дальше, учитывая другие особенности, например поведение пользователя. Например, некоторые пользователи являются активными кликерами, а другие — пассивными кликерами, что существенно влияет на ожидаемое количество кликов. Вы можете довести эту идею до крайности, используя все независимые от документа функции. Однако практичность этого подхода спорна, поскольку для оценки вероятности клика требуется отдельная модель.

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

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