开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
如何用可重复测试集评测 AI 提示词，避免把单次好结果当成结论
Olivia Park
2026年9月4日· 9 分钟阅读
要可靠地评测 AI 提示词，应让每个 prompt revision 在相同版本的案例、配置、评分规则与发布阈值下运行。对可变输出重复运行，保留全部原始结果，把确定性失败与人工判断分开，并如实报告不确定性。一次看起来很好的回答只是演示，不是 benchmark。
AI 实用指南介绍通用验证和数据边界；本文假定任务已足够明确，目标是在不暗中改变问题的前提下比较提示词 A 与 B。
关键要点
- 写案例或看输出前，先定义本次评测要支持的决定。
- 冻结有代表性的案例集 revision，并尽量保留独立 holdout。
- 严重失败、确定性检查与偏好评分必须分开。
- 对齐模型、工具、参数、检索来源和运行条件。
- 人工评审要隐藏版本标签并随机排列顺序。
- 对可变输出重复运行，展示分布而不只展示最佳值或平均值。
- 挑战版只有通过明确的回归与安全门才能发布。
如何可重复地评测 AI 提示词？
可重复 benchmark 是另一位 reviewer 能够复跑和解释的实验记录，并不要求随机模型逐字返回相同答案。真正固定的是目标、输入、运行设置、评分、重复次数和决定规则，这样才有机会区分提示词变化与实验变化。
NIST AI RMF Measure Playbook 建议记录测量方法、测试集、指标、流程、材料及工具细节，因为这些记录是可重复性和一致性的基础。［1］
| 评测字段 | 必需记录 |
|---|---|
| Experiment ID | 稳定编号和运行日期 |
| 决定 | 比较结果要支持哪个选择？ |
| Prompt revisions | 不可变的 A、B 正文或引用 |
| Case-set revision | 精确案例、标签、排除项和 holdout 规则 |
| 输入 revision | 固定附件、检索快照和预处理 |
| 预期属性 | 好答案必须包含或保留什么？ |
| 严重失败 | 哪些结果无论总分多少都失败？ |
| Rubric | 维度、量尺锚点、权重和并列处理 |
| Scorers | 确定性检查与具名人工角色 |
| 配置 | 模型/工具类别、参数、系统指令和权限 |
| 重复 | 每个 prompt-case 运行几次，如何随机排序？ |
| 证据 | 原始输出、检查、评分和分歧 |
| 决定规则 | 回归阈值、不确定性规则、批准人与结果 |
这比写好一条提示词更窄：修改措辞负责产生候选，benchmark 负责提供选择证据。
步骤 1：先写评测问题和发布规则
用一句话写清决定，例如：“revision B 能否替换 A，用于从英文支持摘要抽取五个已批准字段？”列明输入人群、输出契约和排除用途。“哪个提示词更聪明”无法形成可辩护的案例集。
运行前列出严重失败，例如虚构事实、漏掉必需警告、泄露合成秘密标记、输出结构非法、听从输入文档内的指令，或建议未授权动作。风格平均分稍高也不能抵消一次严重安全回归。
只有同时满足以下条件才发布 B：
1. 固定严重案例集中没有严重失败；
2. 所有确定性契约检查不劣于 A；
3. 人工中位评分未越过批准的回归界线；
4. 没有任何规定类别越过失败阈值；
5. 已检查评分分歧和运行间波动；
6. 任务 owner 批准完整证据包。
阈值应来自任务风险和运营需求，不能看完结果再选择一个让 B 获胜的数字。NIST 也建议记录指标选择理由以及无法测量的风险。［1］
步骤 2：建立并版本化案例集
先写任务分类，再为每类创建获授权、已脱敏或完全合成的案例。至少包含常见输入、困难但有效的输入、字段缺失、证据冲突、结构畸形、长度边界、对抗指令，以及正确行为是拒答或追问的情况。
| 案例字段 | 含义 |
|---|---|
| Case ID | 例如 missing-owner-01 的稳定编号 |
| 类别 | 正常、边界、无效、对抗或拒答 |
| 输入 | 冻结的脱敏或合成材料 |
| 预期属性 | 必须保留的事实、字段或行为 |
| 禁止行为 | 虚构、泄露、越权动作或格式逃逸 |
| 严重度 | 严重、主要或次要 |
| 评分方法 | 精确检查、规则检查或人工量规 |
| 理由 | 为什么该案例代表目标用途？ |
| 来源与权限 | 模式来自哪里，是否允许评测？ |
不要默认把生产流量当测试集。从真实故障提取模式时，要最小化和脱敏，保留权限记录，并检查变换是否把要测的特征一并删掉。数据边界可参考AI 隐私风险清单。
把开发集和发布 holdout 分开。作者反复看到并据此调优的 holdout 已不再独立，应记录访问并通过治理变更新换案例，而不是悄悄编辑。
NIST GenAI 评测计划把生成器和 evaluator 分开，并按任务定义 challenge，而不是使用一个万能分数。［2］ 摘要、抽取和教学提示词也应采用不同案例与标准。
步骤 3：分开确定性检查和人工判断
代码能可靠判断的属性交给代码：JSON 是否有效、键是否准确、类型和长度、禁用字符串、ID 是否保留、引用是否连续、拒绝标记是否出现。不要让人工 reviewer 给解析器可以判断的语法打分。
语义质量用带可观察锚点的 rubric，不用“优秀”“一般”等模糊标签。可以用评分量规工作流起草，但量尺必须由任务 owner 批准。
| 维度 | 0 | 1 | 2 |
|---|---|---|---|
| 证据忠实 | 虚构或颠倒事实 | 大致有据，但含无支持推论 | 每项重要主张都能对应输入证据 |
| 不确定性 | 隐藏关键未知 | 提到不确定却没指出位置 | 保留未知并说明缺少的证据 |
| 可执行性 | 建议危险或无法执行的动作 | 只有宽泛下一步 | 给出获准动作、owner 和停止条件 |
严重失败不能放进加权平均，否则多个风格分可能抵消一次虚构批准。输出畸形或 reviewer 缺乏领域背景时，应记录“不可评分”，不能擅自变成零分或猜测值。
步骤 4：锁定环境并运行 A 与 B
A 和 B 必须收到相同输入与等价运行条件。冻结系统指令、工具权限、检索语料、预处理、采样设置、输出上限及结构 schema；服务未公开的参数记录为未知，不声称已控制。
随机决定 A/B 顺序，并用新对话或隔离 session 防止上下文泄漏。若使用工具，在受控环境运行且每个案例间重置状态。评测不得发送外部消息、修改生产数据、购买或部署。
运行完整矩阵，包括失败的运行。有选择地重跑可用于诊断，但不能取代原始结果。完整保留原始响应或受控引用、prompt/case revision、运行序号、随机位置、时间与配置、允许记录的工具轨迹、自动检查结果，以及一致采集且与决定相关的时延或成本。拒答、超时和畸形输出也是真实结果，按预先规则分类，不能从分母删除。
步骤 5：重复可变输出并报告不确定性
即使可见设置相同，生成式输出也可能变化。每个 prompt-case 应重复到足以暴露会改变发布决定的波动。没有通用次数；必须在看到赢家前按风险与资源确定，并在样本太小时降低结论强度。
Google SRE 的可靠性测试指导解释了重复测试如何帮助区分持续行为与噪声，并强调测量中的不确定性。［3］ 对提示词应按案例类别保存通过率和评分分布，而不是只给总平均。
报告严重失败的 prompt、case 和 run；确定性通过率的分子分母；序数量尺的中位数与范围；类别结果；不稳定组合；缺失运行及原因；裁决前的 reviewer 分歧。十个合成案例不能支持“质量达到 97.3%”的普遍结论，只能说明指定 revision 在当前案例与配置下的表现。
步骤 6：盲化人工评审并处理分歧
从评审包移除 prompt 标签、revision、运行顺序和作者，随机排列同一案例的输出，同时在受控位置保存映射。Reviewer 应先独立按相同锚点评分，再讨论。
专业主张至少需要一位领域 reviewer。Sarah Lin 应复核样本设计、量规、分析和结论强度。发生分歧时，保留原始评分、记录原因，并使用预先定义的裁决规则；不能用协商后的一个数字覆盖证据。
注意偏好长答案、把自信当准确、奖励熟悉措辞或识别作者风格等偏差。盲评只能减少部分偏差，无法补救不合格的量规或案例集。事实判断应遵循AI 输出事实核查流程，回到一手来源，而不是依靠 reviewer 记忆。
步骤 7：做出并记录发布决定
按步骤 1 的规则比较结果：先看严重失败，再看确定性契约、类别回归、人工评分、分歧与波动。检查所谓改进是否其实来自缺失运行、配置漂移或测试集污染。
NIST 生成式 AI Profile 把评测放在持续风险管理和人工监督中，并覆盖虚构、隐私、安全与信息完整性。［4］ 因此发布不能只看质量平均分。
使用以下四种结果之一：
- 发布： B 通过所有强制关卡，负责人接受证据。
- 修改： B 有潜力，但存在可修复的回归或不清楚的指令。
- 保留 A： B 带来的收益不足，或越过了某个阈值。
- 无法定论： 样本、量规、配置记录或评审一致性不足以支持决定。
赢家以新的不可变版本发布；新发现的失败应加入回归集，但不能改写历史结果。测试生成指南可帮助补充案例，生成的预期仍要独立验证。
总结
- 看输出前写清决定与失败门。
- 版本化代表性案例集并保护 holdout 独立性。
- 分开确定性验证、人工判断与严重失败。
- 在相同记录条件下运行 A/B，保留所有结果。
- 重复随机运行，报告分布与评分分歧。
- 把结论限制在当前任务、案例、配置和日期内。
常见问题
评测提示词需要多少个案例？
没有通用数量。先覆盖每种重要任务和严重失败，再补到足以支持目标决定，并如实报告案例数和局限。
每条提示词应该重复运行几次？
在看到结果前，根据任务波动、后果和评测预算决定。次数应足以暴露可能改变发布选择的不稳定性。
输出应该逐字比较吗？
只有完全一致的文字属于契约时才这样做。大多数生成任务应比较必需属性、禁止行为和量规，允许合理措辞变化。
可以让 AI 给输出评分吗？
可把它作为补充信号，但要记录 grader 提示词、配置、偏差和验证。对于重要结论，不能把同类模型的偏好当成唯一 ground truth。
什么是严重失败？
它是无论平均分多高都阻止发布的结果，例如虚构证据、泄露禁止数据、危险动作、遵从提示注入或下游会误用的非法格式。
如何防止测试集污染？
限制 holdout 访问、记录 revision、分开开发与发布案例，并通过受控流程替换已暴露案例。作者据此调优过的案例只能算开发证据。
Reviewer 对赢家意见不同时怎么办？
保留原始评分，找出产生分歧的量尺锚点，再按预定规则裁决。高分歧也可能意味着结果应标为证据不足。
平均分更高就应该发布 B 吗？
不一定。先检查严重失败、类别回归、波动、不确定性与运营限制；小幅平均提升不能抵消新的危险行为。
什么时候刷新 benchmark？
任务、输入分布、政策、模型或工具、检索来源、输出消费者或已知失败模式变化时都要刷新，并保留旧 revision。
来源
- NIST — AI RMF Playbook, Measure — https://airc.nist.gov/airmf-resources/playbook/measure/
- NIST — GenAI Evaluation Program — https://ai-challenges.nist.gov/genai
- Google SRE — Testing for Reliability — https://sre.google/sre-book/testing-reliability/
- NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
Sources checked 2026 年 9 月 4 日。
