资料只改了一部分，LlamaIndex 的入库流水线可以复用没变的处理

知识库最开始能问答以后，真正长期要处理的是资料更新：一批文件里只改了两份，是否还要重新切分、提取标题、计算全部向量？LlamaIndex Framework 的 IngestionPipeline，值得从这个重复工作认识。

它让入库成为一组可见的转换，并为处理结果建立缓存。这里讲的是开放的 Framework；当前 README已经说明公司重心转向 LlamaParse 等文档产品，但仍保留 Framework 工具包，两者不要混成同一项云服务。

文档进入索引之前，经过哪些处理

官方入库文档用 SentenceSplitter、TitleExtractor、embedding 组成示例。输入是文档，先切成更小节点，再补元信息并计算用于检索的向量。结果可以作为节点列表返回，也可以直接写入指定向量存储。

这比一句“把资料上传到知识库”多交代了一层：检索用的材料由哪些处理产生。段落怎么切，是否提取标题，选择什么 embedding，都会改变后面能检索到的内容。流程可编辑，才便于逐项调整而不是整套重搭。

如果只是想先检查切分结果，可以不接向量存储；要直接写入向量数据库，文档明确需要在流水线中计算 embedding。输入、处理步骤与下游需要的字段，应在这里接上。

IngestionPipeline 对每个 node 与 transformation 的组合做哈希并缓存。相同节点用相同转换再次处理，就可以复用之前结果。若数据或处理方式变化，不能默认仍使用旧结果。

本地缓存还需要 persist，再在后续运行 load，才能跨运行继续使用；也可以配置远程缓存。这里保存的是处理结果，不是模型自动记住了上次读过的文件。

教学情境中，一组开发说明只有安装章节更新，可以先追踪该章节对应的节点变化，再看哪些转换需要重做。目标不是承诺每次都只算一个段落，而是让重复处理有可识别的缓存单位。

官方还提供 docstore 的文档管理。它以 document.doc_id 或 node.ref_doc_id 为锚点，记录文档 ID 与内容哈希。连接向量存储后，同一 ID 内容未变可以跳过；哈希变化时重新处理并 upsert。

这与转换缓存不完全相同：一层判断“这是不是同一份文档的更新”，另一层判断“这份节点用这项转换有没有算过”。稳定的来源 ID 因而很重要，不能每次导入都随机换一个身份，再期待增量规则自然起效。

资料从源站删除、权限改变或整个来源不可见，还需要应用自己的同步规则；不能从重复检测推出所有生命周期问题都已解决。

框架采用 MIT 许可，模型、embedding 与向量存储按所选集成准备。对于持续维护文档索引的人，这条流水线的实用之处，是让入库过程能够保存、重用与检查：资料变在哪里，哪一步重算，最终又把什么写回检索系统。