Vector RAG Isn’t Enough — I Built a Context Graph Layer for Multi-Agent Memory

Vector RAG 不足以应对 —— 我为多智能体记忆构建了一个上下文图层 | Towards Data Science

大型语言模型

Vector RAG 不足以应对 —— 我为多智能体记忆构建了一个上下文图层

在相同的多智能体对话中，结构化的上下文图层击败了扁平的聊天记录和仅使用向量的 RAG 管道 —— 完整的可运行代码、真实的基准数据、零 API 调用

Emmimal P Alexander

2026 年 6 月 25 日

19 分钟阅读时间

分享

作者生成的图片，使用 ChatGPT（DALL·E）

TL;DR

• 我并不是试图构建一种新的记忆架构。我是在尝试理解为什么一个智能体会忘记另一个智能体做出的决定。基准测试是在之后才进行的。

• 多智能体系统会因为扁平的对话记录和向量搜索都存在结构性的盲点而丢失跨智能体的决策 —— 这不仅仅是噪音问题。

• 上下文图层将事实存储为实体和关系，而不是文本块，因此它可以回答需要结合两个事实的问题。

• 这不是一个概念。三种记忆架构、五个脚本场景、18 个分级查询、完全确定性、零 LLM 调用。

• 上下文图层：每个查询 26.9 个标记，准确率为 88.9%。原始历史记录：每个查询 490.9 个标记，准确率为 61.1%。仅使用向量的 RAG：每个查询 75.9 个标记，准确率为 50.0%。

• 在构建这个系统时，我发现了两个真实的问题：过时事实的检索和实体匹配的差距。这两个问题都在文章中有所描述。

让我构建这个系统的那个问题

我构建了一个三智能体的管道，对于简短的任务表现很好。但一旦对话持续下去，某个智能体需要回忆过去的决定时，整个系统就会崩溃。

它就是这样崩溃的：Agent_Planner 决定项目应使用 PostgreSQL。然后，经过二十轮“听起来不错”和“我会处理”的对话。最终，Agent_Reviewer 会提出问题，询问我们使用的是哪种存储技术。即使整个原始对话记录就在上下文窗口中，智能体也无法可靠地回答。

我是在 EmiTechLogic 作为副项目本地运行这个管道，只是为了看看在多智能体协调遇到瓶颈之前，我能够将它推进到多远。结果是，它并没有持续太久。

最初，我假设这只是模型的限制。但事实并非如此。这是一个记忆架构问题，通常会触发两种巨大的头痛问题，具体取决于你如何尝试解决它。

替代解决方案：向量搜索和关系陷阱

如果你切换到向量搜索，你解决了噪音问题，但会立即产生另一个问题。向量存储会检索与查询相似的块；它不会检索事实之间的关系。

如果一个关键决策在一个块中，而关于该决策的一个关键依赖说明在另一个块中，相似性搜索无法将它们结合起来 —— 无论你的嵌入模型有多好。

这两种方法都遇到了不同的结构性限制。而不是猜测哪种妥协是“足够好”的，我决定对它们两者进行测量。

这个问题实际上是什么

为了明确说明这篇文章不是什么：这不是一个标记压缩问题，也不是一个过时问题。这是一个结构性检索问题。有些问题只能通过结合两个单独陈述的事实来回答，而无论是不断增长的上下文窗口还是向量索引都没有机制可以做到这一点。这与我之前写过的失败模式完全不同，它需要不同的基准测试。

测试设置

为了测试这一点，我构建了五个确定性场景，包含 18 个分级查询，并将所有三种内存架构运行在完全相同的对话上。

以下所有结果都来自使用本地化设置运行该基准测试的真实运行结果：

• 环境：Python 3.12，仅使用 CPU（不需要 GPU）

• API 调用：零次

• 一致性：在两台独立的机器上完全一致地重现

代码仓库：你可以在以下链接找到完整的实现并自行运行测试：https://github.com/Emmimal/context-graph-benchmark/

此处“上下文图”含义

一个扁平的内存存储（无论是原始聊天记录还是向量索引）将每个回合视为一个独立的文本单元。要检索某些内容，只需找到与查询最匹配的单元。

上下文图则完全改变了底层结构。它将内存视为具有类型关系连接的不同实体：

• AuthModule —–> DEPENDS_ON —–> RateLimiter

• Agent_Implementer —–> ASSIGNED_TO —–> AuthModule

在这个模型中，检索意味着遍历这些关系，而不是仅仅匹配关键词或语义向量。

这种结构差异只对一类特定问题有影响：任何需要将两个单独陈述的事实结合起来的问题。

例如，考虑这样一个问题：“哪个团队拥有那个依赖于 X 所选服务的组件？”

原始对话历史中没有任何一个单一的答案块。答案并不存在于一块文本中。它只存在于多个事实之间的路径中。扁平存储无法实时构建这条路径。而图结构可以轻松地穿越这条路径。

适用对象

如果你运行的是多代理流水线，其中某个代理的决策需要在多个回合之后被另一个代理正确检索到，那么这种方法值得构建。它适用于系统中经常需要结合两个或多个单独陈述的事实，或任何长期运行的代理对话，其中重新发送历史记录的令牌成本正在成为一个实际的项目条目。

如果你的任务是单代理、单回合任务，那么可以跳过这种方法，因为没有跨代理的状态需要丢失。如果你的查询始终是单个事实的查找，没有连接操作，也可以跳过。向量 RAG 在这种情况下可以提供大部分准确性，而工程成本却只是其很小一部分。最后，如果你的团队对额外的移动部件没有容忍度，也可以跳过。图结构需要一个提取步骤（在本基准中是基于规则的，但在生产环境中需要 LLM 调用），而扁平存储可以避免这一步骤。

如果你的多代理系统在一个回合内完成其工作，普通的上下文传递就足够了。这个问题特别出现在对话持续时间较长且决策需要在它们被做出之后仍然存在的情况下。

三种架构

| 架构 | 存储内容 | 成本 | 优势 | |------|----------|------|------| | 原始历史记录 | 每个回合，原封不动 | 随着对话长度增长，每次查询都需要重新发送 | 没有额外的免费获取内容 | | 仅向量 RAG | 每个回合，嵌入（TF-IDF） | 每个查询扁平，丢失关系结构 | 查找语义相似的单个事实 | | 上下文图 | 网络图中的结构化三元组 | 每个查询扁平且小 | 需要结合两个事实的问题 |

为什么基准测试中没有 LLM 调用

我特意在基准测试的每个阶段都排除了 LLM 调用：没有用于提取的 LLM，没有用于回答查询的 LLM，也没有用于评分的 LLM。

如果使用真实的大型语言模型（LLM）来处理信息提取，基准测试将衡量LLM的差异性，而不是实际的架构差异。使用确定性、基于规则的替代方案可以确保每次运行都产生完全相同的数值。

在撰写本文时，我在两台不同的机器上独立运行了这个测试。输出结果逐字匹配，准确度保持到小数点后四位，令牌计数精确到整数。

构建一个不秘密偏袒图结构的基准测试

让图结构在基准测试中胜出的最简单方法是只向它提出干净且单一事实的问题。这并不能证明任何问题。为了保持测试的公平性，每个场景都遵循四个严格的规则：

• 干扰项多于事实：每个场景包含大量“听起来不错”、“我会检查”和“我这边没有障碍”的对话，远多于实际的具体决策。

• 查询跨越物理距离：一些查询是在事实陈述后立即提出的（直接），一些是在许多回合之后提出的（远距离），还有一些需要将两个独立的事实拼接起来（连接）。连接查询的一个例子是：“模块由Agent_Implementer拥有，它依赖于哪个组件？”

• 一些查询故意简单：直接的、单一事实的查询被特意包含，以确保扁平架构有公平的机会。

• 评分完全确定：基准测试使用子字符串匹配与手动编写的基准答案进行比对，而不是依赖于LLM评委。

@dataclass
class Turn:
    turn_id: int
    turn_type: TurnType          # FACT, DISTRACTOR, or QUERY
    speaker: str
    text: str
    subject: str | None = None    # structured triple, FACT turns only
    predicate: str | None = None
    object: str | None = None
    fact_id: str | None = None
    query_type: str | None = None # "direct", "distant", "join"
    required_fact_ids: tuple = ()
    ground_truth: str | None = None

该基准测试覆盖了五个不同领域的五个不同场景：软件规划、研究流程、事件响应、客户支持升级和数据流程。

在这五个场景中，共有18个查询，分为三个具体类别：

• 6个直接查询：在事实陈述后立即提出的查询。

• 7个远距离查询：在事实陈述后许多回合之后提出的查询。

• 5个连接查询：需要将两个独立陈述的事实结合起来才能得到答案的问题。

架构1：原始历史记录转储

每个回合都会被追加到一个扁平的转录本中，每次查询时整个转录本都会被重新发送。这正是你不特意设计记忆系统时默认得到的结果。

我构建这个架构是为了提供一个真正公平的基准。它能够获取完整的、完美的转录本，没有任何信息被隐藏。答案提取使用关键词重叠和轻微的词干提取，从最近的回合向后搜索。这种设置非常接近上下文填充提示通常如何权衡近期信息。

class RawHistoryDump:
    def ingest(self, turn: Turn) -> None:
        self.transcript.append(f"{turn.speaker}: {turn.text}")

    def answer_query(self, query_turn: Turn) -> tuple[str, int]:
        prompt = self._build_prompt(query_turn)   # the ENTIRE transcript
        tokens = count_tokens(prompt)
        answer = self._extract_answer(query_turn)
        return answer, tokens

成本模型与生产中看到的完全一致：每次查询都会重新发送整个不断增长的对话历史。

架构 2：仅向量 RAG

每次对话回合，无论是事实还是干扰信息，都会被嵌入并存储为一个块。真正的向量存储库无法提前知道哪些回合在之后会变得重要。在查询时，会检索出与查询最相似的前 K 个块。

我选择使用 TF-IDF 而不是神经嵌入 API，原因与我在其他地方避免调用 LLM 是一样的。TfidfVectorizer 没有随机状态，因此从构造上来说是确定性的。它也不是一个玩具替代方案。TF-IDF 是一种真实且用于生产 RAG 的稀疏检索方法，通常与密集嵌入结合使用，构成混合设置。

class VectorOnlyRAG:
    def _retrieve(self, query_text: str) -> list[str]:
        if not self.chunks:
            return []
        corpus = self.chunks + [query_text]
        vectorizer = TfidfVectorizer()
        matrix = vectorizer.fit_transform(corpus)
        sims = cosine_similarity(matrix[-1], matrix[:-1]).flatten()
        top_idx = sims.argsort()[::-1][:self.top_k]
        return [self.chunks[i] for i in top_idx if sims[i] > 0]

（实际实现中，会将 fit_transform 包裹在 try/except 块中，以处理查询中仅包含停用词这一罕见边缘情况。此处为节省空间省略了这部分，但代码库中包含该实现。）

结构上的限制依然清晰：一个连接查询需要结合两个不同的事实。当这些事实出现在两个不同的回合中时，没有任何一个块同时包含这两部分信息。没有任何嵌入模型可以单独解决这一限制。

架构 3：上下文图

事实以（主体，谓词，客体）三元组的形式写入 NetworkX 有向多重图中。干扰回合则完全不会被写入。这是该架构相较于其他两个架构的优势所在：在数据写入存储之前就对其进行过滤。

在生产环境中，该过滤步骤是通过一个 LLM 调用来执行实体提取。在本基准测试中，它是确定性的，因为场景设置已经标记了哪些回合是事实。我正在明确区分存储和检索架构本身所执行的操作，将提取过程作为已声明的假设保持不变。我并未声称可以免费解决提取问题。

class ContextGraph:
    def ingest(self, turn: Turn) -> None:
        if turn.subject is None:
            return  # 干扰回合不包含结构化三元组；不会被存储
        self.graph.add_node(turn.subject)
        self.graph.add_node(turn.object)
        self.graph.add_edge(turn.subject, turn.object,
                             predicate=turn.predicate, fact_id=turn.fact_id)

连接查询的遍历是真正执行工作的部分。它在图节点上执行两跳遍历，而不是搜索一个恰好包含两个事实的单一文本块。

def _answer_join(self, query_turn, mentioned):
    for entity in mentioned:
        out_edges, in_edges = self._edges_touching(entity)
        intermediates = [v for _, v, _ in out_edges] + [u for u, _, _ in in_edges]
        for intermediate in intermediates:
            further_out, _ = self._edges_touching(intermediate)
            for _, target, data in further_out:
                if target != entity:
                    # 按谓词相关性对候选对象进行评分
                    ...

这是在所有三种架构中搜索空间的差异：

原始历史和向量搜索检索文本。上下文图检索关系。通过遍历连接的实体，系统可以回答仅依赖相似性搜索可能遗漏的多跳问题。

我第一次运行时实际发生了什么

第一次完整运行，构建了所有三种架构，对上下文图的准确率评分是 0%。

我之所以包括这一点，是因为这是大多数“我构建了 X”帖子跳过的部分。我可以将场景改写得更友好，而不是调试代码。那样的话，我会得到一个伪造的结果。我选择追踪问题所在。

错误 1：实体词汇不匹配

图中的节点被命名为类似 Project_Alpha 或 AuthModule 的名称。而查询则是以代理实际会使用的措辞来写的，例如“这个项目”或“认证模块”。查询文本和节点名称之间的字面子字符串匹配完全找不到任何内容。

这正是人们批评向量搜索时提到的词汇不匹配问题。它只是在写入时而不是查询时影响图。

修复方法是使用一个小型别名表来代替真正的实体链接步骤，通常在生产环境中会通过 LLM 调用来处理。使用图并不能让你摆脱这个问题。它只是将问题从查询时的检索转移到写入时的解决。这是一个持续的工程成本，而不是一次性修复。

错误 2：以完全的信心返回过时的事实

这是我会在生产环境中部署这种模式时首先指出的问题。

一个场景中包含一个支持工单，其优先级一开始是“高”，在对话中途被重新分类为“关键”。当查询“当前的优先级是什么？”时，图返回了“高”——这个过时的值，并且与当前值一样具有完全相同的置信度。

原因很简单：我的第一个 ingest() 实现只是添加了每一个新的边，从不删除旧的边。图中存在两个来自同一节点的 HAS_PRIORITY 边。在迭代顺序中，先被访问到的边会赢得查找，完全忽略了哪个事实实际上是当前的。

# 错误
Ticket_4471 --HAS_PRIORITY--> "high"      # 首先声明
Ticket_4471 --HAS_PRIORITY--> "critical"  # 后续声明，覆盖了之前的
# 两个边同时存在；没有任何信息告诉图哪个是“现在”的

使用近期偏见进行搜索的平铺聊天记录通常只需向后扫描就能找到较新的提及。相比之下，一个没有时间模型的图会以相同的结构置信度返回任一事实，因为图本身并不知道关系已被替换，除非你明确告诉它。

这种失败模式比模糊搜索返回一个过时的片段更糟糕。图看起来完全权威，即使它完全错误。

修复方法：当新事实重申一个已有的（主体，谓词）对时，旧边在新边写入之前会被删除。

def ingest(self, turn: Turn) -> None:
    if turn.subject is None:
        return
    self.graph.add_node(turn.subject)
    self.graph.add_node(turn.object)

    stale_edges = [
        (u, v, k) for u, v, k, data in self.graph.edges(keys=True, data=True)
        if u == turn.subject and data.get("predicate") == turn.predicate
    ]
    for u, v, k in stale_edges:
        self.graph.remove_edge(u, v, key=k)

    self.graph.add_edge(turn.subject, turn.object,
                         predicate=turn.predicate, fact_id=turn.fact_id)

如果你要部署类似的东西，处理事实的覆盖是必不可少的。这是构建可靠记忆层和构建重大责任之间的分界线。

最终基准测试结果

五个场景，18个查询，完全确定性，可以在两台独立的机器上完全复现。

准确性

平均每个查询的令牌数

直接

遥远

连接

61.1%

490.9

66.7%

71.4%

40.0%

50.0%

75.9

57.1%

20.0%

88.9%

26.9

100%

85.7%

80.0%

上下文图在准确性方面表现优异，每个查询使用的令牌数约为原始转储的18分之一。这不是一种权衡，而是在两个方面都取得了胜利。

向量RAG的令牌成本也很低，并不是图的主要区别点。两种架构都检索固定数量的项目，因此无论对话长度如何，成本都保持低廉。图与向量RAG的区别在于连接列：80%对20%。这种差距是结构上的论据支持图——向量相似性没有原生的方式来结合两个单独陈述的事实。

原始转储的准确性达到了61.1%，这比我预期的要高，它确实配得上这个成绩。一个完美的无损转录，具有良好的关键词匹配，在单个事实查询上表现良好。但由于同样的结构原因，它在连接查询（40%）上表现不佳，只是令牌成本要高得多。

故意保留了一个限制：在数据管道场景中有两个查询失败，因为它们通过描述而不是名称来引用一个实体——“当前存在异常的数据集”而不是直接命名Upstream_Orders。修复这个问题需要对描述性短语进行真正的语义理解，而不仅仅是简单的别名匹配。将别名表扩展到涵盖我自己的测试查询意味着对基准进行过拟合，而不是真正代表一个限制，因此它仍然存在问题。如果您的生产查询倾向于使用描述性引用，请为基于LLM的解决步骤预算，而不是不断增长的静态别名表。

令牌成本如何随对话长度扩展

我最初的假设是，随着对话的增长，原始转储的令牌成本以O(N²)的比例扩展。我测量了它而不是假设它，因为将不准确的复杂性声明发送给一个会检查它的受众，是快速失去可信度的方式。

设置：一次陈述一个事实，随后是逐渐增加的填充回合（从10到800），然后是一个查询，询问那个事实。这将每个查询的令牌成本隔离为对话长度的纯函数，同时保持信息内容完全固定。

填充回合

原始转储令牌

向量RAG令牌

上下文图令牌

10

157

54

23

50

659

100

1,287

200

2,542

400

5,052

800

10,072

当对话长度增长80倍（从10到800回合）时，原始转储的令牌数量增长了64.15倍。同时，向量RAG和上下文图都增长了1.00倍——完全保持平稳。

原始转储的每个查询令牌数是O(N)，即与对话长度成线性关系，大约每个填充回合使用12.6个令牌。它不是二次的。只有当你在整个多查询对话中汇总成本时，O(N²)的说法才变得准确：Q个查询，每个查询都针对一个线性增长的转录，总成本大约为O(N.Q)。这是真正的数字，只是比“每个查询成本为O(N²)”更精确。

向量RAG和上下文图在每个查询上都保持平稳的O(1)，因为这两种架构无论对话多长，都只拉取固定数量的项目。

LLM中的令牌效率：将原始聊天转储的快速上下文窗口扩展与向量RAG和上下文图架构的平稳、可持续的令牌使用进行比较。

在投入生产之前我将标记的内容

在任何人将这种模式复制到实际应用之前，有几件事需要明确说明。

关于延迟：Vector RAG 实际上是这里最慢的架构，而不是图结构。它在每次查询调用时都会在整个语料库上重新拟合 TF-IDF，而不是维护一个增量索引。在所有五个场景中平均来看，图结构的查询回答耗时为 0.050 毫秒，而 Vector RAG 则为 1.764 毫秒。

在实际部署中，这个差距会缩小，因为你会缓存向量化器，而不是每次都从头开始重新拟合——基准测试测量的是默认行为，而不是最佳工程版本。图结构偶尔会飙升到 1.9 毫秒，完全是因为连接查询需要遍历多个候选路径才能进行评分。

关于别名表的实际作用：允许“认证模块”解析为 AuthModule 的实体别名表，是真实实体链接的一个硬编码替代方案。在生产环境中，这一步是调用 LLM 完成的。基准测试是确定性的，因为我是硬编码了预期的别名——这并不意味着词汇不匹配的问题对任意查询表达方式都已解决。这是一个真实且持续的成本，我正在指出它，而不是隐藏它。

关于标记估计：我使用了每标记约 4 个字符的启发式方法，而不是使用 tiktoken，因为 tiktoken 在首次使用时会从远程 URL 下载其 BPE 排名文件——这在构建没有网络依赖关系的基准测试中是一个隐藏的网络依赖项。该启发式方法在所有三种架构中都以相同的方式应用，因此不会在它们之间产生偏差，但绝对的标记数量只是近似值。

关于本基准测试未测试的内容：这里的干扰项是通用的闲聊，例如“我这边没有障碍”，“听起来不错”。真实的生产环境噪声在主题上与实际事实相近。我预计这三种架构在对抗性噪声下准确率都会下降，但我并未测量这一点，因此我不会声称优势仍然存在。

关于生产使用中缺失的内容：真实的实体提取（ingest() 接口已经接受结构化三元组，因此替换为基于 LLM 的提取器只是一个有限的更改）、增量向量索引、用于长期对话的图结构修剪（这些对话会无限累积实体），以及持久化存储。该仓库包含一个从 NetworkX 导出到 Neo4j 的路径，供需要持久性和并发多代理写入的任何人使用——但这只是一个可选步骤，而不是性能提升。进行这种转换的原因是事务保证和并发性，而不是原始查询速度。

这些数字实际上意味着什么

所有这些都不需要更大的模型或更长的上下文窗口。每一个结果都来自于信息表示方式的改变，而不是将多少数据塞入提示中。

如果你只从这篇文章中带走一个数字，那应该是连接查询的差距：80% 对比 20-40%。这才是结构化记忆的真实论点，而不是标记节省。

虽然标记节省是真实且可衡量的，但它是次要的。在本基准测试中，需要从对话中完全不同的部分获取两个事实的问题是图结构展现出最大优势的地方。这种差距在所有五个场景中都保持一致，而不仅仅是那些对图结构来说恰好容易的场景。

完整项目——包括五个场景、三种架构、将这些数字锁定为回归测试的测试套件，以及 Neo4j 导出路径——可在下方的仓库中找到。

完整源代码：https://github.com/Emmimal/context-graph-benchmark/

参考文献

[1] Liu, N. F., Lin, K., Hewitt, J., Paranjape, A., Bevilacqua, M., Petroni, F., & Liang, P. (2024). Lost in the Middle: How Language Models Use Long Contexts . Transactions of the Association for Computational Linguistics, 12 , 157–173. https://doi.org/10.1162/tacl_a_00638

[2] Zhang, W., Zhou, Y., Qu, H., & Li, H. (2026). Loosely-Structured Software: Engineering Context, Structure, and Evolution Entropy in Runtime-Rewired Multi-Agent Systems (arXiv:2603.15690). arXiv. https://arxiv.org/abs/2603.15690

[3] A. Kollegger, “Context Graphs & Agentic Decisions,” Neo4j Developer Blog, Jan. 31, 2026. [Online]. Available: https://medium.com/neo4j/context-graphs-agentic-decisions-9a125f22f411

[4] W. Lyon, “When Your Agents Share a Brain: Building Multi-Agent Memory with Neo4j,” Neo4j Developer Blog, Apr. 13, 2026. [Online]. Available: https://medium.com/neo4j/when-your-agents-share-a-brain-building-multi-agent-memory-with-neo4j-bac609f17b23

[5] Macklin, N., Zaim, Z., & Erdl, A. (2026). Context Graphs and AI Memory Across the Globe. Neo4j Developer Blog. https://medium.com/neo4j/context-graphs-and-ai-memory-across-the-globe-bb17e293df32

[6] NetworkX documentation. https://networkx.org/

[7] Scikit-learn Developers, “TfidfVectorizer,” Scikit-learn Documentation. [Online]. Available: https://scikit-learn.org/stable/modules/generated/sklearn.feature_extraction.text.TfidfVectorizer.html

[8] OpenAI. Counting tokens with tiktoken. https://github.com/openai/tiktoken

[9] Neo4j Python Driver documentation. https://neo4j.com/docs/api/python-driver/current/

披露

本文中所有代码均由我编写，属于原创作品，已在 Python 3.12（Windows，PyCharm）上开发和测试。基准数据来自链接仓库中代码的实际运行结果，可通过克隆仓库并运行 benchmark.py 和 measure_scaling.py 进行复现，除非文章明确指出某个数字是启发式估计值而非实际测量结果。我与本文中提到的任何工具、库或公司均无财务关系。

作者

查看 Emmimal P Alexander 的所有文章

人工智能

,

深入分析

Llm

多智能体系统

Rag

分享本文

• 在 Facebook 上分享

• 在 LinkedIn 上分享

• 在 X 上分享

Towards Data Science 是一个社区出版物。提交您的见解，以触达我们的全球读者并通过 TDS 作者支付计划获得报酬。

更新为您的实际提交 URL

为 TDS 写作

✦ 结束 CTA ✦