ИИ-агенты для тестирования ботов: прототип из трёх ролей собрали за день, но 20% ошибок пока остаются

Никита Хробостов, тестировщик диалоговых систем в компании Just AI, 3 июня 2025 года опубликовал на Хабре подробный разбор того, как он дважды пытался заменить ручное тестирование чат-ботов и голосовых ботов агентной (agentic, когда ИИ сам принимает решения по ходу задачи) системой из трёх ролей.

Материал ценен тем, что написан практиком из российской компании, с реальными цифрами по трудозатратам, с описанием провалов и с конкретными ограничениями отечественного визуального редактора «Холст» (Holst). Для всех, кто работает с ботами или думает об автоматизации QA, это готовый чертёж: что уже летает, а что пока нет.

Три агента вместо пятидесяти звонков вручную

Суть проблемы: чтобы проверить один сценарий голосового бота в Just AI, тестировщику нужно от 40 до 100 с лишним звонков, а тест-кейсов (отдельных проверок) в два-четыре раза больше. На полную проверку одного небольшого сценария уходит 5-6 часов. На проекте голосового бота у команды 13 активных сценариев.

Человек, который прогоняет пятидесятый тест-кейс за день, начинает говорить шаблонно. А реальный пользователь говорит иначе, и именно на естественной речи NLU-часть (модуль понимания языка, который распознаёт намерение пользователя) ломается чаще всего. Эти баги проще всего пропустить.

Что нового?

• Архитектура из трёх ИИ-агентов. Первый агент генерирует тест-кейсы из JSON-схемы диалога. Второй ведёт диалог с ботом, изображая пользователя. Третий оценивает результат как «судья».
• Четыре режима поведения тестировщика. Согласный клиент (проходит сценарий до конца), негативный клиент (ругается, просит не звонить), «шум» (обрывки фраз, посторонняя речь, вопрос не по теме) и прогон заранее написанных кейсов.
• Режим «шум» оказался полезнее всего. Именно такие входные данные приходят от реальных пользователей: обрывки фраз, плохое распознавание речи, неожиданный вопрос посреди оформления заявки.
• Парсинг схем из «Холста» работает на 80%. Автор собрал цепочку: выгрузка в PDF с разбивкой на фреймы, конвертация в PPTX (где схема разбирается на текстовые блоки, фигуры и стрелки), затем передача в LLM (большую языковую модель) с промптом. Оставшиеся 20% ошибок пока дают ложные падения тестов.
• Данные остаются внутри. Схемы диалогов содержат внутреннюю информацию о логике продакшен-бота, иногда с номерами и деталями бизнес-процессов клиента. Поэтому автор использует только внутренние или локальные LLM и конвертеры.

Почему первая попытка провалилась?

Изначально Хробостов хотел сделать очевидное: взять схему диалога, сгенерировать тест-кейсы и прогнать агента строго по ним. Блокер возник на первом шаге: парсинг (извлечение структуры) визуального дизайна из «Холста».

«Холст» выгружает схемы только в PDF, JPG или SVG. По сути это картинка. OCR (оптическое распознавание текста) давал слишком много ошибок и путал связи между узлами: стрелка, приписанная не тому состоянию, превращается в тест, который проверяет не то, что нужно. Разбирать такие ошибки вручную оказалось дороже, чем тестировать руками.

Задача нормального парсинга дизайна оказалась больше, чем задача сделать самого агента. Автор отложил идею на несколько месяцев.

Как попробовать ИИ-агенты для тестирования в своём проекте?

1. Получите машинную структуру из визуальной схемы. Если ваш редактор (как «Холст») отдаёт только картинку, попробуйте цепочку Хробостова: PDF с разбивкой на фреймы, конвертация в PPTX, затем передача в LLM с примером нужного JSON-формата. Используйте локальную или внутреннюю LLM, если схемы содержат коммерческую информацию.
2. Соберите три роли агентов. Генератор тест-кейсов из JSON, тестировщик с несколькими режимами поведения (минимум «согласный клиент» и «шум»), судья для оценки результатов.
3. Начните с режима «шум». По опыту автора, именно он находит баги, которые пропускает человек после десятков однотипных прогонов.
4. Заложите ручную проверку результатов. Прототип уже находит баги, но парсинг на 80% точности означает, что часть «падений» будет ложной. Пока это инструмент для помощи тестировщику, не для полной замены.

Есть ли аналоги в России?

Публикация Хробостова описывает внутренний проект Just AI, а не коммерческий продукт. Готовых российских платформ для агентного тестирования диалоговых ботов на момент публикации автор не называет.

Для самостоятельной сборки подобной системы в РФ можно использовать YandexGPT или GigaChat как LLM-часть цепочки. Автор подчёркивает требование хранить схемы локально, что совпадает с типичными требованиями российских компаний к обработке данных. При выборе LLM для парсинга схем и генерации тест-кейсов важно, чтобы модель работала на внутренней инфраструктуре.

Частые вопросы

ИИ-агенты полностью заменят тестировщиков ботов?

Пока нет. Автор прямо пишет, что прототип уже находит баги, но парсинг схем даёт 80% точности. Оставшиеся 20% ошибок создают ложные падения, которые всё равно нужно разбирать вручную. Это инструмент усиления, а не замены: агент берёт на себя рутинные прогоны, человек разбирает сложные случаи.

Можно ли использовать эту систему, не отправляя данные наружу?

Да, и автор настаивает на этом. Схемы диалогов содержат внутреннюю информацию о логике бота и данные клиентов. Хробостов использует только внутренние или локальные LLM и конвертеры. Для российских компаний это совпадает с требованиями по хранению данных на территории РФ.

Какой режим ИИ-агента самый полезный для поиска багов?

Режим «шум». Агент в случайный момент начинает говорить нелогичный текст или задаёт неожиданный вопрос. Это имитирует реальные условия: посторонняя речь рядом с телефоном, плохое распознавание, вопрос не по теме посреди оформления заявки. Именно на таких входных данных NLU-часть бота ломается чаще всего, и именно эти баги тестировщик пропускает при ручном прогоне.