Yelp 21 июля 2026 года рассказал о запуске внутреннего фреймворка Training Orchestrator, который свёл обучение ML-моделей к единому сценарию вместо набора разрозненных Spark-скриптов в командах. Для тех, кто строит ML-платформы, новость знакомая и неприятно жизненная: когда каждая команда пишет свою оркестрацию, скорость разработки падает, а воспроизводимость результатов превращается в квест.
По данным InfoQ, новый слой оркестрации в Yelp построен вокруг конфигураций на Pydantic и DAG-модели исполнения. Проще говоря, компания отделила описание пайплайна от среды, где он выполняется. Раньше обучение ML-моделей у Yelp было жёстко привязано к Spark-кластерам и механике запуска джобов, из-за чего даже маленькая правка в коде требовала отправки полной задачи в кластер и ожидания, пока поднимутся контейнеры и инфраструктура. Только после этого разработчик узнавал, что что-то сломалось.
Именно эта связка «логика плюс инфраструктура» и стала главной болью. У разных applied ML-команд накапливались свои скрипты, свои проверки, свои уведомления и свой способ логировать эксперименты. В результате появлялись дублирующийся код, разъехавшиеся конфиги и хрупкий самописный мониторинг. Проверки валидности были размазаны по скриптам, прошлые запуски было трудно воспроизвести в другой среде, а часть параметров или происхождение конкретного результата могли просто потеряться. Для бизнеса это выглядит как обычный техдолг, но для платформенной команды это уже налог на каждую новую модель.
Training Orchestrator пытается этот налог централизовать. Пайплайны теперь описываются декларативно: есть конфиг самого оркестратора, конфиг запуска MLflow и конфиги отдельных шагов. Все они валидируются при создании, ещё до того как будет потрачено хоть сколько-то вычислительных ресурсов. Дальше система строит ориентированный ациклический граф по зависимостям между шагами и запускает их в топологическом порядке. На практике это означает, что команда заранее знает, какие входы и выходы ожидает каждый шаг, а несоответствия между ними ловятся за секунды, а не через несколько часов внутри Spark-задачи.
Важная деталь в том, что Yelp привязал каждый шаг не просто к куску кода, а к паре «класс настроек плюс пользовательская функция» с явной схемой входов и выходов. Условный шаг подготовки данных принимает один тип датасета и возвращает другой, уже подготовленный. Такой контракт звучит скучно ровно до тех пор, пока не приходится параллельно поддерживать несколько версий модели, менять препроцессинг или переиспользовать куски пайплайна в соседних командах. Тогда оказывается, что формализованный шаг экономит недели споров о том, что именно “должно было приехать на вход”.
Для разработчиков здесь, пожалуй, самый интересный бонус не в DAG как таковом, а в локальном цикле разработки. Yelp подчёркивает, что одинаковые определения шагов можно запускать без изменений локально, в Jupyter и в продакшене, потому что оркестратор подмешивает общий контекст Spark и MLflow отдельно от бизнес-логики шага. Это снимает старую проблему, когда тестировать пайплайн можно было только через реальный кластер. Теперь команды могут прогонять полный сценарий локально на сэмплах данных, писать unit-тесты на отдельные шаги и ускорять интеграционные тесты за счёт кэширования входных данных для data-loading шагов. Для любой ML-команды, у которой один неудачный эксперимент съедает полдня, это звучит не как архитектурная косметика, а как реальная экономия времени.
Не новый тренд, а взросление ML-платформ
Yelp в этой истории не выглядит одиночкой. Скорее наоборот: компания пришла к тому же выводу, к которому крупные инженерные организации подходят уже несколько лет. Когда моделей становится много, а команд, которые их тренируют, ещё больше, самодельная оркестрация перестаёт быть свободой и становится бутылочным горлышком. InfoQ в качестве параллелей напоминает про Netflix и Metaflow, где недавно добавили отдельный объект конфигурации для более прозрачного управления поведением пайплайнов, и про платформу Michelangelo в Uber, которая в своё время как раз и строилась для борьбы с фрагментацией инструментов и разрывом между прототипом и продакшеном.
Общий вывод у всех похожий: централизация инфраструктуры для обучения ML-моделей требует заметных вложений в начале, зато потом возвращает их через предсказуемость, тестируемость и более быстрый цикл разработки. В Yelp это называют переносом издержек в одно место: вместо того чтобы каждая команда заново платила за свои обвязки, валидацию, уведомления и трекинг, эти функции становятся общей платформенной услугой. Такой подход особенно хорошо считывается в деталях. Например, логирование полной конфигурации каждого запуска в MLflow артефакты происходит автоматически, а Slack-уведомления и трекинг запусков, которые раньше команды делали вручную, теперь включаются буквально несколькими параметрами.
При этом Yelp не обещает магии и не скрывает цену перехода. Чтобы схема заработала, пришлось инвестировать в дизайн типов шагов и схем конфигурации, а старые скрипты мигрировать в новый контракт «настройки плюс функция». Это не тот случай, когда можно за выходные обернуть хаотичный набор ноутбуков и cron-задач в красивую платформу. Зато инженерная логика здесь понятная: если компания заранее знает, что десятки ML-пайплайнов будут жить годами, дешевле один раз навести дисциплину на уровне платформы, чем бесконечно чинить локальные исключения.
Что это значит для команд за пределами Yelp
Для русскоязычной аудитории здесь важен не сам бренд Yelp, а шаблон решения. В описании нет ничего, что было бы намертво привязано только к стеку этой компании, кроме конкретной интеграции со Spark и внутренней ML-платформой. Ключевая идея универсальна: обучение ML-моделей должно описываться декларативно, с валидируемыми конфигами, явными входами и выходами шагов и возможностью запускать один и тот же пайплайн в разных средах без переписывания кода. Если ваша команда всё ещё проверяет корректность конфигурации через падение джобы на продовом кластере, Yelp фактически показывает, где именно уходит время инженеров.
Особенно это актуально для компаний, где ML-платформа выросла не из одного большого проекта, а из десятка маленьких. Там почти всегда появляются одни и те же симптомы: у каждой команды свой способ запускать обучение, свои YAML или Python-скрипты, свои уведомления, свои практики логирования и своё понимание “воспроизводимости”. Пока моделей мало, всё терпимо. Когда появляется несколько продуктовых направлений и параллельные эксперименты, платформа начинает тормозить не из-за нехватки GPU, а из-за организационной энтропии. Yelp, по сути, оформил эту энтропию в конкретный технический долг и показал, как его можно разбирать системно.
Следующий шаг у компании тоже показателен: Yelp собирается добавить в оркестратор явные шаги для оценки, сравнения и объяснимости моделей, а также lineage на уровне оркестрации. Это хороший маркер того, куда вообще движется зрелый MLOps. Платформа перестаёт быть просто “способом запускать обучение” и превращается в слой, который задаёт стандарты качества эксперимента. Вопрос теперь не в том, нужен ли такой слой крупным ML-командам, а в том, на каком этапе компании признают очевидное: разрозненные скрипты отлично подходят для старта, но почти всегда слишком дорогие для масштабирования.