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（self-ask）生成QA集

3. 将第2步的输出生成向量存储

问答环节

1. 输入问题

2. 在知识库中进行向量检索

3. 提取TopN条向量检索的结果，按相似度排序

4. 将第3步的输出放入上下文，LLM输出回复

LLM在2022-2023那个时间点存在问题包括：

当时LLM可处理的上下文窗口最高为4096tokens，因此需要更加有效的上下文提取方法；

微调一个LLM当时的成本还比较高，无论是自购还是租用显卡资源都不大划算；

LLM的输出效果一般都非常依赖提示词以及上下文的输入；

而DSP的核心理念在于，无论是LM（大语言模型）还是RM（召回模型）都是实际工作流中的基础设施，从领域专家的角度来看，需要有一个能够快速构建有效工作流，成本又不至于过高的解决方案。

这里说到的成本主要是整理训练数据集，不断试错调试提示词（trial-and-error）等工作。

DSP参考PyTorch的实现方式，希望将机器学习的理念用到大模型工作流之上，特别是针对领域专家式的应用。而不是一味地通过调整提示词来调整模型推理效果，重度依赖提示词构建应用会有不少问题我们在实际构建LLM应用时也都曾经遇到过。

比如说提示词的调试有点像是玄学，尽管已有一些不错的提示词框架如ReACT，但很多时候你依然无法确切地知道提示词哪里写得好，哪里写得不好。你可能一方面既希望LLM对任务进行泛化，另一方面又希望LLM能够控制住自己不要胡说八道。因此提示词调试通常来说成本都不低，多少有点碰运气，又或是凭感觉修改。

另一个问题是提示词难以迁移。比如当你基于GPT-4做好一个不错的提示词后，为了批量化或是降低API成本，你希望将其迁移到成本更低的模型时，提示词可能就不适用或是实现效果差距较大。

另外当工作流中步骤不断增多时，提示词 + 多轮对话模式会导致LLM某种自混淆问题，某一个环节的回答突然”跳票“。当然这个问题从目前发展来看，也是当时LLM能力局限所致。

为此，DSP框架的提出是希望降低提示词在工作流中的权重，通过一套高度模块化的程序，用机器学习的方式，让LM自己通过示例数据“学会”怎么写prompt，或者是生成思维链。

论文针对三类知识敏感QA任务：开放领域QA，多跳QA，对话式QA，论文中进行了具体的测评，评估指标为EM和F1。

在自然语言处理（NLP）中，EM 和 F1 是两个常用的评估指标，用于衡量模型的性能，特别是在问答系统和文本分类任务中：

1. Exact Match (EM)：
      - EM 指的是模型生成的答案与参考答案完全一致的比例。这是一个非常严格的指标，因为它要求预测答案在字符级别上与标准答案完全匹配，即使是空格或标点符号的差异也会导致不匹配。

2. F1 Score (F1)：
      - F1 分数是一个更灵活的指标，它是精确率（Precision）和召回率（Recall）的调和平均值。F1 分数考虑了模型预测的准确性和完整性：
        - 精确率是指模型正确预测为正类（即正确答案）的样本占所有预测为正类的样本的比例。
        - 召回率是指模型正确预测为正类（即正确答案）的样本占所有实际正类样本的比例。
      - F1 分数的计算公式是：[ F1 = 2 \times \left(\frac{\text{Precision} \times \text{Recall}}{\text{Precision} + \text{Recall}}\right) ]
      - F1 分数在0到1之间，1表示完美的精确率和召回率，0表示两者都很差。

这两个指标通常一起使用，因为 EM 可能会因为小的差异而忽略正确的答案，而 F1 分数可以提供一个更全面的模型性能视图。在问答任务中，模型需要在给出准确答案的同时，也要尽量覆盖所有相关的信息点，F1 分数能够更好地反映这种平衡。

在分别对三个不同数据集（Open-SQuAD, HotPotQA, QReCC）进行测试的结果来看，DSP程序都取得了较高的分数。

回到DSP与RAG实现方式的对比来看，DSP作者实际上有点省略了对于「整理训练集」这一环节所涉及成本的讨论，但其框架确实不失为以数据驱动的方式来构建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而封装好的工作流/工作流集合，开发者可以使用或自定义module以提供程序的可复用性。

teleprompter直接翻译过来是提词器，实际上是效仿Pytorch原理的优化器（Optimizer），其接收三个输入分别是：程序，训练集，评估函数（metric），输出返回的是优化后的程序。

你可以将teleprompter理解成一个“教师程序”，它可以完成从数据中采样，进行过程中各项优化（包括提示词）的过程。

到此，DSPy就完成了一整套模仿Pytorch机器学习的步骤：

• 收集针对某一场景的有效数据

• 分割训练集与测试集

• 通过定义signature+module+teleprompter进行算法训练

• 运行测试集，观察metric的输出数据是否理想（类似观察拟合度）

• 训练后的算法可导出，直接用于工作流或应用中

总的来说，DSPy期望解决的问题包括：

1. 在不会影响输出效果的前提下，用简洁预定义的模块替代原来复杂的提示词串；

2. 将模块参数化，并且将提示词撰写转化成一个优化器要去完成的工作，因此可以在不同的模型切换时依旧保持输出效果；

3. 这种模块化设计有利于深入探索那些具有优秀性能表现的或符合某个细致评估的复杂工作流。

论文也通过代码来更直观地演示了DSPy是如何构建起一个工作流的，具体可参考上一篇：DSPy: 用数据驱动的方式优化AI应用