RAG Fusion: умное расширение запросов

Короткая версия

RAG Fusion особенно полезен, когда:

• запрос неоднозначный или слишком широкий;
• в документах много разных формулировок одной темы;
• запросы мультиязычные или смешанные;
• single-query retrieval теряет recall.

Как это работает

1. Берём исходный вопрос.
2. Генерируем 3-5 query variants.
3. Ищем по каждому отдельно.
4. Объединяем результаты через RRF.
5. Потом optional reranking или generation.

Исходный запрос: «как уменьшить расходы на LLM»

Query variants:
1. снижение затрат на inference LLM
2. оптимизация стоимости API вызовов языковых моделей
3. уменьшение token spend в LLM-приложении
4. cost optimization для GPT и Claude

Где техника особенно уместна

• support knowledge bases;
• enterprise search с разной терминологией у отделов;
• technical corpora с RU/EN смешением;
• research-style retrieval по широким вопросам.

1. Почему одного запроса часто недостаточно

Single-query retrieval хрупок по простой причине: пользователь выбирает одну формулировку, а corpus может использовать совсем другую.

Типичные failure modes:

• пользователь говорит “расходы”, а документы говорят “cost optimization”;
• пользователь пишет по-русски, а часть документации на английском;
• support team и product docs описывают одно и то же разными словами;
• вопрос слишком широкий и затрагивает несколько подтем.

RAG Fusion полезен именно здесь: он не меняет corpus, а увеличивает шансы retrieval попасть в правильные lexical/semantic районы индекса.

2. Что RAG Fusion реально делает

Практически это не “генерация правильного одного запроса”, а:

• query expansion;
• paraphrase diversification;
• retrieval over multiple formulations;
• result fusion.

То есть это retrieval-side техника, а не generation-side.

Если формализовать:

user query
-> generate query variants
-> retrieve per variant
-> fuse rankings
-> optional rerank
-> send final context to LLM

3. Почему это поднимает recall

Каждая формулировка активирует немного другой сигнал:

• одна лучше ловит exact terms;
• другая — семантические синонимы;
• третья — англоязычные документы;
• четвёртая — более абстрактный angle.

Поэтому multi-query retrieval часто находит:

• больше релевантных кандидатов;
• больше разных типов кандидатов;
• меньше зависимости от wording bias.

Именно в этом смысле RAG Fusion — это recall-first техника.

4. Fusion почти всегда лучше, чем просто склеить результаты

Если просто объединить все найденные документы, retrieval быстро утонет в шуме. Поэтому нужен слой fusion:

• одинаковые документы, найденные несколькими запросами, должны подниматься выше;
• уникальные находки должны сохраняться, но не доминировать;
• результат должен быть совместим с downstream reranking и context budgeting.

Именно поэтому RRF так хорошо ложится на RAG Fusion: он повышает документы, которые стабильно всплывают в нескольких rankings.

5. RAG Fusion, HyDE и Sub-question retrieval — не одно и то же

Их часто смешивают, но practical разница важна:

RAG Fusion

Расширяет исходный запрос несколькими формулировками.

HyDE

Генерирует гипотетический ответ или document-like representation и ищет по нему.

Sub-question retrieval

Разбивает сложный вопрос на подвопросы и ищет по каждой части отдельно.

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

• Fusion полезен для paraphrase diversity;
• HyDE полезен, когда query слишком короткий и нужен answer-shaped retrieval hint;
• Sub-question полезен, когда вопрос реально составной и требует нескольких фактов.

6. Когда RAG Fusion особенно хорош

Широкие вопросы

Например:

• “как сделать LLM дешевле”;
• “почему нейросети галлюцинируют”;
• “как улучшить качество RAG”.

Один запрос обычно не покрывает все релевантные подаспекты.

Мультиязычные корпуса

Если часть данных на русском, часть на английском, разные query variants помогают retrieval добраться до обоих слоёв корпуса.

Разнородная терминология

Это особенно типично для enterprise knowledge bases, где разные команды описывают одно и то же разными словами.

7. Когда техника не нужна или вредна

Есть случаи, где query expansion скорее мешает:

• точные коды ошибок;
• артикулы;
• SKU;
• API names;
• exact legal clauses;
• highly precise navigational queries.

Там слишком широкий multi-query retrieval может только разбавить результат лишним шумом.

То есть RAG Fusion лучше воспринимать как selective tool, а не как universal retrieval default.

8. RAG Fusion хорошо сочетается с hybrid retrieval

Очень сильная practical комбинация:

1. multi-query expansion;
2. dense + sparse retrieval по каждому варианту;
3. fusion внутри одного query branch или после него;
4. final reranking.

Это уже не “одна техника”, а настоящий recall pipeline. И именно в этой форме RAG Fusion чаще всего даёт наибольшую пользу в production.

9. Как оценивать эффект

Не по тому, что запросы “стали умнее”.

Нужно смотреть:

• recall@k;
• unique relevant docs found;
• downstream groundedness;
• cost and latency overhead;
• no-answer behavior;
• retrieval noise growth.

Если Fusion добавил recall, но удвоил noise и не улучшил final answer, это плохой tradeoff. Если он стабильно приносит missing evidence chunks и улучшает groundedness — это уже сильный retrieval win.

Минимальный multi-query retrieval loop

queries = [
    "как уменьшить расходы на LLM",
    "снижение затрат на inference LLM",
    "оптимизация стоимости API вызовов языковых моделей",
]

all_rankings = [retrieve(q) for q in queries]
fused = reciprocal_rank_fusion(*all_rankings)
top_docs = fused[:5]

LangChain-style path

from langchain.retrievers.multi_query import MultiQueryRetriever

retriever = MultiQueryRetriever.from_llm(
    retriever=base_retriever,
    llm=llm,
)

docs = retriever.invoke("как уменьшить расходы на LLM")