Обновление базы знаний RAG: версии документов, удаления и права доступа
Файл заменили, а помощник продолжает цитировать прежнюю инструкцию. Разбираем реестр источников, переключение редакций, удаление фрагментов и проверку доступа до генерации ответа.
В инструкции изменили порядок возврата товара, загрузили новый PDF и сообщили сотрудникам о новой версии. Через неделю помощник по-прежнему рекомендует старый порядок. Документ в хранилище уже правильный, но векторный индекс содержит фрагменты двух редакций. Повторная загрузка файла добавила знания, не определив, какие из них действуют.
Для корпоративной RAG-системы нужен жизненный цикл источников. Разберём учебный контур на n8n и векторном хранилище: что учитывать при загрузке, как вводить новую редакцию и что делать с удалением. Это отдельная задача от улучшения ранжирования найденных фрагментов.
Постоянный идентификатор документа должен переживать переименование файла. Рядом хранят редакцию, контрольную сумму, дату действия, владельца и состояние индексации. Дата изменения в файловой системе полезна, но не всегда доказывает изменение содержания: документ могли скопировать или пересохранить.
Учитывайте статус публикации. Черновик новой инструкции не должен автоматически вытеснять утверждённую. Если правило начинает действовать позже, его можно подготовить в индексе заранее, но доступность при ответе должна определяться датой и статусом. Само попадание текста в базу не делает его действующим регламентом.
В руководстве n8n по RAG описана цепочка загрузки, разбиения на фрагменты и работы с векторным хранилищем. Для эксплуатационного контура к ней нужно добавить реестр состояния и проверку завершения. Триггер изменения файла не доказывает успешность всей индексации.
Новую редакцию готовят с отдельным номером: извлекают текст, формируют фрагменты, добавляют метаданные и проверяют полноту. Только затем реестр переключает активную версию. Поиск обязан проверять этот статус; простое сосуществование двух редакций в одной коллекции не даёт нужной гарантии.
Для небольшой базы проще подготовить отдельный снимок целиком и переключить приложение на него. Для большой — обрабатывать изменившиеся документы. Выбор зависит от объёма, времени обновления и возможностей хранилища. Не выдавайте пакетную запись нескольких фрагментов за транзакционное обновление всех связанных систем.
Ниже собственная модель метаданных, а не готовый запрос к Qdrant. Она помогает связать найденный текст с конкретной редакцией и областью доступа.
example.jsonJSON
{"source_id":"RETURNS-POLICY-DEMO","revision":4,"chunk_id":"RETURNS-POLICY-DEMO:4:07","source_section":"Возврат после отгрузки","access_scope":"support-team","content_hash":"demo-content-hash","ingestion_state":"ready"}
Пользовательские права проверяются на сервере по текущей учётной записи. Нельзя принимать access_scope из свободного текста запроса пользователя. Метаданные помогают отфильтровать кандидатов; полноценная проверка доступа также должна учитывать действующее состояние источника. Фильтры Qdrant — инструмент отбора, а не готовая корпоративная модель прав.
Если источник отменён или закрыт, сначала исключите его из допустимых результатов. Затем удалите соответствующие фрагменты и обработайте кэш, копии контекста и историю диалога в пределах принятой политики. Иначе документ исчезнет из нового поиска, но продолжит попадать в ответ из ранее сохранённого контекста.
В Qdrant предусмотрено удаление точек по идентификаторам или фильтру . Фильтр должен ограничивать нужный документ и редакцию: слишком широкий отбор затронет соседние источники. Пригодность данных к использованию проверяют в приложении независимо от того, завершилась ли физическая очистка всех копий и резервных хранилищ.
Полезна периодическая сверка реестра с источником. Одних уведомлений об изменениях недостаточно: часть событий может не дойти, а некоторые подключения не сообщают все виды изменений. Сверка обнаруживает пропущенную отмену, потерянный файл и документ, который так и остался в состоянии подготовки.
Как проверить обновление до выдачи пользователям #
Подготовьте вопрос, ответ на который заметно отличается в двух редакциях. Сначала сохраните результат на старой версии, затем обновите документ и повторите вопрос в новом и продолжающемся диалоге. Проверяйте цитату, номер редакции и полученные фрагменты, а не только похожесть итоговой формулировки.
— Индексация оборвалась на середине: неполная новая редакция не активировалась.
— Документ отменён: его текст не возвращается и при точном цитировании в вопросе.
— Права сотрудника отозваны: новый запрос не раскрывает закрытое содержание.
— Файл переименован: не появилось второй независимой истории документа.
— В новой версии убрали абзац: прежний ответ больше не воспроизводится как действующее правило.
Нужно ли заново вычислять все embeddings при каждом изменении? #
Нет, неизменившиеся фрагменты можно переиспользовать при совместимой модели и согласованной схеме. Но смена модели embeddings или принципа разбиения требует отдельной миграции. Контрольная сумма текста не доказывает совместимость векторных представлений.
Можно ли просить модель игнорировать старые документы? #
Инструкция полезна как дополнительное правило, но не заменяет исключение недопустимых фрагментов до передачи модели. Если старый текст уже попал в контекст, приложение само создало противоречие, которое не стоило перекладывать на генерацию.
NetLabCS поможет спроектировать RAG-систему и поиск по базе знаний с реестром источников, обновлениями и проверкой доступа. Расскажите, где хранятся инструкции , кто утверждает новые версии и как быстро отменённый документ должен переставать использоваться. Это позволит выбрать подходящий порядок индексации и приёмочные сценарии.
