Почему ИИ-агенты в пилотах работают, а в продакшене не дают результата и как это исправить?

Что произошло, почему это важно и что взять в работу.

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

Связанные услуги: каталог, AI Boost Team, стать клиентом.

Пилот на 90%, продакшен на 40% — и это не про модель

Знакомая картина. Команда три месяца гоняет LLM-агента в песочнице. Точность на отобранных кейсах — под 90%. Демо для совета директоров проходит гладко. Через месяц после релиза в реальный контур бизнес видит 40% успешных задач, поток жалоб и счёт за токены, который никто не планировал. Проект сворачивают. Виновником назначают «сырую модель».

Модель тут почти ни при чём. Разрыв между пилотом и продакшеном — инженерный. И он предсказуем. Ниже — что именно ломается, как это измерять и в каком порядке чинить.

Почему пилот и продакшен — это две разные системы

Пилот живёт в стерильной комнате. Вы сами выбираете входные данные. Вы проверяете ответы руками. Сценариев — пять, и все они описаны в брифе. SLA нет, потому что никто не заметит, если агент ответит за 12 секунд вместо 3.

Продакшен — это открытая сцена. Пользователи пишут с опечатками, меняют тему на середине диалога, задают вопросы вне домена. Внешние API отвечают таймаутами и 500-ми. Цепочка вызовов растягивается на 8–15 шагов, и на каждом шаге что-то может отвалиться. Бизнес требует p95 задержки в пределах разумного и стоимость запроса, которую можно защитить перед финдиром.

Вот где расходятся цифры. На пилотах с ручной проверкой доля успешных задач обычно 40–60%. В продакшене с выстроенными evals и guardrails — 75–90%. Разница не в весах модели. Разница в том, что между агентом и пользователем стоит инженерный слой.

Команды вкладываются в промпты и выбор модели, ожидая, что этого хватит. Не хватает. Провал происходит на уровне наблюдаемости, обработки сбоев и управления состоянием. Покупаете вызов API, а не решение — получаете ровно то, за что заплатили.

Корень проблемы: у агента нет инженерной обвязки

Три вещи, которых почти никогда нет на пилоте и без которых продакшен не живёт.

Наблюдаемость

Трейсинг шагов. Логирование входов и выходов каждого инструмента. Алерты на аномалии: рост доли отказов, всплеск задержки, необычные аргументы вызовов. Без этого вы не знаете, что происходит внутри агента. Без наблюдаемости до пользователя доходит 80–90% инцидентов — то есть бизнес узнаёт о проблеме из жалоб, а не из мониторинга. С трейсингом и алертами эта доля падает до 15–30%.

Evals

Датасет реальных кейсов, включая краевые и ошибочные, который прогоняется на каждой итерации промптов и модели. Не разовая проверка перед релизом, а регрессионный тест. Меняете промпт — гоняете датасет. Обновляете модель — гоняете датасет. Иначе каждое улучшение ломает то, что работало вчера, и вы узнаёте об этом от клиента.

Guardrails

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

Эти три слоя — не «улучшения на будущее». Это то, что превращает демо в рабочий инструмент. Промпты и выбор модели — верхушка. Обвязка — фундамент.

Метрики, которые показывают реальное состояние агента

Точность в вакууме бесполезна. Смотрите на набор, который бизнес может защитить перед руководством.

Эти метрики снимаются на реальном трафике. Не на демо-кейсах. Не на отобранных примерах. Если вы не можете их показать — вы не знаете, готов ли агент к продакшену.

Пошаговый переход от пилота к продакшену

1. Зафиксируйте метрики успеха на реальном трафике. Точность выполнения задачи, доля эскалаций, p95 задержки, стоимость на запрос. До того, как что-то менять.
2. Соберите датасет из 100–300 реальных кейсов. Включая краевые и ошибочные. Это ваш регрессионный тест. Прогоняйте его на каждой итерации промптов и модели.
3. Оберните агента в слой наблюдаемости. Трейсинг шагов, логирование входов и выходов инструментов, алерты на аномалии. Без этого вы слепы.
4. Добавьте guardrails. Валидация аргументов вызовов, лимиты на цепочки, fallback-сценарии, обязательная эскалация при низкой уверенности.
5. Запустите в теневом режиме. Агент работает параллельно с текущим процессом, вы сравниваете результаты с базовой линией. Никакого влияния на пользователя.
6. Канареечный релиз на 5–10% трафика. Смотрите на метрики в реальном контуре. Если держатся — расширяете.
7. Заложите бюджет на регрессионное тестирование и обновление evals. Это не разовая задача. Это регулярный процесс, как поддержка любого продакшен-сервиса.

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

Типичные ошибки при масштабировании

• Пропуск этапа evals и надежда на промпты. Промпт — это не тест. Без датасета вы не знаете, стало ли лучше или просто иначе.
• Игнорирование краевых случаев и отказов инструментов. В демо API отвечает всегда. В проде — нет. Если у вас нет fallback, агент падает.
• Отсутствие владельца агента и процесса обновления. Агент в продакшене — это живая система. Ей нужен человек, который отвечает за метрики, обновляет evals и реагирует на алерты. Без владельца агент деградирует.
• Оптимизация стоимости в ущерб качеству. Сокращение шагов цепочки снижает стоимость с 0,5–1,5 ₽ до 0,1–0,4 ₽ за запрос. Но если при этом падает точность — экономия мнимая.

Когда это не сработает

Инженерная обвязка не универсальна. Есть сценарии, где она не поможет.

• Юридически значимые решения без участия человека. Если агент должен принимать решения с правовыми последствиями, никакие guardrails не заменят человека в контуре.
• Данные недоступны или их качество не улучшается. Если на входе мусор, на выходе будет мусор. Обвязка не чинит данные.
• Бизнес не готов выделить ресурсы на поддержку. Агент в продакшене требует регулярного обновления evals, мониторинга и реакции на инциденты. Если это не заложено — система деградирует за 1–2 месяца.

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

Что делать в первую неделю

1. Зафиксируйте метрики успеха на реальном трафике. Не на демо. На тех данных, которые агент увидит в проде.
2. Соберите первые 50 кейсов, включая краевые. Запустите трейсинг. Даже минимальный — логи шагов и вызовов инструментов.
3. Определите ответственного за агента в продакшене. Не «команда», а конкретный человек с именем.

Этого хватит, чтобы через 4 недели у вас были первые цифры на реальном трафике, а не ощущение, что «вроде работает».

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