LLM_Prompt调优流程以及A/B测试

发表于： 分类于：
字数： 1611 阅读：≈ 4分钟 浏览：
总结摘要
LLM_Prompt调优流程以及A/B测试

Prompt 调优和传统软件开发很像——它是迭代工程，不是一次性写作。

Prompt 调优的一般流程

第一步：明确基线（Baseline）

在改任何东西之前，先回答三个问题：

  1. 输入是什么？ — 用户原话 / API 返回 / 数据库记录 / 文档片段
  2. 期望输出是什么？ — JSON? 自然语言? 分类标签? 代码?
  3. 怎么算"好"？ — 定义可量化的评估指标

先跑一个 v0 prompt，用 10-20 条真实样本手动检查，记录问题类型（遗漏信息、格式错误、逻辑错误、幻觉、语气不对等）。

第二步：诊断问题类型

根据基线测试结果，对问题分类：

问题类型根因调优方向
格式不稳定输出约束不够加 JSON Schema / Few-shot / 结尾强调格式
遗漏关键信息指令不够明确分步骤指令 / Checklist / 强调"必须包含"
幻觉/编造缺少事实约束RAG / “只基于以下内容回答” / 温度降低
逻辑推理错问题太复杂拆解为子任务 / CoT / 增加中间验证步骤
不稳定/随机温度高或指令模糊降温度 / Few-shot / 明确边界条件

关键原则：不要一次改多处，每次只改一个变量。

第三步：分层调优

Prompt 的结构一般是：

1
2
3
4
5
6
7

System Prompt（角色 + 规则 + 约束）
    ↓
Context（RAG 检索结果 / 业务数据 / 历史记录）
    ↓
User Query（用户当前输入）
    ↓
Output Format（期望输出格式）

调优顺序：

  1. 先调 System Prompt — 角色定义、行为约束、边界规则
  2. 再调 Few-shot 示例 — 加入 2-3 个典型案例，比长篇指令更有效
  3. 然后调输出格式 — 用模板/Schema 锁定结构
  4. 最后调 Context 策略 — 检索方式、上下文窗口分配、信息排序

第四步：构建评估集

这是很多人跳过但最关键的一步。

黄金原则：不能只靠感觉判断 prompt 好不好，要有数据。

1
2
3
4
5
6
7
8
9

评估集 = {
    "样本1": {
        "input": "用户实际输入",
        "expected": "期望输出（人工标注）",
        "auto_check": ["必须包含关键词X", "JSON 必须能 parse", "结论必须是 A/B/C 之一"]
    },
    "样本2": { ... },
    ...
}
  • 至少 20-30 条覆盖各种边界情况
  • 能自动检查的部分写脚本跑，不能自动的做人工评审
  • 评估集要持续更新，加入线上发现的新 case

第五步：版本管理与 A/B 测试

版本管理

给每个 prompt 版本打 tag，记录变更原因：

1
2
3
4

v0.1 - 初始版本，基线准确率 72%
v0.2 - 加入 few-shot，格式错误率从 30% 降到 5%
v0.3 - 拆解为 3 步 Chain-of-Thought，逻辑错误率从 20% 降到 8%
v0.4 - 加入 JSON Schema 约束，整体准确率 89%

A/B 测试

是的，Prompt 调优完全应该做 A/B 测试。 实操方法：

1. 离线 A/B（调优阶段） 

1
2

同一个评估集 → 分别跑 prompt_v1 和 prompt_v2
比较：准确率、格式合规率、平均 token 消耗、延迟

用脚本批量跑：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

results = []
for sample in eval_set:
    output_v1 = run_prompt(prompt_v1, sample.input)
    output_v2 = run_prompt(prompt_v2, sample.input)
    score_v1 = evaluate(output_v1, sample.expected)
    score_v2 = evaluate(output_v2, sample.expected)
    results.append({"sample": sample.id, "v1": score_v1, "v2": score_v2})

# 统计胜出比例
wins_v1 = sum(1 for r in results if r["v1"] > r["v2"])
wins_v2 = sum(1 for r in results if r["v2"] > r["v1"])
ties = sum(1 for r in results if r["v1"] == r["v2"])

2. 在线 A/B（灰度发布阶段）

  • 10% 流量走新 prompt，90% 走老 prompt
  • 监控核心指标：任务完成率、用户满意度评分、兜底/人工介入率
  • 如果新版本连续 3 天指标优于老版本，逐步放量到 50% → 100%
  • 出现回退立即切回老版本

3. 常见的 A/B 测试陷阱

陷阱说明
样本量不够5-10 条样本的对比没有统计意义，至少 30+
挑 favorable case只拿新 prompt 表现好的 case 展示，这是自欺欺人
忽略成本v2 准确率 +2% 但 token 消耗 +50%，性价比可能更差
只测 happy path边界 case 和异常输入才是 prompt 调优的重点

第六步：持续监控

Prompt 上线后不是终点：

  • 自动监控：每日跑评估集，准确率下降 >5% 触发告警
  • 用户反馈闭环：收集"不满意"的 case，补充到评估集
  • 模型更新影响：底层模型升级后（如 GPT-4o → GPT-4.1），所有 prompt 要重新跑一轮评估

实战 Checklist 

1
2
3
4
5
6
7
8

□ 定义清晰的输入/输出规范
□ 建 20+ 条评估集，覆盖正常和边界 case
□ 记录 v0 基线指标
□ 每次只改一个变量
□ 用评估集量化对比，不靠感觉
□ 记录每个版本的变更和效果
□ 灰度 A/B 验证后再全量上线
□ 建立持续监控机制

一句话总结：Prompt 调优 = 基线测量 → 问题诊断 → 单变量迭代 → 评估集验证 → 灰度 A/B → 持续监控。本质上是科学实验方法论在 LLM 工程上的应用。