Модель обучили. Что дальше? Почему ИИ-проекты застревают между пилотом и реальной работой

Модель ИИ показывает хорошую точность, пилот признали успешным, команда довольна результатом. Казалось бы, можно запускаться. Но именно здесь многие AI-проекты начинают буксовать. Разработка ИИ для бизнеса заканчивается рабочим инструментом только тогда, когда модель встроена в инфраструктуру компании, получает реальные данные, передаёт результат нужным сотрудникам и продолжает стабильно работать после запуска.

На презентации этот слой почти незаметен. На практике именно он часто определяет судьбу проекта.

Почему работающая модель ещё не означает работающую систему

Представим систему компьютерного зрения на производстве. Камера передаёт видеопоток, модель видит сотрудника без каски и корректно определяет нарушение.

С технической точки зрения задача решена.

С точки зрения предприятия сразу появляются следующие вопросы. Кому сообщить о нарушении? Как быстро? Нужно ли сохранить кадр? Где будет храниться история событий? Как отличить реальное нарушение от ложного срабатывания? Должно ли событие попадать в существующую систему безопасности? Кто увидит статистику за смену или месяц?

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

Модель отвечает на вопрос «что произошло». Система должна определить, что с этим результатом делать дальше.

Самая сложная часть часто начинается на интеграции

У среднего и крупного бизнеса уже существует собственный ИТ-ландшафт. ERP, WMS, CRM, MES, VMS, внутренние базы, системы отчётности и десятки сервисов используются ежедневно.

Новый AI-модуль должен встроиться в эту среду.

Например, система на складе обнаружила несоответствие при приёмке паллеты. Само распознавание даёт мало пользы, если оператору всё равно приходится вручную искать поставку и переносить данные в WMS.

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

Та же логика действует в других отраслях. Результат анализа может:

• создавать событие в корпоративной системе;
• отправлять уведомление ответственному сотруднику;
• запускать проверку;
• передавать данные в ERP, CRM или WMS;
• формировать отчёт;
• сохранять доказательный кадр и историю обработки.

Поэтому архитектуру интеграции желательно проектировать ещё до того, как команда уходит глубоко в разработку модели.

Когда действительно нужна собственная модель

Есть и противоположная крайность: начинать каждый AI-проект с идеи «давайте обучим свою нейросеть».

Это далеко не всегда оправдано.

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

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

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

Поэтому вопрос должен звучать не «можем ли мы обучить свою модель», а какой вариант даст требуемый результат при разумной стоимости владения.

Пилот — это проверка гипотезы, а не финал проекта

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

Но условия пилота обычно проще промышленной эксплуатации.

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

Для ML-систем это нормальная ситуация.

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

После внедрения ИИ тоже требует обслуживания

Обычное корпоративное ПО нуждается в поддержке. Системы машинного обучения добавляют к этому ещё один изменяющийся слой — данные.

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

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

Если об этом вспомнить только после запуска, даже технически сильное решение постепенно начинает создавать проблемы в эксплуатации.

Пять вопросов, которые стоит задать до начала AI-проекта

Чтобы проект не закончился красивым прототипом, на старте полезно проверить пять вещей:

1. Какой бизнес-процесс должен измениться?
   Нужен конкретный участок работы и понятный результат.
2. Какие данные доступны?
   Важно оценить не только их объём, но и качество, доступность и соответствие реальным условиям.
3. Куда должен попадать результат работы ИИ?
   Сотруднику, оператору, руководителю, в CRM, WMS или другую систему.
4. Как решение будет масштабироваться?
   Архитектура для одного пилотного объекта может не выдержать промышленную нагрузку.
5. Кто будет отвечать за систему после запуска?
   Нужно заранее определить порядок поддержки, мониторинга и обновления.

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

Что в итоге

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

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

Тогда успешный пилот становится началом масштабирования, а не последней демонстрацией технологии перед тем, как проект отправится в архив.