准备：候选不要多
开源与闭源各取一到两个候选即可，候选太多会让评测本身变成负担，也会稀释注意力。选择依据是任务匹配与部署条件，而不是榜单排名；把候选理由写下来，后面复盘才有依据，也便于向评审解释为什么是这几个。怎么控制候选数，按部署条件先筛掉一半。
评测：同一批任务
用三十到五十条真实任务，评分标准提前定好：要点覆盖、格式合规、是否拒答得当。评分人最好是业务方而不是工程师，否则容易只看技术细节，忽略可用性；两类人一起评，分歧本身也是信息。为什么让业务方评分，因为他们看得懂可用性。
指标：四个就够
通过率、P95 延迟、单任务成本、失败类型分布。四个指标足以支撑决策；再加更多指标，往往只是让报告变厚，反而不易比较，也拖慢节奏，最后没人愿意认真看完整份材料，更谈不上据此决策。怎么定指标，四个足够，多了反而看不清差别。
灰度：真实流量两周
选定后在一条业务线灰度，观察真实问法与接管情况；灰度期要有人值守，记录每次人工接管的理由。两周后再决定放量，避免用演示效果下结论，也避免把灰度当成走过场的审批环节，没人真正负责。怎么灰度，选一条业务线，派人值守两周。
记录：决策与退出
把候选、任务、指标、结论与未采纳理由归档；同时写下退出方案：如何切回原模型、评测如何重跑、数据如何导出。半年后回看，这份记录比演示更有价值，也能减少重复争论，新人接手也更快。怎么留档，把候选、指标与未选理由一起归档。
适用与不适用
适合谁
- 正在做模型选型、需要证据链的团队
- 要在两周内给出建议的架构师团队
- 需要向管理层汇报选型依据的项目
不适合谁
- 只想要一个最好模型结论的决策者
- 没有真实任务、只能拿公开样例验证的团队
典型场景
某银行远程银行中心要在两个开源候选与一个接口方案之间选择。团队用四十条真实来电问题评测，评分由业务主管完成；结果显示接口方案在复杂问题上更稳，自建候选在术语一致性上更好。最终选择接口方案做主力、自建候选做敏感数据分流，并把路由规则写进方案。
可执行步骤
- 各取一到两个候选，写明入选理由、排除理由与部署条件，留档备查
- 用三十到五十条真实任务统一评分，业务方参与并签字确认结果并留档
- 记录通过率、P95 延迟、单任务成本与失败类型分布，并留样本
- 灰度两周并记录接管理由，指定值守人与升级联系人，并做好交接表
- 归档决策记录与退出方案，写明重跑条件、责任人与联系方式与清单
常见坑
- 候选列了六七个，评测做不完，最后靠印象选了一个，报告也写不实，回头无法解释。全部原因。
- 评分由工程师独立完成，业务方不参与，选出的模型在真实场景里不好用，上线后又要换。
- 只测平均延迟、不看 P95，高峰时段长尾请求超时，用户体验断崖式下降，客服压力陡增。
- 没有退出方案，上线后发现不合适，切回旧模型要重做提示词与评测，拖了一个季度。返工。
自检与验收清单
- 候选数量是否控制在四个以内，理由是否留档
- 评分标准与评分人是否事先确定并签字确认表
- 四项指标是否都记录，并留存测试样本与截图
- 灰度是否有值守记录与接管理由，谁签字台账
- 决策记录与退出方案是否归档可查、可复现吗
常见问题
评测要多少条任务？
三十到五十条能支撑方向判断，覆盖常见、边界与拒答三类。任务太少会被个别样本带偏；太多则评测周期拉长，反而影响决策节奏，建议先定题再开跑，不要边跑边加题，否则结果无法比较。
开源与闭源能放在一张表里比吗？
能，但要注明部署条件差异：自建的成本含算力与人力，接口含用量与限流。把成本口径统一到单任务，再比效果，结论才可比，否则容易拿自建的边际成本去比接口的整体单价，越比越乱。
灰度期出问题怎么办？
先降级再排查：切回原模型或缩小范围，保留现场日志与失败样本。不要在灰度期直接改多处配置，否则问题定位会更难，回退也失去基准，最后只能凭感觉决定去留，团队信心也受损。