RAG (Retrieval-Augmented Generation) — это паттерн, в котором модель сначала извлекает релевантные внешние данные во время запроса, а затем генерирует ответ с их учетом. В исходной работе RAG описан как сочетание параметрической и непараметрической памяти для задач генерации текста.
Английский термин: Retrieval-Augmented Generation. Сокращение: RAG. Важно не путать RAG с retrieval как отдельным этапом поиска, с retriever как компонентом пайплайна и с knowledge base как хранилищем документов или структурированных данных. Ниже — рабочее объяснение по официальным источникам по состоянию на 2026-08-16.
Редакционная оговорка: у RAG нет одной универсальной, вендорно-независимой реализации. В разных документациях границы между обычным RAG, agentic RAG и agentic retrieval описаны немного по-разному.
Простыми словами
Можно представить RAG как экзамен «с открытой книгой». Обычная модель отвечает в основном по тому, что уже «запомнила» в параметрах. RAG добавляет к этому быстрый поиск по внешним материалам именно в момент вопроса.
Грубо говоря, вы задаете вопрос, система сначала идет в свою базу знаний, находит подходящие фрагменты и только потом формулирует ответ. Поэтому RAG особенно полезен там, где знания лежат в документах и меняются чаще, чем вы готовы переобучать или заменять модель.
Как это работает
В paper 2020 года RAG определяется как объединение параметрической памяти модели и непараметрической памяти во внешнем источнике данных. В современных фреймворках эта идея обычно реализуется как связка базы знаний, поиска и генерации.
LangChain описывает базу знаний как репозиторий документов или структурированных данных, который используется во время retrieval. В той же документации retrieval-пайплайн строится из загрузчиков (loaders), разбиения текста (splitters), эмбеддингов (embeddings), векторных хранилищ (vector stores) и поисковых компонентов (retrievers). Haystack отдельно подчеркивает, что retrievers используются в retrieval-части RAG-пайплайнов и тесно связаны с document stores.
Документы / структурированные данные
↓
loaders → splitters → embeddings → vector store / document store
↓
вопрос пользователя → retriever → релевантные фрагменты
↓
генератор / LLM → ответ
- Подготовка базы знаний. Вы собираете документы или структурированные данные, из которых система будет извлекать сведения.
- Индексирование. Материалы загружаются, при необходимости разбиваются на части и подготавливаются для поиска.
- Поиск во время запроса. Когда пользователь задает вопрос, retriever ищет релевантные фрагменты во внешней базе знаний.
- Генерация ответа. Модель получает вопрос вместе с найденным контекстом и формирует ответ.
LlamaIndex показывает эту логику на быстром старте для question-answering: сначала из документов строится VectorStoreIndex, а затем по нему выполняется запрос. LangChain документирует как минимум три паттерна: 2-step RAG, agentic RAG и hybrid RAG. Azure AI Search, в свою очередь, описывает agentic retrieval как multi-query pipeline для сложных вопросов в chat- и copilot-приложениях, а также для agent-to-agent workflows.
Практический вывод: минимальный RAG — это не «магия поиска», а последовательность из подготовки данных, retrieval и generation. Если один из этапов отсутствует, вы уже, скорее всего, говорите не о полном RAG, а о его компоненте.
Где применяется
- Вопросы и ответы по документам. LlamaIndex прямо подает question-answering как RAG-сценарий: есть коллекция документов, по которой система отвечает на запросы.
- Чат по базе знаний. По формулировке LangChain retrieval нужен, чтобы во время запроса подтягивать релевантные внешние знания. Это типовой сценарий для внутренних помощников и FAQ-чатов.
- Copilot- и chat-приложения со сложными вопросами. Azure описывает agentic retrieval для сложных вопросов, где может понадобиться несколько поисковых шагов, а не один запрос к индексу.
- Задачи с внешней памятью. Исходная работа RAG относит подход к knowledge-intensive NLP tasks, где одной параметрической памяти модели недостаточно.
Практический пример
Представим, что вы хотите сделать прототип помощника по внутреннему набору документов команды. Не кодом, а по шагам это выглядит так:
- Соберите базу знаний: документы и, при необходимости, структурированные данные.
- Прогоните материалы через загрузку и разбиение на части.
- Подготовьте представление для поиска: в экосистемах вроде LangChain это обычно включает embeddings и vector store; в Haystack retrieval-часть связывается с document store.
- Если вы идете по пути LlamaIndex, типовой быстрый старт — построить
VectorStoreIndexиз документов и затем отправлять запросы к индексу. - Когда пользователь задает вопрос, retriever находит релевантные фрагменты из базы знаний.
- Модель получает вопрос вместе с найденными фрагментами и формирует ответ.
Если вопрос простой, такого линейного сценария обычно достаточно. Если вопрос составной, некоторые платформы поддерживают более сложную оркестрацию. Например, в Azure AI Search полная демонстрация agentic retrieval в quickstart использует REST API версии 2026-05-01-preview; при этом preview-возможности не имеют SLA, а сама функция требует Azure AI Search в регионе, где agentic retrieval доступен, и уровень Basic или выше для managed identity support.
Если вам нужен уже не термин, а внедрение, полезно перейти к практическим материалам: Как собрать RAG-систему: пошагово и Как настроить RAG с LlamaIndex.
Чем отличается от похожих терминов
| Термин | Что это | Чем отличается от RAG |
|---|---|---|
| Retrieval | Этап поиска релевантных внешних данных во время запроса | RAG включает retrieval, но не заканчивается на нем: после поиска идет генерация ответа. |
| Retriever | Компонент, который выполняет поиск | Retriever — это часть пайплайна. RAG — весь паттерн retrieval + generation. |
| Knowledge base | Репозиторий документов или структурированных данных | База знаний — источник данных для retrieval. Это не RAG сама по себе. |
| Agentic retrieval | По Azure — multi-query pipeline для сложных вопросов | Может использоваться внутри RAG-паттернов, но граница между «agentic retrieval» и «agentic RAG» зависит от документации конкретного продукта. |
Если вам нужен разбор соседних паттернов, посмотрите Self-RAG и Corrective RAG (CRAG). А если выбор стоит между подачей большого контекста целиком и retrieval-подходом, есть отдельное сравнение: Длинный контекст vs RAG: что выбрать.
Ограничения и заблуждения
- Заблуждение: «RAG — это просто векторная база». По официальным схемам это шире: нужны данные, индексирование, retriever и генерация. Векторное хранилище — только один из строительных блоков.
- Заблуждение: «Любой RAG уже agentic». LangChain отдельно различает 2-step RAG, agentic RAG и hybrid RAG. То есть agentic-логика — это не обязательный минимум.
- Ограничение: нет единого стандарта реализации. Вендоры сходятся в общей идее retrieval + generation, но расходятся в названиях и границах паттернов.
- Ограничение: managed-возможности зависят от условий поставщика. Для Azure agentic retrieval важны регион, тариф и статус preview; preview-функции в quickstart прямо указаны как без SLA.
- Ограничение: документация и релизы дрейфуют. Если вы сверяете примеры, учитывайте, что на страницах релизов по состоянию проверки видны
langchain-core==1.5.5,Haystack v3.0.0иLlamaIndex v0.14.23, но сами страницы документации могут показывать более новые пути и примеры.
Практический вердикт: начинайте с простого RAG, если у вас уже есть документы или структурированные данные, по которым нужно отвечать во время запроса. Переход к agentic-вариантам имеет смысл только для действительно сложных, многошаговых вопросов и после проверки ограничений конкретной платформы.
Источники
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Retrieval – Docs by LangChain
- Retrievers | Haystack Documentation
- Welcome to LlamaIndex 🦙 ! | Developer Documentation
- Agentic Retrieval Overview – Azure AI Search | Microsoft Learn
- Quickstart: Agentic Retrieval – Azure AI Search | Microsoft Learn
- Releases · langchain-ai/langchain · GitHub
- Releases · deepset-ai/haystack · GitHub
- Releases · run-llama/llama_index · GitHub
Вопросы и ответы
RAG — это просто поиск по векторной базе?
Нет. По официальным описаниям retrieval — только часть RAG. Полный паттерн включает подготовку базы знаний, поиск релевантных фрагментов и генерацию ответа.
RAG и agentic retrieval — это одно и то же?
Не всегда. LangChain относит agentic RAG к одному из паттернов RAG, а Azure описывает agentic retrieval как multi-query pipeline для сложных вопросов, который используется в RAG-паттернах и agent-to-agent workflows. Универсальной границы здесь нет.
Нужна ли отдельная база знаний для RAG?
На практике да. LangChain определяет knowledge base как репозиторий документов или структурированных данных, который используется во время retrieval. Без такого источника данных RAG теряет свой внешний контекст.
Когда имеет смысл брать agentic-вариант вместо простого RAG?
Когда вопросы сложные и одного поискового шага недостаточно. Но это не обязательный стартовый вариант: LangChain отдельно документирует и простой 2-step RAG, а в Azure часть agentic-возможностей идет как preview и зависит от региона и тарифа.