Когда речь заходит об оценке RAG-систем, многие команды собирают тестовые наборы на скорую руку: берут десяток вопросов из головы, прогоняют и получают красивые метрики. Но эти цифры часто не имеют ничего общего с реальностью. Почему? Потому что eval set не отражает сложность настоящих пользовательских запросов. В свежей статье на Habr авторы детально разбирают, как собрать первые 100-300 кейсов, которые дадут честную картину. Ключевые принципы — ниже.
Три главные ошибки при создании eval set
1. Использование тренировочных данных. Если ваша RAG-система строится на документах, часть вопросов из теста может быть сформулирована по этим же документам, что даёт ложное преимущество. Модель запоминает текст и выдаёт правильный ответ, даже если механизм поиска не работает.
2. Игнорирование edge cases. Реальные пользователи задают вопросы с опечатками, сленгом, двусмысленностями. Если ваш eval set состоит только из чётко сформулированных вопросов, вы никогда не увидите слабые места. Например, пользователь может спросить «как вернуть деньги?» в чате о документах, а в базе знаний будет только раздел «Возвраты и компенсации». Такие несоответствия нужно проверять.
3. Отсутствие негативных примеров. Когда в базе знаний нет ответа, система должна честно это признать, а не выдумывать. Сценарии «вопрос-без-ответа» часто пропускают, и потом система вводит пользователей в заблуждение, уверенно заявляя несуществующие факты.
Как собрать eval set: пошаговая инструкция
Шаг 1. Соберите реальные запросы. Подключите аналитику, проанализируйте логи чатов с поддержкой, отзывы в тикетах, используйте краудсорсинг. Отфильтруйте случайные и неинформативные запросы, оставьте те, которые можно отнести к задачам RAG. Например, если это корпоративный помощник, реальные вопросы будут про положения внутренней документации, а не про общие знания.
Шаг 2. Кластеризуйте и категоризируйте. Разбейте вопросы на типы: фактологические («какова процедура согласования заявки?»), сравнительные («что лучше: вариант А или Б?»), инструктивные («как настроить VPN?»), вопросы о процессах («какие сроки обработки заявления?»). Определите частотность каждого типа в реальном трафике.
Шаг 3. Составьте бутстрэп-набор. Выберите по несколько вопросов из каждой категории, пока наберёте 100-300. Старайтесь покрыть 80% сценариев, даже если для этого придётся взять больше простых вопросов. Но обязательно включите редкие, но критически важные случаи.
Шаг 4. Добавьте сложные случаи. Например, вопросы, где ответ требует информации из двух источников, или вопросы с «подводными камнями» (ложные предположения). Пример: «Когда мы перейдём на удалёнку, изменится ли наш график отпусков?» — здесь нужно объединить два раздела документации.
Шаг 5. Разметьте эталонные ответы. Привлеките минимум двух экспертов, чтобы получить независимые ответы. Вычислите коэффициент согласованности (например, Cohen's kappa) и обсудите разногласия. Если согласованность низкая, переформулируйте инструкции для разметчиков или уточните сам вопрос.
Шаг 6. Подготовьте документацию. Запишите, по каким правилам размечали, какие источники считаются релевантными. Это поможет при расширении набора и при воспроизводимости эксперимента.
Как оценивать RAG: что считают метрики
Метрики качества RAG можно разделить на три группы:
- Оценка контекста: насколько релевантные документы были найдены (context precision, recall). Эта метрика показывает, хорошо ли работает поиск.
- Оценка ответа: насколько ответ полезен и по существу (answer relevance). Здесь оценивается, решает ли ответ задачу пользователя.
- Оценка верности: отражает ли ответ смысл контекста (faithfulness). Это защита от «галлюцинаций» — ответов, которые не подтверждаются документами.
Вместо одного числа стоит смотреть на совокупность метрик, чтобы понять, где именно деградирует система. К примеру, высокий answer relevance при низком faithfulness означает, что модель генерирует правдоподобные, но ложные ответы.
Автоматизация и человеческий фактор
Существуют библиотеки для автоматического расчёта метрик, например, RAGAS. Они позволяют быстро прогнать eval set, но не могут заменить качественную разметку. Авторы статьи подчёркивают, что на этапе первого набора кейсов лучше всё сделать вручную, а автоматизацию использовать для регулярного регрессионного тестирования. Важно также периодически обновлять eval set, добавляя новые типы запросов, чтобы он не устаревал.
Выводы
Собрать честный eval set — это процесс, требующий времени и экспертизы. Но именно он позволяет доверять своим метрикам и понимать реальное качество RAG. Начните с малого: 100-300 хорошо продуманных кейсов дадут вам достаточно информации для итераций. Чтобы узнать больше о подходе, описанном в статье, переходите по Источник.
Комментарии