AI 输出波动性是你可能定价不足的业务风险

当公司谈论 AI 风险时，对话通常集中在那些显而易见的失败上：幻觉事实、偏见输出、以及生成内容带来的法律责任。而较少受到关注的是一个更隐蔽的结构性问题：你已经在其输出本质上是概率性的系统之上，做出了商业承诺——定价层级、SLA（服务等级协议）、面向客户的准确性声明。每次模型生成响应时，它都是在从分布中采样。而合同中从未提及“分布”。

这是一个大多数团队发现较晚的业务风险，通常是在客户抱怨同一个文档审查工作流在周一和周五给出了完全不同的结果时，或者当监管机构要求提供系统在架构上无法提供的可复现性保证时。

非确定性比你想象的更深

大多数工程师都知道 temperature > 0 会引入随机性。常见的解决方案是在一致性至关重要的生产工作负载中设置 temperature = 0。但较少团队知道的是，temperature = 0 并不保证输出完全相同。

对现代大语言模型推理的研究指出了 temperature 控制无法消除的几种结构性方差来源。GPU 浮点运算是不满足结合律的：当同样的计算分布在不同的硬件配置、不同的 batch size 或不同的 CUDA 内核执行顺序上时，累积的舍入误差就会产生分歧。使用混合专家（MoE）架构的模型进一步加剧了这一问题——token 根据当前的 batch 组合竞争专家缓冲区插槽，因此与不同并发请求一起处理的相同输入可能会走过网络中不同的路径。

OpenAI 的文档直接承认了这一点：即使使用了 seed 参数且 temperature = 0，API 也只能保证“大部分确定性”的输出。测量 temperature = 0 时实际方差的研究发现，根据任务类型的不同，相同输入的准确率波动可能高达 15%。对于重推理的任务（数学、逻辑、多步规划），对 Prompt 的微小改动非常敏感：措辞略有不同的同一个底层问题可能会让模型从“我不知道”转变为正确答案。

这对生产系统的启示是令人不安的：如果你依赖统计一致性作为隐含的产品保证，那么你是在寄希望于运气，而不是在做工程。

业务风险暴露在何处

模型输出的方差创造了三个截然不同的商业风险维度。

运营风险显现得最快。当你的 AI 客服机器人给用户 A 批准了退款，而用户 B 的相同查询却被拒绝时，你现在除了处理原始的服务单，还需要处理一致性投诉。消费者投诉数据表明，AI 客服的失败率一直在急剧上升——这主要不是因为系统出错了，而是因为它们的错误是不可预测的。客户可以容忍一个持续报错的系统，但他们更难接受一个对不同的人产生不同错误的系统。

法律和合同风险积累较慢。标准的 SaaS SLA 定义了可用性、响应延迟和支持层级。它们是为确定性的软件系统设计的。应用于基于 LLM 的产品时，它们会产生漏洞：没有任何标准的 SLA 指标能够捕捉到“由于模型推理行为漂移，本季度准确率下降了 12%”。美国联邦贸易委员会（FTC）已经开始对那些对输出质量做出过于具体承诺的 AI 供应商采取执法行动——公司发现，当底层系统是概率性的，且客户因输出不一致而提起诉讼时，“尽力而为”和“行业标准准确率”的承诺在法律上会变得模糊不清。

财务风险在结构上最具挑战性。基于结果的定价模式（仅在 AI 成功完成任务时付费）在商业上很有吸引力，但将方差风险转嫁给了供应商。如果你的提取模型在不同文档之间存在 ±8% 的准确率方差，而你又承诺了“按成功提取计费”，那么你的收入就与你无法控制的因素挂钩了。只有拥有多年生产数据和严密运营对冲策略的公司，才能可持续地按结果定价。目前大多数构建 AI 产品的团队还不具备这种基础。

真正奏效的运营对冲手段

目标不是消除方差——在当前的推理系统中，这在架构上是不可能的。目标是对冲风险，使你的商业承诺具有可兑现性。

置信度门控承诺是最容易入手的切入点。不要将所有模型输出都视为同等有效，而是根据估计的可靠性对输出进行路由。高置信度的提取结果直接流向面向客户的界面。低置信度的输出则触发不同的路径——人工审核、二次模型处理或明确的降级提示。置信度校准本身需要投入：对于闭源模型，原始 token 概率是不可靠的置信度指标，因此务实的团队会使用一致性检查（运行两次相同的查询；如果输出分歧显著，则置信度较低）或思维链（Chain-of-thought）审查（要求模型解释其推理并检查内部矛盾）。

优雅降级层级意味着提前定义置信度较低时的“服务缩水”表现，而不是让模型去猜。一个完全置信的文档摘要系统可能会返回包含提取实体和置信度分数的结构化 JSON。在降级置信度下，它会返回一个标记：“高方差结果——在后续使用前需要人工确认”。客户看到的是一个较慢或人工的路径，但他们不会收到一个“自信地胡说八道”的答案。在 LLM 流水线中部署了熔断机制和回退缓存的组织报告称，可靠性从 99.2% 提升到了 99.87%——这不是因为模型改进了，而是因为故障模式变得可预测了。

针对高风险输出的集成投票通过汇总多次独立的模型运行或多个模型的结果来减少方差。通过三个不同的 Prompt 运行相同的分类任务并采用多数表决的结果，在实践中可以提高准确率，更重要的是，它缩小了方差范围。在内容分类基准测试中，集成多数表决达到了约 75% 的准确率，而表现最好的单次运行配置为 66%。成本是吞吐量和延迟——这是一种你应该有选择性地应用于商业上重要的输出端的对冲手段，而不是统一应用于整个流水线。

输出缓存值得被更广泛地采用。对于重复的输入——相同的 FAQ 查询、相同的文档模板、相同的结构化提取请求——缓存响应可以完全消除该输入的方差。基础设施层面的 Prompt 缓存（可从多个供应商获得）在长上下文请求中可减少 50–90% 的延迟和成本。应用层的请求-响应缓存确保相同的输入始终返回相同的输出，从而消除了大部分生产流量中的概率性因素。一旦团队开始进行监测，可缓存流量的比例往往比预期的要大。

加载中…