Как обновлять базу знаний RAG и не смешивать версии документов

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

Это не встроенная гарантия RAG, n8n или любого векторного хранилища. Ниже — требования к проектируемому процессу, которые нужно проверить на выбранных системах и данных.

Почему новая загрузка не гарантирует актуальный ответ

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

Документация n8n подтверждает две функции компонентов: загрузчики документов могут применять разделители текста, а embeddings преобразуют данные в векторы. В n8n при этом поддерживаются текстовые embeddings. Эти функции помогают подготовить материал к поиску, но сами по себе не определяют, какая редакция действует.

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

Определите единицу обновления и источник истины

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

Для выбранной единицы можно спроектировать такие поля:

Это пример проектной схемы, а не универсальный стандарт и не подтверждённый набор полей любой платформы.

При полной замене файла новая версия наследует стабильный document_id, но получает новый version_id. При частичной правке нужно заранее решить, обновляется весь документ или самостоятельный раздел. Если разные редакции одновременно действуют для разных подразделений, регионов или условий, одного признака «последняя версия» недостаточно: область действия должна быть выражена отдельными данными и учитываться при поиске.

Источником истины служит не векторный индекс сам по себе, а согласованное место, где владелец содержания утверждает документ и его статус. Индекс должен отражать это решение, а не принимать его вместо человека.

Свяжите каждый фрагмент с документом и версией

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

Каждому фрагменту полезно передавать как минимум document_id, version_id, раздел, статус и источник. Нужный состав зависит от процесса и возможностей хранилища.

Документация Default Data Loader в n8n указывает, что к документу можно добавить metadata для векторного хранилища. Там же сказано, что эти metadata можно сопоставлять через параметр Metadata Filter при извлечении данных узлами векторного хранилища.

Это подтверждает наличие параметров в описанном компоненте n8n, но не автоматическое управление версиями. Команда проекта должна отдельно определить:

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

Добавление metadata не удаляет старые данные и не доказывает, что каждый запрос использовал нужный фильтр. Эти свойства проверяют на выбранной конфигурации.

Выберите маршрут замены без смешения редакций

Управляемая замена включает не только загрузку, но и явное решение о переключении:

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

Есть два базовых маршрута. В первом новую редакцию готовят в отдельном индексе или отдельной конфигурации поиска, проверяют и затем переключают рабочий маршрут. Во втором связанные фрагменты управляемо заменяют в текущем индексе по стабильным идентификаторам. Первый вариант упрощает сравнение состояний, второй может требовать меньше инфраструктуры. Выбор зависит от возможностей хранилища и требований к доступности.

Не следует называть переключение атомарным, пока это свойство не подтверждено для выбранной архитектуры. Документация Azure AI Search сообщает, что в классическом RAG-подходе incremental indexing поддерживает актуальность содержимого. Этот факт относится к Azure AI Search и не доказывает безопасную замену редакции, удаление всех прежних фрагментов или пригодность того же маршрута для другой платформы.

Условный синтетический пример — не клиентский кейс и не выполненный тест. В базе находится регламент обработки заявок версии 2.3. Владелец выпускает версию 2.4, где меняет обязательные поля и порядок эскалации.

Это предлагаемое поведение будущего решения. Пример не подтверждает встроенную функцию n8n, Azure AI Search или другого продукта.

Обработайте удалённые, переименованные и частично изменённые документы

Не каждое изменение является новой версией того же файла. Для разных операций заранее определите ожидаемое состояние идентификаторов, фрагментов и ссылок.

Успешная загрузка новой редакции не доказывает, что старая больше не участвует в поиске. После каждой операции нужно явно подтвердить удаление либо исключение прежних фрагментов из рабочего маршрута.

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

Проверьте поиск до переключения и после него

Проверка должна отвечать не на вопрос «workflow завершился?», а на вопрос «какие сведения теперь получает пользователь?». Для этого владелец содержания составляет смысловую матрицу без произвольной нормы количества запросов.

Для каждого запроса проверяйте раздельно:

1. найденные фрагменты и их содержание;
2. document_id, version_id и статус редакции;
3. ссылку или указание на исходный документ;
4. цитату или выдержку, на которой основан вывод;
5. итоговый ответ помощника.

Завершение переиндексации, успешный HTTP-ответ или зелёный статус workflow подтверждают только технический этап. Они не доказывают, что поиск перестал использовать отменённое содержание. Если старая редакция остаётся среди рабочих результатов либо исключение нельзя подтвердить, переключение не завершайте.

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

Назначьте ответственность и предусмотрите возврат

Актуальность базы знаний нельзя оставлять без владельца. Разделите решения между ролями:

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

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

До изменения определите способ возврата к последней подтверждённой конфигурации. Это может быть обратное переключение маршрута, восстановление подготовленного индекса или повторная загрузка подтверждённого набора — в зависимости от архитектуры. Не полагайтесь на автоматическое хранение пригодной для восстановления версии, пока эта возможность не подтверждена для конкретной платформы.

Возврат нужен, если после переключения обнаружились пропущенные фрагменты, неправильный статус, участие старой редакции или ответы, не подтверждённые действующим документом. После возврата команда фиксирует причину и повторяет затронутые проверки.

Что подготовить для доработки ИИ-помощника

Чтобы обсудить доработку, соберите:

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

Switch On AI разрабатывает ИИ-агентов и помощников под конкретные операции. Для такой задачи можно сначала разобрать текущий маршрут обновления, определить границы процесса и ограничения систем, затем подготовить техническое предложение и прототип ключевого сценария.

Прототип не равен полноценному внедрению. Возможности удаления, фильтрации и переключения нужно подтвердить на выбранном хранилище и тестовых данных. Трудозатраты, стоимость разработки, сторонние лицензии и эксплуатационные расходы согласуются отдельно.

Если в базе одновременно находятся разные редакции, начните с одного типового документа. Подготовьте его действующую и предыдущую версии, перечень изменений и несколько реальных рабочих вопросов — этого достаточно, чтобы предметно обсудить схему обновления и критерии приёмки.