Корпоративная база знаний vs RAG: когда что выбрать

Почему этот вопрос стоит острее, чем кажется

Типичная ситуация: в компании есть Confluence с тремя тысячами страниц, половина из которых не обновлялась два года. Приходит запрос сверху — «внедрить ИИ в базу знаний». Команда начинает смотреть на RAG. Через три месяца пилот не выходит в production, потому что система галлюцинирует на устаревших регламентах.

Обратная ситуация тоже распространена: компания наводит порядок в wiki, добавляет хороший поиск — и этого оказывается достаточно для 80% задач. RAG не понадобился.

Решение «wiki или RAG» — это не технический выбор. Это архитектурное решение с последствиями для бюджета, безопасности и операционной эффективности на 2–3 года вперёд. Ниже — структура для принятия этого решения за 30 минут.

Матрица выбора: четыре критерия

Пройдите по каждому критерию и отметьте, в какую колонку попадает ваша ситуация.

Как читать таблицу: если три из четырёх критериев указывают на одну колонку — решение очевидно. Если критерии расходятся — это сигнал в пользу гибридной архитектуры.

Когда wiki достаточна

Не каждая организация нуждается в RAG. Более того, для значительной части российских компаний RAG на текущем этапе — это оверинжиниринг с реальными рисками.

Сценарии, где wiki справляется:

• Онбординг новых сотрудников. Контент стабилен, структурирован, обновляется редко. Confluence с хорошим поиском и чёткой иерархией решает задачу полностью.
• HR-политики и внутренние регламенты. Если документов меньше 200 и они меняются раз в квартал — достаточно структурированной wiki с версионированием.
• FAQ службы поддержки с ограниченным и предсказуемым набором вопросов. Детерминированный поиск по ключевым словам здесь точнее вероятностного retrieval.
• Стабильные технические инструкции — настройка оборудования, процедуры ИТ-поддержки, скрипты.

Порог, после которого wiki начинает «трещать»: примерно 150–200 страниц плотного текста (~50–100k токенов). До этого порога весь корпус помещается в контекстное окно современных LLM — и вы можете просто передать его целиком, без retrieval. После этого порога начинается деградация качества ответов без явного поиска.

Важный нюанс: wiki без назначенных владельцев документов через 6 месяцев превращается в источник галлюцинаций для любого LLM-слоя. Это не проблема RAG — это проблема governance. Решайте её до, а не после внедрения ИИ.

Когда без RAG не обойтись

RAG оправдан, когда задача выходит за пределы того, что можно решить структурированием и хорошим поиском.

Сигналы, что пора смотреть на RAG:

• Корпус превысил 1000 документов с разнородной структурой — регламенты, договоры, технические спецификации, письма.
• Данные обновляются часто: нормативно-правовые акты, прайс-листы поставщиков, тикеты из helpdesk, логи инцидентов. Freshness lag (время от обновления документа до его появления в поиске) становится критичным.
• Запросы семантические, а не навигационные: «Какие у нас обязательства перед клиентом X по договору от марта?», «Где в наших процессах мы обрабатываем биометрию?» — на такие вопросы ключевой поиск не отвечает.
• Мультисистемный поиск: нужно искать одновременно в 1С, СЭД и Confluence. RAG-оркестратор объединяет источники в единый интерфейс.
• Compliance-запросы, где ошибка или пропуск документа имеют юридические последствия.

По данным AI Market Rating (2026), среди ~60 публичных российских кейсов наибольший измеримый эффект RAG даёт именно в сценарии мультисистемного поиска: юридические отделы, служба комплаенса, технические специалисты, работающие одновременно с несколькими корпоративными системами.

Гибридная архитектура как дефолт для enterprise

Для большинства российских компаний с развитой ИТ-инфраструктурой правильный ответ — не «wiki или RAG», а «wiki и RAG» с чётким разделением ответственности.

Принцип разделения:

• Wiki-слой (compile-time знания): стабильные регламенты, политики, онбординг-материалы, технические инструкции. Обновляются редко, структурированы, имеют владельцев. Хранятся в Confluence или аналоге. LLM обращается к ним через прямую передачу контекста или простой keyword-поиск.
• RAG-слой (query-time знания): динамичные данные — обновляемые НПА, тикеты, прайсы, договоры, логи. Индексируются в векторной базе, обновляются по расписанию или по событию.
• Оркестратор: маршрутизирует запрос в нужный слой или объединяет результаты из обоих. Реализуется на LangChain или Haystack.

Пример стека для закрытого контура (РФ):

• LLM: YandexGPT Pro / GigaChat Pro / DeepSeek R2 (self-hosted)
• Embedding: e5-multilingual-large или ruBERT-based модель (CPU-сервер)
• Vector DB: Qdrant (on-premise, open-source)
• Оркестратор: LangChain / Haystack
• Источники: Confluence API + 1С коннектор + СЭД (DIRECTUM, DocsVision)

Такая архитектура позволяет не переписывать wiki (что дорого и болезненно), а добавить интеллектуальный слой поверх существующей инфраструктуры.

152-ФЗ как архитектурный ограничитель

Регуляторика в РФ — не опциональный раздел. Она определяет архитектуру до того, как вы выбираете технологию.

Штрафы: передача персональных данных в публичные LLM API (OpenAI, Anthropic) без договора поручения — прямое нарушение 152-ФЗ. С 2024 года штрафы достигают 3 млн руб. за первичное нарушение и выше за повторные.

Практический вывод: если ваша база знаний содержит хотя бы один документ с ПД сотрудников или клиентов — on-premise или российское облако не выбор по вкусу, а юридическое требование. Проектируйте архитектуру с этим ограничением с первого дня.

Чеклист готовности данных перед внедрением RAG

40–60% RAG-внедрений не доходят до production. Главная причина — не технология, а качество исходных данных. Пройдите этот чеклист до начала технической работы.

• Дубли устранены. Одна тема — один актуальный документ. Дубли масштабируют противоречия в ответах.
• Устаревшие документы помечены или удалены. RAG не знает, что документ 2019 года уже неактуален — он просто его проиндексирует.
• Права доступа задокументированы. Каждый документ имеет атрибут «кто может видеть». Retrieval должен уважать эти права — иначе пользователь получит чужие данные через ответ системы.
• Форматы стандартизированы. PDF-сканы требуют OCR-препроцессинга. Таблицы в Excel требуют отдельной обработки. Смешанные форматы без препроцессинга — источник «слепых пятен» в индексе.
• Язык и терминология консистентны. Если один документ называет процесс «согласованием», а другой — «апрувом», retrieval будет пропускать релевантные результаты.
• Владельцы документов назначены. Без ответственного за актуальность база устареет через 6 месяцев.
• Структура документов предсказуема. Chunking работает лучше, если документы имеют заголовки, разделы, логическую структуру — а не сплошной текст.
• Объём оценён реалистично. Посчитайте реальное количество актуальных документов, а не общее число страниц в Confluence (включая черновики и архив).
• Процесс обновления индекса определён. Кто и когда триггерит переиндексацию при изменении документа? Freshness lag > 24 часов критичен для регуляторных документов.
• Тестовый датасет подготовлен. 50–100 реальных вопросов с эталонными ответами — без этого невозможно объективно оценить качество системы.

Антипаттерны, которые стоят дорого

RAG на грязных данных. Дубли, устаревшие версии и противоречивые регламенты не исчезают при индексировании — они масштабируются. Система начинает уверенно отвечать неправильно.

Wiki без владельцев. Через полгода после запуска wiki без назначенных ответственных превращается в архив. Любой LLM-слой поверх неё будет галлюцинировать на устаревшем контенте.

RAG для 50 документов. Если весь корпус помещается в контекстное окно LLM — retrieval не нужен. Вы платите за сложность без выигрыша в качестве.

Fine-tuning вместо RAG. Fine-tuning «запекает» знания в веса модели. При каждом изменении регламента нужно переобучать модель. RAG обновляет только индекс — это на порядок дешевле и быстрее.

Вектор-дамп без governance. Проиндексировать всё подряд — не архитектура. Без контроля прав доступа на уровне retrieval система становится вектором утечки данных.

Оценка только на демо-датасете. Качество на синтетических английских примерах не предсказывает качество на реальных русскоязычных PDF-сканах с корпоративной терминологией.

Игнорирование прав доступа в retrieval. Если пользователь не имеет доступа к документу в Confluence — он не должен получать его содержимое через ответ RAG-системы. Это не опциональная фича, а требование безопасности.

Метрики: как понять, что система работает

Запуск в production — не финал. Вот минимальный набор метрик для оценки системы в работе:

Если Precision@5 < 0.6 — проблема в данных или chunking, не в выборе LLM. Не меняйте модель, пока не починили данные.

Как принять решение за 30 минут

1. Посчитайте реальный объём актуальных документов (не общее число страниц, а документы без черновиков и архива). Если < 200 — начните с порядка в wiki.
2. Определите частоту обновлений для ключевых категорий контента. Если > 20% документов меняется чаще раза в месяц — wiki без RAG-слоя будет отставать.
3. Опишите три самых частых запроса к базе знаний. Если они семантические («найди все места, где...», «сравни условия...») — wiki не справится.
4. Проверьте наличие ПД в корпусе. Если есть — on-premise или российское облако обязательны. Заложите это в бюджет сразу.
5. Пройдите чеклист готовности данных. Если больше трёх пунктов не выполнены — начните с аудита данных, а не с выбора технологии.

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

Связанные материалы в блоге brezatech: статьи о governance корпоративных данных, выборе BI-инструментов и интеграции LLM в операционные процессы.