DSPy / OPRO：程序化 Prompt 优化
核心观点:
DSPy / OPRO / Automatic Prompt Optimization 解读
面向对象: AI PM / AI BA / AI Architect / Prompt Platform PM / EvalOps。 核心问题: Prompt 不应该只是手写文案，它可以被模块化、参数化、评测驱动和自动优化。 学习目标: 理解 DSPy、OPRO、APE 等方法如何把 prompt engineering 升级成可测试的 LM program engineering。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines | https://arxiv.org/abs/2310.03714 | 理解 declarative LM programs、teleprompters、compile/optimize 思想 |
| Optimization by PROmpting | https://arxiv.org/abs/2309.03409 | 理解用 LLM 作为优化器改进 prompt |
| Automatic Prompt Engineer | https://arxiv.org/abs/2211.01910 | 理解自动生成和搜索 prompt candidates |
| HELM | https://crfm.stanford.edu/helm/latest/ | 将 prompt 优化放入 scenario/metric/release gate |
核心观点:
Prompt 是系统配置，不是一次性文案。企业 AI 需要 prompt registry、eval set、optimizer、release gate 和 change control。
1. 手写 Prompt 的问题
| 问题 | 影响 |
|---|---|
| 依赖个人经验 | 难复用、难交接 |
| 没有版本控制 | 无法回滚和审计 |
| 没有 eval | 改好还是改坏靠感觉 |
| prompt 和业务规则混在一起 | 难维护 |
| 数据样本少 | 容易过拟合几个 demo |
| 安全规则靠自然语言堆叠 | 容易被绕过 |
企业 AI 不应该把 prompt 当作“神秘手艺”，而要工程化。
2. DSPy 的核心思想
DSPy 把 LLM pipeline 抽象成可声明的 program:
- 你声明模块签名。
- 你定义输入输出。
- 你准备训练/评测样本。
- 系统可以优化 prompt、few-shot examples 或 pipeline。
从 Prompt 到 Program
传统:
写一个很长 prompt -> 调模型 -> 看输出 -> 手工改
DSPy 式:
Define task signature
-> compose modules
-> provide examples/eval metric
-> compile/optimize
-> evaluate
-> version and release
3. OPRO / APE 的启发
OPRO 让 LLM 作为优化器:
- 给出候选 prompt。
- 观察得分。
- 生成更好的 prompt。
APE 自动生成 prompt instructions，并用任务指标选择。
企业迁移时要注意:
| 能做 | 不能直接做 |
|---|---|
| 自动产生候选 prompt | 自动上线 |
| 对低风险任务优化格式和准确率 | 绕过安全/合规评审 |
| 帮 PM/BA 比较 instruction variants | 替代业务 owner 定义目标 |
| 提高迭代效率 | 保证泛化能力 |
4. Prompt Optimization Control Loop
Requirement
-> Task Signature
-> Prompt Candidate Generation
-> Eval Dataset
-> Scoring Metric
-> Error Analysis
-> Human Review
-> Release Gate
-> Monitoring
-> Change Control
Task Signature 示例
AML summary:
| Field | Definition |
|---|---|
| Input | customer profile, transaction evidence, alert type, policy snippets |
| Output | investigation summary, red flags, missing evidence, recommendation |
| Constraints | no SAR filing, cite evidence, escalate high risk |
| Metric | completeness, groundedness, policy compliance, reviewer acceptance |
5. PM 视角: Prompt 也是产品资产
PM 需要定义:
| Product artifact | 内容 |
|---|---|
| Prompt objective | 业务目标，不只是“回答更好” |
| Success metric | 用户任务成功、接受率、合规率 |
| Not-in-scope | 不允许优化的方向 |
| Safety constraints | 不得越权、不得承诺、不得泄露 |
| Release gate | 达到什么分数才能上线 |
| Regression policy | 模型升级或 prompt 更新要重跑哪些 eval |
Bad PM metric
用户觉得回答更自然。
Better PM metric
| Metric | Why |
|---|---|
| citation-supported claim ratio | 防幻觉 |
| reviewer acceptance | 业务可用 |
| high-risk escalation accuracy | 风险控制 |
| edit distance | 减少人工返工 |
| complaint / correction rate | 客户影响 |
6. BA 视角: 从业务规则到 Signature
BA 要把模糊需求拆成:
- 输入字段。
- 输出字段。
- 必填信息。
- 禁止输出。
- 异常处理。
- 评分 rubric。
示例: Payment Dispute Draft
| Requirement | Signature / Eval |
|---|---|
| 草稿必须包含交易时间、金额、商户 | output schema required fields |
| 不得承诺退款 | disallowed phrase eval |
| 缺少商户证据时要指出 | missing evidence behavior |
| 涉及欺诈时升级 | risk-tier escalation metric |
| 引用网络规则 | citation support metric |
7. 架构师视角: Prompt Platform
Prompt Registry
-> Task Signature Registry
-> Eval Dataset Store
-> Optimizer Runner
-> Candidate Prompt Store
-> Eval Report
-> Approval Workflow
-> Deployment Config
-> Monitoring / Rollback
关键字段
| Registry field | Purpose |
|---|---|
| prompt_id | 稳定 ID |
| task_signature | 输入输出定义 |
| model_target | 适用模型 |
| risk_tier | 上线门禁 |
| eval_set_version | 回归基准 |
| owner | PM/BA/Tech/Risk |
| approved_version | 当前线上版本 |
| rollback_version | 可回滚版本 |
| safety_constraints | 禁止事项 |
8. Eval 防过拟合
自动 prompt 优化容易过拟合 eval set。
控制:
| Control | 说明 |
|---|---|
| train/dev/test split | 优化集和最终验证集分开 |
| challenge set | 保留边界和攻击样本 |
| hidden SME set | 防止 prompt 针对题库优化 |
| production monitoring | 上线后继续看真实反馈 |
| metric diversity | 不只看一个分数 |
| human review | 高风险任务必须抽检 |
9. 金融零售案例
9.1 Customer Service Copilot
可优化:
- 语气。
- 引用格式。
- 产品政策摘要。
- 拒答/升级话术。
不可自动优化:
- 绕过合规披露。
- 提供个性化投资建议。
- 承诺费用豁免。
9.2 AML Narrative
可优化:
- 证据完整性。
- narrative structure。
- missing evidence listing。
必须控制:
- 不提交 SAR。
- 不改变事实。
- 不隐藏不利证据。
9.3 Credit Explanation
可优化:
- 内部 rationale draft。
- 文件缺口总结。
必须控制:
- adverse action 合规。
- fair lending。
- human underwriter ownership。
10. 与现有体系连接
| Existing asset | 连接 |
|---|---|
AI_REQUIREMENTS_TO_EVAL_COOKBOOK.md | prompt optimization 必须从 requirements-to-eval 开始 |
AI_MODEL_RISK_MANAGEMENT_PLAYBOOK.md | prompt 是 model/system configuration，需要 change control |
AI_AUDIT_EVIDENCE_BINDER_PLAYBOOK.md | prompt version、eval report、approval 要进 evidence binder |
AI_OBSERVABILITY_COST_SLO_PLAYBOOK.md | prompt changes 影响 latency、cost、quality |
AI_THREAT_MODELING_RED_TEAM_PLAYBOOK.md | 优化不能削弱安全控制 |
11. 作品集输出
| Artifact | 内容 |
|---|---|
| Task Signature Spec | 输入、输出、约束、指标 |
| Prompt Optimization Plan | candidate generation、eval、approval |
| Eval Split Design | train/dev/test/challenge/hidden set |
| Prompt Registry Card | owner、version、risk、rollback |
| Release Memo | 新 prompt 是否可上线 |
12. 面试表达
30 秒版本
DSPy、OPRO 和 APE 的共同启发是: prompt 不应只是手写文案，而应成为可声明、可优化、可评测、可版本化的系统配置。企业里任何 prompt 更新都要绑定 eval set、owner、risk tier、approval 和 rollback。
2 分钟版本
DSPy 把 LLM pipeline 抽象成 declarative program，通过 task signature、examples 和 metrics 来编译优化 prompt 或 few-shot examples。OPRO/APE 则说明 LLM 可以生成和搜索 prompt candidates。但在金融场景中，自动优化不能自动上线。PM 要定义业务目标和 success metric，BA 要把规则写成输入输出和 rubric，架构师要提供 prompt registry、eval store、optimizer runner、approval workflow 和 monitoring。这样 prompt 才从经验技巧变成受控工程资产。
CTO 深挖
我会把 prompt optimization 放进 CI/CD 类似流程: candidate generation、offline eval、challenge eval、SME review、risk approval、canary、monitoring、rollback。高风险系统不允许直接把 optimizer 结果推生产。
13. 复习问题
- DSPy 和手写 prompt 的本质差异是什么？
- OPRO/APE 为什么不能直接自动上线？
- Task signature 对 BA 有什么价值？
- Prompt 优化如何防止过拟合 eval set？
- Prompt registry 应该记录哪些字段？
- 金融场景中哪些 prompt 变更需要风险审批？
- 如何把 prompt optimization 结果变成 audit evidence？