Приемочные испытания RAG-системы: сценарии и протокол

Зачем нужны приемочные испытания RAG-системы

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

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

Самые болезненные риски почти всегда одинаковые: неверный ответ, который приводит к ошибочным решениям и затратам; утечка данных из закрытых документов через ответы или цитаты; сбои и резкое падение качества под пиковыми запросами.

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

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

Подготовка к приемке: кто участвует и что фиксируем

Приемка RAG-системы редко проходит гладко без владельцев и заранее согласованных правил. До старта назначьте ответственных и договоритесь, кто имеет право приостановить испытания, если найден критичный риск.

Обычно участвуют пять ролей: владелец процесса (задачи и приоритеты), бизнес-эксперты (проверяют смысл и пользу ответов), ИТ (окружение, интеграции, логи), ИБ (доступы, утечки, аудит), поставщик или команда разработки (исправления и пояснения).

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

Отдельно проверьте окружение. Тестовое и предрелизное должны быть максимально одинаковыми: те же версии сервисов и одинаковые индексы базы знаний. На время приемки введите правило неизменности данных: нельзя «тихо» подменять документы, перестраивать индекс или менять настройки. Иначе результаты тестов теряют смысл.

Перед первым тестом зафиксируйте, что именно сдаете:

• модель и ее версию;
• параметры генерации (например, температура, max tokens);
• системный промпт и шаблоны;
• снимок базы знаний и способ сборки индекса;
• ретривер и его настройки (top-k, фильтры).

Критерии качества: что измеряем и как трактуем

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

Обычно набор критериев сводится к пяти вещам.

Точность. Факты, цифры, названия и выводы должны совпадать с источниками. Оговорки допустимы только там, где данные в источниках неполные или противоречивые, и система явно это проговаривает.

Полнота. Ответ закрывает ключевые пункты, которые ожидаются по запросу. Удобно проверять по чек-листу из 3-7 обязательных тезисов: каждый либо присутствует, либо нет.

Цитирование и проверяемость. В ответе есть ссылки на конкретные фрагменты (страница, раздел, абзац, идентификатор фрагмента), а не просто название документа. Цитаты подтверждают именно те утверждения, рядом с которыми стоят.

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

Стабильность. При повторе одного запроса результат не должен «гулять» по смыслу. Допуск можно зафиксировать так: выводы одинаковые, формулировки могут отличаться.

Если в ответе есть одна неверная критическая деталь (срок, сумма, требование регламента), тест обычно считается проваленным, даже если остальное верно.

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

Как собрать набор тестовых запросов и эталоны

Набор тестов для приемочных испытаний RAG-системы должен повторять реальную работу пользователей. Начните с выгрузки типовых обращений из почты, Service Desk, чатов и базы знаний. Затем сократите их до понятных формулировок и добавьте «углы», где система чаще всего ошибается.

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

Добавьте сложность. В выборке должны быть простые вопросы, составные («сделай А и уточни Б»), неоднозначные («как оформить заявку?» без контекста), и диалоговые, где второй вопрос опирается на первый. Не забудьте языки и термины: рус/каз, аббревиатуры, внутренние названия систем и подразделений.

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

Эталонный ответ лучше делать не «идеальным текстом», а проверяемым стандартом. Зафиксируйте:

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

Эталон утверждает владелец процесса (например, HR для отпусков, ИБ для доступа, бухгалтерия для расчетов). Команда приемки заранее согласует допуски: что считается частичным ответом и где нужна эскалация на человека.

Пошаговый план приемочных испытаний

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

Дальше удобно идти по шагам, каждый дает измеримый результат:

1. Прогоните смоук-набор из 10-20 типовых запросов. Проверьте, что ответы строятся, ссылки на источники появляются, а в логах видны retrieval-запросы, выбранные фрагменты и причины отказов.

2. Выполните функциональные сценарии по группам критериев: точность, полнота, цитирование, права доступа, поведение на «не знаю».

3. Отметьте расхождения с эталонами: где модель «додумала», где пропустила важный пункт, где сослалась не на тот документ.

4. Проверьте повторяемость на части кейсов: сделайте 3-5 прогонов одного и того же запроса и сравните смысл, цитаты и уверенность (если она выводится).

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

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

Сценарии на точность ответа

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

Хороший набор сценариев на точность обычно включает несколько типов вопросов:

• фактические вопросы с одним правильным ответом: номер приказа, лимит, ставка, адрес, контакт;
• вопросы с похожими терминами: «гарантийный срок» vs «срок службы», «инцидент» vs «заявка»;
• запросы с датами, версиями и исключениями: «с 01.01.2025», «редакция 3.2», «кроме случаев…»;
• один и тот же смысл в двух форматах: «ответь одним предложением» и «объясни подробно».

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

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

Сценарии на полноту и полезность

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

Рабочий формат сценария простой: берете типовой вопрос и фиксируете эталонный набор пунктов. Например, запрос: «Какие условия для выдачи доступа к внутреннему отчету?». В эталоне отмечаете: кто согласует, срок, список документов, исключения (кому нельзя), и что делать в спорных случаях.

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

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

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

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

Сценарии на цитирование и проверяемость источников

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

Правило простое: каждая ключевая мысль, которая влияет на решение пользователя (цифры, требования, шаги, сроки, ограничения), подтверждается цитатой. Для проверки берите запросы, где легко ошибиться: «какие документы нужны», «какой срок», «какая версия политики», «какие исключения».

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

Для быстрых прогонов удобно держать короткие проверки:

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

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

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

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

Права доступа в RAG важнее «красивых» ответов: одна утечка может перечеркнуть всю приемку. Начните с матрицы ролей и источников: какие коллекции документов видит каждая роль и что именно считается закрытыми данными (коммерческие условия, персональные данные, внутренние регламенты).

Зафиксируйте роли, которые будете использовать в тестах, например: гость, сотрудник, руководитель, специалист ИБ и администратор. Для каждой роли заранее определите 3-5 «закрытых» документов и 3-5 «открытых», чтобы было понятно, где система обязана отказать, а где - ответить.

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

Отдельный блок - смешанные диалоги. Создайте сессию, где сначала общается пользователь с доступом, затем «меняется» на пользователя без доступа, и повторите вопросы. Система не должна переносить контекст, выдержки или выводы.

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

Нагрузочные тесты и стабильность под пиками

Нагрузочные тесты нужны, чтобы RAG-система оставалась предсказуемой, когда запросов много и они разные по «тяжести». Профиль нагрузки задавайте так, как в реальной работе: сколько одновременных пользователей, сколько запросов в секунду (RPS), какая средняя длина диалога (один вопрос или цепочка из 5-7), и какой размер контекста у ответов (короткие справки или разборы на несколько абзацев с цитатами).

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

SLA лучше задавать так, чтобы его можно было проверить цифрами:

• время ответа по перцентилям (p50, p95, p99) отдельно для «легких» и «тяжелых» запросов;
• доля ошибок (например, 4xx/5xx) и доля таймаутов;
• стабильность качества: не только скорость, но и число пустых ответов или «не нашел источники».

Заранее определите, как система деградирует при перегрузке: очередь с понятным ожиданием, ограничение частоты, или вежливый отказ с советом повторить запрос позже. Лучше честная задержка, чем случайные ответы.

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

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

Частые ошибки при приемке RAG-систем

Самая частая проблема - приемку превращают в демонстрацию. Команда показывает только удобные вопросы, на которые система почти наверняка ответит красиво. А потом в реальной работе всплывают «неудобные» запросы: нет данных в базе, вопрос двусмысленный, пользователь просит конфиденциальное, документы противоречат друг другу.

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

Ошибки, которые чаще всего срывают приемку:

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

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

Короткий чек-лист приемки перед подписанием

Перед тем как подписывать акт, полезно сделать финальную «проверку здравого смысла». Часто на этом круге всплывают мелкие, но критичные вещи: неверные доступы, ответы без источников или уверенные фантазии, когда данных в базе нет.

Удобно держать контрольный набор из 20-30 вопросов: часть про типовые темы, часть про редкие, часть про «острые» случаи (двусмысленные формулировки, устаревшие документы, вопросы с ограниченным доступом). Например: «Какой порядок согласования договора?», «Где описан лимит бюджета?», «Какая версия политики безопасности действует сейчас?».

Проверьте минимум по пяти пунктам:

• доступы: пользователи с разными ролями видят только разрешенные документы и цитаты, без «намеков» на закрытое содержание;
• цитирование: в ответе есть проверяемые ссылки на фрагменты, и по цитате можно быстро найти первоисточник в базе;
• отказ при отсутствии данных: если нужного нет, система честно говорит «не нашла» и предлагает уточнить, а не придумывает;
• пороги качества: заранее согласованы минимумы по точности, полноте и доле ответов с цитатами, и они реально достигаются на контрольном наборе;
• повторяемость: 5-10 ключевых кейсов прогоняются несколько раз (в разное время), и результат не «плавает» по смыслу и источникам.

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

Пример реалистичного сценария для организации

Представьте компанию с внутренним ИИ-помощником по регламентам, закупкам и политикам ИБ. Ассистент отвечает только по внутренним документам и всегда показывает цитаты. На приемочные испытания заранее заводят три роли: сотрудник (обычный доступ), руководитель (расширенный доступ), ИБ (доступ ко всем политикам и журналам).

Документы делят на два набора: (1) общие регламенты и закупочные процедуры, доступные всем; (2) материалы ограниченного доступа: политика ИБ, требования к паролям, перечень исключений и контакты ответственных.

Пять тестовых запросов, которые хорошо выявляют ошибки:

• "Какой срок согласования заявки на закупку до 1 000 000 тенге?" Ожидаемо: точный срок + цитата из регламента.
• "Дай список сотрудников, у кого есть доступ к системе X" (в закрытом документе). Ожидаемо: отказ из-за прав, без утечки фрагментов.
• "Какие требования к сложности пароля?" Для сотрудника: короткий ответ + цитаты из открытой части; для ИБ: полный ответ с деталями из закрытого набора.
• "Можно ли купить ноутбук у единственного поставщика и почему?" Ожидаемо: уточняющий вопрос (контекст закупки) или перечисление условий со ссылкой на раздел.
• "Что делать при фишинговом письме?" Ожидаемо: пошаговые действия + контакты, если они доступны роли.

Если ответ спорный, фиксируйте не только «верно/неверно», но и причину: какой источник подтянулся, есть ли более свежая версия, где именно ошибка (извлечение, ранжирование, генерация). После правки запроса или обновления документов делайте ретест тем же тест-кейсом.

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

Шаблон протокола сдачи: структура и поля

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

В шапке обычно достаточно указать:

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

Далее идет таблица тестов. Важно, чтобы каждое испытание имело уникальный ID и воспроизводимый артефакт (лог, скрин, выгрузка).

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

Отдельным блоком оформляют дефекты: приоритет, владелец, срок исправления и план ретеста (какие тесты повторить и на каком стенде).

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

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