为什么长期记忆必须能解释答案：带证据链的 why/how 召回
摘要
真正能进入生产环境的长期记忆系统，不能只给出答案，还必须解释答案从哪里来。
尤其是 why/how 查询，答案往往不是来自一条相似文本，而是来自多个主体、多个 memory 和多条关系链。没有 citation、observation trace 和 memory edge，系统很容易生成“像是对的”答案，却无法审计、无法调试、无法信任。
InsightMemory 的目标是让 recall 从 similarity recall 升级为 evidence-backed recall：不仅召回相关内容，还召回支撑答案的证据和关系。
正文
很多 LLM 应用在接入 memory 后，会遇到一个尴尬问题：系统能回答，但回答为什么是对的说不清。
短期 demo 里，这个问题不明显。用户问一个事实，系统找回几段相似文本，然后生成一个看起来合理的答案。
但在真实产品里，只“看起来合理”是不够的。
企业 Copilot、研究助手、自动化 Agent、投资分析工具和知识管理系统都需要知道：
- 这个答案来自哪条原始输入；
- 哪些记忆支撑了这个结论；
- 有没有历史版本或冲突信息；
- 为什么一个外部规则会影响当前主体；
- 如果答案错了，应该从哪里调试。
这就是为什么长期记忆必须带证据链。
没有证据链的 memory，很容易成为另一个幻觉入口。它让模型看起来更有上下文，但也可能把错误上下文包装成更自信的答案。
why/how 查询和普通事实查询不一样
普通事实查询可能只需要回答“是什么”。比如：
Atlas rollout 当前主阻塞是什么？
但 why/how 查询通常需要跨越多条 memory：
为什么 Billing service 还不能切换到新模板？
合理答案可能来自两类信息：
- Billing service 自己的 blocker：税率模板校验流程没有补齐；
- 外部 checklist 的 requirement：切换前必须完成税率模板校验流程。
如果系统只按相似度召回，很可能只找到 blocker，却找不到支撑它的外部 requirement。
这个答案不一定完全错，但它是不完整的。它缺少“为什么这个 blocker 足以阻止切换”的外部约束，也缺少可追溯的 supporting observation。
需要关系，不只是相似度
InsightMemory 里有一个关键对象：edge。
edge 用来表达 memory 之间的关系，例如：
support：一条 memory 支撑另一条 memory；update：一条 memory 更新另一条 memory；conflict：两条 memory 存在冲突；derivation：一条 memory 从另一条推导出来；related：两条 memory 对回答同一问题有相关上下文。
有了这些关系，召回就不只是 top-k similarity，而是可以从目标主体的 key memories 出发，沿着有价值的 edge 扩展上下文。
这一步非常关键。它让 recall 不再只是“相似文本堆叠”，而是变成“从目标主体出发，沿着关系链路组织证据”。
普通 RAG 更像搜索引擎，InsightMemory 想把 recall 做成可解释的记忆推理过程。
citation 的价值
citation 不只是给用户看的引用。它还对开发者很重要。
当答案出错时，citation 可以帮助定位：
- 是 entity resolution 错了；
- 是 memory extraction 错了；
- 是 edge 构建错了；
- 是 recall path 错了；
- 还是最终 answer synthesis 错了。
如果系统没有 citation，调试只能靠猜。
对于企业场景，citation 还有审计意义。用户可以知道答案是否来自真实输入，而不是模型补全出来的幻觉。
这也是 memory 系统能否进入严肃场景的分水岭。个人 demo 可以接受“差不多对”，但企业 Copilot、研究助手、投研系统和自动化 Agent 必须知道答案的来源。
一个真实评测里的最小例子
写入：
Billing service 当前还不能切换到新模板，因为税率模板校验流程没有补齐。
Tax template checklist 明确要求切换前必须完成税率模板校验流程。
查询：
为什么 Billing service 还不能切换到新模板？
一个好的 memory 系统不应该只回答第一句话。它还应该把 checklist requirement 带出来，并说明这个 requirement 是支撑原因的一部分。
更进一步，系统应该返回 supporting observation，让开发者能追溯答案来源。
这个例子的价值不在于答案更长，而在于答案更完整：它把 blocker 和 supporting requirement 一起带出来，并且保留了回到原始证据的路径。
这个 why/how 案例也来自真实评测
上面的 Billing service 例子来自仓库里的真实评测用例 cross_entity_document_requirement_why_query。
评测写入：
Billing service 当前还不能切换到新模板，因为税率模板校验流程没有补齐。
Tax template checklist 明确要求切换前必须完成税率模板校验流程。
评测查询：
为什么 Billing service 还不能切换到新模板？
这个 case 的 expected state 要求系统形成 2 个 entity、2 条 memory、2 条 observation，并且出现 1 条 supports edge。也就是说，Tax template checklist 不是主 entity，但它必须作为外部 requirement 支撑 Billing service 的 why answer。
这个 case 在多个报告里跑通过，例如 scheduler_throughput_full_v1_noise、semantic_tail_matrix_v3_noise 和 failed_suites_repairskip_mergeprio_v1_noise。它验证的不是“能不能回答 blocker”，而是“能不能把外部 checklist 的要求作为证据链的一部分带出来”。
evidence-backed recall 的工程意义
如果 memory 系统只返回最终答案，它很难进入严肃场景。
因为用户无法判断答案是否可靠，开发者也无法判断系统哪里错了。
而 evidence-backed recall 提供了三个能力：
- 可审计：答案可以回到原始 observation；
- 可调试：错误可以沿 extraction、relation、recall、synthesis 链路定位；
- 可演进：新证据可以更新、补充、冲突或支持旧 memory。
这三个能力，是 AI 应用从 demo 走向生产环境的关键。
InsightMemory 的召回目标
InsightMemory 的 recall 目标是生成 grounded answer，而不是只返回相似片段。
一次召回大致包含这些步骤：
- 解析用户查询中的目标 entity；
- 从目标 entity 的 memory 中找到 key memories；
- 根据问题类型扩展相关 memory edge；
- 拉取 supporting observations；
- 生成带 citation 的答案；
- 返回不确定性或缺失信息。
这个过程的核心是：答案必须能回到证据。
这也是 InsightMemory 和普通“检索片段 + 生成答案”最大的差异之一。它不仅关心召回内容是否相关，还关心答案是否能被证据支撑、是否能被调试、是否能在新证据到来后演进。
小结
长期记忆系统不应该只是“帮模型想起来一点上下文”。它应该让模型能解释为什么这样回答。
没有证据链，memory 很容易变成另一个幻觉来源。有了 citation、observation 和 memory edge，系统才更适合真实 Agent、企业知识库和需要审计的 AI 应用。
InsightMemory 的设计重点之一，就是让 AI 的长期记忆不仅能召回，还能追溯。
它想做的不是一个更会找文本的组件，而是一层让 AI 记忆可以被信任、被审计、被持续改进的基础设施。
GitHub: https://github.com/MarvekW/InsightMemory
如果你关注 Agent memory、企业 Copilot、知识库或可审计 AI，欢迎试用 InsightMemory。项目仍在快速迭代中，也欢迎提供 LLM API-KEY、调用额度或真实业务 case，帮助继续完善 evidence-backed recall。
