确定性笼子
定义
确定性笼子 是一种面向 ToB AI 落地的工程架构：不试图让 LLM 自身成为最终可靠、最终正确、最终可签字背书的决策者，而是用一套确定性的执行与校验链路把它包起来。
在这套架构里，模型的职责被严格收缩到“理解”一侧，例如自然语言理解、字段与条件抽取、查询意图翻译、非结构化材料中的信息定位与组织；真正承担“交付”责任的，是模型外侧的确定性工程系统，包括执行、规则校验、交叉验算、权限控制、异常回退和结果留痕。
它处理的不是“如何让模型永远逐字一致”这个问题，而是“如何在模型和服务系统都存在不确定性的前提下，仍然稳定交付正确、可复现、可解释、可追责的业务结果”。
在本文语境中的含义
本文讨论 确定性笼子 的背景是 ToB 场景中的零容错要求。企业客户嘴上常问“下周再问一遍，能不能给我一模一样的数”，但文章强调，这句话真正指向的不是单纯的可复现，而是三件事同时成立：
- 结果要对；
- 结果最好稳定可复现；
- 结果还要能拿出依据，让使用者敢签字、敢向上汇报。
因此，确定性笼子 不是“让模型更确定”的同义词，而是把“可复现”“正确”“可追责性”拆开后，优先用工程手段保障后两者，并在必要时再利用确定性约束去支撑前者。
这也是文章的一个核心判断：ToB 不在模型内核那一层正面解决全部不确定性，而是在模型外建立一套能够中和不确定性的承重结构。
为什么需要确定性笼子
文章先指出了一个前提：即使把 temperature 设为 0，LLM 也不必然确定。原因不只在采样策略，还在系统层不确定性。
生产环境中的 matmul、attention 等底层计算会受到并发和 batch size 变化影响；而浮点累加不满足结合律，累加顺序变化会让结果最后几位不同。对单个用户来说，同时并发进来的其他请求并不是自己的“输入”，却会改变服务系统内部的数值路径，因此负载本身就是非确定性的来源。
在这样的前提下，若把 ToB 可靠性交给模型本身，就会遇到两个问题：
- 第一，模型可能不稳定；
- 第二，即使底层完全可复现，也仍可能稳定地给出错误答案。
所以文章明确提出：可复现不等于正确。一个完全可复现的系统，也可能把同一个错误答案一字不差地重复一百次。确定性笼子 的意义，就在于不把“模型输出”直接等同于“业务结论”。
关键机制：四道关卡
文章把 确定性笼子 拆成四道串联的关卡，这四道关卡共同实现“模型负责理解，系统负责交付”。
1. 意图层与执行层分家
第一道关卡是把意图层和执行层解耦。模型只把自然语言请求翻译成结构化意图，而不直接碰真实的数据计算与最终结论。
例如，用户说“帮我看下上季度华东区毛利”，LLM 的职责是把这句话转成结构化查询意图：时间范围、区域、指标、可能的口径映射等；真正的查询执行、聚合计算和结果生成由传统确定性链路完成。
这意味着执行链路与模型解耦。即便模型环节抽风，甚至该环节服务不可用，下游的图表生成、数据校验等确定性模块仍可以独立工作，或者切换到保守路径，而不是让模型直接把未验证的答案送到用户面前。
2. 执行前规则校验
第二道关卡是在执行前做规则校验。模型生成的结构化意图或 SQL 不能直接运行，必须先过规则层。
校验内容在文中明确包括：
- 字段是否正确；
- 口径是否合规；
- 是否存在越权；
- 是否满足生产环境可执行要求。
只要不合格，就直接打回，不允许跑到生产库上。这一步的本质，是把模型的自然语言理解结果转化为“可被规则审核的中间件”，而不是让模型直接触达高风险系统。
3. 结果后交叉验算
第三道关卡发生在结果出来之后。即使查询已经执行，也不能默认结果可交付，还要用确定性算法对关键数字做交叉验算。
如果验算对不上，系统应报警，而不是把结果直接端给客户。这里强调的不是“模型说得像不像”，而是关键数字能不能被另一条确定性逻辑再次验证。
这使得最终交付不再依赖单一路径。模型理解可以是一条概率路径，但结果需要经过第二套确定性计算或规则校验后才能出站。
4. 异常时可回退、可降级
第四道关卡是回退与降级能力。文中要求：任何一环 LLM 抽风，系统都应能优雅降级到“保守但正确”的默认行为，而不是把错误答案堂而皇之地交给用户。
这里的“保守”不是体验最优，而是风险最小。比如宁可返回无法确认、需要复核、转人工、退回固定报表口径，也不应在高风险业务场景中输出未经兜底的模型答案。
因此，确定性笼子 不是“模型永不出错”，而是“模型出错时系统仍可控”。
这套架构到底约束了什么
文章对 确定性笼子 的描述非常明确：它并没有解决模型内核的不确定性，也没有试图修复每一次 token 抖动。它做的是把不确定性限制在最内层，并让每向外一层的输出都被确定性逻辑再约束一次。
也就是说：
- 模型内部仍可能抖动；
- 但抖动先被抽象为语义层的意图；
- 意图要么通过校验，要么被打回；
- 执行结果再被验算；
- 异常时再被降级路径兜住。
最后，客户看到的永远不是模型“原始说法”，而是通过所有关卡后的结果。这个事实是 确定性笼子 的交付定义：客户只看到过关后的结果。
不要把确定性推到底
文章专门反对一种常见误区：既然不确定性深到了内核，那就继续往底层推，硬把推理过程也做成逐字严格确定。
文中以 SGLang 基于 Thinking Machines 工作提出的 batch-invariant kernel 为例，说明这种路线虽然技术上可行，但对大多数 ToB 查询场景并不合算。
其要点包括：
- batch-invariant kernel 试图让计算结果不再依赖同批请求数量；
- 这样同一个输入会走同样的累加顺序，输出可以字字一致；
- 但代价是推理速度下降。
文中引用的数字是：开启 batch-invariant 后，推理减速约 25% 到 45%，主流后端平均在三成以上；而且官方明确说明，这主要用于调试和复现。