AI改对了却改多了？LLM状态协调基准揭示关键盲区

改对了，不等于没改错

一位开发者在 Kaggle 基准测试挑战中提出了一个容易被忽视的评估盲区：AI 助手可以在更新用户信息时做出正确修改，却同时悄悄篡改了不该动的字段。这个失败模式被他称为 LLM State Reconciliation（LLM 状态协调）——模型在多轮对话中维护用户结构化状态时，能否只改该改的，保留该留的。

最初的实验看起来相当乐观。他把 DeepSeek^广告、Claude 和 Gemini 放入十组场景测试，每个模型都拿到了满分。换作别人可能就收工庆祝了，但他反而开始怀疑基准本身——这些用例是不是太容易区分了？

预算变了，其他一切都不能动

问题的核心可以用一个简单场景说明。用户的学习预算原本是 ₹5,000，后来奖学金获批，预算提升到 ₹10,000。预算该变，但用户的位置、职业目标、学习偏好和可用时间都不该变。

复杂度一旦上升，情况就变得棘手：用户因为生病暂时只有三小时可用；用户更正了之前的职业目标；用户提到大学小组项目用了另一款笔记应用；用户在讨论一个尚未确认的实习机会和搬迁计划。

一个可靠的助手必须分辨：临时状况和永久变化、明确更正和矛盾信息、已确认事实和可能性。它还必须保住最新消息从未要求它改变的那些信息。

作者的研究问题正是：语言模型能否在多条消息中更新用户信息的结构化表示，而不丢失重要事实、不引入无关改动、不把不确定事件当成既定事实？

为什么这个基准和普通测试不一样

测试模型是否只改了被要求的设置，本身就是一个独立且重要的问题。但用户信息引入了一个额外挑战：更新的意义取决于上下文。

临时减少的可用时间不等于永久的日程变更。有条件的辞职不等于已完成的辞职。为团队项目表达的偏好不会自动取代个人偏好。一个可能的搬迁计划不应在发生之前就变成记录在案的事实。

这些区分驱动了基准的设计。作者不只是检查无关字段是否保持不变，而是想检验模型是否理解对话究竟为哪些变更提供了正当理由。这意味着要同时评估更新本身和更新后留下的状态。

保留性（Retention） 是评估语言模型状态更新的核心指标之一，指模型在完成目标字段更新后，是否能够不修改、不遗忘那些对话并未要求变更的字段。它与准确率（Accuracy）不同：准确率只看模型是否做对了被要求的操作，而保留性关注模型是否“没有做错”不该做的操作。在结构化状态维护场景中，保留性差通常表现为两种形式——遗漏性丢失（字段被清空或回退到默认值）和附带突变（字段被改成无关值）。这两类错误在只看目标更新准确率的指标下完全不可见，因此必须单独评估。保留性的难点在于，模型需要判断哪些字段与当前对话相关、哪些不相关，而“相关”的判断又高度依赖上下文，这使得保留性评估比单纯的分类或抽取任务更接近真实对话中的状态管理挑战。

从轻松满分到十二个更难的用例

初版实验中，所有模型在十组用例上报告了完美准确率。作者没有把这当成问题已解决的证据，而是把它视为评估的局限：这些用例没有足够的区分度。

于是有了 H01–H12 套件，基于一个 25 字段的基线，覆盖十二种不同的失败模式：临时与永久变更、显式更正、矛盾证据、条件性未来事件、对早期消息的引用、多重同时更新、特定任务与通用偏好、过时信息、个人与项目级偏好、不确定的就业结果、已确认与未确认的变更、复合状态协调。

在评分设计中，这套用例包含九个预期字段更新和 291 个受保护字段槽位。这个区分很关键：模型可能正确更新了被要求的字段，却同时悄悄改动了别的东西。只衡量请求更新的指标会完全错过这种失败。

受保护字段槽位（Protected Field Slots） 是基准设计中用于量化保留性的计数单位。在一个包含 N 个字段的结构化用户状态中，针对某一条对话消息，只有少数字段被明确要求更新，其余字段都处于“受保护”状态——即不应被本次更新触碰。将所有用例中这些受保护字段累加，就得到受保护字段槽位总数。例如 H01–H12 套件中，九个预期字段更新对应 291 个受保护字段槽位，意味着平均每个用例有约二十多个字段需要保持原样。这个设计的价值在于把保留性从模糊的定性判断转化为可计算的比率：模型在 291 个槽位中错误改动了多少个，就是附带突变率的直接分子。它也解释了为什么满分目标更新准确率可能具有误导性——模型只要正确完成九个更新，就会在准确率上表现完美，而 291 个保留性失误则完全不被这个数字反映。

一条异常观察暴露的方法论问题

早期的一条 DeepSeek 观察结果说明了为什么保留性必须单独评估。在一个位置更新用例中，目标位置正确改成了 Bengaluru，但预算却停留在上一用例的 ₹6,000，而没有回到 ₹5,000 的基线。这被记录为可能的跨用例污染。

这个观察同时引出了方法论层面的疑问：每个用例到底应该从同一基线独立开始，还是基准在测试一段有意连续的对话？独立测试需要独立初始化；顺序测试需要预期状态只携带由早期消息证明合理的变更。评估协议必须明确区分这两种情况。

作者也坦诚地指出了当前结果的局限。虽然收集了额外的模型回复和摘要，但并非每个模型和用例的完整原始输出都被保留。因此他无法独立验证完整的 H01–H12 保留性和附带突变指标，也无法给出可靠的对比排行榜。他把对话中报告的观察与能从原始输出中实际计算的分数分开呈现——缺失的证据不等于及格。

目前最有价值的发现来自方法论层面：一个基准可以产出满分，却根本没有测量到你所关心的困难行为。

跨用例污染（Cross-Case Contamination） 指在顺序执行的基准测试中，前一个用例的对话状态意外泄漏到后续用例，导致模型在后续用例中面对一个被污染的输入基线。典型表现是某个字段没有回到该用例的初始值，而是停留在上一用例的残留值上。跨用例污染与模型能力无关，属于评估协议缺陷，但它的存在会严重扭曲结果：模型可能被错误地判为保留性失败，而实际上它只是忠实地延续了上一轮的状态。区分独立初始化与顺序延续，本质上是要求基准设计者明确声明每个用例的预期输入状态，并在评分时使用与该协议匹配的基线。缺少这一声明时，任何保留性和附带突变指标都不可信，因为无法判断字段值偏离究竟源于模型改动还是协议泄漏。

如何正确评估状态协调

作者把评估拆成三个核心维度：

目标更新准确率——模型是否做了对话证明合理的变更？

保留准确率——它是否没有动无关字段？

附带突变——它有多频繁地改变了本应保持不变的东西？

时间推理和不确定性处理也应当单独评估。模型不应因为一次临时例外就永久覆盖某项偏好，也不应把有条件计划当作已完成事件。

为了可复现的对比，所有模型应收到相同的提示词和基线，每个用例遵循明确界定的独立或顺序协议，完整输出被保留，然后用同一套确定性评分代码对每个模型按相同的标准答案打分。

附带突变（Incidental Mutation） 是衡量保留性失败严重程度的独立指标，统计模型在单次状态更新中改动了多少个本应保持不变的字段。它与保留准确率互为补充：保留准确率是一个比率，附带突变则是原始计数，后者更便于定位具体哪些字段被误改、被误改成什么值。在评估协议中，附带突变应当按用例、按字段类型分别统计，因为某些字段（如预算、位置）被误改的代价远高于其他字段。同时，附带突变需要与目标更新准确率交叉分析——一个模型可能在附带突变数很低的同时目标更新准确率也很低（过度保守），也可能两者都高（鲁莽更新），只有两个指标同时呈现才能刻画模型在“改该改的”和“留该留的”之间的真实平衡。

实现进度与现实限制

在实现层面，作者已经创建了共享基线和十二用例的标准答案结构，实现了评分和验证代码，并添加了自动化测试。最新开发运行通过了全部十项测试。已有的 C1–C10 评估在项目变更后也保持可用。

但这些是工程检查，不是模型性能的证明。C1–C10 和更难的 H01–H12 是不同的评估，前者不能替代后者缺失的原始证据。

下一步计划包括：恢复或重新生成完整的原始输出，在文档化的初始化协议下运行用例，重复评估以衡量一致性，并扩展场景范围。作者还希望调查同样的失败模式是否出现在实际维护用户画像的对话式代理中。

在发布环节，作者遇到了 Kaggle 账号验证问题，暂时无法提供公开的基准链接。他选择记录这些限制，而不是把一个未经验证的排行榜当作结果呈现。

真正的问题

当对话式助手承担起更多记忆偏好、计划、目标和约束的责任时，正确更新信息只是问题的一半。

另一半是知道这次更新没有授权助手去改变什么。

当 AI 助手改变它记住的内容时，我们能否信任它保留住那些我们从未要求它改变的东西？这正是 LLM 状态协调想要测量的行为。