RAG: что это и когда он действительно нужен

Проверено 6 мая 2026 года. Это техническая опорная страница по RAG на Toolarium. Её задача не в том, чтобы выбрать одну «лучшую» векторную базу или единственный «правильный» фреймворк, а в более полезной задаче: быстро понять, когда retrieval-augmented generation действительно решает проблему, где хватает длинного контекста или обычного поиска и какие соседние материалы читать дальше.

Если вам нужен маршрут по всему LLM-кластеру, сначала откройте полный гайд по LLM для разработчиков. Если терминология пока плавает, рядом есть базовый разбор что такое LLM и как они работают. Здесь фокус уже инженерный: документы, поисковый слой, доступы, метрики, гибридный поиск и соседние маршруты вроде LangChain vs LlamaIndex или выбора векторной базы данных.

RAG: быстрый ответ

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

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

Где проходит граница этой страницы

Для этой страницы важнее всего не разрастись обратно в общий обзор LLM-стека. RAG — это отдельный интент внутри кластера, а не место, где одновременно выбирают модель, базу и слой оркестрации.

Карта кластера RAG

Главная проблема большинства RAG-материалов простая: они пытаются в одной статье одновременно объяснить поиск по фрагментам, сравнить базы, выбрать фреймворк, показать продакшн-кейс и ещё обсудить агентов. Для читателя это неудобно. Ниже карта соседних интентов, чтобы вы сразу ушли в нужную глубину.

Когда RAG нужен, а когда нет

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

Сначала стоит ответить на четыре вопроса.

1. Документы часто меняются или нет?
2. Пользователь должен видеть источник ответа или нет?
3. Нужен доступ к данным по правам и ролям или нет?
4. Сколько документов реально участвует в типовом вопросе: три, тридцать или триста тысяч?

После этого выбор обычно выглядит так.

Отдельно стоит помнить о выводе из Lost in the Middle: длинный контекст сам по себе не гарантирует, что модель хорошо использует информацию из середины входа. Именно поэтому идея «просто положим всё в промпт» редко оказывается надёжной заменой поисковому слою.

Как работает RAG-система

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

1. Подготовка документов

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

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

2. Индексация

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

Если вы работаете в российском или закрытом контуре, добавляется ещё один слой решения: где будут жить документы и где будет выполняться inference. Тогда RAG часто проектируют вместе с локальным стеком, и полезно заранее посмотреть материалы про локальный запуск через Ollama.

3. Retrieval и ранжирование

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

Именно поэтому продакшн-RAG часто использует гибридный retrieval: семантический поиск плюс BM25, полнотекстовый поиск, фильтры по метаданным и иногда отдельный reranking. Если retrieval нашёл нужный документ, но не поднял его в верх выдачи, проблема обычно не в генераторе ответа, а в ранжировании.

4. Сборка контекста и генерация

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

Как не перепутать embeddings, базу и фреймворк

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

Архитектуры RAG: от 2-step до agentic

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

Agentic RAG не стоит включать только потому, что слово звучит современно. Как только retrieval становится инструментом внутри агента, растут требования к журналированию, безопасности и лимитам действий. Если эта часть вам важна, держите рядом материал про ИИ-агентов, а спор про SDK выносите в отдельное сравнение LangChain vs LlamaIndex.

Минимальный пример RAG на Python

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

from langchain_community.document_loaders import DirectoryLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
from langchain_community.vectorstores import FAISS
from langchain_openai import OpenAIEmbeddings, ChatOpenAI

loader = DirectoryLoader("./docs", glob="**/*.md")
documents = loader.load()

splitter = RecursiveCharacterTextSplitter(
    chunk_size=700,
    chunk_overlap=100,
)
chunks = splitter.split_documents(documents)

embeddings = OpenAIEmbeddings(model="YOUR_EMBEDDING_MODEL")
vectorstore = FAISS.from_documents(chunks, embeddings)

retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

prompt = ChatPromptTemplate.from_messages([
    ("system", "Отвечай только по найденному контексту. Если ответа нет, так и скажи.\\n\\n{context}"),
    ("human", "{input}"),
])

llm = ChatOpenAI(model="YOUR_CHAT_MODEL")
combine_docs_chain = create_stuff_documents_chain(llm, prompt)
rag_chain = create_retrieval_chain(retriever, combine_docs_chain)

result = rag_chain.invoke(
    {"input": "Какие ограничения есть в тарифе Enterprise?"}
)

print(result["answer"])
for doc in result["context"]:
    print(doc.metadata.get("source"))

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

Где RAG ломается и что мерить

Вот где ломается большинство проектов.

• В индекс попадает мусор: плохо распознанные PDF, устаревшие версии документов, дубли, сломанные таблицы.
• Retrieval не знает про права доступа и приносит документ, который пользователь не должен видеть.
• В контекст отправляют слишком много фрагментов «на всякий случай», и модель цепляется за шум.
• У системы нет честного отказа от ответа, поэтому она достраивает ответ из общих знаний модели.
• Команда оценивает качество по трём удачным вопросам вместо тестового набора.

RAG удобно считать двухконтурной системой. Сначала измеряется retrieval. Потом уже generation. Если смешать их в одну оценку, спор быстро скатывается в «кажется, стало лучше».

Именно поэтому Ragas удобен как стартовый набор метрик: он не заменяет ручную проверку экспертом, но помогает перестать спорить на ощущениях. На практике сначала смотрите, нашёл ли retrieval нужный контекст, и только потом обсуждайте модель.

Рабочий маршрут внедрения

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

1. Соберите 50-100 реальных вопросов пользователей, а не «демо-запросы для презентации».
2. Для каждого вопроса зафиксируйте, в каком документе лежит правильный ответ и какие права доступа к нему должны применяться.
3. Проверьте качество извлечения текста из исходников: PDF, HTML, Markdown, таблицы, вложения, служебные поля.
4. Выберите стартовую стратегию чанкинга и сохраните вместе с текстом метаданные: раздел, URL, дата, продукт, уровень доступа.
5. Сравните обычный векторный поиск с гибридным retrieval на одном и том же наборе вопросов.
6. Добавьте reranking, только если retrieval находит нужное, но не умеет правильно ранжировать выдачу.
7. Настройте ответ с цитатами или ссылками на источник и с явным отказом, если ответа в найденных документах нет.
8. После каждого изменения отдельно измеряйте retrieval и generation. Иначе прогресс неотличим от шума.

Если вам нужен прикладной ориентир, а не только теория, посмотрите кейс AI-ассистента для колл-центра. Там хорошо видно, как retrieval и качество источников начинают влиять не на абстрактную «умность модели», а на живой бизнес-процесс.

Что читать дальше по кластеру RAG

Удобнее всего идти по одному из четырёх маршрутов.

1. База и архитектура

• Полный гайд по LLM для разработчиков
• Что такое LLM: как работают большие языковые модели

2. Retrieval и хранение

• Векторные базы данных для RAG
• Как встроить ИИ-поиск в приложение с эмбеддингами

3. Фреймворки и локальный стек

• LangChain vs LlamaIndex
• Ollama: как запустить локальную LLM

4. Агентные и прикладные сценарии

• ИИ-агенты: что это такое, как работают и где полезны
• AI-ассистент для колл-центра: продакшн-кейс

И ещё одно практическое напоминание. Если retrieval уже не находит нужный документ, не лечите это новой моделью. Сначала чините индекс, документы и ранжирование. В RAG это почти всегда даёт больше пользы, чем очередная смена модели в API.

Источники и дата проверки

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, Patrick Lewis et al., NeurIPS 2020. Базовая работа, откуда пошёл сам термин RAG.
• LangChain Docs: Retrieval, проверено 6 мая 2026 года. Описывает retrieval как ответ на ограниченный контекст и статичность знаний модели, а также разводит 2-step, agentic и hybrid RAG.
• Lost in the Middle: How Language Models Use Long Contexts, Nelson F. Liu et al., 2023. Показывает, что длинный контекст не равен надёжному использованию информации из середины входа.
• Ragas Docs: available metrics, проверено 6 мая 2026 года. Источник по context precision, context recall, response relevancy, faithfulness и связанным метрикам для RAG.