Кого вы наймёте первым, когда решите внедрять машинное обучение? Data Scientist'а. Звучит логично. Вы находите человека с блестящим профилем на Kaggle, даёте ему доступ к серверам и ждёте прорыва. Через полгода у вас есть монструозный Jupyter-ноутбук, который выдаёт красивую точность на исторических данных, но падает с ошибкой нехватки памяти при попытке обработать реальный поток. В прод это не едет. Никогда. Это классический сценарий гарантированного уничтожения инициативы на корню.
Реальный мир работает иначе. Сколько людей и каких нужно для ИИ-проекта: роли, которые забывают заложить в бюджет — это суровая математика, которую бизнес обычно постигает на стадии посмертного анализа проекта. Нейросеть сама по себе — это десять процентов усилий. Остальные девяносто — это доставка данных, обвязка, оптимизация под железо, мониторинг деградации и интеграция в бизнес-логику. Один человек не вытянет этот конвейер физически, а если попытается — вы получите архитектуру, которая рухнет при первой пиковой нагрузке.
Ошибка первая: искать «универсального солдата» и плодить bus-factor
Попытка нанять одного специалиста, который закроет весь цикл от выгрузки CSV до настройки балансировщиков нагрузки, приводит к созданию системы с bus-factor равным единице. Если этот человек уволится, вы останетесь с тысячами строк недокументированного кода, который никто не сможет даже запустить. Чтобы система жила, роли должны быть чётко разделены по компетенциям.
Data Engineer — это фундамент. До того как первый тензор умножится на матрицу, данные нужно откуда-то забрать, очистить, дедуплицировать и положить в хранилище так, чтобы чтение не занимало часы. Без дата-инженера ваш дорогой математик будет писать кривые SQL-запросы и тратить семьдесят процентов времени на парсинг битых логов. Это сжигание денег. Данные должны подаваться в модель непрерывным, чистым потоком.
Data Scientist создаёт саму модель. Он ищет архитектуру, подбирает гиперпараметры, валидирует гипотезы. Его зона ответственности — математика. Его код почти всегда не оптимизирован для продакшена. И это нормально. Его задача — доказать, что сигнал в данных вообще существует. Как только он получает приемлемую метрику, его работа на текущем этапе заканчивается.
ML-инженер берёт скрипт Data Scientist'а и превращает его в промышленный софт. Модель написана на Python с кучей зависимостей? ML-инженер перепишет критические узлы на C++, скомпилирует модель в TensorRT для инференса на GPU клиента, настроит батчинг запросов и убедится, что задержка (latency) укладывается в жесткие 50 миллисекунд по p99. Он заставляет тяжёлую математику работать в условиях реальных ограничений по памяти и процессору.
MLOps-инженер строит инфраструктуру, которая не даст всей этой конструкции сгнить. Модели деградируют. Меняется освещение в цеху, меняется поведение пользователей, меняется формат входящих json-пакетов. Без MLOps вы узнаете о том, что модель начала предсказывать бред, только когда клиенты начнут уходить или конвейер отбракует партию хороших деталей. MLOps автоматизирует переобучение, версионирует модели и следит за data drift'ом.
Суровая пропорция: 1 к 3
Исторически сложилась опасная иллюзия, что команда ML состоит в основном из Data Scientist'ов. Практика высоконагруженных систем диктует обратное. На одного Data Scientist'а в зрелой команде должно приходиться от двух до четырёх инженеров (Data, ML, MLOps). Математику нужно обслуживать. Если пропорция нарушена в пользу исследователей, вы будете производить огромное количество мёртвых прототипов, которые некому внедрять.
Ниже — типичный манифест для Kubernetes-кластера, который пишет MLOps или ML-инженер. Data Scientist редко думает о лимитах оперативной памяти или динамическом шардировании. А без этого на реальном трафике ядро Linux просто убьёт процесс по OOM (Out Of Memory).
apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
name: anomaly-detector
spec:
predictor:
minReplicas: 2
maxReplicas: 10
scaleTarget: 80
model:
modelFormat:
name: triton
storageUri: s3://model-registry/anomaly/v3/
resources:
limits:
nvidia.com/gpu: "1"
memory: "8Gi"
requests:
cpu: "4"
memory: "4Gi"Ошибка вторая: забыть про доменного эксперта
Самая дорогая ошибка при планировании бюджета кроется за пределами IT-отдела. Вы можете нанять лучших алгоритмистов на рынке, но они ничего не знают про ваш бизнес. Они не отличают микротрещину на лопатке турбины от блика света. Они не понимают, почему в пятницу вечером трафик падает, а в понедельник утром взлетает.
Доменный эксперт — это человек со стороны бизнеса, который руками размечает критически важные примеры, объясняет физику процесса и валидирует результаты модели на предмет здравого смысла. Зачастую это главный технолог, опытный врач, ведущий аналитик или оператор станка. Участие такого человека в ИИ-проекте критически необходимо, и оно съедает львиную долю его рабочего времени.
Если вы не освобождаете доменного эксперта от его прямых обязанностей на время проекта, он размечает данные по ночам. Как итог — грязный датасет. Грязный датасет на входе означает мусор на выходе. Скрытая стоимость отсутствия доменного эксперта — это месяцы работы команды разработчиков, спущенные в унитаз, потому что нейросеть научилась предсказывать не дефект, а маркер, которым этот дефект обвели на фотографиях.
Владелец продукта (Product Owner) — ещё одна невидимая статья расходов. Кто-то должен переводить метрики из F1-score и ROC AUC в понятные бизнесу рубли, проценты брака и сэкономленные часы. Машинное обучение ради машинного обучения не нужно никому. PO держит команду в фокусе, отрезая бесконечные исследовательские задачи и заставляя инженеров катить в продакшен то, что решает конкретную боль компании прямо сейчас.
Ошибка третья: иллюзия снятой ответственности при работе с подрядчиком
Поняв, что сбор собственной инхаус-команды из шести разных профилей обойдётся в целое состояние, бизнес часто принимает решение отдать всё на аутсорс. Нанимается компания-интегратор. Подписывается договор. Руководство выдыхает, ожидая готового ИИ-решения под ключ.
Подрядчик принесёт вам экспертизу в написании кода, правильную архитектуру и железобетонный инференс. Он закроет позиции ML-инженеров, Data Scientist'ов и MLOps. Но он никогда не принесёт вам понимание вашего собственного бизнеса. Есть вещи, которые должны остаться на стороне заказчика любой ценой.
Ваша сторона обязана предоставить владельца продукта. Никакой подрядчик не имеет права и возможности менять ваши бизнес-процессы под внедрение алгоритма. Ваша сторона обязана выделить доменного эксперта. Подрядчик не привезёт с собой металлурга с двадцатилетним стажем, чтобы отличить шлак от чистого металла. И, наконец, ваша сторона должна обеспечить прозрачный доступ к данным. Интегратор не сможет настроить шину данных, если служба безопасности маринует заявки на доступы к базам по три недели.
Пытаться переложить эти роли на аутсорс — значит обречь систему на тотальную изоляцию от реальности. Вы получите идеальный с точки зрения математики софт, который никто в компании не захочет и не сможет использовать.
Разумный трейд-офф
Обратная крайность тоже губительна. Раздувать штат на раннем этапе — верный путь к кассовому разрыву. Если проект находится на стадии проверки жизнеспособности (PoC) или MVP, вам не нужна полная команда с выделенным MLOps-инженером. На этой фазе архитектурные компромиссы неизбежны и оправданы.
Для старта достаточно связки из сильного аналитика-разработчика, доменного эксперта и продакт-оунера. Их задача — быстро собрать рабочий муляж на предобученных моделях или простых эвристиках, чтобы понять, стоит ли вообще игра свеч. Инвестиции в тяжелую инженерию начинаются ровно в тот момент, когда алгоритм доказал свою ценность и должен интегрироваться в критические системы компании, работающие в режиме реального времени на edge-устройствах без доступа к облаку.
Выбирайте инструменты и состав под текущую фазу. Но помните, что переход от ноутбука к заводскому конвейеру потребует совершенно других людей. Либо вы планируете бюджет на инженеров и экспертов на берегу, либо оплачиваете бесконечный цикл переписывания неработающего кода через год. Чудес в инженерии не бывает.