# Синтетические тесты RAG: не допустить утечки документов в отложенную выборку

Синтетические вопросы RAG следует создавать после разделения исходных документов на разработочную и отложенную группы.

Автор: Команда Retrivium
Обновлено: 2026-11-03
Канонический URL: https://retrivium.ai/ru/journal/rag-synthetic-testset-leakage-controls/
Language: ru

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

## Разделить источники до генерации

Официальный [процесс подготовки тестов Ragas](https://docs.ragas.io/en/latest/getstarted/rag_testset_generation/) создаёт проверочные материалы из документов. Перед запуском группируют копии файлов, редакции и фрагменты одного оригинала. Эти группы назначают совместно. Иначе вопрос по абзацу одной редакции руководства попадёт в отложенный набор, тогда как разработочная выборка содержит почти идентичный абзац другой редакции. Правило группировки записывают в манифест рядом с хешами документов и связями версий, чтобы позднее восстановить причину каждого назначения.

## Сохранить происхождение генерации

Записывают модель генератора, инструкции, идентификаторы источников и созданный эталонный ответ. [Реализация Ragas](https://github.com/vibrantlabsai/ragas) предоставляет механизм процесса, но результат всё равно нуждается в редакционной проверке. Вопрос способен подсказать буквальную формулировку ответа, зависеть от отсутствующего контекста или объединять несовместимые редакции. Такие случаи отбрасывают по заданному правилу, а не в зависимости от успеха предпочитаемого поисковика. Исходный результат генератора сохраняют отдельно от исправленного проверяющим варианта.

## Составить таблицу возможных утечек

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

| Артефакт | Связь с источником | Правило разделения |
| --- | --- | --- |
| Исходное руководство | Семейство источника | Назначить совместно |
| Новая редакция | Связанная версия | Проверить пересечения перед назначением |
| HTML-экспорт | Другое представление копии | Оставить с оригиналом |

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

В [организации данных BEIR](https://github.com/beir-cellar/beir) отдельно существуют корпус, запросы и оценки релевантности. Это разделение полезно синтетическим тестам. Сгенерированный ответ не определяет автоматически все релевантные фрагменты, а исходный фрагмент вопроса не обязательно является единственным допустимым подтверждением. Неоднозначные случаи рассматривают вручную, сохраняя статус отсутствия разметки там, где это нужно. Нетронутый выход генератора позволяет проследить последующие исправления вместо незаметной замены первоначального проверочного артефакта.

## Защитить отложенную выборку

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

Связанные материалы: [Эмбеддинги для русского языка: как проверить поиск на своих документах](/ru/journal/embeddings-russian-retrieval/); [Бенчмарк GPU для инференса, которому можно доверять](/ru/journal/inference-benchmark-method/).