Корпоративная база знаний RAG — это не «залить весь общий диск в векторную базу». Это инженерный слой из четырёх частей: отобранные источники, корректное разбиение документов, гибридный поиск с переранжированием и применение прав доступа. По отчётам вендоров за 2026 год, от 70% до 80% корпоративных RAG-проектов так и не доходят до продакшена, и большинство сбоев рождается в слоях загрузки и поиска, а не в модели. Это руководство разбирает четыре слоя и предлагает план на 90 дней.
Почему большинство RAG-проектов умирает до продакшена
Сценарий повторяется. Команда собирает пилот за две недели, демонстрация впечатляет, затем система сталкивается с организационной реальностью и разваливается. Исследование MLOps Community 2026 года по 143 корпоративным внедрениям RAG показало, что 73% столкнулись как минимум с одним критическим сбоем в первый квартал работы в продакшене, а 41% этих сбоев так и не были отмечены стандартными наборами оценок.
Причина почти никогда не в выборе модели. Наиболее цитируемая отраслевая оценка гласит, что 80% сбоев RAG восходят к слою загрузки и разбиения. Иначе говоря: когда система выдаёт неверный ответ, в большинстве случаев модели изначально подсунули не тот фрагмент. Это различие важно, потому что оно меняет адресата бюджета — не апгрейд модели, а инженерию поиска.
Что это значит для бюджета: в 2026 году RAG — это не проблема модели, а проблема инженерии поиска. Улучшение разбиения и переранжирования даёт больший прирост точности, чем переход на более дорогую модель, при куда меньшей стоимости эксплуатации. Если вы отслеживаете юнит-экономику проекта на базе ИИ, это разница между переменными затратами, растущими вместе с использованием, и разовой инвестицией в инфраструктуру.
Четыре слоя корпоративной базы знаний
| Слой | Что делает | Типичный сбой |
|---|---|---|
| Источники и метаданные | Какие документы попадают внутрь, кто ими владеет, когда их обновляли в последний раз | Загрузить всё сразу, включая устаревшие версии и черновики |
| Разбиение | Деление документов на фрагменты, которые модель получает как контекст | Одно правило разбиения на все типы документов, ломающее таблицы и разделы |
| Поиск и ранжирование | Находить релевантные фрагменты и возвращать лучшие | Опора только на векторный поиск, без совпадения по ключевым словам |
| Права доступа | Гарантировать, что пользователь видит только то, что ему разрешено | Права проверяются в интерфейсе, а не в момент поиска |
Как правильно разбивать документы
Разбиение — решение, сильнее всего влияющее на точность, и одновременно то, которое большинство команд принимает по умолчанию. В 2026 году значимы три семейства методов:
| Метод | Кому подходит лучше всего | Рекомендуемый размер фрагмента |
|---|---|---|
| Рекурсивное разбиение фиксированного размера | Сплошной текст, регламенты, описания процессов | 256–512 токенов для фактических вопросов и ответов |
| Семантическое разбиение | Технические документы, спецификации, продуктовая документация | 512–1024 токена для аналитических задач |
| Позднее разбиение (late chunking) | Длинные документы, где контекст пересекает границы разделов | Сначала векторизуется документ целиком, затем он делится |
Практическое правило: фрагмент должен содержать полный ответ на один вопрос. Если бы вы вручили этот фрагмент сотруднику на бумаге, смог бы он ответить, ничего больше не открывая? Если нет — фрагмент слишком короткий. Если фрагмент покрывает три разные темы, он слишком длинный, и векторному поиску будет трудно на нём сфокусироваться.
Две повторяющиеся ошибки: разрыв таблиц посередине, превращающий числовые данные в шум, и потеря иерархического заголовка. Исправление второй стоит дёшево: добавить в начало каждого фрагмента строку контекста с названием документа, разделом и датой.
Гибридный поиск и переранжирование
Один только векторный поиск упускает ровно то, о чём спрашивают в организациях: артикулы, имена клиентов, коды ошибок, пункты договоров. Это точные строки, которые семантический эмбеддинг размывает. Именно поэтому гибридный поиск, сочетающий плотные эмбеддинги с поиском по ключевым словам в стиле BM25, продолжает превосходить чисто векторный на большинстве типов корпоративных документов.
Структура, ставшая распространённой отправной точкой: достать 20 кандидатов, переранжировать их моделью-реранкером и передать пять лучших в LLM. Переранжирование даёт наибольшую отдачу на единицу усилий, потому что исправляет ошибки поиска, не трогая слой разбиения.
Права доступа: слой, который откладывают все
Именно здесь умирают пилоты. В пилоте все видят всё, а потом наступает момент, когда специалист поддержки не должен видеть зарплатные документы. Если права применяются только в интерфейсе, поиск всё равно читает документ, и модель всё ещё может из него процитировать. Применять их нужно в момент поиска, как фильтр по метаданным, до того как фрагменты дойдут до модели.
На практике: каждый фрагмент несёт идентификаторы групп, которым разрешено его видеть, и запрос фильтруется по ним. Это же делает систему проверяемой, потому что вы можете показать, какие именно документы легли в основу каждого ответа.
Как измерить, что система работает
Примерно 70% команд, эксплуатирующих RAG в продакшене, не измеряют качество поиска систематически. Поэтому сбои и остаются незамеченными. Принятая рамка — «триада RAG», три оси, которые можно прогонять автоматически на фиксированном наборе вопросов:
| Ось | Какой вопрос проверяет | Что делать при низком значении |
|---|---|---|
| Релевантность контекста | Нашёл ли поиск нужные документы? | Исправить разбиение, добавить гибридный поиск |
| Обоснованность источниками | Действительно ли ответ подкреплён найденными фрагментами? | Ужесточить промпт, требовать ссылки на источник |
| Релевантность ответа | Отвечает ли ответ на заданный вопрос? | Разложить многошаговые вопросы на части |
Известное слабое место: 71% продакшен-систем RAG проваливаются на многошаговых вопросах — тех, что требуют объединить сведения из двух разных документов. Если это ваш основной сценарий, стройте набор оценок вокруг него с первого дня, а не вокруг простых фактических вопросов, которые проходят всегда.
Что отличает команды, которые доводят до конца: набор оценок, который задокументирован, версионируется и запускается автоматически каждую ночь. Без него любое изменение разбиения или промпта — ставка вслепую, и вы не можете сказать, стало лучше или сломалось.
План на 90 дней
Дни 1–30: выберите один сценарий с определённой аудиторией. Соберите только 50–200 релевантных документов, вычистите устаревшие версии и назначьте каждому документу владельца и дату последнего обновления. Параллельно напишите 40 реальных вопросов, которые команда действительно задаёт, с утверждёнными ответами. Это и есть ваш набор оценок.
Дни 31–60: соберите конвейер — разбиение, эмбеддинги, гибридный поиск, переранжирование, фильтр прав доступа. Прогоните набор оценок и зафиксируйте базовый результат по всем трём осям. Улучшайте разбиение и ранжирование, пока релевантность контекста не стабилизируется.
Дни 61–90: откройте доступ реальной пилотной группе, логируйте каждый вопрос вместе с найденными фрагментами и добавьте кнопку обратной связи. Провалившиеся вопросы пополняют набор оценок. Расширяться на новые источники стоит только после двух недель подряд стабильных метрик.
Если вы строите это впервые, прочитайте также, как измерять видимость в ИИ-движках ответов — та же дисциплина измерения работает и снаружи. А когда дойдёте до организационного развёртывания, наша практика внедрения ИИ начинается ровно с этого упражнения по картированию.
Частые вопросы
Сколько документов нужно, чтобы начать корпоративный RAG-проект?
Гораздо меньше, чем принято думать. Один сценарий хорошо покрывается 50–200 чистыми и актуальными документами. Загрузка десятков тысяч документов на старте снижает точность, потому что устаревшие версии и черновики конкурируют за те же места в выдаче поиска.
Какой размер фрагмента рекомендуется?
От 256 до 512 токенов для фактических вопросов и от 512 до 1024 токенов для аналитических задач. Практическое правило: фрагмент должен содержать полный ответ на один вопрос, не разрывая таблицы и не теряя заголовок раздела.
Почему одного векторного поиска недостаточно?
Потому что он размывает точные строки — артикулы, коды ошибок, имена клиентов. Гибридный поиск, сочетающий эмбеддинги с поиском по ключевым словам в стиле BM25, даёт лучший результат почти на всех типах корпоративных документов.
Как гарантировать, что пользователь никогда не увидит запрещённый ему документ?
Применяйте права в момент поиска, а не в интерфейсе. Каждый фрагмент несёт идентификаторы групп, которым разрешено его видеть, и запрос фильтруется по ним до того, как хоть один фрагмент дойдёт до модели.
Сколько времени нужно, чтобы выйти в продакшен?
Один сфокусированный сценарий может дойти до настоящего пилота примерно за 90 дней: месяц на картирование источников и сбор набора оценок, месяц на сборку и настройку конвейера и месяц пилота с реальной обратной связью.