为什么榜单和跑分靠不住
MMLU、C-Eval 这些榜单测的是通用学术能力，跟你的业务关系不大。模型在 MMLU 上 88 分，不代表它能看懂你们公司的工单分类规则；反过来，一个跑分中等的模型在你那个狭窄的垂直场景里可能表现极好。榜单的另一个问题是污染——题目早就进了训练数据。所以榜单只用来做初筛，把候选范围缩到 2-3 个，真正的决策必须靠自己的评测。
第一步：建一个最小评测集
不用大，50-200 条真实 case 就够启动，关键是来源真实、标注明确。来源直接从历史业务数据里抽：客服场景就抽真实工单和人工标准回复，审核场景就抽历史判例，文案场景就抽被采纳的终稿。每条 case 要有三样东西：输入、期望输出（或评分标准）、这条 case 属于哪类难度。
评测集要有结构意识，我习惯分三层：六成是「日常题」，代表流量主力，模型在这层必须接近满分才有资格上线；两成是「难题」，长文本、多约束、专业术语，用来区分候选模型的高下；两成是「对抗题」，故意刁难的——诱导幻觉（问一个不存在的产品功能）、注入攻击（用户输入里藏「忽略之前指令」）、越界请求、中英文混杂、错别字连篇。对抗题决定的是产品的下限，很多事故都出在这层。
第二步：设计评分方式
有标准答案的（分类、提取、判断题）直接程序化比对，这部分要做到全自动。开放式输出（总结、回复、生成）用「模型当裁判」：拿一个更强的模型（比如测 GPT-4o 级别时用最强的模型当裁判）按写好的 rubric 打分，rubric 要具体到「事实错误扣几分、遗漏关键信息扣几分、语气不合适扣几分」。模型裁判跟人评的一致性大概能到八成以上，跑批量评测够用，但最终上线前对关键 case 要抽人复核。别嫌麻烦，这一步省掉，后面所有优化都是没有仪表盘的瞎开。
第三步：探测边界而不只是测水平
水平测试告诉你模型「行不行」，边界探测告诉你「到哪开始不行」，后者对 PM 更有用。我常用的探测手法：
- 长度边界：把输入从 2 千字逐步加到 10 万字，看输出质量在哪个点开始塌。很多模型标称 128K 上下文，实际过了三四十 K 就开始丢中间的信息，这决定你要不要上 RAG 而不是全文硬塞。
- 复杂度边界：单一指令到五个约束条件的复合指令，看从几个约束开始丢三落四。这决定 prompt 该写多复杂、要不要拆步骤。
- 数量边界：让它一次从 10 条、50 条、200 条记录里做提取或归类，看准确率拐点。这决定一次喂多少数据、要不要分批。
- 拒答和幻觉边界：问它知识截止日期之后的事、问细分领域不存在的东西，看它是老实说不知道还是一本正经地编。幻觉率高的场景必须在产品上设计引用溯源或人工确认。
把边界变成设计语言
探测完的产出不是一份测试报告，而是产品设计的输入：上下文边界决定功能形态（超长文档做分段摘要而不是一键全文问答），复杂度边界决定交互设计（把用户的一次性复杂需求引导成多步确认），幻觉边界决定兜底策略（关键数字一律展示来源、低置信度回复加提示）。好的 AI 产品不是用了最强的模型，而是把模型确定不行的部分用产品设计接住了。
别忘了回归机制
模型厂商会静默更新版本，今天的评测结论三个月后可能失效。评测集要跟着 CI 走或者至少每月跑一次，模型版本、prompt、成本、延迟一起记录。见过团队线上效果莫名变差查了一周，最后发现是厂商更新了模型，教训很实在。