Что такое RAG простыми словами: AI по вашим документам

Автор: Silvana · Дата: 30.07.2026 · Verified: 30.07.2026 · Reading time: 5 минут · Prerequisite: 006

Кратко

RAG (Retrieval-Augmented Generation) — способ заставить LLM отвечать по вашим документам, не переобучая модель.
Схема одинакова у всех вендоров: перед ответом система находит релевантные куски документов и подкладывает их в промпт вместе с вопросом.
Решает две проблемы: LLM не знает вашу компанию и может выдумать факты. RAG заземляет ответ на реальный источник.
Работает на связке embedding + векторная база + LLM. Стандартный подход к AI-помощникам по базам знаний в 2026.
Дешевле и гибче fine-tuning: добавили документ — он доступен сразу, без переобучения.

Что это и зачем

RAG расшифровывается как Retrieval-Augmented Generation — генерация с подкреплением поиском. За страшным термином простая идея.

LLM обучали на данных до определённой даты (у Claude Sonnet 5 — январь 2026, у GPT-5.6 — февраль 2026). Модель не знает вашу внутреннюю документацию, контракты, регламенты, историю переписки с клиентом. Если спросить Claude «какие условия доставки на маркетплейс X по нашему договору» — он честно ответит «не знаю» или, что хуже, придумает правдоподобный ответ.

RAG решает это так: перед ответом система находит в ваших документах несколько кусков, релевантных вопросу, и вставляет их в промпт. Модель видит вопрос плюс подсказки из документов и отвечает уже по ним.

Аналогия: библиотекарь + карта. Эксперт знает много общего, но не помнит вашего конкретного проекта. Вы задаёте вопрос. Библиотекарь за секунду находит на нужном стеллаже 3 листа регламента и кладёт перед экспертом. Тот читает и отвечает. Без подсказки — выдумал бы, с подсказкой — отвечает точно и может процитировать источник.

Именно так работают AI-помощники по базе знаний, поиск в документации, чат-боты поддержки, юридические помощники. OpenAI в своём cookbook формулирует ту же логику через метафору экзамена: fine-tuning — как готовиться к экзамену за неделю (что-то забудется), RAG — как сдавать с открытыми записями.

Основной разбор

Как работает RAG: четыре шага

Стандартный конвейер, одинаковый у LangChain, LlamaIndex и любого самописного решения:

Embedding (индексация).Документы режем на куски (chunks), обычно 500–1000 символов с перекрытием 50–200. Каждый кусок прогоняем через embedding-модель — она превращает текст в вектор из 768–3072 чисел. Векторы + оригинальные куски сохраняем в векторную базу.
Retrieval (поиск).Вопрос пользователя тоже превращается в вектор. Векторная база находит 3–10 самых близких по смыслу кусков через косинусное сходство или гибридный поиск (dense + BM25).
Augment (обогащение).Формируем финальный промпт: системная инструкция «отвечай только по документам» + найденные куски + вопрос пользователя.
Generate (ответ).Отправляем всё в LLM. Модель отвечает по контексту и в идеале цитирует источники.

Пример: у вас 500 регламентов на 5000 страниц. Сотрудник спрашивает: «какой максимальный размер компенсации за задержку рейса». Embedding превращает вопрос в вектор. База находит 3 релевантных абзаца из положения о командировках. LLM формулирует ответ, цитируя абзацы с указанием страницы.

LlamaIndex в разделе High-Level Concepts определяет RAG так: «core technique for building data-backed LLM applications… allows LLMs to answer questions about your private data by providing it to the LLM at query time».

Три главных failure-mode

RAG не волшебная кнопка. Три места, где чаще всего ломается качество:

1. Плохая нарезка (chunking).Если резать документ по фиксированной длине без учёта смысла, вы разрываете таблицы, списки, определения на пол-слова. Кусок «максимальный размер компенсации составляет» без продолжения — бесполезен. Решение: резать по семантическим границам (заголовки, параграфы), добавлять перекрытие, использовать structural-aware сплиттеры (LangChain и LlamaIndex дают их из коробки).

2. Retrieval нашёл не то (off-topic retrieval).Embedding-модель может не понять смысл вопроса или найти семантически близкий, но фактически нерелевантный кусок. Вопрос про «компенсацию за задержку рейса» может вытянуть куски про «компенсацию за задержку зарплаты» — слова похожи, суть разная. Решение: гибридный поиск (векторы + ключевые слова), rerank (второй проход более точной моделью по топ-20 кандидатам), метадата-фильтры.

3. Галлюцинированные цитаты (hallucinated citations).Даже с релевантным контекстом LLM иногда добавляет от себя факты или ссылается на несуществующие места в документе. Решение: жёсткий системный промпт («если ответа нет в контексте — скажи „не знаю“»), post-check, встроенные citation-механизмы (у Claude на platform.claude.com есть API Citations, автоматически привязывающий фрагменты ответа к source-документам).

Для бизнеса это значит: MVP RAG собирается за день, продовое качество — за 2–3 месяца настройки chunking, retrieval и промптов на реальных вопросах пользователей.

Долгий контекст (Claude 1M, Gemini 2M) vs RAG

В 2026 у Claude Sonnet 5 и Opus 5 контекст 1 000 000 токенов, у GPT-5.6 — 1 050 000, у Gemini 2.5 Pro — до 2 000 000. Возникает соблазн: «зачем RAG, если я могу засунуть весь корпус в промпт?»

Долгий контекст выигрывает когда:

Общий объём документов помещается в окно (условно, до 500 страниц PDF).
Вопросы идут по одному документу за раз.
Помогает prompt caching: у Claude он снижает стоимость повторных запросов по одному контексту в 10 раз (docs.anthropic.com/en/docs/build-with-claude/prompt-caching).
Нужна reasoning-связка по всему корпусу разом.

RAG выигрывает когда:

Корпус в разы больше окна (тысячи документов, гигабайты текста).
Нужен точный источник для каждого утверждения (RAG показывает конкретный chunk).
Latency важна: перебор 1M токенов медленнее, чем найти 10 kb релевантных кусков.
Данные обновляются часто: RAG-индекс — секунды, долгий контекст — пересобирать заново.
Стоимость критична: 1M токенов на каждом запросе дороже, чем 10 kb релевантного контекста.

Гибрид тоже валиден: RAG находит 20–30 самых релевантных страниц, они кладутся в долгий контекст, дальше reasoning по ним.

Contextual Retrieval — доработка Anthropic

Anthropic продвигает подход Contextual Retrieval — модификацию классического RAG. Идея: перед сохранением в векторную базу каждый chunk обогащается коротким контекстом от LLM («этот кусок из раздела X документа Y, речь о Z»). Обогащённый chunk эмбеддится и индексируется.

По данным Anthropic (engineering-блог + API-документация по Citations), Contextual Retrieval снижает retrieval failure rate заметно относительно стандартного RAG. Цена: один вызов LLM на chunk во время индексации — дороже разово, но окупается качеством ответов. Это надстройка, не замена — базовый конвейер тот же.

Практика

Минимальный RAG-стек на pgvector (Postgres-расширение для векторов):

1. pgvector-схема:
   CREATE EXTENSION vector;
   CREATE TABLE docs (
     id serial PRIMARY KEY,
     source text,
     chunk text,
     embedding vector(1536)
   );
   CREATE INDEX ON docs USING ivfflat (embedding vector_cosine_ops);

2. Индексация (один раз при добавлении документа):
   для каждого документа:
     разбить на chunks (500-1000 символов, overlap 100)
     для каждого chunk:
       vector = embedding_model(chunk)
       INSERT INTO docs (source, chunk, embedding) VALUES (...)

3. Ответ на вопрос (на каждый запрос пользователя):
   query_vector = embedding_model(user_question)
   top_chunks = SELECT chunk FROM docs
                ORDER BY embedding <=> query_vector
                LIMIT 5;
   answer = llm(
     system="Отвечай только по контексту. Если ответа нет — скажи так.",
     context=top_chunks,
     question=user_question
   )

Альтернатива pgvector — специализированные векторные базы: Qdrant (open-source, есть managed cloud), Chroma (embedded, для прототипов), Weaviate, Milvus. Для промышленной нагрузки от 1M векторов Qdrant и Milvus работают быстрее pgvector.

Оркестрация: LangChain или LlamaIndex дают готовые классы для всех шагов конвейера (loaders, splitters, embeddings, vector stores, retrievers, query engines). Своя реализация оправдана, если нужен полный контроль над каждым шагом.

RU-специфика

Работает из РФ напрямую.Полностью автономный стек: YandexGPT + YandexGPT Embeddings + Qdrant/pgvector на своём сервере — да, без сторонней инфраструктуры. GigaChat + локальная база — тоже.
Оплата в РФ.YandexGPT и GigaChat — обычной картой российского банка. Зарубежный стек (OpenAI, Claude, Pinecone) — через посредников или зарубежную карту.
RU-локализация embedding.multilingual-e5-large (open-weight, Hugging Face) хорошо работает на русском. YandexGPT Embeddings и GigaChat Embeddings — родная поддержка русского.
Open-source стек для локального разворачивания:LangChain или LlamaIndex как оркестратор, Qdrant или Chroma как векторная база, multilingual-e5-large как embedding, локальная LLM (Llama 3, Qwen) или API RU-провайдера как генератор ответа.

Sources

https://developers.llamaindex.ai/python/framework/getting_started/concepts/· проверено 30.07.2026
https://developers.openai.com/cookbook/examples/question_answering_using_embeddings· проверено 30.07.2026
https://platform.claude.com/docs/en/build-with-claude/prompt-caching· проверено 30.07.2026
https://docs.langchain.com/oss/python/langchain/overview· проверено 30.07.2026
https://ai.google.dev/gemini-api/docs/document-processing· проверено 30.07.2026
https://www.anthropic.com/engineering/contextual-retrieval· проверено 30.07.2026 (страница доступна не из всех регионов; метод также описан в API-документации Anthropic по Citations)

Актуальность

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