TL;DR

RAG (Retrieval-Augmented Generation) — это способ заставить LLM отвечать по вашим данным: договорам, базе знаний, истории клиентов — а не по тому, что модель «помнит» из обучения. В 2026 это стандарт для любого корпоративного AI-агента: без RAG модель либо галлюцинирует, либо отвечает общо.

Что важно знать:
– Цена внедрения RAG в проект: +80–250 тыс ₽ к базовой стоимости агента
– Главная сложность — не «вставить векторный поиск», а правильно подготовить и поддерживать данные
– 60% RAG-проектов с проблемами качества — из-за плохого chunking и метаданных, не из-за модели
– Топ-3 векторных БД для российских проектов: Qdrant, pgvector, Chroma

Ниже — что такое RAG на пальцах, типовые архитектуры, типичные ошибки и сколько это реально стоит.

Что такое RAG (без академических терминов)

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

Технически:
1. Вы загружаете в систему свои документы (статьи, договоры, FAQ, инструкции)
2. Система разбивает их на куски (chunks) и сохраняет в векторной БД с «семантическим» индексом
3. Когда приходит вопрос, система ищет 3–7 самых релевантных кусков по смыслу
4. Эти куски передаются LLM как контекст, и она отвечает только на их основе

В итоге AI отвечает фактом из вашего документа, а не догадкой из своих весов.

Когда RAG нужен

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

RAG нужен, если:
– AI должен отвечать по вашей базе знаний (документация, FAQ, инструкции)
– Информация регулярно обновляется (раз в неделю или чаще)
– Объём данных больше 10–20 страниц (всё, что меньше, помещается прямо в промпт)
– Точность важна — нужно ссылаться на конкретный источник
– Нужно работать с приватными данными, которые модель не должна «запоминать»

RAG не нужен, если:
– Вы делаете креативный контент (RAG ограничит модель)
– Данные статичны и помещаются в промпт (до 50K токенов в современных моделях)
– Задача — обработка нового текста (расшифровка, перевод, суммари)

Архитектура RAG: 5 слоёв

Реальный RAG в продакшне — это не «векторный поиск + LLM». Это:

Слой 1: Подготовка данных (data ingestion)

  • Парсинг документов (PDF, DOCX, HTML, базы данных)
  • Очистка от мусора (футеры, водяные знаки, OCR-ошибки)
  • Извлечение метаданных (дата, автор, раздел, версия)

Слой 2: Chunking (разбиение на куски)

  • По параграфам / страницам / семантическим единицам
  • С пересечением (overlap) для сохранения контекста
  • Иерархическое чанкование для длинных документов

Слой 3: Embedding (векторизация)

  • Модель эмбеддинга (text-embedding-3-large, e5-large, BGE)
  • Сохранение в векторной БД с метаданными
  • Регулярное переиндексирование при обновлении данных

Слой 4: Retrieval (поиск)

  • Семантический поиск (косинусная близость)
  • Гибридный поиск (вектор + BM25 keyword)
  • Реранкинг топ-50 в топ-5 через более точную модель
  • Фильтрация по метаданным (категория, дата, тип)

Слой 5: Generation (ответ)

  • Промпт с инструкцией «отвечай только по контексту»
  • Передача chunk’ов + вопроса в LLM
  • Цитирование источников
  • Fallback при отсутствии релевантного контекста

Половина успеха RAG — это слои 1–2, а не слой 4, которым все хвастаются.

5 ошибок, которые убивают качество RAG

Это список реальных проблем, которые мы видели в проектах.

Ошибка 1: «Чанки по 1000 символов» без логики

Многие делают разбиение «механически» — каждые 1000 символов новый chunk. В итоге chunk обрывается на полуслове, теряет контекст.

Что правильно: разбиение по семантическим единицам (параграф, раздел), с overlap 100–200 символов. Для длинных документов — иерархия (главы → разделы → параграфы).

Ошибка 2: Нет метаданных

Загрузили 5000 страниц одной кучей. AI находит chunk «срок гарантии — 1 год», но не знает, к какому продукту это относится.

Что правильно: каждый chunk имеет метаданные: продукт, версия документа, дата, раздел, источник. Это даёт фильтрацию и улучшает precision.

Ошибка 3: Embedding-модель не под язык

Использовали text-embedding-ada-002 для русских текстов. Эта модель училась преимущественно на английском — релевантность русских ответов проседает.

Что правильно: для русского — multilingual-e5-large, BGE-multilingual или text-embedding-3-large от OpenAI (он лучше справляется с многоязычием, чем ada). Для смешанных текстов RU+EN — обязательно multilingual.

Ошибка 4: Только векторный поиск без reranking

Векторный поиск находит «похожее по смыслу», но не всегда «самое релевантное». Топ-1 chunk может быть формально близок, но не отвечать на конкретный вопрос.

Что правильно: достать топ-20 векторным поиском, потом прогнать через reranker (например, bge-reranker-large или cohere-rerank), оставить топ-3–5. Это даёт +25–40% к точности ответа.

Ошибка 5: Нет fallback на «не знаю»

Промпт «отвечай по контексту» без подкрепления — LLM начинает додумывать, особенно на пограничных кейсах. Хорошие практики промпт-логики мы разбирали в гайде по prompt engineering для бизнеса.

Что правильно: жёсткая инструкция «если контекста недостаточно, ответь “не знаю, эскалирую вопрос менеджеру”». И — главное — оценка confidence: если найденные chunks имеют низкую relevance, не отвечать вообще.

Векторные БД 2026: Qdrant, pgvector, Chroma

Топ-3 варианта для российского бизнеса:

Qdrant

  • Российский по происхождению (основатели), но компания зарегистрирована в Берлине
  • Лучшая производительность из открытых решений
  • Поддерживает фильтрацию по payload (метаданным)
  • Self-hosted и cloud
  • Когда брать: средние и крупные проекты, нужны фильтры и высокая производительность

pgvector

  • Расширение PostgreSQL
  • Использует ваш существующий Postgres
  • Простое внедрение, если уже работаете с Postgres
  • Производительность ниже Qdrant на >10M векторов
  • Когда брать: малые и средние проекты, не хочется отдельной БД

Chroma

  • Самая простая в освоении
  • Python-нативный API
  • Бесплатно self-hosted, есть cloud
  • Слабее по фильтрации, чем Qdrant
  • Когда брать: MVP, прототипы, исследовательские проекты

Также есть Pinecone (managed cloud) и Weaviate — но в российских реалиях оплата за рубежом усложняет картину. Какую LLM подключать к RAG в РФ — мы разбирали отдельно в сравнении Yandex GPT vs Claude vs GPT-4o.

Сколько стоит внедрить RAG

Реалистичная разбивка на 2026:

MVP RAG (1 источник, до 500 страниц): 80–140 тыс ₽
– Подготовка данных: 20 тыс ₽
– Чанкование и embedding: 15 тыс ₽
– Развёртывание Qdrant/pgvector: 25 тыс ₽
– Интеграция с LLM-агентом: 30 тыс ₽
– Тестирование: 20 тыс ₽

Средний RAG (3–5 источников, 5000+ страниц): 180–320 тыс ₽
– Сложный pipeline ingestion (PDF, HTML, БД)
– Метаданные, версионирование
– Гибридный поиск + reranking
– Мониторинг качества

Корпоративный RAG (10+ источников, регулярные обновления): 450–900 тыс ₽
– Continuous ingestion (новые документы автоматически)
– Multi-tenant (разные права доступа)
– Audit log (кто что спросил, что было найдено)
– Интеграция с identity-системой (LDAP, AD)

Ежемесячные расходы:
– API embedding: 2–15 тыс ₽
– Хранение и хостинг Qdrant: 3–25 тыс ₽
– API LLM (зависит от объёма): 5–80 тыс ₽
– Поддержка и обновления: 20–60 тыс ₽

Реальный кейс: техподдержка SaaS, 4000 страниц документации

SaaS-компания, 18 человек в техподдержке, ~600 тикетов в день. Документация на 4000 страниц — Helpdesk-статьи, API-документация, FAQ, changelog.

До RAG: операторы тратили в среднем 4 минуты на поиск ответа в документации перед ответом клиенту. 35% запросов эскалировались на разработчиков, потому что оператор не находил нужный раздел.

Что внедрили:
1. Ingestion pipeline на 4000 страниц с метаданными (продукт, версия, тип статьи)
2. Qdrant как векторная БД
3. Гибридный поиск (вектор + BM25) с reranking
4. AI-агент на Claude Sonnet, который сначала отвечает оператору с цитированием источника, при подтверждении отправляет клиенту

Результат через 8 недель:
– Время ответа: с 4 мин до 35 сек
– Эскалация на разработчиков: с 35% до 8%
– Точность ответов (по проверке выборки): 91%
– Стоимость внедрения: 380 тыс ₽
– API+хостинг в месяц: 28 тыс ₽
– Окупаемость: 6 недель (за счёт высвобождённого времени разработчиков)

Что не сработало сразу: попытка дать AI отвечать клиенту напрямую без оператора провалилась — нужен был «человек в петле» для финальной проверки на нестандартных кейсах.

Когда RAG провалится

Не врать клиенту — это не про инженерию, это про честность. Случаи, когда RAG не помогает или работает плохо:

  1. Документация противоречивая. Если в ваших файлах написано «срок гарантии 1 год» в одном месте и «срок гарантии 2 года» в другом — RAG найдёт оба, AI растеряется. Сначала нужно навести порядок в данных.

  2. Данные сильно устаревают. RAG ищет в том, что есть в векторной БД. Если данные обновляются ежедневно, а реиндексация — раз в неделю, AI будет отвечать устаревшим.

  3. Запросы вне домена. Клиент спрашивает «а как настроить почту в Outlook» — это нет в вашей документации. Без правильного fallback модель начнёт фантазировать.

  4. Cross-document reasoning. Когда ответ требует синтеза из 5+ документов, RAG часто промахивается — модель берёт топ-3 chunk’а, но не видит общей картины.

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

Стек, который мы используем по умолчанию

В большинстве проектов 2026 мы строим RAG на этом стеке:

  • Embedding: text-embedding-3-large (OpenAI) для большинства, multilingual-e5-large (self-hosted) если данные не должны покидать периметр
  • Vector DB: Qdrant self-hosted (для среднего и большого), pgvector (если уже есть Postgres и до 1M векторов)
  • Reranker: cohere-rerank-multilingual-v3 (API) или bge-reranker-v2-m3 (self-hosted)
  • LLM: Claude Sonnet 4.6 для качества, Yandex GPT 4 Pro для данных под 152-ФЗ
  • Оркестрация: LangChain (Python) или LlamaIndex для прототипов; чистый Python для продакшна
  • Мониторинг: Langfuse или Phoenix для отслеживания качества и retrieval

С чего начать

  1. Соберите 1 чёткий вопрос — конкретно «на какие вопросы AI должен отвечать?». Без этого внедрение RAG превращается в «AI на всё».
  2. Найдите 50–500 страниц релевантных данных. Меньше — не нужен RAG. Больше — увеличиваете риск ошибок.
  3. Соберите test set из 30–50 пар «вопрос-ответ» до старта разработки. Без этого нельзя оценить качество.
  4. Сделайте MVP за 2–3 недели на простом стеке (LangChain + Qdrant + GPT-4o-mini), оцените precision/recall.
  5. Если работает 70%+ запросов — масштабируйте. Если меньше — копайте, что не так с данными и retrieval.

FAQ

Можно ли обойтись без RAG, если у меня всего 50 страниц документации?
Да. Современные LLM держат 100–200K токенов в контексте — 50 страниц туда поместятся. RAG нужен с объёма «не помещается в один промпт».

Почему просто не дообучить модель на моих данных (fine-tuning)?
Fine-tuning меняет «стиль» модели, но плохо подходит для запоминания фактов. На фактах он галлюцинирует ровно так же, как базовая модель. RAG — это про факты, fine-tuning — это про стиль/формат.

Сколько обычно стоит запустить простой RAG?
80–140 тыс ₽ на MVP с 1 источником, 2–3 недели работы команды.

А если данные конфиденциальные?
Используйте self-hosted embedding-модель (e5, BGE) + self-hosted Qdrant + Yandex GPT или локальную LLM. Данные не покидают периметр.

Можно ли использовать RAG для русских текстов?
Да, при условии правильной модели embedding (multilingual-e5-large или text-embedding-3-large). Ada-002 хуже работает с русским.

Хотите построить RAG-агента для своих данных? Напишите — посмотрим объём, оценим, что реально достижимо, и предложим архитектуру.

AI AI-агент Qdrant RAG vector DB