Почему пилот AI-системы работает, а после масштабирования всё ломается

Как устроен процесс

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

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

Что важно учесть до запуска

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

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

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

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

Принципы, без которых система не будет управляемой

• Владелец процесса. Один человек отвечает не за модель, а за итоговый KPI процесса и имеет право останавливать автоматизацию.
• Контрольные точки. До и после критических решений фиксируются вход, версия правил, результат, уверенность, время и причина ручной передачи.
• Контракт данных. Обязательные поля, допустимые значения и политика отсутствующих данных проверяются до вызова AI.
• Идемпотентность. Повтор события не создаёт второй заказ, письмо или задачу; у операции есть устойчивый ключ.
• Fallback. При недоступности модели, низкой уверенности или нарушении политики запрос уходит в понятную очередь человеку.

Архитектура решения и движение данных

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

Отдельный слой наблюдаемости должен отвечать на три вопроса: что случилось с конкретной задачей, как изменилось качество на группе задач и сколько стоит один успешно завершённый результат. Логи без связи с бизнес-идентификатором не дают этой картины, а агрегированная стоимость без статуса результата маскирует дорогие повторы.

Ошибки, ограничения и безопасный fallback

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

Как измерять качество, эффект и стоимость

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

Пошаговый план внедрения

1. 01

   Зафиксировать границы процесса, владельца, KPI и условия остановки.

2. 02

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

3. 03

   Описать контракты этапов, статусы задачи, таймауты и идемпотентность.

4. 04

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

5. 05

   Добавить журналирование, стоимость и наблюдаемость до роста нагрузки.

6. 06

   Запустить ограниченный поток, сравнить с baseline и расширять долю только после прохождения критериев.

Чек-лист приёмки

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

• Владелец процесса и дежурный канал эскалации назначены
• Статусы задачи и причины ошибок доступны без чтения сырых логов
• Повтор события не создаёт повторного бизнес-действия
• Версии модели, правил и источников записываются с результатом
• Проверен ручной маршрут при недоступности AI
• Стоимость считается на успешно завершённую задачу

Частые вопросы

Можно ли просто увеличить лимиты API?

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

Когда пилот готов к масштабированию?

Когда описаны входы и исключения, есть измеримый baseline, регрессионные проверки, логи, стоимость операции и проверенный fallback.

Нужен ли отдельный MLOps-контур для LLM?

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

Источники

1. AI Risk Management Framework: CoreNIST
2. Artificial Intelligence Risk Management FrameworkNIST
3. Practitioners guide to MLOpsGoogle Cloud
4. Managing ML projects: productionizationGoogle for Developers
5. Machine Learning Lens — AWS Well-Architected FrameworkAmazon Web Services
6. Best practices for deploying language modelsOpenAI
7. Evals drive the next chapter of AI for businessesOpenAI
8. Building an evalOpenAI