Все статьи
обновлено 10 мин

RAG для корпоративной базы знаний: пошагово от документов к точным ответам

Как построить RAG для корпоративной базы знаний: от подготовки документов до production-системы с reranking. Этапы, выбор технологий, типичные проблемы и как добиться 90%+ точности.

ragкорпоративная-база-знанийembeddingrerankerself-hosted-aiagmind

RAG для корпоративной базы знаний — это архитектура, при которой языковая модель не угадывает ответ, а находит точные куски из ваших документов и формулирует ответ строго по ним. В отличие от fine-tuning, RAG не переобучает модель: новые документы добавляются без переобучения, и это делает подход стандартом для внутренних баз знаний в 2026 году.

Что такое RAG в контексте корпоративной базы

Не путать:

ПодходИсточник ответаТочность на корп-задачах
Plain LLMБазовые знания моделиНизкая (LLM не знает ваших документов)
Fine-tuneДообученная модельВысокая, но дорого и негибко
RAGПоиск + генерация по найденномуВысокая, гибкая, обновляемая
RAG + tools (агент)Поиск + действияСамая высокая, сложная архитектура

RAG — золотой стандарт для корпоративных Q&A: обновили документ — ответы обновились, без переобучения.

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

Минимальная RAG-система для корпоративной базы:

[Документы: PDF, DOCX, MD, HTML, CSV]
        ↓ (1. Парсинг)
[Markdown / структурированный текст]
        ↓ (2. Чанкинг)
[Чанки 200-500 токенов каждый]
        ↓ (3. Эмбеддинг)
[Векторы в Qdrant / Weaviate / pgvector]
        ↓ (4. Поиск + reranking)
[Top-3 релевантных чанка]
        ↓ (5. Генерация)
[Ответ от LLM с цитатами]

Каждый слой влияет на финальную точность. Слабое звено в любом — плохие ответы.

Слой 1: парсинг документов

Где обычно теряется качество: PDF без текстового слоя, сканы, таблицы, картинки с текстом.

Стратегия по типам:

Чистые тексты (DOCX, MD, TXT):

  • Просто загружаем
  • Сохраняем структуру (заголовки → метаданные чанков)

Текстовые PDF:

  • Docling или Unstructured — конвертация в markdown с сохранением структуры
  • PyMuPDF / pdfplumber — для простых случаев

Сканы PDF:

  • RAGFlow — сильный встроенный OCR и парсинг таблиц
  • Cloud OCR (Yandex Vision, ABBYY) — если нужно очень качественно
  • Tesseract — open-source baseline, среднее качество

Картинки с текстом / сложные диаграммы:

Excel / CSV:

  • Не индексируйте как обычный текст — смысла мало
  • Structured retrieval: SQL-агент / pandas-tool, агент пишет запрос к таблице

Базы данных:

  • Выгружаете релевантные представления в JSON / Markdown
  • Или подключаете как tool (агент пишет SQL)

Что часто упускают:

  • Метаданные документа (автор, дата, отдел) — критично для фильтрации
  • Версионность (старая редакция регламента vs новая)
  • Acl-теги (кто имеет доступ к документу)

Слой 2: чанкинг

Документ нужно разрезать на куски (чанки) для индексации. Параметры:

Размер чанка:

  • 200–500 токенов — стандарт
  • Слишком маленький (50) — теряется контекст
  • Слишком большой (2000) — слабая релевантность поиска

Перекрытие (overlap):

  • 10–20% от размера чанка
  • Защищает от ситуации «ответ на границе двух чанков»

Стратегия резки:

СтратегияКогда
По токенам / символамПростой baseline, но рвёт смысл
По параграфамЕстественные границы, хорошо для статей
По заголовкам (semantic)Лучше всего — каждый чанк = логический раздел
Sliding windowКогда документ — длинный непрерывный текст

Best practice 2026: semantic chunking по структуре документа (заголовки H1/H2 определяют границы) + token-based fallback для длинных секций.

Слой 3: эмбеддинги

Каждый чанк → вектор (embedding) → положили в vector DB.

Лучшие embedding-модели для русского в 2026:

  • BGE-M3 (BAAI) — multilingual, хорошо работает на русском
  • multilingual-e5-large — Microsoft, тоже сильная multilingual
  • USER-bge-m3 — fine-tune BGE-M3 на русском
  • mxbai-embed-large-v1 — для английского, но и русский тянет

См. подробное сравнение: embedding-модели для русского.

Размерность: обычно 768–1024. Не критично, главное чтобы embedding и retrieval использовали ту же модель.

Где гоняем embedding:

  • Self-hosted на CPU — OK для индексации (один раз)
  • Self-hosted на GPU — для realtime (когда юзер задал вопрос)
  • vLLM / Text Embeddings Inference (TEI) — production-сервис

Слой 4: vector DB и retrieval

Где хранить векторы:

DBКогда брать
QdrantДефолт. Open-source, быстрый, сильная фильтрация по метаданным
WeaviateЕсли нужны hybrid-search (vector + keyword) из коробки
pgvectorЕсли уже есть Postgres и не хотите ещё одну DB. Медленнее на > 1M векторов
MilvusОчень большие масштабы (10M+ векторов)

См. сравнение vector DB.

Retrieval-стратегия:

  1. Простой top-K по cosine similarity — baseline, обычно 60–75% точности
  2. + метадата фильтрация (отдел, дата, acl) — отсекает мусор
  3. + hybrid search (vector + BM25 keyword) — улучшает на 5–10%
  4. + reranker (см. слой 5) — улучшает на 10–20%

Запрос:

# Pseudo-code
query_embedding = embed(user_question)
candidates = qdrant.search(
    vector=query_embedding,
    limit=20,  # top-20, не top-3 — для reranker
    filter={"acl": {"$in": user_acl_tags}, "doc_type": "regulation"},
)

Первая выборка top-20, потом reranker сортирует и выбирает top-3.

Слой 5: reranking

Зачем reranker: embedding-модели быстрые но не всегда точно ранжируют. Reranker — медленнее но точнее, применяется на top-20–50 чанков.

Лучшие reranker для русского в 2026:

  • bge-reranker-v2-m3 — open-source, multilingual, основной выбор
  • Cohere Rerank — облачный, очень сильный, но не self-hosted
  • mxbai-rerank — open-source альтернатива

Подробно: рерайнкеры для русского RAG.

Pipeline с reranker:

candidates = qdrant.search(query_emb, limit=20)
reranked = bge_reranker.rerank(query, candidates)
top3 = reranked[:3]  # для подачи в LLM

Без reranker точность на корпоративных вопросах обычно 70–80%. С reranker — 85–95%.

Слой 5 (генерация): что говорим LLM

После retrieval у нас есть top-3 чанка. Подаём в LLM:

Ты помощник по корпоративной базе знаний компании X.
Используй ТОЛЬКО предоставленные ниже документы для ответа.
Если в документах нет ответа — скажи "В базе нет информации".
Цитируй документы по их названию.

ДОКУМЕНТЫ:
[1] Регламент отгрузки v3.2:
{chunk_1_text}

[2] Договор поставки шаблон:
{chunk_2_text}

[3] FAQ для менеджеров:
{chunk_3_text}

ВОПРОС: {user_question}

LLM генерирует ответ опираясь на чанки + указывает источники.

Что критично в промпте:

  • «Только из документов» — иначе LLM додумывает
  • «Если нет ответа — скажи нет» — защита от галлюцинаций
  • «Цитируй» — пользователь должен видеть откуда взялся ответ

Метрики качества

Без них вы не знаете работает ли RAG.

Recall@K — есть ли правильный документ в top-K результатов retrieval?

  • Цель: Recall@10 ≥ 90%

Precision@K — какая доля top-K реально релевантна?

  • Цель: Precision@3 ≥ 70% после reranker

Answer accuracy — правильность финального ответа на тестовом наборе вопрос-эталонный ответ.

  • Цель: 85–95% на корпоративных задачах
  • Тестовый набор: 100–300 пар вопрос-ответ

Latency:

  • Embedding запроса: < 100 ms
  • Vector search: < 200 ms
  • Reranking: < 500 ms
  • LLM generation: 1–10 sec
  • Итого: 2–11 sec end-to-end (приемлемо для корп-задач)

Подводные камни

1. Плохие данные = плохие ответы. RAG не магия. Если документы в хаосе, кривые сканы, противоречивые редакции — никакой RAG не поможет. См. топ-7 ошибок.

2. Отсутствие версионности. Регламент 2022 года и 2024-й оба в индексе → юзер получает старый. Нужна метадата valid_from/valid_until и фильтрация по дате.

3. ACL не на retrieval, а в промпте. Опасно. Промпт-инъекцией обходится. Фильтрация по правам должна быть на уровне vector DB query, не доверена LLM. См. также: архитектура AI-помощника.

4. Embedding-модель vs LLM-модель. Это разные модели. Embedding — BGE-M3, LLM — Qwen 32B. Не путать.

5. Не обновляющийся индекс. Документы меняются — индекс должен переиндексироваться. Cron на каждые сутки минимум.

6. Reranker «всё спасёт». Reranker улучшает, но не переписывает плохой retrieval. Если top-20 содержит мусор, reranker отсортирует мусор по релевантности.

Сколько стоит RAG для корпоративной базы знаний?

Минимальный (1000–10000 документов, до 50 пользователей):

  • Железо: 1× RTX 4090 (24 GB) или DGX Spark — 350–600 тыс. ₽
  • Работа интегратора: 800 тыс. – 1.5 млн ₽
  • TCO: 50 тыс. ₽ / месяц

Production (10k–100k документов, 100+ пользователей):

  • Железо: DGX Spark / Mac Studio M3 Ultra — 600 тыс. – 1.4 млн ₽
  • Работа: 1.5–3 млн ₽
  • TCO: 100–200 тыс. ₽ / месяц

Enterprise (100k+ документов, 500+ пользователей, multi-tenant):

  • Железо: 1–2× H100 + Qdrant cluster — 5–10 млн ₽
  • Работа: 4–8 млн ₽
  • TCO: 300–600 тыс. ₽ / месяц

См. сколько стоит AI-сервер, TCO своего ChatGPT.

Что у нас на проекте

В AGmind мы разворачиваем RAG для корпоративной базы знаний как часть стандартного turnkey: парсинг через RAGFlow + чанкинг по структуре + BGE-M3 эмбеддинги + Qdrant + bge-reranker-v2-m3 + Qwen 3 / Llama 3.3 / DeepSeek для генерации. Точность на типовых корп-задачах 85–95%, цикл от первого документа до production — 4–6 недель.

Если у вас 1000+ документов и сотрудники тратят часы на поиск ответов — 30-минутный аудит, оценим scope.

RAG — это один из ключевых компонентов более широкой системы. Если хотите понять что такое корпоративный ИИ-помощник целиком — как RAG, интеграции и модель складываются в рабочий продукт — читайте обзорный гид.

Связанные тексты: RAG простыми словами, архитектура AI-помощника на базе знаний, embedding для русского, рерайнкеры, vector DB.