Что такое RAG и зачем он бизнесу

RAG (Retrieval-Augmented Generation), архитектурный паттерн, в котором LLM получает дополнительный контекст из внешнего хранилища ДО генерации ответа. Формально: вместо answer = LLM(question) выполняется answer = LLM(question + retrieve(question, KB)), где retrieve, функция поиска по корпусу документов.

Паттерн появился в работе Lewis et al. 2020 («Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», Facebook AI) и к 2026 году стал доминирующим способом подключения LLM к корпоративным данным, потому что закрывает три фундаментальных ограничения, которых не решают ни fine-tuning, ни длинный контекст, ни tool use по совокупности качество / цена / скорость внедрения.

Три проблемы LLM, которые решает RAG

1. Параметрические знания заморожены на дате тренировки

Knowledge cutoff топовых моделей в 2026:

• Claude Opus 4.7 / Sonnet 4.6, начало 2026
• GPT-5, конец 2025
• Gemini 2.5 Pro, середина 2025
• Llama 3.3 70B, начало 2024

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

• «Какой текущий статус договора с ООО „Ромашка"?», данных нет в обучении.
• «Что изменилось в regulation v2.4?», регламент внутренний.
• «Какая последняя сигнатура endpoint /v3/users?», могла измениться после cutoff.

2. Галлюцинации, статистическая особенность, а не баг

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

Цифры с публичных бенчмарков (TruthfulQA, корпоративный QA, FactScore):

• Без RAG: GPT-4o ≈ 65–70% truthful answers; на специфичных корпоративных вопросах падает до 20–40%.
• С базовым RAG: 70–85% на тех же корпоративных вопросах.
• С продвинутым RAG (rerank + контекстное обогащение): 85–93%.

Anthropic в исследовании Contextual Retrieval (сентябрь 2024) показал снижение retrieval failure rate на 49% после добавления контекста к чанкам и на 67% при комбинации с rerank.

3. Контекст ограничен и дорог

У современных моделей контекст 200K–2M токенов (Claude Sonnet 4.6, 1M, Gemini 2.5 Pro, 2M, GPT-5, 400K). Кажется, что «можно подать всё». На практике:

• Цена. Prefill 1M токенов на топовых API = $3–15 на запрос. 1000 запросов/день = $3K–15K/день только на ввод.
• Latency. TTFT (time to first token) при 1M контексте, 30–90 секунд.
• Lost in the middle (Liu et al. 2023, Stanford). Модели хуже находят информацию в середине длинного контекста: точность на recall-задачах падает с 75% (информация в начале) до 50% (в середине).

RAG решает всё три: подаёт только релевантные 4–20K токенов, отвечает за 1–3 секунды, стоит центы за запрос.

RAG среди альтернатив

Подход	Когда подходит	Слабость
Long context (1M+)	Корпус до ~100 документов, разовые анализы	Цена ×100, latency ×30, lost-in-middle
Fine-tuning (LoRA, full)	Стиль/формат, классификация, специфичные форматы вывода	Не работает для фактов: модель помнит ≠ цитирует. Каждое обновление = новый чекпоинт
Function calling / tools	Структурированные источники: БД, REST API, калькулятор	Не для свободного текста; нужна точная схема
RAG	Неструктурированный текст, динамические данные	Сложность инфраструктуры, требует data quality
Agentic RAG	Многошаговые запросы через несколько источников	Latency, отладка, цена в 3–10×
Cache-Augmented Generation (CAG)	Маленькая база, повторяющиеся запросы	Только для малых корпусов; не масштабируется

В реальном проде это комбинация: function calling для структурки (CRM, ERP) + RAG для документов + лёгкий fine-tune для стиля ответа.

Архитектура одного запроса (high-level)

[user query]
     │
     ▼
[query rewriter / decomposer]    ◄── LLM-call #1 (опц.): нормализация, expansion
     │
     ▼
[retriever]                      ◄── hybrid: dense (vectors) + sparse (BM25)
     │
     ▼  top-50 кандидатов
[reranker]                       ◄── cross-encoder (Cohere rerank-3, BGE-v2-m3)
     │
     ▼  top-5
[prompt assembler]               ◄── шаблон + инструкции + source IDs для цитирования
     │
     ▼
[generator LLM]                  ◄── LLM-call #2: основная генерация
     │
     ▼
[post-processor]                 ◄── проверка цитат, PII фильтр, guardrails
     │
     ▼
[answer + citations]

В типичном проде на запрос: 2 LLM-вызова + 1 vector search + 1 rerank + 1 BM25. Бюджет latency 1.5–3 сек, бюджет cost, $0.01–0.05.

Где RAG уже работает (продукты, которые вы знаете)

• Perplexity, You.com, RAG поверх веб-поиска: SerpAPI/Bing → fetcher → rerank → LLM.
• Glean, корпоративный поиск, $7B+ valuation: индексирует Google Drive, Slack, Confluence, Jira, Salesforce, GitHub.
• Notion AI, Coda AI, RAG на содержимом workspace.
• Cursor, Continue, Codeium, Sourcegraph Cody, code RAG: индексируют репозиторий, специальные эмбеддинги для кода (понимают AST).
• GitHub Copilot Chat / Workspace, RAG поверх кода + docs + Issues/PRs.
• Harvey AI, CaseText (Co-Counsel), юридический RAG по case law.
• Hebbia, AlphaSense, финансовый RAG по earnings calls и SEC-filings.
• ChatGPT с GPTs / Claude Projects, pre-built RAG поверх загруженных файлов.

Все они под капотом используют один и тот же паттерн: chunk → embed → store → retrieve → rerank → generate.

Типичный стек 2026

Усреднённая корпоративная RAG-система выглядит так:

Слой	Популярный выбор
Embedding	OpenAI text-embedding-3-large, BGE-M3, Voyage AI voyage-3, Cohere embed-v3
Vector DB	pgvector, Qdrant, Weaviate, Milvus, Pinecone, LanceDB
Sparse retrieval	Elasticsearch / OpenSearch (BM25), Tantivy
Reranker	Cohere rerank-3, BGE reranker-v2-m3, ColBERT-v2, mxbai-rerank-large
Generator LLM	Claude Sonnet 4.6, GPT-5, Gemini 2.5 Pro, Llama 3.3 70B (self-hosted)
Orchestration	LangChain, LlamaIndex, Haystack, DSPy, Semantic Kernel
Observability / eval	LangSmith, Langfuse, Phoenix (Arize), RAGAS, TruLens

Когда RAG, НЕ ваша задача

• Корпус помещается в контекст (≤ 50K токенов): просто подайте всё. Дешевле и точнее.
• Знания не текстовые (числовые таблицы, временные ряды): нужен Text-to-SQL агент или специализированный analytics-стек, не RAG.
• Нужна актуальность секундного уровня (биржа, метрики мониторинга): API/streaming, не RAG.
• Жёсткое требование 100% точности (медицинский диагноз как final answer, биржевые ордера): RAG ассистирует, решение, за человеком/специализированной системой.
• Малый объём + редкие запросы: операционная сложность RAG не окупится. Ставьте gpt-4o-mini с инструкцией «отвечай только на основе этого документа» и одним приложенным файлом.

Экономика типичного внедрения

Для оценки порядка стоимости (база 10M токенов корпоративных документов, 1000 запросов/день):

Статья	Цена	Периодичность
Embedding всей базы (OpenAI v3-large @ $0.13/1M)	$1.30	разово, при индексации
Re-embedding при обновлениях	$0.10–0.50	в день
Хранение (Qdrant managed на 10M chunk-ов)	$50–200	в месяц
Хранение (self-hosted Qdrant/pgvector на VPS)	$20–50	в месяц
Per-query: embedding запроса	$0.0001	на запрос
Per-query: rerank (Cohere rerank-3)	$0.001	на запрос
Per-query: Claude Sonnet 4.6 (5K in + 500 out)	$0.02–0.05	на запрос
Итого месячный inference (1K req/day × 30)	$600–1500	в месяц

Сравнение со «всё в контекст» (200K на каждый запрос на топовой модели): $0.60–2.00 на запрос = $18K–60K/месяц при том же объёме. Разница 20–60×.

Главный экономический эффект

RAG даёт LLM ровно столько контекста, сколько нужно для конкретного запроса. Это превращает универсальную модель в production-систему с ответственностью за факты:

• Точность 85–93% на корпоративных задачах вместо 20–40% «голой» модели.
• Стоимость на 1–2 порядка ниже long-context подхода.
• Latency 1–3 секунды вместо 30–90.
• Прозрачность через цитаты, каждое утверждение можно verify по source ID.
• Обновляемость без переобучения, изменили документ, пере-эмбеддинг (секунды), готово.

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