DSPy / OPRO / Automatic Prompt Optimization 解读

Source Anchors

---

核心导读

DSPy、OPRO 和 APE 的共同价值，是把 prompt 从个人经验写作推进为可声明、可评测、可优化、可版本化的系统配置。它们不只是让模型自动生成“更好的提示词”，而是让任务定义、输入输出契约、评价指标、候选搜索和发布门禁形成工程闭环。

Prompt optimization 的有效性取决于 task signature、eval dataset、metric、候选搜索和发布治理。架构上必须把证据完整性、合规边界、人工复核、回滚和可审计变更纳入优化循环，防止优化器只追逐表面分数或绕过控制。

---

1. 核心问题：Prompt 不是一次性文案

企业 AI 原型常从一个长 prompt 开始。它可能包含角色设定、业务规则、输出格式、安全提醒和 few-shot examples。原型阶段这样做很快，但进入生产后会暴露问题：

• Prompt 修改没有评测，效果好坏靠感觉。
• 不同团队复制粘贴，版本和规则不一致。
• 业务规则、安全约束和格式说明混在一起，难审查。
• Few-shot examples 没有来源、owner 和版本。
• 模型升级后 prompt 行为变化，缺少回归证据。
• 变更无法回滚，也无法解释为什么上线。

金融零售系统里，prompt 可能影响客户沟通、投诉分类、AML narrative、信贷材料总结和支付争议路由。它不是普通文案，而是会改变系统行为的配置资产。

核心问题应从“怎么写一个好 prompt”升级为：

Business task
  -> task signature
  -> prompt / examples
  -> eval set and metrics
  -> optimizer
  -> release gate
  -> monitoring and rollback

---

2. 技术贡献：从 Prompt Engineering 到 LM Program Engineering

2.1 DSPy

DSPy 把语言模型调用抽象成可声明的程序模块。你定义输入、输出、模块签名、示例和评价指标，然后用 compiler 或 teleprompter 优化 prompt、few-shot examples 或 pipeline。

这个思路的重要性在于：任务意图、字段契约和评测指标不再隐含在一大段自然语言里，而是变成可检查、可优化、可复用的对象。

2.2 OPRO

OPRO 将 LLM 用作优化器。系统给出已有 prompt、得分和反馈，模型生成新的 prompt candidates，再通过任务指标筛选。

它把 prompt 优化变成搜索过程：

Candidate prompt
  -> run eval
  -> score
  -> summarize errors
  -> generate next candidates
  -> compare and select

2.3 APE

Automatic Prompt Engineer 说明 instruction 本身可以自动生成和筛选。它的启发不是“人不需要写 prompt”，而是 prompt 空间可以被系统化探索。

2.4 共同转向

这三类方法共同推动四个变化：

---

3. 机制原理：Prompt Optimization Control Loop

自动 prompt 优化本质上是一个控制回路。最关键的不是 optimizer，而是目标、数据和门禁。

3.1 Task Signature

Task signature 把模糊需求转成可操作契约。以 AML alert summary 为例：

没有 signature，优化器只能优化表面表达；有 signature，优化才会围绕业务任务展开。

3.2 Candidate Generation

候选可以来自人工、LLM、few-shot 选择、指令重排、输出结构变化或已有 prompt 的变体。优化器扩大探索空间，但候选是否合法仍由治理决定。

3.3 Eval Dataset

Prompt optimization 没有 eval set 就只是更快的主观试错。数据集应覆盖正常样本、边界样本、缺证据样本、冲突样本、高风险样本、越权样本和旧版本回归样本。

3.4 Scoring Metric

指标决定优化方向。低质量指标会鼓励错误行为。例如“答案更自然”可能牺牲准确性，“答案更长”可能增加幻觉，单一 LLM judge 分数可能放大 judge 偏见。

更稳妥的指标组合包括：

• 证据支持率。
• 必填字段完整率。
• 高风险升级准确率。
• 拒答边界准确率。
• 人工 reviewer acceptance。
• 安全回归通过率。
• 成本和延迟。

---

4. 为什么这些方法有效

第一，它们把隐性技巧外显化。手写 prompt 的知识常在个人脑中，DSPy 式 signature 让团队能讨论输入、输出、约束和指标。

第二，它们扩大搜索空间。人工通常只能试少量变体，OPRO/APE 可以生成更多候选，并用同一套 eval 比较。

第三，它们把改 prompt 变成可回归的工程行为。每个候选都有分数、失败样本、成本和安全结果，变更不再靠“感觉更好”。

第四，它们降低模型迁移成本。如果任务被抽象成 signature 和 metrics，模型升级或供应商切换后可以重新优化，而不是从头手写 prompt。

第五，它们支持平台化复用。政策问答、投诉摘要、支付争议草稿、AML narrative、信贷材料检查，都可以共享任务签名、rubric、eval split 和 release gate。

---

5. 局限和误用

自动优化最大的风险，是把分数提升误认为可以上线。

在金融零售中，有些约束不能交给 optimizer 自由改写：

• 不承诺退款。
• 不提供个性化投资建议。
• 不自动作出信贷批准或拒绝。
• 不提交 SAR filing decision。
• 不绕过人工复核。
• 不使用未授权来源。
• 不隐藏不利证据。

这些应进入 platform policy 或 guardrail，而不是 prompt candidate 的可变文本。

---

6. 架构和产品价值：Prompt Platform

成熟系统不应把 prompt 散落在代码、文档和聊天记录中。至少应建立 prompt control plane：

Task Signature Registry
  -> Prompt / Example Registry
  -> Eval Dataset Store
  -> Optimizer Runner
  -> Candidate Store
  -> Eval Report
  -> Approval Workflow
  -> Deployment Config
  -> Monitoring
  -> Rollback

Prompt registry 应记录 prompt_id、task_signature_version、model_target、risk_tier、eval_set_version、safety_constraints、owner、approved_version、rollback_version 和 release notes。

Release gate 应检查五件事：

上线后仍要监控引用失败率、人工修改率、升级率、拒答率、投诉信号、处理时长、成本和分群表现。Prompt 变更应和模型版本、检索版本、schema 版本一起进入 trace。

---

7. 金融零售系统案例

7.1 Customer Service Copilot

客服助手可以优化回答结构、引用格式、语气清晰度、缺失信息提示和升级话术。但不能自动优化合规披露边界、费用豁免承诺、个性化投资建议或未经批准的营销话术。

Eval 应关注 policy citation accuracy、prohibited promise rate、escalation accuracy、agent edit distance 和 complaint signal。一个 prompt 如果让回答更流畅但增加承诺风险，就不能上线。

7.2 AML Narrative Assistant

AML narrative 可以优化 red flags 覆盖、事实和推断区分、missing evidence list 和 narrative structure。但必须固定边界：不提交 SAR 决策，不删除不利证据，不把推断写成事实，高风险 typology 必须升级。

Prompt optimization 的目标是减少调查员返工，而不是替代调查判断。

7.3 Credit Explanation Assistant

信贷材料助手可以优化证据摘要、缺失材料清单、内部 rationale draft 和引用清晰度。但不应生成未经批准的外发拒绝通知，不应使用 prohibited basis，也不能把模型建议当审批结果。

Fair lending、adverse action 和 human ownership 必须由独立 gate 检查。

7.4 Payment Dispute Drafting

支付争议助手可以优化交易字段抽取、网络规则引用、补证请求和 SLA 提醒。但不能承诺退款、跳过证据缺口或把卡组织规则解释成最终裁决。自动发送消息必须受 policy engine 和人工审批约束。

---

8. 防过拟合设计

Prompt optimization 至少需要 train、dev、test、challenge、hidden SME 和 production sample 六类数据。优化器可见 train，团队用 dev 调整策略，发布前看 test，高风险边界靠 challenge，hidden SME 防题库过拟合，上线后抽真实样本监控。

硬性门槛应单独设置。Critical safety tests、高风险升级、未授权来源过滤、approved language、成本 SLO 不能被平均分掩盖。

一个常见错误是平均质量提升，但高风险样本退化。这类变更应被阻断，因为金融零售系统的风险不是均匀分布的。

---

9. 可交付资产

---

10. 学习验证

读完后应能回答：

1. DSPy 与手写 prompt 的本质差异是什么？
2. OPRO/APE 为什么提高迭代效率，但不能自动上线？
3. Task signature 如何把需求转成可优化对象？
4. Eval overfitting 在 prompt optimization 中如何发生？
5. 哪些安全约束不应成为 optimizer 可改写文本？
6. 如何为 payment dispute assistant 设计 prompt release gate？
7. 如果新 prompt 提高平均分但降低高风险升级率，应如何决策？

掌握这组方法的标志，是能把 prompt optimization 放进受控发布系统，而不是只把它理解成“让 AI 帮我改 prompt”。

---

SOTA 状态标注 (2026-07-01)

本篇属于第二、三遍深读池（参考架构/深读笔记），未列入 12 周主线必读。时效基线为写作时点；引用前请按 CLAUDE.md 全局时效性硬规则复查最新进展。模块级 SOTA 对照见 docs/AI_SYSTEMATIC_LEARNING_ROADMAP_2026.md 各周「2026 SOTA 对照」行与文末「SOTA 检查」。