Prompt 评测方法：用数据而非感觉判断好坏

没有评测的迭代是盲人摸象

Prompt 迭代中最常见的场景：改了一个词，看了三五个 case 感觉“变好了”，上线后长尾场景全面退化。原因很简单——五个 case 不是分布，感觉不是指标。评测体系要解决的就是：让每一次改动都有数据支撑，让“好”变成可计算的东西。

第一步：构建测试集

测试集是评测的地基，构建原则：

1. 来源真实：从真实用户日志、客服记录中抽样，不要自己拍脑袋编。自编 case 往往过于“标准”，测不出问题。
2. 分层覆盖：按场景维度分层——常见 case、边界 case、对抗 case（恶意输入、Prompt 注入）、格式极端 case（超长输入、混合语言）。
3. 规模起步即可：50-200 条就能支撑日常迭代，追求完美的三千条全集反而迟迟无法启动。
4. 带标准答案或评分要点：分类、抽取类任务给出 gold label；开放式生成给出“评分要点清单”（是否包含关键信息、是否有幻觉、格式是否符合）。

产品决策提示：测试集要随线上问题动态生长。每次线上发现 bad case，修复后把它加进测试集——这是最有效的回归测试机制，也防止同一个问题反复出现。

第二步：选择评测方法

方法	做法	适用	成本
人工点测	自己过一遍测试集	日常快速 sanity check	低
规则断言	程序检查格式、关键词、JSON 合法性	强结构输出	极低
LLM-as-a-Judge	用强模型按评分标准打分	开放式生成质量	中
人工标注评测	标注团队双盲评分	关键版本上线前	高
线上 A/B	分流量对比业务指标	最终验证	高（但最可信）

实践中通常是漏斗：规则断言筛掉格式问题 → LLM 评分粗排 → 人工精评关键版本 → 线上 A/B 定论。

LLM-as-a-Judge：怎么用才靠谱

用模型评模型的输出，是当前主流做法，但有三个坑：

1. 评分标准要具体成 rubric。“评一下质量好不好”会得到无区分度的分数；“从事实准确性（0-2）、完整性（0-2）、格式合规（0-1）三个维度分别打分并给理由”才有用。
2. 警惕偏好偏差。评审模型偏爱冗长、结构华丽的回答。对策：在 rubric 中明确“冗长本身不加分”，并用** pairwise 对比**（A/B 哪个更好）代替绝对打分，区分度更高。
3. 抽样校准。定期抽一批 Judge 的评分做人工复核，算一致性；一致性掉了说明 rubric 需要修订。

第三步：线上闭环

离线评测通过后，最终要看线上：

• A/B 实验：新旧 Prompt 版本分流，对比任务完成率、用户采纳率（如“是否点击了生成结果”）、修正率（用户重问/重写的比例）、人工转接率。
• 隐式反馈信号：点赞点踩、复制行为、会话中断率，都是质量的代理指标。
• bad case 回流管道：把低分会话自动截取（脱敏后）进入待分析队列，形成“线上发现 → 入测试集 → 离线修复 → 线上验证”的飞轮。

组织层面：让评测成为流程

几个被验证有效的实践：

• 任何 Prompt 变更必须附带测试集跑分结果，写进变更说明，就像代码上线要过 CI。
• 建立基线看板：当前线上版本的各维度得分、分场景得分，可视化呈现，退化一目了然。
• 换模型 = 重新评测。模型升级对旧 Prompt 不保证兼容，历史上“升级模型后效果反降”的案例多数源于此。

产品决策提示：评测体系的投入要匹配业务阶段。MVP 阶段 50 条测试集 + 规则断言就够；进入规模化增长期，再补 LLM Judge 和线上 A/B。反过来，一开始就搭重型评测平台，容易拖延上线时机。

本节要点

• 评测的本质是把“好”变成可计算的标准：真实来源、分层覆盖、带标注的测试集是地基，规模 50-200 条即可起步。
• 用漏斗组合四种方法：规则断言筛格式 → LLM 评分粗排 → 人工精评关键版 → 线上 A/B 定论。
• LLM-as-a-Judge 需要 rubric 具体化、防冗长偏好、定期人工校准一致性，pairwise 对比优于绝对打分。
• 线上 bad case 要回流进测试集，形成“发现—修复—回归—验证”的闭环飞轮。
• 换模型必须重跑评测；评测投入匹配业务阶段，避免过度工程或裸奔上线。