ToB AI 确定性笼子 摘要
文档概览
文章从一个非常典型的误区切入：很多人以为把 temperature 设为 0，就能让 LLM 对同样输入永远返回同样输出。但作者指出，这种理解忽略了 系统层不确定性。即使采样不再随机，生产环境中的并发负载、batch size 变化、底层 kernel 的浮点累加顺序变化，仍然会让输出在最后几位甚至后续 token 路径上发生偏移。
作者把 ToB 场景与 ToC 场景明确区分：C 端容忍“大概率不错”，B 端要求“同一个问题问一百次，得到一百次同样且正确的答案”。这里面实际上混合了三个不同目标：可复现性、正确性、可审计性。文章的关键价值就在于把这三者拆开，并进一步指出：只追求可复现，不等于能交付正确结果；一个完全可复现的模型，也可能稳定地重复错误。
基于这个拆分，文章提出 确定性笼子 架构：不要试图在模型内核层面消灭所有不确定性，而是用确定性的工程链路把概率性模型包裹起来。模型只负责理解自然语言和组织语义；真正执行查询、校验字段与口径、交叉验算关键数字、在异常时回退到保守答案、并全程留痕的，是外层可控的工程系统。
文章进一步讨论了一条看似更“硬核”的路线，即通过 SGLang 基于 Thinking Machines 的 batch-invariant kernel，让同一输入无论 batch 如何变化都走同样的数值路径，从而实现逐字一致。作者认为这条路在 RL 训练或调试复现中有价值，但对大多数 ToB 查询场景是用错地方：代价是推理减速 25% 到 45%，主流后端平均三成出头，还会破坏 split-K、shape-aware tiling 等动态批处理优化，而 ToB 业务往往并不需要逐字一致，只需要结果正确且可追责。
最后，文章把真正的商业价值落点放在 可追责性 上。确定性只是产品“活过第二次演示”的门票；真正能成为护城河的是，当结论被质疑时，系统能否把规则、条款、数据来源、命中逻辑和时间戳完整摆出来。作者用一个部委级招投标平台的案例说明：模型只负责从 PDF 中抽取业绩信息并对齐条款，真正的达标/不达标结论由确定性规则引擎给出，并且必须支持逐条回溯。这种可追责交付，才是企业真正购买的能力。
关键事实
ToB 的核心约束是零容错
- 文章明确提出，ToB 和 ToC 的根本分野不在功能丰富度，而在容错率。
- C 端可以接受 AI 偶尔“抽风”，只要大概率不错甚至偶尔有惊喜即可。
- B 端不接受这种概率性交付。以财务报表、查询系统、合规判断等场景为例，今天一个数字对、明天同样查询结果却不同，这不是“个性”，而是事故。
- 作者把 ToB 的要求概括为“可复现的正确结果”：同一个问题，问一百次，得到一百次同样且正确的答案。
- 文中还以 ChatBI 为例说明企业级系统常见的三重约束是：推理得稳、响应得快、成本得算得过来；其中“稳”排在第一位，再快再便宜，如果结果不稳定，也没人敢用。
- 结论是：零容错不是口号，而是 ToB AI 所有架构决策的出发点。
必须区分三件事：可复现、正确、可审计
文章反复强调，企业场景中常把三个不同目标混成一个：
- 可复现性：同一个输入，永远给同一个输出。
- 正确性：输出符合事实、符合业务口径。
- 可审计性：每个结论都能回溯到依据的是哪条规则、哪份数据、在哪个时间点作出判定。
作者特别指出，可复现性 不等于正确性。即使一个模型在底层实现了完全复现，它也可能把同一个错误稳定地输出一百次。于是，客户嘴上说“下周再问一遍，给我一模一样的数”，真实诉求并不是“逐字一样”本身，而是“又对、又能复现、而且我能拿去汇报并承担责任”的结果。
这也是文章的逻辑支点：如果客户真正要的是正确结果，就不能只拿“让模型稳定输出同样文本”来回应，因为那只解决了复现，不保证正确，更不保证能够解释依据。
temperature=0 不能消除系统层不确定性
文章将不确定性的来源从采样层推进到系统层，给出一条较具体的因果链：
- 很多人误以为不确定性主要来自 temperature 等采样参数。
- 但在生产环境里，真正影响结果的一层在硬件和服务调度系统。
- 底层 matmul、attention 等 kernel 的输出会依赖当前一起计算的请求数量，也就是 batch size。
- 生产环境负载本身是波动的：这一秒可能 10 个请求一起算，下一秒可能 100 个请求一起算。
- batch size 改变后，浮点累加顺序会改变。
- 浮点累加不满足结合律，所以顺序变化会使结果在最后几位产生差异。
- 对 LLM 来说，这种数值细微偏移可能继续传导到后续 token 选择和整段输出，造成“同样输入，今天和明天输出不同”。
文中有一个很关键的表述：对单个用户而言，并发的其他请求并不是自己显式提交的“输入”，但它们却会影响系统输出，因此它们构成了系统的一个非确定属性。换句话说，负载本身就是 系统层不确定性 的来源。
作者借此强调：问题不是 prompt 写错，也不是 temperature 没调好，而是服务系统在并发调度这一层天然带着不确定性，而且这种不确定性深到内核层，连 temperature=0 都“摁不住”。
重要细节
确定性笼子：不要强行改造模型本体，而是用工程链路包裹它
文章提出 ToB 的正确解法不是在内核层和不确定性死磕，而是构建一个 确定性笼子。它的基本原则是：与大模型解耦。
所谓解耦，不是不用模型，而是把模型限制在最适合它的职责上：
- LLM 负责把自然语言翻译成查询意图，承担“理解”任务。
- 真正执行查询、做数值计算、生成最终结果的，是确定性的传统工程链路，承担“交付”任务。
- 即使 LLM 抽风或服务挂掉，下游图表生成、数据校验等环节仍应保持可靠运行。
作者把这套笼子拆成四道关卡：
- 意图层和执行层分家
- 例子是把“帮我看下上季度华东区毛利”这样的自然语言，先转成结构化查询意图。
- 模型只负责这个语义转换，不直接接触真实数据计算。
- 执行前校验
- 生成的 SQL 或查询计划先经过规则校验。
- 校验项包括字段是否正确、统计口径是否合规、是否存在越权访问等。
- 任何不合格结果直接打回，不允许落到生产库执行。
- 结果后验核查
- 查询结果出来后，不是直接返回给客户，而是再通过确定性算法对关键数字做交叉验算。
- 如果核算不一致，系统应报警，而不是把可能错误的结果直接展示出去。
- 可回退与降级
- 任何一环出现异常，系统都应优雅降级到“保守但正确”的默认行为。
- 文章强调，不能因为模型抽风，就堂而皇之把错误答案端给客户。
四道关卡串起来后的效果是：模型内部仍然可能存在不确定性，但它被逐层包裹、逐层中和。作者的原意并不是让模型真的变成数学上的确定系统，而是让客户最终看到的永远是“通过了所有关卡的那个确定结果”。
为什么不主张把确定性一路推到底
文章不是否认底层确定化技术，而是认为它在大多数 ToB 场景里不划算。
作者提到 SGLang 基于 Thinking Machines 的工作实现了 batch-invariant kernel，其目标是让计算结果不再依赖 batch 中同时存在多少请求，使同一个输入永远经历同样的累加顺序，输出做到字字一致。这条路线确实能直接处理前面提到的 batch size 导致的系统层抖动。
但文章给出两类反对理由：
1. 代价过高
- 文中引用的官方数据是：开启 batch-invariant 后，推理减速 25% 到 45%。
- 对主流后端而言，平均性能损失在三成出头。
- 官方还明确说明，这项能力“主要用于调试和复现”。
- 文章进一步提到，有更新的批评认为这种方式不适合真实的 LLM 服务系统，因为它把确定性变成每个请求都必须支付的固定税。
- 同时，它还会牺牲 split-K、shape-aware tiling 等支撑动态批处理效率的优化手段。