Что не так с оценкой RAG-системи какое решение предлагает динамический бенчмарк DRAGOn

В этот раз предлагаю разбор научной статьи DRAGOn: Designing RAG On Periodically Updated Corpus — будет полезна всем, кто интересуется RAG и хочет знать, как оценивать такие системы. 

Структура

1. Почему RAG сложно оценивать 

2. Идея DRAGOn

3. Как строится бенчмарк

4. Проверка качества QA 

5. Проверка бенчмарка на RAG-системах

6. Публичный лидерборд 

7. Ограничения, проблемы и практические выводы

Почему RAG сложно оценивать?

Сегодня RAG-систему можно собрать за один вечер, а вот понять, насколько хорошо она действительно работает, — уже совсем другая задача.

Не углубляясь в теоретические детали, вспомним, что RAG (Retrieval-Augmented Generation) — это подход, при котором модель получает доступ к внешней информации прямо перед генерацией ответа. То есть вместо того, чтобы опираться исключительно на знания модели, полученные на этапе обучения, система извлекает релевантные данные из подключенных баз и добавляет их в контекст запроса.

И вроде логика простая: если система находит хорошие документы и генерирует осмысленные ответы — значит, все отлично, но на практике оценка таких систем оказывается гораздо менее очевидной задачей со множеством проблем. 

Причем проблемы здесь не частные, а вполне системные:

• большинство существующих бенчмарков основаны на фиксированном корпусе текстов, и со временем они перестают отражать реальную информационную среду, в которой предстоит работать RAG-системе; 

• сложно определить, какой именно компонент архитектуры повлиял на итоговую производительность;

• неочевидно, обусловлено ли высокое качество архитектурой системы или тем, что базовая языковая модель уже встречала информацию, на которой ее проверяют;

• сбор и подготовка пар «вопрос — ответ» обычно выполняется вручную, что долго, дорого и плохо масштабируется.

В результате получается довольно парадоксальная ситуация: RAG-системы активно применяются и быстро развиваются, но при этом универсального, надежного, прозрачного и воспроизводимого способа их оценки по-прежнему не существует. Попробуем разобраться, что предлагают для решения этой проблемы ученые из MWS AI, Сбера и ряда университетов в своей научной статье DRAGOn: Designing RAG On Periodically Updated Corpus, недавно представленной на EACL 2026.

Идея DRAGOn

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

Отсюда и возникает подход DRAGOn (Designing RAG On Periodically Updated Corpus). Это целая методология построения бенчмарка для RAG-систем. 

В основе лежат три ключевых элемента:

• регулярно обновляемый корпус документов, который будет отражать актуальное состояние информационной среды;

• автоматизированная генерация пар «вопрос — ответ», необходимая для того, чтобы справиться с проблемой масштабирования и в целом сделать возможным регулярное обновление бенчмарка;

• публичный лидерборд, который обеспечит единые прозрачные условия оценки и сравнения вариантов RAG-систем.

Похожие идеи уже есть в литературе. Так, в ряде работ предлагаются автоматизированные пайплайны генерации QA-пар (например, подходы наподобие RAGAS), а также бенчмарки вроде Real-Time QA. Однако до сих пор отсутствовало решение, которое одновременно закрывало бы все три обозначенных выше аспекта.

В этом смысле DRAGOn объединяет эти требования в одной системе и делает процесс оценки непрерывным, версионируемым и прозрачным.

Как строится бенчмарк

Переходим к самому интересному: как именно генерируются вопросы-ответы.

В DRAGOn эта задача решается с помощью набора парсеров, которые регулярно подгружают данные из внешних источников (например, новостных агрегаторов). 

Однако сам по себе поток текстов еще не является бенчмарком. А чтобы являлся, нужно сделать три вещи: 

• вытащить из текстов атомарные факты;

• отделить действительно новые знания от уже известных;

• и только потом превратить их в QA-пары, на которых можно проверять систему.

Как именно все это сделать? Представим, что корпус текстов уже сформирован, и дальнейший процесс разберем по шагам.

Извлечение знаний

В DRAGOn используется отдельный модуль извлечения знаний, вдохновленный предыдущими работами в этой области.

Его задача в том, чтобы преобразовать неструктурированные тексты в более формальное представление, с которым дальше удобно работать. Для этого с помощью LLM (LLaMa 3.3 70B Instruct*) из текста извлекаются факты в виде триплетов.

Каждый такой триплет по сути соответствует классической структуре: субъект — предикат — объект. Например: 

• (Apple — выпустила — iPhone 15)

• (Илон Маск — возглавляет — SpaceX)

• (Компания X — приобрела — стартап Y)

Таким образом, из сплошного текста получается набор атомарных фактов, которые можно явно анализировать и комбинировать 

Однако, как обсуждалось ранее, для корректной оценки важны именно новые факты, а не уже известные знания. Поэтому для каждой извлеченной сущности отправляется запрос через Wikidata API. Если соответствующий факт уже присутствует в Wikidata, он отбрасывается. 

После все та же LLaMa 3.3 70B Instruct с учетом контекста нормализует имена сущностей и отношений. В результате в граф попадают только новые факты, пригодные для генерации вопросов.

Можно переходить к этапу генерации QA-пар.

Генерация вопросов

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

1. Simple. Самый простой вариант — это вопросы, основанные на одном факте. В этом случае используется один триплет из графа и на его основе формируется вопрос, а одна из сущностей становится ответом.

Например, если в графе есть связь

(Илон Маск — возглавляет — SpaceX),

то можно задать вопрос: «Кто возглавляет SpaceX?» 

Ответ: Илон Маск.

2. Set. В этом случае используется несколько триплетов с общей сущностью и одинаковым отношением. Вопрос задается так, чтобы перечислить все объекты, связанные с этой сущностью одним и тем же отношением.

Например, если в графе есть связи

(Ханс Циммер — написал музыку для — «Пираты Карибского моря») 

и 

(Ханс Циммер — написал музыку для — «Интерстеллар»), 

то можно задать вопрос: «Для каких фильмов Ханс Циммер писал музыку?» 

Ответ: «Пираты Карибского моря», «Интерстеллар».

3. Multi-hop. В этом варианте вопроса несколько фактов связываются через промежуточную сущность. Используется два триплета, которые пересекаются по одной и той же сущности. При этом в самом вопросе эта сущность не упоминается. 

Например, если в графе есть связи
(FAW — страна происхождения — Китай) 

и
(FAW — продала автомобилей в 2023-м — 2139),

то можно задать вопрос: «В какой стране находится компания, продавшая 2139 автомобилей в 2023 году?»
Ответ: Китай.

4. Conditional. Этот тип вопроса можно рассматривать как развитие multi-hop, но в нем используются сразу оба факта.

Как и раньше, берутся два триплета, пересекающиеся по одной сущности. Однако теперь эта сущность становится ответом, а в вопрос выносятся оба условия.

Например, если в графе есть связи
(Роман Мирошниченко — выступал в — M-bar) 

и
(Роман Мирошниченко — встречался с — Дмитрий Дибров),

то можно задать вопрос: «Кто выступал в M-bar и встречался с Дмитрием Дибровым?»
Ответ: Роман Мирошниченко.

В итоге у нас есть способ собирать набор QA-пар разной сложности. Но все ли они будут адекватными и можно ли их сразу использовать в бенчмарке? Конечно, нет.

Проверка качества QA

Во-первых, сгенерированные вопросы нужно проверить на базовую адекватность. Для этого используется модель RuRoBERTa-large, обученная на датасете RuCoLa: она помогает отсеять грамматические ошибки и неестественные формулировки.

Следом тексты проходят проверку на наличие именованных сущностей (NER) с помощью библиотеки Natasha.

Следующим этапом нужно исключить слишком простые вопросы, на которые LLM может ответить просто по памяти, без обращения к контексту. Для такой проверки вопросы прогоняют через небольшие модели (Qwen 2.5 7B и LLaMa 3 8B). Если модель справляется сама, вопрос исключается из выборки.

Но главная проверка качества QA-пар ложится на модель POLLUX 7B. Здесь авторы применили отлично зарекомендовавший себя подход LLM-as-a-Judge. Модель выступает в роли оценщика и выставляет каждому примеру от 0 до 2 баллов по таким критериям, как грамотность, естественность, правильность и, что особенно важно, зависимость от контекста.

Закономерный вопрос: насколько можно доверять такой автоматической оценке? Чтобы это выяснить, авторы провели эксперимент, в котором 532 случайных примера оценивали параллельно и модель, и эксперты. Вопрос считался хорошим, если он получал положительный балл хотя бы от половины аннотаторов.

POLLUX 7B показала высокую точность (Precision), но умеренную полноту (Recall) по сравнению с человеческой разметкой. Проще говоря, модель судит строго: она надежно отбирает качественные пары, но иногда перестраховывается и бракует нормальные, чуть менее очевидные примеры. И для создания бенчмарка это не проблема: пусть в выборку попадет меньше вопросов, зато их качество будет гарантированно высоким.

После всех этапов фильтрации для финального набора бенчмарка отбирается только 150 высококачественных вопросов на каждую категорию.

Оценка RAG-систем на бенчмарке DRAGOn

Когда архитектура бенчмарка готова, настало самое время проверить, как вся эта конструкция ведет себя в реальных условиях, на настоящих RAG-системах.

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

Оценка качества поиска

Для оценки того, насколько хорошо система находит нужные документы, использовались две метрики: Hit Rate и Mean Reciprocal Rank (MRR). Hit Rate измеряет долю запросов, для которых в топ-N результатов находится правильный документ, а MRR оценивает, насколько высоко в списке находится релевантный документ.

Результаты: в лидеры по обоим критериям выбились связки с использованием моделей Qwen 3Embedding 8B и E5 Mistral7B Instruct. Они увереннее всего вытаскивали нужные факты из базы, что для RAG-системы является буквально фундаментом успеха.

Оценка качества генерации

С генерацией ответов все немного хитрее. Базово качество текстов замеряли классическими метриками ROUGE-2 и ROUGE-L. ROUGE-2 оценивает совпадение биграмм между сгенерированным и эталонным ответом, а ROUGE-L замеряет самую длинную общую последовательность слов.

Но механическое совпадение слов — это не всегда показатель хорошего результата. Поэтому главная ставка здесь была сделана на Judge Score, который снова рассчитывала модель POLLUX 7B. В отличие от прямолинейных метрик вроде ROUGE, LLM-судья смотрит на результат целиком. Он оценивает правильность, полноту ответа и то, насколько модель действительно опиралась на найденный контекст, а не фантазировала от себя.

Итоговый вывод отлично подтверждает базовое правило RAG: какой контекст подашь, такой ответ и получишь. Системы с сильным поисковым модулем (те же Qwen и E5 Mistral) ожидаемо показали и самое высокое качество финальной генерации. Если поисковик нашел правильные данные, то и с формулировкой ответа у модели проблем не возникает.

Публичный лидерборд

Поэтому авторы не остановились на полпути и добавили публичный лидерборд для оценки RAG-систем на своем бенчмарке. Исследователи могут отправлять свои результаты через специальную библиотеку rag_bench, которая доступна на PyPi.

Лидерборд делится на публичную и приватную части. Публичная часть доступна для всех, и именно там можно увидеть результаты моделей, которые прошли оценку. Приватная часть используется для внутренней проверки, чтобы результаты можно было точно и без ошибок сопоставить с эталонными данными. 

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

Ограничения, проблемы и практические выводы

Конечно, универсальных решений не бывает, и у предложенного подхода есть свои ограничения.

Во-первых, в настоящий момент бенчмарк фокусируется на русскоязычных новостях. И хотя сама архитектура позволяет перенести этот подход на другие сферы (медицину, юриспруденцию или научные публикации), текущая реализация опирается на новостной поток, содержание которого однозначно отличается от других доменов.

В-вторых, подход LLM-as-a-Judge отлично автоматизирует и ускоряет работу, но автоматическая проверка все еще не может полностью заменить человека-эксперта. Как показал эксперимент, модель-судья иногда перестраховывается и отбраковывает вполне корректные вопросы.

Но несмотря на эти ограничения, DRAGOn предлагает рабочее и прозрачное решение одной из главных проблем оценки RAG-систем. Вместо статических датасетов, которые быстро устаревают, авторы создали динамический, постоянно обновляемый полигон, максимально приближенный к реальным условиям.

Еще раз кидаю ссылку на статью: https://arxiv.org/pdf/2507.05713

И для цитирования:
Fedor Chernogorskii, Sergei Averkiev, Liliya Kudraleeva, Zaven Martirosian, Maria Tikhonova, Valentin Malykh, and Alena Fenogenova. 2026. DRAGOn: Designing RAG On Periodically Updated Corpus. In Proceedings of the 19th Conference of the European Chapter of the Association for Computational Linguistics (Volume 4: Student Research Workshop), pages 622–638, Rabat, Morocco. Association for Computational Linguistics.

В посте упоминаются LLM, разработанные компанией Meta Platforms, признанной экстремистской и запрещенной в РФ.