Данные и логирование

Потому что разные данные имеют разную свежесть и разную стоимость подсчёта. «Пользователь любит молочку» — агрегат за 90 дней, за 50 мс на запросе его не посчитать. «Молоко уже в корзине» видно только в реальном времени. Всё считать в рантайме дорого, всё заранее — неактуально или невозможно.

Отсюда лямбда: batch пересчитывает агрегаты с нуля раз в сутки, speed инкрементально обновляет по событиям, serving хранит две зеркальные части, а отдельный сервис профиля их мержит с учётом того, что batch мог уже учесть часть событий из дельт.

Главная боль — одна логика агрегации живёт в двух местах: баг чинить дважды, деплой дважды, часто разные языки и разные команды.

Расхождение способа подсчёта признака между обучением и инференсом. Канонический пример: офлайн считает возраст клиента от первого заказа, онлайн — от регистрации. Модель обучается на одном, инферит на другом.

Масштаб: при разрыве в 14 дней доля клиентов старше порога сдвигается на 4.6 п.п. в середине распределения, где сосредоточена основная масса. И это одна фича из сотен.

Feature skew — вторая по частоте причина расхождения офлайн- и онлайн-результатов после неправильно выбранной метрики. Лечится общей библиотекой вычисления признаков, которую зовут и офлайн, и онлайн.

Логирование даёт ровно то, что видела модель, гарантирует одинаковое распределение и позволяет воспроизвести предикт. Цена — место и задержка: при 10⁸ запросов, 100 кандидатах и 500 признаках это 20 ТБ в сутки и 7.3 ПБ в год, а новый признак становится доступен для обучения только через окно обучения после начала записи.

Реконструкция снимает и то и другое, но точно восстановить состояние почти невозможно, не все признаки восстановимы (это ограничивает дизайн), и легко получить утечку из будущего.

Промежуточное решение — логировать только показанных: десятикратная экономия, но теряется информация о непоказанных кандидатах, нужная для офлайн-оценки политик.

Бэкенд: идентификаторы запроса, пользователя и айтема, серверное время, позиция, скор модели. Фронтенд: обязательно идентификатор запроса, с которого пришёл айтем, плюс идентификаторы, плюс время — серверное или по попаданию в хранилище, клиентским часам верить нельзя.

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

Склейка идентификаторов одного человека: user_id при логине, device_id разных устройств, cookie_id. Без неё история размазана.

Конкретно: у пользователя 60 событий, порог содержательной истории — 20. На пяти идентификаторах получается по 12, и ни один порога не достигает — человек выглядит новичком по каждому своему устройству. Это фейковый холодный старт: история есть, но раздроблена.

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

Доля запросов, для которых признак доступен. Следят по двум причинам.

Первая — арифметика накопления: при 50 признаках с покрытием 0.95 у каждого полный вектор есть лишь у 7.7% запросов. Работа с пропусками — основной режим, а не краевой случай.

Вторая — расхождение обучения и прода: обучались при покрытии 0.87, в проде 0.60, доля запросов в невиданном режиме выросла с 13% до 40%. Поведение модели там непредсказуемо.

И резкое падение покрытия почти всегда означает поломку выше по потоку — это самый дешёвый сигнал тревоги из существующих.

Covariate — изменилось распределение X (новая когорта, кампания, сезон); лечится переобучением и починкой источника. Label — изменилось распределение Y (кликрейт вырос, потому что пришла лояльная аудитория); надо разобраться в причине. Concept — изменилась сама связь X → Y; самое трудное, переобучение помогает, только если контент успевает.

Различать важно, потому что label drift легко принять за успех модели.

Детекция: для признаков — PSI по децилям обучающего распределения, пороги 0.10 и 0.25. Порядок величин полезно помнить: сдвиг в полсигмы даёт PSI 0.24, а в четверть сигмы — только 0.06. Для предсказаний — распределение скоров на инференсе. Для таргетов — посуточный CTR по сегментам.

Три варианта конвейера: руками (для старта), по расписанию (достаточно для большинства задач), по триггеру — падение метрики, детекция дрейфа, накопление N примеров (для новостей и подобного).

Нейросетям тут удобнее бустинга: бустинг обучается с нуля каждый раз, а сеть можно дообучить поверх старых весов, заморозив нижние слои.

Риски онлайн-дообучения: забывание паттернов, важных для редких сегментов; усиление петли обратной связи, потому что модель быстрее замыкается на собственных рекомендациях; и быстрое впитывание аномалий вроде бот-атаки. Обычно комбинируют: регулярное полное переобучение как якорь плюс быстрое дообучение сверху.