ML recommendation system вайб-кодингом: учебный проект production-уровня

Проблема

На корпоративных тренингах по вайб-кодингу один из первых скептических аргументов звучит предсказуемо: «окей, лендинг — понятно, но production-ML так не строят». Рекомендательная система требует ML-пайплайна, feature store, async-обработки событий, observability. Тренировочная сессия отвечает на этот аргумент прямо — готовым кодом.

Методика

Next-best-offer сервис: персонализированные предложения в реальном времени для роста конверсии и LTV. Задача тренировочной сессии — построить его вайб-кодингом от архитектуры до работающих контейнеров. Bottleneck на сессии не скорость набора кода, а правильное архитектурное решение: что строить и в каком порядке.

Проект спроектирован по методике SDD (Spec-Driven Development) через GitHub Spec Kit. Спека — источник истины, код — её выход; приёмы цепочки specify → clarify → plan → tasks — в разборе #12.

1. specify фиксирует что строить и зачем, без деталей реализации
2. clarify агент расставляет в спеке маркеры [NEEDS CLARIFICATION] — вынуждает явно назвать неопределённости вместо того чтобы молча делать допущения
3. plan технический план: каждое архитектурное решение сопровождается задокументированным обоснованием — не «решили так», а «вот почему именно так»
4. tasks разбивка плана на задачи, упорядоченные по зависимостям; параллелизуемые — выделены явно
5. analyze непрерывная валидация: ищет противоречия и пробелы между спекой, планом и задачами — не одноразовый gate, а петля уточнения
6. implement агент реализует задачи одну за другой, коммитит и тестирует

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

1. 1. API-слой: FastAPI — эндпоинты на данные клиента, события, NBO-рекомендации.
2. 2. Async-обработка: Celery-воркеры считают события и рекомендации асинхронно, не синхронным вычислением в запросе.
3. 3. ML-пайплайн: dual-model — ALS (коллаборативная фильтрация) + LightGBM (градиентный бустинг); обучение и деплой моделей.
4. 4. Feature store: Feast централизует фичи — консистентность между обучением и инференсом (нет train/serve skew).
5. 5. Real-time + batch hybrid: мгновенные ответы API + плановое переобучение.
6. 6. Observable by default: Prometheus-метрики, Jaeger-трейсинг, структурные логи; Docker Compose с health-checks.

Карта зависимостей и точки каскадного отказа:

events ──▶ Celery worker ──▶ Feast (feature store)
                                   │
HTTP /nbo ──▶ FastAPI ──▶ модель (ALS + LightGBM) ◀─┘
                              ▲
              batch retrain ──┘   (отдельный плановый пайплайн)

Отказ Feast / Redis / PG ──▶ каскад на /nbo
Тихий отказ batch retrain ──▶ model staleness (сервис жив, модель мертва)

Главная ловушка видна именно на схеме: сервис /nbo остаётся «зелёным», когда умер batch-пайплайн — поэтому алерт нужен на свежесть модели, не только на доступность API.

Артефакт

github.com/dobryakov/next-best-0ffer (Python) — результат тренировочной сессии. Контейнеризовано, каждый компонент (API, воркеры, ML-пайплайн) изолирован. Репозиторий включает SDD-спеки и план задач — используется как учебный материал на последующих сессиях.

Для кого и почему

Если вы проводите или планируете корпоративное обучение по вайб-кодингу — здесь учебный проект, который отвечает на скептицизм «это не для серьёзных систем» конкретным работающим кодом. Полный MLOps-стек с честным разбором, где он ломается: участники видят и результат, и его ограничения.