检索增强生成（RAG）已成为大语言模型（LLM）落地的标准范式：通过检索外部知识库为模型提供上下文，既降低幻觉率，又避免了频繁重训。然而，一个被长期忽视的问题正在浮现——知识库本身会过时。
实际上由于技术文档每月进行版本迭代、金融报告按季度更新、政策法规持续修订等情况的存在，标准RAG系统面临严重的"版本混淆"问题：它只看语义相似度，不看时间有效性，常常把旧版本的内容当作当前答案返回。更进一步地，当知识库内存在更细粒度的知识冲突时，涉及到的知识增加、遗忘、冲突、演化等问题就需要更复杂的框架进行处理。
因而，本文梳理三篇代表性工作，它们从不同粒度、处理方法切入这一问题，构成了"可更新知识库"技术发展的清晰脉络。
一、VersionRAG: Version-Aware Retrieval-Augmented Generation for Evolving Documents
1. 背景
技术文档的版本迭代是普遍现象，每次更新都会引入新API、废弃旧特性，而当用户问"某个API在当前版本中是否可用"时，标准RAG系统表现不佳。
同时作者经过系统性测试发现：传统Naive RAG在版本敏感问题上仅58%准确率，GraphRAG也仅64%。失败原因有二：一是跨版本混淆，二是无法追踪隐式变更。为此，作者提出了以文档为单位，通过版本感知的图结构解决"多版本检索"问题的VersionRAG。
2. 核心方法
VersionRAG的核心创新是引入一个五层层级图结构来显式建模文档演化：
Category层：文档分类（如API参考、配置指南） Document层：同一文档的标识 Version层：该文档的所有历史版本，形成有序时间序列 Content层：每个版本的具体内容片段 Change层：版本间的变更记录（包括显式changelog和通过diff推断的隐式变更）
检索时，系统先对查询进行意图分类（是问"当前状态"还是问"版本间差异"？），然后路由到不同的检索路径并得到响应的检索内容，随后基于检索到的文档进行相关问题的回答。
3. 实验结果
在VersionQA基准测试（100个人工标注的版本敏感问题，覆盖34个技术文档）上，其准确率和版本变更召回性能均明显优于基线。
4. 局限
需要预先知道文档的版本序列关系，且更新只能以文档为单位进行触发，框架不够灵活。 VersionQA基准规模较小（100题），基线覆盖不够广泛，泛化性待验证。 对非结构化、无明确版本号的文档（如新闻、报告）适用性有限。 本质上是只增量更新的知识库，并没有添加显式的遗忘机制，后续会导致知识库的过分冗余，且无法控制细粒度的知识更新。
二、STACKFEED: Structured Textual Actor-Critic Knowledge base editing with FEEDback
1. 背景与动机
VersionRAG解决了"如何从多版本知识库中正确检索"的问题，但一个更根本的问题是：知识库本身可能就是错的、不完整的、过时的。微软研究院的STACKFEED将视角从"检索端优化"转向"知识库端编辑"。其核心洞察是：与其让RAG系统更聪明地应对劣质知识库，不如让Agent直接修改知识库本身。
2. 核心方法
STACKFEED采用多Actor-集中Critic的强化学习框架：
架构设计：
Critic（集中评估器）：接收用户反馈和RAG系统的错误案例，分析知识库中哪些文档存在问题，生成文档级的编辑指令（如"文档X中关于Y的描述已过时，需补充Z"）。 Actor（分布式编辑器）：每个Actor是一个ReACT agent，负责一个文档的编辑。它接收Critic的指令，执行结构化编辑操作。 反馈循环：编辑后的知识库重新输入RAG系统测试，专家评判改善效果，结果反馈回Critic优化下一轮指令
3. 实验结果
通过对比原始知识库（Base KB）与编辑知识库的方法，我们发现本文方法通过编辑知识库能使得各种模型表现出更优的检索性能。
同时在编辑质量上，完备性与连贯性均有着出色的表现。
此外，在更复杂的仓库级迁移任务中，迁移成功率的提升说明了其复杂场景中的可行性。
4. 局限
编辑粒度为文档级，对于一个事实分散在多个文档中的情况，协调困难。 依赖专家反馈，自动化程度有上限，规模拓展成本高。 强化学习训练需要大量交互数据。 未处理知识之间的关联一致性（编辑A可能导致B过时）。
三、Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory
1. 背景与动机
如果说VersionRAG是"文档级的版本管理"，STACKFEED是"文档级的Agent编辑"，那么Mem0则将更新粒度推进到了单条知识的级别。
考虑到对话式AI Agent需要跨会话记住用户偏好、历史上下文和演变的事实。但LLM的上下文窗口是有限且昂贵的，因此提出了一个生产级的知识管理架构：像数据库一样对知识进行增删改查，而非全量输入。
2. 核心方法
Mem0实现了一个三阶段流式管道：
阶段一：提取（Extraction）
从用户-AI对话中提取显著事实。 使用LLM prompt，结合全局摘要和近期消息窗口。 输出：候选单元。
阶段二：巩固（Consolidation/Update）
将候选事实向量化，检索语义相似的已有知识 对每条候选执行四种操作之一：ADD（新增）、UPDATE（更新已有知识）、DELETE（删除矛盾旧知识）、NOOP（无操作）
阶段三：检索（Retrieval）
查询向量化后检索top-k相关知识 注入为LLM的上下文补充
知识图谱变体（Mem0g）：
在向量知识库之上增加知识图谱层 捕捉三元组之间的关系（如"用户→works_at→公司X"、"公司X→budget→50万"） 支持多跳推理和时序追踪
3. 实验结果
在LOCOMO基准上进行实验，从单跳、多跳、开放性问答等多个角度与众多基线进行比较，展现出较优性能。
4. 局限
依赖LLM进行事实提取，提取质量受限于LLM能力。 向量知识对复杂推理（多跳、反事实）的支持有限，图谱变体部分弥补但延迟增加。 更新严重依赖于检索结果，且更新无法自由拓展，仍是受限于向量检索的范式。 缺乏像VersionRAG那样的严格版本追溯——一旦UPDATE/DELETE执行，旧知识难以恢复。
五、发展方向及展望
传统的基于静态索引的RAG知识库已经难以应对高速更新的现实场景，需要参考如今“记忆”的方法对知识库进行实时地更新确保检索的高置信度与高质量。而在这个过程中，基于什么样的粒度进行知识库的构建及检索；更新的方法是该全权交由Agent还是引入监督信号，甚至基于特定算法进行；更新能否自由、自主拓展；更新行为的触发与可恢复性设计等都是一个可更新的检索增强知识库设计和使用该考虑的基本方向。
