RAG данные решают судьбу всей системы: если корпус содержит дубли, устаревшие версии и документы без понятных прав, поиск честно найдёт их и модель честно ответит ерундой. Подготовка корпуса скучнее выбора модели, но именно она отвечает за большую часть ошибок. Порядок работы с документами складывается из пяти решений: что включать, как вести версии, кому что показывать, как резать текст и как обновлять индекс. Подход рассчитан на корпуса, где документы меняются чаще раза в квартал.
Что в корпусе
В корпус попадают документы, на которые компания готова ссылаться в ответе. У каждого есть владелец, дата, версия и уровень доступа. Всё остальное остаётся за бортом, как бы удобно ни было загрузить папку целиком.
Соблазн велик: загрузить общий диск и посмотреть, что получится. Получается, как правило, свалка, в которой поиск возвращает черновики, старые регламенты и чьи-то заметки наравне с утверждёнными документами. Поэтому корпус собирается намеренно, по списку.
Составьте реестр корпуса в виде таблицы: название, владелец, дата, версия, статус, доступ, источник. Реестр живёт отдельно от индекса и служит источником правды: индекс строится по нему, а изменения проходят через него. Когда возникает вопрос «откуда в ответе этот документ», ответ находится за минуту.
- Включайте только утверждённые документы, на которые можно сослаться при споре.
- Для каждого фиксируйте владельца: человека, который отвечает за актуальность.
- Записывайте дату и версию: без них нельзя выбрать между двумя похожими документами.
- Помечайте уровень доступа: открытый, для сотрудников, для отдела, закрытый.
- Исключайте черновики, переписку, личные заметки и скопированные чужие тексты.
Общее описание того, как устроена база знаний для компании, дано в статье RAG: база знаний для компании. Здесь разбирается только подготовка данных.
Версии и дубли
Самая частая причина странных ответов: в корпусе лежат две версии одного регламента, и поиск возвращает обе. Модель вынуждена выбирать, и выбирает произвольно. Лечится это на этапе подготовки.
Дубли заметны с запозданием. Поиск возвращает три почти одинаковых абзаца, и кажется, что система уверена в ответе, хотя на деле она трижды процитировала один источник. Для проверки возьмите десять вопросов и посмотрите, сколько разных документов стоит за каждым ответом: если один и тот же текст повторяется, пора чистить корпус.
| Проблема | Как заметно | Что делать |
|---|---|---|
| Две версии документа | Противоречивые ответы на один вопрос | Оставить действующую, старую убрать из индекса или пометить архивной |
| Точные копии | Один абзац занимает все места в выдаче | Находить по сравнению текста и удалять повторы |
| Почти копии | Мелкие отличия создают видимость разных мнений | Сводить к основному документу, различия описывать отдельно |
| Документ ссылается на устаревший | Цепочка ведёт к неверному выводу | Проверять ссылки и обновлять связанные документы вместе |
| Нет даты | Невозможно определить актуальность | Требовать дату у владельца до загрузки |
Сложнее всего с документами, которые существуют в разных форматах: договор в редакторе, его скан и выгрузка из системы учёта. Выберите один канонический источник, а остальные привяжите к нему как копии. Копии получают пометку «производная» и ссылку на оригинал, чтобы при проверке сразу было видно, откуда они взялись и когда синхронизировались. Тогда обновление идёт в одном месте, а индекс получает единственный вариант текста.
Практичный приём: у каждого документа есть статус «действует», «заменён», «архив». В выдачу попадают только действующие, а архивные открываются по явной просьбе, например для разбора спорной ситуации.
Права доступа
Система поиска по документам обходит привычные ограничения доступа: если индекс собран из всего диска, сотрудник получит ответ с содержанием документа, к которому у него самого нет доступа. Права поэтому проверяются на уровне данных, запрос к модели с вежливой просьбой остаётся лишь пожеланием.
Каждый фрагмент в индексе хранит метку доступа, а поиск фильтрует выдачу по правам пользователя до того, как фрагмент попадёт к модели. Просьбу «скрой закрытое» в тексте запроса защитой считать нельзя.
Отдельно проверьте документы с персональными данными: их либо исключают из индекса, либо подготавливают с обезличиванием, а решение согласуют с юристом компании. Юридические гарантии остаются за юристом, а порядок мы фиксируем письменно.
Кто в вашей компании отвечает за актуальность документов, которые попадут в индекс?
Разбиение
Разбиение на фрагменты определяет, что поиск вообще способен найти. Слишком мелкие куски теряют контекст, слишком крупные размывают смысл. Универсальной величины нет, её подбирают на ваших вопросах.
Таблицы и списки требуют особой заботы: разрезанная пополам таблица теряет смысл строк, а оторванный от заголовка пункт списка читается как чужая мысль. Для таблиц удобно хранить заголовок столбцов в каждом фрагменте, а для длинных списков повторять вводную фразу.
- Резать по структуре документа: заголовкам, пунктам, абзацам, а таблицы сохранять целиком вместе с шапкой.
- К каждому фрагменту добавлять название документа и раздела: так он остаётся понятным вне контекста.
- Оставлять небольшое перекрытие соседних фрагментов, чтобы ответ на границе сохранился.
- Для регламентов с нумерацией хранить номер пункта: цитата с номером проверяется мгновенно.
- Сравнивать два варианта разбиения на одном наборе вопросов и выбирать по результату.
О том, как проверить результат поиска после разбиения, читайте в статье RAG поиск: оценка релевантности, а о минимальном прототипе, где всё это можно опробовать, в материале RAG Python: минимальный прототип.
Обновление индекса
Документы меняются, и индекс обязан за ними успевать. Полная пересборка при каждой правке дорога и медленна, поэтому нужен инкрементальный порядок: менять только то, что изменилось.
- Для каждого документа хранится отпечаток содержимого, по нему определяется, что поменялось.
- Изменённый документ разбивается заново, старые фрагменты удаляются из индекса, новые добавляются.
- Удалённый документ убирается вместе со всеми фрагментами, чтобы из ответов исчезли ссылки на него.
- Права и статусы обновляются отдельно от текста, ведь смена доступа обходится без нового разбиения.
- После обновления прогоняется контрольный набор вопросов, чтобы поймать поломку сразу.
- Обновление фиксируется в журнале: что, когда и по чьему решению изменено.
Задайте расписание: срочные правки, например отмена регламента, попадают в индекс сразу, а плановые собираются раз в сутки или раз в неделю. Так индекс остаётся свежим там, где это важно, и экономит ресурсы там, где задержка безобидна. Особняком стоят документы с ограниченным сроком действия: акции, временные порядки, сезонные условия. Для них в реестре ставится дата окончания, и по её наступлении документ автоматически уходит в архив и перестаёт мелькать в выдаче годами. Фиксируйте время последнего обновления на странице ответа, чтобы пользователь видел актуальность.
Реализация такого обновления в конструкторе процессов описана в статье n8n RAG: обновление документов и поиск по источникам, а хранение индекса и его обновление в самой базе в материале Qdrant в Docker. Если подготовку корпуса нужно собрать под вашу компанию, ею занимаются в проектах по автоматизации бизнес-процессов: состав, версии, права, обновление и контрольные вопросы.