Агент против агента: новая модель QA

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

Когда у вас обычный код, тесты пишет человек: входы конечны, поведение детерминировано, сотни случаев покрывают почти всё. С диалоговым агентом так не выходит. Пространство того, что может сказать живой клиент, практически бесконечно, а каждый прогон у LLM идёт чуть иначе. Человек физически не способен проверить достаточно. Поэтому в QA диалоговых систем происходит сдвиг: тестировщиком становится не человек, а другой агент.

Гипотеза: тестировщик диалогового агента — это другой агент

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

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

Проблема: ручное QA не масштабируется, а простой автотест не ловит главное

У команды, которая это осознала, обычно два неудачных подхода за плечами.

Первый — ручное тестирование. QA-инженер садится и гоняет диалоги руками. Подход честный, но упирается в две стены. Стена объёма: десятки проверенных диалогов против тысяч нужных — это не покрытие, а выборка, в которую редкие сбои просто не попадают. Стена воспроизводимости: человек не повторит один и тот же диалог дважды одинаково, а из-за недетерминизма LLM один прогон ничего не доказывает — нужна статистика по многим повторам одного давления.

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

Оба подхода — это попытка проверять диалоговую систему инструментами для статичного кода. Диалог — процесс, а не функция; его и проверять нужно процессом.

Почему обычные подходы не работают

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

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

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

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

Инженерная модель: Симулятор клиента → Целевой агент → Судья

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

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

Целевой агент. Тот самый, что пойдёт к клиентам, в полной проде-комплектации: те же инструменты, те же ограничения, тот же стек. Никаких облегчённых версий — иначе контур врёт.

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

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

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

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

Практический вывод для бизнеса

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

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

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

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

Открытые вопросы

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

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

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

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