Как обновлять документ в RAG, чтобы старые чанки не оставались в ответах

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

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

Где возникает ошибка

Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.

СостояниеНовая версияСтарые фрагментыРиск
До обновленияОтсутствуетДесять фрагментовСтарая инструкция
Частичная записьСемь фрагментовЕщё три фрагментаСмешанные правила
Согласованная заменаСемь фрагментовНе участвуют в поискеОдна версия

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

Удалять старую версию сразу после первой успешной записи тоже опасно: генерация эмбеддингов могла завершиться лишь частично. Статус «готово» должен означать завершение всей проверяемой операции.

Как воспроизвести проблему

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

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

Что учитывать при переносе

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

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

Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.

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