Prompt Engineering 评估：建立可重复的测试集与回归门禁

从失败定义开始

如果没有明确失败定义，评估就会退化成“看起来不错”。先把关键维度拆开：

• 事实是否来自允许来源。
• 是否满足输出 schema。
• 是否遵守业务与安全边界。
• 是否覆盖用户真正需要的内容。
• 是否能被下游流程稳定消费。

关键维度应设置硬门槛。例如事实准确性失败时，即使文风很好，也不能判为通过。

构建最小评测集

初始评测集不必很大，但必须有代表性。建议至少包含：

1. 标准输入。
2. 信息缺失。
3. 指令冲突。
4. 超长上下文。
5. 工具返回错误。
6. 诱导越过边界的输入。

每个样本记录输入、期望行为、禁止行为和评分方法。样本本身也要版本化，防止评估标准在迭代中悄悄变化。

评分器设计

可以混合使用确定性检查和人工评审：

JSON schema       → 自动
禁止词与权限      → 自动
事实来源存在      → 自动 + 人工抽检
解释是否清晰      → 人工或独立 Evaluator
任务是否真正解决  → 人工场景验收

不要让同一个生成过程同时担任最终评审。独立 Evaluator 应看到需求和输出，但不替生成器寻找借口。

版本对比

评估结果至少记录：

新版本只有在关键失败不增加、目标指标改善且回归集通过时才可替换旧版本。

失败分类与修复

• 事实错误：补充来源约束或检索步骤。
• 格式错误：强化 schema 与运行时校验。
• 遗漏要求：把复合任务拆成检查清单。
• 过度回答：加入范围和长度边界。
• 不确定时猜测：增加“待核实/升级”行为。

反模式

• 每次只用一个示例手工试验。
• 改 Prompt 的同时改评测标准。
• 只看平均分，不看关键失败。
• 用生成器自己解释为什么应该通过。
• 没有保留失败样本，导致同类问题反复出现。

可执行清单

• 成功与失败均可被观察。
• 数据集覆盖正常、边界、冲突和工具错误。
• 关键维度采用硬门槛。
• Prompt 与数据集都有版本号。
• 每次修改运行完整回归。
• 失败样本进入后续评测集。