8.2
深览指数
科技人人都是产品经理·巫师Sorcerer··AI 生成
把 LLM 关进确定性的笼子：ToB AI 落地工程手册
本文论证了ToB AI落地的核心挑战不是模型能力，而是结果的可追责性。作者指出，LLM的不确定性根源在于系统层的并发调度，而非temperature参数，因此解决方案不在修模型，而在用确定性工程架构将概率性内核包住。文章提出了「确定性笼子」的四层架构（意图/执行分离、事前校验、交叉验算、可回退），并强调可审计性才是真正的商业模式护城河。适合ToB产品经理、AI架构师和SaaS创业者阅读，尤其适合正面临客户质疑AI可靠性的从业者。原文 ↗
核心观点
- ▍ToB AI商业化的核心不是模型有多聪明，而是能否交付「可被追责的确定结果」——可复现、正确、可审计三件事中，可审计性才是真正的护城河。
- ▍驾驭LLM的关键不是把它变确定，而是用确定性工程把它的不确定性精准关进笼子里，同时把剩下的抖动读出来作为风险信号。
- 01LLM不确定性的根因不在temperature参数，而在系统层的batch size变化导致浮点累加顺序不同，进而改变输出结果。
- 02作者提出「确定性笼子」四层架构：①意图层和执行层分离——LLM只负责翻译自然语言为结构化查询，不碰数据计算；②执行前SQL校验——检查字段、口径、权限；③结果交叉验算——用确定性算法核对关键数据；④可回退机制——任意环节抽风时降级到保守默认行为。
- 03SGLang的batch-invariant kernel虽然能从推理层根除抖动，但代价是推理速度降低25%-45%，且会破坏split-K、shape-aware tiling等动态批处理优化，不适合ToB查询场景。
- 04作者分享了一个部委级AI招投标平台案例：落标方质疑中标方的一条「类似业绩」资格，系统通过调出完整判定链路（条款编号、投标书页数、规则命中记录、时间戳）成功应对质疑。
反方 / 局限
- — 作者承认「确定性笼子」本身（解耦、校验、回退）是普通工程，人人能搭，并不构成护城河；真正的壁垒在于笼子里积累的行业规则、口径、判例，这些是拿一个个真实项目喂出来的。
- — 作者引用了Stochastic CHAOS的观点：把LLM的条件分布p(y|x)硬压成单点函数f(x)，会隐藏模型自身的不确定性，而方差本身是重要的信号，不应被完全消灭。
- — 可复现并不等于正确——一个完全确定的模型会稳定地、可复现地输出错误答案，这解释了为什么客户嘴上要「可复现」，实际要的是「又对又能复现还能签字汇报」的结果。
12 分钟 · 5 卡片 · 12 资料
读原文 →