Как сохранить кэш индексации LlamaIndex IngestionPipeline

1. Зафиксируйте входной набор и список преобразований, включая размер чанка и модель, если она участвует в pipeline.
2. Выполните первый run с Document, сохраните количество узлов и содержимое контрольного фрагмента.
3. Вызовите persist для каталога кэша и создайте новый IngestionPipeline с тем же списком transforms.
4. Загрузите кэш через load и повторите run на неизменном входе; сравните данные узлов, а также время на вашей среде.
5. Измените входной текст и убедитесь, что результат не берётся ошибочно из прежней версии.

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

from llama_index.core import Document
from llama_index.core.ingestion import IngestionPipeline
from llama_index.core.node_parser import SentenceSplitter

transforms = [SentenceSplitter(chunk_size=128, chunk_overlap=16)]
docs = [Document(text="Правило R7: срок возврата 14 дней.", id_="R7")]
first = IngestionPipeline(transformations=transforms)
nodes_one = first.run(documents=docs)
first.persist("./ingestion-cache-r7")
second = IngestionPipeline(transformations=transforms)
second.load("./ingestion-cache-r7")
nodes_two = second.run(documents=docs)
print(len(nodes_one), len(nodes_two))

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

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

Вход: одна редакция правила R7. Ожидается одинаковый текст извлечённых nodes после сохранения и восстановления кэша; повтор может быть быстрее, но точное ускорение зависит от нагрузки. Если заменить 14 на 10 дней, результат должен отражать новую редакцию. Проверка только количества nodes не выявит устаревшее содержание — сравните строки.

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

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

Кэш экономит повторение дорогостоящих преобразований, но не управляет жизненным циклом опубликованного поискового индекса. Нельзя считать успешный вызов load доказательством того, что удалённый vector store восстановлен: состояние store и кэш — разные сущности. Если вы поменяли длину чанка, модель embeddings или реализацию custom transform, старые результаты не должны подменить новые; сохраните манифест конфигурации и сравните его перед повторным использованием. При работе с документами разных клиентов разносите кэши по границам доступа и проверяйте, что идентификатор tenant не потерян. Каталог кэша тоже может хранить производные персональных данных, поэтому применяйте правила хранения и удаления. Не говорите о гарантированном ускорении без измерения на собственном наборе: для маленького текста накладные расходы на диск могут перевесить пользу.

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

Проверочный набор должен включать неизменный документ, изменённый документ и документ с тем же текстом, но другой политикой доступа. Повторная обработка первого может использовать кэш; второй обязан дать новый текст; третий не должен наследовать чужие метаданные. Если в pipeline включена внешняя embedding-модель, зафиксируйте модель и версию интеграции до измерений, иначе различия нельзя объяснить корректно. Отдельно прогоните новый процесс после load, а не только повтор в той же памяти. В рабочей системе кэш можно очищать по версии пайплайна, но очищение само по себе не удаляет старые векторы из хранилища; организуйте обновление/удаление узлов отдельно.

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