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

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

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

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

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

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

Идея DRAGOn

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

Основа подхода — три ключевых элемента:

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

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

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

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, обученной на RuCoLa.
• Анализ именованных сущностей с помощью библиотеки Natasha.
• Фильтрация «слишком простых» вопросов: если небольшая модель (например, Qwen 2.5 7B) отвечает правильно без контекста — вопрос исключается.
• Финальная оценка с помощью POLLUX 7B по методу LLM-as-a-Judge. Модель выставляет от 0 до 2 баллов за грамотность, естественность, правильность и зависимость от контекста.

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

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

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

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

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

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

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

Лучшие результаты показали модели Qwen 3Embedding 8B и E5 Mistral7B Instruct — они наиболее эффективно находили нужные факты.

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

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

• Классических метрик ROUGE-2 и ROUGE-L, оценивающих совпадение биграмм и наибольшей общей последовательности слов.
• Судейской оценки от 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-систем. Вместо статических датасетов, которые быстро устаревают, авторы создали динамический, постоянно обновляемый полигон, максимально приближенный к реальным условиям.Еще раз кидаю ссылку настатьюИ для цитирования: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, признанной экстремистской и запрещенной в РФ.