Evaluation set для RAG: как собрать вопросы, ответы и источники

RAG-систему нельзя принимать потому, что один ответ звучит убедительно. Полезный evaluation set делает ожидаемое поведение проверяемым: какой задан вопрос, какие источники разрешены, какие claims ожидаются, когда нужно уточнение, а когда — отказ или передача человеку. Так «в демо стало лучше» превращается в воспроизводимую инженерную проверку.

В статье описан EVALSET-10 — компактный контракт оценки document-grounded ассистента. Это не отчёт о клиентском внедрении, не рейтинг моделей и не универсальный порог. Публичный fixture намеренно мал и синтетичен: его метод, ограничения и ожидаемые маршруты можно прочитать до того, как команда применит тот же паттерн к своим разрешённым документам.

Начните с решений, которые ассистент вправе принять

Evaluation row — не просто prompt и удачная строка ответа. Он фиксирует границу решения. Для policy-ассистента корректный row проверяет, позволяет ли актуальная policy дать конкретный ответ; для safety-сценария — требует escalation; для access-control — ожидает deny ещё до retrieval. В первом release разделите маршруты:

1. Ответ с citation: evidence актуальны, разрешены и достаточны для ограниченного claim.
2. Уточнение: отсутствуют существенные ID, role, locale, version или scope.
3. No-answer: разрешённый corpus не доказывает claim.
4. Deny: identity или policy не позволяют получить source или ответ.
5. Human review: вопрос неоднозначен, consequential или конфликтует с evidence.

Широкая задача внедрения принадлежит странице RAG-систем. Эта статья уже: она показывает, как одно поведение RAG становится versioned и reviewable тестом. Для более широкого разговора о scope проекта используйте /ru/ai-specialist-armenia.

Минимальная форма evaluation case

Каждый case должен сохранять identity, provenance и ожидаемый маршрут. Не копируйте приватный текст документа в benchmark только ради удобства. Храните durable source ID и открываемый locator для авторизованного reviewer; перед выходом из approved environment редактируйте fixture.

Метрики полезны только после такого контракта. Ragas описывает, в частности, context precision, faithfulness и answer accuracy; применяйте их как инструмент реализации, а не замену owner и границы бизнес-риска. Руководство NIST AI RMF также требует документированных и повторяемых процессов test, evaluation, verification и validation. Метрики Ragas и NIST AI RMF проверены 2026-09-11.

Оригинальное доказательство: публичный fixture EVALSET-10

JSON fixture EVALSET-10 содержит двенадцать синтетических cases: пять обычных ответов с citations, два случая change source, два no-answer, один access denial, одно уточнение из-за ambiguity и один маршрут human review. В нём нет клиентских документов, customer outputs, model score или сравнения vendors.

Запускайте его на известной конфигурации и фиксируйте model, prompt, embedding/index version, retrieval parameters и source snapshot. Ожидаемый результат — не «12/12 answer accuracy». Ожидаемый результат — каждый case выходит по объявленному safe route, а каждый cited answer использует только допустимый fixture locator.

Это воспроизводимый method fixture, а не performance evidence. Он показывает форму release gate. Production dataset следует расширять representative queries, изменениями source, adversarial phrasing, locales, permissions, сбоями из эксплуатации и review domain owner.

case: HR-014 / version=evalset-10-v1
scope: employee role / Armenia locale / policy collection
permitted: leave-policy@2026-08 / section=4.2
expected: cited_answer / claim="submit request before leave start"
reject: superseded leave-policy@2025-12
receipt: model + prompt + index + retrieved locators + reviewer decision

Запускайте тест как release receipt, а не как эксперимент в чате

Для run зафиксируйте dataset и source snapshot. Сохраняйте request, returned answer, retrieved chunks или locators, citation links, route, результат evaluator и reviewer override. Run без configuration receipt не объяснит, пришла ли регрессия из model, prompt, chunking, metadata filter, index, source lifecycle или evaluator.

Сравнивайте подобное с подобным. Новая модель может улучшить среднюю формулировку ответа, но сделать один policy slice менее grounded. Показывайте counts по slices и uncertainty малого sample; не превращайте маленький fixture в общекорпоративный claim о точности. У пилота должен быть named owner: он разбирает failures, классифицирует причину и либо исправляет систему, либо обновляет authoritatively expected answer.

Дисциплина lifecycle разобрана в Обновление индекса RAG: ingestion, версии и удаление данных. Для source locators и evidence, видимых читателю, используйте Цитаты и traceability в RAG. Следующая статья о метриках отличает coverage retrieval от grounding ответа; ни одно измерение не authorizes небезопасное действие.

Failure cases должны быть частью набора

Команды часто собирают только вопросы с чистыми ответами. Получается комфортный score и хрупкая система. Включайте cases, где source отозван, два документа конфликтуют, роль не авторизована, в вопросе отсутствует существенный identifier, запрошенный ответ consequential или разрешённых evidence нет.

• Изменённая policy проверяет, исчезла ли прежняя revision из retrieval и показан ли current locator.
• Вопрос вне corpus проверяет явный no-answer вместо правдоподобного synthesis.
• Запрос protected document проверяет deny до появления snippet в ответе или trace.
• High-consequence request проверяет review route, даже если сформулирован как обычный FAQ.
• Неоднозначный вопрос проверяет clarification до того, как retrieval выдают за доказательство.

Это не «краевые случаи после запуска». Они определяют operating boundary. Если система может записывать данные, принимать eligibility-решения, давать юридические, медицинские, safety или финансовые рекомендации либо существенно влиять на человека, действие должно оставаться отдельным authorised workflow с appropriate review.

Acceptance gate для контролируемого пилота

Начните с одного controlled use case и малого разрешённого corpus. Добавляйте cases из реальных reviewable failures, а не раздувайте dataset paraphrases. Так у команды останется evidence, которые можно инспектировать, улучшать и повторно запускать — более прочная база для controlled RAG pilot, чем polished demo. Для обсуждения пилота начните с RAG-систем или посмотрите engineering proof в /ru/case-studies.