Машинное обучение часто воспринимают как работу над моделью: есть данные, алгоритм, обучение и результат. В крупных компаниях основная сложность постепенно перемещается в другое место. Одни и те же данные приходится готовить для разных проектов, модели — регулярно переобучать, эксперименты — проверять, а найденные решения — переносить между командами.

На «ИТ-Пикнике» Сергей Кузнецов, руководитель разработки платформы рекомендаций и поиска MWS, показал на трех кейсах, почему в одних случаях лучше работать с полноценной ML-платформа, а в других — выгоднее остановиться на уровне библиотеки.

Когда отдельные решения становятся слишком дорогими

По мере развития ML-разработки команды постепенно накапливают собственные подходы, инструменты и удачные решения. Пока таких проектов немного, этого достаточно, но, когда похожие задачи начинают возникать в разных отделах компании, появляется необходимость объединить накопленный опыт и использовать его повторно.

В начале карьеры Сергею казалось, что руководители, заставляющие команды работать по общим правилам, только замедляют разработку. Когда его зона ответственности выросла и в личном управлении стало несколько команд, ситуация изменилась: выяснилось, что одну задачу уже решали в другом проекте, а ошибка, которую собирается допустить новая команда, где-то уже была решена.

Отсюда возникает последовательность: сначала когда команда сохраняет удачные практики, затем превращает их в библиотеку, а при росте повторяющихся задач появляется смысл строить платформу. Причем платформа — это про общую инфраструктуру, автоматизацию и единые правила работы.

На этом этапе появляется главный экономический эффект: разработчики перестают каждый раз заново решать одну и ту же инженерную задачу.

Кейс 1. Один велосипед вместо десяти

Наглядный пример — рекомендательные системы (как сейчас меняются их алгоритмы, рассказывали в предыдущем материале). Пользователь сталкивается с ними постоянно: когда открывает ленту, получает подборку фильмов или видит товары в определенном порядке. 

В MTC Web Services (MWS) в какой-то момент оказалось около десяти проектов с собственными рекомендательными системами. Вместо того чтобы поддерживать десять похожих решений, команды объединили разработки в общую платформу.

Унифицировать пришлось не только алгоритмы. Основой платформы стали данные в едином формате, аналитическое ядро для экспериментов и автоматизированный конвейер, который позволяет после загрузки данных получить готовую рекомендательную систему за несколько часов. Для более сложных случаев сохранили возможность глубокой настройки.

Важно, что хорошая платформа не должна превращать все команды в одинаковые, должно оставаться пространство для экспериментов и новых задач.

Отдельной сложность — это те решения, которые команды раньше создавали внутри собственных микросервисов. Даже если такой компонент был полезен, перенести его в другой проект было сложно. Поэтому появился оркестратор: конвейер описывается конфигурацией, а отдельные этапы становятся самостоятельными модулями. В результате другой разработчик может увидеть, как устроен чужой процесс, и использовать уже готовую часть для себя. Одновременно общие изменения, мониторинг и другие инфраструктурные функции можно внедрять централизованно.

Получается, что команда отказывается от части свободы, но получает доступ к результатам работы остальных.

Модель — только часть системы

Еще один важный вывод из опыта Сергея  — автоматизировать нужно не только обучение модели. В упрощенном виде работа выглядит как последовательность из подготовки данных, обучения модели и получения результата. На практике между этими этапами есть еще несколько процессов — генерация кандидатов, ранжирование, проверка качества, проведение экспериментов и последующий запуск модели в рабочей среде.

Поэтому в платформе автоматизируется весь конвейер. Спикер отдельно отметил что по мере взросления рекомендательного продукта базовые модели могут уходить, тогда как созданные вокруг них инструменты и интерфейсы остаются.

«В индустрии происходит постепенный переход от подходов, где ключевую роль играли вручную рассчитанные признаки, к трансформерным архитектурам, которые самостоятельно выделяют значимые закономерности в данных. Это меняет состав задач, но не отменяет потребности в инфраструктуре для экспериментов, валидации и мониторинга».

Сергей Кузнецов, руководитель разработки платформы рекомендаций и поиска MWS

Особенно хорошо это отслеживается в экспериментах. Офлайн-оценка модели не всегда улучшает продукт. В рекомендациях нельзя заранее узнать реакцию пользователя на объект, который ему раньше не показывали. Поэтому изменения проверяют через A/B-тестирование.

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

Сергей привел и другой способ оценки накопительного эффекта. В рекомендательных системах отдельные эксперименты нельзя просто сложить, поскольку изменения могут влиять друг на друга. Поэтому небольшая доля пользователей постоянно остается на максимально простой версии рекомендаций. Ее поведение становится долгосрочной точкой сравнения. Такой эксперимент позволил найти ответ на вопрос, сколько в совокупности дают рекомендации, а не отдельное улучшение.

Кейс 2. В чем еще ценность платформ

Второй кейс — скоринговые модели, например для оценки вероятности возврата кредита. Здесь сама математическая задача давно известна, а дополнительный эффект часто получается как раз от работы с данными.

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

Но наиболее интересный эффект от этого связан не с собственно автоматизацией запуска, а с тем, что со временем платформа превращается в накопитель инженерного опыта. Если какой-то признак оказался полезным в одной модели, его сразу можно проверить в другой и так в результате появляется библиотека уже проверенных решений. Сергей поделился, что со временем внутри их платформы уже накопились тысячи таких признаков.

То же относится и к графовым моделям. Иногда важно знать и характеристики самого клиента, иего связи с другими объектами. Например, для оценки риска может иметь значение не только поведение человека, но и структура его взаимодействий. Такие методы позволяют передавать в модель информацию о связанных объектах.

Кейс 3. Почему не все так просто с динамическими ценами

Третий кейс особенно важен, потому что он показывает обратную сторону платформизации. Команда МТС пыталась создать универсальную платформу динамического ценообразования для разных бизнесов. Она должна была учитывать исторические и внешние данные, цены, ограничения бизнеса, эластичность спроса и целевые показатели — например, выручку, прибыль или объем продаж.

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

В итоге платформу не стали развивать дальше и фактически остановились на уровне библиотеки. И это не провал, а просто главный риск платформизации, поскольку общая инфраструктура тоже стоит денег. Нужно создавать интерфейсы, поддерживать совместимость, документировать компоненты, автоматизировать процессы и учитывать будущие сценарии, что стоит немалых денег. Если такие сценарии возникают редко, эти инвестиции могут не окупиться — в этом главный риск платформизации.

Как понять, что пора строить платформу

По сути критерии довольно простые:  если задача уникальная в своем роде, ее проще решить локально. Когда аналогичная задача появляется в нескольких проектах, имеет смысл вынести общий компонент в библиотеку. А если весь процесс повторяется регулярно, от подготовки данных до финального результата, затраты на платформу начинают окупаться.

При этом считать нужно не количество моделей и не сложность технологий. Важнее посмотреть, сколько раз команда выполняет одну и ту же работу, сколько людей занято ее повторением и сколько ошибок возникает из-за отсутствия общих решений.

В этом смысле платформа машинного обучения — не признак зрелости компании и не обязательный этап развития любой ML-команды. Это инструмент, который должен окупать собственное существование.

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

Так что ключевой вопрос, который стоит решить в первую очередь — действительно ли повторяемость работы оправдывает создание общего инструмента?