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

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

Для RAG-чат-бота недостаточно посчитать долю «правильных ответов». Такая система сначала ищет фрагменты в базе знаний, затем передаёт их модели, а уже модель формирует сообщение. Ошибка может появиться на любом этапе. Поэтому поиск, ответ, отказ, передачу человеку и доступ к документам нужно тестировать раздельно. Только после этого оценивается диалог целиком. Такой же принцип лежит в основе официальных руководств Microsoft и исследовательского фреймворка RAGChecker, где диагностика поиска отделена от диагностики формирования ответа.[1][2][9]

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

Сначала договоритесь, что считать правильным результатом

Фраза «бот должен отвечать точно» не годится как критерий приёмки. Она не объясняет, что делать при неполном вопросе, противоречии в документах или запросе закрытой информации.

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

• какой документ или раздел считается источником;
• какие факты обязательно должны попасть в ответ;
• что нельзя утверждать без дополнительных данных;
• нужно ли задать уточняющий вопрос;
• когда бот обязан отказаться от ответа;
• в какой момент обращение передаётся сотруднику;
• какие документы доступны конкретной роли пользователя.

Получается не «список вопросов для бота», а таблица решений. Она связывает техническую проверку с рабочим процессом.

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

Соберите тестовый набор из реальной работы, а не из удобных вопросов

Хороший тестовый набор обычно начинается с журналов обращений, истории поиска, вопросов сотрудников и ответов предметных экспертов. Для систем, которые отвечают по документам, OpenAI рекомендует сочетать производственные данные, экспертно подготовленные правильные ответы и исторические логи. В отдельном руководстве для бизнеса компания предлагает на раннем этапе просмотреть 50–100 ответов, чтобы составить классификацию ошибок.[3][4]

Число 50–100 — не норматив. Это разумный объём для первого прохода, после которого уже видны повторяющиеся проблемы. Для большого каталога, нескольких подразделений или высокорискового процесса набор потребуется расширить.

В него стоит включить разные классы запросов:

1. Обычные вопросы. Самые частые формулировки из реальной работы.
2. Перефразирования. Один смысл, выраженный разными словами, с сокращениями и опечатками.
3. Составные запросы. Два вопроса в одном сообщении или вопрос, для ответа на который нужны несколько документов.
4. Неполные запросы. Ситуации, где сначала нужно уточнить номер договора, регион, продукт или статус клиента.
5. Отрицательные примеры. Вопросы, на которые в базе нет ответа и система не должна импровизировать.
6. Конфликты и устаревшие версии. Документы с разными датами, статусами и областями применения.
7. Проверка доступа. Одинаковые вопросы от пользователей с разными ролями.
8. Редкие, но дорогие ошибки. Возврат денег, персональные данные, юридически значимое решение, остановка оборудования.

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

Проверяйте поиск отдельно от ответа

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

Нужно ответить на четыре вопроса:

• найден ли нужный документ;
• оказался ли полезный фрагмент достаточно высоко в выдаче;
• не попали ли в контекст старые или посторонние материалы;
• не получил ли пользователь доступ к запрещённому документу.

В инженерных командах для этого используют precision@K, recall@K и MRR. По-простому: precision показывает, какая доля первых найденных фрагментов действительно полезна; recall — сколько нужных материалов система не пропустила; MRR — насколько близко к началу выдачи оказался первый правильный результат.[5]

Для первого пилота необязательно строить сложную панель метрик. Достаточно таблицы:

Запрос	Ожидаемый документ	Найден в топ-3	Есть лишний контекст	Найдена старая версия	Нарушен доступ
«Какой лимит по договору?»	Действующая версия договора и регламент лимитов	да/нет	да/нет	да/нет	да/нет

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

Здесь нет универсального значения top-K — числа фрагментов, передаваемых модели. Возвращать больше фрагментов полезно для полноты, но лишний контекст добавляет шум и может увеличить задержку. Переранжирование повышает точность порядка результатов, но тоже требует времени. Выбор нужно сравнивать на одном тестовом наборе, а не принимать по примеру из документации.[5]

Затем проверяйте, что модель сделала с найденным контекстом

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

Опора на источник. Каждое проверяемое утверждение должно следовать из найденных документов. В англоязычной документации это часто называется groundedness или faithfulness.

Фактическая корректность. Ответ должен быть правильным, а не просто похожим на текст источника.

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

Релевантность. Ответ должен решать запрос пользователя без лишней справки и ухода в соседнюю тему.[2][6]

Опора на контекст и корректность — разные вещи. Чат-бот может без выдумок пересказать устаревшую инструкцию. Формально ответ будет хорошо основан на найденном документе, но для бизнеса останется неверным. Microsoft прямо рекомендует смотреть эти показатели вместе: высокий groundedness не исключает ошибочной интерпретации или проблем в исходных данных.[2]

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

Автоматическую первичную оценку можно поручить другой модели, особенно когда тестов уже сотни. Но модель-оценщик не должна сама устанавливать стандарт качества. Сначала предметные специалисты размечают часть примеров и согласуют рубрику, затем команда проверяет, насколько автоматическая оценка совпадает с человеческой. Иначе один ИИ будет уверенно подтверждать ошибки другого.[3]

Отказ и передача человеку — часть качества, а не провал

У хорошего корпоративного чат-бота есть вопросы, на которые он не отвечает. Это нормальное ограничение.

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

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

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

В опубликованном кейсе RAG-ассистента технической поддержки перед запуском отдельно проверялись качество поиска, корректность ответа, разные формулировки, эскалация, контекст для специалиста и актуальность знаний. Доля диалогов без сотрудника не использовалась как единственный критерий: система может закрывать много обращений и при этом отвечать неточно.[7]

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

Права доступа проверяются до генерации

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

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

OWASP относит слабые права доступа, непроверенные источники и отравление базы знаний к существенным рискам RAG. Среди базовых мер — разделение данных, фильтрация с учётом полномочий пользователя, проверка источников и журналирование операций поиска.[8]

Добавьте два специальных сценария:

• в доступном документе есть скрытая или явная инструкция, пытающаяся изменить поведение ассистента;
• в базу попал неутверждённый файл с правдоподобным, но неверным правилом.

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

Соберите приёмочный лист вместо одного процента

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

Контур	Что проверяем	Пример условия допуска	Владелец
Поиск	нужный и актуальный источник попадает в верхние результаты	критические документы находятся во всех обязательных сценариях	владелец базы знаний + разработчик поиска
Ответ	факты подтверждены, вопрос закрыт, нет лишних условий	в критических сценариях нет неподтверждённых утверждений	предметный эксперт
Отказ	бот не отвечает при недостатке данных	все заранее размеченные критические случаи корректно остановлены	владелец процесса
Эскалация	обращение вовремя передано человеку с контекстом	сотруднику не приходится восстанавливать диалог заново	руководитель поддержки/операций
Доступ	закрытые документы не попадают в retrieval	ни одной утечки в тестах разграничения ролей	ИБ/владелец данных
Эксплуатация	система укладывается в допустимые задержку и стоимость	значения соответствуют экономике конкретного процесса	владелец продукта

После технических условий допуска посмотрите на результат процесса: сколько ответов исправляет специалист, сколько обращений открывается повторно, как меняются время решения и стоимость обработки. Эти показатели не объясняют, где сломался RAG, зато показывают, помогает ли система бизнесу. Они дополняют проверку качества, а не усредняют критические ошибки.

Числовые пороги зависят от стоимости ошибки. Для справочного поиска внутри команды допустим один уровень риска, для финансового решения или внешней консультации — другой. Универсальный показатель «точность 90%» без состава тестов и классов ошибок почти ничего не говорит.

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

Повторяйте тест после каждого значимого изменения

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

Поэтому тестовый набор становится регрессионным: команда прогоняет его при каждом изменении и сравнивает результаты с предыдущей версией. OpenAI рекомендует запускать оценки на каждом изменении и пополнять набор примерами из реальной эксплуатации; Microsoft также рассматривает оценку RAG как повторяющийся процесс, поскольку меняются документы и вопросы пользователей.[2][3]

Журнал должен сохранять минимум:

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

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

Вывод

Тестирование чат-ботов с RAG нужно начинать не с вопроса «какую метрику выбрать», а с описания правильного решения в рабочем процессе. Затем собирается эталонный набор, отдельно проверяется поиск, после него — ответ, отказ, эскалация и доступ к данным.

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

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

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

Что обычно включает тестирование чат-бота?

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

Как проверить ответы ИИ на достоверность?

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

Как понять, что RAG находит правильные документы?

Для каждого тестового запроса заранее разметьте ожидаемые документы или фрагменты. Затем проверьте, появились ли они в первых результатах, сколько нерелевантного контекста было добавлено и не попали ли в выдачу устаревшие или закрытые материалы.

Кто должен проверять ответы чат-бота?

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

Нужно ли тестировать систему после обновления базы знаний?

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

Источники

1. Microsoft Azure Architecture Center. Design and develop a RAG solution. Обновлено 30.06.2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-solution-design-and-evaluation-guide
2. Microsoft Azure Architecture Center. Large language model end-to-end evaluation. Обновлено 21.11.2025. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-llm-evaluation-phase
3. OpenAI. Working with evals. Актуальная документация, обращение 15.07.2026. https://developers.openai.com/api/docs/guides/evals
4. OpenAI. How evals drive the next chapter in AI for businesses. 19.11.2025. https://openai.com/index/evals-drive-next-chapter-of-ai/
5. Microsoft Azure Architecture Center. Information retrieval. Обновлено 02.07.2026. https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-information-retrieval
6. Microsoft Foundry. Retrieval-Augmented Generation (RAG) evaluators. Обновлено 02.06.2026. https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators
7. ai-av.ru. Автоматизация технической поддержки: RAG и Битрикс24. Проверено 15.07.2026. https://ai-av.ru/blog/support-automation-rag-bitrix24/
8. OWASP GenAI Security Project. LLM08:2025 Vector and Embedding Weaknesses и LLM09:2025 Misinformation. https://genai.owasp.org/llmrisk/llm082025-vector-and-embedding-weaknesses/ ; https://genai.owasp.org/llmrisk/llm092025-misinformation/
9. Ru D. et al. RAGChecker: A Fine-grained Framework for Diagnosing Retrieval-Augmented Generation. 2024. https://arxiv.org/abs/2408.08067