DSPy

为什么选择 DSPy？

当提示词工程（Prompt Engineering）开始演变为软件工程时，DSPy 就派上用场了。管理单个提示词并不难，但生产环境中的 LLM 系统通常包含多个步骤、检索调用、分类器、提取任务、排序逻辑、工具调用以及评估需求。

DSPy 将语言模型的行为视为一个“程序”来解决这个问题。开发者不再手动编写冗长的提示词字符串，而是定义结构化的输入输出、组合模块、定义指标，并让优化器根据示例自动改进程序。

DSPy 的核心价值不在于降低入门门槛，而在于让复杂的 LLM 系统更加系统化。对于关注可靠性、回归测试、模型切换、成本降低和可衡量质量提升的团队来说，DSPy 的价值远高于那些只做一次性聊天机器人演示的项目。

核心工作流

实际的 DSPy 工作流从定义每个语言模型步骤的功能开始。这通常始于“签名”（Signature）：即输入和输出的类型化契约。随后，开发者选择合适的模块，如直接预测、思维链（CoT）推理、检索增强生成（RAG）或 ReAct 风格的工具调用。

下一步是评估。当团队定义好示例和能够捕捉有效行为的指标时，DSPy 的威力就会显现。这些指标可以是精确匹配、语义相似度、答案忠实度、提取准确率、分类 F1 分数、人类偏好对齐或自定义评分函数。

一旦程序、示例和指标就绪，优化器就可以“编译”出一个更优版本的程序。这可以改善指令、演示示例或多阶段行为，而无需手动重写每个提示词。

简化的工作流如下：

1. 通过签名定义任务契约。
2. 选择或组合模块以确定推理策略。
3. 根据需要添加检索器、工具或外部函数。
4. 创建示例和评分指标。
5. 针对程序运行优化器。
6. 保存优化后的程序。
7. 跨模型比较质量、延迟和成本。
8. 在常规 Python 应用中部署程序。

这与“提示词链”是完全不同的思维方式。DSPy 鼓励开发者思考：什么是可以衡量、优化、替换和重用的？

适用场景

DSPy 最擅长质量可衡量的任务，包括 RAG 系统、问答、分类、信息提取、路由、摘要流水线、支持工单分拣、使用工具的智能体以及多跳推理工作流。

在 RAG 场景中，DSPy 非常有用，因为检索、答案生成、引用行为和忠实度都可以表示为程序的独立部分。团队不再凭直觉调整单个提示词，而是可以针对示例和指标优化整个流水线。

在提取和分类任务中，DSPy 的结构化签名使预期输出变得明确，降低了纯自然语言提示词的脆弱性，并使模型或推理策略的对比更加容易。

对于智能体，当智能体拥有明确的工具边界和可衡量的成功标准时，DSPy 最为有效。它不适合目标模糊且缺乏评估集的开放式自主系统。

竞品对比

LangChain 是最常被拿来对比的框架。LangChain 为智能体、链、工具、集成和应用编排提供了广泛的构建块。DSPy 则更专注、更具主见，侧重于对语言模型行为进行编程并根据指标进行优化。如果集成广度和编排模式最重要，请选择 LangChain；如果问题的核心是提示词和流水线的优化，请选择 DSPy。

LlamaIndex 是重度 RAG 应用的首选对比对象。LlamaIndex 深耕于数据摄取、索引、检索和知识工作流。当团队想要围绕检索优化推理和生成程序时，DSPy 表现更佳。许多团队会结合两者：使用 LlamaIndex 负责数据和检索基础设施，使用 DSPy 负责结构化语言模型程序及优化。

Haystack 是搜索和问答系统的另一个实用选择。它通常更适合生产级搜索流水线、检索器和企业信息检索工作流。如果主要挑战是优化语言模型调用和多步提示词行为，DSPy 则更具吸引力。

Semantic Kernel 适用于深度绑定微软生态或构建基于计划器/工具的 AI 应用。DSPy 虽然不那么偏向企业框架，但作为 LLM 程序的科研级优化层表现更强。

Instructor 和 Guidance 在结构化输出和控制生成方面更为接近。对于简单的模式约束输出，它们更容易上手。DSPy 虽然更重，但为团队提供了更广泛的框架来组合和优化多阶段程序。

最佳配置

当团队将评估数据视为一等公民时，DSPy 运行效果最好。在优化任何内容之前，团队应定义具有代表性的示例、失败案例以及反映实际产品目标的指标。

对于 RAG 系统，这意味着收集问题、预期答案、相关文档和忠实度检查。对于提取任务，意味着标注示例和模式级校验。对于分类任务，意味着明确类别定义、边界情况并关注类别不平衡问题。

强大的生产环境配置通常包括：

• 用于快速迭代的小型开发集；
• 用于优化器决策的独立验证集；
• 用于回归检查的留出测试集；
• 缓存模型调用以控制成本；
• 版本化的优化程序；
• 针对特定提供商的延迟和成本追踪；
• 明确的模型或优化器上线规则。

DSPy 还应与常规软件工程实践相结合。程序应保存在版本控制系统中，评估应尽可能在 CI 中运行，优化后的产物应像应用代码一样进行版本化管理。

迁移建议

从手写提示词迁移到 DSPy 应该循序渐进。第一个目标最好是那个输入输出明确、有评估数据但让人头疼的提示词。一次性重写整个智能体或 RAG 系统会让你难以判断 DSPy 究竟是提升了系统性能，还是仅仅改变了太多变量。

实用的迁移路径是：

1. 选择一个具有可衡量输出且重度依赖提示词的步骤。
2. 将其转换为 DSPy 签名和模块。
3. 添加 20 到 100 个代表性示例（如果有）。
4. 定义一个能捕捉真实失败模式的指标。
5. 将手写提示词与 DSPy 程序进行对比。
6. 仅在基准测试正常工作后进行优化。
7. 保存优化后的程序并长期追踪变化。

从 LangChain 或 LlamaIndex 迁移的团队不需要替换所有内容。DSPy 通常可以作为优化后的语言模型层嵌入这些系统中。例如，检索可以保留在 LlamaIndex 中，而将答案生成、重排序或声明验证实现为 DSPy 模块。

实施评估清单

在采用 DSPy 之前，团队应确认以下几点：

• 项目是否有可重复的语言模型任务，而非一次性提示词？
• 团队能否定义有用的输入和输出契约？
• 是否有示例或日志可以转化为评估集？
• 是否存在超越主观偏好的质量衡量指标？
• 模型切换、降本或提示词优化是否能产生实际价值？
• 工程团队是否具备维护 Python 代码和部署基础设施的能力？
• 提示词、输出、追踪和缓存数据是否可以安全存储或检查？
• 团队是否清楚流水线中哪些部分是被优化的，哪些是固定的？

如果具备这些条件，DSPy 可以让 LLM 开发更加系统化。如果团队只需要一个快速上线的聊天机器人，更简单的框架或低代码构建工具可能是更好的起点。