Как обновлять документ в RAG, чтобы старые чанки не оставались в ответах
Редактор сократил инструкцию с десяти абзацев до семи. Загрузчик перезаписал первые семь фрагментов, но оставшиеся три не удалил. Теперь поиск одновременно видит актуальное правило и старое исключение. По дате последнего запуска загрузки всё выглядит исправным: проблема находится в модели обновления документа, а не в расписании.
Нужно обновлять не произвольный набор точек, а согласованную версию смыслового документа. Идентификатор документа, версия извлечения и список фрагментов делают эту операцию проверяемой.
Где возникает ошибка
Данные ниже вымышлены: они показывают способ разбора, а не измерения действующего сервиса.
| Состояние | Новая версия | Старые фрагменты | Риск |
|---|---|---|---|
| До обновления | Отсутствует | Десять фрагментов | Старая инструкция |
| Частичная запись | Семь фрагментов | Ещё три фрагмента | Смешанные правила |
| Согласованная замена | Семь фрагментов | Не участвуют в поиске | Одна версия |
Один из вариантов — подготовить новую версию отдельно, проверить полноту и переключить активный указатель. Другой — транзакционно согласовывать реестр документов и поисковую доступность в приложении. Конкретные возможности зависят от хранилища; нельзя предполагать атомарность многосистемного обновления по умолчанию.
Удалять старую версию сразу после первой успешной записи тоже опасно: генерация эмбеддингов могла завершиться лишь частично. Статус «готово» должен означать завершение всей проверяемой операции.
Как воспроизвести проблему
Проведите тест с сокращением, переименованием и полным удалением документа. Искусственно прервите загрузку посередине. После каждого сценария запросите все фрагменты по идентификатору документа и сравните их с реестром активной версии.
В поисковом логе сохраняйте версию найденных фрагментов. Это позволит отличить плохой ранжировщик от рассинхронизации индекса. Добавьте контроль числа активных частей и проверку отсутствия удалённой фразы. Для важных документов фиксируйте время публикации в источнике и время доступности новой версии в поиске.
Что учитывать при переносе
Отложенная обработка и репликация могут давать окно рассогласования. Его нужно описать как свойство сервиса и измерять. Обещание немедленной актуальности требует более строгой архитектуры, чем периодическая загрузка файлов.
Коллекции и служебные признаки позволяют разделять наборы данных; согласование версий остаётся задачей приложения. Официальная документация помогает уточнить технический механизм; предложенный диагностический протокол — наш учебный пример.
Если хотите связать этот разбор с системной практикой, посмотрите программу Vector DB & RAG Developer на Latorn: она охватывает векторный поиск с фильтрами, гибридную выдачу и оценку RAG. Перед оплатой сопоставьте требования курса со своим опытом и задачей проекта.
Следующий шаг: RAG на практике: документы, поиск и качество ответов. По смежным вопросам: Чанки в RAG теряют заголовки: как сохранить смысл раздела, Как готовить таблицы для RAG, чтобы модель не путала столбцы.
