来源追溯和推导依赖，为什么要分开存？

标准回答

我把来源追溯和推导依赖分开，是因为它们回答的问题不同。来源追溯回答“这段内容从哪里来”，推导依赖回答“这个结论依赖什么才成立”。只有原文链接，不能完整表达后一种关系。

比如来源 A 说某功能只支持版本 3，系统结合设备信息得到结论 B：这台设备可以开启该功能。B 的文字可能没有直接引用 A，但它的正确性依赖 A。如果后来 A 被纠正，只更新 A 的文本，B 仍可能作为独立记忆被召回。

因此 EachOf 保存来源的语义版本、内容摘要，以及派生内容与依据之间的依赖关系。来源变化时，可以识别受影响的推导，让依赖旧依据的内容退出当前召回；缓存答案也要复核来源。这使纠错影响到后续使用，而不只是修改数据库中的一行文本。

这里最复杂的是多来源、多级推导。一个依据变化，并不总意味着结论必然错误，但也不能因为还有其他依据就默认有效。我会按推导策略判断是否需要隔离和重新计算。内容摘要可以帮助识别内容是否改变，语义影响范围仍然需要额外规则判断。

来源 A 说“功能仅支持版本 3”，结论 B 建议“当前设备可开启”。A 被纠正后，B 即使没有直接复制 A 的文字，也可能不再成立。

我会先看这个结论对各个依据的依赖方式。如果多个条件必须同时成立，一个失效就足以让结论暂时退出当前使用；如果多个来源只是独立佐证，剩余依据可能仍然足够。没有证明剩余依据足够时，保守做法是先隔离并重新计算。这里不能只按“还剩几个来源”决定，更不能把单来源规则直接套到所有多来源推导上。

覆盖原文只能改变原记录，无法自动找到已经根据它生成的其他结论，也无法让旧答案缓存知道自己过期了。此外，完全覆盖还会丢掉“当时为什么作出这个判断”的历史依据。所以我把当前有效内容与历史解释分开：当前查询不再使用旧依据，历史视图在权限允许时仍能追溯原来的版本和推导过程。

有来源 ID 不等于已有完整推导图；需要证明推导依赖在创建、更新与迁移时都被保留。