指标一：自有评测成功率
用业务真实问题与标准答案建评测集，逐条判定通过与否。为什么不用公开榜单：榜单题目与你的业务分布不同，排名靠前的模型在你的场景里可能更差；边界是评测集要持续扩充，否则很快被过拟合。
指标二：单位任务成本
把花费除以通过评测的任务数，失败重试与人工接管一并折算。为什么这样算：便宜模型失败率高时，返工与接管的人力成本会吃掉差价；边界是人工折算口径由业务方确认，技术侧只提供工时估算。
指标三：分位延迟
取首字延迟与整体完成时间的分位值，分别对照交互与批处理场景。怎么做：在同一提示词与同款上下文档位下测，避免用短请求测出的数字去承诺长文档场景；边界是延迟受并发影响，要标注测试条件。
指标四：结构化与工具调用
统计结构化输出的合法率、工具选择准确率与多步任务完成率。为什么单独看：对话流畅不代表能稳定产出可解析的结果，很多系统上线后卡在这一步；边界是格式校验要覆盖边界输入与超长字段。
指标五：可替换性
评估接口抽象程度、版本停服政策与迁移成本。怎么做：保留一层适配、把提示词写成与模型无关的形式、定期用同组样本验证备选；边界是完全中立不现实，关键是知道换模型需要多少人天。
适用与不适用
适合谁
- 有明确业务场景与真实样本的企业
- 准备在多模型之间做长期选择的产品团队
- 对延迟与稳定性有明确要求的产品
不适合谁
- 尚无样本、只想先体验的团队与个人
- 只看单价与榜单排名、不做评测的采购岗位
典型场景
一家物业公司的工单分类要换模型。团队从历史工单里抽了三百条建评测集，把分类准确率、单位任务成本与延迟放在一起比较，再测结构化输出的合法率。最后选了一个榜单排名不高但在自有样本上更稳的模型。
可执行步骤
- 从历史数据抽取样本，建成带标准答案的评测集，并按季度扩充
- 用同一套提示词跑候选模型，记录成功率、成本与分位延迟三项对照
- 补测结构化输出合法率与工具调用准确率，覆盖边界与超长输入
- 评估迁移成本与停服政策，保留一层可替换的接口适配与回归样本
- 小流量灰度上线，用业务指标复核后再扩大范围，并留回滚方案
常见坑
- 只看公开榜单排名，选出的模型在自有样本上表现更差，回头又要重测，工期被拖长，团队也疲惫。
- 用短请求测延迟，长文档场景一上线就超时，用户直接放弃，投诉集中出现，解释成本很高。
- 只比单价不看失败率，返工与人工接管把省下的钱全花回去，还拖慢交付，得不偿失。
- 提示词深度绑定某家模型特性，换供应商等于重写，迁移成本被严重低估，续约时没有筹码。
自检与验收清单
- 是否有带标准答案、可复跑的自有评测集
- 成本是否按通过任务数折算，含失败重试
- 延迟是否在真实上下文长度下测过并记录条件
- 结构化输出合法率是否统计并覆盖边界输入
- 迁移所需人天与停服政策是否评估留档
常见问题
评测集要多大才够
没有固定数字，取决于场景复杂度与容错要求。分类类任务几百条通常能看出差异，开放生成类需要更多并配人工评分。关键是覆盖典型问题、失败样例与边界输入，并定期补充新出现的问题类型。
多模型混用会不会更复杂
会增加路由与评测的复杂度，但能兼顾成本与效果。做法是按任务难度分流，主链路保留一个稳定模型，其余走轻量模型；边界是要有统一评测与降级策略，否则问题定位会变得很困难。
模型更新频繁怎么跟
建立固定评测集与回归流程，更新前后各跑一次，比较成功率与错误类型。不必每次更新都跟进，但安全补丁与重大版本应评估；跟得太紧会增加验证成本，跟得太松会错过能力提升。