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

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

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

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

• Большинство бенчмарков используют фиксированные корпусы, которые со временем устаревают и перестают отражать реальность.
• Невозможно точно определить, какой компонент — поиск или генерация — повлиял на результат.
• Высокое качество может быть обусловлено не архитектурой, а тем, что языковая модель уже «знает» ответ из обучающих данных.
• Сбор пар «вопрос — ответ» требует ручной разметки, что трудоёмко и плохо масштабируется.

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

Идея DRAGOn

Ключевая проблема — отсутствие независимости тестовой выборки. DRAGOn решает её, создавая бенчмарк на основе новых знаний. Методология включает три основных элемента:

• Регулярно обновляемый корпус документов, отражающий актуальную информацию.
• Автоматизированная генерация QA-пар для масштабируемости и непрерывного обновления.
• Публичный лидерборд для прозрачного и единообразного сравнения систем.

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

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

Данные регулярно парсятся из внешних источников, например, новостных агрегаторов. Затем проходят три этапа обработки:

• Извлечение атомарных фактов.
• Фильтрация уже известных знаний.
• Генерация QA-пар разной сложности.

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

С помощью LLM (LLaMa 3.3 70B Instruct) тексты преобразуются в триплеты вида «субъект — предикат — объект», например:

• (Apple — выпустила — iPhone 15)
• (Илон Маск — возглавляет — SpaceX)

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

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

Из графа новых фактов генерируются QA-пары четырёх типов:

• Simple — вопросы по одному факту. Например: «Кто возглавляет SpaceX?» → «Илон Маск».
• Set — вопросы с перечислением. Например: «Для каких фильмов Ханс Циммер писал музыку?» → «Пираты Карибского моря», «Интерстеллар».
• Multi-hop — вопросы, требующие логического перехода через промежуточную сущность. Например: «В какой стране находится компания, продавшая 2139 автомобилей в 2023 году?» → «Китай».
• Conditional — вопросы с двумя условиями. Например: «Кто выступал в M-bar и встречался с Дмитрием Дибровым?» → «Роман Мирошниченко».

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

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

• Проверка на грамматику и естественность с помощью модели RuRoBERTa-large.
• Анализ именованных сущностей с помощью библиотеки Natasha.
• Отсеивание «слишком простых» вопросов: если небольшая модель (Qwen 2.5 7B или LLaMa 3 8B) отвечает правильно без контекста, вопрос исключается.
• Финальная оценка с помощью модели POLLUX 7B, выступающей в роли судьи (LLM-as-a-Judge). Она оценивает каждую пару по шкале от 0 до 2 баллов по критериям: грамотность, естественность, правильность и зависимость от контекста.

Чтобы проверить надёжность автоматической оценки, 532 примера параллельно оценили модель и эксперты. POLLUX 7B показала высокую точность, но умеренную полноту: она строго отбирает качественные пары, иногда отбрасывая допустимые, но менее очевидные. Для бенчмарка это приемлемо — важнее качество, чем количество.

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

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

Авторы разделили оценку на два этапа: поиск и генерация.

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

Использовались метрики:

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

Лучше всего показали себя модели Qwen 3 Embedding 8B и E5 Mistral7B Instruct. Они наиболее эффективно находили нужные факты — ключевой элемент для RAG.

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

Качество ответов измерялось через:

• Классические метрики ROUGE-2 и ROUGE-L, оценивающие совпадение биграмм и наибольшей общей последовательности слов.
• Судейский балл (Judge Score) от модели POLLUX 7B, которая оценивает правильность, полноту и опору на контекст, а не на «внутренние знания» модели.

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

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

Авторы запустили публичный лидерборд, доступный через библиотеку rag_bench на PyPi. Он разделён на две части:

• Публичная — отображает результаты участников.
• Приватная — используется для внутренней проверки и сопоставления с эталонами.

Это обеспечивает прозрачность, воспроизводимость и удобное сравнение решений. Платформа автоматически обновляется, способствуя быстрому обмену опытом.

Ограничения и выводы

У DRAGOn есть ограничения:

• Пока бенчмарк ориентирован на русскоязычные новости. Хотя архитектура позволяет адаптацию к другим доменам (медицина, юриспруденция), текущая реализация привязана к новостному контенту.
• Автоматическая оценка (LLM-as-a-Judge) ускоряет процесс, но не заменяет эксперта полностью. Модель-судья может быть излишне строгой.

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

Привет, Хабр! В этот раз предлагаю разбор научной статьи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. InProceedings 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, признанной экстремистской и запрещенной в РФ.