Продуктовую команду в AI-компании обычно собирают просто: берут привычную софтверную команду и ставят рядом пару дата-сайентистов. Первые месяцы это работает. Потом выясняется, что поменялась сама единица работы. Раньше команда сдавала фичу с понятным результатом. Теперь она отвечает за поведение модели, а оно на разных данных разное.
Из-за этого ломается всё, что держалось на предсказуемости: оценки сроков, приёмка, дежурства, ответственность за качество. Ниже разбор того, какие структуры выдерживают рост числа AI-продуктов, какие роли появляются и где у такой организации проходят швы.
Модель ведёт себя по-разному, и под это нужна другая структура
Мода на искусственный интеллект тут ни при чём. Раньше команда выпускала функции, и результат был предсказуем. Теперь модель отвечает по-разному, зависит от данных, качество плавает, а регуляторы предъявляют свои требования. Со всем этим приходится справляться в рамках одного порядка работы.
Пока AI-продукт в компании один, привычный Agile справляется. Когда продуктов несколько, команды, настроенные на выпуск функций, начинают трещать. Потоки данных усложняются, модели ведут себя нестабильно, проверок безопасности становится всё больше, а сред для выкладки уже несколько слоёв.
Код самой модели в такой системе занимает малую часть. Всё остальное, те самые пайплайны, проверки и окружения, и требует новой структуры команд, потому что у этой работы по умолчанию нет владельца.
Структуру определяет число AI-продуктов, а не вкус руководителя
Устойчивых топологий три. Выбор между ними диктуют зрелость и масштаб AI-инициатив. Скорее это три точки на траектории роста одной организации, чем три альтернативы.
Названия у этих команд в каждой компании свои, функции совпадают. Платформенная команда снимает с продуктовых рутину инфраструктуры. Продуктовые команды ведут поток ценности до пользователя. Центр компетенций по сути ближе к команде, которая подтягивает остальных, и постоянным посредником ему становиться нельзя.
Отсюда видно, почему единый центр со временем ломается. Любая команда, через которую обязаны проходить чужие задачи, превращается в затор, как только поток запросов превышает её пропускную способность.
Централизованный Center of Excellence
На ранних этапах разумно собрать редких специалистов по машинному обучению в одном месте. Центр держит их вместе, вырабатывает стандарты и правила контроля (governance), быстро делает прототипы и учит продуктовые команды.
У модели есть срок годности, и его можно посчитать. Допустим, центр из шести человек закрывает 12 запросов в месяц. Пять продуктовых команд присылают по четыре, то есть 20. Очередь растёт на восемь запросов ежемесячно. К концу квартала в ней 24 задачи, и новый запрос ждёт около двух месяцев. Команды начинают обходить центр и строить свои пайплайны, а стандарты расползаются.
Платформа и продуктовые команды поверх неё
Платформенные команды отвечают за общие детали, которыми пользуются все. Это хранилища данных для моделей, инструменты для работы с запросами к моделям, процессы обучения и дообучения, каталог моделей и системы проверки качества. Сюда же входят проверка качества данных, автоматический контроль правил и инструменты для тестирования и безопасной работы.
Продуктовые команды отвечают за другое. За задачи от начала до конца и функции поверх общих компонентов, за эксперименты и раскатку моделей, за UX AI-поведения. В конечном счёте за бизнес-результат. Разделение простое: платформа даёт масштаб, продуктовые команды дают ценность.
Гибридная федеративная модель
Для нескольких продуктовых направлений подходит гибрид. В основе централизованная платформа и governance. Продуктовые команды организованы по доменам, дата-сайентисты встроены прямо в них, кросс-функциональные сквады работают автономно.
Схема масштабируется без потери качества, потому что общие правила и инфраструктура заданы в центре, а решения принимаются близко к продукту. Сигналы, что пора переходить к ней от единого центра, обычно видны заранее:
- в очереди центра больше задач, чем он закрывает за месяц;
- две команды и больше пишут одинаковые компоненты: оценочные датасеты, оркестрацию промптов, мониторинг дрейфа;
- продуктовые команды ждут центр дольше, чем длится их собственный цикл эксперимента;
- стандарты оценки в разных командах уже разошлись, и результаты моделей нельзя сравнить.
Два сигнала из четырёх уже повод проектировать платформу. Три значат, что переход запаздывает.
Новые роли закрывают разрывы между моделью и продуктом
AI-продукт добавляет обязанности вокруг жизненного цикла моделей, качества данных, оценки и рисков. Под них появляются роли, которых в обычной продуктовой команде просто нет.
AI-продакт формулирует проблему и гипотезы и проверяет, хватит ли под задачу данных. Он решает, по каким признакам оценивать модель и где ставить ограничители, вместе с дизайнером продумывает, как пользователь общается с моделью, планирует эксперименты и метрики. Ещё он следит за этическими и правовыми требованиями и помогает договориться инженерам, специалистам по данным и юристам. Это сочетание продуктовых навыков, понимания моделей и умения управлять рисками.
Специалист по данным (data scientist) готовит данные для модели, ставит эксперименты с моделями и проверяет их на исторических данных. Он следит за статистической строгостью, собирает исследовательские прототипы и копается в данных в поисках закономерностей.
ML-инженер отвечает за то, чтобы модель попала в продукт и работала: встраивание, процесс выкладки, скорость, способность выдержать рост запросов, наблюдение за моделью и за тем, не стала ли она хуже работать со временем. MLOps-инженер отвечает за инфраструктуру: мониторинг, автоматическое переобучение, управление процессами и версиями моделей.
Отдельно стоит роль, которой раньше не было совсем: специалист по оценке и безопасности AI. Он собирает эталонные наборы примеров (golden-датасеты), проверяет модели на выдуманные ответы, предвзятость и уязвимости и решает, можно ли выпускать релиз. Дизайнер AI-интерфейсов придумывает, как показать пользователю, насколько модель уверена, как объяснить её ответ и где решение должен проверить человек. Ответственный за данные следит, откуда взяты данные и соответствуют ли они правилам, а также за тем, чтобы по каждой модели оставались документы для проверки.
Для небольшой компании это не значит семь новых ставок. Роли можно совмещать. Нельзя оставлять обязанность без имени: если никто не отвечает за golden-датасет, его не обновляют, и оценка тихо устаревает.
Цикл AI-PM чаще возвращается назад, чем идёт вперёд
Процесс устроен по другой логике: вместо линейной поставки идёт итеративный цикл. Шаги идут в таком порядке:
- PM формулирует проблему, гипотезы и критерии успеха.
- Data scientist оценивает качество и доступность данных.
- Вместе с ML-инженером он собирает прототипы, после чего PM и DS разбирают оффлайн-результаты.
- Если результаты устраивают, инженерия интегрирует модель в продукт.
- PM запускает онлайн-эксперименты на реальном трафике.
- Команда безопасности одобряет релиз.
- MLOps берёт на себя деплой, мониторинг и переобучение.
На любом шаге результат может отправить команду назад, к данным или к постановке задачи. Это нормальный ход работы, и план должен оставлять на него время.
Самый болезненный откат случается между шагами 3 и 5. Booking.com в докладе на KDD 2019 о 150 моделях в продакшене показал: рост оффлайн-метрики не гарантирует роста бизнес-метрики. Там же приведён пример цены задержки: рост latency примерно на 30% стоил около 0,5% конверсии. Модель, которая точнее, но медленнее, может проиграть на живом трафике.
Поэтому оценка модели не уходит целиком к дата-сайентистам. Она остаётся зоной ответственности продакта. PM должен понимать, что стоит за precision / recall, latency, уровнем галлюцинаций, стоимостью инференса и дрейфом поведения. Иначе он не сможет решить, готов продукт к раскатке или нет.
Governance дешевле встроить, чем пришить после релиза
В AI-организациях контроль встроен в повседневную работу. На уровне процесса это контроль происхождения и качества данных, документирование моделей, тестирование на уязвимости промптов. Плюс уведомления пользователей и сценарии human-in-the-loop там, где решение нельзя полностью отдавать автомату.
Над этим слоем стоит структурный. Фреймворки Responsible AI задают критерии справедливости, требования к объяснимости, оценку рисков, документирование датасетов и журналы аудита. Каждое такое требование удобно привязать к шагу цикла, описанного выше: у шага появляется владелец риска и документ на выходе, и проверка перестаёт быть отдельным событием в конце.
Там, где модель решает что-то о деньгах, работе или доступе к услугам, проверку человеком закладывают в дизайн с первого прототипа. Пришить её после релиза обходится дороже, а пользователи успевают привыкнуть к ответам без проверки.
У надзора есть ловушка, известная задолго до нейросетей: о ней писала ещё Бейнбридж в статье "Ironies of Automation" (1983). Речь о склонности человека слишком полагаться на вывод системы, особенно когда она обычно права. Для команды это значит конкретную метрику: доля случаев, где проверяющий не согласился с моделью. Если она месяцами держится у нуля, надзор, скорее всего, превратился в формальность.
Конвейеры оценки моделей стандартизируют red-teaming, golden-датасеты, оффлайн- и онлайн-тесты и процедуры одобрения. Управление жизненным циклом собирает всё в единый контур: реестры моделей, мониторинг дрейфа, расписания переобучения и вывод моделей из эксплуатации. Если в этом контуре нет владельца, модели работают в продакшене дольше, чем кто-либо проверял их качество.
Четыре компетенции держат команду вместе
AI поднимает планку требований и к продактам, и к техническим ролям. Держится эта планка на четырёх вещах.
Основа всего: понимать, как устроены модели, почему они выдумывают ответы, как писать для них запросы, как подключать к ним поиск по своим данным, как мерить качество и какие есть риски. Без умения работать с данными этого мало. Рядом нужно уметь читать поведение пользователей, метрики моделей, качество данных, разбивать аудиторию на группы и замечать, когда модель начинает работать хуже.
Третье: эксперименты. AI-команда всё время что-то проверяет: модель на старых данных и на живых пользователях, A/B-тесты моделей, защитные метрики, автоматическое распределение трафика между вариантами, постепенный выпуск на часть аудитории. Замыкает список экономическое мышление: AI меняет структуру затрат продукта, и PM должен уметь моделировать стоимость инференса, эффективность масштабирования, компромисс между точностью и стоимостью и влияние AI на экономику процессов.
Всё это работает, только если роли плотно связаны. Специалист по данным подключается уже на этапе поиска решения, продакт задаёт признаки качества, ML-инженер доводит модель до работы у пользователей, дизайнер придумывает, как объяснять ответы модели, MLOps следит за мониторингом.
План работ тоже становится общим. В нём есть то, чего нет в обычном продуктовом плане: новые возможности платформы, потоки данных, развитие моделей, зависимость от платформы и пределы роста. Отдельная нагрузка ложится на коммуникацию. PM приходится честно объяснять неопределённость, рисковые сценарии и диапазон поведения моделей, даже когда руководство ждёт уверенных формулировок.
Первый кандидат в платформу уже написан дважды
Оргсхему выбирают последней. Три топологии нельзя выбрать заранее, как блюдо из меню: правильная структура определяется тем, сколько у вас AI-продуктов и как часто они переиспользуют одни и те же компоненты. Пока продукт один, Center of Excellence быстрее. Когда команд три и больше и они переписывают чужие пайплайны, выигрывает гибридная модель с общей платформой.
Практический шаг поэтому скромный. Выпишите, какие AI-компоненты в командах уже дублируются: оценочные датасеты, оркестрация промптов, мониторинг дрейфа. Первым в платформу идёт компонент, который прямо сейчас пишут заново в двух местах, даже если технически он самый скучный. Вокруг него потом достраиваются роли и governance.