AI记忆纠错反被旧错误引用：图数据库如何修复溯源

给AI智能体纠正记忆错误，本以为大功告成——直到它拿着你刚改正的结论，引用那条原始错误作为证据，并以置信度1.0信誓旦旦地告诉你：“这次肯定没错。”这是开发者Vaibhav在WeMakeDevs Graph Hacks黑客松上构建Afterhack项目时遇到的真实困境，也是绝大多数智能体记忆演示中从未展示的一面。

为什么向量检索救不了“纠错”

常见的智能体记忆方案是分块、嵌入、按相似度检索。这种方式用于查找信息没有问题，但它无法回答一个关键问题：“如果这个事实错了，还有哪些东西跟着错？”

原因在于，相似度不等于依赖关系。两个文本块可能都在谈论同一次产品发布，但其中一个未必是另一个成立的理由。Vaibhav需要的是一条清晰的“因为”链条：

Source ──▶ Fragment ──▶ Claim ──▶ Decision ──▶ Action
                          ▲
                      Correction
         (everything to the right of it might now be wrong)

一旦把问题写成这样，“这条错误事实影响了什么”就从搜索问题变成了图遍历问题。这正是他选择FalkorDB的原因——每个工作区使用一张独立的图，图名由服务端生成的UUID派生，请求无法自行指定要访问的图，从隔离层面杜绝越权。

图数据库与向量数据库的核心差异在于数据模型与查询范式。向量数据库将文本编码为高维向量，通过近似最近邻搜索（ANN）返回语义相似的条目，擅长“找相似”，但无法表达条目之间的有向关系。图数据库则以节点和边存储实体及其关联，支持多跳遍历、路径查询和模式匹配（如 Cypher 的 MATCH、-[:REL]->），能精确回答“哪些节点依赖此节点”这类溯源问题。在本场景中，“声明→决策→动作”构成一条有向依赖链，纠错需要沿链传播影响，这正是图遍历的强项；而向量检索只能返回“与错误声明相似的文本”，无法区分相似与依赖，因此无法完成失效传播。

规则先行：没有精确引用就不算证据

在考虑纠错之前，首先要保证存入记忆的每条声明都可信。为此，提取环节设了一条硬规则：模型必须为每条声明返回一个evidence_quote，且API会校验该引用是源文档的精确子串，必须逐字符匹配。

模型如果改写了原文，丢弃；如果编造了引用，丢弃。通过校验的声明会连同起止偏移量一起存储，界面可以精确高亮这句话来自原文的哪几个字。

这条规则很粗暴，会误伤一些技术上说得通的声明。但作者对此很坦然：一个偶尔健忘的记忆系统让人烦躁，一个自信编造的记忆系统则可怕得多。

精确子串匹配（exact substring match）是一种严格的证据校验方式：要求模型输出的引用文本与源文档中的某段字符完全一致，包括空格、标点和大小写。与模糊匹配或语义相似度不同，精确匹配无法被“意思相近但措辞不同”的改写所满足，因此能有效拦截模型凭记忆复述或润色原文的行为。实现上通常使用字符串查找（如 Python 的 in 或 str.find）并记录匹配起始偏移量，从而支持界面高亮定位。代价是召回率偏低——一些语义正确但措辞被调整的声明会被误判为无效。这种“宁可错杀”的设计把证据可靠性置于覆盖率之上，适合对事实准确性要求高的记忆系统。

搜索命中不等于证据：用代码堵住模型的偷懒

智能体一侧由两个角色分工、两次模型调用构成。Analyst拥有搜索声明、拉取原始片段的能力，它把提案交给Coordinator，后者审核并撰写决策草稿。

首次实测暴露了两个问题。其一，Analyst像人用谷歌一样搜索整句（如“launch date for the product”），而Cypher查询用的是CONTAINS，自然一无所获，智能体便断定“没有证据”。为此加了回退策略：整句未命中就拆成实词并剔除停用词再搜。

其二更严重：Analyst有时搜到了声明，却跳过了拉取源片段的步骤，直接基于声明ID下结论。作者因此写下了项目的座右铭：“搜索命中本身不是证据”，并在代码层面强制执行：

allowed_ids = searched_claim_ids & retrieved_claim_ids
claim_ids = [str(i) for i in proposal.get("claim_ids", []) if str(i) in allowed_ids]

Coordinator只能引用本次运行中既被搜索到、又被拉取过源片段的声明。它既不能编造ID，也不能复用记忆中的旧ID。如果过滤后无一幸存，决策会被标记为needs_review，标题为“No source-backed answer yet”，且不产生任何动作。

作者用一个刻意模糊的提示词在无相关证据的工作区测试，智能体诚实地回答“不知道”，并将这条轨迹连同交接记录存入图数据库。这反而成了他整个周末最满意的结果。

Cypher 中的 CONTAINS 操作符执行的是区分大小写的子串包含判断，而非全文检索或语义搜索。当 Analyst 把整句自然语言（如“launch date for the product”）直接作为 CONTAINS 的参数时，要求图中某条声明的文本完整包含该整句，这在实际数据中几乎不可能命中。回退策略的本质是查询改写：将整句拆分为实词、剔除停用词（如“for”“the”），再以多个 CONTAINS 条件或分词后的关键词逐一匹配。这暴露了 LLM 生成查询与数据库查询语言之间的语义鸿沟——模型按人类搜索习惯构造输入，数据库按精确字符串规则执行，二者不匹配时需要显式的适配层。

“哦……”时刻：纠错继承了错误的证据

纠错流程本应是这样的：审核者输入更正后的陈述，Preview展示依赖该声明的决策和动作，Apply把旧声明标记为superseded，创建带SUPERSEDES关系的新声明，并更新受影响的决策。

功能做出来了，替换声明文本正确。但当作者查看这个新声明由什么支撑时，问题出现了——第一版代码把旧声明的证据直接复制到了新声明上：

CREATE (replacement:Claim {
  statement: $statement,
  evidence_quote: old.evidence_quote,  -- 👀
  confidence: 1.0,
  ...
})
CREATE (replacement)-[:SUPPORTED_BY {role:'correction_context'}]->(f)  -- the OLD fragment

于是，替换声明声称“七月”，却指向一份写着“六月”的文档作为证明，且置信度拉满。后续智能体检索时，找到这条“已更正”的声明，拉取其“来源”，然后把原始错误当作修复依据引用回来。每一步都在忠实执行指令，图数据库只是忠实地保留了一条说谎的链接。

修正方案是把纠错本身当作新的证据来源：

CREATE (f:SourceFragment {
  text: $statement,
  origin_type: 'human_correction',
  origin_name: 'Workspace reviewer correction'
})
CREATE (corr)-[:HAS_FRAGMENT]->(f)
CREATE (replacement:Claim {
  statement: $statement,
  evidence_quote: $statement,
  confidence: 0.0,
  confidence_kind: 'human_correction',
  ...
})
CREATE (replacement)-[:SUPPORTED_BY {role:'reviewer_correction'}]->(f)

纠错现在会创建归属于Correction节点、标明人工来源的独立片段，替换声明引用的是这个片段。置信度从0.0起步，并带上明确的confidence_kind——审核者手打的句子和模型匹配引文的置信度不是一回事，作者不愿让一个数字假装同时表达两者。

SUPERSEDES 关系在图模型中表示版本替代：新节点通过该边指向被取代的旧节点，旧节点保留但标记为 superseded，从而维持完整的历史链而非物理删除。这种设计支持时间旅行查询（“在某次纠错之前，系统依据什么做决策”）和审计溯源。关键在于，SUPERSEDES 只表达“谁替代了谁”，不自动传递证据关系——新声明必须通过独立的 SUPPORTED_BY 边指向自己的证据片段。若实现时误将旧声明的证据边复制给新声明，就会形成“新陈述 + 旧证据”的错误组合，而图数据库不会主动检测这种语义矛盾，因为它在结构上完全合法。

关联不等于失效：别让警报变成狼来了

修好证据问题后又暴露了第二个错误。最初的传播规则很粗暴：只要决策用到了被更正声明就标记needs_review，依赖该决策的动作标记held。

这会导致误报泛滥。设想一个决策由三条声明支撑，其中一条被更正，另外两条依然充分支持它。标记它就像烤面包时烟雾报警器响个不停，第三次之后没人会再看。

修正后的逻辑是：只有决策失去最后一条支撑声明时才标记复核，只有依赖这些决策的动作才被挂起。

当测试库是假的，测的是你的假设

第一版传播逻辑本是一条优雅的查询，用NOT EXISTS { ... }子查询一次性找出“没有其他支撑声明”的决策。单元测试通过了——因为测试用的是假对象，根本没跑过真正的Cypher。

真实纠错测试直接返回HTTP 500。FalkorDB不支持这种子查询形式。作者只能拆成多条有界、只读、FalkorDB确定支持的查询，完整实测流程才通过。他的结论很直接：测试替身测的是你对数据库的假设，只有连真库的测试才能抓住这类bug。

并发与原子性的取舍

纠错会改变共享状态，必须处理并发问题。工作区和每条声明都带revision号，Preview返回所见版本，Apply必须带回来，只有版本仍匹配写入才生效。若期间有变更，返回409 stale_correction_preview；若同一纠错已应用，则返回现有替换声明并标注already_applied，同时重跑依赖检查以防首次尝试中途崩溃。

作者也坦白了一个取舍：纠错加修复涉及多次FalkorDB调用，并非单个原子事务。如果进程在“标记声明被取代”和“挂起动作”之间崩溃，可能留下部分状态，重试可以清理，但这是恢复路径而非保证。

把数据库藏起来不给用户看

最后一个发现与AI无关。最初把完整图渲染到界面时，Workspace、SourceVersion、SourceFragment、AuditEvent、AgentRun、Handoff满天飞，像犯罪现场证据板——技术上准确，对问“这个事实错了会怎样”的人毫无用处。

后端因此改为返回产品级视图：Sources → Claims → Decisions → Actions，外加Corrections，关系名也换成SUPPORTS这类可读词。底层结构仍存在FalkorDB中用于溯源，用户不必读那些管道。作者借此点出：图可视化的难点在于决定不显示什么。

当前局限与核心经验

项目仍有多处未竟之处：实测中Coordinator从未真正提出动作，“挂起动作”只在存储层测试中验证过；“替代支撑”仅指至少一条其他当前声明，未追问其是否来自独立来源，也不追踪多级链条；每个源只有单一片段，尚未分块；修复过程非原子。

作者给周五晚上的自己四条经验：纠错是证据而非编辑，若让修复继承错误的溯源，错误从未真正离开，只是换了个标题；证据要在代码里强制，而非在提示词里请求，“请只引用检索到的证据”是请求，searched & retrieved是规则；关联不等于失效，标记一切只会让人学会忽略标记；把东西打印出来——表头bug、NOT EXISTS的500错误、复制的引用，每一次都是他假设了某物的样子而没真正去看。

这个项目最终想说的是：智能体记忆的有趣之处不在于记住，而在于记错之后发生了什么，以及有多少东西已经基于那个错误行动了。