Датасет для RAG оценки за две недели: пошаговая сборка 120 кейсов

Проблема знакома каждому, кто строит RAG на русскоязычных регламентах, инструкциях или технической документации. Публичный бенчмарк отвечает на вопрос «как модель ведёт себя на наборе открытых задач». Проверку пункта 4.7 актуальной версии именно вашего регламента, который пользователь назвал своими словами, он на себя не берёт. Ниже разберём, как собрать рабочий eval set (набор для RAG оценки) за одну-две недели, а не за квартал.

Три набора, которые нельзя путать

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

• Smoke-набор живёт рядом с CI (системой непрерывной интеграции) и прогоняется при каждом заметном изменении. Внутри: запросы, на которых система уже ошибалась, плюс несколько критичных «счастливых путей». Он короткий специально.
• Ручной eval set помогает принимать решения: нужен ли гибридный поиск, помогает ли реранкер на длинных регламентах, сломали ли фильтры поиск по старой версии документа.
• Данные для дообучения (fine-tuning) нельзя тихо тащить в eval set. Если вопрос влиял на дообучение, ему нужен отдельный holdout (отложенный набор, который модель не видела). Иначе метрика вырастет просто потому, что система снова увидела экзаменационные билеты.

Что понадобится

• Доступ к вашему корпусу документов (регламенты, инструкции, FAQ, release notes)
• Реальные или максимально близкие к реальным вопросы пользователей (логи чата, тикеты поддержки, запросы коллег)
• Таблица или JSONL-файл для хранения кейсов
• Один-два человека, знающих домен и цену ошибки
• От 4 до 10 рабочих часов на первую итерацию из 120 кейсов

Почему синтетика и публичные метрики не заменяют свой набор?

В доменном поиске болят вещи, почти невидимые в среднем скоре:

• Точные сущности: артикулы, номера договоров, коды ошибок
• Версии и даты документа
• Длинные разделы, где ответ и условие разнесены на несколько абзацев
• Таблицы, у которых при парсинге потерялась шапка
• Конфликтующие источники: инструкция обновилась, а старый FAQ остался в корпусе
• Вопрос, на который в корпусе честно нет ответа
• Человеческая формулировка, не похожая на заголовок документа

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

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

Пошаговая инструкция

1. Выпишите 6 от 8 срезов (сценариев), на которых будете принимать решения. Ориентир: реальные риски системы. Пример для внутреннего помощника по техдокументации: «точная сущность», «мультиабзацный ответ», «конфликт версий», «нет ответа в корпусе», «человеческая переформулировка», «таблица с потерянной шапкой».

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

3. Начните со 120 кейсов: по 12 от 20 на важный срез. Этого хватает, чтобы увидеть крупную проблему, а набор ещё можно дочитать руками за вечер-два.

4. Оформите каждый кейс в JSONL. Минимальная строка «вопрос плюс правильный документ» годится для первого наброска, но потом понадобятся дополнительные поля. Пример структуры:

{
  "id": "ops-047",
  "query": "После обновления агент перестал отвечать. Где посмотреть код ошибки E204?",
  "scenario": "exact_entity",
  "difficulty": "medium",
  "answerability": "answerable",
  "expected_document_ids": ["runbook-errors-v3"],
  "gold_evidence": [
    {"document_id": "runbook-errors-v3", "section_id": "errors/e204", "relevance": 2},
    {"document_id": "release-notes-2-4", "section_id": "known-issues", "relevance": 1}
  ],
  "expected_facts": [
    "E204 означает недоступность upstream API",
    "Нужно проверить статус upstream и повторить запрос"
  ],
  "acceptable_answer": "Короткая инструкция с источником; без причин, которых нет в документации"
}

1. Идентифицируйте документы через стабильный document_id и section_id, а не через chunk_id. Чанк-идентификатор привязан к конкретному индексу: поменяли разбивку и старый gold-label уже не с чем сравнивать.

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

3. Читайте результат по срезам, а не по среднему. Recall@10 = 0.91 по всему набору может скрывать recall = 0.3 на сценарии «конфликт версий». Именно этот провал убьёт доверие пользователей.

Что делать с этим прямо сейчас?

• ML-инженеру и разработчику RAG: возьмите реальные логи пользовательских запросов, выпишите 6 от 8 болевых срезов вашего домена, соберите первые 120 кейсов в JSONL. Это занимает не квартал, а неделю. Такой набор для RAG оценки покажет, где именно ломается поиск, а не просто даст красивый средний скор.
• Автору Дзена и контент-маркетологу, работающему с AI-инструментами: если вы подключаете RAG к базе знаний для генерации статей или ответов, протестируйте поиск на реальных формулировках ваших читателей, а не на заголовках документов. Разница будет заметной.
• Предпринимателю в РФ: русскоязычные регламенты, многоверсионные документы, артикулы с кириллицей и латиницей вперемешку ломают стандартные бенчмарки особенно сильно. Публичные оценки на английских датасетах вашу специфику не покрывают. Свой eval set обязателен.

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