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

我合作过的一个采购团队花了 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，工程部门运行并行的试点项目——会产生最慢的决策和最坏的结果。

对 AI 厂商至关重要的合同条款

一旦你改变了评估方式，合同也必须跟上。标准的 SaaS 合同模板至少存在四个专门针对 AI 厂商的漏洞。

模型变更通知期。 大多数服务商合同授予厂商单方面更新 API 端点背后模型的权利。对于具有行为依赖性的生产系统，这是不可接受的。为任何固定的模型版本协商至少 90 天的弃用通知期，并定义一个能触达你的工程团队而非财务收件箱的明确通知渠道。从业者在签约前越来越倾向于要求这一条款，严肃的厂商也会同意为企业客户提供此保障。小型厂商可能会推辞；这种推辞本身就是一个值得高度重视的采购信号。

容量预留。 公共速率限制（Rate limits）是一种共享资源。在服务商侧发生容量事件期间——如竞争租户的流量激增、区域性宕机故障转移，或由于模型发布占用了推理资源——你的流量优先级与其他人相同。对于那些延迟降低或硬性速率限制错误会导致收入损失的工作负载，你需要一个具有文档记录的余量（headroom）的预留容量层级。合同应明确底线：每秒处理多少请求、排队优先级如何、在什么条件下遵守底线，以及如果不遵守底线将适用何种补偿。

追踪数据的存储地，而不只是输入数据。 大多数厂商会告诉你他们在哪里处理你的输入 Token。但很少有厂商会告诉你他们在哪里存储推理追踪（inference traces）、用于滥用监测的 Prompt-Completion 日志，以及当你的使用触发内容过滤器时他们收集的评估数据。对于受监管的行业——医疗保健、金融服务、受 GDPR 约束的欧盟辖区——这种区别至关重要。你的数据处理协议（DPA）需要包含涵盖系统发送给厂商的每个字节的全生命周期的语言，包括厂商通过观察你的流量生成的数据。

评估透明度和方法论披露。 目前 AI 采购中最被低估的条款是要求厂商披露（如有必要可在 NDA 框架下）其内部用于验证模型更新的评估方法。如果一家厂商愿意分享其内部回归测试套件、可接受的性能下降阈值以及发布前的辅助人工评估协议（human evaluation protocol），那么它是在向你展示其运营成熟度的核心信息。拒绝披露或试图用一份 Benchmark PDF 文件搪塞的厂商，同样是在向你传递核心信息——只是不太体面。这一条款比其他条款更难谈判，因为它在文化上比较新颖；但它也是区分“你可以建立多年依赖关系的厂商”和“会在某个周二让你措手不及的厂商”的关键。

厂商的评估方法论究竟告诉你了什么

采购界的传闻说，Benchmark 是跨厂商的可比指标。事实并非如此，原因有二。首先，Benchmark 是公开的；厂商会针对它们进行训练（无论是刻意为之还是由于数据污染），从你特定工作负载的角度来看，两个尖端模型在公开评估中的得分差异大多只是噪声。其次，Benchmark 回答的是“这个模型在这个固定任务上表现如何？”——这个问题几乎从未与你的问题匹配，即“这个模型处理我产品生成的特定分布输入的可靠性如何，以及这种可靠性能否在接下来的三次模型更新中保持？”

真正区分严肃厂商的信号是接触到他们自身的质量控制体系。当你能看到一家厂商如何思考回归——他们认为什么是回归、触发发布阻断的阈值是什么、在推送前如何针对历史用户流量进行验证——你从这一份文件中了解到的信息比从任何第三方排行榜中得到的都要多。运行复杂内部评估的厂商，其模型行为是由希望之外的东西约束的。而直接发版并观察支持队列的厂商则不然。

这也是应对未来模型变更最有效的防御信号。厂商在第一季度卖给你的模型不会是第四季度运行的那个。持久存在的是产生这两个模型的方法论和工程文化。如果方法论是严谨的，那么第四季度的模型行为很可能在你第一季度验证过的评估范围内。如果方法论是“看情况再说”，那么任何合同条款都救不了你。

新的采购闭环

取代长达 11 周的 RFP 表格的是一种更接近于持续采购职能而非一次性事件的流程。选择的瞬间缩小了，持续的衡量扩大了。一个有效的版本大致如下：

• 预选阶段（数周）： 从生产流量中构建“自带任务”套件。定义分布验收标准——不是“必须达到 85% 的准确率”，而是“在三次运行中，p50 Schema 一致性必须超过 0.97，且标准差低于 0.02”。让两到三家候选厂商在相同条件下通过同一套测试体系，比较分布情况，而非单点估计。
• 签约阶段（数周）： 在标准 SaaS 条款之外协商上述四个 AI 特有的条款。拒绝那些不承诺模型变更通知期的厂商；这是一个关于他们对待企业客户认真程度的结构性信号。
• 版本锁定与影子运行（持续）： 锁定你接受的模型版本。每周针对锁定版本和厂商推送的任何新版本运行评估回归测试。其差异就是你的迁移缓冲期。
• 持续重新谈判： 将这种关系视为一种受管的依赖项，而非一成不变的合同。容量需求会增长，评估会扩展，监管范畴会转移；应该按定义的节奏重新审视厂商关系，而不是等到 SOC 2 审计时才处理。

以这种方式运作的团队——目前还很少——具有一个共同的结构特征：工程团队拥有评估体系，法务团队拥有合同层面，采购团队拥有关系节奏。这三个职能之间的交接是目前大多数企业泄露风险的地方。堵住这个漏洞需要采购组织愿意承认其现有的博弈策略对 AI 无效，并且承认这一点的成本与生产环境中等待发生的静默回归成本相比微不足道。

做对这件事的企业买的不是模型。它买的是一份附属于概率表面的测量合同，其中包含了该表面允许波动的明确条款，以及用于捕捉波动情况的明确工具。这种思维模型是 AI 真正需要的采购原语，目前尚未出现在任何标准策略中。率先建立这一模型的采购团队——内部推进、过程痛苦、在监管机构强制干预之前行动——才能将周五的签字变成在周二依然有效的保障。