考察点
「你怎么知道你改的 Prompt 变好了」是面试官检验候选人工程成熟度的试金石。凭感觉看几条例子就上线的做法在真实业务里活不过一个月。追问方向：开放式生成没有标准答案怎么评、LLM 当裁判靠谱吗、评估成本怎么控制。
参考答案
第一步永远是建评测集
没有评测集谈评估都是空谈。评测集来源三条路：业务方提供的典型 case、线上流量的随机采样、历史 badcase。规模上，50 到 200 条精选 case 足够支撑日常迭代，关键是覆盖面——主要意图类别、边界情况、已知坑都要有。每条 case 带上期望输出或评分标准（rubric），格式校验类 case 还要写明「必须满足的硬性条件」。
评测集要当资产维护：脱敏、版本化、随业务补充。它和 Prompt 模板放在同一个仓库里同步演进。
分任务类型选评估方法
客观任务（分类、抽取、结构化输出）：有标准答案，直接算指标。分类看准确率和混淆矩阵——混淆矩阵比单一准确率有用，能告诉你新 Prompt 把哪两类的边界搞坏了；抽取任务看字段级 F1；JSON 输出看格式合规率和 Schema 通过率。全部自动化，成本几乎为零，改一次 Prompt 跑一遍。
开放任务（问答、摘要、客服回复）：没有唯一标准答案，三层组合拳：
- LLM-as-Judge：用一个强模型（GPT-4 级）按 rubric 打分。rubric 要具体：准确性、完整性、是否遵循格式、语气是否符合人设，每项 1-5 分并写出扣分理由。关键技巧是让裁判模型对比新旧两个版本的输出做 pairwise 判断（「哪个更好」），比绝对打分稳定得多——人对绝对分数都没概念，模型也一样。
- 人工抽检：LLM 裁判的结论必须定期用人工标注校准。我们的做法是每版抽 30 条人工评，算人机一致率，低于 80% 就调 rubric 或换裁判模型。完全不抽检的自动评估，时间长了必然跑偏。
- 硬指标兜底：格式合规率、敏感词命中数、输出长度分布，这些不依赖任何裁判，出问题最直接。
线上闭环
离线评测过了不代表线上好。上线后看业务侧指标：客服场景看问题解决率、转人工率、用户点赞点踩；内容生成场景看采纳率（用户是否直接使用生成结果）。点踩和转人工的 case 自动回流进评测集，评估体系就这样滚动起来。
另外别忘了成本指标：新 Prompt 如果 token 消耗涨了 30%，效果持平，那就是退步。效果、延迟、成本三个数字一起看，才是一次完整的评估。
常见误区
- 只看成功案例：改完 Prompt 挑几条效果好的例子贴在群里，这叫展示不叫评估。评估必须跑全量评测集。
- 裁判模型和被测模型同源：用同一个模型生成又打分，会系统性偏好自己的表达风格，分数虚高。裁判模型要比被测模型强一档，至少不同家。
- 一次评估定终身：模型输出有随机性，temperature 不为 0 时同一输入多次结果不同。重要结论要跑 3 次以上取分布，单跑一次的结果当不得真。
可能的追问
- 评测集太小跑不出显著差异怎么办？ 小差异（一两个点）本来就该视为噪声。要么扩评测集，要么看趋势——连续两三次迭代同方向变化才算数。
- LLM-as-Judge 有什么已知偏差？ 位置偏差（偏好先出现的答案）、长度偏差（偏好长的）、自我偏好。对策：pairwise 对比时交换顺序跑两次、rubric 里限制以长度论优劣、裁判与被测不同源。
- 多轮对话的 Prompt 怎么评？ 单条评不了，要用仿真：用一个模型扮演用户按剧本多轮对话，最后对整段对话按目标达成度评分；或者录制真实会话回放。