可追责性
定义
可追责性，是指 AI 系统产出的每个结论，都能够被事后回溯到它所依赖的具体数据、规则、判定链路以及发生时间。
它关心的不只是“结果有没有重复出现”，更关心“这个结果为什么成立、由谁判定、依据是什么、哪一步得出的”。
在本文语境里，可追责性与“可复现”“正确性”并列，但层级更高：
- 可复现：同一个输入，系统反复给出同一个输出。
- 正确性：输出符合事实、符合业务口径。
- 可追责性：当结果被质疑时，系统能把依据一条条摆出来。
作者明确指出：同一份结论，光做到每次都一样没有意义；真正决定企业是否敢把它写进工作流、拿去向上汇报的，是在出事时能不能查到“是哪一步、按什么依据得出的”。
在本文档中的语境
本文讨论的是 ToB AI 落地，尤其是财务、报表、合规审查、招投标评审这类零容错场景。
在这类场景里，客户表面上常问的是：“同样的问题，下周再问一遍，能不能给我一模一样的数？”
但作者认为，这句话真正对应的采购需求并不是单纯的“重复一致”，而是：
- 结果要对；
- 结果要稳定；
- 结果要在被问责、被复议、被审查时拿得出依据。
因此，可追责性 是对“确定性”更贴近商业现实的翻译。客户嘴上说的是确定性，真正购买的是可追责性。
这也是为什么文中最后把“确定性即商业模式”进一步改写为：可追责性，才是商业模式。
为什么它重于单纯的重复一致
作者专门强调：可复现，不等于正确。
一个系统即便实现了严格可复现，也可能只是“稳定地错”。
文中的表达很尖锐：同一个错误答案，问一百次，它可以一字不差地错一百次；可复现只是把错误冻得结结实实，并没有把它改对。
因此，在 ToB 业务里，只拿“每次都一样”去回应客户，并不能真正解决问题，因为客户要的不是一个稳定重复的错误，而是一个：
- 又对，
- 又能复现，
- 还敢让他签字向上汇报的结果。
而“敢签字”的前提，恰恰不是重复一致本身，而是出了事之后能够倒查依据。这就是 可追责性 相比单纯可复现更重要的原因。
关键机制：每个结论都能回溯依据
在本文的工程思路中，可追责性 不是一句治理口号，而是由一套明确的系统分工支撑的。核心原则是：
- 模型只负责“理解和组织”；
- 真正下结论的环节交给确定性的规则与校验；
- 每一步都必须留痕。
这意味着，一个最终结论如果要可追责，系统至少要能回答以下问题：
- 这个结论依据的是哪份数据；
- 命中的业务规则是哪一条；
- 判定链路经过了哪些步骤；
- 结论是在什么时间点生成的；
- 如果有争议，能否把整个过程重新调出来核对。
文中把这种能力概括为“可审计”，但其落地表现就是可追责性：不是只给结果，而是能给依据、给路径、给时间记录。
与 确定性笼子 的关系
可追责性 不是脱离工程架构单独存在的，它建立在 确定性笼子 之上。
文中提出，ToB 场景不去直接消灭大模型内核中的全部不确定性，而是用确定性的工程链路把概率性的 LLM 包起来。这个笼子至少包括四道关卡：
- 意图层和执行层分家：LLM 只把自然语言翻译成结构化查询意图，不直接碰真实的数据计算。
- 执行前规则校验：例如 SQL 要先检查字段是否正确、口径是否合规、是否越权；不合格直接打回，不能进入生产执行。
- 结果后交叉验算：关键数字要用确定性算法再次核验，对不上就报警，而不是直接展示给客户。
- 可回退机制：任一环节出现模型抽风或服务异常时，系统可以优雅降级到保守但正确的默认行为。
这套架构先解决“交付给客户的结果必须受控”，而 可追责性 则在其基础上再往上加一层：
- 不仅结果受控；
- 还要把受控过程记录下来；
- 让之后的质疑、复议、审计都有据可查。
换句话说，确定性笼子 是交付正确结果的工程基础，可追责性 是把这套基础变成可签字、可审查、可担责业务系统的关键。
规则判定为什么必须完整留痕
本文最强的一点，是把“留痕”从技术偏好提升成了业务刚需。
作者参与过一个部委级 AI 招投标平台，并给出了一个非常具体的案例。
在一次评审结束后，落标方提出质疑，认为中标方的一条“类似业绩”不应算数：虽然合同金额达标，但服务期与招标文件规定的口径相差两个月。
在复议会上，系统并不是靠口头解释来应对，而是把整条判定链路逐一调出，包括：
- 资格条款对应招标文件中的哪一条；
- 被审查业绩出现在投标书的哪一页；
- 规则引擎命中“不达标”的是哪一行规则；
- 该判定发生的具体时间戳。
因为这些信息都能完整回溯、逐条对照，最后对方没有继续追问。
这个例子说明，ToB 中真正经得起质疑的，不是“模型看起来很聪明”，而是：
- 模型只负责从一沓 PDF 中把相关业绩读出来、对到条款上；
- “达标/不达标”的结论由确定性规则作出；
- 规则判定全过程有完整留痕。
因此，规则判定必须完整留痕，不是为了内部排障好看，而是为了在外部合规质疑、复议、审查、责任追溯中，系统能够像证据链一样自证。
可追责性服务的对象：合规质疑与复议
可追责性 的直接服务对象，就是那些“结果会被挑战”的时刻。
文中明确点出的典型场景包括：
- 合规质疑；
- 复议；
- 业务追责；
- 需要向上汇报、签字背书的流程。
这些场景的共同点是：系统不是只需要“再跑一次给出同样答案”，而是需要“解释为什么上次会得出这个答案”。
所以，可追责性本质上是一种面向争议处理的能力。
如果一个系统只能重复结果，却不能提供：
- 数据出处，
- 规则依据，
- 判定过程，
- 时间记录，
那么一旦结果被挑战，它就无法承接正式业务责任。这样的系统可以做演示，但很难进入关键流程。
不要把“确定性”误解成“把不确定性彻底消灭”
本文还有一个重要边界：可追责性 并不要求把大模型底层彻底变成逐字确定。
作者讨论了 SGLang 基于 Thinking Machines 工作提出的 batch-invariant kernel：它通过固定累加顺序，让同一个输入在不同批次条件下也得到完全一致的输出。
但文中认为，这种底层逐字一致对多数 ToB 查询场景并不划算，原因有两类：