We Taught AI to Answer Questions. Who Taught It to Change Its Mind?

我们教会AI回答问题。谁教会它改变主意？| Towards Data Science

人工智能

我们教会AI回答问题。谁教会它改变主意？

当新证据推翻一个结论时，基于该结论的决策也会随之改变吗？我测试了六种更新策略，然后测试了本地模型。

Emmimal P Alexander

2026年10月31日

26分钟阅读

在Google上关注我们

分享

作者图片

航班取消会在旅行中引发连锁反应。酒店和出租车信息会更新，而牙医预约却保持不变。一个友好的机器人在一旁观察。100%到0.7%的卡片显示了文章的结论：那些能够从零开始正确回答的策略，在需要修改旧状态时却可能失败。

我经常看到AI系统在状态更新上失败。它们缓存了一个答案，接收到推翻该答案的数据后，仍然无法更新。我想找出背后的原因。

假设一个旅行机器人预订了航班、酒店和出租车。它标记旅行已确认。稍后航班被取消，机器人记录了取消信息。但它会取消出租车吗？会更新酒店信息吗？它知道牙医预约与当前情况无关，应该保持不变吗？

更新信念是困难的。系统需要修改某些事实，保留其他事实，并放弃旧的假设。在标准基准测试中得到一个正确答案，并不能证明系统真的具备这种能力。

我创建了RevisionTrace来进行测试。这是一个用于信念修正的Python基准测试。

它通过两种不同路径运行测试。第一种路径让系统提前获取所有最终数据，从零开始计算所有内容。第二种路径从基线状态开始，逐步输入实时更新，迫使系统即时适应。两者使用相同的规则和相同的真相数据。

我在300个案例中测试了六种策略。性能差距巨大。

策略

从零开始回答

修正现有状态

完全重新计算

100%

增量修正

基于历史的浅层更新

59%

基于历史的粘性状态

57%

基于历史的优先分支更新

29%

基于历史的激进刷新

0.7%

稍等。在查看数据之前，先添加一些背景信息。我亲自构建了这些测试策略。这里并没有对真实的LLM进行基准测试。我也不是说生产环境中的AI系统恰好失败了这么多。

真正的教训非常具体。一个代理可能在内存中拥有所有正确的数据。但当变量发生变化时，它仍可能无法更新旧结论。记住事实很容易，管理状态变化却很困难。

RevisionTrace测试了一个问题：当核心事实发生变化时，系统是否会更新相关逻辑？它是否会保留无关数据？

本文涵盖实验、我发现的错误以及修复方案。所有内容都基于标准Python实现。无需API密钥。无需模型调用。

你可以在GitHub上找到代码：https://github.com/Emmimal/revisiontrace/

简要关键发现

300个案例显示了以下结果。你可以在本文末尾运行代码自行验证这些数字。

• 计算 vs 更新：所有六种方法在从零开始时都获得了满分。但在更新旧状态时，准确率低至0.7%。

• 过期数据 vs 附带损害：保留旧数据和破坏有效数据是两种不同的错误。有三种方法未能更新多达65%需要修改的事实。另一种方法则破坏了58%本应保留的事实。

• 静默故障：错误隐藏在中间步骤中。三种方法在约五分之一的失败运行中得到了正确的最终输出。最终答案看似正常，但内部状态已崩溃。

• 一致但错误：一种策略无论如何打乱更新顺序，结果始终相同。它看起来完全稳定。但实际上只有75%的时间是正确的。

• 解决方案：该方法非常轻量。只需跟踪依赖关系。当变量发生变化时，将更新沿链式结构向下传递，直到值稳定。这种方法得分100%。它完成的工作量比完整重建少75%。

整个架构可以放入一张图表中。

相同证据，两条通向相同最终状态的路径。仅路径B依赖于历史。

信念修订基准测试比较了从零开始回答与修订存储结论的效果。路径A从最终证据推导出每个结论，以达到状态A。路径B从旧结论出发，应用证据更新并修订至状态B。然后由一个"神谕"检查每个状态是否正确。

关于语言模型中信念修订的研究现状

在编写任何代码之前，我检查了现有研究。人们已经从不同角度研究过这个问题。

Belief-R（Wilie等，2024）测试模型在新证据到来时是否会更新结论。作者测试了约30个模型。他们发现模型通常无法修订信念。他们还注意到一个权衡关系：成功更新的模型在不需要更新时更容易失败。这正是我稍后测量的附带损害。

知识编辑研究处理类似问题。MQuAKE（Zhong等，2023）在模型中编辑单个事实。然后提出依赖该变化的多步骤问题。模型很容易记住新事实。但它们在相关问题上表现非常差。

RippleEdits（Cohen等，2024）探索了相同的涟漪效应。这是一个包含约5000个事实编辑的诊断数据集。修改一个事实应自动修改相关事实。但标准编辑方法无法实现这些一致更新。一个简单的上下文基线方法反而效果最好。

AGM-Bench（Jenkins，2026）是最近的先驱工作。它是在ICLR 2026研讨会的海报。它基于1985年的AGM信念修订理论。作者在七种模型上测试了2400个场景。论文发现两个主要错误：模型保留过时事实（称为"信念惯性"），模型还会破坏无关事实（称为"附带损害"）。我使用了相同的术语，但并未发明它们。由于是研讨会论文，仍属于早期研究。

计算机科学在数十年前就解决了类似问题。真相维护系统（Doyle，1979）跟踪每个信念的确切原因。如果前提发生变化，系统会丢弃相关信念。数据库使用增量视图维护（Gupta等，1993）仅更新受影响的数据。我的基准测试正是使用了这个概念作为解决方案。我没有发明这个概念。

研究分解如下：

| 工作 | 核心问题 | 测试对象 | |------|----------|----------| | Belief-R (2024) | 模型在事实变化时是否会更新结论？ | ~30个语言模型 | | MQuAKE (2023) | 编辑一个事实是否会更新多跳答案？ | 模型编辑方法 | | RippleEdits (2024) | 编辑后相关事实是否会一致更新？ | - | | AGM-Bench (2026) | 模型是否遵循理性修订规则？ | 七种语言模型 | | RevisionTrace (此处) | 修复是否能触及所有相关事实且不产生其他影响？ | - |

六种修订策略

我的贡献非常具体。我同时在完全相同的数据上并行运行scratch-build路径和update路径。我在单次运行中跟踪陈旧错误和附带损害。我只想观察成功更新的机制。

如果你想了解真实语言模型的基准测试，请阅读上面的论文。我的实验严格测试底层更新逻辑。

我如何构建实验：依赖图、三值逻辑和预言机

我使用依赖图、三状态逻辑和预言机构建了实验环境。每个组件都很小。但结合起来，它们能让故障变得显而易见。

这个图的工作原理是：事实驱动结论，结论驱动其他结论，最终端点是决策。

每个节点对其输入应用简单的逻辑规则，使用AND、OR或k-of-n逻辑。我还为每个图添加了独立分支，这让我能检查局部更新是否意外破坏了无关逻辑。

典型图使用约10个事实计算12个结论。逻辑链深度为2到5层。

结构示例（虚构案例）。实际案例规模更大。

一个小型依赖图包含三列：事实、结论和决策。C1是F1和F2的AND。C2是F3和F4的OR。决策C3是C1和C2的AND。实际基准案例使用相同结构，包含约12个结论。

每个节点状态为TRUE、FALSE或UNKNOWN。我使用克里内三值逻辑。AND门在任一输入为FALSE时输出FALSE，所有输入为TRUE时输出TRUE，其他情况输出UNKNOWN。OR门逻辑相反。k-of-n规则在至少k个输入为TRUE时输出TRUE，当将所有UNKNOWN视为TRUE仍无法达到目标时输出FALSE，其他情况保持UNKNOWN。这非常重要。"未知"是一个有效状态。拒绝承认未知状态的系统将会失败。

证据以声明形式输入。更新要么添加声明，要么删除声明。每个声明都有值和等级。事实采用最高等级声明的值。如果顶级声明出现平局且不一致，事实变为UNKNOWN。如果某个事实没有活跃声明，也会变为UNKNOWN。撤回是永久性的。最终状态仅取决于最终声明列表。更新顺序无关紧要。这就是为什么洗牌测试有效。

预言机从最终证据计算真实值。我将其独立于测试策略构建。它使用严格的克里内逻辑。每次测试前，自检会用5000个随机逻辑检查验证预言机与策略的一致性。

我将每个结论与旧值、预言机预期值和系统新值进行对比。这能暴露五种类型的错误。

错误类型 | 含义 --- | --- Stale | 应该改变但保留了旧值 Collateral | 应该保持不变却发生了变化 Wrong direction | 改变了但方向错误 False resolution | 应该是UNKNOWN却选了TRUE或FALSE Hidden damage | 内部节点失效但最终决策正确

只有所有节点都与预言机匹配，案例才算通过。由于300个案例样本量较小，最终评分使用95%威尔逊置信区间。

更新存储结论的六种方式

我测试了六种更新缓存结论的方法。每种方法都从完美初始状态开始。然后我逐个向它们输入更新。两种方法是标准技术，其他四种是我特意构建的失败案例。每个失败模型只违反一个规则。

工作方式 | 类型

从每次更新后都从头开始重新计算所有内容。

设计正确性

仅更新下游节点。当值稳定时停止。

浅层更新

仅触及变更的事实及其直接邻居。

失败模型

优先分支更新

正确传播但仅遵循看到的第一个分支。

粘性状态

正确传播但拒绝将确定答案改回未知。

激进刷新

将所有内容重置为未知。仅重新计算变更下游的节点。

前两种方法是坚实的基准线。它们通过设计通过所有测试。测试套件验证这两种方法在300个案例中与预言机完全一致。它还证明当从头开始计算时，所有六种方法都能完美运行。

我构建这四种失败模型是为了模拟现实中的错误。浅层更新就像一个只检查直接笔记的代理。粘性状态就像一个拒绝放弃旧假设的缓存。激进刷新模拟了硬重置后懒惰重建的过程。优先分支更新就像一个忽略并行路径的流水线。这些只是代码的类比，我并未针对特定产品。

300个测试用例覆盖六个不同场景。我使用固定种子为每个类别生成50个案例。代码在创建时严格验证每个案例，确保其实际测试预期逻辑。

类别

必须发生的情况

单一事实变更

所有依赖该事实的内容都需要重新考虑

多支持

一个具有多个支持的结论仅在剩余支持不足时才会变更

共享依赖

共享一个事实的两个分支都会被修订

冲突证据

同等优先级的矛盾会使事实保持未解决状态，或高优先级证据将其解决

无关变更

侧边分支的变更不会影响主图

多更新

连续四到八次更新，其中一些被添加后又被撤回，没有过时结论存活

结果：从头开始回答时100%，修订时0.7%

以下是结果：从头开始时100%，但更新时低至0.7%。

第一部分很简单。每种策略从头开始都能完美运行。得到正确答案仅取决于数据。只要给这些方法最终事实和规则，它们就能构建正确状态。即使在更新中得分0.7%的方法，在这里也能得到满分。

更新才是导致问题的原因。证据相同。规则相同。逻辑完全一致。唯一不同的是起点。一个从零构建，另一个修改现有状态。这个基准测试隔离了更新逻辑的确切影响。请注意，真实语言模型可能不会如此清晰地区分推理和记忆。

同六个策略在相同最终证据上以两种方式评分。

在300个种子案例中，最终状态完全一致。每种策略从头开始都能正确回答。从存储状态修订时，全量重新计算和增量修订得分100%，浅层更新59%，粘性状态57%，优先分支更新29%，激进刷新0.7%。

让我们看看300个案例的整体得分。两种正确策略达到100%。浅层方法得分在53%到64%之间。粘性方法得分在51%到63%之间。优先分支方法降至24%到34%。刷新方法几乎完全失败，得分低于3%。请记住，这些区间仅衡量我的特定测试样本，它们无法预测真实世界AI的失败率。

正确的方法在所有测试中都表现优异，因此我未将其纳入下表。以下是四种失败模型在六个类别中的评分情况。每个类别均运行了50次。

浅层

粘性

分支优先

刷新

40%

54%

10%

0%

72%

84%

58%

2%

46%

6%

52%

28%

36%

66%

34%

64%

30%

三个模式显而易见。

首先，分支优先方法在共享依赖项上失败。得分仅为6%。当一个事实为多个路径提供数据时，代码只会更新第一个路径并忽略其余路径。

其次，粘性方法在冲突证据上失败。得分为28%。当证据冲突时，正确答案应为UNKNOWN。此方法拒绝退回到该状态。

第三，浅层方法在无关更改上表现最佳。得分为84%。侧边分支较小且较短。懒惰的单跳更新实际上可以到达终点。

图深度会显著影响浅层策略。其准确性从深度为2时的70.5%下降到深度为5时的44.4%。每一层额外深度都为单跳更新提前停止提供了更多机会。粘性策略不关心深度。其得分只是随机波动。每个深度的样本量实在太小，无法显示真实趋势。

最小的失败：一个过时的结论

原始数据隐藏了实际的错误。让我们看看我发现的最小的干净失败案例。

它来自一个包含18个总结论的测试用例。我们只需关注一个小的三个事实角落。

事实F6、F7和F8最初为TRUE。系统根据它们计算出两个结论。

首先，C14需要所有三个事实为TRUE。由于它们是，C14解析为TRUE。其次，C17需要C14和F8都为TRUE。它也解析为TRUE。

然后一个新的更新覆盖了F6。它将F6设置为FALSE。

正确的系统会更新这两个节点。C14依赖于F6，因此降为FALSE。C17依赖于C14，因此也降为FALSE。

浅层策略修复了C14但提前停止。C17错误地保持为TRUE。缓存数据现在已过时。

种子2026运行的案例unrelated_change-003。

信念修订测试中的过时结论。当F6变为FALSE时，浅层更新策略正确地更改了C14，但让依赖于C14的C17保持为TRUE。Oracle认为C17应该为FALSE。

基本逻辑没有问题。如果你给浅层方法最终数据并要求它从头开始计算C17，它会正确回答FALSE。错误完全存在于更新过程中。系统修复了新事实旁边的节点，只是从未检查过下游节点。

这完美地说明了核心问题。一个结论发生了变化。依赖它的结论保持不变。想象一个真实代理。C14是取消的航班。C17是"行程确认"状态。

该测试中的其他16个结论都是正确的。仅检查更新节点附近节点的基准测试会通过此次运行。这正是我为图中每个节点都打分的原因。

过时结论与附带损害：两种错误方式

过时数据只是失败的一种类型。附带损害是另一种。仅检查过时数据的基准测试会完全忽略它。

以案例shared_dependency-048为例。五个事实初始为TRUE。F4初始为FALSE。然后一个新的更新将F4翻转为TRUE。

刷新策略将其视为暴力缓存清除。它将每个节点重置为UNKNOWN。然后它仅重建F4下游的节点。这条特定路径完美运作。C1和C3翻转为TRUE。C0和C4保持TRUE。

但另外两个节点与F4完全无关。C2查看F1、F2和F0，这三个值都是TRUE，因此C2应保持TRUE。C5查看C2、F1和F0，也应保持TRUE。

由于这两个节点都不依赖F4，重建脚本会忽略它们。这两个节点因此卡在UNKNOWN状态。系统虽然成功更新了正确的事实，但在这个过程中破坏了完全正确的数据。

案例shared_dependency-048。前两行被正确修订，后两行遭到损坏。

修正后的附带损害。刷新策略会将所有存储的结论重置为UNKNOWN，然后仅重新填充依赖F4的结论。C2和C5从未依赖F4，因此它们应保持TRUE却仍停留在UNKNOWN状态。

我将第一类错误称为陈旧状态。某个值需要改变却未改变。我将第二类错误称为附带损害。某个值本应保持不变却发生了错误。以下是这两种错误在所有300个案例中的表现。

四种失败模型的陈旧率和附带损害率。正确策略在两项指标上均为0%。

修订时出错的两种方式。陈旧表示本应改变的结论未改变。附带损害表示本应保持的结论发生了改变。浅层策略陈旧率33.1%，粘性策略42.1%，分支优先策略65.4%。刷新策略陈旧率仅2.0%，但导致58.0%本应保持的结论受损。

观察刷新策略。如果你只检查陈旧数据，它似乎比浅层方法好得多。它仅留下2.0%的陈旧数据，而浅层方法有33.1%。

但它实际上整体表现最差。为什么？因为它完全破坏了无关数据。其他三种方法几乎从不触碰无关事实。它们失败是因为留下了旧数据。

这证明仅问"答案是否改变？"是糟糕的测试方式。你必须同时问两个问题：受影响的数据是否改变？无关数据是否完全保持原样？

只有依赖跟踪器能通过这两个测试。

隐蔽的失败：正确决策，错误原因

另外两个统计数据揭示了错误如何隐蔽存在。

首先是隐蔽损害。在每个失败测试中，我检查了最终决策是否仍然正确。决策是最终端点节点。对于留下陈旧数据的三种方法，大约五分之一的失败案例最终输出是正确的。最终答案看似正常，但内部状态已损坏。

这是一个重大问题。如果你只测试最终输出，就会通过这些错误。想象"行程确认"标志正确，但内部"酒店预订"记录错误。下次系统检查酒店时会失败，你将完全没有任何预警。

其次是虚假解决。在整个测试套件中，有526个节点应解析为UNKNOWN。糟糕的策略会强行将其设为TRUE或FALSE。

失败运行情况

失败但决策正确

在UNKNOWN时强行给出答案

123

23 (18.7%)

103 (19.6%)

213

34 (16.0%)

209 (39.7%)

129

29 (22.5%)

302 (57.4%)

298

5 (1.7%)

0 (0%)

仔细观察粘性策略。它拒绝放弃已确认的信念。当证据冲突时，真实状态应为UNKNOWN。粘性方法却坚持使用旧答案。它没有产生任何方向性错误，附带损害几乎为零（0.1%）。如果你只检查错误答案，它看起来完美无缺。

你在生产环境中经常能看到这种情况。可信来源被撤回，正确状态应变为"我们不知道"。拒绝承认这种状态的系统会基于死数据投射信心。

刷新方法的作用正好与之相反。它会激进地默认设置为 UNKNOWN。它从不会错误提交，但会清除如此多的数据，以至于最终决策几乎总是出错。

更新顺序重要吗？稳定不等于正确

更新顺序不应改变结果。最终的证据是相同的。

我选取了具有多次更新的 133 个测试用例。对每个用例的更新顺序进行了最多五次随机打乱。我关注两个问题：系统是否每次都能达到完全相同的状态？该状态是否确实正确？

每次状态相同 每次状态正确

88.0% 48.9%

97.7% 75.2%

87.2% 28.6%

66.2% 0.8%

以下是顺序失败的示例。用例 multi_update-004 接收四次更新。F2 获得一个主张后又失去，F3 失去一个旧主张，F0 降至 FALSE。最终证据使 F2 和 F3 变为空。真实情况期望节点 C3 从 TRUE 降至 UNKNOWN。

我使用浅层方法运行了两种不同的更新顺序。在第一种顺序中，C3 始终卡在 TRUE。在第二种顺序中，C3 正确降至 UNKNOWN。最终数据完全相同。仅凭到达历史就导致了错误。

再次审视粘性策略。它在 98% 的运行中达到了完全相同的状态。但只有 75% 的时间是正确的。如果你只衡量一致性，这种方法看起来非常出色。它高度稳定。但在大约五分之一的案例中，它始终陷入相同的错误状态。

测试更新顺序的成本极低。你只需打乱输入，重放测试，然后比较输出。如果最终状态不同，就说明存在缺陷。你甚至不需要 oracle 来发现它。

谁教会它改变主意？什么使修订有效

本文标题提出了一个问题。究竟什么使修订有效？以下是数据给出的答案。

我想精确隔离使成功策略奏效的关键因素。因此我采用了正确的增量方法并加以限制。我严格限制了更新能从变更事实传播的距离。

在零跳情况下，系统仅记录新证据。它完全忽略已存储的结论。它变成一个仅追加的日志。它可以回答新问题，但无法修订旧问题。

在单跳情况下，它仅更新直接下游邻居。我逐步增加这个跳数限制，直到完全取消限制。

相同的 300 个案例，相同的机制。唯一变化的是修正的传播范围。工作量是每次更新的节点评估次数。

对增量修订的消融实验，限制修正通过依赖图传播的跳数。零跳时精确一致率为 8.0%，单跳时为 59.0%，双跳时为 90.3%，三跳时为 99.3%，四跳时达到 100%。每次更新的工作量从 1.0 次节点评估增加到 5.2 次。

三个关键发现：

首先，零跳仍获得 8.0% 的准确率。在这些运行中，更新实际上并未改变最终结果。如果新数据最终被证明无关，拒绝更新的系统仍可能通过测试。基准设计者需要警惕这一点。

其次，单跳正是浅层策略。它获得 59.0% 的准确率，每次更新使用 3.7 次评估。我撰写的浅层失败模型正是正确修复的单跳版本。

第三，准确率随传播范围增加而提升。在双跳时准确率跃升至 90.3%，三跳时达到 99.3%，四跳时实现完美的 100%。在这些运行中，四跳始终足够。

计算成本遵循这一模式。完整重建需要每次更新进行21.9次评估，而增量修订仅需5.2次。它仅用四分之一的工作量就获得了满分。

有缺陷的模型评估次数介于2.5到7.1次之间。刷新操作消耗的计算资源甚至超过了正确的增量修复方法，但仍然完全失败。有缺陷的策略并不自动更便宜。浅层方法之所以快速，仅仅是因为它们跳过了必要的工作。

那么究竟是什么让系统能够成功改变其结论？你只需要两件事。首先，绘制依赖关系图。其次，应用严格的传播规则。更新下游节点，并在值停止变化时立即停止。

没有依赖关系图，你就无法找到下游节点。没有停止规则，你要么过早终止导致数据陈旧，要么彻底清除所有内容造成附带损害。

在相同案例中运行小型本地模型：Gemma 3 4B的表现

到目前为止所有内容都使用纯代码实现。但标题提到了AI，所以我通过精确相同的测试运行了一个小型本地模型。我在此明确设定边界条件：这仅涉及一个模型、一次运行和部分数据。请将其视为边界测试，而非语言模型的通用基准。

我通过Ollama本地运行Gemma 3 4B，没有进行任何API调用。我将温度硬编码为0并固定了随机种子。我仅测试了66个案例，过滤掉了任何包含超过八个结论的图。完整图结构对4B模型来说过于庞大。

我以三种不同方式提示模型处理每个案例：

• 回答：仅提供最终证据，从零开始构建。
• 修订：提供旧证据、旧结论和新更新。
• 带提示的修订：提供旧证据、旧结论、新更新，以及需要更新的节点直接列表。

我还运行了一个基准测试，该测试完全不执行任何操作，仅保留旧状态。如果模型的表现无法超越"什么都不做"，则其修订逻辑没有实际价值。

该模型在基础逻辑上表现挣扎。从零开始计算时，它在单个节点上的准确率仅为58.6%。在总共471个节点中，有66个应该标记为UNKNOWN，但模型错误地将其中62个强制标记为TRUE或FALSE。

只有当所有节点都正确时，测试案例才算通过。节点准确率具有误导性。系统可能获得高节点得分但几乎每个完整案例都失败。以下静态基准测试纯粹作为对照组进行处理。

66个小案例中个体结论正确率占比，Gemma 3 4B的表现

通过Ollama在66个案例（结论数不超过8个）上运行的本地语言模型。仅复制存储结论的基准测试得分79.4%。模型在修订时得分77.3%，在带依赖提示（携带评分）时得分77.1%，从零构建时得分58.6%，在严格提示评分时得分52.0%。

| 行（66个案例） | 精确匹配 | 结论正确 | 复制存储从不修订 | |----------------|----------|-----------|------------------| | 12.1% | 79.4% | 0 | | 修订 | 16.7% | 77.3% | 81.4% | | 修订 | 7.0% | 2 | | 带提示（携带） | 13.6% | 77.1% | 72.2% | | 12 | | | | | 带提示（严格） | 7.6% | 52.0% | 38.5% |

有三个显著发现：

首先，在结论正确率方面，什么都不做比模型表现更好。每个模型行的得分均不超过79.4%的复制基准。

其次，提示仅改变了错误类型。陈旧错误从81.4%下降到72.2%，但方向错误却从2%激增至12%。模型触及了更多节点，但计算了错误的值。

第三，模型在基本格式化方面失败了。它直接丢弃了本应复制的118个结论。我不得不应用一个严格规则来确保这些值被正确传递，仅仅为了完成这次测试。我报告了两个数据，因为丢弃数据本身就是一种真正的失败。

精确匹配得分只是噪音。在66个案例中，我们只看到9到11个正确案例。

关键结论是：提示只是告诉模型该往哪里看，它不会教会模型如何计算。这个模型在基础推导上彻底失败了。如果一个系统无法首先计算状态，就无法测试它更新状态的能力。

这就是纯Python测试至关重要的原因。它们隔离了更新逻辑。每个代码策略都从完美状态开始。要在LLM上正确测试这一点，我们需要一个从零开始就能达到100%准确率的模型。到目前为止，我还没有运行过这样的测试。

本实验未展示的内容

我需要明确说明本次测试的局限性。标题虽然醒目，但数据具有高度特定性。

首先，这不是一个LLM基准测试。这六个策略只是Python代码，不是AI模型。在从零构建时获得完美分数只是代码设计的特性。

其次，我自行构建了失败模型。它们的错误率只是反映了我的编程方式。刷新方法会破坏58%的数据，因为我硬编码了清除所有内容的逻辑。我不确定生产环境中的代理是否真的会这样行为。

第三，逻辑完全基于符号。图结构很小，变量只能是TRUE、FALSE或UNKNOWN。真实数据要复杂得多。从原始文本中提取干净的依赖关系图是一个极其困难的问题。本基准完全忽略了这个问题。

第四，样本量很小。总共使用了300个案例。我报告了95%的威尔逊置信区间，并且在区间重叠的组别中没有刻意寻找模式。

第五，一个随机种子只是一个快照。我测试了另外三个种子来验证数据。正确方法的准确率始终保持在100%。失败率在范围内波动（浅层方法55.3%到60.7%，分支优先方法25.7%到33.3%，刷新方法0.7%到1.3%），但模式没有改变。

代码库包含一个名为llm_eval.py的脚本。它用相同的基准测试本地模型。我之前分享了一次运行结果。它在66个小型案例中测试了一个小型模型。请将这个结果视为边界测试，而不是对语言模型的广泛结论。

我们必须在此划清界限。在这个受控基准测试中，计算答案和更新状态表现为两种独立的能力。它精确地展示了更新如何失效，但并不能证明真实LLM会以完全相同的方式失败。如果你想了解相关证据，请阅读Belief-R和AGM-Bench论文。它们确实对模型进行了实际测试。

应该构建到代理或RAG系统中的功能

这是如何将这些原则应用到AI代理或RAG系统中的方法。这些是设计规则，而非原始测试数据。如果你的系统缓存了摘要、答案或状态标志，这六个习惯可以修复我找到的漏洞。但前提是你的系统能正确追踪依赖关系。

• 追踪依赖关系。为每个缓存项标记它依赖的事实ID。否则更新将永远丢失。

• 持续推送更新直到稳定。不要在第一个下游节点就停止，也不要直接清空整个缓存。更新受影响节点，直到值稳定后立即停止。

• 允许UNKNOWN状态。冲突数据通常意味着"我不知道"。如果系统无法表达这种不确定性，它将基于过时事实保持自信的错误答案。

• 双向测试。检查数据是否正确更新，验证无关数据是否保持不变。仅测试单侧会隐藏大量潜在问题。

• 检查内部状态。最终输出可能看似正常，但内部节点可能已完全过时。必须对整个图进行测试。

• 随机化更新顺序。以随机顺序输入更新。如果最终状态发生变化，说明存在缺陷。甚至不需要真实值验证器即可发现。

最后一点。定期运行完整重建作为审计。从零开始重新计算所有内容，并与缓存进行差异对比。完整重建的计算成本是常规操作的四倍，因此不要在生产环境中执行。仅将其作为健康检查使用。

回想旅行机器人案例。航班被取消时，如果机器人具备依赖关系图，就能准确知道需要检查哪些内容。它会更新相关逻辑，必要时将内容标记为"未知"，同时不会影响你的牙医预约。从原始文本中提取这种依赖关系图是一个巨大挑战。本次实验并未解决这个问题。

我们花了数年时间训练AI回答问题。现在需要训练它改变观点。要做到这一点，只需要依赖关系图和一个明确的使用规则。

自行运行

整个基准测试是一个单独的Python文件。严格使用标准库。

运行方式如下：python revisiontrace.py

耗时约1秒。它会打印报告并将7个文件保存到revisiontrace_out文件夹。输出内容包括CSV表格、完整案例日志、JSON数据、最小失败案例的文本记录，以及两个SVG图表。

在终端顶部查看运行结果，确认与我的输出一致。你应该看到以下精确内容：

text

verified: full_recompute and incremental match the oracle on all 300 cases
verified: all 6 strategies answer correctly from scratch on all 300 cases
RevisionTrace  |  300 cases  |  case-set hash 506be3856003

默认种子始终生成完全相同的测试用例和字节对字节的输出文件。想测试其他样本？只需运行 python revisiontrace.py --seed 7 --cases 100 。

披露声明

本文所有代码均由我编写，属于原创作品。本工作未获得任何赞助，与本文引用论文的作者无任何关联。基准测试结果未使用任何语言模型。唯一一次模型运行（Gemma 3 4B）使用本地Ollama安装，温度参数设为0，种子设为42。未进行任何API调用或网络访问。

所有基准测试数据均来自revisiontrace.py在种子2026（案例集哈希506be3856003）下的运行结果，加上限制章节中提到的三个额外种子，以及一次验证运行（种子42，1200个案例，每个案例10种额外更新顺序），其中所有正确策略再次与验证器完全匹配。模型数据来自我运行的llm_eval.py在种子2026下的结果。

相关工作描述基于每篇论文的摘要页面，我已核对出版商或会议页面。未复制任何论文中的文本、数据或图表。图表均为原创，源自基准测试的输出。

参考文献

• Alchourrón, C. E., Gärdenfors, P., & Makinson, D. (1985). On the logic of theory change: Partial meet contraction and revision functions. The Journal of Symbolic Logic, 50, 510–530. https://doi.org/10.2307/2274239

• Cohen, R., Biran, E., Yoran, O., Globerson, A., & Geva, M. (2024). 评估语言模型知识编辑的涟漪效应。计算语言学协会会刊, 12, 283–298. https://aclanthology.org/2024.tacl-1.16/

• Doyle, J. (1979). 一个真值维护系统。人工智能, 12, 231–272. 概述：推理维护（维基百科）

• Gemma Team, Google DeepMind. (2025). Gemma 3 技术报告。arXiv:2503.19786. https://arxiv.org/abs/2503.19786

• Gupta, A., Mumick, I. S., & Subrahmanian, V. S. (1993). 增量维护视图。第19届ACM SIGMOD国际数据管理会议论文集, 157–166. https://dl.acm.org/doi/10.1145/170035.170066

• Jenkins, B. (2026). AGM-Bench：大语言模型是否理性地修正信念？大型语言模型逻辑推理研讨会，ICLR 2026. https://www.iclr.cc/virtual/2026/10017503

• Marcos, J., Přenosil, A., & Égré, P. 多值逻辑。斯坦福哲学百科全书（2026年春季版）。https://plato.stanford.edu/archives/spr2026/entries/logic-manyvalued/

• Ollama. (n.d.). Ollama [软件]. GitHub. https://github.com/ollama/ollama

• Python Software Foundation. (n.d.). Python标准库。Python 3 文档. https://docs.python.org/3/library/index.html

• Wilie, B., Cahyawijaya, S., Ishii, E., He, J., & Fung, P. (2024). 信念修正：大语言模型推理的适应性。第24届自然语言处理经验方法会议论文集, 10480–10496. https://aclanthology.org/2024.emnlp-main.586

• Wilson, E. B. (1927). 可能推断、连续定律与统计推断。美国统计协会会刊, 22, 209–212.

• Zhong, Z., Wu, Z., Manning, C., Potts, C., & Chen, D. (2023). MQuAKE：通过多跳问题评估语言模型的知识编辑。第23届自然语言处理经验方法会议论文集, 15686–15702. https://aclanthology.org/2023.emnlp-main.971