Тестирование и оценка ИИ-агентов

«Агент прошёл тесты» и «агент работает» — это не одно и то же. Большинство диалоговых ИИ-агентов проходят свои тесты и проваливаются на живых людях, потому что тесты пишут те, кто знает систему, и неосознанно ей помогают. Реальный пользователь не помогает почти никогда. Мы тестируем ИИ-агентов, чат-ботов и LLM так, как их ломает реальность, — и считаем зрелость не числом зелёных прогонов, а качеством красных, которые система уже пережила.

Почему «зелёные тесты» не значат рабочий агент

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

Red team для диалогового ИИ

Чтобы проверка была честной, нужен контур, заинтересованный не в зелёном, а в красном. Разработчик на это неспособен по построению: он тестирует свои ожидания. Нужен независимый агент-оппонент, цель которого — доказать, что агент не работает: запутать, увести, поймать на противоречии, заставить выдумать ответ. Это та же логика, что у пентестеров в безопасности, перенесённая на разговорный ИИ. «AI red team» — уже не экзотика, а отдельная инженерная дисциплина, и для диалоговых систем она нужна не меньше, чем для инфраструктуры.

Агент против агента: симулятор клиента, который хочет сломать

Лучший тестировщик диалогового агента — не человек, а другой агент. Архитектура простая: симулятор клиента ведёт диалог с целевым агентом, а третий, судья, оценивает исход. Ключевой момент — задача симулятора: не «помочь пройти тест», а максимально затруднить достижение цели. Обычные LLM плохо играют клиента: через пару реплик они начинают отвечать по существу и помогать. Поэтому симулятору задают модели поведения, которых не хватает наивному тесту, — тревожный, конфликтный, забывчивый, подозрительный, импульсивный, скучающий. Это и есть мультиагентная проверка, применённая к качеству.

Метрики, которые реально отражают качество диалога

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

Галлюцинации и недостоверный вход

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

Тестирование на реальных диалогах, а не на синтетике

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

Где это решает деньги и риск

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

Почему так, а не «прогнали сценарии — зелено»

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

Глубже по теме

• GREEN bias: как среды разработки фальсифицируют качество ИИ-агентов
• RED-driven development: зрелость ИИ-агента — в красных тестах
• Красная команда для диалогового ИИ
• Агент против агента: новая модель QA
• Бот, который проходит все тесты и не продаёт
• Почему чат-бот — это не ИИ-архитектура
• RAG: где помогает, а где создаёт иллюзию знания
• Проблемы мультиагентных систем и как их избегать
• Корпоративные чат-боты и операционные ИИ-агенты · Инженерные кейсы