Capstone: система целиком (E3)

Финал офлайн-части: данные и split из D2a, пять источников кандидатов, ранкер из Фазы 8 и продуктовые правила из B6 соединены в одну воронку, посчитанную одним проходом. Здесь измеряется то, чего не видно ни в одном модуле по отдельности: маржинальная ценность источников, происхождение витрины и цена продуктового решения.

⚠ Всё считается офлайн из сырого лога (~2.02M событий) и приезжает готовым маленьким артефактом — VPS не обучает и сырых данных не видит. Это офлайн-полнота, а не production-полнота: чего здесь нет и почему — прямым списком в секции 8.

загрузка артефакта воронки…

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

Capstone — это не новый алгоритм, а сборка: те же данные, split, retrieval и ранкер, что строились по модулям, соединены в одну воронку — и измерено то, что видно только на стыке: кто из источников реально кормит систему.

▸Зачем capstone, если каждый кусок уже сделан

БылоМодули D2a/D2b/B-трека и Фаз 8/14 отвечали каждый за свой этап: датасет, split, фичи, ранкер, правила, мониторинг, cold-start, онлайн-оценка.

ПроблемаПо кускам не видно системных вопросов: сколько стоит выключить источник кандидатов? откуда приходят айтемы витрины? где потолок всей воронки? как продуктовые правила меняют ценность источников под ними?

ИдеяСобрать этапы в один пайплайн, посчитанный ОДНИМ проходом, с provenance на каждом кандидате — тогда цифры ступеней стыкуются друг с другом, а не собраны из разных замеров.

Стало лучшеПоявились ответы уровня системы: маржинальный вклад любого источника <1.5 п.п. при сольном recall до 0.93 (перекрытие); витрину больше всего кормит co-visitation, а не популярность; продуктовые правила стоят 8.9 п.п. агрегата, поднимают novel-recall на треть и режут долю history в витрине вдвое.

Осталось слабымОфлайн-полнота, но не production-полнота: нет живого трафика и propensities, нет impressions, feature store измерен, но не построен как инфраструктура, ANN не в проде воронки, eligibility синтетическая. Протокол наследует revisit-доминирование.

ДальшеДальше — то, чего в офлайне не бывает: живой A/B поверх выбранной конфигурации правил (Фаза 14), сессионные модели и бандиты из дорожной карты; перенос каркаса на другие продукты — E2.

Write-up: проект по каркасу жизненного цикла

Ниже — системный документ проекта по тем же 10 стадиям, что и E2 case studies, только с реальными цифрами и ссылками на модули, где каждая стадия строилась. Это формат, в котором принято описывать дизайн системы: цель → данные → протокол → архитектура → оценка → эксплуатация.

1Бизнес-задача и метрики успеха

Location-сервис: предсказать следующий чек-ин пользователя. Метрики успеха заданы здесь же, до данных: учебный аналог north-star — Recall@10 следующего визита; guardrails — не залипнуть в глобальном топе (coverage, head-share). Важное продуктовое решение принято на старте: возвраты — валидный таргет (89% следующих чек-инов — revisit), это не MovieLens с «remove seen».

2Сбор данных / логирование

Реальный positive-only лог: 2.02M чек-инов Brightkite (SNAP) после чистки заглушки геолокации, схема событий user/place/timestamp/гео. Честное ограничение зафиксировано сразу: нет impressions → нет настоящих негативов и propensity, IPS-коррекции недоступны. Концепты — B1, схема и датасет — D2a.

3Обработка данных

Глобальный temporal split по квантили 0.9 (никакого random-split — см. B2); вся метаданные мест (координаты, часовой профиль) агрегируются только из train — в D2b мы поймали и починили реальную утечку, когда они считались по полному логу. Зафиксирован scope: все recall-метрики проекта — warm-user evaluation; 56 из 1574 test-пользователей холодные (без train-истории) и из ранжирующего eval исключены — в проде их обслуживает fallback-политика (B5), здесь их качество не измеряется.

4Протокол офлайн-оценки

Цель задана на шаге 1 — здесь протокол её измерения, и он продиктован данными: лог positive-only (шаг 2) → Recall@K ≡ HitRate@K (один таргет на пользователя), MRR; отдельно — потолок retrieval (достижимость таргета в пуле) и разрез revisit vs novel, без которого agg-метрика лжёт. Гид по метрикам — /metrics.

5Выбор архитектуры

Трёхстадийная воронка, как в системном дизайне: retrieval = union 5 источников (история, co-visitation, transition, geo, popularity) с provenance каждого кандидата → ранкер (градиентный бустинг, Фаза 8) → продуктовые правила (eligibility, квоты, слот исследования — B6). Под всеми тремя ступенями лежит слой фичей, корректность которого — предмет B4: он не ступень воронки, но именно он решает, воспроизведутся ли эти числа онлайн. ANN (B3) сознательно НЕ в проде воронки: на каталоге 7.4k мест exact-скан дешевле. Cold-start закрыт лестницей fallback (B5).

6Обучение и офлайн-оценка (петля → 2–3)

Ранкер обучается на point-in-time фолдах внутри train (каждый фолд строит индексы на t ≤ cutoff и размечает первое событие следующего окна), на 8 фичах из D2b. Класс модели выбран замером, а не вкусом (Фаза 8): на этой воронке логрег даёт 0.9177, бустинг — 0.9203, то есть в агрегате разницы нет, и вся ценность нелинейности живёт на novel-срезе. Петля «не устроило → назад к данным» сработала в проекте трижды, и все три раза чинили данные и протокол, а не модель: revisit-баг протокола D2a, утечка метаданных D2b и место-заглушка «геолокация не определилась», которое было топ-1 каталога и давало 29% таргетов (разбор — в секции 7 лаборатории выше). Итог: top-10 recall 0.920 при потолке 0.958, на novel — честные ~0.10.

7Деплой / serving

Паттерн проекта: тяжёлое считается офлайн локально (make implicit), на сервер едет маленький JSON-артефакт; MovieLens-модели тренируются локально и уезжают релизами weights-vN с hot-reload — сервер никогда не обучает. Отдельное свойство продуктового слоя: он считается на лету (re-rank поверх готовых слейтов — доли секунды), поэтому правила выдачи меняются без переобучения — это видно в живом конструкторе B6. Живой serving воронки можно потрогать на /system-design (MovieLens).

8Онлайн-оценка (A/B)

Честно: у учебного проекта нет живого трафика, поэтому онлайн-стадия здесь — осознанный пропуск, а не забытая. Что бы мы делали: A/B по пользователям на north-star + guardrails; почему офлайн ≠ онлайн и как лог старой политики смещает оценку — разобрано в E2-кейсах и придёт практикой в Фазе 14 (A/B, IPS/DR; причём IPS/DR возможны, только если логируются propensities / есть randomized exploration — к произвольным старым логам их «просто применить» нельзя). Конкретная гипотеза для теста у нас уже есть и сформулирована численно: выбранная конфигурация продуктовых правил стоит 8.9 п.п. агрегата и поднимает recall на новых местах с 0.109 до 0.146. Офлайн умеет посчитать только цену — вопрос «стоит ли discovery этих потерь» решается на живом трафике.

9Мониторинг

На этих же данных измерен дрейф популярности: PSI по децилям стабильного каталога растёт 0→0.57→0.76→1.15 между срезами. Все значения >0.25 — сильный drift-alert по эвристическим порогам: это повод для расследования и проверки качества на свежем срезе и, вероятно, ретрейна — но сам PSI не доказывает, что модель уже деградировала. Смещения зафиксированы: head-share офлайн-выдачи 0.11 при каталоге 0.10 — то есть персональный ранкер на этих данных почти НЕ концентрирует выдачу в голове каталога (прежние 0.66 целиком создавала заглушка), но Gini 0.74 и 45% уже посещённых мест в топ-10 говорят, что концентрация просто переехала на личную историю. Дисциплина симптом→причина→проверка→фикс — B7.

10Поддержка и итерация (петля → 2)

Известные failure modes системы: revisit-петля (рекомендуем то, куда и так ходят — reinforcement 0.46; частично лечится квотой из B6), потолок retrieval деградирует с дрейфом, качество на новых для пользователя местах остаётся низким (0.146 даже после правил), а ценность источника зависит от продуктового слоя над ним — правила режут долю history в витрине вдвое. Каждый пункт ведёт назад к данным: новые срезы, ретрейн, пересмотр источников по маржинальному вкладу и пересмотр квот по онлайн-эффекту.

Главный урок сборки

Метрики компонента и метрики системы — разные вещи. Каждый источник кандидатов по отдельности выглядит сильным (сольный recall до 0.93), но система почти не замечает потери любого из них — перекрытие сигналов огромно: максимальный маржинальный вклад 1.45 п.п. у history. И наоборот: co-visitation с сольным recall всего 0.53 покрывает 64% финального слейта (source coverage, не причина показов) — вклад в пул и вклад в витрину это разные величины. Решения о компонентах в production принимаются на уровне воронки: Δ recall без источника, сегменты, устойчивость — не сольные метрики.

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

Оценивать источник кандидатов по сольному recall — измеряй Δ recall union-пула без источника и сегменты, которые он закрывает эксклюзивно.
Читать slate provenance как причину показа — это source coverage (у кого айтем был в кандидатах); в слейт его поднял ранкер по фичам, а не факт источника.
Читать recall 0.92 как качество модели — это revisit-мираж протокола; на novel-таргетах воронка даёт ~0.10 при потолке ретривала 0.43.
Считать потолок retrieval константой — он живёт: дрейф (PSI до 1.15 между срезами) со временем размывает и пул, и ранкер.
Выключать «дублирующий» источник только из экономии — перекрытие даёт устойчивость: упал один источник, воронка продолжает работать.
Выдавать офлайн-полноту за production-полноту: здесь нет живого трафика, propensities и impressions, а feature store измерен, но не построен — список границ целиком в секции 8 лаборатории.
Оценивать retrieval-источник по метрикам ДО re-rank: продуктовые правила режут источники неравномерно (доля history в витрине падает вдвое), и ценность источника зависит от слоя над ним.

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

Это E3 — полный capstone, сборочный финал офлайн-части и центр портфолио: retrieval (D2a/E3) → ранкер (Фаза 8) → продуктовые правила (B6), поверх слоя фичей (B4), с мониторингом (B7) и fallback-политикой (B5). Что осталось за границей офлайна: живой трафик и онлайн-оценка, сессионные модели (Фаза 9) и бандиты (Фаза 12) — они в дорожной карте.