Агент уже работал.
Мы проверили, можно ли ему верить

Не разработка,
а независимая проверка

Агент у клиента уже работал: читает новое письмо, классифицирует его (заявка / не заявка) и, если это заявка — извлекает структурированные данные и отправляет уведомление менеджеру в Telegram через n8n. RITMA не разрабатывала этого агента с нуля, а построила вокруг него процесс тестирования и мониторинга — по модели «внешний QA/AI-reliability подрядчик, который не трогает прод, но систематически проверяет качество и ловит регрессии».

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

Тестирование —
это не разовый прогон

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

Найденный баг — ложные заявки от текущих клиентов

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

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

После добавления в промпт явных исключений для существующих клиентов метрика is_correct на контрольном датасете выросла с 0.87 до 1.00, а найденный false positive на реальном трафике закрылся полностью.

Оптимизация модели — скорость без потери качества

Отдельный эксперимент сравнил полную модель yandexgpt и облегчённую yandexgpt-lite на том же датасете из 18 кейсов и промпте v2_fix_support.

Метрики качества идентичны, латентность ниже почти вдвое — прод переключили на yandexgpt-lite, а риск деградации на более разнообразном реальном трафике приняли осознанно, под контролем прод-мониторинга, а не заблокировали до «идеального» тестирования.

Тестирование
вскрыло не только баги

Кроме находок в логике классификации, тестирование выявило и операционные пробелы вокруг агента: он не переживал падение SSH-сессии — перевели на systemd-сервис с автозапуском; промпт был захардкожен в коде — вынесли в файлы с версионированием; не было логирования на уровне отдельного письма — добавили построчный JSONL-лог решений; не было разделения биллинга — завели отдельный каталог под проект, чтобы расход был виден отдельной строкой.

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