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

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

Один из таких способов — RAG (Retrieval-Augmented Generation, генерация с дополненной выборкой). Система ищет релевантную информацию во внешних материалах и добавляет её в контекст ответа. Готовые функции ИИ тоже могут обращаться к документам, но загрузка файла не всегда запускает один и тот же механизм поиска.

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

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

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

RAG — это механизм, в котором LLM (большая языковая модель) формирует ответ с учётом релевантной информации, найденной во внешних источниках. Здесь показан базовый вариант: сначала поиск, затем ответ. Источником может быть существующая БД или поиск по ключевым словам; отдельная векторная БД не обязательна.

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

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

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

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

Главная идея — не переобучать саму LLM, а передавать нужную информацию извне при каждом вопросе. Это отличается от дообучения, описанного ниже.

Руководство LangChain по поиску объясняет эту схему и использование существующих SQL-баз или систем документов как источников.

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

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

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

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

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

RAG может использовать информацию из новостей, БД или API. Но устаревший источник способен привести к устаревшему ответу. Нужны обновление документов и проверка результатов поиска.

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

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

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

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

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

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

RAG выбирает релевантные фрагменты для модели, но сам по себе не гарантирует конфиденциальность. Даже при собственной БД внешние API эмбеддингов или LLM получают документы, вопросы либо найденные фрагменты. Проверьте права пользователя при поиске, получателей данных, хранение и журналы. Эти различия разобраны в FAQ.

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 релевантных чанков (в этом примере — три)
   • близость считается, например, по косинусному сходству
2. Шаг 2: Augmented (расширение)
   • найденные чанки встраиваются в промпт как «справочный контекст»
   • примерно так: «Опираясь на следующее, ответь на вопрос: [результаты поиска] Вопрос: [вопрос пользователя]»
3. Шаг 3: Generation (генерация)
   • LLM (GPT, 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)

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

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

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

База данных или расширение, которое хранит векторы и ищет похожие. Подробнее — в следующем разделе.

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

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

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

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

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

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

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

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

[Вопрос]
{user_question}

[Ответ]

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

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

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

Что выбрать

Цены Pinecone и Weaviate проверены по официальным страницам 9 октября 2026 года. Даже бесплатное ПО требует ресурсов сервера и обслуживания. В облаке итог зависит от ёмкости, числа поисков, дополнительных функций ИИ, резервных копий и других параметров.

• Проба поиска в Python: Chroma и другие варианты; подготовьте пакеты и модели
• Уже есть PostgreSQL: pgvector позволяет объединить работу с БД
• Передать управление инфраструктурой сервису: managed-решения вроде Pinecone; индексы, ёмкость и права всё равно настраиваются
• Развёртывание у себя: например, Qdrant или Weaviate; эксплуатацию и права контролируете сами
• Много документов: оцените варианты вроде Milvus на реальных данных по индексам, ёмкости и поиску

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поиск по коду и проектным документам помогает выяснить, как использовать функцию или найти похожую логику. Обращение к коду полезно и в GitHub Copilot Chat, и в Cursor, Claude Code и других ИИ для разработки, но их внутренние процессы не обязательно совпадают с этой схемой.

Сценарий 8. Текстовые путеводители по материалам: llms.txt

llms.txt — предложение создавать текстовый путеводитель по материалам сайта. Он может помочь поиску и сбору документов, но не гарантирует, что ИИ прочитает их или правильно процитирует.

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

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

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

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

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

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

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

Условия дообучения различаются по сервисам. По официальным материалам OpenAI, проверенным 9 октября 2026 года, платформа дообучения недоступна новым пользователям. Сначала проверьте модели и условия договора.

Объединяйте и оценивайте при необходимости

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

Сначала определите ожидаемые ответы и способ оценки; проверьте, достаточно ли улучшить инструкции или добавить материалы. RAG стоит рассмотреть для обращения к источникам, дообучение — для настройки поведения ответов. Сравните стоимость, скорость и качество на реальных запросах. Рекомендации OpenAI также начинаются с оценки и улучшения промптов, а дообучение предлагается для подходящих задач. Локальный запуск дообученной модели зависит от распространения весов, лицензии и среды исполнения.

8. Прежде чем строить своё — проверьте на собственных документах

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

Шаг 1: проверьте, можно ли передать все материалы целиком

Если материалы помещаются в контекст выбранной модели, их можно передать без поиска. В объяснении Contextual Retrieval 2024 года Anthropic предложила включать базы меньше 200 000 токенов (около 500 страниц) целиком в промпт и использовать кэширование (официальное объяснение). Это число не является общим порогом для всех моделей. Учитывайте текущий лимит ввода, длину документов, качество ответов и стоимость.

Шаг 2: загрузите документы в готовую функцию «Проекты» и задайте вопросы

Projects в Claude автоматически переходят на RAG, когда знания проекта приближаются к пределу контекста, и вмещают до 10 раз больше материала. Это функция платных планов; при включении появляется индикатор, а при ответе Claude использует инструмент «project knowledge search» (Справочный центр Claude). В Projects у ChatGPT тоже можно добавлять файлы и задавать по ним вопросы, а ограничения, например число файлов, зависят от плана.

Шаг 3: проверьте на 10 вопросах, ответы на которые вы знаете

Составьте 10 вопросов, для которых вы знаете, где в документах ответ, и запишите три вещи.

1. Верен ли ответ?
2. Правильный ли фрагмент указан в качестве источника?
3. Когда вы спрашиваете о том, чего в документах нет, говорит ли он об этом?

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

Шаг 4: если нужен контроль, сравните свои и managed-решения

В качестве примера улучшений Anthropic сообщает, что сочетание Contextual Embeddings и Contextual BM25 снизило долю неудачных поисков среди топ-20 чанков на 49%, а с переранжированием — на 67% (условия и результаты эксперимента). Это измерения поиска на данных поставщика, а не гарантия такого же сокращения ошибок ответов у вас.

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

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

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

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

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

Это учебный пример поиска фрагментов PDF и передачи их модели для ответа. LangChain 1.x требует Python 3.10 или новее. Задайте API-ключ в переменной окружения OPENAI_API_KEY и обеспечьте доступ к используемым моделям OpenAI API. Не записывайте ключ в код или публичный репозиторий.

Пример отправляет текст PDF и вопросы в API эмбеддингов, а найденные фрагменты и вопросы — в API LLM. Локальная Chroma не делает все вычисления локальными. Условия и оплату API проверьте отдельно от подписки ChatGPT. Используйте неконфиденциальные материалы, которые разрешено передавать. Этот код — учебный пример, работа которого не проверена. Перед запуском сверьте его с официальной документацией для используемой версии библиотеки.

# pip install -U langchain-openai langchain-chroma langchain-text-splitters langchain-community pypdf
from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_chroma import Chroma

# 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)
retriever = vectorstore.as_retriever(search_kwargs={"k": 3})

# 4. Поиск (3 чанка, ближайших к вопросу)
question = "Сколько дней оплачиваемого отпуска?"
found = retriever.invoke(question)
context = "\n\n".join(d.page_content for d in found)

# 5. Передать источники и сгенерировать ответ
llm = ChatOpenAI(model="gpt-6-luna")
answer = llm.invoke([
    {"role": "system", "content": "Отвечай только по материалу ниже. Если ответа там нет, так и скажи.\n\n" + context},
    {"role": "user", "content": question},
])
print(answer.content)
print("Источники:", [d.metadata for d in found])

Пример рассчитан на поиск фрагментов PDF и передачу их GPT-6 Luna для ответа. Также выводятся метаданные найденных документов. Сведения о страницах зависят от источника и загрузчика; правильность цитат в ответе нужно проверять отдельно.

gpt-6-luna — ID, проверенный 9 октября 2026 года на официальной странице модели. Перед использованием сверьте API, условия и цены с официальным списком моделей. Сравнивайте модели на одинаковых материалах и вопросах по пониманию источников, качеству ответов, скорости и стоимости.

Код использует структуру пакетов LangChain 1.x. В LangChain 1.0 старый langchain.chains, включая RetrievalQA, перенесён в отдельный пакет langchain-classic. Разбиение импортируется из langchain_text_splitters; схема «2-Step RAG» записана двумя шагами: поиск, затем передача материала модели. Пути импорта и требования к Python сверяйте с официальным руководством по миграции. Записывайте версии пакетов и проверяйте реализацию в воспроизводимой среде.

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

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

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

При эксплуатации RAG проверяйте следующие аспекты.

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

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

Решения:

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

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

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

Решения:

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

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

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

Решения:

• сократить K (топ-3–5)
• сначала суммаризировать, потом передавать
• использовать LLM с длинным контекстом (предел у каждой модели свой, сейчас есть модели порядка миллиона токенов; лимит своей модели сверьте с официальной документацией)

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

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

Решения:

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

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

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

Решения:

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

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

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

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

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

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

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

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

• Chroma — векторный поиск из Python
• Qdrant — векторный поиск и фильтры
• Weaviate — OSS-версия
• Milvus — векторная база данных
• pgvector — расширение PostgreSQL

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

• OpenAI text-embedding-3 — генерация эмбеддингов через API
• Voyage AI — упомянута в документации Anthropic
• Cohere Embed — многоязычная
• BGE-M3 — многоязычный кандидат для локального запуска

No-code / managed-RAG

• ChatGPT Projects / существующие Custom GPTs — готовые функции для обращения к материалам; проверьте обработку и условия каждой
• Claude Projects — RAG от Anthropic
• Notion AI — поиск по документам в Notion
• Microsoft Copilot (Microsoft 365) — кандидат для обращения к внутренним материалам; проверьте договор, подключения и права
• 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

Если хотите глубже разобраться в fine-tuning, прочитайте также что такое fine-tuning: когда применять его вместо RAG и методы вроде LoRA/QLoRA, для новичков.

FAQ

9 октября 2026 года описания цен, доступности продуктов и обработки данных API сверены с официальными материалами. Код, API, расходы и защита конфиденциальности в реальной среде не испытывались. Перед внедрением проверьте актуальные условия сервисов.