如何系统地评估和优化提示词的效果？
- 标签：Prompt、效果评估
🏛 业务架构师
系统性评估和优化提示词，我的方法论是"评测集驱动 + 版本管理 + 迭代闭环"：
第一步·建评测集（地基工程）：从真实使用场景抽 50~200 条代表性输入，覆盖：典型 case、边界 case、对抗 case（诱导跑偏）；每条标注期望输出要点（不必逐字，关键要素即可）。这是提示词工程里"一次投入持续复利"的资产。
第二步·定义评估维度：任务准确率（答对没）、格式遵从率（schema 通过没）、相关性（答到点没）、安全性（红线没破）；能自动化的自动化（规则+LLM-as-Judge），抽样人工校准 judge 一致性。
第三步·基线与对比：当前提示词跑出基线分 → 修改后跑对比 → 统计显著性（小样本下别被噪声骗）→ 只合入有提升的变更。
第四步·优化手法优先级（按 ROI）：先改指令清晰度（任务、约束、输出格式写明确）→ 加/减 Few-shot 示例（选典型+边界）→ 加角色设定与分隔符结构 → 调参数（temperature）→ 最后才是换模型。
第五步·线上验证与回归：离线评测通过后小流量 A/B，看真实业务指标（采纳率、纠错率）；线上 badcase 定期回流评测集——评测集要"长大"，形成飞轮。
工程纪律：提示词进 Git 版本管理、变更走 PR 评审（描述"改了什么、为什么、评测分数变化"）、生产禁止手改。常见误区警示：不要每次拍脑袋改一句就上线——没有评测集的提示词优化是玄学；不要过度拟合评测集（定期换新鲜样本）。
🏗 系统架构师
我把提示词评估优化做成**"评测集 → 指标 → 迭代闭环"**的工程流程，而不是凭感觉改：
第一步：建评测集（地基）：
- 100~300 条覆盖真实分布的样本（线上采样 + 人工补充边界 case 与难例）；
- 每条带期望输出或评分要点；评测集版本化管理，与 Prompt 版本对应。
第二步：定义指标（多维，别只看"感觉"）：
- 任务准确率（可判定任务：分类准确、抽取字段正确率）；
- 格式合规率（结构化输出通过 Schema 校验的比例）；
- 质量分（LLM-as-Judge 按 rubric 打分：正确性/完整性/简洁性，人工抽检校准 Judge）；
- 成本与延迟（token 数、响应时间）——效果相同选便宜的。
第三步：迭代闭环：
- 基线跑分 → 单变量改动（一次只改一处：加示例/改指令/调格式）→ 回归对比 → 显著改善才合入；
- 失败分析驱动：badcase 聚类归因（指令没理解？缺上下文？格式歧义？），针对性修——盲目调措辞是玄学；
- 版本管理：Prompt 进 Git，带变更说明；线上灰度 + A/B 验证；
- 监控漂移：线上效果月度复测（模型升级、用户分布变化都会导致退化）。
架构师心得：Prompt 优化 80% 的收益来自前三件事——加对 few-shot 示例、输出契约明确化、关键约束放首尾；剩下 20% 才是措辞打磨。纪律（评测集 + 版本化 + 单变量迭代）比技巧重要——把 Prompt 当代码管理，是团队从"手艺"到"工程"的分水岭。
💻 全栈开发专家
我系统评估提示词的流程是「建基准→自动化评分→迭代对照→线上验证」四步：
1. 建评测集（最重要的资产）：
- 覆盖典型场景 + 边界情况 + 历史坏例，50~200 条；每条含输入、（可选）参考答案、评分要点；
- 按业务重要性加权（高频场景权重高）。
2. 自动化评分（三种裁判组合）：
- 规则断言：格式检查（JSON 可解析、字段齐全）、关键词/禁词、长度——确定性维度全部规则化；
- LLM-as-Judge：质量维度（准确性、完整性、语气）用强模型按 rubric 打分（明确细则+锚点示例，先写分析再给分）；成对比较时交换位置防偏差；
- 程序判卷：可执行的任务跑测试（生成的代码过单测）。
3. 迭代对照：
bash
# promptfoo：声明式评测，CI 可跑
promptfoo eval --prompts v1.txt v2.txt --tests dataset.yaml单变量迭代（一次只改一处），版本化管理（Git 存 prompt，语义化版本），每次变更出对比报告。
4. 线上验证闭环：离线胜出的版本小流量 A/B，看行为指标（任务完成率、点踩率）+ 护栏指标（成本、延迟）；线上 badcase 回流评测集。
优化手法优先级（经验序）：明确输出格式与约束 > 加/换 few-shot 示例 > 补上下文（RAG）> 调结构（角色/分节）> 换模型——先便宜后贵。纪律：没有评测集就不算「优化」，只是「改动」。