Почему красивого ответа недостаточно

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

OWASP относит избыточную агентность к ключевым рискам LLM-приложений. Корень проблемы обычно не в одном плохом промпте, а в лишней функциональности, чрезмерных правах или слишком большой автономии. Значит, до подключения к боевым системам нужно проверять не только финальную фразу, но и весь маршрут действий.

Три уровня проверки агента

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

1. Отдельный шаг

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

Этот тест быстрый и хорошо ловит лишние инструменты, неверные идентификаторы, отсутствующие обязательные поля и попытки выйти за разрешённую область.

2. Траектория

Проверяем последовательность действий. Один и тот же результат иногда достигается несколькими правильными маршрутами, поэтому не всегда нужен буквальный список вызовов. Важно задать обязательные и запрещённые свойства:

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

Траектория показывает ошибки, которые скрывает хороший финальный текст. Агент мог сообщить «письмо подготовлено», хотя уже успел его отправить.

3. Итог задачи

Проверяем бизнес-результат: нужная карточка обновлена, текст соответствует исходным данным, запрещённых изменений нет, человек получил понятный запрос на согласование. Здесь нужны детерминированные правила и выборочная экспертная оценка, а не только другая LLM в роли судьи.

Архитектура испытательного полигона

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

Версионированный сценарий

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

Без версий сравнение превращается в спор «вчера вроде работало». С ними можно понять, что сломалось после смены модели или добавления поля в CRM.

Двойники внешних систем

Для каждого опасного интеграционного действия создаётся тестовый адаптер с тем же контрактом:

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

Документация LangChain показывает похожий принцип: модель можно заменить управляемой имитацией, а реальную операцию возврата средств — тестовой функцией. Это делает проверки быстрыми, повторяемыми и не требующими боевых ключей.

Политический шлюз действий

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

Журнал побочных эффектов

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

Трасса рассуждаемых действий

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

Набор проверок

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

Какие сценарии положить в набор

Начните с 30–50 сценариев одного процесса. Половина должна описывать обычную работу, остальное — границы и сбои.

  • Нормальный запрос с полными данными.
  • Два клиента с похожими именами.
  • Отсутствующее обязательное поле.
  • Запрос пользователя без нужного права.
  • Инструкция внутри письма или документа, пытающаяся изменить правила агента.
  • Тайм-аут после успешной записи: агент не должен создавать дубль.
  • Частичная ошибка, когда CRM обновилась, а письмо не создалось.
  • Отказ человека от согласования.
  • Попытка вызвать неразрешённый инструмент.
  • Слишком большая сумма или слишком широкий список получателей.
  • Неожиданный формат ответа внешней системы.
  • Повтор того же запроса с прежним идемпотентным ключом.

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

Как приготовить реалистичные тестовые данные

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

Критические свойства данных:

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

Метрики, которые понятны бизнесу

Одна доля успешных ответов скрывает слишком много. Для агента полезнее панель из нескольких показателей:

  • доля сценариев с правильным итоговым состоянием;
  • частота выбора неверного инструмента;
  • доля недопустимых аргументов;
  • попытки действия без нужного согласования;
  • дубли побочных эффектов;
  • доля корректных отказов при нехватке данных или прав;
  • восстановление после тайм-аута и частичной ошибки;
  • стоимость и время одного успешно завершённого сценария;
  • число шагов до результата и доля бесполезных вызовов.

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

Локальный контур не отменяет проверку

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

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

Экономика тестового контура

Основные расходы — не токены, а подготовка сценариев, двойников API и критериев правильности. Зато этот набор используется повторно при каждой смене модели и промпта. Чем больше у агента инструментов и побочных эффектов, тем дороже обходиться без регрессии.

Для пилота считайте:

  • часы эксперта на создание и разбор сценариев;
  • разработку безопасных адаптеров;
  • вычисления на число повторов;
  • стоимость найденных до запуска ошибок;
  • время на проверку новой версии.

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

План внедрения на две недели

1. Выберите один агентный процесс и перечислите все реальные побочные эффекты.
2. Оставьте минимальный набор инструментов и прав.
3. Создайте двойники CRM, почты или ERP с теми же схемами команд.
4. Опишите 30–50 сценариев, включая сбои и попытки обхода правил.
5. Добавьте детерминированные проверки траектории и финального состояния.
6. Запустите несколько повторов каждой версии модели: поведение недетерминировано.
7. Разберите все опасные ошибки до теневого запуска на реальных данных.

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

Практический вывод

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

Первый полезный артефакт — не универсальная платформа, а 30–50 воспроизводимых сценариев одного процесса. Если новая версия проходит их без запрещённых действий и дублей, её можно переводить в теневой режим. Если нет, Внутрик остаётся в лаборатории и продолжает сортировать картонные письма — безопасно и с энтузиазмом.