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

Почему юнит-тестов недостаточно для ИИ-агентов

Юнит-тесты работают для традиционного кода, потому что одни и те же входные данные всегда дают одинаковый результат. «2 + 2 = 4» — это гарантия, которую можно проверить простым сравнением на равенство. Однако агент на базе LLM меняет свои ответы в зависимости от промпта, окружающего контекста и состояния любых внешних инструментов, которые он вызывает. Тест, проверяющий точное соответствие строк, пропускает галлюцинации, смену тона или нарушение защитных механизмов (guardrails). Скрытый сбой, который стоил мне клиента, показывает, что необходимо оценивать всё взаимодействие целиком, а не только отдельные функции.

Создание системы оценки перед написанием кода функций

Я изменил порядок разработки: сначала я спроектировал четырехслойную систему оценки (evaluation harness), а уже затем начал писать код агента. Система выполняет 131 тест за один проход, стоит примерно три цента за запуск и завершается примерно за одиннадцать минут. Я назначаю каждый тест самой маленькой модели, которая способна с ним справиться, резервируя более крупные и дорогие модели для тех моментов, когда они действительно приносят пользу.

Слой 1 — Функциональность инструментов

Первая линия обороны проверяет, может ли агент правильно вызывать свои инструменты. Тесты охватывают успешные поисковые запросы, намеренно некорректные запросы и симуляцию сбоев API. Поскольку использование инструментов в значительной степени детерминировано — либо запрос сформирован правильно, либо API возвращает ошибку — достаточно простых проверок (assertions) на Python. Выявление некорректного запроса на этом этапе предотвращает путаницу на последующих этапах.

Слой 2 — Следование инструкциям

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

Слой 3 — Целеориентированное поведение

Третий слой — самый критический. Он отвечает на вопрос, действительно ли агент достигает своей цели. Для бота по генерации лидов это означает подтверждение того, что он задает правильные квалифицирующие вопросы и при необходимости переводит диалог на человека. Здесь я использую модель, ориентированную на рассуждения (reasoning model), так как она может оценить общий поток диалога, не раздувая расходы. Если бот не достигает своей цели — даже если он прошел первые два слоя — он помечается для переработки.

Слой 4 — Производительность

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

Способы экономии средств

Цифра в 0,03 доллара за запуск — это не маркетинговый трюк; она получается за счет сопоставления сложности теста с размером модели. Детерминированные проверки инструментов запускаются на самом дешевом рантайме, соблюдение инструкций проверяется легкой моделью, и только целеориентированные оценки задействуют более мощную, хотя и более дорогую модель. Такой многоуровневый подход позволяет держать общие расходы достаточно низкими, чтобы запускать полный набор тестов при каждом изменении кода.

Компромисс: скорость против безопасности

Внедрение системы оценки добавило трения на начальном этапе. Циклы разработки растянулись, а сроки запуска сдвинулись.

На что обратить внимание в будущем

  • Оценщики на базе моделей: по мере совершенствования LLM, оценщик на Слое 2 сможет стать более нюансированным, что позволит сократить количество ложноположительных результатов, по-прежнему выявляя тонкие нарушения политик.

Главный вывод

Если вы создаете ИИ-агентов для продакшна, многослойная система оценки не является опциональной — она фундаментальна. Перенося затраты на комплексное тестирование на ранние этапы (0,03 доллара за запуск, одиннадцать минут на весь набор), вы защищаете себя от скрытых сбоев, которые юнит-тесты просто не способны обнаружить.