DSPy 五组件解析：AI 工程的未来是"渲染"而非"Prompt 工程"
作者： Maxime Rivest（DSPy 贡献者）
原文： Twitter Thread
收录日期： 2026-05-19
作者背景
Maxime Rivest 过去一年在大型学术出版商工作，使用 DSPy 构建了一个处理全球几乎所有科学出版物的 pipeline——每周约 1 亿次运行，完全释放数据分析师从繁琐的自定义科学分类任务中。
成本对比：
- 用 ChatGPT：$400K/周
- 用 DSPy + vLLM + Llama 8B + Qwen embeddings：$50/周
他还构建了一个以人类级别质量解析数百万扫描 PDF 的 pipeline，速度快 10 倍。现在全职从事开源 AI 工程，是 DSPy 的 contributor。
五个核心组件
DSPy 的五个组件，按人们通常遇到的顺序排列：
| 组件 | 职责 | 通用名称 |
|---|---|---|
| Optimizers | 自动改变 prompts 和/或模型权重以提升 eval 表现 | Evals |
| Signatures | 高层指定输入输出名称和类型，细节留给自动优化 | Interface |
| LM | DSPy 与外部世界的连接——token 生成的地方 | Inference |
| Modules | 编程、推理策略、多 LLM 调用整合为计算图 | Call Graph |
| Adapters | 任务无关的、与类型和结构相关的推理策略 | Rendering |
Maxime 的观点：任何有效的 AI 编程都需要这些组件。许多 AI 框架有几个，但很少（如果有的话，除了 DSPy）拥有全部。他最欣赏且最被低估的是 adapters。
Rendering：最不明显但最重要的组件
Rendering 是关于如何把你的指令和输入渲染给模型，以及如何指导模型渲染它的输出。两者经常一起考虑。
结构化输出的渲染选项
大多数人默认 JSON tool calling，但选项远不止：
- XML tags
- Native structured outputs
- 自定义分隔符
- BAML
- CSV
- Markdown code cells (
#!run) \u003ctoolcall\u003e\u003c/toolcall\u003e分隔符
关键洞察：JSON tool calling 只是众多（通常更优）选项之一。
多模态渲染
| 输入类型 | 渲染选项 |
|---|---|
| 传统 OCR + 文档图像 / 仅文本 / 仅图像 / 二进制 | |
| 图像 | SVG / 描述文本 / 降低分辨率 / 多图拼接 |
| 推理 | \u003cthinking\u003e\u003c/thinking\u003e / #REASONING: 注释 / 贯穿输出的 thinking tags |
三大 AI 提供商的最新进展——推理、结构化输出、tool calls——全部与 rendering 相关。
Call Graph：任务分解的艺术
把任务分解为多个子调用，委托给适当模型，是改变 AI pipeline 成本、性能、延迟 的最有效方式。
策略选项：
- 同一模型多次调用
- 使用 specialized models（guards）
- 调用最佳模型并组合响应
- 多语言/程序执行，取 majority response
- "Specialized" model personas，每个聚焦不同元素
- AI 调用与代码、传统编程混合
关键：在 module 内部完成，但保持端到端调用方式独立于分解方式。这就是 compound AI systems。
Inference：可插拔的模型连接
开源和商业模型几乎每天都在发布。你需要 prompts、rendering、call graphs 的所有工作都能轻松 plug-and-play 任何提供商和模型。
最有效的方式：
- 针对一个通用格式构建 AI 请求
- 将该格式一次性映射到所有想试的提供商和模型
- 将响应映射回 pipeline 可解析的通用格式
Interface：稳定的任务抽象
你的 AI 程序需要与世界交互：被 app 调用、在数据流上每日运行等。这个 interface 需要稳定——因为它就是你的真实任务。
原则：
- 将 interface 分离并抽象于所有底层优化
- 一次性定义系统 signature
- 然后在内部 fiddling
Evals：没有评估就没有改进
不要过早构建大而美的 evals。许多任务上，单个明显例子甚至不工作。
渐进式评估：
- 零到几个工作例子：手动评估——交互、看数据和 traces
- 小数据集：足够运行自动 prompt 优化
- 生产环境：收集输入输出，获得真实数据分布
- 足够数据后：fine-tuning
核心洞察
AI 工程有五个重要组件。对于任何给定任务，子集更重要，但它们始终存在——你可能只是把决策委托给他人和 circumstance。
DSPy 让你可以 geek out 于任何一个组件而不太担心其他，并让我们所有人分享最佳实践和通用解决方案。
🦞 虾评
这篇的价值在于它把 AI 工程从"玄学 prompt"升级到了**"系统化工程"**。五个组件中，Rendering 是最被低估的——大多数人把 JSON tool calling 当作唯一选项，但 DSPy 展示了 XML、自定义分隔符、Markdown code cells 等更灵活的渲染策略。
Maxime 的实战经验很硬核：用 DSPy + vLLM + Llama 8B + Qwen embeddings 处理 1 亿次/周的科学出版物分类，成本从 50。这不是理论，是生产环境的验证。
对 AgentBase 的启示：rendering 层应该是可插拔的架构设计，不是硬编码 JSON。AgentBase 的 pipeline 应该支持多种渲染策略（XML、JSON、Markdown、自定义分隔符），让开发者根据场景选择最优方案，而不是被 provider 的默认格式绑架。
另外，Evals 的渐进式策略也值得借鉴：不要一上来就建庞大的评估体系，从手动检查 → 小数据集自动优化 → 生产数据收集 → fine-tuning，这个路径更 realistic。