Чек-лист: LLM-агент готов к продакшену или ещё нет

Агент, который бодро проходит демо на трёх заранее подобранных запросах, — это ещё не продукт. Продакшен начинается там, где к нему приходят живые пользователи с кривыми формулировками, где каждый вызов модели стоит денег, а один неверный вызов инструмента может списать деньги со счёта или удалить запись из базы. Между «работает у меня в ноутбуке» и «работает у тысячи клиентов» лежит список проверок, который легко пропустить в спешке. Собрали его в виде чек-листа: если хотя бы половина пунктов красная — релиз лучше отложить.

Что вообще считать «агентом»

Под агентом¹ здесь понимается система, где языковая модель не просто отвечает текстом, а сама решает, какие инструменты вызвать: поиск в базе, запрос к API, отправку письма, запись в CRM. Именно эта автономность и делает продакшен рискованным. Обычный чат-бот в худшем случае ответит глупость. Агент в худшем случае эту глупость выполнит — переведёт деньги не туда, отменит не тот заказ, разошлёт письма не тем людям.

Поэтому чек-лист ниже устроен вокруг одного вопроса: что произойдёт, когда агент ошибётся. Не «если», а «когда» — ошибётся он обязательно.

Блок 1. Границы и права доступа

Первое, что проверяют перед релизом, — что агент физически не может сделать то, чего делать не должен. Не «мы попросили его в промпте не удалять записи», а «у сервисного аккаунта нет прав на удаление».

• Минимальные права. Каждый инструмент работает от аккаунта с ровно теми правами, что нужны для задачи. Промпт — не защита, промпт обходится одной удачной формулировкой пользователя.
• Необратимые действия — под подтверждением. Всё, что нельзя откатить (платёж, отправка внешнего письма, удаление), проходит через явное подтверждение человека или второй проверки.
• Лимиты на вызовы. Есть потолок на число вызовов инструментов за одну сессию, чтобы агент не ушёл в бесконечный цикл «вызвал — не понравилось — вызвал снова».
• Изоляция данных пользователей. Агент одного клиента не может через инструмент дотянуться до данных другого.

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

Блок 2. Качество ответов и оценка

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

• Оффлайн-набор кейсов. 50–200 реальных запросов с ожидаемым поведением. Меняете промпт — прогоняете весь набор, а не три любимых примера.
• Проверка на галлюцинации. Если агент отвечает по вашим данным, у него должен быть RAG² или иной способ опираться на источник, а не выдумывать. И проверка, что он не сочиняет факты, когда источник молчит.
• Поведение при незнании. Агент умеет сказать «не знаю» и передать человеку, а не выдавать уверенную ерунду.
• Устойчивость к провокациям. Проверьте попытки вытащить системный промпт, заставить агента игнорировать правила, подсунуть вредную инструкцию в данных.

Блок 3. Деньги и производительность

Агент делает несколько вызовов модели на одну задачу, иногда десятки. На демо это незаметно. На тысяче пользователей в день счёт за API становится главной строкой расходов, а задержка в 15 секунд — причиной, по которой пользователи уходят.

• Стоимость на задачу. Вы знаете, сколько стоит один типовой сценарий в токенах и деньгах. Умножьте на прогноз нагрузки — цифра не должна вас удивить после релиза.
• Потолок расходов. Есть лимит трат за период с алертом, чтобы зациклившийся агент или всплеск нагрузки не выставили счёт на порядок больше ожидаемого.
• Задержка. Замерена задержка по 95-му перцентилю, а не средняя. Средняя врёт: пара медленных запросов её не портит, но именно они бесят пользователей.
• Кэш и модель под задачу. Простые шаги отданы модели подешевле, повторяющиеся ответы кэшируются.

Блок 4. Наблюдаемость и откат

Когда агент ответит клиенту чем-то странным, вам придётся понять, что именно произошло: какой был запрос, какие инструменты он вызвал, что вернули, какой промпт был активен. Без логов трейса вы будете гадать.

• Полный трейс каждой сессии. Сохраняются все шаги: входной запрос, вызовы инструментов, ответы модели. С учётом закона о персональных данных — с маскированием того, что нельзя хранить в открытом виде.
• Быстрый откат. Новую версию промпта или модели можно вернуть назад за минуты, а не переписывая код.
• Обратная связь пользователя. Есть кнопка «ответ бесполезен» и способ разобрать такие случаи, а не просто копить их.
• Алерты. Резкий рост ошибок, задержки или расходов поднимает уведомление сам, а не ждёт жалобы клиента.

Три уровня готовности

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

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

Кому этот чек-лист нужен, а кому нет

Нужен обязательно, если агент:

• общается с внешними клиентами, а не только с сотрудниками;
• имеет доступ к деньгам, заказам, персональным данным;
• работает без человека в цепочке на каждом шаге;
• масштабируется на тысячи запросов, где стоимость и задержка становятся ощутимыми.

Можно упростить, если это внутренний инструмент для небольшой команды, который только читает данные и ничего не меняет, а пользователи — свои же сотрудники, готовые перепроверить ответ. Тут избыточная инфраструктура откладывает запуск без реальной пользы. Достаточно логов и базового набора тестов.

Опасная середина — прототип, который «временно» показали реальным клиентам и забыли, что он временный. Именно такие агенты и попадают в новости с историями про списанные не те деньги. Если внешние пользователи уже пришли — чек-лист применяется целиком, независимо от того, называли вы это релизом или нет.

Короткий финальный прогон

1. Агент физически не может сделать необратимое без подтверждения?
2. Есть набор тестов, который вы прогоняете на каждую версию?
3. Вы знаете стоимость одной задачи и потолок расходов?
4. По логам можно восстановить, что произошло в любой сессии?
5. Новую версию можно откатить за минуты?

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

¹ Агент — система на основе языковой модели, которая сама выбирает и вызывает внешние инструменты (поиск, API, действия) для выполнения задачи, а не только генерирует текст.

² RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные фрагменты из вашей базы знаний и опирается на них, снижая риск выдумок.