DSPy使用笔记 先验证LM程序合同再谈优化

在试用 DSPy 之前，请确保你的 LLM 流程具备“合同”

DSPy 是一个很容易被肤浅理解的框架。

若仅仅将其视为“更高级的 prompt 编写方式”，初次尝试很可能偏离方向。更值得思考的问题是：你的语言模型工作流程是否能被封装为一个独立程序，具备清晰的输入、输出、固定样本、可追踪的 trace，并允许优化器调整提示词，同时保持业务边界不变？

只有达到这一步，DSPy 的实际价值才能充分发挥。

本次复核的信息来源于 Doramagic 的 DSPy 项目页面、说明文档、PROJECT_PACK，以及上游 README、pyproject.toml 和 GitHub API 快照。官方安装方式仍为 pip install dspy，包元数据声明 name="dspy"、版本 3.3.0b1，Python 版本要求 >=3.10,<3.15。GitHub API 显示该仓库在 2026-07-05 仍有推送，近期 PR 涉及 empty devset 的错误提示、Document 格式化、GEPA trace attribution 等细节。

这些信息表明项目仍在积极维护，但这并不意味着可以直接引入。真正的采用决策需要依据以下三条关键分界线。

1. 先将任务合同与提示词分离

在 DSPy 中，最值得优先关注的并非某个 prompt，而是 Signature。

Signature 定义了输入和输出字段。Module 将这个合同封装为可调用的计算单元。Adapter 则将合同转换为模型实际可接受的格式，并将模型输出解析为结构化字段。

这引出一个非常实用的评审问题：

团队能否在调整 prompt 之前，先明确定义输出字段？

如果不能，DSPy 暂时无法挽救这个流程——你们仍在定义任务本身。第一轮尝试应仅围绕一个非常简单的合同：输入文本、检索上下文、答案、引用、置信度，或者产品实际所需的几个字段。切勿一开始就引入 agent、工具调用、多阶段流水线。

2. 将编译优化与运行正确性区分开

DSPy 的优化器能够为模块优化 prompt 或权重。这虽然有用，但失败模式也随之改变。

危险的用法是：“优化器找到了更好的 prompt，直接发布。”

更稳健的用法是：“优化器生成一个候选版本，然后使用固定的 devset 进行对比，检查 trace，并保留回滚路径。”

上游最近的改动恰好揭示了这一边界。例如，empty devset 不应默默变成除零错误，而应抛出明确的 ValueError；GEPA trace attribution 也需要按照 predictor identity 进行归因。这里的重点并非某个 PR 本身，而是 DSPy 的真实操作逻辑：优化必须依赖于样本、trace 和归因。缺少这些，你只是以更复杂的方式在移动 prompt 文本。

一个最小验收路径应该非常朴素：创建 Python 3.10 隔离环境；配置一个廉价模型；定义一个 Signature 和一个 Module；运行一个很小但固定的 devset；打印 compiled program 和 history/trace；保存优化前后的结果，以便观察行为差异，而非仅看分数。

如果这套流程已经让你感到繁琐，那么 DSPy 可能并非当前任务的首选抽象。

3. 将检索质量与答案质量分开

DSPy 常被应用于 RAG 场景，但 RAG 的问题往往不仅限于最终答案。更常见的是分块(chunk)、检索(retrieval)、元数据(metadata)、文档格式、负例样本等环节先出了问题。

因此，不能仅仅用“是否能够回答问题”来评估 DSPy。

关键在于：Module 接收到的 retrieved records 是否准确；生成之前能否检查检索结果；输出合同中是否强制要求引用或 evidence 字段；devset 中是否包含“应该检索失败”的样例；优化器是否能在提升答案质量的同时，不掩盖检索性能的退化。

Doramagic 的 DSPy 说明书将项目拆分为 Signatures、Modules、Adapters、LM clients、Optimization/Compilation、Tools、Streaming、Retrieval 和 Utilities 等模块。这种拆分方式很有价值，因为它促使你不应将“最终答案”作为唯一的测试对象。

何时适合引入 DSPy

DSPy 更适合已经具备重复性 LM 任务的团队：任务边界大致清晰，有样本、有评测、有 trace，希望将 prompt 层转变为可编程、可审查、可优化的部分。

它不太适合任务仍处于产品探索阶段、缺乏样本、且无法明确正确输出是什么的情况。此时应先用常规代码、一个小型 eval 文件和人工 trace 来稳定合同。

采用规则其实十分简洁：

当“修改 prompt”应当被视为“编译程序”时，使用 DSPy。

当“修改 prompt”实际上仍属于产品定义阶段时，暂时不要引入 DSPy。

来源：Doramagic DSPy 项目页面/说明文档/PROJECT_PACK，上游 README、pyproject.toml、GitHub API 仓库与发布快照。

标签：DSPy、LLM、RAG、prompt-optimization、agent-engineering、evaluation、Python、open-source、AI-engineering、observability、retrieval、GEPA