RAG 的下一步，可能不是更好的检索
RAG 火了两年，但你有没有想过——为什么每次对话，Agent 都要重新检索一遍同样的文档？
一个你可能熟悉的场景
你有一个基于 RAG 的 Agent，它连接了你的项目文档库。每天早上你开始工作时，会问它几个问题。Agent 从文档库中检索相关片段，生成回答。
到了下午，你又问了几个相关的问题。Agent 再次从文档库中检索——检索出的很可能跟上午的差不多。
第二天，你又来了。Agent 又检索了一遍。
每次对话都在从零开始检索。它不知道昨天已经检索过什么，不知道上周你问过类似的问题，不知道你对某个话题已经有了深入的理解。
这不是 Agent 的 bug——这是 RAG 架构的固有特征。但如果你退一步想，就会发现一个矛盾：
RAG 是为"一次性查询"设计的，但 Agent 需要的是"持续性理解"。
RAG 的本质：用完即弃
RAG（Retrieval-Augmented Generation）的核心流程是：
Query → Embedding → 向量检索 → 取回 Top-K 片段 → 拼入 Prompt → LLM 生成
这个流程在 2023 年出来的时候，确实解决了 LLM 知识陈旧和幻觉的问题。但它有一个根本的设计假设：每次查询都是独立的。
在"问答系统"的场景下，这个假设没问题。用户问一个问题，系统检索相关文档，生成回答。完事。
但 Agent 不是问答系统。Agent 跟用户的交互是持续的，它应该随着使用越来越了解用户和项目，应该能主动利用过去的经验来辅助当前任务。
这三个特征，RAG 一个都满足不了。
RAG 的三个短板
没有记忆层。 RAG 直接在原始文档上检索。它没有一个独立的"记忆层"来存储从过去交互中提炼出的知识和经验。打个比方：RAG 就像一个实习生，每次被问问题都去翻公司的文档库。虽然文档库很全，但这个实习生从不记笔记、从不总结经验。三个月后，他的工作效率跟第一天一样。
检索粒度粗。 RAG 通常按"文档片段"或"段落"为单位检索。但 Agent 需要的往往是更细粒度的信息——一个配置参数的含义、一个设计决策的原因、一个 Bug 的根因。这些信息可能散落在多个文档片段中，也可能根本不在文档中，而是存在于代码注释、commit message、甚至团队成员的口头讨论中。
缺乏时间维度。 一条三年前写的文档和昨天刚更新的文档，在 RAG 看来可能权重差不多。但在实际开发中，信息的时效性很重要——架构决策会变、技术方案会迭代、业务规则会更新。
为什么"更好的检索"解决不了根本问题
过去两年，RAG 领域的创新大多集中在"如何提升检索质量"上：Hybrid Search 结合向量检索和关键词检索，Re-ranking 对检索结果做二次排序，Query Rewriting 对用户查询做改写和扩展，Agentic RAG 让 Agent 自主决定何时检索，Graph RAG 用知识图谱增强检索。
这些都有价值，但它们解决的是"如何从现有知识库中更好地检索"。更根本的问题——知识从哪里来？如何积累？如何管理？——没有回答。
你可以把检索算法优化到极致，但如果你的知识库是一堆静态文档，Agent 的表现天花板就在那里。就像你可以给一个图书管理员最先进的检索系统，但如果图书馆的藏书从来不更新、不补充、不整理，这个管理员再能干也帮不了读者太多。
另一个思路：持久化的上下文层
我的看法是：RAG 的演进方向可能不是"更好的检索"，而是在 RAG 之上建立一个持久化的上下文层。
这个上下文层的职责不是存储原始文档（这是知识库的事），也不是做检索（这是 RAG 的事），而是：
- 从交互中自动提取和积累知识
- 以结构化的方式组织和管理知识
- 在需要时精准地将相关知识注入 Agent 的上下文
这个方向目前有一些探索，ContextDB 是其中一个。下面以它的设计为例，聊聊这个思路具体怎么落地。
ContextDB 的设计思路
ContextDB 的核心设计理念可以概括为三个词：积累、结构化、治理。
积累：从"用完即弃"到"越用越懂"。 传统 RAG 每次检索完就结束了。ContextDB 不同，它会自动从 Agent 的每次交互中提取有价值的信息，沉淀为"原子事实"（Atomic Fact）。每条原子事实带有两个关键属性：置信度（这条事实的可信程度，会随后续的确认或否定而调整）和时间戳（用于时效性判断）。Agent 的知识是持续积累的，而不是每次从零开始。
结构化：从"文本片段"到"知识图谱"。 传统 RAG 的知识是扁平的文本片段。ContextDB 设计了三层架构：原子事实是最小知识单元；记忆实体（Entity Card）是多个原子事实聚合成的画像，比如"用户编码偏好"这个实体，可能聚合了十几条从不同交互中提取的原子事实；记忆图谱（Memory Graph）是实体之间的关联关系，比如"支付模块"→"Saga 模式"→"幂等设计"→"分布式锁"。结构化带来的好处是：检索时不是简单地做文本相似度匹配，而是可以沿着图谱进行关联推理。当你问一个关于支付模块的问题时，Agent 不仅能获取支付模块的直接信息，还能沿着图谱获取相关的技术决策和设计约束。
治理：从"只增不减"到"生命周期管理"。 传统 RAG 的知识库通常是只增不减的——文档越来越多，噪音越来越多。ContextDB 引入了完整的知识生命周期：准入（AI 筛选 + 人工评审，不是所有信息都能入库）、演进（自动去重、冲突消解、置信度衰减）、分发（按 Workspace 和权限模型分发给不同的 Agent）。这套治理机制保证了知识库的信噪比。
当然，这套设计也有代价。比如知识提取依赖 AI 的质量——提取错了，反而引入噪音。再比如知识图谱的维护成本会随着规模增长而上升，在数据量特别大的场景下表现如何，我们自己也还在验证。
数据供参考
理论再好，还得看数据。在 LOCOMO 基准测试中：
| 指标 | ContextDB | LightRAG |
| 准确率 | ~79% | ~65% |
| Token 成本 | 基准 | 约 3x |
| 检索延迟 | 1.64s | - |
我比较关注的是 Token 成本。Token 成本是 Agent 最大的变动成本项。ContextDB 通过更精准的知识组织和检索，把不必要的 Token 消耗砍掉了不少。
在 Mem0 兼容迁移场景中，仅切换 endpoint，准确率就从 20% 提升到 78%。同样的记忆条目，不同的管理和检索方式，效果差这么多，说明上下文层的质量确实被低估了。不过这个数据的可复现性需要进一步验证，Mem0 的默认配置可能并不是最优的。
在 FinanceBench（金融）、SyllabusQA（教育）、Qasper（学术论文）、ClapNQ（开放域问答）四个数据集上表现稳定。
从 RAG 到 Context Database：范式可能在变
把视角拉远一点：
RAG 范式：
- 核心问题：如何从已有文档中检索相关信息？
- 知识来源：预置的文档库
- 交互模式：一次性查询
- 知识状态：静态
- 优化方向：更好的检索算法
Context Database 范式：
- 核心问题：如何让 Agent 持续积累和有效利用上下文？
- 知识来源：交互过程中自动提取 + 已有文档导入
- 交互模式：持续对话，知识随对话积累
- 知识状态：动态演进（置信度衰减、冲突消解、去重）
- 优化方向：更好的知识管理和治理
这不是要"替代"RAG。RAG 依然是一个重要的底层技术——ContextDB 的检索层也会用到向量检索。但 RAG 不应该是一个完整的解决方案，它应该是一个更大系统的组件。
就像数据库引擎（如 InnoDB）很重要，但你不会用它来替代整个应用架构。RAG 是"检索引擎"，Context Database 是"上下文管理系统"。这是两个层次的东西。
当然，也有人认为随着上下文窗口越来越大（1M Token 已经出来了），RAG 本身会被淘汰。这个观点有道理但也有局限——窗口再大，也解决不了跨会话记忆和知识治理的问题。方向还在演进中，没有定论。
接入实践
如果你对这个方向感兴趣，接入 ContextDB 比较简单：
curl -fsSL 'https://context-database-client.oss-cn-hangzhou.aliyuncs.com/install.sh' | bash -s -- --agent <agent> --api-key <api-key>
支持 Qoder、Claude Code、Codex、OpenClaw、OpenCode、Hermes、QoderWork 等主流 Agent。
如果你已经在用 Mem0，ContextDB 兼容 Mem0 协议，只需切换 endpoint，不需要修改业务代码。
最后
RAG 让 LLM 能够访问外部知识，减少了幻觉问题，这件事做得很好。但作为一个架构范式，它有一个绕不开的限制：它是为一次性查询设计的，不是为持续交互的 Agent 设计的。
当 Agent 从"聊天机器人"变成"长期协作伙伴"时，它需要的不只是一个更好的检索引擎，还需要一套能持续积累、组织、治理和分发知识的上下文管理系统。
从"用完即弃"到"越用越懂"，从"每次从零开始"到"持续积累"——我觉得这是 Agent 基础设施接下来要走的一个方向。至于最终会是什么样的技术方案跑出来，现在还不好说，但方向本身值得关注。
参考链接
