Мониторинг и отладка (B7)

Модель уехала в прод — и начинается наблюдаемость: данные дрейфуют, каталог обновляется, сама модель влияет на свои будущие данные. Здесь — реальный дашборд этого сервиса и интерактивный симулятор инцидентов по схеме «симптом → причина → проверка → фикс».

⚠ Верхний дашборд — настоящие числа (живой замер на моделях). Инциденты ниже — синтетика с иллюстративными значениями: цель — плейбук отладки, а не фейковая точность. Бизнес/онлайн-метрики (CTR/CVR/retention) требуют живого трафика и здесь не считаются.

загрузка мониторинга…

Теория простым языком

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

Что вообще мониторить: четыре слоя

Проблема может жить на любом уровне — и симптомы у них разные:

Данные (вход) — дрейф распределения фич, свежесть (staleness), объём и аномалии трафика, доля пропусков/null. Чаще всего ломается именно здесь и тихо.

Модель (выход) — дрейф распределения score, схлопывание coverage/diversity, концентрация в популярную голову. Калибровка — только если модель выдаёт вероятность (CTR/CVR-ранкер); для retrieval/ranking-score (ALS-dot, BPR, cosine, MMR) мониторят распределение score, margin, top-1/top-K gap и долю fallback/empty.

Система (serving) — latency p50/p95/p99, error rate, throughput, cache hit rate, таймауты и fallback-rate — доля запросов, где сработал fallback (popularity / cached / default) вместо основной модели. Empty может быть 0, а сервис уже деградировал, если половина пользователей тихо ушла в fallback.

Бизнес (онлайн) — CTR, CVR, watch-time, retention, guardrail-метрики. Исторический CTR/CVR по старым логам посчитать можно (если были impressions) — но это метрика старой политики, смещённая экспозицией, а не честная причинная оценка новой модели. Эффект новой модели проверяют живым трафиком / A-B (см. страницу метрик).

Срезы (slices) — все метрики смотрят не только глобально, но и по срезам: новые / малоактивные / power-пользователи, head / tail айтемы, платформа, регион, surface, источник трафика. Средний NDCG/CTR может быть стабилен, пока целая когорта уже сломана.

▸Почему offline-метрик недостаточно после запуска

БылоДо запуска модель хороша на отложенном test-срезе.

ПроблемаПосле запуска меняются пользователи, каталог и поведение — и сама модель влияет на данные, которые собирает.

ИдеяМониторить качество, дрейф, coverage, latency, свежесть и bias — непрерывно, а не разово.

Стало лучшеДеградации ловятся до крупных потерь; понятно, на каком слое искать причину.

Осталось слабымНе всё видно офлайн: нужны online-метрики и guardrails, а причинность проверяется экспериментом.

ДальшеA/B-тесты и counterfactual/IPS-оценка — в следующих модулях; дрейф и bias вживую — D2b.

Дрейф и train/serve skew

Дрейф (drift) — распределение входов или спроса меняется со временем, и модель, обученная на прошлом, устаревает. Меряют, например, PSI по бинам — мы это делали на дрейфе популярности в D2b.

▸Формула PSI и пороги

$\text{PSI}=\sum_i (p_i - q_i)\,\ln\frac{p_i}{q_i}$ по бинам. Практические пороги: <0.1 стабильно, 0.1–0.25 умеренный сдвиг, >0.25 значимый дрейф. Но это эвристика: пороги калибруют под домен, объём трафика, сезонность и конкретную фичу. И сравнивать лучше с релевантным baseline-окном (тот же день недели / час / сезон), а не всегда «сегодня против вчера». Тот же приём годится для train-vs-serving распределения фичи.

Train/serve skew — фичи в обучении (батч) и в сервинге (онлайн) считаются по-разному — другие дефолты, нормализация, версия кода. Офлайн-метрики отличные, а онлайн — плохо. Лечится единым feature-пайплайном и parity-тестами.

Деградация во времени: система влияет на свои же данные

Самое коварное — петля обратной связи: рекомендуем популярное → его больше кликают → оно ещё популярнее, а хвост не получает шанса. Coverage и diversity сползают неделя к неделе. Мы уже видели это с двух сторон:

Пример. В модуле про логи (B1) наивные клики раздували head-share 0.23 → 0.80, а ε-greedy exploration это лечил. В D2b персональный ранкер, наоборот, в голове каталога выдачу почти НЕ концентрирует (head-share 0.11 при каталоге 0.10) — он тянет пользователя в его личные места, а не в глобальный топ. Но концентрация никуда не делась, а переехала: Gini 0.74 и 45% топ-10 — уже посещённые места. Важная оговорка: в Brightkite нет impressions, поэтому это концентрация сгенерированной офлайн-выдачи (proxy exposure), а не реальных показов. Прежние 0.66 там создавала одна строка-заглушка в данных (см. D2a, «Качество данных»), и это отдельный урок: метрика смещения тоже бывает артефактом. Именно поэтому за coverage/Gini следят во времени, а не как за одним средним.

Плейбук отладки и алертинг

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

Guardrail-метрика — «предохранитель», который не должен просесть, пока гонимся за основной метрикой: coverage, доля хвоста, жалобы/отписки, latency. На него ставят алерт с порогом.

Алертить лучше на ранние диагностические (proximal) сигналы (freshness lag, PSI, p99), которые ближе к причине, чем выручка — но помни, что сам монитор причинность не доказывает (см. ниже). И на p99, а не только на среднее: медиана может быть в норме, когда хвост уже горит.

Сильные стороны

Ловит деградации до того, как их заметит бизнес.
Локализует слой проблемы (данные / модель / система / бизнес) → быстрее чинить.
Guardrails не дают «выиграть» краткосрочную метрику ценой долгосрочной.

Слабые стороны

Онлайн-эффект офлайн не измерить — нужен живой трафик и A/B.
Слишком чувствительные алерты → усталость от алертов; слишком грубые → пропуски.
Причинность требует эксперимента: корреляция монитора ≠ причина.

⚠️ Что может пойти не так

Смотреть только на среднее качество: деградация часто прячется в хвосте (p99) или в сегменте (long-tail, новые юзеры).
Мониторить модель, но не данные: свежесть/дрейф фич ломают качество тихо и без ошибок в логах.
Игнорировать петлю обратной связи: без exploration метрики какое-то время растут, а система схлопывается.
Алерт на выручку вместо ранних причинных сигналов — узнаёшь о проблеме последним.
Считать, что offline-победа = online-победа: это проверяют A/B-тестом, а не NDCG.

🧠 Проверь себя: Офлайн-метрики модели в норме, latency в норме, но онлайн-качество после деплоя резко упало. Куда смотреть в первую очередь?

Где это в дорожной карте

Это B7 — мониторинг и отладка: наблюдаемость поверх всей воронки. Дальше — честная онлайн-оценка (A/B-тесты, interleaving) и counterfactual/IPS-оценка смещённых логов, а также exploration/bandits как системное лекарство от петли обратной связи.