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

В этой статье мы посмотрим на результаты экспериментов: какие техники оказались наиболее эффективными на датасете Natural Questions, где они приятно удивили, а где — наоборот, не оправдали ожиданий. Для оценки будем использовать фреймворк RAGAS, а также метрики BertScore и ROUGE-2 для анализа релевантности извлечённых чанков и финальных ответов.

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

TL;DR: В данной статье мы

1. Разобрали, что может повлиять на качество работы LLM-as-a-Judge (ссылка).

2. Оценили каждую технику с помощью RAGAS (ссылка), BertScore (ссылка), ROUGE-2 (ссылка).

3. Кратко проанализировали показатели оценок для каждой техники (ссылка). Такие техники, как HyDE, Fusion Retrieval и Reranking RAG хорошо показали себя как в оценках контекста, так и в оценках ответов.

4. Поэкспериментировали с разными шкалами для Reranking RAG (ссылка). Оказалось, что лучше всего отработал реранкер с пятибалльной шкалой, опередив реранкеры с двухбалльной, трёхбалльной и непрерывной (на отрезке ) шкалами.

Глава 2. Сравнение RAG техник на датасете Natural Questions

Передо мной стоял выбор — использовать бесплатную, но медленную и менее сильную LLM или воспользоваться быстрой, относительно мощной, но платной. В итоге, я решил, что гулять так гулять и закупился токенами для GigaChat Lite. Поэтому здесь и далее все вычисления, связанные с LLM будут проходить на GigaChat. В качестве векторной базы данных будем использовать Qdrant, а в качестве векторизатора BGE-M3.

Определение объёмов выборки.

Для оценки RAG-техник мы будем использовать выборку из 200 валидационных вопросов. Такое число было выбрано, как компромисс между информативностью оценки и практическими ограничениями (стоимость запросов к LLM через API). В качестве эмпирического обоснования решения возьмём 500 ответов стандартной RAG-системы и оценим их на верность по бинарной шкале (1 — ответ системы равносилен эталонному ответу, 0 — иначе). Оценки получались с помощью той же LLM GigaChat (хоть в качестве LLM as a judge не совсем правильно использовать ту же модель). Для большего эффекта вектор из 500 оценок перетасуем 5 раз и посчитаем накопительные средние доли верных ответов:

# evals - вектор из 500 оценок 
cumulative_average = []

for i in range(1, len(evals)):
    cumulative_average.append(np.mean(evals[:i]))

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

Настройка LLM для оценок (LLM as a judge)

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

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

Сравнение подходов к оцениванию.

Первый эксперимент был проведён с локальной моделью Qwen2.7-8b, которая в базовой конфигурации показала лишь 62% совпадений с моей разметкой. Анализ промпта показал, что модель часто залипала на тексте самого вопроса и выносила решение, ориентируясь не на соответствие ответа эталону, а на правдоподобности, ответа.

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

В финале я протестировал модель GigaChat, которая в аналогичной настройке достигла 92% совпадений, а при добавлении примеров удалось достичь 96%. Такого результата достаточно для того, чтобы использовать GigaChat как судью в основном эксперименте.

RAGAS

Один из самых популярных фреймворков, позволяющий проводить end-to-end оценки работы RAG систем. Имеет поддержку большого количества необходимых метрик, которых хватает для понимая слабых и сильных сторон системы. В данном исследовании рассмотрим такие метрики, как Faithfulness, Context Precision, Context Recall и Correctness.

Не будем углубляться в разбор данного фреймворка и метрик, потому что про это я уже писал здесь. Сразу перейдём к таблице результатов.

Или если удобнее смотреть на графики:

Давайте разбираться с результатами. Первая метрика — Faithfulness, которая показывает согласованность между ответом LLM и данным ей контекстом. Грубо говоря, если ответ содержит в себе только те факты, которые есть в контексте, то данная метрика будет высокой. Почти все техники лежат в диапазоне 0.66-0.73. Особо выбивается из данного диапазона, как и во всех метриках, Proposition Chunking, но о нём поговорим позже. Также особо высокую оценку имеет Query Decomposition, но это можно объяснить конструктивной особенностью. Контекстом для данной техники являются ответы на подзапросы.

Например, можно рассмотреть следующий вопрос из выборки (сразу перевёл для удобства):

Вопрос:
Какой длины знаменитый подвесной мост в Сан-Франциско и как он называется?

Подзапросы:
Как называется знаменитый подвесной мост в Сан-Франциско?
Какой длины знаменитый подвесной мост в Сан-Франциско?

Ответы (Контекст для итогового ответа):
Знаменитый подвесной мост в Сан-Франциско называется мост Золотые ворота.
Общая длина моста Золотые ворота от устоя до устоя составляет 8 981 фут (2 737 м).

Итоговый ответ:
Знаменитый подвесной мост в Сан-Франциско называется мост Золотые ворота, и его общая длина от опоры до опоры составляет 8 981 фут (2 737 м).

Как мы видим, контекст уже содержит самые необходимые факты без шума. Поэтому метрика Faithfulness выше среднего. Однако тут плюсы заканчиваются. У техники относительно высокий Context Precision, но низкий Context Recall. Для простоты понимая, можно описать данные метрики так:

• Precision отвечает на вопрос: «То, что мы нашли, действительно нужно?»

• Recall отвечает на вопрос: «Мы нашли всё, что нужно?»

И, как мы видим, данная техника путём разбиения запроса на подзапросы иногда достаёт нужную, но не полную информацию. Это можно увидеть на примере:

Запрос:
Кто дольше всех работал модератором на «Встрече с прессой»?

Подзапросы:
Кто был первым модератором на «Встрече с прессой»?
Кто был последним модератором на «Встрече с прессой»?

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

Перейдём к изучению низких оценок Faithfulness у техники Proposition Chunking. Напомню, что для данной техники из каждого чанка достаются факты в виде предложений. Рассмотрим конкретный пример:
Вопрос:
Какой длины знаменитый подвесной мост в Сан-Франциско и как он называется?

Контекст
Сан-Франциско - это город в США.
Статуя свободы находится в Лос-Анджелесе.
Статуя свободы, находящаяся в Лос-Анджелесе стоит уже более 100 лет
....
Знаменитым подвесным мостом в Сан-Франциско является мост Золотые ворота. Его общая протяженность составляет 1,7 мили (2,7 километра).

Если изначальная векторная база документов уже имела крупные размеры (~40k чанков), то векторная база, состоящая из фактов, имела уже (~90k чанков). Довольно много времени занимает простое формирование такой базы (+ фильтрация некорректных фактов), я уже не говорю про удаление дубликатов, которых в данном методе плодится приличное количество. Поэтому на выходе мы получаем то, что работать с семантическим сходством становится очень сложно (вспомним про фундаментальные ограничения ретриверов, основанных на эмбеддинг моделях). Из-за этого в контекст попадает много нерелевантных чанков (например, про статую свободы).

Поэтому Proposition Chunking будет хорошо работать на небольших объемах данных, в которых пользователям будут требоваться короткие факты. А текущий датасет не совсем подходит для Proposition Chunking техники, так как в статьях Википедии много шума.

Следующая метрика — Context Precision. На данной метрике мы видим просадку в таких техниках, как Dartboard RAG, Context Window Enhancement и Relevant Segment Extraction. Этот факт говорит о том, что в контексте много ненужной информации. Такую просадку легко объяснить:

• В Dartboard RAG контекст формируется из чанков, которые не только семантически похожи на запрос, но и семантически отличны от уже отобранных чанков.

• В Context Window Enhancement мы всегда добавляем соседние чанки, что добавляет не всегда релевантную информацию. Как я говорил, такой метод хорош при работе с документами или отчётами, в которых на одной странице чаще всего размещается близкая по смыслу информация.

• В Relevant Segment Extraction могут добавляться чанки, которые находятся между релевантными, что добавляет лишней информации.

В среднем, техники имеют оценку, близкую к 0.5-0.6, что не совсем хорошо. На примере простого RAG можно разобрать, как это подправить. Если в контексте много шума, то, значит, некоторые чанки оказываются лишними и для формирования ответа они не нужны. Поэтому при сокращении количества чанков в простом RAG с 10 до 5 можно добиться следующих метрик:

• Faithfulness: 0.73 (было 0.68),

• Context Precision: 0.59 (было 0.56),

• Context Recall: 0.75 (было 0.72),

• Correctness значимо не поменялась.

Ещё один способ — уменьшить длину чанков, что также снизит объём шума в контексте.

Следующая метрика — Context Recall. Почти все техники довольно близко расположены друг к другу. Выделить можно HyDE, который имеет низкую метрику Context Precision, но высокую Context Recall. Объяснить такие результаты можно следующим примером:

Вопрос:
Кто первый получил Нобелевскую премию по физике?

Потенциальный ответ: (Ответ неверный)
Альберт Эйнштейн получил первую Нобелевскую премию по физике в 1901 году за свою новаторскую работу по фотоэлектрическому эффекту, которая заложила основу квантовой теории. Его новаторские теории произвели революцию в физике и принесли ему всемирное признание

Контекст, полученный для потенциального ответа:
Чанк про Эйнштейна
Чанк про Эйнштейна
Первая Нобелевская премия по физике была присуждена в 1901 году Вильгельму Конраду Рентген из Германии...
...

Как мы видим, несмотря на то, что потенциальный ответ неверный, он помог достать релевантный чанк. Ценой является шум в контектсе (чанки про Эйнштейна). Именно этот шум понижает Context Precision. Но LLM может в качестве потенциального ответа дать и правильный ответ, который достанет релевантные чанки. Такое очень помогает, если вопросы пользователей касаются открытых и распространённых фактов (как в данном датасете). Однако, если мы имеем дело с закрытыми или узкими знаниями, то ответ LLM может быть сильно поверхностным. Например, «Какой номер у справки X?» — точный номер справки LLM не знает, а угадывание мало поможет, хотя всё нужно проверять.

Основной метрикой является Сorrectness, которая показывает долю верных ответов. Метрика высока у техник HyDE, Fusion Retrieval, Relevant Segment Extraction, Dartboard RAG и Reranking, поэтому можно считать, что для текущего датасета эти техники работают хорошо.

Больше графиков

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

Как видно из графика, Context Precision и Correctness не имеют корреляции. Также можно увидеть, как техники образуют кластера:

• Кластер с излишним контекстом (Dartboard RAG, Context Window Enhancement, Relevant Segment Extraction)

• Кластер с техниками, близкими к обычному RAG (Semantic Chunking — простой RAG, но с другим разбиением на чанки, Query Transformation\Decomposition — тоже простой RAG, но с изменением запроса пользователя). Рядом находится Reranking RAG, который отличается от обычного RAG тем, что нерелевантные (по мнению LLM) чанки удаляются.

• Кластер с HyDE и Fusion Retrieval.

Можно заметить те же кластеры, но более растянутые. Корреляция довольно слабая, в основном на неё повлияла Query Decomposition. Также и на графике ниже.

BertScore.

Чтобы не полагаться только на RAGAS оценки, которые зависят от работы LLM, воспользуемся ещё одной метрикой — BertScore, с помощью которой мы оценим релевантность контекста и ответа. Данная метрика работает на предобученной языковой модели, которая также, как и LLM, способна улавливать семантические связи.

В датасете Natural Questions помимо Short Answer есть также Long Answer, который представляет из себя отрывок из статьи, в котором находится ответ по мнению аннотатора. Поэтому мы будем брать каждый полученный чанк и сравнивать с Long Answer при помощи BertScore. Итоговый ответ будем сравнивать, как и в RAGAS, с Short Answer. Результаты можно увидеть ниже.

Как мы видим, для BertScore метрики ранжировки остаются похожими. Опять Fusion Retrieval, Reranking RAG и HyDE показали хорошие результаты.

ROUGE.

Ради интереса посмотрим ещё на метрику ROUGE-2.

ROUGE-2 — это классическая метрика, которая сравнивает биграммы между сгенерированным текстом и эталоном. Эта метрика проста и интерпретируема: чем больше слов совпало, тем лучше. Но она не учитывает семантику, чувствительна к перефразированиям и ошибкам.

Как и в прошлых метриках, можно выделить 4 метрики, которые отработали лучше остальных: Fusion Retrieval, Reranking RAG и HyDE.

Корреляции между метриками

Как и предполагалось, корреляция между метриками присутствует. Можно также заметить, что ROUGE-2 ближе остальных ROUGE (1 и 3) к остальным метрикам. Между собой же метрики ROUGE очень близки, поэтому можно смотреть только на ROUGE-2.

Между метриками контекста же корреляция слабее. Механизм оценки релевантности с метриками BertScore и ROUGE был простроен на оценке чанков относительно эталонного отрывка текста, поэтому можно заметить корреляцию с Context Precision и обратную корреляцию с Context Recall.

Вывод.

Если собрать все метрики и отранжировать техники, то получится таблица ниже:

Здесь 1, 2, 3 — ранги по определённой метрике (меньше — лучше).

Из данной таблицы видно, что техники HyDE, Fusion Retrieval и Reranking RAG хорошо показывают себя как в контекстных метриках, так и в метриках для ответов.

Давайте подведём итог работы каждой техники на датасете Natural Questions:

SimpleRAG

Работает заметно лучше простой LLM (Доля верных ответов с 52% увеличилась до 70%). Просто реализуется, по времени работает почти также, как и простая LLM (0.4 секунды на запрос). «Из коробки» может показывать хороший результат.

Query Transformation

По сути это тот же простой RAG, только вопрос пользователя немного корректируется, если это необходимо. Пример:
Вопрос:
how many tornado planes does the uk have

Скорректированный вопрос:
How many UK military tornado aircraft are there?

Собственно, поэтому можно заметить небольшое (с учётом погрешностей) улучшение релевантности контекста (особенно заметно на метрике ROUGE-context +60%), но качество ответа остаётся примерно одинаковым, это связано с тем, что появляется слабое звено в виде LLM, преобразующей запрос. Некоторые вопросы LLM может неверно переформулировать. Например, уже на первом вопросе из датасета можно обнаружить следующее:
Вопрос:
who got the first nobel prize in physics

Скорректированный вопрос:
Who received the first Nobel Prize in Physics in 1901?

Как будто бы всё правильно, это событие, действительно, произошло в 1901, но пользователь это не имел в виду, поэтому ситуация довольно спорная. И чтобы модель решала даже такую несложную задачу так, как вам нужно, лучше потратить время и протестировать данный модуль получше, потому что он напрямую подаёт свой вывод в retrieval-модуль.

Query Decomposition

По характеристикам данная техника близка к предыдущей. Отлично работает на сложных вопросах, но приходится расплачиваться дороговизной. Относительно обычного RAG время работы увеличивается почти на 60% (c 1.6 до 2.8 секунд на запрос). Как я уже говорил, на данном датасете техника отработала не лучшим образом (результаты близки к простому RAG) из-за простых вопросов, не требующих разбиения на подзапросы. Также стоит понимать, что данная система будет работать хуже из-за своей параллельности. Вспомним пример:

Запрос:
Кто дольше всех работал модератором на «Встрече с прессой»?

Подзапросы:
Кто был первым модератором на «Встрече с прессой»?
Кто был последним модератором на «Встрече с прессой»?

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

HyDE

Входит в топ лучших техник в данном исследовании. Причиной может быть то, что пропадает семантический разрыв между вопросом и повествовательно изложенными чанками. Время работы по сравнению с простой RAG увеличивается примерно на 40%, но и существенно увеличивается доля верных ответов (0.7 → 0.76) и ROUGE-answer метрика (0.06 → 0.14).

Relevant Segment Extraction

Также хорошо себя показала данная техника. Почти на всех scatter-графиках видно улучшение качества ответов (correctness: 0.7 → 0.74), однако похуже, чем HyDE. Но RSE не требует дополнительных вызовов LLM. Однако, сложность появляется при поиске чанков, так как для этого нужно получить их все и обработать, поэтому необходимо проводить оптимизацию, чтобы это не занимало столько времени, сколько у меня.

Context Window Enhancement

Как и RSE, данная техника добавляет шум в контекст, что видно по метрике RAGAS-Precision, но этот шум может нести в себе полезную информацию (что видно по Recall), которая увеличивает качество ответов (на метриках RAGAS и BertScore). По времени CWE работает также, как и простой RAG, но если не уменьшить количество чанков, которые изначально достаются, то можно в 3 раза увеличить объём контекста, по сравнению с простой RAG, что может бить по качеству работы LLM и дороговизне одного ответа. Поэтому в данном исследовании количество получаемых чанков был уменьшен в 3 раза (10 → 3).

Semantic Chunking

Семантическое чанкирование в текущем исследовании не дало особого преимущества, из-за строения документов. Статьи на Википедии зачастую довольно хорошо структурированы и каждый абзац несёт в себе новую мысль. По этой причине хорошо срабатывает обычное рекурсивное разбиение (RecursiveCharacterTextSplitter). Настроить же рекурсивное разбиение было сложно, из-за того, что в текстах бывают слишком бесполезные участки (длинные перечисления или источники с огромным количеством строк). Поэтому при увеличении значения точки разбиения (breakpoint_threshold_type) получались огромные куски текста, в котором размывалась семантика, а при уменьшении раздувалось общее количество чанков, что приводило к ситуации с Proposition Chunking. Из этого следует, что для данной техники нужно иметь чистые тексты без шума или заранее очищенные тексты.

Fusion Retrieval

Одна из лучших на данном датасете техник, которая выбивает 76% верных ответов и работает со скоростью обычного RAG (следовательно, и потребляет токенов примерно столько же). Как уже говорил в прошлой части, Fusion Retrieval совмещает в себе плюсы семантических поисковиков с полнотекстовыми, что критично при больших базах данных. Однако, для этой техники зачастую необходимо добавлять Reranker-модуль (смешивание техник в данном исследовании затрагивать уже не будем), который поможет справиться с шумом.

Reranking RAG

Из-за фильтрации чанков данная техника имеет хорошие показатели метрик, связанных с контекстом. Но по метриками, оценивающим ответ, есть небольшое отставание от лидера (0.73 простив 0.76 у лидера). Сложным является процесс настройки промпта и процесса оценки, чтобы релевантные чанки не удалялись, а нерелевантные не попадали в контекст.

Довольно спонтанно пришёл в голову вопрос, а какую шкалу оценки лучше использовать? В текущем исследовании чанки получали только 2 оценки — 1, если чанк относится к вопросу и 0 иначе. Но что если расширить шкалу? Поэтому давайте сравним реранкер с двумя оценками (0 и 1), с тремя оценками (0, 2, 4), пятью оценками (0, 2, 4, 6, 8) и с непрерывной шкалой оценивания (оценки принимают значение из отрезка ). Проверять будем только основную метрику — correctness. Результаты получились следующими:

• Реранкер с двумя оценками: 73% верных ответов.

• Реранкер с тремя оценками: 73% верных ответов.

• Реранкер с пятью оценками: 77% верных ответов.

• Реранкер с непрерывной шкалой оценивания: 73% верных ответов.

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

Давайте ещё вспомним статью про то, что некоторые LLM лучше работают, когда релевантные чанки идут в конце. Давайте и это проверим. Возьмём реранкер с пятью оценками, но порядок чанков будем инвертировать. Также замерим correctness. Результаты получились следующими:

• Реранкер с пятью оценками: 77% верных ответов.

• Реранкер с пятью оценками: 71% верных ответов.

Результат ожидаем, но попробовать всё равно стоило.

Dartboard RAG

В среднем, отработала данная техника чуть лучше просто RAG с точки зрения RAGAS и BertScore, хотя из-за внесения разнообразия в контекст видно, что проседают метрики, связанные с контекстом, что говорит о зашумлённости. Поэтому было бы хорошо добавлять Reranker-модуль для фильтрации.

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

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

Спасибо, что дочитали до конца! Всем терпения и вдохновения в собственных экспериментах :)

P.S. У меня осталось ещё немало идей для экспериментов. Если вам интересен этот формат, буду рад видеть вас в моём Telegram-канале — там я делюсь промежуточными результатами и наблюдениями, которые не всегда попадают в статьи.