LLM Wiki

Prompt评估体系

11分钟阅读

Prompt评估体系

一句话定义

Prompt评估体系是对AI系统中Prompt效果进行系统化测试和回归验证的工程实践，通过预定义的评估场景和自动化测试框架，确保Prompt修改不会降低AI表现。

摘要

Prompt评估体系是AI质量保障的关键环节。以Chromium的实践为代表，其在agents/prompts/eval/中维护15+个评估场景，每次Prompt修改后运行回归测试，形成”修改→评估→验证→发布”的闭环。从大淘宝技术的实践来看，评测所花时间甚至超过Agent构建时间的两倍以上，说明评估体系的重要性和成本之高。

详情

起源与背景

随着Prompt Engineering从”写提示词”发展为”系统化工程”，单纯依靠人工试错已无法满足质量要求。Prompt的修改可能在某个场景下提升效果，却在另一个场景下导致退化。建立自动化的评估体系成为必然。

核心机制 / 工作原理

评估闭环

Prompt修改 → 运行评估套件 → 对比基线 → 决策发布/回退
    ↑                                        ↓
    └────────────── 反馈优化 ←──────────────┘

评估维度

1. 正确性：AI输出是否符合预期
2. 一致性：相同输入是否产生一致输出
3. 鲁棒性：面对边缘case是否仍然可靠
4. 效率：token消耗、响应时间
5. 安全性：是否产生有害或不当内容

Chromium的评估实践

agents/prompts/eval/
├── 15+ 个评估场景
├── 每个场景包含：输入、预期输出、评判标准
├── 自动化测试框架
├── 回归测试：每次prompt修改后验证效果

评估的挑战

1. 成本高：评测时间可能超过Agent构建时间的两倍
2. 评判标准难定义：主观任务（如写作）难以量化
3. 场景覆盖不全：总有未预见的边缘case
4. 模型版本变化：不同模型版本可能需要不同的评估标准

应用场景

  • Prompt迭代优化的验证
  • AI应用发布前的回归测试
  • 多版本Prompt的A/B测试
  • 模型升级后的效果验证

局限与注意事项

  • 评估体系本身需要持续维护和更新
  • 评估场景需要覆盖足够的多样性
  • 评估结果需要与业务指标对齐
  • 自动化评估不能完全替代人工评审

与其他评估体系的关系

传统软件测试：
  对象：代码
  方法：单元测试、集成测试、E2E测试
  特点：确定性输入→确定性输出

Prompt评估：
  对象：Prompt + 模型
  方法：评估场景 + 评分标准 + 回归测试
  特点：确定性输入→概率性输出

AI评测（更宏观）：
  对象：整个AI应用
  方法：黄金数据集 + 人工标注 + 自动化
  包含：Prompt评估 + 模型评估 + 系统评估

评估方法论

Golden Dataset法：维护一组高质量的标注数据（输入+期望输出），每次Prompt修改后对比新输出与期望输出的一致性。适合有明确正确答案的任务。

LLM-as-Judge法：用另一个大模型来评判AI输出的质量。适合主观任务（如写作、创意），但引入了额外的模型依赖和成本。

人类评审法：由人类专家对AI输出进行打分。最准确但成本最高，通常用于关键场景或作为其他方法的校准基准。

A/B测试法：在生产环境中同时运行两版Prompt，通过实际用户反馈来判断优劣。适合大规模部署前的最终验证。

从黄金集校准到生产集扩展

SnowThink 的实践把“怎么从 0 开始搭一套 prompt / agent 评测”讲得更接地气：不是先追求几百上千条样本，而是先挑 10 个高频黄金 case，把评分器对齐做扎实，再扩到 100-500 条生产评测集。这个顺序的意义在于：评分器不可信时，样本规模越大，噪声越大。

它给出的最小校准框架有三条：

  1. 维度分差：逐维比较人评与机评，单维分差 > 1 视为不对齐。
  2. 排序倒置率：人评与机评对样本优劣的排序是否经常排反。
  3. 极端 case 一致率：人评给到 1 分或 5 分的极端样本，模型能否落到相近区间。

这也补全了 LLM-as-Judge 的一个常见盲点：评分器 prompt 不是“一写就准”，而是要通过 bad case 和差异样本反复校准。先把差距最大的几条样本拉出来读模型的评分理由，再判断问题在评分 prompt、标准设计还是模型能力边界。

Agent / Skill 测评扩展

腾讯技术工程的实践把 Prompt 评估扩展到 Agent/Skill 层，关键变化是评估对象从”最终文本输出”变成”输入、执行过程、Trace、中间产物、最终结果和成本”的完整链路。这个扩展要求被测系统输出稳定结构的 Trace，否则工具调用检查、过程对比、基线对比都无法落地。

Agent/Skill 测评三类评分器：
1. 确定性评分器：脚本 / 断言 / Lint / AST，检查文件存在、工具调用、字段格式、Token 和耗时
2. Rubric 评分器：LLM-as-Judge + Prompt + JSON Schema，检查推理合理性、语义完整性、建议质量
3. 人工评分器：专家校准、诊断 0%/100% 异常、红队和高风险兜底

基线方法也更接近软件回归测试：先执行一次真实用例，人工确认其过程和结果可接受后，把工具调用序列、报告、输出文件、耗时与 Token 固化成快照。后续每次变更都和基线对比，判断是否退化。这让 Prompt 评估从”场景样例打分”变成可进 CI 的回归系统。

阿里技术的 Agent 评测体系进一步强调按 Agent 类型定义侧重：对话 Agent 不能只平均每轮得分，而要同时看 Turn、Session、Trace、Outcome；大量依赖 Skill 的系统，还要把 Skill 触发条件、流程正确性、工具参数、产物质量和异常降级纳入评测。评分结果也必须回到“反馈生产”，把线上失败沉淀为用例库、Trace 库、根因标签库、修复建议库、Judge 校准集和回归集。

行业实践

Chromium的评估实践：

  • 在agents/prompts/eval/中维护15+个评估场景
  • 每次Prompt修改后自动运行回归测试
  • 评估场景覆盖：代码生成、Bug修复、测试编写、代码审查等
  • 评估结果作为Prompt合并的必要条件

大淘宝技术的评估实践：

  • 秒杀AI审核场景：建立黄金数据集，每次Prompt迭代后对比准确率和召回率
  • 评测时间超过Agent构建时间的两倍以上
  • 采用”线上数据采样 → 样本集构建 → 评测 → 优化 → AB实验 → 指标观测”的闭环
  • 历史审核案例库向量检索带来8%准确率提升，混合审核决策带来10%以上提升

腾讯技术工程 Agent/Skill 测评实践：

  • 以功能正确性、过程质量、效率成本、鲁棒性安全、体验对齐五大维度组织指标
  • 用触发条件、核心逻辑、产物质量、异常容错四类场景设计用例
  • TPerf 性能分析 Agent 通过 Knot AG-UI 事件流采集 Trace，用 LCS 对齐工具调用步骤，用 CodeBuddy CLI 做报告语义评分

SnowThink 的 AI Evals 六步法：

  • 业务目标先拆成可独立打分的维度，再设计评分 rubric
  • 先用 10 个黄金 case 做人工打分和 LLM-as-Judge 对齐
  • 生产评测集扩到 100-500 条，并用 bad case 反推 prompt / few-shot / 模型路由
  • 评分器的可信度优先于样本规模，没校准过的评分器“跑一万个 case 也没用”

阿里技术的 Agent 评测体系：

  • 按 Agent 类型拆分评测重点，而不是用一套万能指标评所有系统
  • 用 Trace、Scorer、报告和根因归类复用底层评测骨架
  • 发布阶段联动离线质量、线上体验和业务结果三类信号
  • 对 badcase 做入库门槛和样本治理，避免回归集无限膨胀

关系图谱

反向链接