用DSPy把提示词调试变成程序优化

把提示词藏进 Python 函数，并不等于告别提示词工程。Kevin Madura 在这场 DSPy 分享里真正主张的是：先把大模型应用写成输入输出明确、模块可以组合的程序，再用数据和指标优化背后的提示词。

对需要维护文档提取、消息分类或工具调用流程的开发者，这个思路值得看。它把讨论从「这句话怎么写模型才听话」，推进到「流程怎么拆、结果怎么验、模型怎么换」。但演示跑通与生产效果之间，仍然缺少几组关键数据。

签名让模型调用有了接口，但没有消灭提示词

DSPy 的入口是签名（Signatures），用来声明输入和输出。例如，"text -> sentiment" 表示输入文本、输出情感判断。复杂任务可以使用基于 Pydantic 的类，描述更具体的字段和类型。

这和前端调用一个接口很像：调用方关心传什么、拿回什么，不必每次处理 choices、messages、content，再手写字符串解析器。

不过，签名并非纯粹的类型声明。字段名也会传给模型，相当于微型提示词。作者演示情感分类时，仍然通过「数字越低越负面」这样的指令约束结果。已有的好提示词，也可以作为系统指令放进签名或模块，成为优化起点。

DSPy 改变的是提示词的组织和优化方式，提示词仍在程序背后工作。

签名下面还有适配器（Adapters），负责把输入输出约定转换成实际调用格式，如 JSON、XML、BAML。作者用 inspect_history 查看 JSON 与 BAML 适配器生成的提示词，展示后者更简洁、更易读。分享提到，不同适配器可能造成 5-10% 的表现差异，但没有交代统一的测试条件，不能把这个范围当成稳定收益。

模块化的价值，是让模型和业务逻辑各归其位

签名描述任务，模块（Modules）组织执行过程。DSPy 提供 Predict、ChainOfThought、ReAct，也允许自定义模块：先调用模型，再运行普通 Python 业务逻辑。工具（Tools）则直接使用 Python 函数。

作者展示的通用文件处理器，比单次问答更能说明这个设计：

先分类文件，再进入不同分支。SEC 文件提取指定信息，合同做递归摘要，图片做视觉解读；图片分支可以用 Gemini，文本分支可以用 GPT-4.1。流程结构保留下来，模型可以分别选择。

文档处理也有两种目标。如果只是探索内容，可以让模型挑选重要信息并返回字典；如果后续要接数据库或业务接口，就预先用 Pydantic 定义交易日期、类型、数量等字段，再按结构访问结果。

演示还包括用 attachments 加载英伟达的 SEC Form 4 PDF，以及让 ReAct Agent 使用 Perplexity 搜索和获取 URL 内容的工具调查人物背景。多个 Agent 可以异步执行，并通过 trajectory 查看工具调用轨迹；Phoenix 则用于追踪 LLM 调用。环境中配置了 Claude、Gemini、GPT-4.1 mini 等模型。

这些例子说明了可组合性，但没有证明所有文件都能稳定处理。尤其是把 PDF 页面转成图片、再让 Agent 判断合同章节边界，仍然需要检查识别错误会怎样影响后续提取。

自动优化能不能成立，先看你怎样定义成功

优化器（Optimizers）需要指标（Metrics）告诉它，什么结果更好。指标可以是严格匹配，也可以由另一个 LLM 评分。

客服分类演示采用数据集检查「紧急程度是否匹配」，再让更强的教师模型分析失败案例、提供反馈，迭代修改提示词。原文将这个优化器写作 Jeepo，没有提供版本或完整调用代码，照着落地前还需要核对名称。

优化结果是一个新的程序模块，可以保存、加载和调用。按作者的解释，其核心仍包含动态构建的提示词，例如从失败案例里发现「名字必须大写」这样的隐含要求，再补入指令。

作者认为，准备质量良好、结构清晰的 10-100 个输入输出对，就能获得显著效果。但材料没有给出优化前后的分数、数据划分，也没有提供迁移到便宜模型后的质量与费用对照。

因此，「强模型辅助优化，再换小模型」可以作为实验方向，不能直接写进降本承诺。优化期间的多次调用也要计费。作者强调，成本主要取决于 LLM 调用次数；长上下文可以加入压缩逻辑，而未来是否会被更大窗口解决，只是他的判断。

我的判断

我认可 DSPy 把模型调用纳入普通程序结构的方向。相较于散落在代码里的提示词字符串，明确的签名、可复用模块和可追踪调用，更方便维护多步骤流程。

但类型约束解决不了事实正确性。交易数量符合字段类型，不代表数量提取正确；客服消息格式合法，也可能分错紧急程度。评测数据和业务校验仍要自己建立。

作者认为 DSPy 比 LangChain 更少束缚，这属于使用体验，材料没有提供同任务对照。对于只有一次模型调用、输出结构简单的功能，直接使用模型 SDK 和结构校验也可能足够。流程开始出现分支、多模型和重复调参需求时，DSPy 的收益才更容易显现。

没有可靠指标，自动优化只能更努力地追逐一个未必正确的目标。

能拿来做什么

• 给现有客服分类功能整理一批人工确认的输入输出，按作者建议从 10-100 对起步，并预留未参与优化的样本检查效果，避免只看优化器报告的分数。
• 做合同或 SEC 文件提取时，先定义 Pydantic 字段，再单独校验日期、数量等业务信息；把自由提取留给探索阶段。
• 在已有 Node 应用中，可以先把一个边界清晰的文档处理流程交给 Python 服务试验 DSPy，再比较质量、调用次数和维护成本，决定是否扩大使用范围。
• 将用户点赞、点踩与具体失败样本关联，定期离线重新优化；涉及换模型时，重新跑同一套评测，不把程序接口兼容当成效果兼容。