Машинное обучение в e-commerce давно перестало быть экспериментом — сегодня это неотъемлемая часть бизнес-инфраструктуры. По оценкам McKinsey, до 35% выручки онлайн-ритейлеров может напрямую зависеть от качества рекомендательных и поисковых систем, а реальное время обработки запросов стало ключевым фактором пользовательского опыта. От работы ML-алгоритмов зависит, что именно увидит пользователь, сколько он купит и насколько быстро завершит заказ.
Но в условиях, когда платформа обрабатывает миллионы действий в секунду, главная задача ML-инженеров — не просто «сделать модель», а построить надёжную, масштабируемую и устойчивую систему. Такую, которая выдерживает пиковые нагрузки, не падает в критические моменты и позволяет внедрять новые версии моделей без простоев и потери качества. Без этого невозможно говорить о зрелой AI-инфраструктуре, особенно в масштабах крупных маркетплейсов или финтех-продуктов.
В интервью с Артёмом Бочкарёвым, Director of Machine Learning в AliExpress, под руководством которого были построены системы поиска, рекомендаций и модерации, работающие на масштабе миллиардов товаров, мы обсуждаем, как проектировать отказоустойчивые ML-системы, которые действительно работают в продакшене на масштабе.
1. Почему стандартные ML-решения не масштабируются под реальные бизнес-нагрузки?
На первый взгляд может показаться, что если модель показывает хорошие результаты на тестовых данных, то она так же успешно будет работать и в продакшене. Однако в реальности всё сложнее.
Проблема многих ML-решений в том, что они изначально создаются как «модель в вакууме». Её обучают, проверяют метрики качества — и предполагают, что в продакшене она будет работать так же. Но в реальном бизнесе модель — лишь часть большой онлайн-системы. Здесь важны не только точность, но и скорость ответа, стабильность сервиса, стоимость вычислений и предсказуемое поведение при пиковых нагрузках. Именно на этих этапах часто ломаются решения, которые выглядели хорошо на этапе экспериментов. Об этом писали инженеры Google в Hidden Technical Debt in Machine Learning Systems: основная сложность production-ML обычно не в самой модели, а в связях между данными, фичами, сервисами и процессами выкладки.
Есть и другая проблема — разрыв между offline-метриками и тем, что происходит в реальности. Модель может показывать красивый рост качества на тестовых данных, но проигрывать в онлайне из-за слишком сложного ранжирования, нестабильных признаков или высокой стоимости вычислений. Иногда всё упирается даже в пользовательский опыт: если система отвечает медленно, пользователь просто не дождётся результата.
Поэтому зрелые ML-системы проектируются иначе. Например, из технических материалов Airbnb о работе их поисковых и рекомендательных систем видно, что архитектура строится каскадом: сначала быстрый этап отбора кандидатов, затем более сложные модели применяются только к ограниченному набору результатов. Такой подход позволяет сохранить баланс между качеством ранжирования, скоростью ответа и стоимостью вычислений — и именно он обычно отличает экспериментальную модель от системы, готовой к реальному масштабу.
2. Какие типичные ошибки совершают команды при проектировании продакшен-систем с ML внутри?
Первая — это когда команды спешат проектировать продакшен, не завершив стадию экспериментов и тестирования модели. Иногда сначала выстраивается архитектура, проектируются сервисы, но в итоге оказывается, что планируемая модель не показывает нужной точности, и значительную часть системы приходится переделывать. Поэтому мой совет — не начинать строить продакшен до того, как модель будет достаточно протестирована, по крайней мере в тех частях системы, которые напрямую от неё зависят. Если посмотреть на истории развития ML-систем в разных компаниях, можно заметить, что архитектура обычно эволюционирует постепенно — от более простых решений к более сложным.
Другая распространённая ошибка — выкатывать модель в продакшен без мониторинга качества, отслеживания её устаревания и без пайплайнов переобучения. Это опасно по двум причинам. Во-первых, можно просто не заметить, как модель в продакшене начинает «деградировать» из-за изменений данных или поведения пользователей. Во-вторых, даже если инженеры это заметят, часто нет чёткого процесса замены модели: как обучить новую версию, как протестировать её и безопасно выкатить.
В результате получается не живая продакшен-система, а скорее одноразовое решение, которое при любой проблеме требует значительных ресурсов для восстановления. Поэтому важно следить не только за аптаймом сервиса, но и за качеством самой модели — например, отслеживать skew и drift между train- и serving-данными, что в свою очередь должно запускать процесс переобучения. Платформенные решения вроде Vertex AI Model Monitoring или инструментов мониторинга в BigQuery ML как раз построены вокруг этой идеи. Если система создаётся in-house, про эти механизмы тоже важно подумать заранее.
3. Что такое отказоустойчивость в контексте ML — и как она достигается?
Когда мы говорим про отказоустойчивость, речь может идти либо про обычную инженерную составляющую — время ответа сервиса, отсутствие ошибок и стабильность работы, — либо про ML-компонент системы.
ML-отказоустойчивость — это гарантия того, что предсказания модели остаются валидными и ожидаемыми. Если с обычной отказоустойчивостью всё более-менее понятно — можно выделить больше ресурсов, мониторить стандартные метрики сервисов и следить за их состоянием, — то в случае с ML всё сложнее.
Для каждой конкретной задачи важно определить диапазоны корректных ответов модели и мониторить их. Также сильно помогает мониторинг признаков, которые поступают на вход модели: на практике ошибки часто возникают именно там, а не на этапе предсказания.
Общий совет — чем больше сценариев, в которых модель может отвечать некорректно, вы сможете заранее предусмотреть и покрыть проверками, тем устойчивее будет система.
4. Как выглядит архитектура системы, которая выдерживает миллионы запросов в секунду?
Из своего опыта я могу уверенно говорить про системы на десятках тысяч запросов в секунду; масштабы в миллионы — это уже уровень крупнейших глобальных платформ. Но сами архитектурные принципы там те же, просто требования к дисциплине исполнения становятся гораздо жестче.
У зрелых платформ ML почти никогда не используется как одна тяжелая модель на каждый запрос. Обычно это многоступенчатая система: сначала быстрый этап retrieval или rules-based filtering, затем более точный ranker, после чего применяются дополнительные бизнес-ограничения и постобработка. Такой каскад позволяет использовать дорогие вычисления только там, где это действительно необходимо. Похожую каскадную архитектуру, как упоминалось ранее, описывала команда Airbnb в статье о работе их поисковой системы.
Ключевая функция масштабируемой системы — плавная деградация (graceful degradation). Когда нагрузка растёт и система рискует не уложиться в SLA, она не должна полностью падать. Она должна уметь переключаться на более простые и быстрые сценарии: например, отключать часть тяжёлых фичей, использовать более простой ranker, уменьшать глубину rerank или переходить на предвычисленные рекомендации и кэшированные результаты.
Это классический подход из SRE-практик: лучше показать пользователю немного менее оптимальный результат, чем получить таймаут и не ответить вовсе.
5. Что важнее в real-time ML — скорость или точность?
Обычно, если мы говорим о системах, которые видят и с которыми взаимодействуют живые пользователи, то скорость выходит на первый план. Например, в случае поиска или рекомендаций намного лучше показать пользователю не самую оптимальную выдачу быстро, чем заставить его ждать 1–2 секунды до прогрузки результатов. Пользователь не видит ROC-AUC и offline uplift — он видит, насколько быстро система отреагировала.
Это не означает, что точность не важна, но в реальных системах всегда приходится искать баланс. Если модель слишком тяжёлая и не укладывается в допустимое время ответа, её приходится упрощать или менять архитектуру системы так, чтобы сохранить приемлемую скорость работы. В конечном итоге задача — сделать систему, которая одновременно даёт достаточно качественный результат и остаётся быстрой для пользователя.
6. Как организованы пайплайны, которые позволяют переобучать модели без простоев?
В нормальной архитектуре простой при обучении модели вообще не должен происходить: обучение, валидация и выкладка новой версии должны быть отделены от контура онлайн-обслуживания. Пока одна версия модели обслуживает трафик, другая обучается и проходит проверки.
Поэтому зрелые ML-платформы строят end-to-end workflow: подготовка фичей, обучение, оценка, регистрация модели, деплой и мониторинг как единая цепочка. Такой подход позволяет безопасно обновлять модели без остановки системы. Похожую архитектуру, например, описывала команда Uber в материалах о платформе Michelangelo.
7. Как мониторятся ML-системы в реальном времени и что делать, если что-то пошло не так?
Если взять в качестве примера поиск, одна из ключевых метрик — доля запросов с нулевой выдачей. Обычно она достаточно стабильна, и если начинает резко меняться, это почти всегда сигнал о проблеме.
Также часто выделяют набор контрольных запросов и следят за результатами по ним в реальном времени. Например, если без выкладки новой модели или обновления фичей начинает заметно меняться выдача по запросу «айфон», это повод проверить систему.
Дополнительно смотрят на пользовательские метрики — клики и переходы по результатам поиска. Но такие показатели сильнее зависят от качества аналитики и обычно лучше подходят для оценки на горизонте нескольких дней или недель, а не для мгновенной диагностики.
Если проблема обнаружена и причина понятна, чаще всего правильное решение — быстро откатиться на предыдущую стабильную версию или включить fallback-режим. Если причина неочевидна, её локализуют дежурные инженеры. В случае drift-сценариев обычно проверяют данные, анализируют природу сдвига, переобучают модель или временно переходят на более простой fallback.
8. Какие уроки можно применить другим компаниям — даже если они не на масштабе маркетплейса?
Главный принцип — не усложнять. Важно чётко понимать бизнес-задачу, которую вы пытаетесь решить, и по возможности начинать с самой простой модели и архитектуры, способной дать нужную точность.
Такую систему легче поддерживать и развивать. При необходимости всегда можно перейти к более сложной модели, а вот обратный путь — от сложной системы к простой — обычно оказывается гораздо сложнее.