多阶段语言程序与自动 Prompt 优化：从 DSPy 到 MIPRO

#

当 RAG、Agent 与「复合 AI 系统」叠成十几步流水线时，真正卡住团队的往往不是再换一个向量库，而是：谁在什么粒度上优化 prompt、demo 与模块组合，以及端到端 metric 如何把功劳摊到每一步。 本文围绕 DSPy 与其中的 MIPRO（Multiprompt Instruction PRoposal Optimizer）梳理机制、文献可核对部分与仍属工程判断的边界；画面素材为访谈双人镜头，未见可读架构图或结果表，定量结论以论文与官方 API 为准。

问题空间：多阶段程序、复合系统与评估瓶颈

#

为什么：检索增强、工具调用与多角色编排，本质都是「多次 LM 调用 + 中间状态」——网页 Agent 逐步行动、检索器改写查询、写作流水线分节生成，都依赖外部状态，很难用单次结构化输出在上下文内等价替代（演讲者观点）。

机制/约束：业界常混用 multi-stage、compound、multi-agent；在 DSPy 主论文 叙事里，重点是可编译的多模块程序与程序级 metric，而非 UI 上有几个聊天气泡。CrewAI 式多角色团队可视为另一类多阶段 LM 系统，但营销类任务往往缺少可在线优化的延迟指标——评估设计才是瓶颈（演讲者观点）。

常见误区：把「Agent 框架」与「prompt 优化器」对立；优化器针对的是程序内各 LM 模块的 instruction/demo 参数，中间检索、函数调用可以是黑盒，只要 metric 在程序出口可算（见后文 P09 边界）。

若你已有 Weaviate / 其他向量库上的 RAG，可把它视为程序中的 Retrieve 或自定义 Python 模块：优化器不会替你改 embedding 模型，但会改「如何用检索结果回答」那一层的 instruction 与 demo。主持人提到的「生成式反馈环」——把生成内容写回库以供后续检索或微调——与多阶段程序正交，属于数据飞轮设计（演讲者观点），需单独定义一致性与权限策略。

DSPy：用程序声明替代手工 prompt 工程

#

为什么：手工 prompt 在个案上可极强（嘉宾自述 EHR 项目中优于有限数据微调——演讲者观点，不可外推），但换模型、扩任务时维护成本高。

机制/约束：DSPy 将流水线写成 Module + Signature + Metric；teleprompter / optimizer 在训练集上搜索各模块的 instruction 与 demonstration，目标为程序级分数，而非单点 loss 反传。

怎么做（minimal）：

import dspy

class QA(dspy.Signature):
    """Answer from context."""
    context = dspy.InputField()
    question = dspy.InputField()
    answer = dspy.OutputField()

class RAG(dspy.Module):
    def __init__(self):
        self.retrieve = dspy.Retrieve(k=3)
        self.generate = dspy.ChainOfThought(QA)

    def forward(self, question):
        context = self.retrieve(question).passages
        return self.generate(context=context, question=question)

# metric + trainset → optimizer.compile(program, trainset=...)

常见误区：把 DSPy 当成「更好的 prompt 模板库」；其核心是可优化的参数化程序，与 OPRO 类「LM 当优化器」思路可组合，但多模块时信用分配更难（下节）。

访谈中 Krista 将「用 GPT-4 写 DSPy 程序」描述为因 API 类似 PyTorch 而「还不错」（演讲者观点）。这降低的是拓扑搭建成本，不替代 metric 设计与优化预算；愿景级的「用户只说 optimize」仍依赖任务示例、评判标准与算力（演讲者观点）。工程上更稳妥的路径是：人工搭骨架 → 自动搜 prompt/demo → 再考虑 per-stage 换模型或 prompt routing（演讲者观点）。

MIPRO：提议、自举与组合搜索

#

为什么：多阶段程序中，每个模块的 prompt 含 instruction 与 few-shot，搜索空间随模块数指数级膨胀；需要专门处理「如何提议好候选」与「谁该为 metric 负责」（论文 §3.1–§3.2 术语：proposal challenge、credit assignment challenge——arXiv:2406.11695）。

机制/约束：

二者不矛盾：文献把 bootstrap 单列；访谈将「提议+搜索」并谈。主循环可概括为：

Few-shot 来源（P02，已核实）：对训练样本跑完整程序；若 metric 判定成功，保留逐步 trace 作为该模块 demo——BootstrapFewShot 族与 MIPRO 论文 Initialize 一致。

Instruction 提议（P03，已核实）：GroundedProposer 可接入 dataset summary、program summary（DescribeProgram / DescribeModule）、bootstrap I/O，以及 categorical tip（源码含 high_stakes 等）。嘉宾称「让 LM 看见自己的程序结构」能改进提议——演讲者观点，与论文 grounding 设计一致。

组合搜索（P04，部分核实）：将 instruction × demo 视为昂贵黑盒；MIPRO 用 Optuna TPE 作 surrogate，在 mini-batch 上评估以抗噪（论文 §4.3；Snoek et al. 2012）。MIPROv2 默认 minibatch_size=35（源码），勿与论文中「20–50 次 full evaluation trials」预算混为 batch=20（核验报告已标注）。

怎么做：

tp = dspy.MIPROv2(metric=my_metric, prompt_model="gpt-4o-mini", task_model="llama-3-8b")
optimized = tp.compile(my_program, trainset=train, num_trials=30, minibatch=True)

常见误区：以为 MIPRO 只改 system 一句；它同时搜 instruction 与 demonstration 组合，且 v2 强调小 batch 上的快速试探。

论文 §3.2 还讨论 greedy、surrogate、history-based 等信用分配策略：surrogate 与 MIPRO 主循环中的 TPE 一致，用观测过的 (组合, mini-batch 分数) 估计各候选潜力；greedy 逐模块锁定，实现简单但可能陷入局部最优。访谈未逐条对比算法名，落地时以 dspy.MIPROv2 默认策略为准，并在 dev 集上对比「只优化最后一层生成器」与「全模块一起搜」的增益差。

反直觉（标注来源）：优化器常找到人类难以想到的 instruction 措辞（主持人引 unreasonable effectiveness of prompts 类轶事，Krista 认同）；向 proposer 强调 high_stakes 情境的 tip 在源码与论文附录中均有对应，但「为何有效」尚无机制解释（演讲者观点）。更多 few-shot 并非单调有益——嘉宾警告长 demo 可能迷惑模型，Llama-3-8B 级 task 模型有时不如只用 instruction（演讲者观点），与 industry 上的 many-shot 热潮形成张力；Google 原始 many-shot 论文 ID 勿随意引用（核验中 2402.04326 为无关论文）。

信用分配：Module-level OPRO 与 Program-level OPRO

#

为什么：多模块共用一个端到端 metric 时，必须判断哪一 stage 的哪类变量拉高了或拖累了分数（论文 §3.2 credit assignment）。

机制/约束：

• Module-level OPRO：仅把单个模块的历史 instruction + 该模块相关分数交给 LM 提议下一版（扩展 OPRO 的单 prompt 设定）。
• Program-level OPRO：把整程序所有 instruction 与单一 program score 交给 LM 做全局推断——论文 §4.5 实验 未带来额外增益；嘉宾称当前模型尚不足以做好全局贝叶斯式信用分配，module-level 更现实（演讲者观点，与论文结论一致）。

常见误区：与 ORPO（偏好对齐）混淆——二者缩写相近、问题无关（已核实）。

有确定单元测试的代码生成任务，嘉宾认为「执行结果 + 自改进闭环」最强（演讲者观点）；开放域写作、营销文案仍依赖 LLM-judge 或人工抽检。DSPy 可把 metric 链也参数化，但若评判器与真实业务目标错位，优化会在错误目标上过拟合——这与 RAG 里「检索指标 ≠ 用户满意度」是同一类问题。

Meta-proposer、评判器与「不可微」中间件

#

Meta-proposer（P08，已核实）：0-Shot MIPRO++ 用 BO 选择是否向 proposer 提供 dataset summary、program summary、tip、temperature、meta-prompt 内 demo 等离散开关（论文 §4.4）。嘉宾提醒：全量 tune meta-prompt 耗优化轮次，预算紧时可能不如直接把 trial 花在主搜索上——演讲者观点；论文 Lesson 5 亦讨论高低预算下的权衡，无统一公式。

LLM-as-judge：无金标准的任务（摘要质量、推文风格）常依赖评判 LM；Who Validates the Validators? 讨论评判者与人类对齐。DSPy 可把 metric 本身建成可优化程序——演讲者观点，需警惕评判漂移。

Tool / 检索中间件（P09，部分核实）：优化目标仍是程序出口 metric；论文六任务以 QA/分类/检索管线为主，未提供充分 tool-use 优化基准——嘉宾称 LangProBe 将扩展 tool 场景，但公开仓库名 LangProBe 本次未在 GitHub/DSPy README 中命中（论文 §5.1 基准内容可核对，产品名未核实）。

Proposer vs task 模型（P10，部分核实）：论文 §5.2 主实验 task model 为 Llama-3-8B，proposer 为 GPT-3.5（非访谈口述的 GPT-4 默认）；访谈称 8B proposer 与 GPT-4 差距「小于预期」——演讲者观点。结构上 proposer 调用次数通常远少于 task LM 在训练集上的反复 rollout，故可把大模型预算倾斜给 proposer（演讲者观点）。

基准、LangProBe 与可复现实验

#

为什么：没有对齐的任务集，就无法比较 BootstrapFewShot、MIPRO 与手工 prompt 谁更值得算力。

机制/约束：MIPRO 论文 §5.1 给出 六个任务（HotPotQA、HotPotQA Conditional、Iris、Heart Disease、ScoNe、HoVer），各含 dataset / metric / 固定 LM program 拓扑；主表为 accuracy 或任务专属指标（如 HoVer Retrieval@21）。摘要写明在 DSPy 生态发布新 optimizer 与 benchmark。

怎么做：复现 Table 2 时对齐论文 §5.2：Llama-3-8B 作 task model、GPT-3.5 作 proposer（特定任务 bootstrap teacher 用 GPT-4o）、optimizer budget 20–50 full eval trials，并记录 minibatch 带来的额外 trial 数。

常见误区：把访谈中的 LangProBe 名称直接写成已验证的 PyPI/GitHub 包——本次检索 stanfordnlp/dspy 未命中该字符串（名称未核实）；以论文六任务为准更稳妥。主持人提到的「DSPy ImageNet 时刻 / ~20 点 margin」（Bo Wang 组）未验证具体 benchmark，不宜写入生产决策。

与 RAG、Agent UI、微调的分野（未收敛的结论）

#

微调：在数据极少且任务分布稳定时，微调仍可能胜出；但若流水线含检索、工具、多模块，端到端 prompt 优化有时更省标注（EHR 个案为 演讲者观点）。更现实的组合是：DSPy 优化 prompt/demo → 收集高分 trace → 再决定是否蒸馏或微调小模型。

若你要落地

#

1. 先固定程序拓扑与 metric：在 STORM 类多阶段写作或 RAG 管线上，用 dev 集定义可自动计算的 metric；模糊任务再引入 LLM-judge，并计划校对人抽验。
2. 从 BootstrapFewShot + 小预算 MIPROv2 起步：num_trials 对齐论文 20–50 次 full eval 量级；启用 minibatch=True 时注意默认 minibatch_size 与 trial 计数方式（文档与 mipro_optimizer_v2.py）。
3. 分模块信用分配：优先 module-level 策略；勿指望 program-level OPRO 在当前模型上稳定增益（论文 §4.5）。
4. 分开配置 prompt_model 与 task_model：以论文为准核对 proposer 规模；用本地 8B 跑 task、云端较强模型跑 proposer 是常见省钱组合（论文为 GPT-3.5 proposer + Llama-3-8B task）。
5. 为 tool-use 与检索单独建基准：MIPRO 论文六任务不覆盖复杂 tool 链；上线前用自有 trace + 通过/失败 metric 补洞（演讲者观点：优化器对中间件「应保持 agnostic」，但 benchmark 缺口真实存在）。

参考与延伸阅读

#

• DSPy 官方文档
• DSPy 优化器教程（含 MIPROv2 三阶段）
• MIPROv2 API 参考
• BootstrapFewShot API
• MIPRO 论文：Optimizing Instructions and Demonstrations for Multi-Stage Language Model Programs
• DSPy 论文：Compiling Declarative Language Model Calls
• OPRO：Large Language Models as Optimizers
• ORPO（与 OPRO 无关，偏好对齐）
• Practical Bayesian Optimization（Snoek et al.）
• Who Validates the Validators?（LLM 评判对齐）
• STORM：多阶段写作流水线示例
• DSPy Tools / ReAct 编程指南
• GroundedProposer 源码
• MIPROv2 实现（mipro_optimizer_v2.py）
• stanfordnlp/dspy GitHub 仓库