Проблема усредненных метрик

Использование сильных публичных бенчмарков вроде BEIR или MTEB полезно для сравнения моделей, но они не гарантируют качество работы системы на ваших специфических данных. Можно сохранить 99% точности на внешнем тесте и при этом не находить нужные документы в собственном домене. Для проверки системы на реальных задачах необходим собственный eval set — набор проверочных кейсов.

Золотая середина: 100–300 кейсов

Существует две крайности: либо тратить квартал на разметку тысячи вопросов, либо генерировать десяток синтетических вопросов и объявлять систему готовой. Эффективное решение — собрать первые 100–300 кейсов вручную. Это не универсальный датасет для обучения, а инструмент для принятия инженерных решений. Такой набор позволяет понять, помогает ли reranker на длинных документах, нужен ли гибридный поиск и не сломали ли фильтры поиск при обновлении индекса.

Как избежать ловушек синтетики

Синтетические вопросы ускоряют старт, но они опасны. Модели, которые сами генерируют вопросы по документам, создают слишком «аккуратные» формулировки. В реальности люди пишут иначе: вместо «опишите порядок оформления согласно разделу 3.2» они спрашивают «кому нести заявку, если доступ вчера закрыли?». Синтетику стоит использовать только как вспомогательный слой для подготовки кандидатов или покрытия редких типов документов, но финальное решение о качестве кейса должен принимать человек.

Структура правильного набора

Не стоит начинать разметку просто со списка вопросов. Сначала нужно выделить 6–8 сценариев (срезов), исходя из реальных рисков системы. Например, для техподдержки это могут быть: поиск по кодам ошибок, поиск по артикулам, работа с таблицами или проверка способности системы отвечать «информации нет». Важно разделять поиск (retrieval) и генерацию ответа. Если система ошибается, нужно понимать: либо нужный фрагмент не попал в выдачу, либо модель додумала лишнего, либо в базе лежит устаревший документ.

Что хранить в eval set

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

Что это значит

Для эффективной работы RAG-системы недостаточно одного среднего показателя точности. Необходимо разделять оценку поиска и оценку генерации, использовать ручную разметку для критических сценариев и внедрять короткий тестовый набор как обязательный этап проверки (release gate) перед каждым обновлением системы.