Что такое RAG? Простое объяснение принципа и применений для начинающих — издание 2026

«Хочу, чтобы ChatGPT прочитал наши внутренние правила и автоматически отвечал на вопросы сотрудников», «Нужно искать по базе свежих научных статей и резюмировать их» — таких запросов становится всё больше. Но обучающие данные ChatGPT обрываются на каком-то моменте в прошлом, а отдавать конфиденциальные внутренние документы прямо в обучение модели тоже нельзя.

Эту проблему решает технология RAG (Retrieval-Augmented Generation, генерация с дополненной выборкой). С 2023 года это одно из ключевых слов корпоративного применения ИИ; функции ChatGPT «Custom GPTs» и «Projects» внутри тоже устроены как RAG.

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

1. Что такое RAG — Retrieval-Augmented Generation

Дословно RAG (Retrieval-Augmented Generation) — это «генерация (Generation), дополненная (Augmented) поиском (Retrieval)». На русском обычно говорят «генерация с дополненной выборкой».

В одном предложении: «прежде чем LLM (большая языковая модель) сформирует ответ, она ищет релевантную информацию во внешней базе данных и опирается на найденное при генерации».

Кулинарная аналогия

«Голая» LLM — это шеф-повар, готовящий «по памяти». Талантливый, но новый рецепт ему не приготовить, и о содержимом конкретного холодильника он ничего не знает.

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

Роли «Retrieval», «Augmented» и «Generation»

Главная идея — мы не переобучаем саму LLM, а каждый раз, когда поступает вопрос, передаём ей «нужные знания» извне. В этом и есть принципиальное отличие от дообучения, о котором речь ниже.

2. Зачем нужен RAG — три ограничения «голой» LLM

У ChatGPT, Claude и других LLM в чистом виде есть три проблемы, которые им самим не решить.

Ограничение 1. Cut-off знаний (актуальность)

LLM обучается на «данных до некоторого момента», поэтому ничего не знает о событиях после этой даты. Например, у ранней версии GPT-4 знания были по апрель 2023 года.

• «Расскажи о новом продукте, который вчера анонсировали» → ответить не сможет
• «Что в законе, который вступил в силу на прошлой неделе?» → не знает
• «Какой сегодня курс валюты?» → не ответит

С помощью RAG можно подгружать свежие новости, данные из БД и API и отвечать на их основе.

Ограничение 2. Галлюцинации (правдоподобная ложь)

Если у LLM спросить о том, чего она не знает, она склонна выдумывать ответ, который выглядит уверенно. Это и называют галлюцинацией.

Пример: «Сколько дней оплачиваемого отпуска у нас в компании?» — LLM не знает, но отвечает «обычно от 10 до 20 дней». Для бизнеса так нельзя.

В RAG модель ищет реальный текст внутреннего регламента и опирается на него — ответ становится обоснованным. Можно даже указать, «какой это документ и какой пункт».

Ограничение 3. Нет доступа к внутренним и приватным данным

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

RAG позволяет хранить документы во внутренней векторной БД, и при поступлении вопроса извлекать только нужный фрагмент и передавать его LLM. Так можно использовать корпоративные данные, не теряя в безопасности.

3. Принцип работы — RAG в три шага

Работа RAG делится на две фазы: «подготовка (индексация)» и «исполнение (ответ на вопрос)».

Фаза подготовки — векторизация документов

1. Сбор документов: PDF, Word, HTML, Markdown — собираем то, что хотим использовать
2. Чанкование: режем документы на куски подходящей длины (например, 500–1000 символов)
3. Эмбеддинги: каждый чанк прогоняем через эмбеддинг-модель (например, OpenAI text-embedding-3-small) и получаем вектор (массив чисел) размерности, например, 1536
4. Сохранение в векторную БД: пары «чанк — вектор» кладём в специализированную БД (Pinecone, Qdrant и т. п.)

Этот процесс запускается, когда документы добавляются или меняются.

Фаза исполнения — ответ за три шага

Когда поступает вопрос пользователя, происходит следующее.

1. Шаг 1: Retrieval (поиск)
   • превращаем вопрос в вектор той же эмбеддинг-моделью
   • в векторной БД находим топ-K (обычно 3–10) чанков, ближайших к вектору запроса
   • близость считается, например, по косинусному сходству
2. Шаг 2: Augmented (расширение)
   • найденные чанки встраиваются в промпт как «справочный контекст»
   • примерно так: «Опираясь на следующее, ответь на вопрос: [результаты поиска] Вопрос: [вопрос пользователя]»
3. Шаг 3: Generation (генерация)
   • LLM (GPT-4, Claude, Gemini и т. п.) формирует ответ на основе контекста
   • при необходимости указывает, «какой именно документ был использован»

Конкретный пример: внутренний регламент через ChatGPT

Сценарий «Сколько дней оплачиваемого отпуска?»:

1. вопрос превращается эмбеддинг-моделью в вектор → [0.12, -0.45, 0.78, ...]
2. из векторной БД достаются три чанка по темам «отпуск» и «оплачиваемый»
3. например: «Статья 15. Ежегодный оплачиваемый отпуск. Сотрудникам, проработавшим 6 месяцев, предоставляется 10 дней...» и «в зависимости от стажа — до 20 дней...»
4. промпт собирается так: «Контекст: ст. 15... Вопрос: сколько дней отпуска?»
5. LLM отвечает: «После 6 месяцев — 10 дней; в зависимости от стажа — до 20 дней (см. ст. 15 регламента)»

4. Основные компоненты RAG

RAG состоит из пяти компонентов.

1. Эмбеддинг-модель (Embedding Model)

ИИ-модель, которая превращает текст в числовой вектор. Обучается так, чтобы «семантически близкие тексты находились близко и в пространстве векторов».

2. Векторная база данных

Специализированная БД, которая хранит большие массивы векторов и быстро ищет «ближайших». Подробнее в следующем разделе.

3. Поисковик (Retriever)

Кроме векторного поиска часто комбинируется с поиском по ключевым словам (BM25 и т. п.) — получается гибридный поиск.

4. LLM (генератор)

Большая языковая модель, которая строит итоговый ответ. GPT-4, Claude, Gemini, Llama 3 и т. д. — подойдёт и платное API, и локальная OSS-модель.

5. Шаблон промпта

Шаблон, который собирает результаты поиска и вопрос пользователя в готовый промпт для LLM. От него сильно зависит качество RAG.

Ты ассистент по внутренним правилам компании.
Отвечай на вопрос, опираясь только на приведённый ниже контекст.
Если в контексте нет ответа — напиши «информации нет».

[Контекст]
{retrieved_chunks}

[Вопрос]
{user_question}

[Ответ]

5. Что такое векторная база данных

Векторная БД, в отличие от обычной реляционной (MySQL и т. п.), специализируется на «быстром поиске ближайших соседей в многомерном векторном пространстве».

Сравнение основных векторных БД

Что выбрать

• Просто попробовать: Chroma (поставил pip — заработало)
• Уже есть PostgreSQL: pgvector (всё в одной БД)
• Прод с минимальной эксплуатацией: Pinecone (почти ничего не нужно настраивать)
• Серьёзный OSS-стек: Qdrant или Weaviate
• Сотни миллионов и больше: Milvus

К слову, по выбору хостинга для самой системы будет полезна статья PaaS (Vercel и др.) vs шаред-хостинг, VPS и облако.

6. Где применяется RAG — основные сценарии

С 2023 года RAG — одна из самых востребованных технологий в корпоративном ИИ. Самые показательные сценарии:

Сценарий 1. Внутренний QA по документам (knowledge base)

Регламенты, инструкции, тех. спецификации, протоколы встреч, материалы для продаж индексируются в RAG, и сотрудники задают вопросы, как ChatGPT. Microsoft 365 Copilot для документов в SharePoint тоже использует RAG.

Сценарий 2. Автоматизация поддержки клиентов

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

Сценарий 3. Q&A по праву и медицине

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

Сценарий 4. Поиск и резюме научных статей

arXiv, PubMed, Google Scholar и т. п. индексируются, и можно спросить «какие сейчас тренды в этой теме?» или «есть ли похожие исследования по методу X?». Так работают Elicit и Perplexity.

Сценарий 5. Поиск товаров и FAQ для интернет-магазинов

Инструкции, отзывы, правила возврата — всё в одном RAG. Можно искать на естественном языке: «подходит ли этот пылесос для шерсти питомцев?»

Сценарий 6. Чат по документации для разработчиков

Документация библиотек индексируется в RAG — и можно спросить: «Как написать вот так на AWS Lambda? Дай пример кода». Похожий подход используют Stripe, Vercel, Supabase. Внутри GitHub Copilot Chat и Cursor, Claude Code и других ИИ-инструментов разработки тоже работают похожие методы.

Сценарий 7. Поиск и объяснение по корпоративной кодовой базе

Код из GitHub индексируется как RAG, и инструмент для разработчиков помогает с вопросами: «как использовать эту функцию?», «где ещё реализована похожая логика?».

Сценарий 8. Новые форматы оптимизации под ИИ — например llms.txt

llms.txt — это способ корректно отдавать ИИ информацию с сайта. Идея хорошо ложится на RAG: владелец сайта в структурированном виде сообщает, что именно ИИ должен прочитать.

7. RAG vs дообучение — что выбрать

Часто рядом с RAG обсуждают дообучение (Fine-tuning) как способ «дать LLM свои знания». Подходы принципиально разные.

Принципиальные различия

Когда подходит RAG

• знания часто меняются (новости, внутренние документы, информация о товарах)
• нужно показывать источники (право, медицина, финансы)
• документов очень много (учить всё нереалистично)
• нужно стартовать быстро (сократить срок разработки)

Когда подходит дообучение

• нужен особый стиль и тон (брендовый голос, характер персонажа)
• нужны специфические языковые паттерны (медицинская, юридическая лексика)
• хочется снизить стоимость инференса (промпт станет короче)
• уже есть большой объём качественной обучающей выборки

Сильнее всего — комбинация

На самом деле RAG и дообучение не противоречат друг другу и могут использоваться вместе. Стиль зашиваем дообучением, актуальные знания подаём через RAG — на проде такая связка встречается часто.

Однако новичкам всегда лучше начинать с RAG: его несравнимо проще запустить и поддерживать, чем дообучение.

8. Реализация — RAG на LangChain

Сначала пройдёмся по основным фреймворкам, потом — минимальный пример на Python.

Основные фреймворки

Минимальный RAG на LangChain

Реализуем RAG, отвечающий на вопросы по PDF с внутренним регламентом, — примерно в 30 строках на LangChain.

from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA

# 1. Загрузка документа
loader = PyPDFLoader("regulations.pdf")
docs = loader.load()

# 2. Чанкование
splitter = RecursiveCharacterTextSplitter(
    chunk_size=500, chunk_overlap=50
)
chunks = splitter.split_documents(docs)

# 3. Эмбеддинги + сборка векторной БД
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(chunks, embeddings)

# 4. Сборка цепочки RAG
llm = ChatOpenAI(model="gpt-4o-mini")
qa = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=vectorstore.as_retriever(search_kwargs={"k": 3}),
    return_source_documents=True,
)

# 5. Вопрос
result = qa.invoke({"query": "Сколько дней оплачиваемого отпуска?"})
print(result["result"])
print("Источники:", [d.metadata for d in result["source_documents"]])

Этот код ищет нужные фрагменты в PDF и заставляет GPT-4o-mini сформулировать ответ. Поскольку доступны и номера страниц источников, можно отвечать «согласно ст. 15» с указанием цитаты.

Что добавляется в боевой реализации

• Оптимизация чанкования (семантическое разбиение, иерархические чанки и т. п.)
• Гибридный поиск (вектор + BM25)
• Reranking (Cohere Rerank, voyage-rerank — переупорядочивают результаты)
• Переписывание запроса (HyDE, Multi-Query — повышают точность)
• Конвейер оценки (RAGAS для автоматической оценки)

9. Проблемы RAG и способы их решения

RAG — мощная технология, но в эксплуатации возникают типичные сложности.

Проблема 1. Сложность чанкования

От стратегии разбиения сильно зависит точность поиска. Слишком короткие чанки теряют контекст, слишком длинные — снижают точность поиска.

Решения:

• семантическое разбиение (по смысловым единицам)
• перекрытие (соседние чанки частично пересекаются)
• иерархическое разбиение (храним связь «родитель — ребёнок», ищем по детям, отдаём родителя)

Проблема 2. Точность Retrieval

Достаются «похожие, но не те» чанки или, наоборот, теряются важные.

Решения:

• гибридный поиск (вектор + BM25)
• reranker для пересортировки результатов
• генерация нескольких запросов (один вопрос — разные формулировки)

Проблема 3. Ограничение по длине контекста

В LLM можно передать лишь ограниченное число токенов — все чанки не пролезут.

Решения:

• сократить K (топ-3–5)
• сначала суммаризировать, потом передавать
• использовать LLM с длинным контекстом (Claude 200K, Gemini 1M и т. п.)

Проблема 4. Сложность оценки

Оценить качество ответов RAG объективно непросто. Сложно даже подготовить эталонный набор.

Решения:

• использовать RAGAS (OSS-фреймворк для оценки RAG)
• автоматически считать метрики корректности ответа, релевантности, верности контексту
• LLM-as-a-Judge (другая LLM ставит оценки)

Проблема 5. Многоязычность и мультимодальность

Документы со смесью языков, PDF с картинками, таблицы и графики — всё это сложно обрабатывать.

Решения:

• многоязычные эмбеддинги (BGE-M3, Cohere Multilingual)
• заранее конвертировать картинки и таблицы в текст (OCR + VLM)
• мультимодальные эмбеддинги (CLIP, Nomic и т. п.)

10. Обзор основных инструментов и сервисов

Сводка основных инструментов для построения RAG по категориям.

Фреймворки и библиотеки

• LangChain — самый распространённый фреймворк для RAG
• LlamaIndex — фокус на коннекторах данных
• Haystack — enterprise-уровень
• DSPy — автооптимизация промптов

Векторные БД (managed)

• Pinecone — отраслевой стандарт
• Weaviate Cloud — поддержка GraphQL
• Qdrant Cloud — высокая производительность
• Zilliz Cloud — managed-версия Milvus

Векторные БД (OSS, self-host)

• Chroma — лёгкий, сразу работает в Python
• Qdrant — Rust, быстрый
• Weaviate — OSS-версия
• Milvus — для крупного масштаба
• pgvector — расширение PostgreSQL

Эмбеддинг-модели

• OpenAI text-embedding-3 — стандартный, дешёвый
• Voyage AI — рекомендован Anthropic
• Cohere Embed v3 — многоязычная
• BGE-M3 — лучший в OSS

No-code / managed-RAG

• ChatGPT Projects / Custom GPTs — RAG от OpenAI
• Claude Projects — RAG от Anthropic
• Notion AI — поиск по документам в Notion
• Microsoft Copilot (Microsoft 365) — кросс-поиск по SharePoint и Teams
• Dify — OSS-платформа no-code AI
• Vertex AI Agent Builder — RAG в Google Cloud
• Amazon Bedrock Knowledge Bases — managed-RAG в AWS

Инструменты оценки

• RAGAS — OSS-фреймворк оценки RAG
• TruLens — оценка LLM-приложений в целом
• LangSmith — официальная трассировка и оценка от LangChain

FAQ

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