Предисловие переводчика

Продолжаю адаптированный перевод статьи китайских исследователей Retrieval-Augmented Generation for Large Language Models: A Survey (ссылка на первую часть — здесь, на вторую часть — здесь, третью часть — здесь, четвёртую часть — здесь). Перевод этой части мы выполняли в тандеме с коллегой — Мариной Хазиевой. К некоторым терминам, как и в прошлых частях, добавлены переводы и пояснения для удобства начинающих ИТ-переводчиков.

В этой части мы поговорим про техники оценки качества систем RAG и соответствующие им наборы данных. Основная цель — понять и оптимизировать эффективность моделей RAG в различных прикладных сценариях.

А. Задачи, решаемые через RAG

По-прежнему главная задача RAG — отвечать на вопросы, в частности предоставлять:

• стандартные ответы с одноэтапным и многоэтапным поиском информации (см. Рисунок 1);

• ответы на вопросы с вариантами ответа;

• ответы на предметно-ориентированные вопросы;

• сценарии генерации развернутых ответов.

Кроме того, сегодня у RAG есть и другие задачи (см. Таблицу 1), например:

• извлечение информации;

• генерация диалогов;

• поиск кода.

Таблица 1. Задачи и наборы данных RAG

Б. Параметры оценки

Обычно качество моделей RAG оценивают на конкретных задачах и метриках. Например, мы оцениваем правильность классификации при помощи следующих метрик (см. Рисунок 2):

1. Exact Match [EM, строгое соответствие] — процент полного совпадения ответа.

Допустим, эталонный ответ: «HTTP-код 429 означает Too Many Requests». Если модель выдала точно такую же фразу — это засчитывается как Exact Match. Но если она написала: «Слишком много запросов — код 429» — даже при верной сути совпадение не будет полным, и EM = 0. Поскольку метрика чувствительна к формулировкам, её лучше использовать только тогда, когда нужна буквальная точность — например, при проверке терминологии.

2. Accuracy — доля правильно классифицированных объектов (также подходит для фактчекинга).

К примеру, если система определяет, содержит ли предложение ошибку в использовании термина API, где :

«GET-запрос должен изменять состояние сервера» → неверно;

«POST используется для создания ресурсов» → верно.

Если из 10 таких утверждений модель правильно оценила 9 — accuracy = 90%.

Эта метрика проста и наглядна, особенно при бинарной проверке фактов, но плохо работает с несбалансированными классами и сложными данными.

3. Precision — насколько релевантны предсказанные данные.

Пример: нужно найти все упоминания async/await в документации. Модель вытянула 5 чанков, но только 3 из них действительно про async/await, а 2 — про колбэки.

Тогда Precision = 3 / 5 = 60%.

Высокая точность означает: когда модель что-то «нашла» — ей можно доверять, но эта метрика ничего не говорит о том, что модель могла пропустить.

4. Recall  — насколько хорошо модель нашла все релевантные данные.

Допустим, в предыдущей задаче всего было 4 настоящих упоминания async/await, а модель нашла только 3.

Recall = 3 / 4 = 75%.

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

5. F1-Score — сочетание Precision и Recall.

В примере выше:

Precision = 0,6

Recall = 0,75

F1 = 2 × (0,6 × 0,75) / (0,6 + 0,75) ≈ 0,67

Это сбалансированный показатель: он падает, если хоть один из параметров слаб.

При отсутствии единственно правильного ответа — например, когда нужно сгенерировать описание, объяснение или инструкцию — нельзя полагаться только на метрики вроде Exact Match. В таких случаях используются метрики, которые оценивают, насколько сгенерированный ответ близок к эталонному образцу:

1. BLEU (Bilingual Evaluation Understudy) — метрика, изначально разработанная для оценки качества машинного перевода. Она основана на n-граммной точности (Precision) и включает штраф за краткость.

Допустим, что в примере эталонный ответ: Для установки пакета используйте команду pip install package_name в терминале. А модель выдала: Используйте pip install — коротко, но неполно. BLEU это «поймает»: высокая точность по словам (pip, install) будет компенсирована штрафом за слишком короткий ответ.

Это особенно важно при локализации руководств: например, если технический переводчик получит от RAG обрезанную инструкцию, он может упустить ключевые детали.

2. ROUGE (Recall-Oriented Understudy for Gisting Evaluation) — метрика, ориентированная на полноту воспроизведения информации. Он учитывает Precision, Recall и F1-Score, но не накладывает штраф за краткость. Чаще всего используется ROUGE-L, который считает совпадения по наибольшей общей подпоследовательности между текстами.

Пример: есть эталонное выражение «Функция map() применяет указанную функцию к каждому элементу итерируемого объекта». Ответ модели: «map() выполняет операцию над каждым элементом списка». Несмотря на упрощение («списка» вместо «итерируемого объекта»), ROUGE покажет высокий балл, потому что ключевая идея сохранена. Эта метрика хорошо работает при оценке генерации документации или аннотаций, где важнее не буквальное совпадение, а передача сути.

Инструменты для автоматической оценки вроде RaLLe (Retrieval-Augmented LLM Development and Evaluation Framework) также используют количественные метрики для автоматической оценки RAG (см. Рисунок 3).

В целом системы RAG оценивают по следующим критериям:

1. Качество поиска [Retrieval Quality] — насколько эффективен контекст, полученный ретривером [retriever, модуль для поиска и извлечения информации]. 

Эффективность ретривера можно измерить  метриками, которые используют для анализа поисковых систем [search engines], систем рекомендаций [recommendation systems] и систем информационного поиска [information retrieval systems], в частности:

• Hit Rate — доля нахождений релевантной информации;

• MRR — характеристика эффективности информационного поиска, зависящая от порядкового положения (ранга) первого релевантного результата;

• NDCG — нормализованная (приведенная к общей шкале) оценка качества ранжирования с учётом позиций релевантных нахождений.

2. Качество генерации — насколько эффективно генератор формирует логичные и релевантные ответы на основе извлечённого контекста.

Качество генерации можно оценивать на размеченном или неразмеченном контенте.

Для неразмеченного контента мы оцениваем:

• достоверность;

• релевантность;

• отсутствие наносимого вреда, то есть предвзятых или оскорбительных ответов.

Для размеченного контента мы оцениваем Accuracy.

И качество поиска, и качество генерации можно оценить ручными и автоматическими методами.

В. Аспекты оценки

В современных подходах к оценке RAG выделяют три основных показателя качества и четыре ключевых возможности RAG.

1) Показатели качества определяют эффективность RAG в процессе поиска и генерации информации и включают:

• релевантность контекста;

• достоверность ответа;

• релевантность ответа.

1.1) Релевантность контекста характеризует точность и специфику найденного контекста.

Например, пользователь спрашивает: Как в React правильно использовать хук useEffect с очисткой? Если система подтянула фрагмент про useState или вообще про Vue.js — мимо. А вот если она нашла описание того, как возвращать функцию очистки в useEffect — это и есть релевантный контекст.

1.2) Достоверность ответа гарантирует, что сгенерированные ответы соответствуют извлечённому контексту, согласованы и не содержат противоречий.

Допустим, в документации написано: Метод fetch() по умолчанию не отправляет куки. Если LLM говорит: Метод fetch() автоматически передаёт куки — это ложь, даже если звучит правдоподобно.

1.3) Релевантность ответа требует, чтобы сгенерированные ответы напрямую касались поставленных вопросов и эффективно раскрывали суть запроса.

Представьте, что нужно перевести запрос: Что означает ошибка “413 Payload Too Large”? Хороший ответ: Сервер отклонил запрос, потому что тело данных слишком большое. Нужно уменьшить размер файла или увеличить лимит на сервере. Плохой ответ: длинный рассказ о всех HTTP-ошибках от 400 до 500, где нужная информация теряется.

2) Ключевые возможности (см. Рисунок 4) отражают адаптивность и эффективность модели RAG и включают:

• устойчивость к шуму;

• отказ от ответа;

• интеграцию данных ;

• контрфактуальную устойчивость.

2.1) Устойчивость к шуму показывает, насколько хорошо модель справляется с зашумленными данными, которые связаны с запросом, но содержат недостаточно полезной информации.

Например, вы спрашиваете: Как исправить ошибку ModuleNotFoundError: No module named 'requests' в Python? Система могла найти чанк, где упоминается requests, но основное содержание — про установку NumPy или настройку виртуального окружения без pip. Хорошая модель RAG должна проигнорировать этот шум и сосредоточиться только на релевантных фрагментах.

2.2) Отказ от ответа характеризует, насколько точно модель распознаёт, что ей стоит воздержаться от ответа, если найденные данные не содержат запрашиваемой информации.

Допустим, вы спрашиваете: Какие новые функции появились в Django 6.0? — а ваша база знаний обновлена только до версии 5.0. Если модель молча сочинит правдоподобный, но ложный список нововведений — это галлюцинация. А вот если она скажет: На основе доступных данных я не могу ответить на этот вопрос — это корректный отказ.

2.3) Интеграция данных показывает умение модели интегрировать данные из нескольких источников для ответа на сложные вопросы.

Допустим, мы задали вопрос: Как безопасно передавать токены в REST API? Первый чанк говорит: Используйте заголовок Authorization. Второй: Тип токена — Bearer. Третий: Никогда не передавайте токены в URL. Хорошая модель RAG объединит эти кусочки в один чёткий ответ: Токены следует передавать в заголовке Authorization с типом Bearer, например: Authorization: Bearer <token>. Никогда не включайте их в URL, чтобы избежать утечки в логах.

2.4) Контрфактуальная устойчивость проверяет умение модели распознавать и игнорировать заведомо ложные данные.

Например, в одном из документов есть ошибка: В Python 3.11 ключевое слово match можно использовать только в циклах for. На самом деле — это неправда: match — это часть match-case, аналог switch в других языках, и работает независимо от циклов. Если модель повторит эту ошибку — значит, у неё плохая контрфактуальная устойчивость. А если она сверит противоречие с достоверными источниками и скажет: Утверждение о том, что match работает только в циклах, неверно — модель сработала успешно.

Среди этих аспектов для оценки качества поиска важны:

• релевантность контекста;

• устойчивость к шуму.

Для оценки качества генерации важны:

• достоверность ответа;

• релевантность ответа;

• отказ от ответа;

• интеграция данных;

• контрфактуальная устойчивость.

В Таблице 2 вы найдете основные релевантные метрики для каждого аспекта оценки. Эти метрики заимствованы из смежных областей, поэтому единого стандартизированного подхода к количественной оценке аспектов RAG пока нет.

Таблица 2. Основные метрики для оценки аспектов RAG

Г. Фреймворки для оценки RAG

Фреймворки (см. Таблицу 3) используют количественные метрики для более точной оценки сразу нескольких аспектов RAG. Например, для оценки базовых характеристик RAG используют:

• RGB (Retrieval-Augmented Generation Benchmark);

• RECALL (Robustness against External CounterfactuAL knowLedge);

• CRUD (Create, Read, Update, and Delete). 

Для оценки показателей качества с помощью LLM используют автоматизированные инструменты типа:

• RAGAS (Retrieval Augmented Generation Assessment);

• ARES (Automated RAG Evaluation System);

• TruLens.

Таблица 3. Основные фреймворки для оценки RAG

^{Символ † означает бенчмарк, символ ‡ — инструмент, а символ * — специализированные количественные метрики, отличающиеся от традиционных.}