RAG-системы для корпоративной базы знаний 2026: гайд по реализации
Большая компания накапливает терабайты документов: регламенты, инструкции, протоколы, контракты, переписка с клиентами, технические задания. Сотрудник тратит 1–3 часа в день на поиск нужного документа или ответа в этих текстах. RAG (Retrieval-Augmented Generation) — это архитектура, которая позволяет языковой модели отвечать на вопросы по корпоративным данным без передачи их в облако и без галлюцинаций. Ниже разбираем, как такую систему собрать в 2026 году с учётом российского контекста.
Зачем нужен RAG, а не просто LLM
Языковая модель «из коробки» (GPT-4, Llama, GigaChat) знает много общего, но не знает специфики вашей компании. Если спросить её «какой норматив на расход топлива у нашего грузовика МАЗ-6312?», она ответит общими словами или придумает цифру. Это галлюцинация — главная проблема LLM в корпоративном применении.
RAG решает это так: перед генерацией ответа система ищет в корпоративной базе релевантные фрагменты документов и подаёт их в модель как контекст. Модель отвечает «согласно регламенту RT-2024-12, норматив расхода для МАЗ-6312 в зимний период составляет 38 л/100 км» с прямой ссылкой на документ.
Архитектура RAG за 5 слоёв
Слой 1. Подготовка данных (40% работы)
Самая недооценённая часть. Корпоративные документы это:
- PDF (часто отсканированные, без текстового слоя).
- DOC, DOCX с таблицами и графиками.
- XLS с цифрами и формулами.
- HTML внутренних wiki.
- Сообщения в почте, Slack, корпоративных мессенджерах.
Каждый формат требует своего парсера. Для сканов нужен OCR (Tesseract или коммерческий ABBYY FineReader). Для таблиц — отдельный pipeline, который сохраняет структуру (LayoutParser, Camelot). Для PDF с картинками-схемами часть информации теряется без VLM (visual language model).
После парсинга текст разбивается на чанки. Размер чанка имеет значение:
- 200–400 символов — точный поиск, но потеря контекста.
- 800–1500 символов — баланс, оптимально для большинства задач.
- 3000+ символов — много контекста, но снижается точность поиска.
Современный подход — multi-chunk overlap (соседние чанки делят 20–30% текста), плюс иерархия (parent-child chunks).
Слой 2. Векторизация и индекс
Текстовые чанки превращаются в векторы через embedding-модель. Российские варианты: ai-forever/ru-en-RoSBERTa, deepvk/USER-bge-m3. Зарубежные через on-premise разворачивание: BGE-M3, E5-large.
Векторы хранятся в векторной базе. Варианты:
- Qdrant (Россия, open-source, hybrid search) — стандартный выбор.
- Vespa (open-source, очень быстрый, сложнее в развёртывании).
- PostgreSQL + pgvector — если уже есть Postgres и нужна простота.
- Weaviate, Milvus — также open-source, активно развиваются.
Дополнительно делается ключевое индексирование (BM25 через Elasticsearch / OpenSearch / Manticore Search) для гибридного поиска.
Слой 3. Retrieval (поиск)
Когда сотрудник задаёт вопрос, происходит:
- Расширение запроса: переформулировка через LLM, генерация синонимов, hyde-подобные техники.
- Векторный поиск top-K (обычно 20–50) по семантической близости.
- Ключевой поиск top-K по BM25.
- Объединение и реранкинг (CrossEncoder, например ru-en-RoSBERTa-cross или BAAI/bge-reranker).
- Top-N (обычно 5–10) лучших чанков идут в LLM.
Без реранкинга качество ответов RAG проседает на 25–40%. Это самый недооценённый слой.
Слой 4. Generation
LLM получает системный промпт «отвечай только на основе предоставленного контекста, если ответа нет — скажи "не знаю"», вопрос и top-N чанков. Генерирует ответ с обязательными цитатами и ссылками на документы.
Выбор LLM:
- GigaChat Pro — российская, on-premise возможна. Хорошее качество русского. Примерно $X/токен в облаке.
- YandexGPT 5 Pro — аналогично, on-premise.
- Qwen 2.5 72B — open-source, разворачивается на 4×A100 или 8×A6000. Топовое качество русского для open-source.
- Llama 3.3 70B — open-source, чуть слабее на русском чем Qwen, но активно дорабатывается.
Для большинства корпоративных задач достаточно 32B-параметрической модели. 70B+ нужны для сложных рассуждений и работы с длинным контекстом.
Слой 5. Контроль качества
Что отслеживается на проде:
- Доля ответов «не знаю» (норма 5–15%, выше = плохой retrieval, ниже = галлюцинирует).
- Время ответа (норма 2–8 секунд для типовых запросов).
- Удовлетворённость пользователя (через лайк/дизлайк после ответа).
- Регулярный аудит проблемных диалогов вручную, дообучение системы.
Реалистичные цифры
Размер задачи
- Малая база знаний (до 10 тыс документов, ≈100 МБ текста): 1 сервер с 64 ГБ RAM, 2× RTX A4500. Бюджет железа от 800 тыс ₽.
- Средняя (до 200 тыс документов, ≈2 ГБ): 2-3 сервера с GPU, A100 или H100. Бюджет от 4 млн ₽.
- Корпоративная (миллионы документов): кластер из 10+ узлов, отдельный векторный сервис. Бюджет от 25 млн ₽.
Сроки разработки
- MVP на тысяче документов: 6–8 недель.
- Промышленное развёртывание на 50–200 тыс документов: 4–7 месяцев.
- Полный rollout с интеграциями (Active Directory, Confluence, 1С): 8–14 месяцев.
Что съедает бюджет
- Подготовка данных и OCR: 30–40%.
- Разработка retrieval/reranking: 15–20%.
- Инфраструктура (серверы, GPU, лицензии): 25–35%.
- Интеграции с внутренними системами: 15–25%.
- Обучение пользователей и поддержка: 5–10%.
Главные ошибки
- Пытаются использовать готовый облачный сервис. Информация утечёт, юристы не подпишут.
- Не делают подготовку данных. Загружают сканы PDF без OCR, удивляются что система ничего не находит.
- Используют только векторный поиск без BM25 и реранкинга. Качество ответов 50–60%, пользователи через месяц перестают пользоваться.
- Берут одну универсальную LLM на всё. На юридические вопросы лучше работает дообученная под законодательство модель, на инженерные — другая.
- Не предусмотрели обновление. Новые регламенты пишутся каждую неделю, индекс должен обновляться автоматически или быстро по мере появления документов.
С чего начать
- Опишите 5 типовых вопросов, на которые сотрудники тратят больше всего времени поиска ответа сейчас.
- Соберите документы, в которых ответы содержатся (или должны содержаться).
- Оцените объём: сколько мегабайт текста, сколько разных форматов, как часто обновляются.
- Если объём 1+ ГБ или больше 50 разных типов документов, нужна кастомная разработка. Готовые SaaS не справятся.
- Закажите аудит. Подробный гайд: Аудит ИИ-готовности компании.