LLM 应用评测：测量整条系统是否完成真实任务

评测要回答的第一个问题，其实是：什么叫“回答不错”？如果两个评审对这个词的理解不一样，一个人觉得“够礼貌”就算好，另一个人认为“没出错”才算好，那么他们各自打出的分数放在一起就没有共同的度量基准。分数一旦失去共同基准，就无法回答那个真正重要的问题：这次改动能不能上线。上线决策需要的不是一团“整体感觉”，而是一份双方都能逐条核对的验收契约。

以退款助手为例，“用户成功拿到退款”这件事不能作为一个整体来评。它必须拆成一系列原子属性：资格判断是否正确（不该退的没退、该退的退了）、退款金额是否正确、每一个政策主张是否都有证据支撑、有没有承诺自己无权执行的动作、信息缺失时有没有先询问而不是瞎猜、输出结构能否被前端直接解析，以及整个处理是否落在延迟和成本预算之内。拆分之后，“好”就不再是一个主观印象，而是一组可以分别打勾或打叉的判定。

每个原子属性还要配齐三样东西：适用条件、证据和判定规则。适用条件说明这个属性在什么场景下才需要检查——例如“询问缺失信息”只在用户输入不完整时适用；证据说明依据什么来判，例如依据最终回复文本中的哪个字段；判定规则说明满足什么标准才算通过。没有这三样，属性就只是一个口号，评测时仍然会退回靠感觉打分。

拆出来的属性并不平等。资格判断错误、金额错误、隐私泄漏、越权承诺这类属于硬约束：出现一次就可能直接阻断发布，因为它们造成的损失不是“体验略差”，而是资金、合规或信任上的实质性损害。措辞自然度这类则属于软目标：它的作用是在已经通过硬约束的合格候选之间排序，而不是给不合格的方案找补。把两类属性先混在一起算平均分，会出现一种危险的补偿效应——“更好听”的措辞可以抵消“更危险”的错误，平均分因此掩盖了真正该阻断的失败。

为了杜绝这种混同，评分要遵循一个固定的契约结构：样本输入 + 运行上下文 + 期望属性 + 评分器 + 失败严重度 + 系统版本。样本输入是这一次要评的具体请求；运行上下文记录评测发生的环境和条件；期望属性是上面拆出的原子属性及其判定规则；评分器说明用什么方式判定；失败严重度区分硬约束和软目标；系统版本保证结果可以对应到具体的被测对象。这六项缺任何一项，复现和归因都会变弱——复现不了，就说不清结果是环境造成的还是系统造成的；归因不了，就说不清该改哪个组件。

契约的运转方式可以概括为一个输入输出关系：输入是样本、运行上下文、期望属性、评分器、严重度和系统版本，输出是可复现的通过或失败结论以及失败原因。执行顺序同样有讲究：硬约束先判，只要有一个硬约束失败，评测结果就是阻断发布，软目标分数不再参与；只有硬约束全部通过的可行方案，才用软目标在它们之间排序。这个顺序一旦颠倒，回到“先算平均分再说”的老路，验收契约就失效了。

所以整件事的因果链是：评审之间无法共享判定规则时，总分就不能指导上线；要共享规则，就必须把业务成功拆成原子属性；要防止软硬混淆，就必须先判硬约束、再用软目标排序；要让整个过程可复现、可归因，就必须把样本、上下文、属性、评分器、严重度和版本固定成契约。契约不是形式上的表格，而是让“上线”这个决定从主观印象变成可核对判定的前提。

答案出错时，团队的第一反应往往是“换个更强的模型试试”。这个反应之所以危险，是因为它默认了错误一定发生在生成这一步。而一个真实的 LLM 应用不是单点模型，是一条从输入、检索、生成、工具调用一直延伸到业务结果的链。错误可能出现在链的任何一环，换模型只对生成那一环有效；如果问题根本不在生成环节，更强的模型只是让错误以更自信的方式继续出现。

把评测对象分层，正是为了解决这个问题。以退款助手为例，评测要沿着链路逐层展开：输入层处理用户请求如何进入系统，检索层决定召回哪些政策条款，生成层基于召回内容产出回复，工具层负责执行退款、查询订单等动作，最后落到业务结果——用户是否真的正确完成了退款。每一层都对应自己的组件指标，而整条链的结果对应端到端指标。

端到端结果决定能否上线，组件指标负责解释为什么。这两个方向缺一不可：只有组件指标、没有端到端结果，团队会陷入局部最优——每个组件单独看都在进步，但完整任务并没有变好；只有端到端结果、没有组件指标，出了问题无法诊断——只知道“最终答案不对”，却不知道错在哪一环。图 1 表达的就是这个分工：上线决策挂在端到端，归因分析挂在组件。

“最终答案没有引用”这个例子能把分层诊断的因果链说清楚。无引用只是表象，其上游至少有四个可能：检索层没找回条款；上下文在进入生成前被截断；提示词没有要求逐项引用；渲染层在组装页面时丢了 citation id。这四个原因分别落在链路的不同位置，修复动作完全不同——修召回、修截断、修提示、修渲染。只有分层记录每一层的中间产物，才能把笼统的“模型不行”改写成可执行的修复指令。

因此，应用评测的输入是版本化的各层配置——输入处理、检索策略、生成策略、工具策略和界面链路，版本化保证每次评测都能对应到具体被测对象；输出是两份东西：组件诊断与端到端业务结果。组件诊断回答“第一次偏离发生在哪一环”，端到端结果回答“完整任务是否完成”。

这套分工同时划出了两类不能混淆的边界。其一，组件局部提高不等于完整任务提高：检索召回率上升了，不代表最终退款成功率高，因为下游还可能截断、生成还可能漏用条款。其二，诊断不能替代最终验收：组件指标能把失败定位到层，但“能不能发布”永远由端到端结果说了算。评测对象是一条有边界的链——边界内逐层诊断，边界外只看端到端。

十个精心编写的“正常问题”为什么反而会制造虚假的安全感？因为这些问题出自评审者的想象，而不是出自真实用户。真实流量里几乎找不到一个措辞标准、信息完备、意图单纯的提问：用户会打错别字、用口语、漏掉关键信息，会把互相冲突的政策一起摆出来，会多轮补充条件，会上传超长附件，会提出越权要求，甚至直接尝试提示注入。手写题库恰好把这些全部过滤掉了，于是系统在题库上表现优异，上线第一天就被真实流量击穿。样本的问题不在于数量，而在于来源：样本必须来自任务分布，而不是灵感题库。

构建样本数据要从五个桶取材。高频任务保证最常见的工作负载被覆盖；高损失任务纳入出错代价最大的场景，如大额退款或合规敏感操作；历史事故把线上曾经真实发生过的失败固化下来，防止回归；边界组合覆盖输入、政策、工具状态叠加出的边缘情形；真实抽样直接从生产流量按时间窗口截取，保证数据反映实际分布。五个桶合成之后，每个样本还要打上切片标签：语言、客户群、渠道、长度、工具和风险。标签的作用是在评测完成后按切片分析——总体分数掩盖的差异，会在切片上现形。

样本集不是“一个数据集”，而是用途不同的四个集，权重解释不能混用。

开发集用于日常调提示词，允许频繁查看：它的价值在于快速给出反馈，被反复查看导致的小幅过拟合是可以接受的代价。冻结门禁集只在候选版本成熟之后才运行：团队不能在日常迭代中反复查看它，正是为了减少测试过拟合——如果门禁集被看烂了，通过的版本可能只是背熟了答案。挑战集故意集中长尾和对抗案例：它的使命是暴露低频高损失的风险，所以不能用挑战集的比例去估计总体成功率。线上抽样集才负责估计真实分布：它需要脱敏、权限审查和明确的时间窗口，因为真实用户数据进入评测流程本身就带有隐私和合规成本。

四个集各管一段因果：开发集让日常迭代有反馈，冻结集让发布门槛不被过拟合污染，挑战集让长尾风险不被平均分淹没，线上抽样集让总体估计忠于真实分布。把这个逻辑反过来验证会更清楚：把挑战集里占比 30% 的攻击样本按真实流量的权重做平均，会低估正常体验——因为线上攻击样本远没有 30%；反过来完全不看挑战集，又会掩盖低频高损失风险——因为这类样本在随机抽样里几乎不会出现。所以两者必须分别报告，而不是合并成一个总分。

由此可以得到样本设计的完整形态：输入是真实流量、高损失任务、历史事故、边界组合和对抗场景，输出是带语言、群体、长度、工具和风险标签的数据集。使用时的边界同样清晰：挑战集的比例不等于生产发生率，它衡量的是系统在压力下的暴露程度，不是线上风险的概率；线上抽样集的总体估计也不能替代挑战集的风险暴露测试。二者各司其职，混用权重只会让两个结论同时失真。

LLM 裁判说“合格”，真实质量就一定合格吗？这个问题的答案是否定的，而且原因不在于裁判偶尔马虎，而在于评分器本质上是一组测量仪器。任何仪器读数都包含偏差和噪声，把仪器读数当作被测对象的真值，是评测里最隐蔽的一类错误。

不同属性适合不同的评分器，选择依据是属性的确定程度和校验成本。金额、日期这类可确定属性，优先用程序断言：拿输出中的金额与订单系统里的真实金额做精确比对。它确定、便宜、可复现，但盲区在于输入真值本身可能错——如果系统拿到的订单金额就是错的，程序断言只会确认一个错误值。工具副作用适合用沙箱状态差异来评：在受控沙箱中执行动作，直接检查真实结果是否发生，比如退款动作之后账户余额是否真的变了；盲区是模拟环境与生产的差异，沙箱里通过的操作在生产权限或网络条件下未必成立。证据支持类属性适合主张—证据核验：对回答里的每个政策主张，检查它能否定位到原文的具体跨度，防止“有引用但没有支撑”；盲区是来源本身可能过时，引用和原文一致不等于条款仍然有效。帮助性、语气这类开放语义属性，适合盲化 LLM 加人工的组合：LLM 处理开放语义的规模，人工兜底最终判断；盲区是顺序、长度和文化偏差——裁判可能偏爱排在前面或写得更长的回答，也可能对某些表达风格有系统性偏好。

把评分当作测量，观测分数就有一个清晰的误差分解：观测分数 = 真实质量 + 评分器系统偏差 + 样本随机误差。写成符号形式是 Score观测 = Q真 + B判 + E样。被测系统本身有一个潜在的真实质量 Q真；评分器有自己的系统偏差 B判，例如位置偏好、文风偏好、文化偏好，它不随样本波动，而是随评分器特性固定存在；样本随机误差 E样则来自这次具体抽样和标注中的偶然波动。三者叠加才得到观测分数，所以任何一次评分变动，都不能直接归因于“系统变好或变坏”——也可能是裁判偏差或样本噪声在变化。

既然裁判有系统偏差，就需要用金标样本校准它。做法是取一批双人标注并经仲裁的金标样本——两个标注者独立打分，分歧由仲裁解决，仲裁结果作为该样本的基准答案——然后用金标计算裁判在各切片上的精确率、召回率和一致性。精确率回答“裁判判合格的里面有多少真的合格”，召回率回答“真的合格里面裁判找出了多少”，一致性回答“重复打分结果是否稳定”。针对偏差类型还有专门检查：交换候选顺序，看分数是否跟着位置翻转，以检验位置偏差；统一候选长度或明确 rubric，观察分数变化，以降低文风偏差。此外有一条硬性纪律：模型裁判不能读取候选文本中的指令性内容来改变评分规则，否则被测候选可以直接“说服”裁判给自己加分，仪器就被被测对象操控了。

这个校准框架给出了评分器使用的边界。测量模型的输入是潜在质量 Q真、评分器系统偏差 B判和样本随机误差 E样，输出是观测分数 Score观测；由于分数是三者叠加，任何把裁判输出直接当真的做法都会把 B判 和 E样 混进结论。校准只能让偏差可测、可比、可修正，不能把裁判变成真值。由此得到一条选型原则：高风险、可确定的属性，优先用程序断言或状态检查，因为这些仪器没有裁判那样的语义偏差；LLM 裁判应当留给真正开放的语义属性，并且始终带着精确率、召回率和偏差数据一起使用。

新版本的加权通过率从 80.3% 升到 83.1%，但越权请求的通过率也明显下滑，应该上线吗？把这个问题算清楚，就能看清平均提升和发布决策之间的真实关系。

先把三个切片的数据摆出来。普通资格问答占流量的 70%，旧版通过率 84%，新版 90%，失败成本记为 1；金额计算占 20%，旧版 75%，新版 78%，失败成本记为 3；越权请求占 10%，旧版 65%，新版 45%，失败成本记为 12。先看加权通过率：旧版 0.7×84 + 0.2×75 + 0.1×65 = 80.3%，新版 0.7×90 + 0.2×78 + 0.1×45 = 83.1%，看似提高了 2.8 个百分点。只看这张表，新版在最大流量的切片上进步明显，越权切片的退步被 10% 的权重稀释了。

再看风险损失，即把每个切片的失败概率乘上它的失败严重度：旧版为 0.7×0.16×1 + 0.2×0.25×3 + 0.1×0.35×12 = 0.682；新版为 0.7×0.10×1 + 0.2×0.22×3 + 0.1×0.55×12 = 0.862。其中每个 1−通过率 就是该切片的失败概率：越权切片从 0.35 恶化到 0.55，再乘上 12 的失败成本，单这一项就从 0.42 涨到 0.66。整体风险损失从 0.682 升到 0.862，恶化了约 26%。平均通过率的 2.8 点提升，在风险维度上是净倒退。

把这两个计算写成通用形式。门禁案例的输入是切片权重 wi、通过率 pi 和失败严重度 ci，输出是两个量：加权通过率 PassWeighted 与风险损失 RiskLoss。前者是 Σwi×pi，衡量整体通过比例；后者是 Σwi×(1−pi)×ci，衡量失败概率按严重度加权后的期望损失。这个例子说明的正是：总通过率提高，而 RiskLoss 从 0.682 升至 0.862，高风险切片的退化没有被平均抵消。

但实际门禁不应该依赖 RiskLoss 这个数本身。原因在于 ci 是一组效用权重——把一次越权失败折合成 12 个普通单位——而权重本质上是价值判断，充满争议。实际做法是先定硬门槛：越权切片“不得低于旧版且至少 60%”。按这条门槛，新版 45% 直接失败，根本不需要争论 12 这个数字是否合理。成本权重只用于排序修复优先级：风险损失最高的切片先修；硬门槛则用于保护不可交易的约束，任何平均分都无权抵消。

这里还藏着一个组织层面的因果：失败成本由业务、法律和受影响的人共同决定，不是评测工程师单独填写的技术常数。把成本权重写死在评测脚本里，等于把价值判断伪装成价值共识——数字看起来客观，实际上只是一个人的估计。发布决策需要的不是更精巧的加权公式，而是硬门槛先执行、争议权重仅用于排序这两条纪律。

端到端掉分之后，怎样判断问题出在模型、检索还是提示？单纯观察每个组件的指标只能得到相关性——检索分数降了，端到端分数也降了，两者同时发生不等于一个导致另一个。组件消融做的事情，就是把相关性变成修复线索：保持同一批输入，冻结其他变量，只替换一个组件，然后观察端到端结果的变化。

针对不同的怀疑对象，消融实验有对应的设计和可支持的结论。怀疑生成器时，用 oracle 证据消融：把正确的金标条款直接塞给生成器，绕开检索这一环。如果拿到正确证据仍然答错，问题偏向生成环节或规则设计；如果拿到正确证据就答对，说明问题在召回上限——检索没把需要的条款找出来，而不是生成器不会用。这个实验把“召回上限”和“生成利用”两个因果分开了。怀疑索引时，固定同一个模型，只把旧检索换成新检索，提示词和采样参数保持不变，端到端的变化就可以估计索引版本的影响。怀疑工具环节时，用工具回放消融：把之前记录的工具返回结果原样回放，让每次评测面对完全相同的 tool responses，外部服务的波动就被隔离出去；此时端到端差异不再可能来自工具的不稳定。怀疑渲染或规则时，用规则开关消融：同一批样本成对运行——规则开一次、关一次——对比结果可以估计护栏带来的收益，以及它是否引发了过拒绝。

这里有一条容易走偏的边界：组件分数本身并非最终目标。检索的 Recall@5 提升可能只是塞入了更多干扰项，反而降低生成的忠实度——召回率越高，答案越不忠实，这样的组件“进步”对任务是有害的。工具调用准确率高也可能表现为不该调用时过度行动——工具成功执行本身不等于动作是必要的。所以消融的价值在于缩小因果候选集，而不是证明某个组件独立决定了结果。

消融实验的输入是同一批样本、被冻结的其他变量和一个待替换的组件，输出是关于检索、生成、工具或渲染哪一环造成了端到端差异的因果线索。每个设计都对应一条纪律：oracle 证据消除召回限制，工具回放隔离外部波动，规则开关估计护栏作用。反过来，一次改变多个因素就完全无法归因——同时换了模型、检索和提示，端到端变了，谁负责？所以受控消融的底线是：每一轮只动一个变量。

因果线索最终要接回验收：消融只能把“嫌疑范围”缩小到某一层，最终是否修复成功，仍然要回到业务任务的整体验收。把某一层的指标修漂亮而端到端没有恢复，说明因果候选猜错了，或者还有第二个原因没被消融出来。消融是诊断工具，不是发布依据。

离线评测集全部通过之后，为什么不能直接全量切换？因为离线回放能看到的一切，都是旧数据和模拟环境里的东西。它快、安全、可重复，却看不到真实用户怎么反应，也看不到外部服务在生产环境里发生了什么变化。离线的满分回答的是“在固定样本上对不对”，不是“在真实流量里会怎样”。从离线到全量之间，需要一条逐步加大真实性的发布阶梯。

第一级是离线门禁：所有硬切片过线，主指标的差值区间满足要求。这一级回答的是资格问题——不合格的候选根本走不到下一步。第二级是影子流量：让新版处理真实的线上请求，但结果不展示给用户。因为不展示，风险几乎为零；但它能测到离线测不到的东西——真实输入的分布、容量、延迟、版本记录，以及工具读操作的执行情况。影子阶段的边界是绝不执行不可逆工具，读操作可以放开，写操作必须禁止。第三级是小流量发布（金丝雀）：这时才第一次观察真实交互。金丝雀必须按稳定的用户单位随机分配，防止同一个会话在版本之间跳来跳去——用户这一轮看到新版、下一轮变回旧版，体验会失真，归因也会混乱。这一级同时要监控伤害、完成率和人工接管情况。

每一步扩大都必须带着实时硬护栏、停止规则和回滚能力。扩大时每级保持观察窗口：没有观察窗口的扩大等于把实验当发布。越权行为、p95 延迟或错误预算任何一项超过阈值，立即回滚——这个停止动作应当是自动的，而不是等评审会。回滚能力必须在扩大之前就存在，否则所谓“小流量”只是换了名字的全量。

这一整套流程的输入是离线门禁、影子结果、金丝雀指标和回滚阈值，输出是一个三选一的决定：继续扩大、停止或回滚。各级之间的因果分工是：离线先证明硬切片合格，影子验证真实输入和容量但不触碰不可逆动作，金丝雀才观察真实交互，每一级都靠观察窗口判断是否进入下一级。

最后还有一条关于线上信号的边界：用户点赞是弱信号。沉默不代表正确——大多数用户不会举报一个温和的错误；满意度甚至可能奖励过度承诺——系统越敢承诺，用户当下越满意，但承诺无法兑现的损失由后台承担。所以线上行为指标必须与抽样人工审查和确定性业务结果组合使用：行为指标负责发现异常，人工审查和业务结果负责判断真伪。单看点赞率做发布决策，等于把风险交给沉默的大多数。

持续把每一个线上失败都加入测试集，为什么仍可能越测越不可信？因为测试集的生命周期被忽视了。一个失败样本被加入固定集之后，团队随即针对这道题调参，下一次评测通过，这个过程重复足够多次，集合就不再是“真实任务的抽样”，而逐渐变成了训练信号本身：系统学会了这些具体题目，而不是学会了任务。与此同时还有两个老化机制在叠加：重复近邻让某种事故被过度计权——同一个失败以十个相似变体出现，这一事故就被计了十次权重；旧政策又使答案失效——政策条款已经改了，样本里还按旧规则判对错，通过或失败都不再有意义。

要让评测集可控地新陈代谢，每条样本都需要记录元数据：来源、创建时间、适用政策、个人信息处理方式、去重簇和退役条件。来源和创建时间回答“这条样本为什么会在这里”；适用政策把样本绑定到具体政策版本，政策变更时才能定位哪些样本需要重审；个人信息处理标记样本是否含隐私数据及其处理许可；去重簇防止近邻变体重复计权；退役条件写明这条样本何时该退出，而不是永远留在集合里。

元数据只是前提，真正的治理在于版本流程。失败样本不是直接进固定集，而是走“发现池→审核→开发集→下一版冻结集”的路径：新发现的失败先进入发现池，审核确认它真实、不重复、不含无效政策之后，进入开发集供日常迭代，只有到下一个版本才进入冻结门禁集。当前发布门禁一旦冻结，就不能因为候选版本失败而删题或改 rubric——删掉让候选挂掉的题，等于现场修改及格线。确有必要的变更只能通过升版本完成，并且要同时保留旧版本的结果，保证跨版本可比。数据漂移监控的责任是提示何时该重采样——看到分布变化就自动重训反而是错误的反应，因为变化可能只是暂时的，先判断再行动。

这条治理链的输入是样本的来源、时间、政策版本、隐私状态、近邻簇和退役条件，输出是发现池、审核记录、开发集、冻结集以及下一版本的迁移记录。因果上，失败样本直接加入并反复调参会让门禁退化成训练集；冻结集不可因候选失败而删改；集合的更新必须走版本化的迁移而不是就地修补。

最后是评测本身的边界。评测只能降低已经建模的风险——你在集合里写下了什么样的失败，系统就在这些方向上变得可靠；它不能证明系统在开放世界里绝对安全。那些低频但不可逆的动作——一笔无法追回的转账、一条无法撤回的对外承诺——即便评测集里放了一千个样本，剩下的风险依然要靠权限约束和人在回路来控制。评测集做得再好，也不替代这两道防线。

评测这套方法的起点是一个具体问题：评审之间对“好答案”理解不一致时，分数无法指导上线。从这个问题出发，整个因果链可以一步步连通到可验证的实践，而且每一步都是对前一步缺陷的回应。

第一步，把业务成功拆成可判定属性。退款成功这个整体无法打分，资格、金额、证据、权限、追问、结构、延迟、成本这些原子属性可以逐条判定。拆解解决的是“好”没有共同基准的问题：有了属性和判定规则，两个评审才能共享同一把尺子。

第二步，从真实分布构造版本化样本。有了尺子，还必须有能代表真实任务的被测对象。手写题库制造虚假安全感，真实流量里的错别字、口语、冲突政策、越权请求和提示注入才是系统将要面对的分布。高频、高损失、历史事故、边界组合、线上抽样五个桶提供素材，开发集、冻结门禁集、挑战集、线上抽样集按用途分开，各自带版本和标签。这一步解决的是“测什么”的问题。

第三步，组合并校准评分器。有了样本，还要有可靠的测量方式。金额日期用程序断言，工具副作用用沙箱状态差异，证据支撑用主张—证据核验，语气帮助性用盲化 LLM 加人工；任何评分器都有系统偏差，所以要用金标样本测量精确率、召回率、位置偏差和文风偏差。观测分数 = 真实质量 + 评分器偏差 + 样本误差，校准让仪器误差可测，而不是可忽略。

第四步，运行端到端与组件消融。端到端结果回答“能不能上线”，组件指标回答“为什么”。当端到端掉分时，oracle 证据、同模型换索引、工具回放、规则开关这些消融实验把相关性变成因果线索，把“模型不行”改写成可执行的修复指令。

第五步，按硬门槛、切片和成本决策。数据齐了之后，决策规则决定一切。越权切片“不得低于旧版且至少 60%”这类硬门槛先执行，成本权重只用于排序修复优先级；切片加权通过率和风险损失分别报告，不让平均提升抵消高风险退化。这一步解决的是“分数如何变成决定”。

第六步，把生产失败经审核回流下一版。链条不能断在发布：线上真实失败进入发现池，审核后进入开发集，下一版本才进入冻结门禁集。失败样本直接加入并反复调参会让门禁退化成训练集；回流必须有来源、时间、政策版本、隐私状态、去重簇和退役条件这些元数据支撑，并保留旧版本结果。

这六步构成一个闭环：属性拆解让目标可判定，版本化样本让目标对应真实分布，校准评分器让测量可信，端到端加消融让结果可解释，硬门槛让决策可执行，失败回流让评测集随世界一起更新。环上任何一处断裂，都会在另一端显现：样本失真会让再好的评分器白费，门槛缺失会让再准的测量失去约束力。评测最终交付的不是一个分数，而是一条从业务成功出发、经测量、诊断、决策再回到样本更新的因果链。