跳到内容

本文档发布于 2024 年 8 月。自那时以来,DSPy 2.5 和 2.6 版本已发布,DSPy 已显著发展,并且 3.0 版本即将到来!以下内容已高度过时。

路线图草图:DSPy 2.5+

自 DSPy 从 Demonstrate–Search–Predict (DSP) 演变而来已有一年,DSP 的研究最早始于 2022 年 2 月的斯坦福 NLP。感谢 200 位杰出的贡献者,DSPy 已将数万人引入构建模块化语言模型程序并自动优化其提示词和权重的领域。在此期间,DSPy 每月下载量已增长到 160,000 次,GitHub 星标数达到 16,000 个,在许多圈子里成为提示词优化的代名词,并启发了至少六个很酷的新库。

本文档是 DSPy 未来几周和几个月公共路线图的初步草图,我们将致力于 DSPy 2.5 并规划 DSPy 3.0。非常欢迎提出建议和开源贡献:只需针对路线图提交议题或拉取请求即可。

技术目标

DSPy 的核心论点是,要使语言模型有用,我们必须从临时提示词转向编程语言模型的新概念。我们不能仅仅依赖语言模型获得更通用或更具组合性的能力,而是需要使开发者能够迭代地探索他们的问题,并构建模块化软件,为明确范围的任务调用语言模型。我们需要通过模块和优化器来实现这一点,它们将问题分解和系统目标描述的方式与调用或微调语言模型以最大化目标的方式隔离开来。DSPy 的目标一直是为实现这一论点开发(并构建社区和共享基础设施以进行集体开发)抽象、编程模式和优化器。

初步来看,DSPy 当前面向用户的语言包含了解决上述目标的最低限度的适当抽象:声明式签名、定义时运行模块以及可以强大组合的优化器。但要实现我们的目标,我们还需要在几个方面做得更好。即将发布的 DSPy 版本将包含以下目标。

  1. 打磨核心功能。
  2. 开发更准确、成本更低的优化器。
  3. 构建从 DSPy 的机器学习工作流程到部署的端到端教程。
  4. 转向更具交互性的优化与跟踪。

团队与组织

DSPy 在其技术目标、贡献者和受众方面相当独特。虽然 DSPy 从用于构建和优化深度神经网络 (DNN) 的库 PyTorch 中汲取灵感,但存在一个主要区别:PyTorch 在 DNN 成为成熟的机器学习概念之后才被引入,而 DSPy 则致力于建立和推进核心语言模型程序研究:该框架由持续不断的学术研究驱动,研究领域从编程抽象(如最初的 Demonstrate–Search–Predict 概念、DSPy SignaturesLM Assertions)到自然语言处理系统(如 STORMPATHIReRa)再到提示词优化器(如 MIPRO)和强化学习(如 BetterTogether)等诸多相关方向。

这项研究得益于数十位行业贡献者,其中许多人正在使用 DSPy 在生产环境中部署应用,所有这些研究共同构成了一个具体实用的库。正因为如此,DSPy 不仅触及研究生和机器学习工程师,还触及许多非机器学习工程师,从早期采用者软件工程师到探索语言模型新用法的业余爱好者。以下团队在开源社区许多人士的帮助下,正努力实现本路线图中的目标。

项目负责人: Omar Khattab (斯坦福大学 & Databricks)

项目导师: Chris Potts (斯坦福大学), Matei Zaharia (加州大学伯克利分校 & Databricks), Heather Miller (CMU & Two Sigma)

核心库: Arnav Singhvi (Databricks & 斯坦福大学), Herumb Shandilya (斯坦福大学), Hanna Moazam (Databricks), Sri Vardhamanan (Dashworks), Cyrus Nouroozi (Zenbase), Amir Mehr (Zenbase), Kyle Caverly (Modular),特别感谢 Keshav Santhanam (斯坦福大学), Thomas Ahle (Normal Computing), Connor Shorten (Weaviate)

提示词优化: Krista Opsahl-Ong (斯坦福大学), Michael Ryan (斯坦福大学), Josh Purtell (Basis),特别感谢 Eric Zhang (斯坦福大学)

微调与强化学习: Dilara Soylu (斯坦福大学), Isaac Miller (Anyscale), Karel D'Oosterlinck (Ghent),特别感谢 Paridhi Masehswari (斯坦福大学)

程序语言抽象: Shangyin Tan (加州大学伯克利分校), Manish Shetty (加州大学伯克利分校), Peter Zhong (CMU)

应用: Jasper Xian (滑铁卢大学), Saron Samuel (斯坦福大学), Alberto Mancarella (斯坦福大学), Faraz Khoubsirat (滑铁卢大学), Saiful Haq (IIT-B), Ashutosh Sharma (UIUC)

1) 打磨核心功能。

在接下来的一个月里,打磨是主要目标,也可能是对普通用户体验回报率最高的目标。概念上,DSPy 有一个非常小的核心。它不过是 (1) 语言模型, (2) 签名与模块, (3) 优化器, 和 (4) 断言。这些概念及其实现经过过去几年的有机演变。我们现在正在整合所学到的东西,并在内部进行重构,以便对新用户来说,一切都能“开箱即用”,即使他们还不了解所有的技巧和窍门。

更具体地说

  1. 我们希望提高零样本、开箱即用的 DSPy 程序的质量,即那些尚未在自定义数据上编译的程序。
  2. 在可能的情况下,DSPy 应该将较低级别的内部复杂性(如管理语言模型和结构化生成)委托给新兴的较低级别库。如果需要,我们可能会从 DSPy 中分叉出更小的库,作为独立项目来支持基础设施部分。
  3. DSPy 内部应该更加模块化,我们需要提高内部组件之间的兼容性。具体来说,我们需要在 (i) 类型化的多字段约束、(ii) 断言、(iii) 可观测性和实验跟踪、(iv) 成果物部署以及流式和异步等相关问题,以及 (v) 微调和提供开放模型等方面进行更深入、更原生的投入。

关于语言模型

截至 DSPy 2.4 版本,该库大约有 20,000 行代码,另有大约 10,000 行用于测试、示例和文档的代码。其中一些显然是必需的(例如 DSPy 优化器),但另一些之所以存在,仅仅是因为语言模型领域缺乏我们底层所需的构建块。幸运的是,对于语言模型接口,现在存在一个非常强大的库:LiteLLM,一个统一各种语言模型和嵌入提供商接口的库。我们预计通过将大部分工作转移到 LiteLLM,可以减少大约 6000 行支持自定义语言模型和检索模型的代码。

这方面的目标包括改进缓存、语言模型的保存/加载、支持流式和异步语言模型请求。这项工作目前由 Hanna Moazam 和 Sri Vardhamanan 领导,基于 Cyrus Nouroozi、Amir Mehr、Kyle Caverly 等人的基础。

关于签名与模块

传统上,语言模型提供文本输入-文本输出的接口。为了实现模块化编程,DSPy 首次引入了签名(2023 年 1 月以 DSP Templates 的形式),作为构建语言模型交互输入和输出的方式。标准提示词将接口(“语言模型应该做什么?”)与实现(“我们如何告诉它去做?”)混为一谈。DSPy 签名将前者隔离出来,以便我们可以在更大的程序上下文中从数据中推断和学习后者。如今在语言模型领域,“结构化输出”的概念已因约束解码和其他改进而发生巨大变化,并已成为主流。而“结构化输入”的概念在 DSPy 之外尚未成为主流,但同样至关重要。

这方面的目标包括完善 DSPy 中语言模型适配器这一第一类概念的抽象和实现,适配器作为签名和语言模型接口之间的转换器。优化器通过与用户提供的指标和数据交互来调整提示词,而适配器则更关注构建与语言模型的交互,以应对例如 (i) 非纯文本语言模型接口,如聊天 API、结构化输出、函数调用和多模态 API,(ii) 除英语以外的语言或其他形式的更高层次的特化。这在 DSPy 中以各种形式断断续续地进行了探索,但我们已经开始研究解决这一问题的更基础方法,这将为大多数用例带来切实的改进。这项工作目前由 Omar Khattab 领导。

关于微调与服务

2023 年 2 月,DSPy 引入了编译以优化语言模型程序权重这一概念。(要理解这在 AI 时间线上有多久远,这比斯坦福大学的 Alpaca 训练项目开始还要早,也比第一个 GPT-4 发布早了一个月。)自那时起,我们在 2023 年 10 月以及更广泛地在 2024 年 7 月展示了 DSPy 的微调方式可以为小型语言模型带来显著收益,尤其是在与提示词优化结合使用时。

然而,总体而言,大多数 DSPy 用户在实践中探索的是提示词优化而不是权重优化,我们的大多数示例也是如此。造成这种情况的主要原因是基础设施。DSPy 风格的微调不仅仅是训练一个模型:最终,我们需要为程序中的多个不同模块引导训练数据,训练多个模型并处理模型选择,然后将这些模型加载并插入到程序的模块中。在 DSPy 提供的抽象级别上稳健地做到这一点,需要现有外部工具通常不支持的资源管理水平。这方面的主要工作目前由 Dilara Soylu 和 Isaac Miller 领导。

关于优化器与断言

这自然是打磨过程中的一个重要方向。在上述三个方面取得更多进展后,我们将在再次分享更多想法。

2) 开发更准确、成本更低的优化器。

DSPy 的很大一部分研究集中在优化语言模型程序的提示词和权重。2022 年 12 月,我们介绍了 BootstrapFewShot(在 DSP 中称为 Demonstrate)及其几个变体的算法和抽象。2023 年 2 月,我们介绍了后来成为 BootstrapFinetune 的核心版本。2023 年 8 月,我们引入了这两者的新变体。2023 年 12 月,我们将首批几个指令优化器引入 DSPy,即 CA-OPRO 和早期版本的 MIPRO。这些在 2024 年 3 月再次升级。快进到 2024 年 6 月和 7 月,我们发布了用于提示词优化的 MIPROv2 和用于微调语言模型程序权重的 BetterTogether。

我们一直在努力开发一些更强大的优化器。虽然我们目前无法分享关于新优化器研究的内部细节,但我们可以概述其目标。一个 DSPy 优化器可以从三个角度进行描述

  1. 质量:它可以从各种语言模型中提供多少质量?它需要零样本程序达到多高的有效性才能良好工作?
  2. 成本:它需要多少带标签(和不带标签)的输入?它需要多少次程序调用?生成的优化程序在推理时有多昂贵?
  3. 鲁棒性:它对不同的未知数据点或分布的泛化能力如何?它对指标或标签的错误有多敏感?

在接下来的六个月里,我们的目标是在保持其他两个角度不变的情况下,显著改进这三个角度的每一个。具体来说,这里有三个方向。

  • 基准测试:这里的关键前提是基准测试工作。在团队中,Michael Ryan 和 Shangyin Tan 正在领导这些工作。更多信息即将发布。

  • 质量:这里的目标是开发出在代表性任务上平均比 MIPROv2 和 BetterTogether 多提取 20% 性能的优化器,这些优化器在通常条件下工作——例如,从一个不错的零样本程序开始,提供数百个带标签的输入和良好的指标。这方面的各种工作由 Dilara Soylu、Michael Ryan、Josh Purtell、Krista Opsahl-Ong 和 Isaac Miller 领导。

  • 效率:这里的目标是开发出能够匹配 MIPROv2 和 BetterTogether 当前最佳分数,但在 1-2 个挑战下工作的优化器,例如:(i) 仅从 10-20 个带标签的输入开始,(ii) 从一个得分 0% 的弱零样本程序开始,(iii) 训练/验证集与测试集之间存在显著失配,或 (iii) 用户不提供指标,但提供非常少量的输出判断。

3) 构建从 DSPy 的机器学习工作流程到部署的端到端教程。

很好地使用 DSPy 解决新任务就像是使用语言模型进行良好的机器学习,但这很难教。一方面,这是一个迭代过程:你做一些初步选择,这些选择可能是次优的,然后你逐步改进它们。它具有高度探索性:通常没有人知道如何以 DSPy 的方式最好地解决一个问题。另一方面,DSPy 提供了多年构建语言模型系统的许多新兴经验,在这些系统中,设计空间、数据环境以及许多其他因素对于机器学习专家和大量没有机器学习经验的用户来说都是新的。

尽管当前文档以隔离的方式解决了其中的许多问题,但我们学到的一点是,我们应该将教授核心 DSPy 语言(最终非常小)与教授在 DSPy 环境中运作良好的新兴机器学习工作流程区分开来。作为这种自然延伸,我们需要更强调在 DSPy 中明确编码之前和之后的步骤,从数据收集到在实践中提供服务和监控优化后的 DSPy 程序的部署。这项工作刚刚开始,但将在 Omar Khattab、Isaac Miller 和 Herumb Shandilya 的领导下加速推进。

4) 转向更具交互性的优化与跟踪。

目前,DSPy 用户有几种方法来观察和调整优化过程。他们可以研究优化方法(如 inspect_history、内置日志记录和/或优化器返回的元数据)之前、之中和之后的提示词。类似地,他们可以依靠 program.saveprogram.load 手动调整优化后的提示词。或者,他们可以使用许多强大的可观测性集成之一——例如来自 Phoenix Arize、LangWatch 或 Weights & Biases Weave 的集成——来实时观察优化过程(例如,分数、堆栈跟踪、成功和失败的轨迹以及候选提示词)。DSPy 鼓励通过在优化运行中调整程序、数据或指标来进行迭代工程。例如,一些优化器支持“检查点”——例如,如果您使用 BootstrapFewShotWithRandomSearch 优化了 10 次迭代,然后增加到 15 次迭代,前 10 次将从缓存加载。

虽然这些可以实现许多目标,但未来的 DSPy 版本将寻求解决两个限制。

  1. 总的来说,DSPy 的 (i) 可观测性、(ii) 实验跟踪、(iii) 成本管理和 (iii) 程序部署应通过与 MLFlow 等工具集成成为第一类关注点。我们将在接下来的 1-2 个月内分享更多针对 DSPy 2.6 解决此问题的计划。

  2. DSPy 3.0 将引入新的优化器,优先考虑临时、有人参与的反馈。这可能是我们在可预见的未来中,认为在 DSPy 中唯一必要的实质性范式转变。它涉及抽象、UI/HCI 和机器学习等层面的各种研究问题,因此这是一个更长期的目标,我们将在接下来的 3-4 个月内分享更多信息。