从DSP到DSPy：论文详解

DSP

回头看看DSPy那篇2022年的开山之作——《DEMONSTRATE–SEARCH–PREDICT: Composing retrieval and language models for knowledge-intensive NLP》。当时作者把DSP的核心拆成了三个模块：Demonstrate、Search和Predict。听起来有点抽象，但拆开来看其实很直白。

• Demonstrate
  ：演示环节，需要喂训练集进去，本质就是Few-shots的思路；

• Search
  ：从知识库里捞信息；

• Predict
  ：基于已有依据生成最终输出。

这三个组件，跟现在主流的RAG流程其实大差不差。RAG通常怎么做的？输入阶段：

1. 先把知识库（通常是文件）丢进去；
2. 文件分片或分组，或者干脆让LLM自己生成QA对；
3. 把这些输出转成向量存起来。

到了问答环节：

1. 用户提问题；
2. 去向量库里检索；
3. 捞出TopN条相似度最高的结果；
4. 把这些结果塞进上下文，让LLM生成回复。

但2022-2023年那会儿，LLM的上下文窗口最高才4096 tokens，所以得想办法更高效地提取上下文。而且当时微调一个LLM的成本实在不低，不管是自购显卡还是租用资源，都不划算。另外，LLM的输出效果严重依赖提示词和上下文的质量——稍微写得不对，结果就偏了。

DSP的核心理念就是：无论是大语言模型（LM）还是召回模型（RM），都只是基础设施。从领域专家的角度看，真正需要的是一个能快速搭出有效工作流、成本又可控的方案。这里说的成本，主要花在整理训练数据集、反复试错调试提示词（trial-and-error）这些事上。

所以DSP参考了PyTorch的设计思路，想把机器学习的理念搬到大模型工作流里来，特别是针对领域专家那种应用场景。而不是靠反复调提示词来优化推理效果。重度依赖提示词构建应用，实际踩过的坑还真不少。

比如提示词调试这事，有时候真像玄学。虽然已经有像ReACT这样的框架，但很多时候你根本说不清提示词哪写得好、哪写得不好。既希望LLM能泛化任务，又希望它别乱编。所以调试提示词的成本通常不低，多少有点碰运气、凭感觉的味道。

另一个问题是提示词很难迁移。比如你基于GPT-4调好了一套提示词，想换到更便宜的模型上批量跑，结果可能完全不适用，效果差一大截。

另外，当工作流里的步骤越来越多，提示词加多轮对话的模式容易让LLM自己“串线”——某个环节突然跳票。当然，从现在的角度看，这更多是当时LLM能力受限所致。

针对这些问题，DSP提出的方案是：降低提示词在工作流中的权重，用一套高度模块化的程序，让LM通过示例数据自己“学会”怎么写prompt，或者生成思维链。就像机器学习那样，靠数据驱动，而不是靠人工调参。

论文在三个知识敏感的QA任务上做了测试：开放域QA、多跳QA、对话式QA。评估指标用了EM和F1。

这里简单解释一下EM和F1：
- EM（Exact Match）：要求模型输出与参考答案完全一致，连空格、标点都不能差，非常严格。
- F1 Score：精确率（Precision）和召回率（Recall）的调和平均值，能更灵活地衡量模型在准确性和覆盖度之间的平衡。F1的公式是 2×(Precision×Recall)/(Precision+Recall)，值越接近1越好。

在Open-SQuAD、HotPotQA、QReCC三个数据集上，DSP程序都跑出了不错的分数。

不过话说回来，DSP和RAG对比，作者其实有点绕过了“整理训练集”这一环的成本。但换个角度看，这确实是一种用数据驱动来构建AI应用的可行思路——RAG的文件组织、分片、生成QA都是全自动的，而DSP需要你一开始就针对场景构建有效数据。

举个例子：你想让LLM读几篇公众号文章，然后生成总结。在整理训练集时，你可能需要自己先读文章，再对AI生成的总结进行二次修改。另一种方式：先用GPT-4跑出一批结果作为训练集，然后放入DSP程序，转而用免费开源的本地模型，效果可能跟直接跑GPT-4差不多。

当然，这篇旧论文里的DSP框架还不够完善，直到后来提出DSPy，整个工作流才算真正靠谱起来。

DSPy

在DSPy的论文《DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines》里，提出了三个新概念：signature、module和teleprompter。一个一个来看。

，可以翻译成“信号”或“暗号”。它就是直接丢进Predict函数里的输入值。Signature用来抽象提示词或者微调——注意这里的微调是指对工作步骤的微调，不是模型权重的微调。

比如论文里的例子：signature可以是 question -> answer，或者 english_document -> french_translation。不同signature在DSPy内部被封装成相对固定的处理工作流。所以DSPy的目标就是把原来复杂的一大段提示词拆分成多个互相独立的处理单元。

Predict函数是传入signature一起工作的核心模块，用来调用LM，它本身也是一种module（下面会讲）。

简单讲，DSPy做的不是把一堆复杂提示词拼在一起，而是把提示词拆得更细，这样一来每个处理单元的提示词都变得相对简单。

，模块，是signature更高一层的抽象。刚才说的Predict就是module之一。此外还有ChainOfThought、ProgramOfThought、MultiChainComparison、ReAct这些内置模块。

Module还包括：

• 可参数化输入：指定模型、基础模块等；
• 工具：通过signature内置调用不同的RAG算法，或SQL查询生成；
• 可编程：比如初始化时定义召回函数，生成答案用CoT，然后组合到一起工作。

你可以把module理解为基于signature封装好的工作流或工作流集合。开发者可以直接用，也可以自定义，提高复用性。

，直译是“提词器”，但实际是模仿PyTorch的优化器（Optimizer）。它接收三个输入：程序、训练集、评估函数（metric），输出是优化后的程序。

你可以把teleprompter想象成一个“教师程序”，它负责从数据中采样，并在过程中做各种优化（包括提示词的优化）。

至此，DSPy完整地模仿了PyTorch机器学习的步骤：

• 收集针对某一场景的有效数据；
• 分割训练集与测试集；
• 通过定义signature + module + teleprompter进行算法训练；
• 运行测试集，观察metric输出是否理想（类似观察拟合度）；
• 训练后的算法可以导出，直接用于工作流或应用中。

总的来说，DSPy想要解决这几个问题：

1. 在不影响输出效果的前提下，用简洁预定义的模块替代原来复杂的提示词串；
2. 把模块参数化，让提示词撰写变成优化器的工作，这样切换模型时效果依然稳定；
3. 模块化设计便于深入探索那些表现优秀或符合细致评估的复杂工作流。

论文里也通过代码直观演示了DSPy怎么构建工作流，具体可以参考上一篇文章《DSPy: 用数据驱动的方式优化AI应用》。