DSPy

1. 调研缘由

提示词往往随模型、数据和任务一起变化。DSPy 官方将其描述为编程而非手工提示的框架，目标是让 LM 程序可组合、可优化。[S1] 当团队已经有可度量的任务目标，却仍靠人工反复改写提示时，框架试图解决的是迭代过程不可复现、难比较和难迁移的问题。

2. 简介与产品工作流

开发者先用 signatures 和 modules 描述输入、输出与任务，再接入语言模型和评测指标；优化器利用示例或反馈调整程序中的提示、少样本示例或模型选择。[S1][S2] 因此工作流的先后顺序很重要：先定义可审查的输入输出和指标，再准备与线上任务相近的数据，最后才比较优化前后的质量、延迟和成本。

3. 团队与资本背景

DSPy 以公开代码库和文档维护。[S1][S2] 本篇不将研究影响力转化为未经核实的商业结论。使用方应根据自身发布节奏核查版本锁定、依赖兼容性和内部评测资产的保密要求，而不是假设研究型工具天然适合所有生产场景。

4. 技术基础与生态位

它将 LM 调用看成声明式模块，而非固定字符串提示。[S1] 这使它处在 prompt engineering、评测数据和应用编排之间；效果依赖任务指标和代表性数据。它尤其适合目标可量化的分类、抽取、检索增强生成等任务；面对开放式创作或含强人工偏好的体验，指标设计本身可能比优化器更难。

5. 市场与外部信号

文档覆盖 modules、optimizers 和评测相关路径，表明其面向需要系统化迭代的开发与研究工作流。[S1] 对团队而言，最有价值的外部信号是能否把一次实验转成可重复的基线：同一测试集、同一模型版本、同一成本口径下，结果是否能稳定复现。

6. 公开评价与主要分歧

**可取之处：**把优化目标和任务接口显式化，便于重复实验。[S1] **主要分歧：**优化不会替代数据质量；错误的指标可能让程序更擅长“通过测试”而非满足真实需求。还应防范开发集泄漏、只对单一模型调优以及忽略推理成本等问题；这些都会令离线提升无法转化为线上收益。

7. 同类对比

维度	DSPy	手写提示	通用 agent 框架
核心对象	签名、模块与优化器。[S1]	字符串和少样本示例。	工具、状态和执行流。
迭代方式	以数据和指标优化。[S2]	人工修改。	以任务流程为主。
适合场景	可评测的 LM 程序。	小型快速实验。	多步骤工具任务。

8. 信息缺口与后续观察

应在真实数据分布、不同模型和成本约束下比较优化收益，并审查训练／验证泄漏。建议将保留集与线上抽样分开，记录每次优化使用的数据、模型和参数；若更换模型或业务规则，应重新建立基线而非直接沿用旧结论。

9. 归纳洞察 ★

把提示变成程序接口后，优化才有可复现的对象；但“优化什么”仍是人必须负责的产品判断。

10. 来源与更新时间

• 信息截至(as_of): 2026-08-01