# Как Adobe и Yelp строят бизнес-кейсы для платформ машинного обучения

Источник: https://www.youtube.com/watch?v=oNtd8lGkuzg
Канал: The TWIML AI Podcast
Опубликовано: 08.09.2022

---

Создание платформ машинного обучения (ML) — это уже не вопрос престижа, а насущная необходимость для крупных компаний. В рамках конференции, организованной The TWIML AI Podcast, эксперты из **Adobe**, **Yelp** и **Booz Allen Hamilton** обсудили, как обосновать инвестиции в инфраструктуру, когда пора переходить от готовых облачных решений к собственным разработкам и как централизация платформ помогает масштабировать инновации, не создавая хаоса в процессах.

## 💼 Эволюция бизнес-кейса: от «зачем нам ML» к «как этим управлять»
[[JUMP:00:01]]

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

**Джастин Норман (Yelp)** отмечает, что в зрелых организациях, которые уже сделали многолетние восьмизначные инвестиции в ИИ, каждый новый запрос на финансирование теперь проверяется так же строго, как любые другие инженерные или продуктовые затраты [10:21]. Разговоры о «полезности» сменились разговорами о «измеримости» и конкретной отдаче от вложений (ROI).

**Кирк Борн (Booz Allen Hamilton)** подчеркивает важность ориентации на результат:

*   Компании должны переходить от техникоцентричного подхода («у нас есть крутые инструменты») к миссиоцентричному («какую задачу бизнеса мы решаем»).
*   Стратегия «Думай масштабно, начинай с малого» (Think big, start small) позволяет создавать небольшие инкрементальные продукты [11:52].
*   Успех ИИ — это «командный вид спорта» [12:31]. Борн приводит аналогию с американским футболом: если выставить на поле 11 лучших квотербеков, команда проиграет, так как нужны разные навыки и роли.

## 📈 Метрики эффективности: как оценить пользу платформенной команды
[[JUMP:15:04]]

Для руководителя платформенного подразделения главная сложность заключается в том, что его работа — это не конечный продукт, а «включение» (enablement) других команд. **Дивья Джейн (Adobe)** выделяет несколько ключевых показателей эффективности (KPI), которые помогают доказать ценность платформы руководству [15:41]:

1.  **Time-to-Market (Скорость вывода на рынок):** Если раньше путь модели от идеи в исследовательском отделе до внедрения в продакшен занимал 6–9 месяцев, а с платформой сократился до 3 месяцев — это прямой показатель эффективности [16:21].
2.  **Повторное использование (Deduplication):** Возможность применить одну и ту же модель или пайплайн данных в разных продуктовых линейках с минимальной доработкой экономит огромные ресурсы организации [16:33].
3.  **Демократизация:** Упрощение инструментов до такой степени, чтобы ML могли использовать не только узкие специалисты, но и смежные подразделения.

## 🛠 Дилемма «Создать или купить»: когда API недостаточно
[[JUMP:17:50]]

Вопрос о том, стоит ли строить собственную платформу или использовать готовые облачные сервисы (AWS, Google Cloud, Azure), вызвал активную дискуссию.

**Кирк Борн** придерживается мнения, что новичкам не стоит изобретать велосипед. Начать можно с готовых API для распознавания лиц, обработки естественного языка или создания чат-ботов [19:06]. Это позволяет быстро проверить гипотезу без капитальных вложений в инфраструктуру.

Однако **Джастин Норман** возражает, указывая на ограничения готовых решений при масштабировании [20:12]:

*   **Нагрузки:** В **Yelp** около 17 миллионов пользователей генерируют триллионы событий в потоковом режиме. Облачные API часто не справляются с таким объемом данных или становятся запредельно дорогими [20:39].
*   **Специфика данных:** Коробочные решения не всегда позволяют проводить глубокую очистку и обогащение данных с нужным уровнем детализации.
*   **Скрытые факторы:** В реальных системах критически важны задержка (latency) и сетевые аспекты, которые внешние вендоры не всегда могут гарантировать в рамках интеграции с конкретным пользовательским интерфейсом [21:31].

Норман предлагает рассматривать ML-платформу как самостоятельный продукт, в который вовлечены дизайнеры, стратеги и инженеры, что позволяет гибко переходить от одного вендора к мультивендорной системе по мере роста [22:20].

## 🏛 Централизация против свободы: в поисках баланса
[[JUMP:23:24]]

Другой важный аспект — организационная структура. Стоит ли создавать единую платформенную команду или распределять специалистов по продуктовым группам?

По словам **Дивьи Джейн**, в **Adobe** принята модель централизованной платформы. Это необходимо, так как область ML еще не стандартизирована [25:09]. Если каждая команда будет самостоятельно решать задачи хранения данных, обучения и эксплуатации моделей, компания погрязнет в дублировании функций и проблемах с безопасностью [30:26]. Централизация обеспечивает «управление и соответствие» (governance and consistency), подобно тому, как в обычной разработке существуют единые системы CI/CD и базы данных.

**Джастин Норман** описывает гибридный подход в **Yelp** [26:53]:

*   **Инфраструктура централизована:** Есть только несколько стандартизированных путей вывода модели в продакшен.
*   **Продуктовые команды вертикализированы:** Специалисты по данным (data scientists) встроены в конкретные отделы (например, потребительские продукты или бизнес-аналитика). Это позволяет им использовать специфические техники (рекомендательные системы для одних, компьютерное зрение для других), опираясь на общую надежную базу [27:18].

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