DSP

回顾DSPy那篇2022年的奠基性论文——《DEMONSTRATE–SEARCH–PREDICT: Composing retrieval and language models for knowledge-intensive NLP》。作者将DSP的核心拆解为三大模块：Demonstrate（演示）、Search（搜索）和Predict（预测）。虽然听起来有些抽象，但逐一拆解后其实非常直观。

• Demonstrate：演示阶段，需要输入训练集，本质上是Few-shot学习思路；
• Search：从知识库中检索相关信息；
• Predict：基于已有依据生成最终输出结果。

这三个组件与当前主流的RAG流程高度相似。RAG的标准做法是怎样的？输入阶段：

1. 首先将知识库（通常为文件）导入系统；
2. 对文件进行分片或分组，或者让LLM自行生成问答对；
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任务上进行了测试：开放域问答、多跳问答、对话式问答。评估指标使用了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（优化器）。逐一来看。

Signature，可译为“信号”或“暗号”。它指的是直接传入Predict函数的输入值。Signature用于抽象提示词或微调——注意这里的微调是指对工作步骤的微调，而非模型权重的微调。

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

Predict函数是与signature协同工作的核心模块，用于调用LM，它本身也是一种module（下文会详述）。

简单来说，DSPy所做的并非将一堆复杂提示词拼在一起，而是将提示词拆得更细，这样一来每个处理单元的提示词都变得相对简洁。

Module，模块，是signature更高层次的抽象。刚才提到的Predict就是module之一。此外还有ChainOfThought、ProgramOfThought、MultiChainComparison、ReAct等内置模块。

Module还包括：

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

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

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

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

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

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

总的来说，DSPy致力于解决以下几个核心问题：

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

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