RAG (Retrieval-Augmented Generation): полное руководство 2026

Такое ограничение есть у любой большой языковой модели (Large Language Model, LLM), если она не получает информацию из внешних источников. Эту проблему решает дополненная поиском генерация (Retrieval-Augmented Generation, RAG): перед созданием ответа система находит нужные сведения в базе знаний и передает их модели вместе с запросом.

Прототип RAG можно собрать за вечер, но превратить его в надежную промышленную систему гораздо сложнее. Разберем, как устроен RAG-конвейер, чем он отличается от дообучения, почему такие системы могут терять производительность под нагрузкой и как построить рабочее решение в облаке.

Что такое RAG и зачем он нужен

Проблема без RAG

Без доступа к внешним данным модель сталкивается с тремя ограничениями:

• Галлюцинации. Модель может сформировать правдоподобный, но по факту неверный ответ. Даже если нужной информации у нее нет, она все равно предлагает текст на основе выученных закономерностей.

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

• Устаревшие знания. События и изменения, произошедшие после завершения обучения модели, могут быть ей неизвестны. Для получения актуальной информации нужны внешние источники или инструменты.

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

При этом задача массовая. Согласно исследованию рынка искусственного интеллекта, опубликованному в декабре 2025 года, генеративный ИИ используют больше 70% крупных российских компаний. А сам рынок генеративного ИИ в России за 2025 год вырос примерно до 58 млрд рублей против 13 млрд годом ранее — такую оценку Just AI и агентства Onside привели в марте 2026 года. Модели массово внедряют и почти сразу сталкиваются с тем, что о самой компании они не знают ничего.

Решение: RAG

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

Посмотрим на примере. Сотрудник уточняет тариф оплаты переработки в праздничный день. Без доступа к внешним данным модель выдаст общие нормы. С RAG система находит в базе нужный приказ, извлекает соответствующие пункты и формулирует ответ строго по ним. В итоге сотрудник получает не обобщенную справку, а точное предписание из актуального внутреннего документа.

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

Разберем все четыре шага по порядку — от загрузки документов до готового ответа.

Шаг 1. Индексация документов

Документы проходят несколько этапов: исходный файл → чанки (chunking) → векторные представления текста (embeddings) → векторная база данных.

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

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

Шаг 2. Retrieval — поиск релевантных чанков

Запрос пользователя проходит ту же обработку, что и документы при индексации: превращается в вектор той же embedding-моделью. Дальше система сравнивает вектор запроса с векторами чанков — чаще всего по косинусной мере близости — и отбирает top-K ближайших.

Здесь работает семантика: на вопрос про отпуск система найдет фрагмент про ежегодный оплачиваемый отдых, хотя ни одно слово не совпадает.

Шаг 3. Augmentation — обогащение промпта

Система передает модели исходный вопрос вместе с найденными фрагментами базы знаний. Дополнительно системный промпт (system prompt) задает правила работы с контекстом: например, отвечать на основе предоставленных данных, а если нужной информации нет — прямо сообщать об этом.

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

Шаг 4. Generation — ответ модели

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

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

RAG, дообучение (fine-tuning) и промпт-инжиниринг (prompt engineering) решают разные задачи.

Выбор подхода зависит прежде всего от характера задачи. Если нужно регулярно работать с меняющимися документами и фактами, RAG обычно практичнее дообучения: достаточно обновлять базу знаний, а не переобучать модель после каждого изменения. На практике подходы можно комбинировать.

Прототип RAG и промышленная система отличаются прежде всего не моделью, а тем, как устроены поиск и работа с данными. В исследовании «Seven Failure Points When Engineering a Retrieval Augmented Generation System» (Скотт Барнетт (Scott Barnett) и коллеги, 2024), представленном 3-й Международной конференции по AI Engineering (CAIN), авторы проанализировали три реальных внедрения RAG-систем и выделили семь ключевых точек отказа. Исследование показало, что большинство проблем возникают на этапе извлечения информации (retrieval), а не на этапе генерации ответа. Поэтому надежность RAG-системы нужно проверять на нагрузках и рабочих сценариях.

Разберем четыре места, где такие системы чаще всего дают сбой.

Плохой чанкинг

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

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

Более сильный прием — контекстуализация: перед векторизацией к каждому чанку добавляют короткое пояснение, откуда он взят. По данным эксперимента Anthropic (сентябрь 2024):

• Контекстуализация (добавление пояснений к чанкам перед векторизацией) снизила долю неудачных извлечений при поиске top-20 чанков с 5,7 до 3,7% (снижение на 35%). 

• Сочетание контекстных эмбеддингов и контекстного BM25 снизило долю неудач до 2,9% (снижение на 49%). Максимальный результат — снижение до 1,9% (на 67%) — достигается при комбинации всех трех методов: контекстных эмбеддингов, контекстного BM25 и реранкера. 

Несоответствие embedding-модели

Для индексации документов и кодирования запросов нужно использовать совместимые embedding-модели. Если заменить модель для запросов, но оставить старые векторы документов, пространство представлений может измениться, и качество поиска резко снизится. Поэтому после смены embedding-модели базу обычно переиндексируют.

Также важен и язык: модель, отлично работающая на английском, может путать падежи и синонимы в русском тексте. Сравнивать варианты стоит по русскоязычному бенчмарку ruMTEB, представленному в 2025 году на конференции NAACL (Снегирев и коллеги). Бенчмарк включает 23 задания в 7 категориях: классификация, кластеризация, многоклассовая классификация, парная классификация, переранжирование, поиск и семантическое текстовое сходство (STS). Современные модели для русского языка, такие как GigaEmbeddings, достигают на ruMTEB 69.1 балла (по данным авторов модели), что сопоставимо с качеством англоязычных моделей. 

Отсутствие re-ranking

Векторный поиск быстро находит подходящие по смыслу фрагменты, но не всегда правильно определяет, какой из них отвечает на вопрос. Например, по запросу «какие документы нужны для возврата товара?» он может поставить рядом общий порядок возврата, список документов для гарантийного ремонта и требования для возврата товара надлежащего качества.

Re-ranking (переранжирование) добавляет второй этап проверки. Реранкер анализирует запрос и каждый найденный чанк вместе, точнее оценивает их и оставляет лучшие фрагменты для модели. Например, из 50 кандидатов он может выбрать 3–5 подходящих больше всего.

Размытый system prompt

Если не задать модели четкие правила работы с контекстом, она дополнит ответ собственными знаниями или догадками. Поэтому system prompt должен явно указывать: нужно опираться на предоставленные данные, а при отсутствии ответа в контексте сообщать об этом, а не додумывать.

Есть и другая проблема — слишком большой контекст. Исследование «Lost in the Middle: How Language Models Use Long Contexts» (Нельсон Лю и его коллеги, 2024), опубликованное в Transactions of the Association for Computational Linguistics (TACL), показало, что производительность моделей значительно падает при размещении релевантной информации в середине длинного контекста. Наибольшая точность ответов достигается, когда ключевые данные находятся в начале или в конце контекстного окна. Этот феномен наблюдался на задачах многодокументного question answering и key-value retrieval. 

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

В Evolution Managed RAG эту инфраструктуру берет на себя Cloud.ru. Пользователю остается загрузить документы, создать базу знаний и подключить ее к приложению через API.

Что умеет Evolution Managed RAG

Сервис закрывает весь слой извлечения данных:

• Автоматическая индексация из Evolution Object Storage. Файлы кладутся в бакет объектного хранилища, сервис сам разбирает их, режет на чанки и векторизует.

• Готовая векторная база. Подбирать и разворачивать хранилище не нужно, поддерживаются векторный и полнотекстовый поиск.

• Интеграция с Evolution Foundation Models и Evolution ML Inference. Модели для эмбеддингов и генерации подключаются из каталога, включая открытые модели с HuggingFace.

• API для поиска и генерации ответов. Совместим с форматом OpenAI и встраивается в существующий код практически без доработок, а проверить ответы можно в песочнице без строчки кода.

• MCP-сервер для подключения к ИИ-агентам. База знаний становится инструментом агента: он сам обращается к ней, когда не хватает информации.

Есть и версионирование: каждое обновление создает новую версию базы, а откат — это смена идентификатора версии в запросе.

Быстрый старт

Запуск занимает около 15 минут, и большая часть уходит на автоматическую индексацию.

1. Перейти в AI Factory → Managed RAG и создать базу знаний.

2. Указать путь к папке в Object Storage и расширения файлов, которые нужно обработать.

3. Дождаться статуса «Активная» — индексация выполняется автоматически.

4. Скопировать URL версии базы знаний и использовать его в запросах через API.

Ограничения

Перед загрузкой информации стоит проверить технические ограничения.

Вопросы, которые могут возникнуть у команд перед первым внедрением.

Чем RAG отличается от поиска?

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

Нужна ли GPU для RAG?

Для инференса (выполнения запросов) RAG-системы центрального процессора (CPU) достаточно: поиск в векторной базе данных и работа с embedding-моделями могут выполняться на CPU. Однако есть важные нюансы:

• Индексация больших объемов данных (сотни тысяч документов) на CPU может занимать несколько часов, тогда как GPU сокращает этот процесс до десятков минут.

• Современные embedding-модели для русского языка (например, GigaEmbeddings, ru-en-RoSBERTa) требуют GPU для эффективного обучения и могут показывать лучшую производительность на GPU при инференсе.

• В Managed RAG инфраструктура моделей подключается через Foundation Models, что снимает необходимость самостоятельного управления GPU.

GPU понадобится, если компания самостоятельно запускает модели, которым нужны такие ресурсы. В Evolution Managed RAG инфраструктура моделей подключается через Evolution Foundation Models или собственные инференсы в Evolution ML Inference, поэтому управлять GPU напрямую необязательно.