跳到主要内容

AI 采购鸿沟:为什么你的供应商评估流程无法处理概率性系统

· 阅读需 12 分钟
Tian Pan
Software Engineer

我合作过的一个采购团队花了 11 周时间,对照一份 312 行的 RFP(征求建议书)电子表格给 4 家 LLM 供应商打分。他们谈妥了 99.9% 的正常运行时间 (uptime)、每 1K 输入 token 0.0008 美元的价格、SOC 2 Type II 认证,以及一份光鲜亮丽的基准测试 PDF——该文件显示他们选中的供应商在 MMLU 上领先 2.3 分。合同在周五签署。随后的周二,供应商悄然发布了一个模型更新,该团队构建的客服代理开始将大约 14% 的退款请求路由到错误的队列。正常运行时间 SLA 得到了遵守。基准测试得分没有变化。采购流程完全按照设计运行,而系统依然坏了。

这就是 AI 采购鸿沟。企业采购用于管理软件风险的工具——功能清单、正常运行时间保证、安全问卷、样本基准测试——都是为输出可重现的系统而构建的。这些工具都无法衡量真正决定 AI 供应商是否能持续为你工作的因素:由供应商控制而你无法控制的随机表面的行为稳定性。

RFP 之所以失效,并不是因为采购团队懒惰,而是因为底层产品的概率特性尚未渗透到供应商管理学科中。大多数企业采购框架都假设“供应商上周卖给我们的软件就是我们这周运行的软件”。当你与领先的模型提供商签约时,这一假设就会悄然瓦解,而标准合同语言中没有任何内容会告诉你发生了什么。

为什么功能清单和 SLA 都在骗你

功能清单是一个二进制的表面(“API 是否支持函数调用?”)覆盖在一个连续的表面之上(“函数调用在生成针对你的工具架构的格式良好的参数时有多可靠?”)。第一个问题可以在销售电话中得到“是/否”的回答。第二个问题得到的是一个分布,而不是一个答案,并且每当供应商重新调整模型权重、重新训练分词器或滚动安全过滤器更新时,该分布都会发生变化。企业 RFP 几乎从不问第二个问题,因为传统的供应商管理没有“我们需要结果的概率分布,而不是一个简单的‘是’”这种模板。

正常运行时间 SLA 更糟糕。99.95% 的正常运行时间保证仅意味着供应商的 API 会响应。它完全没有说明响应是否正确、格式是否良好,或者在行为上是否与你上个月针对相同输入获得的响应一致。从业者已开始将其称为“运行中但已损坏 (up but broken)”的状态——供应商的状态页是绿色的,你的监控显示零个 5xx 错误,而你的产品却在悄无声息地发生退化。当前 AI 采购中最危险的鸿沟正是这一点:企业依赖正常运行时间 SLA 来管理一个风险面,而在这个面上,正常运行时间是满足成本最低、且与用户体验相关性最弱的维度。

同样的鸿沟也适用于安全问卷。SOC 2、ISO 27001 和 PCI 控制旨在证明代码在认证和审计之间不会发生变化。它们没有、且在结构上无法证明一个模型的行为属性,因为模型的权重或采样参数可以在不违反任何这些控制的情况下被悄悄更新。

“自带评估” (Bring-your-own-eval) 的 RFP

替代方案在概念上很简单,执行起来却很难:用任务套件取代功能清单。与其询问“你的模型是否支持工具使用?”,不如向供应商发送一套从你的实际生产流量中提取的加密评估框架(经过适当的脱敏处理),并要求他们在记录的条件下运行。根据对你的任务至关重要的指标进行评分——架构符合率、对语料库外查询的拒答行为、真实并发下 p95 和 p99 的延迟、单次成功任务完成的成本——并将单次运行的分数视为毫无价值。概率系统需要分布评分:至少进行三次独立运行,报告均值和标准差,理想情况下返回完整的输出分布供你的团队检查。

一旦你采取了这种立场,就会出现几条实用的设计规则:

  • 使套件具有领域针对性。 供应商的 MMLU 分数几乎无法告诉你他们的模型能否处理你的保险理赔分类器或合同提取流水线。评估套件必须根据你的任务分布构建,而不是借用公开排行榜。
  • 包含对抗性示例和边缘案例,而不仅仅是正常路径。 供应商在处理正常路径时表现都会很好。但在长尾输入上,供应商之间的差距会急剧拉大。
  • 要求针对供应商更新进行回归运行。 评估套件不是一次性的关卡;它是针对供应商界面的持续集成测试。构建一次,然后每周针对你锁定的模型版本以及供应商正在推送的最新版本运行一次。
  • 根据校准度 (calibration) 而非仅仅是准确度进行评分。 如果一个供应商的模型在 8% 的时间里是错误的,但它知道自己什么时候可能出错,那么在运营上,这比一个在 5% 的时间里是错误的但对错误输出充满信心的模型要便宜得多。标准的准确度指标抹杀了这一区别。

结构性变革比技术性变革更难。拥有 RFP 主导权的采购团队通常不具备构建、维护和解释评估框架的工程能力。而具备构建能力的团队(将使用该模型的工程师)通常不在采购决策环内。弥合这一鸿沟本身就是一个组织设计决策:要么采购部门吸收评估工程能力,要么工程部门被赋予对供应商选择的否决权。中间路径——采购部门负责 RFP,工程部门运行并行的试点项目——会产生最慢的决策和最坏的结果。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates