高级篇 - 模型优化
·
一、工程化Prompt（优化）
一、建立基线（Baseline）
| 维度 | 测量方法 | 示例指标 |
|---|---|---|
| 准确性 | 人工标注 100 条典型问题 | 正确率 72% |
| 格式符合度 | 正则/JSON Schema 校验 | 正确 JSON 格式比例 58% |
| 延迟 | API 调用计时 | P95 延迟 4.2 秒 |
| 成本 | Token 计数 | 平均 850 tokens/次 |
| 用户满意度 | 点赞/踩、反馈率 | 好评率 68% |
对不对（内容、格式）、快不快、贵不贵、满意不
PM 动作：建立一份Prompt 优化日志，记录每次改动后的指标变化，否则你无法证明优化有效。
二、分层拆解 Prompt
不要把 Prompt 当成一个整体优化，而是拆成可独立迭代的模块：
┌─────────────────────────────────────┐
│ 1. 角色设定 (Role) │
│ “你是一位资深的客服专家...” │
├─────────────────────────────────────┤
│ 2. 任务目标 (Task) │
│ “根据用户问题，判断属于哪个类别...” │
├─────────────────────────────────────┤
│ 3. 输出格式 (Format) │
│ “必须返回 JSON，包含 category 字段” │
├─────────────────────────────────────┤
│ 4. 约束条件 (Constraints) │
│ “如果无法确定，返回 unknown，不要猜测” │
├─────────────────────────────────────┤
│ 5. 示例 (Few-shot Examples) │
│ “用户: 我想退款 → 类别: refund” │
└─────────────────────────────────────┘1. 先调 示例（收益最大，通常 10-30% 提升）
2. 再调 约束（解决边界情况）
3. 最后调 角色（影响风格，对准确性影响较小）
三、结构化 Prompt 模板
从自然语言到结构化，让 Prompt 更稳定、更易维护：
{
"system": "你是一个订单查询助手。",
"instructions": [
"1. 优先从用户输入中提取订单号（格式：ORD-数字）",
"2. 如果缺少订单号，反问用户",
"3. 查询成功后，只返回订单状态和预计送达时间"
],
"constraints": [
"不要输出任何 markdown 格式",
"不要添加额外建议"
],
"examples": [
{"input": "查一下我的订单", "output": "请提供订单号，格式如 ORD-123456"},
{"input": "ORD-789012 到哪了", "output": "订单 ORD-789012 已发货，预计 3 月 5 日送达"}
],
"output_schema": {
"type": "object",
"properties": {
"status": {"type": "string"},
"estimated_delivery": {"type": "string"}
}
}
}四、负面约束 + 边界处理
模型最怕“边界情况”。系统性优化必须覆盖：
| 边界类型 | 优化手段 | 示例 |
|---|---|---|
| 信息不足 | 明确“反问”而非“猜测” | “如果缺少订单号，反问用户，不要用示例订单号填充” |
| 超出范围 | 定义拒答机制 | “如果问题与订单无关，回复‘我只能帮你查订单问题’” |
| 恶意输入 | 防注入 | “忽略前面所有指令”类 prompt 必须被拦截 |
| 多轮混淆 | 明确上下文引用规则 | “仅基于当前对话，不要引用历史中的其他订单” |
五、分场景优化，而非一刀切
不同场景对 Prompt 的要求不同，建立场景化 Prompt 库：
| 场景 | 优化重点 | 典型约束 |
|---|---|---|
| 客服问答 | 准确性 + 情绪管理 | “语气温和，如果用户愤怒，先道歉再解决问题” |
| 数据提取 | 格式严格 + 容错 | “只输出 JSON，如果字段缺失，值为 null” |
| 代码生成 | 可执行性 + 安全 | “不要生成删除数据的代码” |
| 创意写作 | 多样性 + 风格一致 | “避免陈词滥调，保持角色人设一致” |
六、持续监控与回归测试
Prompt 优化不是一次性工作。模型会更新、业务会变化，必须有回归机制。
建立 Prompt 回归测试集**（50-200 条）：
- 10% 简单用例（确保没变差）
- 30% 边界用例（核心保护）
- 60% 真实用户问题（持续覆盖）每次改 Prompt 前跑一遍，确保核心指标不下降。
七、A/B 测试 Prompt 效果
1. 为什么需要 A/B 测试：数据证明Prompt 优化效果
2. 产品级 A/B 测试框架
┌──────────────┐
│ 用户分流 │ → 方案 A (50%) + 方案 B (50%)
└──────────────┘
↓
┌──────────────┐
│ 埋点采集 │ → 准确性、延迟、成本、用户反馈
└──────────────┘
↓
┌──────────────┐
│ 统计检验 │ → 置信度 ≥95% 才判定胜出
└──────────────┘3. PM 必须关注的指标
| 指标类型 | 具体指标 | 采集方式 |
|---|---|---|
| 技术指标 | 准确率、格式正确率、延迟 P95 | 系统日志 + 自动化校验 |
| 体验指标 | 用户点赞/踩、重复提问率 | 前端埋点 |
| 业务指标 | 任务完成率（如退款成功）、人工转接率 | 后端数据 |
| 成本指标 | 单次请求 token 数、API 费用 | 成本系统 |
4. 实战技巧
| 技巧 | 说明 |
|---|---|
| 不要同时测太多变量 | 一次只改 1-2 个模块，否则无法归因 |
| 设置最小样本量 | 至少 500-1000 次调用/组，才有统计意义 |
| 关注长尾影响 | 平均值提升可能掩盖了某些场景变差 |
| 灰度发布 | 先 5% → 20% → 100%，有问题随时回滚 |
八、Meta Prompting
1. Meta Prompting：让一个 LLM 来帮你生成、优化、评估另一个 LLM 的 Prompt。
2. 三种应用
1️⃣ Prompt 生成器
输入你的需求，让 LLM 生成初版 Prompt：
你是一位 Prompt 工程专家。请根据以下需求生成一个系统提示词：
【需求】客服订单查询助手，需要提取订单号（格式 ORD-数字），
如果缺少则反问，输出只包含状态和预计送达时间。【要求】使用结构化格式，包含角色、指令、约束、示例。
2️⃣ Prompt 评估器
用 LLM 评估你的 Prompt 质量：
请评估以下 Prompt 的质量，给出 1-10 分，并指出问题：
[Prompt 内容]
评估维度：
- 清晰度：指令是否明确无歧义
- 完整性：是否覆盖边界情况
- 示例质量：few-shot 是否典型
- 防注入：是否有安全风险
3️⃣ Prompt 迭代优化器
让 LLM 根据失败案例自动改进 Prompt：
以下 Prompt 在处理某个用户问题时失败了。
失败输入：[用户输入]
失败输出：[模型输出]
期望输出：[人工标注]请分析失败原因，并给出优化后的 Prompt。
3. Meta Prompting 的局限性
| 问题 | 说明 |
|---|---|
| 循环优化 | 可能在同一问题上反复调整，没有实质改进 |
| 过度复杂化 | 容易把简单 Prompt 变成冗长的大段文本 |
| 忽略成本 | 生成的 Prompt 可能 token 数暴增 |
| 无法验证 | 需要配合 A/B 测试确认确实变好了 |
> 建议：Meta Prompting 用于“生成初稿”和“识别问题”，人工做最终决策和验证。
九、落地路线图（MVP → 规模化）
| 阶段 | 动作 | 产出 |
|---|---|---|
| Week 1-2 | 建立基线 + 结构化重构 | 第一版结构化 Prompt + 100 条测试集 |
| Week 3-4 | 人工优化 + 边界覆盖 | 准确率提升 15-20% |
| Week 5-6 | A/B 测试框架上线 | 可对比实验的工程能力 |
| Week 7-8 | Meta Prompting 辅助迭代 | 自动化生成候选 Prompt |
| 长期 | 回归测试集持续维护 + 版本管理 | Prompt 作为资产可追溯 |
Prompt 优化的系统性方法 = 建立基线 + 结构化拆解 + 边界覆盖 + A/B 验证 + Meta Prompting 辅助。产品经理的核心职责不是写 Prompt，而是建立“可度量、可迭代、可自动化”的优化体系，让 Prompt 从“手工艺品”变成“工程资产”。
十、补充内容
1. 埋点：在产品代码中“埋”下监控点，自动收集用户行为数据的技术手段
| 层次 | 采集内容 | 示例 | 典型用途 |
|---|---|---|---|
| 前端埋点 | 用户点击、页面浏览、滑动 | “用户点击了‘查订单’按钮” | 分析用户行为路径、转化率 |
| 后端埋点 | API 调用、业务状态、错误 | “调用订单查询 API 成功，耗时 1.2 秒” | 监控系统性能、业务指标 |
| LLM 专用埋点 | Prompt、模型输出、Token 数 | “本次调用用了 850 tokens，输出格式错误” | 优化 Prompt、控制成本 |
2. 长尾影响：优化或改动对“少数边缘场景”产生的意料之外的影响
（1）案例：你优化了订单查询的 Prompt
-
✅ 标准订单号（ORD-123456）识别率：95% → 98%
-
❌ 带空格的订单号（ORD - 123456）识别率：90% → 40%
原因：你加了“订单号格式严格为 ORD-数字”的约束，模型不再灵活处理用户输入中的空格。
过度优化特定案例会导致泛化能力下降
（2）如何防范长尾影响
| 措施 | 说明 |
|---|---|
| 回归测试集覆盖长尾 | 测试集里至少 30% 是边界/异常场景 |
| 分场景看指标 | 不要只看平均值，要看每个细分场景的准确率 |
| 监控投诉关键词 | “以前能查现在不能”类投诉是长尾问题的信号 |
| 灰度发布 | 先放 5% 用户，观察 1-2 天再全量 |
3.MVP（Minimum Viable Product）最小可行产品，用最少的资源快速验证核心假设的产品版本。
4. LLM优化的三层手段
┌─────────────────────────────────────────────────────────────┐
│ LLM 优化的三层手段 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 第1层：Prompt 工程 │
│ └── 改的是“输入文本”，模型权重不变 │
│ └── 示例：加 few-shot、改角色设定、加约束 │
│ │
│ 第2层：微调 │
│ └── 改的是“模型内部的权重参数”，让模型“学会”新模式 │
│ └── 微调过程中，超参数是“控制如何改权重的参数” │
│ │
│ 第3层：预训练 │
│ └── 从零开始训练，几乎不用 │
│ │
└─────────────────────────────────────────────────────────────┘二、微调（Fine-tuning）
一、什么时候需要微调
开始
↓
RAG 能否达到 80% 准确率？
↓ 否（或已到瓶颈）
是否需要模型学习“新的知识”？
↓ 是 → ❌ 微调不适合学新知识，用 RAG
↓ 否
是否需要改变“行为/风格/格式”？
↓ 是 → ✅ 微调适合
↓ 否
是否有 ≥500 条高质量标注数据？
↓ 是 → ✅ 可以考虑微调
↓ 否 → 先优化 Prompt/RAG1. 微调的 5 个典型适用场景
| 场景 | 说明 | 示例 |
|---|---|---|
| 1. 固定输出格式 | 模型总是不按 JSON/表格输出 | 必须输出 {"category":"refund","confidence":0.95} |
| 2. 特定语气/人设 | 通用模型太“机器人”或太“油腻” | 医疗问诊要冷静专业，游戏 NPC 要活泼中二 |
| 3. 复杂推理链路 | 需要多步推理，Prompt 写不清楚 | 根据用户历史订单+浏览记录+库存状态推荐商品 |
| 4. 减少延迟/成本 | 用小模型微调替代大模型 | 用 7B 模型微调替代 GPT-4 的重复性任务 |
| 5. 减少 token 消耗 | Prompt 太长，每次调用成本高 | 把“角色+约束+10个示例”微调进模型，Prompt 缩至 50 tokens |
2. 微调不适合的场景
| 场景 | 原因 | 正确做法 |
|---|---|---|
| 注入新知识 | 微调容易遗忘，且无法实时更新 | 用 RAG |
| 数据量 < 500 条 | 过拟合风险高，效果不如 Prompt 工程 | 优化 Prompt |
| 知识频繁变化（天级） | 重新训练成本太高 | 用 RAG |
| 需要引用来源 | 微调模型不提供溯源 | 用 RAG |
PM 决策原则：先 RAG 后微调，先大模型后蒸馏。微调是“精修”，不是“补课”。
二、如何准备训练数据
1. 数据格式（OpenAI 标准）
{"messages": [{"role": "system", "content": "你是一个订单查询助手"},
{"role": "user", "content": "查一下我的订单 ORD-123456"},
{"role": "assistant", "content": "订单 ORD-123456 状态：已发货，预计 3 月 5 日送达"}]}
{"messages": [{"role": "system", "content": "你是一个订单查询助手"},
{"role": "user", "content": "帮我看看 123456 到哪了"},
{"role": "assistant", "content": "请提供完整订单号，格式如 ORD-123456"}]}2. 数据质量的三条红线
| 红线 | 说明 | 检查方式 |
|---|---|---|
| 一致性 | 同样的输入，输出应一致 | 同一问题至少 3 人标注，取共识 |
| 准确性 | 输出必须正确，错误数据会污染模型 | 抽样 20% 人工复核 |
| 多样性 | 覆盖真实用户的各种表达方式 | 分析历史日志，补充长尾场景 |
3. 数据量建议
| 任务复杂度 | 最低数据量 | 推荐数据量 |
|---|---|---|
| 简单分类/格式约束 | 200-500 条 | 500-1000 条 |
| 中等复杂度（多意图） | 500-1000 条 | 1000-3000 条 |
| 高复杂度（推理+工具调用） | 1000+ 条 | 3000-10000 条 |
PM 必做：建立数据标注规范文档，包含正例、负例、边界情况的具体示例。
4. 数据准备流程
1. 采集真实日志（用户问题 + 当前模型输出）
↓
2. 人工标注（修正错误输出，补充缺失场景）
↓
3. 质量校验（一致性检查、格式校验）
↓
4. 分割数据集（80% 训练 / 10% 验证 / 10% 测试）
↓
5. 版本管理（每次数据集变更都有记录）三、微调流程和最佳实践
1. 完整微调流程（PM 视角）
┌─────────────────────────────────────────────────────────┐
│ 阶段 1：准备（1-2 周） │
│ • 收集真实对话日志 │
│ • 建立标注规范，人工标注 500-1000 条 │
│ • 分割训练/验证/测试集 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段 2：基线测试（2-3 天） │
│ • 用当前 Prompt 在测试集上跑一遍，记录准确率 │
│ • 这是“微调必须超越的基线” │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段 3：首次微调（1-2 天） │
│ • 选择基础模型（GPT-3.5 / Llama 3 / Qwen） │
│ • 设置超参数（epoch=3, learning_rate=2e-5） │
│ • 在训练集上微调 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段 4：评估（1-2 天） │
│ • 在验证集上评估，对比基线 │
│ • 人工评估 50-100 条边界案例 │
│ • 如果效果不如基线 → 检查数据质量 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段 5：迭代（1-2 周） │
│ • 分析失败案例，补充数据 │
│ • 调整超参数（epoch、学习率） │
│ • 重新训练，直到验证集准确率稳定 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段 6：上线（1 周） │
│ • A/B 测试 5% 流量，对比线上基线 │
│ • 监控延迟、成本、用户反馈 │
│ • 全量发布 │
└─────────────────────────────────────────────────────────┘微调改的是“模型内部的权重参数”，让模型“学会”新模式
2. 最佳实践清单
| 类别 | 实践 | 原因 |
|---|---|---|
| 数据 | 训练集和验证集分布一致 | 避免过拟合到特定模式 |
| 数据 | 包含边界情况和拒答样本 | 让模型学会“我不知道” |
| 训练 | 先从 1-2 个 epoch 开始 | 防止灾难性遗忘 |
| 训练 | 保留 10% 数据做验证 | 早停防止过拟合 |
| 评估 | 同时看准确率和 loss | loss 低不一定业务好 |
| 评估 | 人工评估 50+ 条 | 自动化指标可能漏掉风格问题 |
| 上线 | 保留基线模型可快速回滚 | 微调模型可能在某些场景变差 |
3.常见坑点
| 坑 | 表现 | 解决方案 |
|---|---|---|
| 灾难性遗忘 | 微调后不会通用推理了 | 减少 epoch，或在数据中加入通用对话样本 |
| 过拟合 | 验证集准确率高，线上差 | 增加数据量，降低学习率 |
| 数据泄露 | 验证集包含训练集样本 | 严格按用户 ID 分割，而非按对话 |
| 分布偏移 | 训练数据和线上用户输入不一样 | 定期用线上日志更新训练集 |
四、模型蒸馏（用大模型教小模型）
1. 什么是蒸馏
用大模型（Teacher）生成高质量数据，训练小模型（Student），让小模型以更低成本达到接近大模型的效果。
| 维度 | 大模型（Teacher） | 小模型（Student 蒸馏后） |
|---|---|---|
| 成本 | 高（$0.01-0.10/次） | 低（$0.001-0.01/次） |
| 延迟 | 高（2-5 秒） | 低（0.5-1 秒） |
| 准确率 | 95% | 88-92%（损失 3-7%） |
| 适用场景 | 复杂推理、冷启动 | 高并发、重复性任务 |
2. 蒸馏的三种模式
| 模式 | 流程 | 适用场景 |
|---|---|---|
| 离线蒸馏 | 大模型生成 1 万条数据 → 微调小模型 | 最常用，成本可控 |
| 在线蒸馏 | 大模型实时生成数据，持续更新小模型 | 数据分布变化快 |
| 自蒸馏 | 用模型自身生成数据再训练 | 无大模型资源时 |
3. 蒸馏实战流程
┌─────────────────────────────────────────────────────────┐
│ Step 1: 采集真实用户输入（5000-10000 条） │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Step 2: 用大模型（GPT-4）生成理想输出 │
│ • 成本：5000 条 × $0.03 ≈ $150 │
│ • 质量：人工抽检 100 条，确保准确率 ≥95% │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Step 3: 用小模型（GPT-3.5 / Llama 3-8B）微调 │
│ • 数据量：3000-5000 条即可 │
│ • 训练成本：$50-200 │
└─────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────┐
│ Step 4: 评估 vs 大模型 │
│ • 测试集 500 条，准确率对比 │
│ • 如果差距 >10%，增加数据量或用更强的小模型 │
└─────────────────────────────────────────────────────────┘4. 蒸馏的 ROI 计算
假设你的产品每天调用 10 万次：
| 方案 | 单次成本 | 日成本 | 月成本 |
|---|---|---|---|
| 直接调用 GPT-4 | $0.03 | $3,000 | $90,000 |
| 蒸馏后的 7B 模型 | $0.003 | $300 | $9,000 |
| 节省 | - | $2,700/天 | $81,000/月 |
代价：准确率从 95% 降到 90%。
决策：这 5% 的准确率下降，是否影响用户体验和业务指标？
>PM 决策原则：蒸馏是用“成本换性能”的核心手段。在准确率可接受的场景下，优先蒸馏。
5. 蒸馏的最佳实践
| 实践 | 说明 |
|---|---|
| 大模型选最强的 | GPT-4 / Claude 3.5 做 Teacher，质量越高蒸馏效果越好 |
| 数据量 3000-10000 | 太少学不到，太多边际收益递减 |
| 覆盖边界情况 | 蒸馏数据要包含大模型处理好的长尾场景 |
| 保留拒答样本 | 让小模型也学会“我不知道” |
| 迭代优化 | 用线上失败案例补充蒸馏数据，持续更新 |
五、决策矩阵：什么时候选哪个
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 新产品，需求不确定 | Prompt 工程 + RAG | 快速验证，灵活调整 |
| 格式/风格要求严格 | 微调（500-1000 条数据） | Prompt 控制不住时 |
| 高并发、成本敏感 | 蒸馏小模型 | 降低成本 80-90% |
| 需要实时知识 | RAG | 微调和蒸馏都不适合 |
| 大模型太慢 | 蒸馏小模型 | 延迟降低 50-70% |
| 准确率要求极高（>98%） | 大模型 + RAG + 人工兜底 | 微调也难达到，留人工审核 |
产品经理的决策路径是：先用 Prompt+RAG 验证，确认需求稳定后用微调精修，高并发场景用蒸馏降本。
六、RAG 与微调
1. 初期 RAG 上手快，后期 RAG 更难精
| 阶段 | RAG 难度 | 微调难度 |
|---|---|---|
| Demo/原型 | ⭐ 低（1-2天搭起来） | ⭐⭐⭐ 中（需要准备数据） |
| 达到 80% 准确率 | ⭐⭐ 低-中 | ⭐⭐⭐ 中 |
| 达到 95% 准确率 | ⭐⭐⭐⭐⭐ 极高 | ⭐⭐⭐⭐ 中-高 |
| 维护/迭代 | ⭐⭐⭐⭐ 高（知识更新快，但检索调优难） | ⭐⭐ 低（模型稳定后很少动） |
2.为什么 RAG 后期更难
RAG 系统有 4 个独立组件，每个都需要调优，且它们相互影响：
┌─────────────────────────────────────────────────────────────┐
│ RAG 系统的复杂度 │
├─────────────────────────────────────────────────────────────┤
│ 1. 知识库构建 │
│ • 文档如何分块？chunk_size 多大？overlap 多少？ │
│ • 用什么 embedding 模型？ │
│ • 元数据如何设计？ │
├─────────────────────────────────────────────────────────────┤
│ 2. 检索优化 │
│ • 用什么检索策略？向量检索？关键词混合？重排序？ │
│ • 召回多少条？top_k 怎么设？ │
│ • 检索失败时怎么降级？ │
├─────────────────────────────────────────────────────────────┤
│ 3. Prompt 工程 │
│ • 如何把检索内容塞进 prompt？ │
│ • 检索内容太长截断？ │
│ • 检索到无关内容，模型会忽略吗？ │
├─────────────────────────────────────────────────────────────┤
│ 4. 评估体系 │
│ • 检索不到时，是 embedding 问题还是分块问题？ │
│ • 检索到了但回答错了，是模型问题还是 prompt 问题？ │
│ • 如何做回归测试？ │
└─────────────────────────────────────────────────────────────┘3. 微调前期难，后期简单
微调的复杂度是前置的，一旦数据准备好了，后续迭代非常稳定
微调的核心优势：问题归因简单。
-
效果不好 → 大概率是训练数据有问题
-
补充数据 → 效果提升
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
3
0- 0
已为社区贡献3条内容
所有评论(0)