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

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

Почему повтор одного запроса даёт разные ответы

На ответ влияют версия модели, параметры генерации, переданный контекст, найденные документы и состояние внешних сервисов — цены, наличие товаров, доступность API. Один и тот же вопрос, заданный дважды, может закончиться разными результатами. Для стохастической модели одного прогона недостаточно: число повторов выбирают с учётом изменчивости ответов, риска сценария и стоимости проверки. Параметр seed у провайдера повышает воспроизводимость в одном окружении, но полной идентичности ответов не гарантирует.

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

Четыре аспекта одной задачи

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

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

Из чего собирают эталонный набор

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

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

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

Чем оценивают результат

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

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

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

Безопасность как отдельные сценарии

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

Промпт-инъекция — попытка изменить поведение модели инструкцией, которая приходит вместе с запросом пользователя (прямая атака) или находится на веб-странице, в письме, документе, результате поиска (косвенная). В рекомендациях OWASP среди последствий называют утечку данных, обход ограничений и несанкционированные вызовы инструментов. Red teaming проверяет, следует ли ассистент системным инструкциям при просьбе их изменить, не раскрывает ли секреты, отдаёт ли персональные данные только в пределах прав, воспринимает ли текст из документов и API как данные и запрашивает ли подтверждение перед чувствительной операцией.

Текст ответа сам по себе безопасность не обеспечивает. Приложение отдельно проверяет, имеет ли пользователь право просматривать заказ, менять данные или проводить операцию; инструментам задают минимальный набор разрешений, параметры сверяют по схемам и спискам допустимых значений. Две атаки способны сложиться в цепочку: после промпт-инъекции модель передаёт в инструмент вредоносный параметр, инструмент включает его в запрос к базе, и при небезопасной сборке SQL-запроса возникает риск SQL-инъекции.

Прогон на каждой версии

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

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

Что происходит после релиза

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

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