# Дизайн ML-систем на собеседовании

> Дизайн ML-систем на интервью: от метрики продукта до данных, модели, сервиса и мониторинга — каркас ответа без лишней теории.

Раздел: [Продакшн и качество](https://ml-book.com/s/production/) · Страница темы: https://ml-book.com/t/ml-system-design/ · Обновлено: 2026-09-16 · Источник: ml-book.com, учебник делается сообществом

## Интуиция

ML system design (дизайн ML-систем) — это разговор на 40–60 минут по открытой задаче: рекомендации, антифрод, поиск, модерация контента. Интервьюер смотрит, как ты думаешь: задаёшь ли вопросы, привязываешь ли метрики к деньгам, помнишь ли про данные и продакшн. Главная ошибка кандидатов — прыгнуть в «возьмём трансформер» на первой минуте, пропустив вопросы «а что мы вообще оптимизируем и какой ценой?».

## Как это работает: фреймворк из 8 шагов

1. **Продуктовая цель и ограничения.** Что за продукт, кто пользователь, какова цена ошибок: ложное срабатывание (FP) против пропуска (FN)? Какие латентность, масштаб, бюджет? Во фроде FP — заблокированный честный клиент, FN — украденные деньги; баланс определяет всю систему.
2. **Метрики.** Онлайн (бизнес): выручка, retention, доля пойманного фрода. Оффлайн (ML): AUC, recall, nDCG. Обязательно проговори *связь*: «оптимизируем PR-AUC, потому что классы несбалансированы, и верим, что рост precision снизит потери от блокировок».
3. **Данные и разметка.** Откуда берём: логи, ручная разметка, слабая разметка? Здесь же — дисбаланс классов и утечки (leakage): признак, недоступный в момент предсказания, даст сказочные оффлайн-метрики и провал в проде.
4. **Бейзлайн — сначала!** Правила, логистическая регрессия, «рекомендуем популярное». Бейзлайн проверяет пайплайн данных, даёт точку отсчёта и нередко закрывает задачу.
5. **Фичи и модель по нарастающей.** От простого к сложному, каждое усложнение оправдано метрикой: логрег → [градиентный бустинг](https://ml-book.com/t/trees-ensembles/) → нейросети.
6. **Обучение и валидация.** Для временных данных — сплит по времени: трейн на прошлом, тест на будущем. Random split перемешает будущее с прошлым — утечка и завышенные метрики.
7. **Деплой и сервинг.** Батч (пересчитать рекомендации ночью) или реалтайм (фрод-скоринг за 50 мс)? Кэши для тяжёлых фичей, фолбэк на правила или популярное, если модель недоступна.
8. **Мониторинг и переобучение.** Дрифт входных данных, распределение предсказаний, деградация онлайн-метрик; расписание и триггеры переобучения.

> **💡 Ключевая мысль**
>
> Порядок шагов — это и есть ответ: цель → метрики → данные → бейзлайн → модель → валидация → деплой → мониторинг. Модель — лишь пятый шаг из восьми, и интервьюер это знает.

> 🎛 Интерактивная визуализация — на странице темы: https://ml-book.com/t/ml-system-design/

## Типичные задачи и их акценты

Задач на таких интервью немного, и у каждой — свой центр тяжести. **Рекомендации:** двухэтапная схема «отбор кандидатов → ранжирование», холодный старт новых пользователей, метрики nDCG и CTR. **Антифрод:** жёсткий реалтайм, экстремальный дисбаланс классов, адаптирующийся противник — модель устаревает быстро. **Поиск:** recall на первом этапе против precision на реранжировании, оценка релевантности по кликам с поправкой на позиционное смещение. **Модерация контента:** цена пропуска токсичного контента против цены ложного бана, обязательный контур человека-ревьюера для спорных случаев. Полезный ход на интервью — явно назвать, к какому классу относится задача, и переиспользовать известные паттерны.

## Красные флаги для интервьюера

Эти фразы мгновенно понижают оценку — проверь, что не говоришь их сам:

- **«Возьмём нейросеть» без бейзлайна** — непонятно, зачем сложность и с чем сравнивать результат.
- **Метрика не привязана к продукту** — «будем максимизировать accuracy» во фроде с 0.1% положительного класса: константный ответ «не фрод» даст 99.9%.
- **Random split временных данных** — модель «подглядела» будущее; в проде метрики рухнут.
- **Нет плана на отказ** — что показывает лента, если сервис ранжирования упал? Ответ «ничего» не принимается: нужен фолбэк.

> **⚠️ Подводный камень**
>
> Утечка данных (data leakage) — самый коварный враг: признак вроде «число звонков в поддержку за неделю» отлично «предсказывает» отток, потому что записан *после* ухода клиента. Оффлайн-метрики сказочные, продакшн — провал. На интервью прямо проговаривай: «проверяю, что каждый признак доступен на момент предсказания».

> **🎤 На собеседовании**
>
> - «Спроектируйте антифрод» — начни с цены ошибок FP/FN и требования к латентности (реалтайм!), затем по фреймворку; метрика — precision/recall или PR-AUC, не accuracy.
> - «Как валидировать модель оттока?» — сплит по времени: учимся на январе–июне, проверяем на июле; random split даст утечку.
> - «Модель готова, что дальше?» — теневой запуск (shadow mode), [A/B-тест](https://ml-book.com/t/ab-testing/) на онлайн-метриках, мониторинг дрифта, план переобучения.
> - «Почему сначала бейзлайн?» — точка отсчёта, проверка пайплайна данных и честный ответ на вопрос «а нужен ли здесь ML вообще».

## Связанные темы

- [Мониторинг и дрифт данных](https://ml-book.com/t/monitoring-drift/)
- [Инференс: KV-cache, квантизация, спекулятивный декодинг](https://ml-book.com/t/inference/)
- [Fine-tuning: SFT, LoRA, PEFT](https://ml-book.com/t/finetuning/)
- [Метрики качества](https://ml-book.com/t/metrics/)

---

Интерактив, тест из 12 вопросов и карточки терминов — на странице темы: https://ml-book.com/t/ml-system-design/
Весь учебник в markdown: https://ml-book.com/llms-full.txt · Оглавление для агентов: https://ml-book.com/llms.txt