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

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

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

Гипотеза: источник истины — реальные диалоги, а не выдуманные сценарии

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

Из этого следует простое, но неудобное правило. Если вы хотите знать, как агент поведёт себя с клиентами, тестируйте его на том, как клиенты уже разговаривали с вами. Всё остальное — проверка гипотезы команды о клиенте, а не проверка агента.

Проблема: синтетика даёт зелёный отчёт и слепые зоны

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

Дальше включается опасный механизм. Отчёт зелёный, тестов много, метрика покрытия высокая — и менеджмент читает это как «агент готов». Но покрытие здесь обманчиво: покрыты выдуманные ветки, а не реальные. Агент уходит в прод с целыми пластами непроверенного поведения, и эти пласты находит не команда, а клиент — в момент, когда уже поздно. Это тот же разрыв между демо и продом, о котором мы пишем в GREEN bias: красивый отчёт о качестве при плохом качестве в реальности.

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

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

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

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

Инженерная модель: корпус живых диалогов как тестовый актив

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

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

Второе — разметить. Сырой диалог сам по себе ещё не тест: нужно зафиксировать, чем разговор должен был закончиться (клиент оформил заказ, получил точный ответ, был корректно переведён на человека) и где в реальном диалоге была трудность — возражение, смена темы, противоречие в данных. Разметка превращает архив переписок в набор проверяемых исходов.

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

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

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

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

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

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

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

Собрать корпус и проверить на нём вашего агента — обсудить с инженером → .

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

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

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