Что такое RAG? Объясняем Retrieval-Augmented Generation
Большие языковые модели могут создавать беглые и убедительные ответы, но это не гарантирует, что ответ основан на правильной информации. У модели может не быть доступа к частным документам, недавним обновлениям, внутренним правилам компании, данным о продуктах или другим знаниям, находящимся за пределами её обучающего контекста.
Retrieval-Augmented Generation, обычно сокращённо RAG, решает эту проблему, предоставляя модели релевантную внешнюю информацию в момент, когда пользователь задаёт вопрос. Вместо того чтобы ожидать, что LLM знает всё из собственных параметров, приложение сначала находит подходящие данные, а затем просит модель сформировать ответ с их использованием.
Краткий ответ
Retrieval-Augmented Generation (RAG) — это архитектура AI, которая объединяет информационный поиск с генеративной большой языковой моделью. Когда пользователь задаёт вопрос, система извлекает релевантную информацию из внешнего источника, добавляет её в контекст модели и просит модель сформировать ответ, основанный на полученных данных.
Проще говоря:
Retrieve → Augment → Generate
RAG особенно полезен, когда AI-приложению нужен доступ к частной, специализированной или часто обновляющейся информации. (learn.microsoft.com)
Ключевые факты
| Понятие | Что это означает |
|---|---|
| Retrieval | Поиск информации, релевантной вопросу пользователя |
| Augmentation | Добавление найденной информации во входной контекст модели |
| Generation | Формирование итогового ответа на основе предоставленного контекста |
| Источник знаний | Документы, базы данных, базы знаний, сайты, поисковые индексы или другие данные |
| Embeddings | Числовые представления, часто используемые для семантического поиска по сходству |
| Vector database | Один из возможных способов хранения и поиска embeddings |
| Grounding | Предоставление модели внешних данных, на которых она может основывать ответ |
| Цель RAG | Улучшить доступ к релевантным внешним знаниям без переобучения базовой модели |
RAG не требует обязательного использования vector search. Для retrieval могут применяться keyword search, semantic search, vector search, hybrid search или другие механизмы, подходящие для конкретных данных. (learn.microsoft.com)
Что такое RAG?
LLM содержит знания, закодированные в её обученных параметрах. В оригинальной работе о RAG 2020 года это называлось parametric memory и объединялось с внешней non-parametric memory, из которой можно было извлекать информацию во время генерации ответа. В той работе внешним источником знаний служил dense vector index Википедии. (arxiv.org)
Современные RAG-системы применяют ту же общую идею в разных формах.
Представим внутреннего AI-ассистента компании. Сотрудник спрашивает:
«Сколько дней отпуска я могу перенести на следующий год?»
Без retrieval модель может ответить на основе общих знаний или закономерностей, усвоенных во время обучения. Для конкретной компании такой ответ может оказаться полностью неправильным.
RAG-система вместо этого ищет информацию в актуальной HR-документации компании, находит раздел о неиспользованных днях отпуска, добавляет соответствующий фрагмент в контекст модели и просит модель ответить на основе этой информации.
LLM по-прежнему генерирует ответ, но фактическая основа поступает из внешнего источника.
Как работает RAG
Практическая RAG-система обычно состоит из двух крупных частей: подготовки знаний для retrieval и извлечения этих знаний при поступлении вопроса.
1. Подготовка данных
Сначала система собирает материалы, которые могут понадобиться в будущем: документацию, статьи поддержки, инструкции, PDF-файлы, записи из баз данных, информацию о продуктах, правила или другой контент.
Большие документы часто разделяют на более мелкие части, называемые chunks, поскольку retrieval обычно работает лучше, когда можно найти отдельные релевантные фрагменты, а не возвращать документ целиком. Microsoft описывает извлечение контента, preprocessing, chunking, indexing и стратегию обновления как важные части ingestion-процесса в production RAG-системах. (learn.microsoft.com)
2. Создание индекса
После этого chunks должны стать доступными для поиска.
Один из распространённых подходов — преобразовать текст в embeddings, то есть числовые представления, отражающие семантические связи, и сохранить их в доступном для поиска vector index. Позже вопрос пользователя можно представить в том же пространстве и сравнить с этими chunks.
Это распространённый подход, но он не является определением RAG. Индекс может поддерживать keyword, semantic, vector или hybrid retrieval. (learn.microsoft.com)
Например, текущие API OpenAI для vector stores поддерживают хранение обработанных файлов и поиск релевантных chunks, включая настройки ranking и attribute filters. (platform.openai.com)
3. Поиск релевантной информации
Когда поступает вопрос, retrieval-система ищет по доступным знаниям и выбирает наиболее релевантные фрагменты.
Например:
Вопрос: «Могут ли клиенты получить возврат средств после 30 дней?»
Retriever может вернуть:
- раздел политики возврата
- правила отмены подписки
- исключения для дефектных товаров
Качество этого этапа критически важно. Если система извлекает неправильную информацию, LLM получает неправильные данные.
4. Дополнение prompt
Приложение объединяет несколько элементов:
- вопрос пользователя
- найденные фрагменты
- системные инструкции
- при необходимости историю разговора
- правила по работе с цитатами или отсутствующей информацией
Итоговый prompt может фактически сообщать модели:
Ответь на вопрос пользователя, используя предоставленную документацию компании. Если документация не содержит ответа, сообщи, что доступной информации недостаточно.
Найденная информация становится grounding context для модели. (learn.microsoft.com)
5. Генерация ответа
Наконец, LLM создаёт ответ с использованием дополненного контекста.
Хорошо спроектированное приложение также может сохранять metadata документов, чтобы в ответе можно было указать исходную страницу, документ, имя файла или URL. Microsoft отдельно отмечает, что индексы могут хранить metadata, улучшающие source attribution и качество цитирования. (learn.microsoft.com)
Почему RAG важен
RAG решает другую задачу, чем простое увеличение размера LLM.
Доступ к частным знаниям
Модель не знает автоматически содержимое вашей внутренней документации, клиентской базы данных, технических инструкций или частной базы знаний.
RAG может извлекать эту информацию, когда она нужна авторизованным пользователям.
Более актуальная информация
Информация, полученная моделью во время обучения, со временем может устареть. Retrieval-слой вместо этого может искать в источнике знаний, который обновляется независимо от самой модели.
Поэтому RAG полезен для таких областей, как документация продуктов, цены, правила, инвентарь, техническая поддержка и быстро меняющаяся бизнес-информация. (docs.cloud.google.com)
Указание источников
Поскольку найденные фрагменты поступают из идентифицируемых источников, приложение может сохранять их metadata и показывать цитаты.
Это не делает автоматически каждое сгенерированное утверждение правильным, но упрощает проверку ответа.
Более простое обновление знаний
Если политика компании меняется, в RAG-архитектуре часто достаточно обновить соответствующий проиндексированный материал вместо полного переобучения языковой модели.
Такое разделение модели и внешнего источника знаний — одно из практических преимуществ RAG.
RAG и Fine-Tuning
RAG и fine-tuning решают разные задачи.
| RAG | Fine-tuning |
|---|---|
| Добавляет внешнюю информацию во время запроса | Изменяет поведение модели через дополнительное обучение |
| Подходит для изменяющихся или частных знаний | Полезен для поведения, стиля, форматирования или специализации на задаче |
| Знания можно обновлять отдельно | Для новых знаний может потребоваться дополнительное обучение |
| Сильно зависит от качества retrieval | Сильно зависит от качества обучающих данных |
| Может предоставлять ссылки на источники | Сам по себе не обеспечивает provenance источников |
Текущая документация Microsoft также разделяет RAG как подход для grounding ответов на основе частных или часто обновляющихся данных и fine-tuning как способ изменить поведение модели, стиль или производительность в конкретной задаче. (learn.microsoft.com)
Эти подходы не исключают друг друга. Fine-tuned модель также может использовать RAG.
INTERNAL LINK: Fine-Tuning vs RAG: When to Use Each
RAG — это не только Vector Search
Одно из самых распространённых упрощений выглядит так:
RAG = embeddings + vector database + LLM
Это описывает популярную реализацию, но не всю концепцию.
Эффективная retrieval-система может сочетать точное keyword matching с semantic similarity. Точный поиск особенно важен, когда запрос содержит product IDs, error codes, имена, юридические термины или другие строки, которые должны совпадать буквально.
Поэтому современные поисковые платформы часто поддерживают hybrid retrieval, объединяя традиционный текстовый поиск с vector retrieval. (learn.microsoft.com)
Правильная retrieval-архитектура зависит от корпуса данных и от тех вопросов, которые пользователи действительно задают.
INTERNAL LINK: Vector Search Explained
Где RAG может давать сбои
RAG улучшает доступ к доказательной информации, но не гарантирует правильные ответы.
Плохой Retrieval
Если релевантный фрагмент вообще не был найден, модель не сможет надёжно использовать его.
Причинами могут быть неудачный chunking, слабое индексирование, неоднозначные запросы, неподходящие similarity settings, отсутствующие документы или слабый ranking.
Нерелевантный контекст
Извлечение слишком большого объёма информации может добавить шум. Большое количество нерелевантного контекста также занимает ограниченный input budget модели. (learn.microsoft.com)
Устаревшие знания
RAG предоставляет актуальную информацию только в том случае, если исходный corpus и index действительно поддерживаются в актуальном состоянии.
Устаревшая база знаний приводит к устаревшему grounding.
Галлюцинации всё ещё возможны
Grounding снижает необходимость модели додумывать ответ, но не заставляет каждое сгенерированное утверждение быть правильным. Microsoft прямо указывает, что неточные ответы всё ещё возможны даже при наличии retrieved context. (learn.microsoft.com)
Поэтому приложения должны отдельно оценивать как retrieval quality, так и answer quality, а не судить о системе только по тому, насколько убедительно звучит итоговый ответ. (learn.microsoft.com)
Безопасность по-прежнему важна
Retrieval также создаёт вопросы, связанные с авторизацией.
Пользователь не должен иметь возможность получить информацию только потому, что она присутствует где-то в индексе. Ограничения доступа должны применяться до того, как чувствительный контент попадёт к модели. Microsoft называет security и governance одной из ключевых production-проблем RAG-систем корпоративного уровня. (learn.microsoft.com)
Классический и Agentic RAG
Традиционный RAG обычно следует относительно фиксированному pipeline:
Question → Search → Context → LLM → Answer
Более сложные системы могут использовать agentic retrieval. Вместо выполнения одного заранее определённого поиска агент может проанализировать сложный запрос, решить, какие источники знаний нужно проверить, создать несколько subqueries, изучить промежуточные результаты и при необходимости выполнить retrieval повторно. (learn.microsoft.com)
Это может улучшить выполнение сложных многоэтапных retrieval-задач, но одновременно увеличивает сложность orchestration, latency, стоимость и количество поведения системы, которое необходимо оценивать.
Для многих приложений хорошо спроектированный классический RAG pipeline остаётся разумной отправной точкой.
INTERNAL LINK: Agentic RAG Explained
Рекомендация SeoNest
Начинайте с самой простой retrieval-архитектуры, которая способна надёжно отвечать на реальные вопросы пользователей.
Используйте репрезентативные запросы из будущего приложения, проверяйте, что именно возвращает retriever, и измеряйте retrieval отдельно от generation. Не добавляйте reranking, agents, несколько indexes, knowledge graphs или сложную orchestration только потому, что эти технологии доступны.
В системах, ориентированных на документы, тестируйте chunking, metadata, filters, keyword search, semantic retrieval и hybrid retrieval на реальных вопросах. Если ответ оказался неправильным, сначала определите, была ли вообще найдена правильная информация. Если нет, изменение одного только LLM prompt вряд ли устранит основную retrieval-проблему.
RAG следует рассматривать одновременно как систему information retrieval и generation, а не просто как функцию LLM.
FAQ
Обучает ли RAG LLM на моих документах?
Обычно нет. RAG извлекает информацию и передаёт её модели во время inference. Внешние документы не обязаны становиться частью обученных параметров модели.
Нужна ли RAG-системе vector database?
Нет. Vector databases часто используются в RAG-архитектурах, но RAG может применять keyword, semantic, vector, hybrid, database, API или другие механизмы retrieval.
Устраняет ли RAG галлюцинации?
Нет. Релевантный grounding может уменьшить количество неподтверждённой генерации, но плохой retrieval, неоднозначные данные, конфликтующие документы или поведение модели всё ещё могут приводить к неточным ответам. (learn.microsoft.com)
RAG лучше, чем fine-tuning?
Эти подходы решают разные задачи. RAG обычно подходит, когда модели нужен доступ к внешним или изменяющимся знаниям. Fine-tuning больше подходит, когда цель — изменить поведение модели или специализировать её на определённой задаче.
Какие данные может использовать RAG?
Возможные источники включают документацию, базы знаний, базы данных, контент поддержки, файлы, каталоги продуктов, сайты и другие системы, в которых приложение может безопасно выполнять поиск.
От чего зависит качество RAG?
Единственного компонента нет. На итоговый результат могут влиять качество контента, extraction, chunking, indexing, понимание запроса, retrieval, ranking, построение prompt, поведение модели, авторизация и evaluation. (learn.microsoft.com)
Итог
RAG даёт LLM то, чего у неё иначе нет: практический способ обращаться к внешним знаниям во время ответа на вопрос.
Основная идея проста:
найти релевантные данные, добавить их в контекст модели и сформировать ответ на их основе.
Главная инженерная задача заключается в том, чтобы система находила правильные данные, модель корректно их использовала, пользователи могли проверять важные утверждения, а конфиденциальная информация оставалась защищённой.
Поэтому сильная RAG-система определяется не тем, насколько сложна её vector database. Она определяется тем, насколько стабильно весь retrieval-and-generation pipeline предоставляет правильную информацию для тех вопросов, которые пользователи действительно задают.
Sources
- Lewis, Patrick et al. — “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” arXiv:2005.11401, originally submitted May 22, 2020; published at NeurIPS 2020. (arxiv.org) Read the RAG paper on arXiv
- Meta AI — “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” December 16, 2020. (ai.meta.com) Meta AI research page
- Microsoft — “Retrieval augmented generation (RAG) and indexes in Microsoft Foundry.” Last updated May 20, 2026. (learn.microsoft.com) Microsoft Foundry RAG documentation
- Microsoft — “Retrieval-augmented generation (RAG) in Azure AI Search.” (learn.microsoft.com) Azure AI Search RAG overview
- Microsoft — “Build Advanced Retrieval-Augmented Generation Systems.” (learn.microsoft.com) Advanced RAG guidance
- Google Cloud — “Generative AI Glossary: Retrieval-Augmented Generation.” (docs.cloud.google.com) Google Cloud generative AI glossary
- Google Cloud — “Generative AI with RAG.” Architecture Center; last reviewed September 22, 2025. (docs.cloud.google.com) Google Cloud RAG architecture guidance
- OpenAI — “Vector Stores.” OpenAI API documentation. (platform.openai.com) OpenAI vector store documentation


