Лучшие практики RAG: как собрать систему, которая действительно улучшает ответы LLM

Почему вокруг RAG так много шума и так мало системности

Retrieval-Augmented Generation давно стал базовым паттерном для AI-сервисов, которые должны работать не только на знаниях модели, но и на внешних данных: внутренней документации, базе знаний, свежих статьях, product-спецификациях, регламентах и отраслевых источниках.

Проблема в том, что в реальной разработке RAG слишком часто собирают как набор отдельных приёмов. Где-то добавляют vector search, где-то подключают reranker, где-то пробуют HyDE, а потом пытаются понять, почему система стала сложнее, дороже и медленнее, но не всегда заметно лучше.

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

Разбор ниже - это адаптированный и практический перевод ключевых выводов из исследования Searching for Best Practices in Retrieval-Augmented Generation. Не в формате академического пересказа, а в виде инженерской карты: что действительно важно при построении RAG-системы и как это можно применить в продукте.

Что вообще входит в современный RAG-пайплайн

Когда говорят "мы используем RAG", это может означать очень разные архитектуры. На практике пайплайн обычно состоит из нескольких этапов:

• query classification - определение, нужен ли retrieval для текущего запроса;

• chunking - разбиение документов на части для индексирования и поиска;

• vector storage - хранение embeddings и метаданных;

• retrieval - поиск кандидатов по запросу;

• reranking - уточнение порядка найденных документов;

• repacking - упаковка контекста в prompt в нужном порядке;

• summarization - сжатие или очистка контекста;

• generator fine-tuning - дообучение генератора под реальные условия retrieval.

Смысл исследования как раз в том, чтобы не спорить о "лучшем retriever в вакууме", а посмотреть на RAG как на последовательность взаимосвязанных решений. В такой системе слабый этап способен испортить результат даже при сильных соседних компонентах.

Главный вывод: хороший RAG это не трюк, а собранная система

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

Сильный retriever без reranking даёт неполную картину. Хороший reranker без продуманного chunking не спасает поиск. Большое контекстное окно не отменяет проблему шумных документов. А генератор, который видел только идеальный контекст, часто ведёт себя хрупко в реальной среде.

Если свести всё к одному тезису, он будет таким: зрелый RAG - это архитектура компромиссов между качеством, скоростью и стоимостью, а не набор модных AI-фич.

1. Retrieval нужен не для каждого запроса

Одна из самых практичных идей это не отправлять в retrieval всё подряд. Если запрос можно качественно обработать без внешних документов, поиск только добавит задержку и увеличит стоимость ответа.

Поэтому первым модулем в пайплайне логично делать query classification: система определяет, достаточно ли знаний модели и пользовательского контекста для ответа без внешнего поиска.

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

Практический эффект у такого подхода двойной:

• меньше latency - не нужно каждый раз идти в retriever, vector DB и reranker;

• меньше лишнего контекста - модель не перегружается документами там, где они не нужны.

Для продуктовой системы это один из самых недооценённых способов одновременно улучшить UX и сократить вычислительные расходы.

2. Chunking это один из самых важных слоёв в RAG

Chunking часто воспринимают как второстепенную настройку. На деле это один из ключевых факторов качества поиска.

Если chunks слишком большие, retriever получает слишком общий и тяжёлый контекст. Если слишком маленькие, то повышается шанс потерять смысловые связи между предложениями или абзацами. В обоих случаях страдает релевантность.

Наиболее разумным компромиссом выглядит sentence-level chunking. Такой подход сохраняет семантику лучше, чем агрессивное токеновое деление, и при этом остаётся заметно проще и дешевле, чем сложные LLM-based стратегии разбиения.

Ещё один важный момент - metadata. Заголовки, ключевые слова, связанные вопросы и дополнительная служебная информация могут заметно помочь retrieval-слою, особенно на больших и неоднородных данных.

Хороший практический вывод здесь такой: chunking нельзя выбирать абстрактно. Он должен зависеть от типа данных. Техническая документация, support-диалоги, юридические тексты и исследовательские статьи требуют разных размеров chunks, overlap и правил нарезки.

3. В retrieval побеждает гибридный подход

Один из самых сильных выводов - в реальной системе редко выигрывает только один тип поиска. Sparse retrieval и dense retrieval решают разные задачи, а вместе работают устойчивее.

Поэтому наиболее сильной базой для RAG оказывается hybrid search, где комбинируются:

• sparse retrieval - например, BM25 для точных лексических совпадений;

• dense retrieval - поиск по embeddings для смыслового соответствия.

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

Если смотреть на продакшен, hybrid search особенно хорош там, где данные неоднородные: часть данных структурирована, часть полуформальна, часть написана разными стилями, а часть содержит терминологию, которую нельзя терять при поиске.

4. HyDE может усиливать retrieval, но это не бесплатный апгрейд

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

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

Но здесь важно смотреть на trade-off. Да, Hybrid + HyDE даёт лучший результат по качеству. Одновременно это одна из самых тяжёлых конфигураций по времени ответа.

Из этого следует очень здоровая инженерная рекомендация:

• если приоритет максимум качества, стоит смотреть в сторону Hybrid + HyDE;

• если нужен баланс качества и скорости, чаще разумнее брать просто Hybrid без дополнительной генерации гипотетического документа.

То есть HyDE это не универсальный флаг "сделать RAG лучше", а инструмент, который имеет смысл включать там, где выигрыш по качеству оправдывает рост latency.

5. Reranking - обязательный слой для серьёзного качества

Обычный retrieval почти никогда не даёт идеальный порядок документов с первой попытки. Он может вернуть в целом подходящие фрагменты, но не гарантирует, что наверху окажется именно тот контекст, который нужен генератору.

Здесь и нужен reranking. Это второй этап, на котором найденные кандидаты переоцениваются более точной моделью.

Если упростить, retrieval отвечает на вопрос: "что вообще похоже на запрос?", а reranking - "что из этого действительно надо показать модели в первую очередь?".

Для практики важен следующий вывод:

• monoT5 хорошо подходит, когда нужен сильный баланс качества и общей полезности;

• TILDEv2 интересен там, где особенно важна эффективность и низкая стоимость reranking-слоя.

На уровне архитектуры это означает простую вещь: можно начать с не самого сложного retrieval, но без reranking качество почти всегда будет упираться в потолок.

6. В каком порядке подавать документы тоже важно

Даже после retrieval и reranking остаётся ещё одна недооценённая проблема: как именно упаковать найденный контекст в prompt.

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

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

Практический вывод очень полезный: даже хороший retrieval можно испортить плохой упаковкой в prompt. Если контекст выстроен неудачно, часть найденной пользы просто не доходит до генератора.

7. Summarization нужен не всегда, но в нужный момент очень помогает

После retrieval система нередко получает слишком длинный, шумный и частично дублирующийся контекст. В таком случае summarization-модуль помогает очистить вход для генерации.

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

Но важно не превращать summarization в обязательный ritual. Если контекст и так хорошо помещается в окно модели и не содержит большого объёма мусора, дополнительная компрессия только усложнит пайплайн и увеличит задержку.

Здоровый подход здесь такой: summarization включается тогда, когда он решает реальную проблему, а не ради ощущения архитектурной полноты.

8. Генератор нужно учить работать не только с идеальным контекстом

Один из самых прикладных выводов касается fine-tuning генератора. В реальной жизни retrieval далеко не всегда приносит идеально чистые документы. В контексте могут быть частично нерелевантные фрагменты, дубли, шум и случайные совпадения.

Если генератор обучать только на "золотом" контексте, он окажется слишком нежным: в лабораторных условиях будет выглядеть отлично, а в проде начнёт чаще ошибаться или использовать контекст не так, как ожидалось.

Поэтому наиболее жизнеспособной выглядит схема, где во время обучения модель видит смесь:

• релевантных документов;

• случайных или частично шумных документов.

Такой подход делает генератор более устойчивым и лучше готовит его к реальному quality profile retrieval-системы, а не к идеализированному benchmark-сценарию.

9. Vector database это часть архитектуры, а не просто хранилище

Выбор vector DB часто сводят к вопросу "что сейчас популярно". На практике решение должно приниматься по намного более приземлённым критериям:

• какие типы индексов нужны;

• какой объём данных предстоит обслуживать;

• нужен ли hybrid search как нативная возможность;

• как система будет разворачиваться и масштабироваться.

Если смотреть на open-source решения, особенно сильным вариантом выглядит Milvus (прежде всего как комплексная инфраструктурная основа для серьёзного retrieval-сценария).

Но сам по себе этот вывод не означает, что любому проекту нужен именно Milvus. Скорее это напоминание о том, что vector DB нужно выбирать по operational requirements, а не по уровню медийности в AI-сообществе.

Две практические RAG-конфигурации, которые можно брать за основу

Конфигурация №1: максимум качества

• Query classification - включён;

• Chunking - sentence-level;

• Retrieval - Hybrid + HyDE;

• Reranking - monoT5;

• Repacking - Reverse;

• Summarization - Recomp;

• Generator fine-tuning - обучение на смеси релевантного и шумного контекста.

Такой вариант хорошо подходит там, где качество ответа важнее стоимости и времени отклика.

Конфигурация №2: баланс качества и скорости

• Query classification - включён;

• Chunking - sentence-level;

• Retrieval - Hybrid;

• Reranking - TILDEv2;

• Repacking - Reverse;

• Summarization - Recomp или отключение при жёстком SLA;

• Generator fine-tuning - та же стратегия с примесью шумного контекста.

Это более продуктовый вариант: он хорошо подходит для корпоративных ассистентов, knowledge bots, внутренних copilot-инструментов и FAQ-сценариев.

Как это внедрять без архитектурного перегруза

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

1. Сначала добавить query classification. Это дешёвый способ сразу убрать часть ненужных retrieval-вызовов.

2. Построить baseline на hybrid retrieval. Такой поиск обычно устойчивее dense-only схемы.

3. Подключить reranking. Именно здесь часто находится один из самых заметных рычагов качества.

4. Подобрать chunking под конкретные данные. Не по шаблону из чужого блога, а по данным и типу документов.

5. Добавить summarization только при реальной необходимости. Если контекст и так чистый, этот слой можно не включать.

6. Дообучать генератор на реалистичном контексте. Не только на идеальных документах, но и на шумных сценариях.

Такой порядок полезен тем, что каждый новый модуль появляется не ради зрелого AI-стека, а как ответ на конкретную проблему: низкий recall, плохой ranking, слишком длинный prompt или хрупкий генератор.

Что важно не переоценить

При всей практической ценности такого разбора, воспринимать его как абсолютную истину не стоит.

• Итоги зависят от домена. На ваших данных порядок лучших решений может отличаться.

• Chunking невозможно подобрать универсально. Тип текста сильно влияет на оптимальный размер и структуру chunks.

• Latency зависит от инфраструктуры. Одинаковые модули могут вести себя по-разному на разных моделях, индексах и железе.

• Не все улучшения одинаково окупаются. Некоторые техники дают небольшой прирост при заметном росте сложности.

Но именно в этом и ценность подхода: он помогает смотреть на RAG как на инженерную систему, где каждое решение нужно проверять через реальный quality/latency trade-off.

Вывод

Лучший способ думать о RAG не как о поиске для LLM, а как о системе подготовки качественного контекста для генерации.

Хорошая конфигурация начинается с вопроса, нужен ли retrieval вообще. Затем строится надёжный слой chunking и hybrid search. После этого качество усиливается reranking, а repacking помогает подать контекст в наиболее удобной для модели форме. Summarization подключается там, где действительно есть проблема длинного или шумного prompt. А fine-tuning генератора делает систему устойчивой к реальным, а не идеальным условиям.

Если нужен короткий практический вывод, он звучит так: не пытайтесь сразу собрать самый сложный RAG. Сначала нужен честный baseline, затем измерение качества и задержки, и только потом точечное усиление тех модулей, которые действительно двигают систему вперёд.

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

Источник: Searching for Best Practices in Retrieval-Augmented Generation