误区一：看榜单
榜单任务通常是公开题，和你的单据、术语、口径差得远。怎么做：抽一百条自家样本做小评测，记录通过率与失败类型；榜单可以筛掉明显不合适的模型，却不能当作选型依据，更无法解释上线后的失败。
误区二三：演示与漂移
演示用的是准备好的输入，看不出边界；版本漂移更隐蔽，供应商升级后输出风格与格式都会变。怎么防：锁定版本号或至少记录版本，升级前跑一遍回归评测，把提示词与校验规则一起回归，覆盖全部场景。
误区四：长上下文当记忆
上下文窗口大不等于记得住。把几十页文档塞进去，模型仍可能漏掉中段的关键约束，调用成本也随长度快速上升。怎么用：先做检索再拼接，关键约束放在开头与结尾，长文档分段处理并保留引用位置。
误区五：只比单价
单价低不等于总成本低。要看一次任务平均消耗多少用量、重试几次、人工兜底多少；返工与人工接管所花的人力，往往远超调用费用。怎么算：按一个月真实任务量估总量，再折算成单任务成本比较。
适用与不适用
适合谁
- 正在做模型选型、收到多份报价的团队
- 已上线一个场景、准备优化成本的负责人
- 希望避免上线后返工与追加预算的项目组
不适合谁
- 只按单价采购、不愿意做任何评测的团队
- 没有真实样本、也不打算收集的团队
典型场景
某电商企业原先按榜单选了模型，上线后商品标题生成格式经常出错。团队复盘后改为两层验证：先用两百条历史标题做离线评测，再让两个模型在测试环境跑一周影子流量；同时锁定版本号，升级前必须重跑评测并比对差异。
可执行步骤
- 把上次上线后出现的问题按模型、提示词与数据三类逐一归因，写成一张清单
- 抽一百到两百条真实样本，建一个规模小而固定的评测集，并附评分标准
- 锁定模型版本号，升级前重跑评测并逐条比对输出差异，确认无退化再切
- 按单任务用量与人工兜底工时核算真实成本，再与供应商报价对照表
常见坑
- 只看榜单与发布会信息做决策，忽略了自家的单据格式，上线后返工两周，排期全被打乱。
- 演示时用整理干净的输入，真实数据带错别字与缺字段，模型输出直接崩掉，现场无法收场。
- 不记录模型版本，供应商静默升级后输出变化，排查两周才找到原因，团队信任明显下降。
- 把长文档整段塞进上下文，中段信息被漏掉，回答看似完整却引用错段，核对成本转给业务。
自检与验收清单
- 是否用自家业务样本做过至少一次小规模评测
- 是否记录并锁定模型版本号，升级前留档，并纳入评测记录
- 升级前是否安排了完整的回归评测与差异比对
- 是否核算过单任务真实用量与人工兜底工时，而不是只看单价
- 长文档是否采用分段处理与检索增强的方式，并保留引用位置
常见问题
榜单完全没用吗？
有用，但只适合初筛。榜单能帮你排除明显不合适的模型，缩小到三四个候选；最终选择仍要看自家任务上的通过率、格式合规率与延迟，否则容易选出平均分高却不适合你的模型。
版本锁定会不会错过改进？
会，但可控。建议锁定主版本、按季度评估升级；升级前用固定评测集跑一遍，对比通过率与失败类型，确认没有退化再切换。这样既不错过改进，也避免被动承受行为变化，也便于向业务解释取舍。
上下文越长越好吗？
不是。长上下文解决的是能不能放进去，不解决能不能用对。多数任务用检索加分段更稳、成本更低；只有在需要整体理解的长文档场景，才值得用满窗口，并配合引用定位做校验。