向量检索之后，Agent 长期记忆又回到了知识图谱

从 Semantic 技术的视角看，HippoRAG 的价值不只是把知识图谱重新放进 RAG，而是让分散在不同文档中的实体、关系与证据能够被组织、连接和追溯。它提醒我们，Agent 的长期记忆不能只依赖相似度召回，还需要稳定身份、关系结构和来源边界，才能把“找到内容”推进到“理解并核对上下文”。

就如同我在 DTCC 大会上讲解主题 《Not only Vector》时一直强调的，向量检索是非常重要的技术，我们不是要放弃向量检索，而是要理解清楚它的能力边界。但某个问题的答案确实藏在某一个 chunk 里时，它往往就是最直接的办法。

而真正的麻烦在于，现实问题很少会把问题的线索放在同一段材料里，例如：A 文档给出人物，B 文档给出关系，C 文档才留下能回答问题的事实。如果我们只按相似度挑几段文字，可能每一段的相似度都不够，必须把它们连起来才能得到答案。

2024 年的 HippoRAG 做了很务实的选择：把知识图谱和 Personalized PageRank 放回 RAG。它不是要用图取代向量，而是要解决向量检索难以独自解决的问题：跨文档的线索怎样才能相遇并一起使用。

前面几期内容，我们从【DBpedia】 的实体和链接，走到 【TransE】 的向量、【RAG】 的外部记忆，再到 【Reflexion】 的经验记忆。HippoRAG 把问题带回关系本身：向量时代走了一大圈，为什么我们还需要图？

图 1：HippoRAG 论文标题与作者。来源：Gutiérrez 等，NeurIPS 2024，论文第 1 页。

不只是没召回，是线索根本没有连上

标准 RAG 往往把 passage 独立编码。问题和一段文字足够相似，它就更容易被召回。局部、单跳问题适合这种做法；跨文档组合关系时，它就会露出边界。

论文给出的例子是：查询同时提到 Stanford 和 Alzheimer’s，真正相关的人物 Thomas Südhof 可能分别出现在“任职于 Stanford”和“研究 Alzheimer’s”的不同材料里。任何一段材料单独看，都未必对完整问题有用；但沿着图中的关系，两条线索却会在同一个实体上会合。

这正是图结构擅长处理的部分。它不只问“哪段文字像这个问题”，还追问“这些概念通过什么路径连在了一起”。

HippoRAG 先构图，再让相关性沿关系扩散

HippoRAG 分成离线索引和在线检索两部分。

• 离线阶段：系统用 LLM 做开放信息抽取，把 passage 转成没有预设 schema 的知识图谱三元组；再由稠密检索编码器把意思接近、写法不同的节点连起来。

• 在线阶段：系统先从问题中抽取命名实体，把它们链接到图节点，再以这些节点为起点运行 Personalized PageRank。概率沿着图进行传播，系统据此找到同时靠近多个查询线索的节点和原始 passage。

图 2：论文 Figure 2 展示 LLM、检索编码器、知识图谱与 Personalized PageRank 的分工。来源：论文第 4 页。

论文用大脑皮层、海马旁区和海马体来组织这个架构比喻：LLM 负责抽取，检索编码器负责连接，知识图谱加 PageRank 负责关联召回。这种解说的方法确实容易让大家记住，但也必须说清楚一个边界：HippoRAG 借鉴的是一种记忆索引理论，但他依然是一种数据处理方法的实现，绝对无法等同于人类的大脑。

一次走出多跳关系

很多多跳 RAG 会先检索一次，让模型生成中间问题，再检索下一次。这样能逐步追踪线索，但每一步都有可能跑偏，也会增加延迟和调用成本。HippoRAG 尝试在已经构好的图上运行一次 Personalized PageRank，让多个查询节点周围的关联共同被激活。论文在 MuSiQue、2WikiMultiHopQA 和 HotpotQA 的各 1000 个验证问题上比较了多种方法。

图 3：论文 Table 2 的单步检索结果。来源：论文第 6 页。

在 2WikiMultiHopQA 上，论文报告 HippoRAG 相比强基线的 R@2 和 R@5 分别提高约 11 和 20 个点；在 MuSiQue 上提升较小；在知识整合要求较弱的 HotpotQA 上，它没有全面胜出。从这个结果上可以看出：图的方法是否有优势，取决于任务是否真的需要跨文档关联，而不是“加一张图，所有检索都会更好”。

论文还指出，单步 HippoRAG 可以达到与迭代检索 IRCoT 相当或更好的表现，同时在线检索更便宜、更快。但这些成本和速度会受到模型、硬件、数据规模与实现影响，不能直接变成结论。

图也会把错误连起来

HippoRAG 的图不是人工精修的知识库，而是 LLM 用 OpenIE 从文档中自动抽取出来的。构图更快，错误也会一起进入图。这也是我一直强调的 AI 工具出错，数据治理中 AI 可以是强而有力的辅助，但使用者永远是第一责任人。

论文对 MuSiQue 中 100 个错误做了小规模分析：48% 归因于 NER 限制，28% 来自错误或缺失的 OpenIE，24% 与 PPR 图搜索有关。这个分析不能代表所有场景，却把系统的脆弱点放得很清楚。关键上下文可能没有被 NER 抽出来；关系抽取也可能弄错主客体；图里的相似概念太多时，PageRank 也会被干扰。

向量 RAG 的问题是“相似但不一定相关”，图 RAG 则多了一层风险：“内容是连起来了，但也可能连错了”。所以我们不能把知识图谱当成给准确性“兜底”的免费午餐。它只是把错误从一个相似度分数，变成可以检查的节点、边和路径。能检查，是治理的开始，不是治理的结束。

对 Cortrix 的设计提醒：长期记忆不应只是一堆孤立 chunk

在 Cortrix 的设计思考里，我们关注的是面向检索、记忆和 API 驱动 AI Agent 的 semantic storage 问题。公开项目可见于 https://github.com/cortrix/cortrix 。

HippoRAG 给我们的启发是：如果一个 block 永远只是独立的向量，Agent 将很难稳定地跨文档积累关系。但系统一旦决定引入图，就必须回答更具体的问题：节点身份如何保持自己的稳定性，关系从哪里来，错误的边需要怎样撤销，等等……。

读完这篇论文，我们不需要把所有数据都强行变成知识图谱，也不该把 PageRank 写成长期记忆的唯一答案。更现实的设计是让精确标识、全文检索、向量召回和关系结构各做擅长的事，并保留足够清楚的来源与边界。

《Semantic经典论文》第一阶段回顾：技术在变，问题没有变

【DBpedia】 在 2007 年追问“机器怎样知道我们谈的是同一件事”；【TransE】 让关系进入向量空间；【RAG】 把外部知识接回生成；【Reflexion】 把失败写成经验；HippoRAG 再用图把分散经验连接起来。

五篇论文跨了 17 年，看起来从 Semantic Web 一路走到 AI Agent，底下却一直在追同一个问题：怎样让机器保存、找到、连接并核对它真正需要的上下文？