Корпоративная wiki закрывает большинство задач, если контент структурирован и обновляется редко. RAG нужен там, где корпус большой, неструктурированный и запросы нечёткие. Гибрид — лучший выбор при 5 000+ документах. Главный антипаттерн: внедрять RAG, потому что «все внедряют», не проверив, решает ли это реальную боль. ```yaml --- slug: baza-zaniy-vs-rag type: playbook format: flagship title: "Корпоративная база знаний vs RAG: когда что выбрать" summary: "Матрица выбора между wiki/Confluence и RAG-системой: критерии объёма, частоты обновлений и точности. Антипаттерн — RAG ради RAG." seoTitle: "База знаний vs RAG: матрица выбора для B2B" datePublished: 2026-07-10 tags: - база знаний - RAG - LLM - документооборот - BI - управление знаниями - корпоративный поиск relatedService: /uslugi relatedServiceLabel: Услуги brezatech relatedCase: relatedCaseLabel: ogImage: /assets/blog/baza-znaniy-vs-rag-og.svg imagePrompt: "Офисный дашборд с двумя панелями: слева — структурированная wiki с иерархией документов и папок, справа — граф векторного поиска с подсвеченными фрагментами текста. Нейтральный корпоративный стиль, синяя гамма, без абстрактного AI-свечения." keyFacts: - "По данным Gartner (2024), 60% корпоративных знаний хранятся в неструктурированных документах — именно там RAG даёт наибольший прирост точности поиска." - "Confluence и Notion покрывают до 80% задач, если контент обновляется реже раза в неделю и структура документов стабильна." - "RAG снижает время поиска нужного регламента с 8–12 минут (ручной поиск) до 30–60 секунд — но только при качественной индексации источников." - "Главная причина провала RAG-проектов в РФ — запуск без аудита источников: мусор на входе даёт галлюцинации на выходе." - "Гибридная схема (wiki как источник истины + RAG как интерфейс поиска) показывает лучший ROI при корпусе от 5 000 документов." faq: - q: "Чем RAG отличается от корпоративного поиска в Confluence?" a: "Confluence ищет по ключевым словам и метаданным — вы получаете список страниц. RAG извлекает релевантные фрагменты из множества источников и формирует связный ответ с указанием источника. Разница ощутима при нечётких запросах: «как мы обычно оформляем акты с нерезидентами» найдёт RAG, а не полнотекстовый поиск." - q: "Когда RAG точно не нужен?" a: "Если у вас меньше 500 документов, контент меняется редко, а сотрудники и так знают, где что лежит — RAG избыточен. Достаточно хорошо структурированной wiki с тегами и регулярным ревью." - q: "Как часто нужно переиндексировать корпус для RAG?" a: "Зависит от частоты изменений. Для регламентов и политик — раз в неделю или по триггеру (коммит в репозиторий, новая версия документа). Для новостных или операционных данных — стриминговая индексация или ежедневный батч." - q: "Можно ли использовать RAG поверх Confluence?" a: "Да, это один из самых распространённых гибридных сценариев. Confluence остаётся источником истины и редактором, RAG-слой строится поверх его API или экспорта. Важно настроить права доступа: RAG не должен отдавать фрагменты, к которым у пользователя нет доступа." - q: "Какие LLM подходят для RAG в российских компаниях с учётом регуляторики?" a: "Для чувствительных данных — self-hosted модели (Mistral, LLaMA, GigaChat on-premise). Для менее критичных задач — облачные API с обработкой данных в российской юрисдикции. Ключевой вопрос: попадают ли документы под 152-ФЗ или отраслевые требования ЦБ/Минздрава." sources: - "Gartner, «Magic Quadrant for Workplace Content and Collaboration Platforms», 2024" - "Lewis et al., «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», NeurIPS 2020" - "Forrester, «The State of Enterprise Search», Q3 2024" mentions: - Confluence - Notion - Gartner - LLaMA - Mistral - GigaChat - 152-ФЗ aboutBrezatech: "brezatech — интегратор ИИ в данные и процессы: разработка LLM-решений, BI и автоматизация документооборота для B2B-компаний в РФ." --- ``` --- Почему вопрос стал актуальным именно сейчас Два года назад типичный запрос звучал так: «Нам нужна база знаний». Сегодня тот же запрос звучит иначе: «Нам нужен корпоративный ChatGPT, который знает наши регламенты». За этим сдвигом стоит реальная проблема — сотрудники тратят от 8 до 12 минут на поиск нужного документа, а правильный ответ всё равно не гарантирован. Но «корпоративный ChatGPT» — это не одно решение. Это спектр архитектур с разными компромиссами. И прежде чем выбирать технологию, стоит честно ответить на три вопроса: сколько у вас документов, как часто они меняются и насколько критична точность ответа. --- Что такое корпоративная база знаний в классическом смысле Под «базой знаний» обычно понимают структурированное хранилище: Confluence, Notion, GitBook, самописные wiki. Ключевые характеристики: • Контент создаётся и редактируется людьми — есть владелец страницы, история изменений, процесс согласования. • Навигация иерархическая — пространства, разделы, страницы, теги. • Поиск полнотекстовый — по ключевым словам и метаданным. • Права доступа на уровне страниц — стандартная корпоративная модель. Это зрелая, предсказуемая технология. Confluence используют сотни тысяч компаний именно потому, что она решает задачу хранения и совместного редактирования знаний без лишней сложности. Где wiki работает отлично: • Регламенты и политики с редкими обновлениями (раз в квартал и реже) • Онбординг-материалы, инструкции, FAQ • Технические спецификации с чёткой структурой • Корпусы до 1 000–2 000 страниц, где сотрудники знают навигацию --- Что такое RAG и в чём его принципиальное отличие RAG (Retrieval-Augmented Generation) — архитектура, при которой языковая модель перед генерацией ответа извлекает релевантные фрагменты из корпуса документов. Упрощённо: пользователь задаёт вопрос → система находит топ-N релевантных чанков → LLM формирует ответ на основе этих фрагментов с указанием источника. Принципиальные отличия от wiki-поиска: • Семантический поиск — система понимает смысл запроса, а не только ключевые слова. «Как оформить возврат от нерезидента» найдёт нужный регламент, даже если в нём нет слова «нерезидент». • Синтез из нескольких источников — ответ может агрегировать информацию из трёх разных документов. • Нечёткие запросы — работает с разговорными формулировками, которые сотрудники реально используют. • Масштаб — качество поиска не деградирует при росте корпуса с 1 000 до 100 000 документов. Где RAG даёт реальный прирост: • Большие неструктурированные корпусы (договоры, переписка, протоколы) • Частые обновления с разными версиями документов • Запросы, требующие синтеза из нескольких источников • Поддержка первой линии, где скорость ответа критична --- Матрица выбора Три ключевых критерия: объём корпуса, частота обновлений, требования к точности. Критерий | Wiki / Confluence | RAG | Гибрид Объём документов | до 2 000 страниц | от 5 000 документов | от 2 000, смешанный контент Частота обновлений | реже раза в неделю | часто или непредсказуемо | по-разному для разных разделов Тип запросов | навигационные, точные | семантические, нечёткие | оба типа Требования к точности | высокие (регуляторика) | средние, нужны ссылки на источник | высокие + масштаб Права доступа | стандартные, на уровне страниц | требует кастомной реализации | сложная, но решаемая Стоимость внедрения | низкая | средняя–высокая | высокая Стоимость поддержки | низкая (редакторы) | средняя (переиндексация, мониторинг) | средняя Регуляторные риски (152-ФЗ) | минимальные | требует аудита | требует аудита Практическое правило: если ваши сотрудники жалуются на то, что «не могут найти нужный документ», сначала проверьте, не является ли проблема плохой структурой wiki, а не отсутствием RAG. --- Три сценария с конкретными рекомендациями Сценарий 1: Производственная компания, 200 сотрудников, 800 регламентов {#scenario-1} Симптомы: Регламенты обновляются раз в квартал, структура стабильна, но новые сотрудники тратят много времени на поиск нужного документа. Рекомендация: wiki с улучшенной структурой. RAG здесь избыточен. Достаточно провести аудит Confluence: выстроить иерархию пространств, добавить теги, назначить владельцев страниц, настроить шаблоны. Это решит 80% проблемы за 20% стоимости RAG-проекта. Сценарий 2: Юридическая фирма, 50 юристов, 50 000 договоров и судебных актов {#scenario-2} Симптомы: Юристы тратят часы на поиск прецедентов в архиве. Документы разнородные, плохо структурированные, часто обновляются. Рекомендация: RAG как основной интерфейс поиска. Здесь wiki не поможет — невозможно вручную структурировать 50 000 документов. RAG с семантическим поиском и фильтрацией по метаданным (дата, тип документа, контрагент) даёт кратный прирост скорости работы. Критично: настроить разграничение доступа на уровне чанков, не только документов. Сценарий 3: Ритейлер, 1 500 сотрудников, смешанный контент {#scenario-3} Симптомы: Есть и стабильные HR-политики, и постоянно меняющиеся операционные инструкции, и архив переписки с поставщиками. Рекомендация: гибридная архитектура. Confluence остаётся источником истины для структурированного контента. RAG-слой строится поверх него плюс подключает неструктурированные источники (почта, CRM-заметки, PDF-договоры). Единый интерфейс поиска для сотрудника, разные бэкенды под капотом. --- Антипаттерн: RAG ради RAG Это главная ошибка 2024–2025 годов. Компания видит демо «умного поиска по документам», впечатляется, запускает проект — и через три месяца получает систему, которой никто не пользуется. Почему так происходит: • Мусор на входе. RAG индексирует всё подряд: устаревшие версии регламентов, черновики, дублирующиеся документы. Модель честно отвечает на основе этого мусора — и галлюцинирует не потому что плохая, а потому что источники плохие. • Нет владельца корпуса. Wiki работает, потому что есть редакторы. RAG требует того же — кто-то должен следить за качеством источников, актуальностью индекса, удалением устаревшего контента. • Переоценка нечёткости. Не все запросы выигрывают от семантического поиска. Если сотрудник ищет конкретный приказ по номеру — полнотекстовый поиск быстрее и точнее. • Игнорирование прав доступа. RAG по умолчанию не знает, кому что можно читать. Если не реализовать фильтрацию на уровне ретривера, система будет отдавать конфиденциальные фрагменты неавторизованным пользователям. Диагностический вопрос перед запуском RAG: «Если бы у нас был идеальный полнотекстовый поиск с фильтрами — это решило бы 80% проблемы?» Если да — начните с поиска, не с RAG. --- Регуляторный контекст для РФ Для российских компаний есть дополнительный слой сложности. Если корпус содержит персональные данные (152-ФЗ), медицинскую информацию, финансовые данные под требованиями ЦБ — выбор LLM-провайдера и инфраструктуры становится регуляторным вопросом, а не только техническим. Практические ограничения: • Облачные RAG-сервисы (Azure OpenAI, YandexGPT API) требуют проверки: где физически обрабатываются данные, есть ли DPA. • Self-hosted модели (Mistral, LLaMA, GigaChat on-premise) снимают вопрос трансграничной передачи, но требуют инфраструктуры и экспертизы. • Для ряда отраслей (госсектор, банки, медицина) self-hosted — не опция, а требование. Wiki-решения в этом смысле проще: Confluence Data Center разворачивается on-premise, вопросов к регулятору нет. --- Чеклист перед принятием решения Перед тем как выбирать между wiki, RAG или гибридом, ответьте на эти вопросы: • Объём: сколько документов в корпусе сейчас и через два года? • Структура: документы структурированы или это разнородный архив? • Обновления: как часто меняется контент? Есть ли процесс управления версиями? • Запросы: пользователи ищут конкретные документы или задают вопросы в свободной форме? • Точность: что хуже — пропустить нужный документ или получить неточный ответ? • Права доступа: есть ли чувствительный контент с ограниченным доступом? • Регуляторика: попадает ли контент под 152-ФЗ или отраслевые требования? • Команда: есть ли ресурс на поддержку индекса и качества источников? Если на большинство вопросов ответ указывает на простоту и стабильность — начните с wiki. Если на сложность и масштаб — проектируйте RAG сразу с учётом качества источников и прав доступа. --- Итог Выбор между корпоративной базой знаний и RAG — это не вопрос «старое vs новое». Это вопрос соответствия инструмента задаче. Wiki решает задачу хранения и совместного редактирования структурированных знаний — и решает её хорошо. RAG решает задачу поиска в большом неструктурированном корпусе с нечёткими запросами — и тоже решает её хорошо, но при условии качественных источников. Гибридная архитектура — не компромисс, а осознанный выбор для компаний с разнородным контентом и высокими требованиями к масштабу. Но она требует больше инвестиций в поддержку. Главный вывод: прежде чем проектировать RAG, проведите аудит существующих источников знаний. Часто проблема не в отсутствии умного поиска, а в том, что искать нечего — документы устарели, дублируются или просто плохо написаны. --- *Читайте также в блоге brezatech:* • Как провести аудит корпоративных данных перед внедрением BI • LLM в продакшене: что идёт не так и как это предотвратить • Документооборот и автоматизация: где заканчивается ECM и начинается ИИ