Тестирование чат-ботов с ИИ: как проверить RAG до запуска

На демонстрации всё обычно выглядит убедительно. Команда задаёт чат-боту пять знакомых вопросов. Он находит документы, формулирует аккуратные ответы, показывает ссылки. Можно запускать.

А потом приходит реальный пользователь и пишет что-то вроде: «В договоре один лимит, но есть более новое дополнительное соглашение. Какой действует сейчас?»

Бот находит старую версию, уверенно отвечает и даже прикладывает источник.

Демонстрация не обманула. Она просто проверяла не то.

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

Моя позиция простая: принимать RAG-систему нужно по отдельным контурам и по блокирующим ошибкам. Средний балл здесь полезен, но сам по себе почти ничего не решает.

Фраза «чат-бот должен отвечать точно» не является критерием приёмки.

Она не объясняет, что должен сделать бот, если:

До тестов владелец процесса и предметный эксперт должны описать ожидаемое поведение системы. Для каждого типа запроса я бы фиксировал пять вещей:

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

То есть нужен не список «вопрос — красивый ответ», а таблица решений.

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

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

По каждому тестовому вопросу проверьте:

И вот здесь часто выясняется, что проблема вообще не в промпте.

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

Для инженерной оценки поиска используют precision@K, recall@K и MRR:

Microsoft рекомендует оценивать этапы RAG раздельно и прямо относит эти метрики к проверке retrieval — поиска и извлечения контекста.[2][3]

Но для первого пилота необязательно начинать со сложной аналитической панели. Часто достаточно отчёта с шестью колонками:

Запрос → ожидаемый документ → найден в топ-3 → есть лишний контекст → найдена старая версия → нарушен доступ.

Такой отчёт даёт больше пользы, чем один общий показатель точности, потому что сразу показывает направление исправления.

Когда поиск стабильно возвращает правильные материалы, можно подключать генерацию. Проверка ответов ИИ на этом этапе должна идти по отдельным утверждениям, а не по общему впечатлению от текста.

Я разделяю здесь четыре свойства.

Опора на источник. Каждое проверяемое утверждение следует из найденных документов.

Фактическая корректность. Утверждение действительно верно для конкретной ситуации.

Полнота. Ответ закрывает все существенные части вопроса.

Релевантность. В сообщении нет лишней справки, которая мешает принять решение.

Опора на источник и правильность — не одно и то же.

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

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

Когда тестов становятся сотни, первичную оценку можно поручить другой модели. Но модель-оценщик не должна сама придумывать стандарт качества. Ей нужна рубрика, подготовленная предметными экспертами, и регулярная сверка с человеческой разметкой. В документации OpenAI тестовый набор строится на репрезентативных данных и эталонных метках, заданных человеком.[4]

Иначе один ИИ будет уверенно подтверждать ошибки другого.

У корпоративного ассистента обязательно должны быть вопросы, на которые он не даёт самостоятельный ответ.

Это не недостаток. Это граница полномочий.

Отдельно проверьте сценарии, где:

Для каждого случая заранее задайте правильный исход: уточняющий вопрос, безопасный отказ или передача сотруднику.

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

Поэтому я не считаю сам факт эскалации провалом теста.

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

Инструкция в промпте «не показывай конфиденциальные данные» не является системой разграничения доступа.

Если закрытый документ уже попал в контекст языковой модели, защита построена неправильно. Проверка полномочий должна сработать на этапе поиска.

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

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

Поэтому в тестовый набор стоит добавить ещё два класса примеров:

Содержимое документа для RAG — это данные, а не команда. Сама база знаний для чат-бота должна быть управляемой: у каждого источника нужны владелец, статус, дата актуализации и перечень ролей, которым он доступен.

Руководителю всё равно нужен понятный ответ: запускать систему или нет.

Но лучше сформулировать его не как «точность выше 90%», а как набор обязательных условий.

Например:

У каждого условия должен быть владелец. За поиск отвечает не тот же человек, который утверждает бизнес-правила. Права доступа нельзя оставлять на усмотрение автора промпта. Границы эскалации должен принять владелец процесса, а не только разработчик.

Среднее значение может скрыть дорогую ошибку. Система способна хорошо отвечать на сотни обычных вопросов и один раз раскрыть закрытый документ. Или уверенно назвать неверный финансовый лимит. В таких сценариях «средняя точность» не спасает: ошибка должна блокировать запуск независимо от остальных результатов.

После технической приёмки добавьте показатели самого процесса:

Технические метрики показывают, где сломалась система. Процессные — имеет ли смысл её эксплуатация.

После релиза RAG-система продолжает меняться. Обновляются документы, настройки поиска, модель эмбеддингов, промпт, языковая модель и права доступа.

Любое изменение может исправить один сценарий и сломать другой.

Поэтому тестовый набор нужно превратить в регрессионный. Прогонять его после каждого значимого изменения и сохранять:

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

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

Минимальный рабочий комплект выглядит так:

Уже на этом этапе становится видно, готова ли компания принимать систему осмысленно или пока оценивает её по впечатлению от демонстрации.

Тестирование чат-ботов с RAG начинается не с выбора «самой правильной» метрики. Оно начинается с описания рабочего процесса, стоимости ошибки и решения, которое система имеет право принять.

А дальше порядок простой:

поиск → источник → ответ → отказ → передача человеку → доступ → результат процесса.

Какой критерий вы считаете главным для корпоративного чат-бота: максимальную долю автономных ответов или минимальное количество опасных ошибок?

Мой ТГ канал о разработке с ИИ

Мой сайт и блог.