В рамках интервью для подкаста The TWIML AI Podcast известный эксперт в области MLOps Якопо Тальябуэ (Jacopo Tagliabue) представил прагматичный взгляд на построение систем машинного обучения. Он объяснил, почему слепое копирование инженерных практик гигантов Кремниевой долины вроде Facebook или Uber наносит вред большинству ИТ-компаний, работающих в сфере B2B. На примере своего опыта руководства ИИ-департаментами спикер описал концепцию «разумного масштаба» и выделил специфические особенности работы с данными, моделями и командами в корпоративном секторе.
🎾 Метод Рафы Надаля и концепция разумного масштаба 0:02
Якопо Тальябуэ недавно завершил трехлетний этап работы в качестве директора по искусственному интеллекту в крупной канадской публичной SaaS-компании Coveo. До этого его собственный стартап Tooso, занимавшийся обработкой естественного языка (NLP) для электронной коммерции в Кремниевой долине, был поглощен Coveo. По словам эксперта, в те годы инфраструктура MLOps еще не была столь развита, как во времена Snowflake, и инженерам приходилось делать всё вручную. Накопленный опыт на разных стадиях развития бизнеса — от масштаба «гаража» до IPO — позволил Тальябуэ сформировать реалистичный манифест MLOps для компаний так называемого «разумного масштаба» (Reasonable Scale).
Как утверждает Тальябуэ, в индустрии сформировался опасный разрыв в идеях. С одной стороны, эксперты обсуждают сложнейшие планетарные инфраструктуры Uber или Pinterest, с другой — предлагают простейшие туториалы на Flask по развертыванию базовой модели scikit-learn. Однако большинство реальных компаний находятся строго посередине этого распределения. Для них академические туториалы слишком примитивны, а подходы технологических гигантов экономически нецелесообразны и технически избыточны.
Для иллюстрации своей позиции гость приводит аналогию со спортом. Наблюдение за тренировками таких легенд тенниса, как Рафаэль Надаль или Роджер Федерер, помогает понять высший уровень мастерства и увидеть правильный вектор развития. Однако если обычный тренер начнет обучать любителя по методикам Надаля, это будет полностью оторвано от контекста. По мнению Тальябуэ, обычный игрок просто пытается перебросить мяч на другую сторону сетки, и точно так же в MLOps — существует масса интересных и эффективных задач машинного обучения, которые можно успешно решать на любом, даже самом скромном масштабе, не превращаясь в Facebook.
📊 Две стороны B2B и три измерения архитектурных различий 6:31
Обсуждая специфику корпоративного сектора, Тальябуэ выделяет два основных типа B2B-компаний, использующих машинное обучение:
- Провайдеры ИИ-моделей. Компании вроде Tooso или Coveo, которые непосредственно продают искусственный интеллект как услугу для сотен других бизнесов. Для них качество моделей критически важно, поскольку это их основной продукт.
- Традиционный B2B SaaS. Компании вроде Expensify или Gusto, где небольшие ML-модели встроены внутрь комплексного продукта для автоматизации вспомогательных задач — например, распознавания типов продуктов по чекам. Клиенты покупают их сервис ради общего удобства, а не ради самих алгоритмов.
По словам эксперта, обе категории сталкиваются с вызовами, принципиально отличающимися от задач b2c-гигантов вроде Airbnb. Эти отличия лежат в трех плоскостях: данные, моделирование и инструментарий (Tooling).
Главный водораздел проходит по линии оценки возврата инвестиций (ROI). Тальябуэ подчеркивает, что в b2c-гигантах вроде Amazon улучшение рекомендательной системы всего на 1% мгновенно оборачивается миллиардными доходами в конце года, что легко оправдывает огромные зарплаты исследователей. В B2B-модели SAS ситуация иная: даже если алгоритм повысит эффективность на тот же 1%, поставщик не получит эти деньги напрямую из-за подписочной или транзакционной бизнес-модели. Косвенную выгоду и удовлетворенность клиентов измерить значительно сложнее. По этой причине лучшими прокси-метриками успешности для B2B-практиков гость считает отказоустойчивость, автоматизацию и минимизацию ручного труда при масштабировании.
🗄️ Специфика работы с данными: стратегия тотального логирования 15:04
В b2c-сфере разработчики оперируют единым массивом данных, поступающим из собственного приложения. В B2B ситуация иная: совокупный объем данных может быть огромным, но юридические ограничения, требования к приватности и безопасности заставляют изолировать данные для каждого конкретного клиента. Вместо одного огромного распределения инженерам приходится поддерживать сотни изолированных микро-распределений. Это кардинально меняет юнит-экономику: фиксированные затраты на обслуживание длинного хвоста предсказаний не снижаются по мере роста клиентской базы.
Кроме того, B2B-компания не владеет интерфейсом конечного пользователя. Если вы поставляете рекомендательный движок для чужого интернет-магазина, вы полностью зависите от того, как клиент передает вам данные. Их стандартизация превращается в сложнейший процесс, требующий не только качественного кода, но и выстраивания коммуникации между людьми.
В связи с этим Тальябуэ дает практический совет: логировать абсолютно все доступные параметры с самого первого дня работы в домене. В качестве примера он приводит историю из 2017 года, когда его команда в Tooso начала анонимно собирать геоданные пользователей на уровне городов, хотя в моделях этот признак не использовался. Спустя годы, когда возникла гипотеза о влиянии погодных условий на покупательское поведение, у компании уже был накоплен массив исторических данных, позволивший моментально провести анализ без необходимости заставлять клиентов менять настройки трекинга. В качестве индустриального стандарта Тальябуэ рекомендует ориентироваться на протоколы Google Analytics: если клиенты согласны с объемом сбора данных ИТ-гиганта, они без проблем одобрят аналогичный список для вашей рекомендательной системы.
🤖 Коммодитизация моделей и преодоление страха перед вендор-локом 24:00
По мнению Тальябуэ, современная индустрия искусственного интеллекта пришла к коммодитизации архитектур: для табличных данных отлично подходит XGBoost, а для текстовых — трансформеры. На этапе «разумного масштаба» тратить месяцы на оптимизацию модели ради сотых долей процента метрики бессмысленно, так как это не приносит компании ощутимого ROI. Основные проблемы и хаос возникают на этапах «до» и «после» обучения, что и составляет суть MLOps.
В споре о создании собственной инфраструктуры против покупки готовых решений (Build vs Buy) эксперт занимает жесткую позицию сторонника покупки. Под «покупкой» он понимает как коммерческие SaaS-платформы, так и внедрение зрелых open-source инструментов, таких как оркестратор Airflow или фреймворк Metaflow, изначально созданный в Netflix.
Якопо формулирует простое правило:
- Четко определите, в чем заключается уникальная ценность вашего продукта для клиента (например, для Coveo это были сессионные рекомендации, работающие без долгосрочной истории пользователя).
- Фокусируйте все силы команды на этой уникальной фиче.
- Всё остальное — покупайте или берите в готовом виде. Клиенту безразлично, как вы выделяете GPU-мощности или разворачиваете CSV-файлы.
Тальябуэ также скептически относится к популярному среди инженеров страху перед «вендор-локом» (зависимостью от облачного провайдера). Он признается, что последние пять лет его команда использовала облако только одного провайдера и полностью удовлетворена скоростью и надежностью. По его мнению, выгода от делегирования инфраструктурных проблем условному AWS существенно перевешивает потенциальные риски гипотетического повышения цен на 10% в будущем.
👥 Команда «full-stack» ML-инженеров: против хаоса и Кубернетиса 37:35
Концепция «разумного масштаба» диктует особые требования к кадрам. Вместо узкой специализации Тальябуэ голосует за концепцию «end-to-end» (или full-stack) ML-специалистов. Такой инженер обладает широким кругозором: он способен написать SQL-запрос к Snowflake, самостоятельно собрать конвейер данных, обучить модель и развернуть её в продакшене, неся полную ответственность за результат. Это исключает неэффективную практику, когда исследователь просто передает свой неоптимальный ноутбук дата-инженеру и умывает руки.
Однако full-stack подход накладывает обязательства на руководство. Задача лидера — предоставить инженерам удобные абстракции и «кубики Lego», избавив их от рутины. На вопрос, должен ли каждый дата-сайентист уметь настраивать Kubernetes, эксперт отвечает категорическим отказом. Специалисты должны понимать общую архитектуру системы, но не обязаны тратить дорогое рабочее время на правку YAML-файлов.
Как отмечает гость, эффективные ML-команды за пределами Биг Теха со стороны всегда выглядят недоукомплектованными. Но секрет прост: если убрать инфраструктурные барьеры, два классных full-stack специалиста сделают работу десяти сотрудников, постоянно согласующих действия между собой. При этом один дорогой универсал обойдется бизнесу дешевле пяти низкоквалифицированных кадров. Привлекать такие таланты небольшим компаниям помогает активное участие в open-source сообществах, публикации исследований и открытое ведение технологического блога.
⚡ Эвристики вместо ИИ: как находить реальную бизнес-ценность 48:35
Главный совет Тальябуэ для компаний, сталкивающихся с нехваткой данных и бюджетов, звучит парадоксально: «Первое правило машинного обучения — никогда не использовать машинное обучение на старте». При запуске новой функции, например анализа тональности твиттера, стоит начать с простейшей бессерверной функции (Lambda) на базе эвристических правил: если в тексте есть слово «супер», помечать его как позитивный.
Такой подход позволяет за три минуты запустить прототип и проверить, кликают ли пользователи на новую фичу вообще. Если интереса нет, компания экономит месяцы работы на построение сложных пайплайнов. Если же пользователи начинают активно взаимодействовать с сервисом или жаловаться на неточность правил — значит, бизнес-ценность подтверждена, и можно переходить к полноценному ML-моделированию.
Скорость итерации всегда побеждает технологическую сложность алгоритмов. Машинное обучение — это в большей степени искусство экспериментов, нежели чистая академическая наука. Построив гибкую систему из готовых технологических блоков, компания получает возможность точечно заменять и улучшать компоненты, оперативно реагируя на запросы рынка и фокусируясь на главном вопросе бизнеса: не как построить систему, а что именно имеет смысл создавать.
