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

1. Назначьте правилу устойчивый ID, независимый от текста и даты обновления, и сохраните старую редакцию вне текущего поискового индекса.
2. Постройте индекс на начальном тексте, проверьте запрос на число 14.
3. Создайте новый Document с прежним id_ и новым содержимым, затем вызовите update_ref_doc.
4. Повторите проверку: свежий факт присутствует, старый не выдаётся как действующая версия.
5. Сохраните индекс согласно используемому backend и протестируйте то же после перезапуска.

Готовый шаблон Python

from llama_index.core import Document, VectorStoreIndex

old = Document(text="Правило R7: срок возврата 14 дней.", id_="R7")
index = VectorStoreIndex.from_documents([old])
new = Document(text="Правило R7: срок возврата 10 дней.", id_="R7")
index.update_ref_doc(new)
results = index.as_retriever(similarity_top_k=3).retrieve("срок возврата R7")
for item in results:
    print(item.node.get_content())

Код ниже в статье предназначен для тестовых источников без персональных сведений. Вызовы SDK не выполнялись в данном окружении с реальной моделью; синтаксис Python проверен отдельно. Не переносите вывод демонстрационного эксперимента на любой корпус и любого провайдера без повторной проверки.

Пример входа и ожидаемого результата

Вход: два текста одной политики R7 со сроками 14 и 10 дней. После update_ref_doc ожидается поиск актуального правила о 10 днях и отсутствие старого утверждения о 14 днях как активного источника. Проверяйте текст всех вернувшихся узлов, а не только первый ответ генератора.

Сохраните входные файлы, идентификаторы документов и ожидаемое утверждение в отдельном проверочном наборе. При неуспехе выделяйте слой ошибки: чтение источника, преобразование в nodes, получение embedding, поиск, синтез ответа или UI. Правильная форма ответа ещё не гарантирует правильного происхождения сведений.

Диагностика и границы решения

Если новую редакцию загрузить как новый ID, индекс может содержать оба противоречащих правила; запрос выберет то, которое лучше совпадает по векторной близости, а не то, которое вступило в силу позднее. Устойчивый id_ решает задачу сопоставления логического документа. При частичном изменении большого договора update_ref_doc может перепарсить его узлы, поэтому контролируйте число старых узлов после обновления. Архив старых редакций держите отдельно с явным статусом и проверкой доступа, если он нужен аудиторам, а не в общем RAG-корпусе. Если приложение распределённое, состояние нескольких реплик и внешнего vector store требует согласованного переключения. Функция refresh_ref_docs полезна при периодическом сравнении входного набора, но не заменяет проверку исчезнувших из нового набора документов. Удаление в некоторых структурах поддерживается не везде, о чём предупреждает официальный источник.

Дополнительный проверочный сценарий

Для регрессии держите два вопроса: «каков действующий срок» и «каков был срок в прошлой редакции». Первый должен брать только активный R7, второй — архивную систему с явной датой, если такая функция вообще предусмотрена. В тесте с обновлением добавьте отрицание и исключение, чтобы новая редакция не уничтожила часть важных условий. Сравните список source node IDs до и после: устаревший узел не должен участвовать в рабочей выдаче. Не полагайтесь на хронологическую сортировку метаданных без серверного правила: модель не гарантирует выбор новейшего текста. Перед массовым refresh снимите резервную копию индекса и протестируйте одну запись на отдельной среде.

Критерии проверки