RAG 记忆系统中时序变更如何破坏 Agent 的逻辑推理？

在 Agent 向记忆系统询问「生产库用的啥」时，接口返回的两条记录分别是 PostgreSQL（分数 0.94）和 MongoDB（分数 0.91）。按传统 RAG 模式，Agent 仅凭语义相似度选择 PostgreSQL，结果却发现四个月前架构组已经替换为 MongoDB。问题出在 记录间的时序关系被忽略了。

存储层存储的数据库版本变更实际上是双时态建模，SQL:2011 标准早已支持通过时间戳和版本表记录。然而，现有记忆 API 仅返回独立记录列表，没有提供 “当前生效记录”与“被替代记录”之间的关系链，导致 Agent 无法区分“当时的真实”和“现在的假象”。 Edward Izgorodin 在数据库领域指出，“这件事当时是真的、现在已经是假的”问题已十多年未解决，覆盖式更新仍是常见问题。

更复杂的例子来自业务规则变更：记录 A 表示“客户退款需经理审批”，而记录 B 为“100 美元以下退款免审”。在存储层看起来是更新，但在业务逻辑中可能是政策调整、地区差异或纠错。如果将这两条记录压平为权重相同的列表，Agent 无法判断哪条是“当前有效”的，哪条是“过时的”，从而误判决策。这种设计背后的危险假设是：语义相似度等同于当前真实度，但在 Agent 决策中，过时记录的“伪相关”会直接导致错误。

如何从扁平列表升级为图谱结构？

在实际应用中，我将检索接口改为返回「事实图谱片段」，避免扁平列表的局限：

{
  "current_fact": "MongoDB",
  "valid_from": "2026-04-15",
  "supersedes": {
    "fact": "PostgreSQL",
    "valid_until": "2026-04-14",
    "reason": "architecture_decision_2026_q2"
  },
  "confidence": 0.97
}

这样，Agent 可以清晰链接：

1. 当前生效的事实是什么？
2. 为什么被替代？
3. 如果中间存在多阶段变更（如“先用 TiDB 过渡”），图谱也能完整展示。

成本与风险平衡：

构建图谱片段需增加写入时的元数据声明（如 valid_from、valid_until、supersedes），并维护冲突与合并逻辑。但与 Agent 在生产环境中因过时记录导致错误决策相比，工程成本并不高。关键是 Agent 正确率，而不是传统 RAG 中的 Recall@K。

建议步骤：

1. 检查存储层是否仍采用覆盖式更新，补全时间戳字段。
2. 检索接口尝试返回带边的子图（如增加 supersedes 字段）。
3. 对高频决策 Agent 物化当前生效视图缓存，避免每次重新遍历图。