Как подготовить базу знаний для RAG: документы, chunking и доступы

RAG не становится полезным после загрузки папки с PDF в векторную базу. Он начинает отвечать точно только тогда, когда в индексе есть актуальные документы, понятные фрагменты, метаданные и правила доступа. Если этих четырёх частей нет, ассистент либо не находит ответ, либо уверенно цитирует старую инструкцию, либо показывает пользователю данные, которых он не должен видеть.

Ниже - практический порядок подготовки базы знаний для RAG. Он подходит для внутреннего ассистента, поддержки, отдела продаж, CRM, Wiki и портала с регламентами. Если нужен не только индекс, а готовый рабочий контур с интерфейсом, интеграциями и эксплуатацией, это входит в услугу creating an AI consultant with RAG.

Что должно быть готово до загрузки документов

Не начинайте с выбора векторной базы или LLM. Сначала зафиксируйте четыре вещи:

1. Сценарии вопросов. Кто будет спрашивать, какие решения принимает по ответу и что будет считаться ошибкой.
2. Границы базы. Какие источники разрешены для индексации, а какие нельзя включать вообще.
3. Владелец каждого источника. Конкретный человек или команда, отвечающие за актуальность документа.
4. Правила ответа. Когда ассистент должен сослаться на источник, попросить уточнение или честно ответить «в базе нет данных».

Это защищает проект от типичной ловушки: команда загружает «всё, что нашла», а затем пытается лечить низкое качество более дорогой моделью. Модель не исправит противоречивые регламенты, сканы без текста и документы без владельца.

Шаг 1. Соберите реестр источников, а не архив файлов

Начните с таблицы или каталога источников. В ней достаточно восьми полей:

Поле	Пример	Зачем нужно
Источник	Wiki отдела продаж	Понимать, откуда пришёл фрагмент
Владелец	Руководитель продаж	Согласовывать обновления и спорные ответы
Тип данных	Регламент, FAQ, договор, тикет	Выбрать правила парсинга и поиска
Пользователи	Продажи, поддержка, руководители	Настроить доступ до поиска
Частота обновления	Раз в неделю	Запланировать переиндексацию
Статус	Актуален, на ревизии, архив	Не смешивать старые и действующие знания
Риск	Обычный, конфиденциальный, ПДн	Ограничить индексацию и выдачу
Ссылка на оригинал	URL документа	Показывать пользователю проверяемый источник

Сначала берите небольшой, но качественный набор: например, FAQ поддержки, действующие регламенты и карточки продуктов. Пилот на 50 хороших документов полезнее, чем индекс из 20 000 неразобранных файлов.

Какие источники обычно дают лучший старт

• инструкции, в которых есть одна понятная процедура;
• FAQ с подтверждёнными ответами;
• статьи базы знаний и Wiki с владельцем;
• шаблоны писем, скрипты и правила обработки заявок;
• описания продуктов, тарифов и актуальных условий;
• закрытые тикеты, но только после очистки персональных данных и выделения типовых решений.

С осторожностью относитесь к перепискам, черновикам, старым презентациям и экспортам CRM. В них полезный контекст часто смешан с персональными данными, временными договорённостями и уже отменёнными правилами.

Шаг 2. Очистите и нормализуйте документы

Для поиска важен текст, структура и актуальность, а не исходный формат файла. Перед индексацией приведите документы к предсказуемому виду: Markdown, HTML с заголовками или структурированный JSON.

Проверьте каждый источник по короткому чек-листу:

• у сканов PDF есть качественный OCR, а не только картинка страниц;
• в документе читаются заголовки, списки и таблицы;
• удалены колонтитулы, номера страниц, повторяющиеся меню и служебные подписи;
• дубли объединены или помечены как версии одного документа;
• отменённые документы выведены из индекса;
• сокращения и внутренние термины расшифрованы хотя бы один раз;
• ссылка на первоисточник остаётся рядом с текстом.

Особенно внимательно проверьте таблицы. Таблица с тарифами, SLA или параметрами товара не должна превращаться в последовательность обрывков вида «30 дней | 15% | 12 000». Лучше сохранять название таблицы, заголовки столбцов и строку как единый смысловой блок.

Шаг 3. Разделите документ на смысловые фрагменты

Фрагмент, или chunk, - единица, которую поиск передаёт модели. Плохое разбиение приводит к двум проблемам: нужная мысль оказывается разрезанной пополам либо один вектор начинает описывать пять несвязанных тем.

Начинайте с границ документа, а не с количества символов:

1. Сначала разделите по H1/H2, карточкам FAQ, разделам регламента и строкам таблиц.
2. Внутри большого раздела сохраняйте абзацы и предложения, не режьте фразы посередине.
3. Добавляйте к каждому фрагменту название документа и путь заголовков. Тогда отрывок из середины файла не потеряет контекст.
4. Применяйте небольшой overlap только там, где соседние части действительно продолжают одну мысль.

Для обычных текстовых регламентов разумная стартовая гипотеза - около 512 токенов и 128 токенов перекрытия. Это не универсальная норма: Microsoft рекомендует этот стартовый вариант для векторного поиска, но оптимальный размер зависит от типа документа и реальных вопросов пользователей. Проверяйте несколько настроек на своей контрольной выборке, а не переносите параметры вслепую.

Когда нужны особые правила chunking

Тип контента	Как делить
FAQ	Один вопрос с полным ответом в одном фрагменте
Регламент	Раздел или шаг процедуры, включая условия и исключения
Таблица	Заголовки и одна логическая строка или группа строк вместе
Договор	Статья или пункт с номером, названием и связанным определением
База тикетов	Проблема, причина, решение и версия продукта вместе
Catalog	Одна карточка товара или услуги с характеристиками и ограничениями

Не добавляйте одинаковое введение ко всем кускам ради «лучшего контекста»: это создаёт дубли и ухудшает поиск. Лучше хранить общую информацию как метаданные или отдельный родительский документ.

Шаг 4. Добавьте метаданные, которые будут участвовать в поиске

Вектор похожести отвечает на вопрос «о чём этот фрагмент». Метаданные отвечают на вопросы «какая версия действует», «из какого отдела документ», «можно ли его показывать этому человеку» и «где открыть оригинал».

Минимальная карточка фрагмента может выглядеть так:

{
  "chunk_id": "support-refunds-v3-04",
  "document_id": "support-refunds-v3",
  "title": "Возвраты: правила и сроки",
  "section_path": "Поддержка > Возвраты > Деньги на карту",
  "source_url": "https://wiki.company.local/support/refunds",
  "updated_at": "2026-08-01",
  "valid_from": "2026-08-01",
  "owner": "head-of-support",
  "access_groups": ["support", "finance"],
  "confidentiality": "internal",
  "language": "ru",
  "content_type": "procedure",
  "version": 3
}

Обязательные поля для большинства корпоративных проектов:

• document_id and chunk_id, чтобы обновлять и удалять ровно нужные данные;
• title, section_path and source_url, чтобы строить цитаты и экран «откуда ответ»;
• updated_at, valid_from, version and status, чтобы не выдавать прошлогоднее правило как действующее;
• owner, чтобы спорный ответ можно было направить владельцу знаний;
• access_groups или иной набор прав, который фильтрует поиск до генерации ответа;
• language and content_type, если база многоязычная или в ней смешаны регламенты, FAQ и карточки.

Метаданные не нужно выдумывать после индексации. Их лучше получать из исходной Wiki, CMS, CRM или реестра источников в том же пайплайне, где документ очищается и разбивается на фрагменты.

Шаг 5. Права доступа проверяйте до генерации ответа

Самая опасная ошибка корпоративного RAG - сначала найти закрытый документ, передать его модели, а потом попытаться вырезать из готового ответа лишнее. Ограничение должно работать на этапе retrieval: пользователь не должен получить в поисковой выдаче ни сам фрагмент, ни его текст для контекста модели.

Практический минимум:

1. Наследуйте ACL или группы доступа из исходной системы.
2. Копируйте права на каждый дочерний фрагмент, а не только на документ-родитель.
3. В каждый поисковый запрос передавайте разрешённые группы текущего пользователя.
4. При изменении прав переиндексируйте затронутый документ.
5. Отдельно тестируйте сценарии «доступ запрещён», а не только корректные ответы администратора.

В документации Azure AI Search это называется security trimming: результаты отсекаются по идентификаторам пользователя или групп прямо в запросе. Конкретная реализация зависит от стека, но принцип одинаковый: доступ контролирует поиск, а не промпт.

Шаг 6. Настройте обновление, удаление и версии

База знаний устаревает быстрее, чем кажется. Поэтому RAG нужен не одноразовый импорт, а процесс синхронизации.

Для каждого документа храните хеш содержимого и время последней обработки. Тогда пайплайн сможет:

• не пересчитывать embeddings для неизменённых файлов;
• переиндексировать только обновлённые разделы;
• удалять фрагменты, если документ снят с публикации;
• вести историю версий для разбора спорных ответов;
• показывать дату актуальности в интерфейсе ассистента.

Не оставляйте в индексе старые фрагменты после замены документа. Даже если новый текст тоже загружен, поиск может выбрать старую версию из-за похожей формулировки. При конфликтующих правилах полезно помечать один документ как действующий, а старый как архивный или удалять его из production-индекса полностью.

Шаг 7. Проверьте базу на реальных вопросах до запуска

Качество RAG нужно измерять в два этапа: сначала качество поиска, затем качество ответа модели. Красивый ответ не доказывает, что система достала верный источник.

Соберите контрольный набор из 50-100 вопросов от будущих пользователей. Включите в него:

• прямые вопросы с одним очевидным ответом;
• вопросы со служебными сокращениями и названиями продуктов;
• вопросы, где ответ разбросан по двум документам;
• запросы без ответа в базе;
• вопросы по новым и отменённым правилам;
• вопросы пользователя без прав на часть документов.

Для каждого вопроса заранее укажите ожидаемый источник и допустимый результат. Затем проверяйте:

Metrica	Что показывает
Попадание источника в top-k	Находит ли retrieval нужный документ до генерации
Подтверждённость ответа	Есть ли в процитированном фрагменте основание для каждого важного утверждения
Качество отказа	Говорит ли ассистент «не знаю», когда знания нет
Актуальность	Выбирается ли действующая версия документа
Проверка доступа	Не попадает ли закрытый фрагмент в контекст или цитату

Если поиск не находит правильный источник, не переписывайте сразу системный промпт. Чаще причина в структуре документа, метаданных, фильтрах или размере фрагмента.

Пример рабочего процесса на две недели

Дни 1-2. Выбираем один бизнес-сценарий, собираем вопросы, определяем владельцев и права доступа.

Дни 3-5. Создаём реестр источников, очищаем документы, настраиваем OCR и нормализацию в единый формат.

Дни 6-8. Разбиваем контент на фрагменты, добавляем метаданные, строим первичный индекс и ссылки на оригиналы.

Дни 9-10. Тестируем retrieval на контрольном наборе, меняем правила chunking и фильтрации.

Дни 11-12. Подключаем генерацию ответов с цитатами, правила отказа и журналирование.

Дни 13-14. Проверяем права доступа, запускаем пилот на ограниченной группе и фиксируем процесс обновления базы.

Такой пилот даёт ответ на главный вопрос до масштабирования: хватает ли качества исходных знаний, чтобы пользователи действительно доверяли ассистенту.

Частые ошибки при подготовке базы знаний для RAG

1. Индексируют архив целиком. В нём почти всегда есть дубли, отменённые правила и чувствительные данные.
2. Делят текст только по количеству символов. Вопрос и ответ, условие и исключение оказываются в разных фрагментах.
3. Не хранят ссылку на оригинал. Пользователь не может проверить ответ, а команда не понимает, что исправлять.
4. Смешивают документы разных версий. Ассистент получает несколько правдоподобных, но несовместимых ответов.
5. Проверяют права только в UI. Закрытый фрагмент уже мог попасть в контекст модели.
6. Тестируют только удачные запросы. Без «вопросов без ответа» система учится галлюцинировать в красивой форме.

Подготовка знаний обычно занимает больше времени, чем первый запуск модели, но именно она определяет, будет ли RAG экономить время команды или создавать новые риски. Если нужно связать базу знаний с CRM, helpdesk, внутренним порталом или несколькими LLM, посмотрите также как запустить корпоративного RAG-консультанта and как выбрать инфраструктуру для RAG.

FAQ

Можно ли загружать в RAG обычные PDF

Да, если из PDF корректно извлекается текст и сохраняется структура. Скан без OCR, сложная таблица или презентация с текстом внутри изображений требуют отдельной обработки, иначе поиск будет работать по неполному или искажённому содержимому.

Какой размер chunk выбрать для RAG

Нет единственного правильного размера. Для обычных регламентов можно начать примерно с 512 токенов и 128 токенов перекрытия, а затем проверить попадание источников в top-k на реальных вопросах. FAQ, таблицы и юридические пункты обычно требуют более семантического разбиения.

Нужны ли метаданные, если есть векторный поиск

Да. Векторный поиск находит смысловую близость, но без метаданных не знает версию, автора, источник, язык, срок действия и права доступа. Метаданные позволяют отфильтровать документы и показать проверяемую цитату.

Можно ли дать RAG доступ ко всем внутренним документам

Не стоит. В индекс попадают только источники с понятным владельцем, актуальностью и моделью доступа. Конфиденциальные данные лучше исключить либо снабдить строгими правами на уровне поиска.

Как часто обновлять базу знаний

Это зависит от источника: регламенты можно синхронизировать по событию публикации, Wiki - по расписанию, данные CRM или helpdesk - инкрементально. Главное, чтобы удаление и смена прав доступа попадали в индекс так же надёжно, как добавление новых файлов.

Useful on the topic

• AI-консультант с RAG для корпоративной базы знаний
• RAG-консультант для компании: запуск AI-базы знаний
• Сервер для RAG: on-premise, облако и выбор LLM
• Кейс AI2Media: AI-платформа для SEO-процессов

Sources

• Microsoft Learn: chunking документов для RAG и vector search
• Microsoft Learn: очистка фрагментов и обогащение метаданными
• Microsoft Learn: документный контроль доступа для поиска
• Microsoft Learn: hybrid search для RAG
• OpenAI API: метаданные и chunking strategy для vector store files
• OWASP GenAI: риски retrieval augmentation и контроля доступа