Что такое RAG
RAG (Retrieval-Augmented Generation) - подход, при котором языковая модель перед ответом находит релевантные фрагменты из вашей базы знаний и только потом генерирует текст. Вместо того чтобы «помнить» все документы в весах модели или загружать их целиком в контекст, система ищет нужные куски и подставляет их в промпт. Ниже - что такое RAG, как устроен пайплайн и когда этот метод оправдан в production.
Определение простыми словами
Retrieval-Augmented Generation - это связка из двух этапов:
- Retrieval (поиск) - по запросу пользователя система находит наиболее подходящие фрагменты текста в корпусе: wiki, PDF, тикеты, код, регламенты.
- Generation (генерация) - LLM получает найденные фрагменты как контекст и формулирует ответ, опираясь на них.
Термин закрепился после работы Lewis et al. (2020) и быстро стал стандартом для корпоративных чат-ботов, support-систем и внутренних ассистентов. RAG не заменяет модель - он дополняет её актуальными данными, которых не было в обучении или которые изменились вчера.
Как работает RAG: типичный пайплайн
┌──────────┐ ┌─────────────┐ ┌──────────────┐ ┌─────────┐
│ Документы│───▶│ Chunking + │───▶│ Vector DB │ │ │
│ (PDF, MD)│ │ Embeddings │ │ (индекс) │ │ LLM │
└──────────┘ └─────────────┘ └──────┬───────┘ │ │
│ │ │
Запрос пользователя ──▶ Embedding ──▶ Top-K ──▶ Prompt + контекст ──▶ Ответ
1. Подготовка данных (offline)
- Загрузка - парсинг PDF, HTML, Markdown, Confluence, Notion, репозиториев.
- Chunking - разбиение на фрагменты по 256-1024 токенов с перекрытием (overlap), чтобы не рвать смысл на границе абзаца.
- Embedding - каждый chunk превращается в вектор моделью эмбеддингов (OpenAI text-embedding-3, Cohere, open-source BGE, E5).
- Индексация - векторы сохраняются в vector store: Pinecone, Weaviate, Qdrant, pgvector, Chroma, Milvus.
Этот этап выполняется при добавлении или обновлении документов, не при каждом запросе пользователя.
2. Запрос (online)
- Вопрос пользователя тоже превращается в embedding тем же энкодером.
- Vector DB возвращает Top-K ближайших chunks (обычно K = 3-10).
- Опционально - reranking: вторая модель пересортировывает кандидатов по релевантности точнее, чем чистый cosine similarity.
- Найденные фрагменты вставляются в system/user prompt вместе с инструкцией «отвечай только на основе контекста».
- LLM генерирует ответ; иногда добавляют цитирование - ссылки на chunk id или страницу источника.
Качество RAG на 80% определяется качеством retrieval: если нужный фрагмент не попал в Top-K, модель либо галлюцинирует, либо честно говорит «не знаю».
Ключевые компоненты
| Компонент | Роль | Примеры |
|---|---|---|
| Embedding model | Текст → вектор для семантического поиска | text-embedding-3-large, bge-m3, voyage-3 |
| Vector database | Хранение и быстрый ANN-поиск | Qdrant, Pinecone, pgvector, Weaviate |
| Chunking strategy | Баланс между детализацией и шумом | Fixed size, semantic split, по заголовкам |
| LLM | Финальный ответ с рассуждением | GPT-5.6, Claude Fable 5, Gemini 3.1, локальные модели |
| Orchestrator | Связка этапов, кэш, логирование | LangChain, LlamaIndex, Haystack, свой код |
В 2026 году многие фреймворки (LlamaIndex, LangGraph) и продукты (Cursor @Codebase, Notion AI, корпоративные Glean-подобные системы) реализуют RAG «под капотом», но понимание базового пайплайна нужно для отладки и тюнинга.
Где RAG применяют на практике
- Support и FAQ - ответы по базе статей и прошлым тикетам без ручного поиска оператором.
- Внутренние wiki - «как оформить отпуск», «где лежит runbook для инцидента».
- Legal и compliance - поиск по договорам и регламентам с указанием пункта.
- Code assistants - семантический поиск по репозиторию (индекс файлов + embeddings), дополнение к полному контексту в IDE.
- Аналитика документов - вопросы к отчётам, исследованиям, транскриптам встреч.
Общий паттерн: большой корпус, частые обновления, нужны ссылки на источник - RAG подходит лучше, чем разовая загрузка файла в чат.
RAG vs fine-tuning vs длинный контекст
| Подход | Когда уместен | Ограничение |
|---|---|---|
| RAG | Актуальные документы, прозрачные источники, быстрые обновления без переобучения | Зависит от качества поиска |
| Fine-tuning | Стиль, формат, доменная терминология, стабильные знания | Дорого обновлять при смене данных |
| Long context | Нужен весь документ или кодовая база целиком в одной сессии | Стоимость, латентность, «lost in the middle» |
Эти подходы не взаимоисключающие. Типичная схема 2026 года: RAG для поиска по корпусу + long context для нескольких полных файлов + лёгкий fine-tuning или system prompt под tone of voice компании.
Ограничения и типичные проблемы
RAG решает проблему доступа к знаниям, но не:
- гарантию фактической точности (модель может игнорировать контекст)
- сложные многошаговые действия (для этого нужны tools / MCP)
- автоматическую актуализацию индекса (нужен ETL при изменении документов)
Частые сбои:
- Плохой chunking - таблица разрезана пополам, формула потеряла заголовок.
- Неверный K - слишком мало chunks → пропуск фактов; слишком много → шум в промпте.
- Устаревший индекс - документ обновили, embedding не пересчитали.
- Гибридный поиск не настроен - чистый semantic search промахивается по точным SKU, ID, датам; помогает hybrid (BM25 + vectors).
Для production добавляют: мониторинг retrieval hit rate, A/B тесты chunk size, human feedback на ответы, guardrails «если confidence низкий - не отвечай».
Как улучшить RAG-систему
- Метаданные - теги отдела, дата, версия документа; фильтрация до vector search.
- Hybrid search - keyword (BM25) + semantic; особенно для технической документации.
- Reranker - cross-encoder после первичного Top-20 → финальные Top-5.
- Query transformation - перефразирование вопроса, multi-query, HyDE (гипотетический документ).
- Graph RAG - для связных сущностей (люди, проекты, зависимости) поверх плоских chunks.
- Evaluation - датасет вопрос-эталонный ответ; метрики faithfulness, context recall (RAGAS, DeepEval).
Начинать стоит с простого pipeline (chunk → embed → Top-5 → GPT), замерить baseline, затем добавлять сложность только там, где метрики растут.
RAG и экосистема агентов
RAG часто идёт в паре с MCP и tool calling: RAG достаёт знания из документов, tools выполняют действия (создать тикет, запросить баланс счёта). В Cursor семантический индекс @Codebase - частный случай RAG над файлами проекта; в enterprise-стеках тот же паттерн масштабируют на Confluence, Slack и CRM.
| Слой | Задача |
|---|---|
| RAG | «Что написано в документах?» |
| MCP / tools | «Что сейчас в системе? Сделай действие» |
| LLM | Синтез ответа и планирование шагов |
Итог
RAG - стандартный способ подключить LLM к вашим данным без переобучения модели: документы индексируются, по запросу извлекаются релевантные фрагменты, модель отвечает с опорой на них. Подход масштабируется от прототипа на Chroma + OpenAI до кластера с гибридным поиском, reranking и мониторингом качества.
Для первого проекта: выберите один корпус (например, FAQ на 50 страниц), настройте chunking и Top-K, измерьте, попадает ли правильный абзац в контекст - это главный предиктор успеха всей системы.
Часто задаваемые вопросы
Чем RAG отличается от fine-tuning?
Fine-tuning меняет веса модели на ваших примерах - подходит для стиля, формата и устойчивых паттернов. RAG не трогает веса: при каждом запросе подтягивает свежие фрагменты из индекса. Документы, которые меняются каждую неделю, проще обновлять через RAG (переиндексация), чем через повторное обучение. Fine-tuning лучше, когда нужно, чтобы модель «знала» процедуру наизусть без поиска; RAG - когда важны актуальность и ссылка на источник.
Нужен ли RAG, если у модели контекст на миллион токенов?
Длинный контекст (1M+ токенов у Claude, Gemini, GPT-5.6) позволяет загрузить много текста в одну сессию, но не заменяет RAG для больших корпусов: вся база из 100 GB PDF в prompt не влезет, а стоимость и латентность растут линейно. RAG выбирает релевантные куски; long context удобен для нескольких полных файлов после retrieval или для кода текущего репозитория в IDE. На практике комбинируют оба подхода.
Какую векторную базу выбрать для RAG?
Зависит от масштаба и инфраструктуры. pgvector - если уже есть PostgreSQL и объём до миллионов vectors. Qdrant, Weaviate, Milvus - self-hosted или managed при росте и нужде в фильтрах по metadata. Pinecone - managed без возни с кластером. Chroma - быстрый старт для прототипа. Критичны не столько «бренд» БД, сколько качество embeddings, chunking и мониторинг; многие production-системы начинали с Chroma и мигрировали на pgvector или Qdrant без смены логики приложения.
Почему RAG иногда выдаёт неверные ответы?
Основные причины: (1) retrieval промахнулся - нужный chunk не попал в Top-K; (2) модель проигнорировала контекст и достроила из «памяти»; (3) устаревший индекс - в документе уже другая цифра; (4) противоречивые chunks - модель усреднила. Лечится улучшением поиска (hybrid, reranker), жёстким prompt («если нет в контексте - скажи не знаю»), цитированием источников и eval-набором для регрессий.
Можно ли строить RAG на локальных моделях?
Да. Embedding-модели (bge-m3, nomic-embed) и LLM (Llama, Qwen, Mistral через Ollama) работают offline; vector store тоже можно поднять локально. Ограничения - качество retrieval и generation на слабом железе, нужно подбирать размер модели под GPU/RAM. Для конфиденциальных данных (медицина, финансы, гос-сектор) local RAG - частый выбор: документы не покидают перimeter, а архитектура pipeline та же, что в облаке.