三种AI记忆架构对决：上下文图的关系优势与token效率

核心概览

• 该系统最初并非为了构建新的内存架构，而是为了解决多代理系统中跨代理决策遗忘的问题，基准测试是后续补充的验证环节。
• 多代理系统出现跨代理决策丢失的问题，根源在于纯文本会话和向量搜索都存在结构性盲区，而非仅仅是噪声干扰问题。
• 上下文图将事实以实体和关系的形式存储，而非独立文本块，因此可以回答需要结合两个独立事实的关联查询。
• 该项目并非概念验证：共测试了三种内存架构、五个脚本化场景、18个分级查询，全程确定性行为，未使用任何大语言模型调用。
• 测试数据显示：上下文图的准确率为88.9%，单查询平均token数为26.9；原始历史转储准确率为61.1%，单查询平均token数为490.9；纯向量RAG准确率为50.0%，单查询平均token数为75.9。
• 开发过程中发现了两个真实bug：陈旧事实检索问题和实体匹配缺口，相关细节已在文中说明。

触发研发的核心问题

研究人员最初开发的三代理管道在短任务中表现良好，但当对话变长，代理需要回忆过往决策时，系统就会彻底失效。

具体失效场景如下：规划代理会决定项目使用PostgreSQL作为存储技术，之后经过多轮无关对话，最终审核代理会询问当前使用的存储技术是什么。即便完整的原始会话记录都在上下文窗口中，代理依然无法可靠地给出答案。

研究人员最初认为这是大语言模型的能力局限，但后续验证发现，这本质上是内存架构的问题，根据修复方案的不同，通常会引发两种严重的问题。

向量搜索的结构性陷阱

如果使用向量搜索来修复遗忘问题，虽然可以解决噪声干扰的问题，但会立刻引入新的缺陷。向量存储只会检索与查询语义相似的文本块，无法获取事实之间的关联关系。

如果一个关键决策存储在一个文本块中，而该决策的关键依赖说明存储在另一个文本块中，无论嵌入模型的效果有多好，相似性搜索都无法将两者结合起来获取完整信息。

无论是纯文本会话还是向量搜索，都存在不同的结构性上限。研究人员没有选择猜测哪种折中方案“足够好用”，而是决定对两种方案进行量化测试。

问题的核心本质

需要明确的是，本文讨论的并非令牌压缩问题，也不是事实陈旧问题，而是结构性检索问题。有些查询只能通过结合两个独立陈述的事实才能得到答案，而无论是扩展上下文窗口还是向量索引，都没有原生机制来完成这种关联查询。这与此前讨论过的失效模式完全不同，因此需要专门的基准测试来验证。

基准测试的搭建方案

为了验证该问题，研究人员搭建了五个确定性行为的场景，包含18个分级查询，并让三种内存架构在完全相同的会话场景下进行测试。

所有测试结果均来自该基准测试的实际运行，运行环境为：

• 运行环境：Python 3.12，仅使用CPU（无需GPU支持）
• API调用：无任何大语言模型调用
• 一致性：在两台独立的机器上运行结果完全一致

完整的实现代码和测试脚本可以在公开仓库获取：https://github.com/example/context-graph-benchmark/

上下文图的核心概念

传统的扁平内存存储（无论是原始聊天记录还是向量索引）都会将每一轮对话视为独立的文本单元，检索时只会寻找与查询最匹配的单元。

而上下文图则完全改变了底层存储结构，将内存视为带有类型化关系的独立实体集合，例如：

• 认证模块 ——> 依赖于 ——> 限流模块
• 实现代理 ——> 负责分配到 ——> 认证模块

在这种模型中，检索过程不再是简单匹配关键词或语义向量，而是通过遍历这些实体之间的关系来获取信息。

这种结构性差异仅在一类特定查询中体现出优势：需要结合两个独立陈述事实的查询。例如类似“负责X所选服务的组件所属的团队是哪个？”的问题，在原始会话记录中不存在单独包含答案的文本块，答案仅存在于多个事实构成的关联路径中。扁平存储无法动态构建这种路径，而上下文图可以轻松完成遍历。

该方案的适用场景

如果你的系统运行多代理管道，且不同代理的决策需要在多轮对话后被其他代理准确检索到，那么这种方案值得开发。它专门为那些需要频繁结合多个独立陈述事实进行查询的系统，或是长会话代理系统设计——这类系统中重复发送完整历史记录的令牌成本已经成为显著的开销项。

以下场景则不适合使用该方案：单代理单轮对话任务（不存在跨代理状态丢失的问题）；所有查询都是单事实查找且无需关联的场景（纯向量RAG可以以更低的工程成本实现大部分准确率）；团队无法容忍额外的复杂性组件的场景（上下文图需要实体提取步骤，在基准测试中是基于规则的，生产环境则需要大语言模型调用，而扁平存储无需该步骤）。

如果你的多代理系统仅需一次交互即可完成任务，那么普通的上下文传递就足够了。该问题仅在对话变长、决策需要在创建后的多轮对话中保留时才会显现。

三种内存架构的对比

基准测试中未使用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</code></pre>

该架构的成本模型与生产环境完全一致：每次查询都需要重新发送不断增长的完整会话历史。