В бизнесе RAG Evals нужны до запуска и после каждого изменения базы знаний, промпта, retriever, chunking, top-k, reranking или модели. Без evals команда обычно оценивает качество на глаз: задали несколько вопросов, получили приятные ответы и решили, что система готова. Проблема в том, что реальные пользователи задают вопросы иначе, а ошибки часто появляются только на пограничных кейсах.
Хороший набор RAG Evals проверяет несколько вещей отдельно. Retrieval quality показывает, нашла ли система правильные фрагменты. Answer faithfulness показывает, не противоречит ли ответ найденным источникам. Citation quality проверяет, можно ли по ссылке подтвердить утверждение. Coverage показывает, ответила ли система на весь вопрос. Safety checks помогают отловить утечки, ответы без прав доступа и использование устаревших документов.
RAG Evals лучше строить на реальных вопросах пользователей: обращения поддержки, запросы менеджеров, типовые вопросы сотрудников, сложные кейсы из CRM или базы знаний. Для каждого вопроса фиксируют ожидаемый источник, критерии хорошего ответа и типичные ошибки. Тогда RAG становится не “магической поисковой штукой”, а управляемой системой, качество которой можно измерять и улучшать.
Примеры
- Команда поддержки проверяет, находит ли агент правильный регламент возврата и не ссылается ли на старую инструкцию.
- Юридический RAG тестируют вопросами по договорам: ответ должен опираться на конкретные пункты и показывать источник.
- Внутренний поиск по базе знаний сравнивают на 100 реальных вопросах сотрудников до и после смены chunking.
- BI-агента проверяют на вопросах по метрикам: он должен ссылаться на metric catalog, а не придумывать определение.
- После добавления reranker команда смотрит, выросла ли доля ответов с правильными источниками в top-3.
Где используется
- Проверить RAG-систему перед запуском в поддержку, продажи, HR, юристов или внутренний поиск.
- Сравнить разные настройки chunking, top-k, reranking и retrieval filters.
- Понять, почему агент отвечает неправильно: не нашел источник или неправильно его пересказал.
- Отлавливать галлюцинации, слабые цитаты и ответы без подтверждения источниками.
- Контролировать качество после обновления базы знаний и регламентов.
- Собрать regression suite для RAG, чтобы новые изменения не ломали старые сценарии.
- Оценивать качество разных моделей на одной и той же базе документов.
- Проверять соблюдение прав доступа и запрет ответа по закрытым источникам.
- Показывать бизнесу качество системы в метриках, а не в субъективных впечатлениях.
Связанные термины
Частые вопросы
Что именно проверяют RAG Evals?
Обычно проверяют качество поиска, релевантность найденных фрагментов, точность ответа, верность цитат, полноту ответа, отсутствие галлюцинаций и соблюдение прав доступа.
Чем RAG Evals отличаются от обычных evals модели?
Обычные evals могут оценивать ответ модели сам по себе. RAG Evals оценивают весь контур: документы, индексацию, поиск, фильтры, контекст, промпт, модель, цитаты и финальный ответ.
Сколько вопросов нужно для первых RAG Evals?
Для старта достаточно 30-50 реальных вопросов по основным сценариям. Для production-системы лучше собрать 100-300 кейсов с разными типами документов, сложностью и ожидаемыми источниками.
Можно ли автоматизировать RAG Evals?
Да. Часть проверок автоматизируют через метрики, LLM-as-judge, сравнение с эталонными источниками и regression suite. Но важные бизнес-кейсы все равно стоит периодически смотреть вручную.
Какая самая частая ошибка в RAG Evals?
Оценивать только красоту финального ответа. Если не проверять найденные источники отдельно, можно не заметить, что модель отвечает убедительно, но опирается на неправильный документ.
