Что такое RAG

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

Определение простыми словами

Retrieval-Augmented Generation (дословно «генерация, дополненная извлечением») - это связка из двух этапов:

1. Извлечение (поиск) - по запросу пользователя система находит наиболее подходящие фрагменты текста в корпусе: wiki, PDF, тикеты, код, регламенты.
2. Generation (генерация) - LLM получает найденные фрагменты как контекст и формулирует ответ, опираясь на них.

Термин закрепился после работы Lewis et al. (2020) и быстро стал стандартом для корпоративных чат-ботов, систем поддержки и внутренних ассистентов. RAG не заменяет модель - он дополняет её актуальными данными, которых не было в обучении или которые изменились вчера.

Как работает RAG: типичный пайплайн

┌──────────┐    ┌─────────────┐    ┌──────────────┐    ┌─────────┐
│ Документы│───▶│ Chunking +  │───▶│ Vector DB    │    │         │
│ (PDF, MD)│    │ Embeddings  │    │ (индекс)     │    │   LLM   │
└──────────┘    └─────────────┘    └──────┬───────┘    │         │
                                          │            │         │
Запрос пользователя ──▶ Embedding ──▶ Top-K ──▶ Prompt + контекст ──▶ Ответ

1. Подготовка данных

• Загрузка - парсинг PDF, HTML, Markdown, Confluence, Notion, репозиториев.
• Нарезка на фрагменты - разбиение на фрагменты по 256-1024 токенов с перекрытием, чтобы не рвать смысл на границе абзаца.
• Эмбеддинг - каждый фрагмент превращается в вектор моделью эмбеддингов (OpenAI text-embedding-3, Cohere, open-source BGE, E5).
• Индексация - векторы сохраняются в векторное хранилище: Pinecone, Weaviate, Qdrant, pgvector, Chroma"), Milvus.

Этот этап выполняется при добавлении или обновлении документов, не при каждом запросе пользователя.

2. Запрос

1. Вопрос пользователя тоже превращается в эмбеддинг тем же энкодером.
2. Векторная БД возвращает Top-K ближайших chunks (обычно K = 3-10).
3. Опционально - переранжирование: вторая модель пересортировывает кандидатов по релевантности точнее, чем чистое косинусное сходство.
4. Найденные фрагменты вставляются в system/user промпт вместе с инструкцией «отвечай только на основе контекста».
5. LLM генерирует ответ; иногда добавляют цитирование - ссылки на фрагмент id или страницу источника.

Качество RAG на 80% определяется качеством извлечения: если нужный фрагмент не попал в Top-K, модель либо галлюцинирует, либо честно говорит «не знаю».

Ключевые компоненты

В 2026 году многие фреймворки (LlamaIndex, LangGraph) и продукты (Cursor @Codebase, Notion AI, корпоративные Glean-подобные системы) реализуют RAG «под капотом», но понимание базового пайплайна нужно для отладки и тюнинга.

Где RAG применяют на практике

• Поддержка и FAQ - ответы по базе статей и прошлым тикетам без ручного поиска оператором.
• Внутренние wiki - «как оформить отпуск», «где лежит инструкция по инцидентам».
• Legal и соответствие требованиям - поиск по договорам и регламентам с указанием пункта.
• Code assistants - семантический поиск по репозиторию (индекс файлов + embeddings), дополнение к полному контексту в IDE.
• Аналитика документов - вопросы к отчётам, исследованиям, транскриптам встреч.

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

RAG против дообучения и длинного контекста

Эти подходы не взаимоисключающие. Типичная схема 2026 года: RAG для поиска по корпусу + long context для нескольких полных файлов + лёгкое дообучение или системный промпт под тональность компании.

Ограничения и типичные проблемы

RAG решает проблему доступа к знаниям, но не:

• гарантию фактической точности (модель может игнорировать контекст)
• сложные многошаговые действия (для этого нужны tools / MCP)
• автоматическую актуализацию индекса (нужен ETL при изменении документов)

Частые сбои:

• Плохая нарезка на фрагменты - таблица разрезана пополам, формула потеряла заголовок.
• Неверный K - слишком мало фрагментов → пропуск фактов; слишком много → шум в промпте.
• Устаревший индекс - документ обновили, эмбеддинг не пересчитали.
• Гибридный поиск не настроен - чистый семантический поиск промахивается по точным SKU, ID, датам; помогает связка точного поиска по ключевым словам с поиском по смыслу.

Для продакшена добавляют: мониторинг извлечения и хит-рейт, A/B-тесты размера фрагмента, обратная связь от людей на ответы, защитные правила «если уверенность модели низкая - не отвечай».

Как улучшить RAG-систему

1. Метаданные - теги отдела, дата, версия документа; фильтрация до векторного поиска.
2. Hybrid search - keyword (BM25) + semantic; особенно для технической документации.
3. Reranker - cross-encoder после первичного Top-20 → финальные Top-5.
4. Трансформация запроса - перефразирование вопроса, multi-query, HyDE (гипотетический документ).
5. RAG на графе - для связных сущностей (люди, проекты, зависимости) поверх плоских фрагментов.
6. Оценка качества - датасет вопрос-эталонный ответ; метрики точности по фактам, context recall (RAGAS, DeepEval).

Начинать стоит с простого пайплайна (chunk → embed → Top-5 → GPT), замерить базовую линию, затем добавлять сложность только там, где метрики растут.

RAG и экосистема агентов

RAG часто идёт в паре с MCP и вызов инструментов: RAG достаёт знания из документов, инструменты выполняют действия (создать тикет, запросить баланс счёта). В Cursor семантический индекс @Codebase - частный случай RAG над файлами проекта; в корпоративных стеках тот же паттерн масштабируют на Confluence, Slack и CRM.

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

RAG добавляет инженерную сложность и требует поддержки, поэтому внедрять его стоит не всегда:

• База знаний маленькая и почти не меняется - текст проще один раз вставить в системный промпт, без поиска и векторной БД.
• Нет ресурсов поддерживать пайплайн - индекс нужно обновлять при изменении документов и следить за качеством поиска; без выделенной команды или подрядчика система быстро устаревает и начинает давать неверные ответы.
• Нужна гарантированная точность - для расчётов, юридических формулировок и других задач, где ошибка недопустима, надёжнее детерминированные системы и проверка человеком, а не генерация текста моделью.
• Задача не про поиск по документам, а про действия - создать заявку, изменить запись в системе - сам по себе RAG не поможет, нужны инструменты/MCP (см. раздел ниже).

Перед стартом стоит прикинуть объём документов, частоту их изменения и кто будет отвечать за индекс - это и определяет, окупится ли RAG или хватит более простого решения.

Итог

RAG - стандартный способ подключить LLM к вашим данным без переобучения модели: документы индексируются, по запросу извлекаются релевантные фрагменты, модель отвечает с опорой на них. Подход масштабируется от прототипа на Chroma + OpenAI до кластера с гибридным поиском, переранжированием и мониторингом качества.

Для первого проекта: выберите один корпус (например, FAQ на 50 страниц), настройте нарезку на фрагменты и Top-K, измерьте, попадает ли правильный абзац в контекст - это главный предиктор успеха всей системы.

Если нужна помощь с разработкой, внедрением ИИ или сопровождением сайта под вашу задачу - напишите мне.

Часто задаваемые вопросы

Чем RAG отличается от дообучения?

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

Нужен ли RAG, если у модели контекст на миллион токенов?

Длинный контекст (1M+ токенов у Claude, Gemini, GPT-5.6) позволяет загрузить много текста в одну сессию, но не заменяет RAG для больших корпусов: вся база из 100 GB PDF в промпт не влезет, а стоимость и латентность растут линейно. RAG выбирает релевантные куски; long context удобен для нескольких полных файлов после извлечения или для кода текущего репозитория в IDE. На практике комбинируют оба подхода.

Какую векторную базу выбрать для RAG?

Зависит от масштаба и инфраструктуры. pgvector - если уже есть PostgreSQL и объём до миллионов векторов. Qdrant, Weaviate, Milvus - self-hosted или управляемый при росте и нужде в фильтрах по метаданным. Pinecone - управляемый без возни с кластером. Chroma - быстрый старт для прототипа. Критичны не столько «бренд» БД, сколько качество эмбеддингов, нарезка на фрагменты и мониторинг; многие продакшен-системы начинали с Chroma и мигрировали на pgvector или Qdrant без смены логики приложения.

Почему RAG иногда выдаёт неверные ответы?

Основные причины: (1) извлечение промахнулось - нужный фрагмент не попал в Top-K; (2) модель проигнорировала контекст и достроила из «памяти»; (3) устаревший индекс - в документе уже другая цифра; (4) противоречивые фрагменты - модель усреднила. Лечится улучшением поиска (hybrid, reranker), жёстким prompt («если нет в контексте - скажи не знаю»), цитированием источников и набором проверки качества для регрессий.

Можно ли строить RAG на локальных моделях?

Да. Модели эмбеддингов (bge-m3, nomic-embed) и LLM (Llama, Qwen, Mistral через Ollama) работают offline; векторное хранилище тоже можно поднять локально. Ограничения - качество извлечения и generation на слабом железе, нужно подбирать размер модели под GPU/RAM. Для конфиденциальных данных (медицина, финансы, гос-сектор) local RAG - частый выбор: документы не покидают периметр компании, а архитектура пайплайна та же, что в облаке.

Термины в статье

RAG — Retrieval-Augmented Generation — генерация с дополненным поиском

промпт — prompt — текст-инструкция или запрос к модели

пайплайн — pipeline — цепочка автоматических шагов обработки

LLM — Large Language Model — большая языковая модель

Confluence — Atlassian wiki for team documentation — вики Atlassian для командной документации

эмбеддинг — embedding — числовой вектор, отражающий смысл текста

индексация — indexing — добавление страниц в индекс поисковика

Pinecone — managed vector database for similarity search — управляемая векторная БД для поиска по сходству

pgvector — PostgreSQL extension for vector search — расширение PostgreSQL для векторного поиска

переранжирование — reranking — переранжирование кандидатов (reranking)

Qdrant — vector database for similarity search — векторная БД для поиска по сходству

Chroma — open-source embedding database for RAG apps — хранилище эмбеддингов (embeddings) с открытым кодом (open-source) для RAG

chunks — small text pieces indexed for retrieval — небольшие фрагменты текста для поиска и RAG

top-k — keep only the k most likely next tokens when sampling — при генерации оставляют только k самых вероятных токенов

orchestrator — component that coordinates steps/services — оркестратор

ANN-поиск — ANN search — приближённый поиск ближайших соседей по векторам

LlamaIndex — framework for connecting LLMs to private data — фреймворк для подключения LLM к частным данным

LangChain — framework for building LLM applications — фреймворк для приложений на больших языковых моделях

дообучение — fine-tuning — дополнительное обучение модели под вашу задачу

латентность — latency — задержка до получения ответа

системный промпт — system prompt — скрытые инструкции, которые задают поведение модели

long context — model that can take a very large prompt in one go — модель, которая принимает очень длинный промпт за раз

паттерн — reusable solution pattern for a common design problem — повторно используемый приём для типовой задачи проектирования

hybrid search — keyword plus vector search together — гибридный поиск: ключевые слова + векторы

cross-encoder — rerank model that scores query and document together — реранкер: оценивает запрос и документ вместе

reranker — model that reorders search hits by relevance — модель, которая переупорядочивает выдачу по релевантности

проверка человеком — human review — проверка человеком (human review)

SKU — Stock Keeping Unit — единица складского учёта

MCP — Model Context Protocol — протокол контекста модели

CRM — Customer Relationship Management — управление взаимоотношениями с клиентами

self-hosted — software you run on your own servers — ПО на собственном сервере

проверки качества — evals — проверки качества ответов модели (evals)

GPU — Graphics Processing Unit — графический процессор