ML System Design

Google's famous paper 'Hidden Technical Debt in Machine Learning Systems' showed that ML code is only a tiny fraction of a real-world ML system. The rest is data collection, feature extraction, configuration, monitoring, and infrastructure. Knowing how to design the whole system separates ML engineers from ML researchers.

• **Рекомендации Netflix** - ML System Design масштаба миллиардов: data pipeline обрабатывает миллиарды событий просмотра, feature store хранит сотни features на каждого юзера, cascade из десятков моделей (candidate generation, ranking, re-ranking) работает за < 200ms, A/B тесты идут непрерывно, а модели ретрейнятся ежедневно
• **Uber Michelangelo** - внутренняя ML-платформа, покрывающая весь цикл: от feature engineering до мониторинга в production. Позволила масштабировать ML с десятков до тысяч моделей (предсказание ETA, dynamic pricing, fraud detection) с единой инфраструктурой вместо отдельных pipeline для каждой задачи
• **Tesla Autopilot** - edge ML System Design: модели компьютерного зрения обучаются на петабайтах видео в облачном кластере, проходят distillation и quantization, деплоятся на чипы в автомобилях, а feedback loop собирает новые данные с миллионов машин для следующей итерации модели

Предварительные знания

• Distributed Training

Как проектирование ML-систем стало отдельной дисциплиной

Проектирование системы машинного обучения это куда больше, чем выбор модели. Это работа с конвейерами данных, хранилищами признаков, инфраструктурой обучения и сервинга, мониторингом и петлями обратной связи, которые их связывают. Долгие годы это знание жило только в индустриальном опыте и разрозненных инженерных блогах. Google помог формализовать часть этого через внутренние рубрики проектирования и широко читаемые статьи о техническом долге в ML-системах, где утверждалось, что модель это маленький блок в куда большей системе из связующего кода, зависимостей данных и конфигурации. Дисциплина оформилась для широкой аудитории в 2022 году, когда Чип Хьюен опубликовала Designing Machine Learning Systems, книгу, изложившую сквозной фреймворк: бизнес-требования, инженерия данных, инженерия признаков, разработка модели, развёртывание, мониторинг и непрерывное обучение. Проектирование ML-систем также стало стандартным форматом собеседований в крупных техкомпаниях, где кандидата просят спроектировать что-то вроде ленты рекомендаций или детектора мошенничества в реалистичных ограничениях, рассуждая о масштабе, задержках и компромиссах, а не только об алгоритмах.

Формулировка задачи

Первый и самый важный шаг в ML System Design - перевод бизнес-задачи на язык машинного обучения. Бизнес говорит: "хотим увеличить конверсию на 20%". ML-инженер должен превратить это в конкретную задачу: что предсказываем (target), какие данные на входе (features), как измеряем успех (metrics). Ошибка на этом этапе стоит дороже всего - можно идеально обучить модель, которая решает не ту задачу.

**Бизнес-метрики vs ML-метрики:** Бизнес измеряет успех в деньгах, конверсиях, retention. ML - в accuracy, AUC, RMSE. Между ними нет прямой связи: - Модель с AUC 0.95 может не улучшить конверсию, если пользователи не видят рекомендации - Модель с AUC 0.80 может дать огромный прирост, если решает правильную задачу **Proxy-метрики** - мост между мирами: - Бизнес: "увеличить выручку" -> Proxy: CTR (click-through rate) -> ML: AUC для предсказания клика - Бизнес: "уменьшить отток" -> Proxy: retention 30d -> ML: precision@k для top-k рисковых юзеров

Перед тем как строить ML-модель, нужно установить **baseline** - простейшее решение для сравнения. Это может быть правило ("показывать самые популярные товары"), статистика ("среднее значение за последний месяц") или простая модель (logistic regression). Baseline отвечает на главный вопрос: **нужен ли вообще ML?** Если правило "показывать топ-10 по продажам" дает 90% от целевой метрики, сложная ML-система может не окупиться.

**Формулировка задачи - это итеративный процесс.** На старте задача может казаться classification ("юзер купит или нет"), а после анализа данных оказаться ranking ("в каком порядке показать товары") - и второе даёт больший бизнес-импакт. Правильная формулировка часто приходит после 2-3 итераций, и это нормальная часть ML System Design.

Data Pipeline

Data pipeline - это вся инфраструктура от сбора сырых данных до готовых features, которые попадают в модель. По оценкам Google, **инженеры тратят 80% времени на работу с данными** и только 20% на саму модель. Pipeline должен быть надежным, воспроизводимым и масштабируемым - потому что качество данных определяет потолок качества модели.

**ETL vs ELT:** - **ETL** (Extract-Transform-Load): данные трансформируются ДО загрузки в хранилище. Классический подход, когда storage дорогой. - **ELT** (Extract-Load-Transform): данные загружаются сырыми, трансформируются внутри хранилища. Современный подход (BigQuery, Snowflake): storage дешевый, compute производительный. Для ML чаще используется ELT: - Сырые данные сохраняются - можно пересчитать features - Новые features не требуют перестройки pipeline - Воспроизводимость: всегда можно вернуться к исходным данным

**Data quality checks** - критическая часть pipeline, которую часто недооценивают. Модель, обученная на грязных данных, будет давать грязные предсказания (garbage in - garbage out). Типичные проблемы: дубликаты, пропущенные значения, сдвиг распределений (data drift), некорректные labels. Автоматические проверки должны запускаться при каждом обновлении данных и **блокировать pipeline** при обнаружении аномалий.

Хорошо спроектированный data pipeline - это **воспроизводимый** (одни входные данные всегда дают одни features), **версионированный** (можно откатить features к любому моменту), **мониторируемый** (алерты на аномалии) и **масштабируемый** (обрабатывает рост данных без переписывания). В production-системах data pipeline обычно сложнее самой модели.

Выбор модели

Правило номер один в выборе модели: **начинай с простого**. Logistic regression или gradient boosting решают большинство задач на табличных данных. Сложная модель оправдана только когда простая уже работает и есть количественное понимание, сколько процентов метрики она не добирает. Компании вроде Google и Meta подтверждают: зачастую простая модель с хорошими features побеждает сложную модель с плохими features.

**Constraints определяют выбор модели:** - **Latency < 10ms** -> Logistic Regression, маленький LightGBM, ONNX-модели - **Latency < 100ms** -> Gradient Boosting, небольшие нейросети - **Latency < 1s** -> Transformer, сложные ensemble - **Batch (без ограничений)** -> любая модель, включая тяжелые ensemble **Память:** - Мобильное устройство (< 50 MB) -> TFLite, CoreML, quantized модели - Серверная GPU (16 GB) -> полноразмерные нейросети - Кластер GPU -> LLM, огромные модели Не выбирайте модель, которая не впишется в production-constraints.

**Ensemble vs single model** - вечный компромисс. Stacking (комбинация нескольких моделей) почти всегда дает лучшие метрики на Kaggle, но в production создает проблемы: сложнее деплоить, отлаживать, мониторить, больше latency. Netflix Prize показал это наглядно: winning ensemble из 107 моделей так и не был внедрен в production из-за сложности. В реальных системах одна хорошо настроенная модель часто выигрывает у ensemble по совокупности факторов.

Важный принцип: **модель - это не финальный продукт, а компонент системы**. Самая частая ошибка junior ML-инженеров - тратить недели на улучшение AUC с 0.93 до 0.94, когда рядом лежат features, способные поднять AUC с 0.93 до 0.97. Время, потраченное на feature engineering, почти всегда окупается лучше, чем время на подбор архитектуры.

Масштабирование

Модель, работающая на ноутбуке, и модель, обслуживающая миллионы запросов - это разные инженерные задачи. Масштабирование ML-системы включает не только inference, но и обучение, data pipeline и feature computation. Ключевой вопрос: **как обслужить X запросов в секунду с latency < Y ms при бюджете Z?**

**Caching предсказаний - самый дешевый способ масштабирования:** Если 30% запросов повторяются (один и тот же юзер, те же features), кеширование предсказаний снижает нагрузку на модель на 30% без потери качества. - **Exact cache** (Redis): ключ = hash(features), значение = prediction. Работает для повторяющихся запросов - **Precompute** (batch): рассчитать предсказания для всех юзеров заранее, сохранить в key-value store. Работает для рекомендаций, ранжирования - **Approximate cache**: похожие features -> похожие предсказания. Locality-sensitive hashing для поиска ближайших Precompute - основа систем рекомендаций: Netflix заранее рассчитывает рекомендации для каждого юзера batch-процессом.

**Edge deployment** - запуск модели на устройстве пользователя (мобильный телефон, IoT, браузер). Преимущества: нулевая latency сети, работа без интернета, приватность данных. Ограничения: маленькая память, слабый процессор, батарея. Для edge нужны специальные форматы: TensorFlow Lite (мобильные), ONNX Runtime (универсальный), CoreML (Apple), TensorRT (NVIDIA). Модель обязательно проходит compression (quantization + pruning + distillation).

Масштабирование ML-системы - это **экономическая задача**. Цель не максимальная производительность, а оптимальное соотношение качество/стоимость. Cascade-архитектура (простая модель отвечает на простые запросы, сложная - на сложные) часто дает 80% качества тяжелой модели при 20% ее стоимости. В production это означает экономию тысяч долларов в месяц.

Мониторинг и итерации

Деплой модели - это не финиш, а начало. В отличие от обычного софта, ML-модели **деградируют со временем**: мир меняется, распределение данных сдвигается, пользователи меняют поведение. Рекомендательная система, обученная до пандемии, после нее работает совсем иначе. Мониторинг ML-системы - это непрерывный процесс отслеживания качества модели и данных с автоматическими алертами при деградации.

**A/B тестирование ML-моделей:** A/B тест - единственный надежный способ оценить влияние новой модели на бизнес-метрики: - **Control (A):** текущая модель (например, v2.3) - **Treatment (B):** новая модель (v2.4) - **Трафик:** 95% / 5% -> 90% / 10% -> 50% / 50% (постепенный rollout) - **Метрики:** и бизнес (конверсия, revenue), и ML (AUC, latency) - **Длительность:** минимум 1-2 недели (учесть day-of-week эффект) **Feedback loops** - коварная проблема: Модель влияет на данные, которые потом используются для ретрейна. Пример: рекомендательная система показывает популярное -> популярное становится еще популярнее -> модель учится рекомендовать еще больше популярного. Это **положительная обратная связь**, которая убивает разнообразие. Решение: exploration (показывать случайные items небольшой доле юзеров).

**Model refresh strategy** - когда и как переобучать модель. Три подхода: 1. **По расписанию** - самый простой: ретрейн каждые N дней. Работает, если drift предсказуем. 2. **По триггеру** - ретрейн запускается автоматически, когда мониторинг обнаруживает деградацию. Эффективнее, но сложнее. 3. **Online learning** - модель обновляется на каждом новом примере. Максимально адаптивно, но сложно отлаживать и может быть нестабильно.

ML System Design - это **инженерная дисциплина**, а не только data science. Успешная ML-система требует экспертизы в распределенных системах, data engineering, DevOps, и понимания бизнеса. Поэтому статья Google показала, что ML-код - это лишь маленький фрагмент реальной production-системы. Остальные 95% - данные, инфраструктура, мониторинг и процессы.

Итоги

• **Формулировка задачи** определяет успех всего проекта: перевод бизнес-метрик в ML-метрики через proxy, baseline для оценки ROI от ML, и feasibility analysis перед стартом - ошибка здесь стоит дороже всего
• **Data Pipeline** - 80% работы ML-инженера: ETL/ELT, Feature Store с online/offline features, автоматические data quality checks на каждом обновлении - качество данных определяет потолок качества модели
• **Выбор модели** по принципу 'от простого к сложному': logistic regression -> gradient boosting -> deep learning, с учетом constraints (latency, память, стоимость) - feature engineering почти всегда окупается лучше, чем усложнение модели
• **Масштабирование** через cascade (простая модель для простых запросов), model compression (distillation, quantization, pruning), caching и auto-scaling - цель не максимум производительности, а оптимум качества/стоимости
• **Мониторинг** замыкает цикл: data drift, prediction drift, A/B тестирование, feedback loops, model refresh strategy - потому что, как показала статья Google из нашего hook'а, ML-код - лишь 5% системы, а оставшиеся 95% определяют, выживет ли модель в production

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

ML System Design объединяет знания из всего курса, от базовых алгоритмов до production-инфраструктуры:

• MLOps Pipeline — Фундамент ML System Design: CI/CD для моделей, автоматизация обучения, версионирование данных и моделей. MLOps - инструменты, ML System Design - архитектура, в которой эти инструменты живут
• Мониторинг ML — Глубокое погружение в monitoring: data drift detection, concept drift, alerting strategies. В ML System Design мониторинг - один из пяти компонентов, а в этой теме - полный курс по его реализации
• Model Serving — Детали inference-инфраструктуры: batching, model versioning, canary deployments, load balancing. Model Serving - реализация того, что в ML System Design проектируется на уровне архитектуры
• Distributed Training — Обучение моделей на кластерах GPU: data parallelism, model parallelism, gradient accumulation. Distributed Training решает часть 'scaling' для обучения, а ML System Design добавляет inference-scaling и cost optimization

Вопросы для размышления

• Проектируется ML-система для e-commerce-рекомендаций с 50M юзеров. Какие компоненты будут самыми дорогими по времени и бюджету: модель, data pipeline, inference infrastructure или мониторинг? Как распределить ресурсы команды?
• Feedback loops могут незаметно деградировать качество рекомендаций, усиливая popularity bias. Какие механизмы стоит встроить в систему, чтобы обнаружить и компенсировать этот эффект?
• Компания хочет перейти от rule-based fraud detection к ML. Какие риски присутствуют на каждом этапе (problem framing, data, model, scaling, monitoring) и как их митигировать?

Связанные уроки

• ml-45-mlops-pipeline — Дизайн системы оркеструет MLOps-пайплайн
• ml-46-model-serving — Serving - ключевой компонент дизайна
• ml-47-model-monitoring — Мониторинг - часть дизайна
• ml-54-distributed-training — Дизайн должен масштабировать обучение
• sd-03-scalability — ML и общее масштабирование пересекаются
• sd-01-intro