Как измерять качество RAG-систем: метрики Context Precision и Context Recall

Две трети коммерческих ИИ-проектов сегодня построены на архитектуре RAG — и большинство из них оцениваются на глаз. Третья часть серии об инженерии качества агентных систем посвящена тому, как перевести оценку поискового слоя в числа.

RAG (Retrieval-Augmented Generation) появился как ответ на два фундаментальных ограничения LLM: конечный контекст и стоимость его обработки. Даже модели с окном в миллион токенов на практике деградируют при работе с информацией из середины контекста — явление называется Lost in the Middle. Механизм внимания теоретически позволяет модели обращаться к любому токену с равной вероятностью, но на практике обучающие данные структурированы так, что ключевая информация концентрируется в начале и конце текста. Модель усваивает этот паттерн и воспроизводит его при инференсе. Добавьте к этому стоимость: одна пользовательская сессия с большим контекстом занимает гигабайты GPU-памяти, и при сотнях параллельных пользователей экономика проекта не сходится.

RAG решает проблему иначе: статичные данные — корпоративные документы, исходный код, базы знаний — индексируются заранее и помещаются в специализированное хранилище. При каждом запросе система извлекает только релевантные фрагменты (чанки) и передаёт их в контекст модели. Пайплайн сводится к четырём шагам: найти потенциально полезные документы, отранжировать и выбрать topN, упаковать в контекст, сгенерировать ответ. Простота архитектуры объясняет её распространённость — и одновременно маскирует точки отказа.

Отказов у RAG три. Первый — система не находит нужные фрагменты вовсе: плохая индексация приводит к тому, что нужные данные не попадают в topN, и модель вынуждена галлюцинировать. Второй — система находит слишком много: в выдаче оказываются нерелевантные чанки, которые активируют эффект Lost in the Middle и расходуют вычислительные ресурсы впустую. Третий — поиск работает корректно, но модель всё равно генерирует ответ мимо запроса. Каждый из этих сценариев требует отдельной метрики.

Для первых двух сценариев фреймворк RAGAS предлагает метрики Context Precision и Context Recall — прямые аналоги метрик из классических поисковых систем (SERP-метрик).

Context Precision измеряет не просто наличие релевантных чанков в выдаче, а их позицию. Формула взвешивает Precision@k на индикатор релевантности v_k для каждой позиции и нормирует на общее число релевантных документов в топе. На практике это означает: если оба нужных чанка стоят на позициях 2 и 5 из пяти, итоговый Context Precision@5 составит 0,45 — система штрафуется за то, что не подняла релевантный документ выше. Релевантность каждого чанка определяет LLM-судья через few-shot промпт: модель получает вопрос, ответ и контекст и выносит вердикт «1» или «0» в JSON.

Context Recall считается проще: метрика берёт эталонный ответ, разбивает его на отдельные утверждения и проверяет, какая доля этих утверждений подкреплена найденными документами. Разбивку на утверждения тоже выполняет LLM через few-shot промпт. Если эталонный ответ содержит три факта, а в retrieved-контекстах подтверждается только два — recall равен 0,67.

Оба показателя реализованы в RAGAS через единый интерфейс: создаётся экземпляр метрики с указанием evaluator_llm, формируется объект SingleTurnSample с полями user_input, retrieved_contexts и reference, после чего вызывается асинхронный метод ascore. Это позволяет встроить оценку в CI/CD-пайплайн и отслеживать деградацию при изменении индекса или модели эмбеддингов.

Серия продолжается: в предыдущих частях были разобраны универсальные метрики агентных систем и оценка суммаризации. Метрики для оценки финального ответа — faithfulness и answer relevancy — логично следуют за поисковыми и закрывают третий сценарий отказа RAG.