Q: How should I approach evaluating my RAG system? – Hamel’s Blog - Hamel Husain
Статья описывает подход к оценке RAG-систем, разделяя их на два компонента: поиск (retrieval) и генерацию. Для поиска рекомендуется использовать классические метрики информационного поиска — Recall@k, Precision@k, MRR — на синтетически сгенерированных парах «запрос–документ». Для генерации предлагается применять анализ ошибок, человеческую разметку и валидированных LLM-судей. В качестве базового фреймворка упоминается статья Jason Liu «There Are Only 6 RAG Evals», разделяющая оценки на три уровня. Автор подчёркивает, что доменные ошибки (например, в медицинских или юридических RAG) выявляются только при систематическом анализе реальных сбоев и требуют отдельных метрик. Главный совет: сначала отладить поиск по IR-метрикам, затем заняться качеством генерации с помощью проверенных LLM-судей.
RAG-системы состоят из двух отдельных компонентов, требующих разных подходов к оценке: поиска и генерации.
Компонент поиска — это задача информационного поиска. Оценивайте его с помощью классических метрик информационного поиска (IR). Типичные примеры: Recall@k (какую долю релевантных документов вы извлекли в топ-k?), Precision@k (сколько из k извлечённых документов оказались релевантными?) и MRR (насколько высоко оказался первый релевантный документ?). Конкретные метрики зависят от вашего сценария использования. Это чистые поисковые метрики, которые измеряют, находите ли вы нужные документы (подробнее об этом ниже).
Для оценки поиска создайте датасет из запросов, сопоставленных с релевантными документами. Сгенерируйте его синтетически: возьмите документы из вашего корпуса, извлеките ключевые факты, а затем сформулируйте вопросы, на которые эти факты отвечают. Такой обратный процесс даёт пары «запрос–документ» для измерения качества поиска без ручной разметки.
Для компонента генерации — насколько хорошо LLM использует полученный контекст, галлюцинирует ли она, отвечает ли на вопрос — применяйте те же процедуры оценки, которые рассматриваются в этом курсе: анализ ошибок для выявления типов сбоев, сбор человеческих меток, создание LLM-судей и валидация этих судей по человеческим аннотациям.
Статья Jason Liu «There Are Only 6 RAG Evals» предлагает фреймворк, хорошо ложащийся на это разделение. Его Tier 1 охватывает классические IR-метрики для поиска. Tier 2 и Tier 3 оценивают связи между вопросом, контекстом и ответом — например, релевантен ли контекст запросу (C|Q), соответствует ли ответ контексту (A|C) и отвечает ли ответ на вопрос (A|Q).
Помимо шести оценок Jason, анализ ошибок на ваших конкретных данных может выявить доменные типы сбоев, заслуживающие собственных метрик. Например, медицинская RAG-система может систематически путать дозировки препаратов для взрослых и детей, а юридическая RAG — смешивать границы юрисдикций. Такие паттерны обнаруживаются только при систематическом разборе реальных ошибок. После их выявления можно создать целевые оценщики для этих конкретных проблем, выходящие за рамки общего фреймворка.
Наконец, при реализации метрик Tier 2 и Tier 3 Jason не берите промпты «как есть». Стандартный процесс LLM-судьи требует нескольких шагов: анализ ошибок, итерация промптов, создание размеченных примеров и измерение точности судьи относительно человеческих меток. Когда вы узнаете показатели True Positive и True Negative вашего судьи, вы сможете скорректировать его оценки и определить реальный уровень сбоев в системе. Если пропустить эту валидацию, судьи могут не отражать ваши реальные критерии качества.
Подводя итог: сначала отладьте поиск с помощью IR-метрик, а затем займитесь качеством генерации, используя должным образом валидированных LLM-судей.
Эта статья — часть нашего FAQ по оценке ИИ, сборника частых вопросов (и ответов) об оценке LLM. Смотреть все вопросы FAQ или вернуться на главную.