测试数据
提示测试用例
Prompt test case
含义
一种定义的输入、上下文、预期行为和评估规则,用于检查提示。
使用场景
创建用于正常请求、边缘条件、模糊输入和预期拒绝的案例。
应用示例
输入:缺少帐户 ID;预期行为:在不捏造 ID 的情况下,请求 ID。生成式 AI 工程
了解如何构建提示测试用例,比较受控的变体,分析失败,防止回归,并平衡质量、延迟和成本。
16 个术语
测试数据
Prompt test case
一种定义的输入、上下文、预期行为和评估规则,用于检查提示。
创建用于正常请求、边缘条件、模糊输入和预期拒绝的案例。
输入:缺少帐户 ID;预期行为:在不捏造 ID 的情况下,请求 ID。测试数据
Golden dataset
经过审查的、具有代表性的测试输入集合,以及可信的预期结果或评分指南。
用于在不同版本中,对提示的变化进行一致的比较。
随着实际使用情况的变化,刷新数据集,同时保留一个稳定的回归子集。
保留 200 个已审查的支持案例,包括预期的类别、所需的事实以及禁止的声明。实验
Baseline prompt
用作比较的参考点,当前或最简单的提示。
在优化之前记录它,以便可以衡量所声称的改进。
Baseline v12 使用生产模型、默认参数以及未更改的检索设置。实验
Prompt variant
一个替代的提示措辞、结构、示例集、模型或推理配置,并与基线进行比较。
使用不同的名称和版本,以便可以安全地重现和推广结果。
Variant B 在源数据之后移动约束,并添加一个负面示例。实验
Controlled experiment
一种比较,在保持相关输入和设置不变的情况下,改变一个预期的因素。
用于将观察到的差异归因于提示的变化,而不是模型、数据或采样。
仅更改指令措辞;保持数据集、模型版本、温度和评估器固定。实验
A/B test
一个实验,比较两个提示或配置版本在可比的流量或测试样本上的效果。
在离线检查后,使用它,以便比较生产环境的行为和用户结果。
通过资格规则、监控和停止条件来保护用户;不要在未经审查的情况下暴露高风险的工作流程。
随机将符合条件的请求路由到 A 或 B,并比较任务成功率、纠正情况、延迟和成本。实验
Prompt ablation
删除或替换一个提示组件,以衡量其贡献。
用于识别不必要的指令、示例或上下文,这些指令、示例或上下文会增加成本,而不会提高质量。
删除第三个示例,同时保持其他所有组件不变。评估
Batch evaluation
对许多预定义的案例运行提示,并将每个案例和整体结果进行汇总。
在将手动检查误认为是具有代表性的性能之前,使用它。
在固定的评估集上运行所有提示变体,并导出每个案例的失败情况。评估
Prompt regression
之前有效的功能,但在提示、模型、检索、工具或策略更改后变得更差。
使用稳定的测试套件跟踪它,并在每次发布前比较结果。
新的简洁格式提高了长度,但停止了包含必需的源 ID。可靠性
Robustness test
一种测试,用于验证在现实变化、噪声、语言和边缘情况下是否保持可接受的行为。
使用释义、重新排序的上下文、拼写错误、缺失字段以及具有迷惑性的输入。
使用正式、口语化、拼写错误以及多语言的措辞测试相同的意图。可靠性
Sensitivity test
一种测量当输入或配置的细微变化时,输出变化强度的测试。
用于措辞、示例顺序、温度、上下文放置和模型版本更改。
将相同的证据从开头移动到中间,并比较引用准确性。可靠性
Failure taxonomy
一组用于标记和分析提示失败的类别。
在进行大规模评估之前,定义它,以便团队可以优先考虑原因,而不仅仅是计算失败次数。
标签:缺少的事实,不支持的声明,模式错误,错误的工具,不安全的披露,过高的延迟。评估
Acceptance threshold
一个预定义的得分或规则,提示版本必须满足才能发布。
根据风险设置阈值,并包含必须成功的情况,而不是仅依赖平均值。
仅在所有必需字段的准确率至少为 98% 且没有关键的隐私问题发生时才发布。评估
Model and parameter matrix
一个计划好的网格,用于比较不同模型版本和推理设置下的提示。
在提示可能在模型迁移或参数更改后表现出不同行为时使用。
在两个支持的温度设置下,在模型 A 和 B 上评估提示 v8。效率
Quality, latency, and cost comparison
对每个候选者的任务质量、响应时间和资源使用的综合视图。
用于避免选择一个略微更好的提示,但速度太慢或成本太高。
比较通过率、p95 延迟、输入令牌、输出令牌以及每个成功任务的估计成本。效率
Prompt optimization loop
一个定义目标、测试基线、分析失败、更改提示和重新测试的迭代循环。
使用小幅基于证据的更改,并在每个迭代中保留版本结果。
Define metric -> run baseline -> label failures -> change one component -> rerun -> review regressions.| 步骤 | 必需的证据 |
|---|---|
| 定义目标 | 用户结果、质量标准、风险、延迟和成本限制。 |
| 建立基线 | 版本提示、模型、设置、数据集和每个案例的结果。 |
| 测试更改 | 控制变体,根据需要进行重复运行,并添加失败标签。 |
| 发布或拒绝 | 接受阈值、回归审查、人工审核和回滚计划 |
几个示例可能遗漏了常见的失败、边缘情况、变异和回归。 使用具有代表性的案例、稳定的评分规则、逐个案例的审查和批量结果,然后再得出结论。
否。 选择能够反映任务的指标,包括所需的事实、可靠性、格式有效性、安全性、鲁棒性、延迟、token 使用量、成本以及人工校正的 effort。
对于因果诊断,一次只更改一个主要因素。更广泛的候选比较可以更改多个组件,但它们显示哪个完整的候选方案更好,而不是哪个组件导致了差异。
描述提示工程作为一种以测试为导向、迭代的工作流程,具有明确的目标和系统的评估。
关于在具有代表性的数据上测试受控的提示变体并比较可测量的结果的官方指南。
从明确的指令、示例、约束、输出模式和分解的工作流程开始。
将特定于提示的实验与更广泛的系统质量、人工审核、基准测试和运营指标连接起来。
验证候选版本,并仅推广批准的不可变修订版。
在测试策略中,包括提示注入、隐私、有害内容、公平性和红队测试用例。