DSPy 教给我的 AI 工程五要素

Maxime Rivest 是一位从学术出版领域转向开源 AI 工程的实践者。他去年用 DSPy 搭建了一套处理全球学术出版物的分类管道——每周运行约 1 亿次，如果用 ChatGPT 做同样的事需要 $400,000/周**，而基于 vLLM + Llama 8B + Qwen embeddings + DSPy 的方案只花了 **$50/周。他还搭建了一套解析数百万扫描 PDF 的管道，速度提升 10 倍且达到人类水平质量。

这篇文章不是 DSPy 的教程，而是作者从实战中提炼出的 AI 工程五要素框架——无论你用不用 DSPy，这些组件都客观存在，只是你可能在「外包」这些决策给框架提供商。

五要素：从 DSPy 概念到通用工程语言

作者特别强调 Rendering（渲染） 是最被低估的要素。

Rendering：模型怎么「看」你的请求

Rendering 解决的是：你如何把指令和输入呈现给模型，以及如何要求模型呈现输出。

这看似是「格式问题」，实则是直接影响模型推理质量的 inference strategy：

• 结构化输出：XML、JSON、native structured outputs、BAML、CSV……每种格式都是不同的推理策略
• 工具调用：JSON tool calling 是默认方案，但也可以用 Markdown code cells（#!run）或自定义标签（<toolcall>）
• PDF 处理：纯文本 OCR + 图像、仅文本、仅图像、二进制——不同渲染方式效果差异巨大
• 图像输入：直接传图、转 SVG、先描述再传描述、降分辨率、拼贴多图
• 推理过程：<thinking> 标签、代码注释 #REASONING:、分散式思考标签

作者指出，近期 AI 领域的三大进展——推理能力、结构化输出、工具调用——本质上都是 Rendering 层面的突破。

Call Graph：把大任务拆成小调用

将任务分解为多轮 LLM 子调用，并委派给合适的模型，是改变成本、性能、延迟的最有效手段：

• 同一模型多次调用
• 专用 guard 模型做安全/质量检查
• 多模型投票取多数响应
• 多语言/多程序实现同一任务后合并结果
• 混合 AI 调用与传统代码/机器学习

这些组合构成了 Compound AI Systems（复合 AI 系统）。

Inference：面向未来的即插即用

开源和商业模型几乎每天都在发布。你需要让 prompt、rendering、call graph 的工作成果能轻松切换到任意提供商和模型。

最佳实践：定义一个通用请求格式，一次性映射到所有目标提供商和模型，再把响应映射回统一格式供下游解析和评估。

Interface：稳定的对外契约

AI 程序需要被应用调用、需要每天处理数据流。这个接口必须稳定——因为它就是你的真实任务定义。

把它与底层的调优、分解、渲染工作隔离开：先定义系统的 signature（输入输出契约），再在内部折腾细节。

Evals：没有评估就没有改进

但作者提醒：不要过早搭建庞大的评估体系。很多任务连一个明显的样例都跑不通。

建议的迭代路径：

1. 手动评估：交互式观察数据和 trace，检查 rendering、请求、解析是否有 bug
2. 小数据集：足以运行自动 prompt 优化即可
3. 生产数据：上线后收集真实输入输出分布，可能足够支撑微调

结论

AI 工程的五要素始终存在，区别只在于你是主动掌控这些决策，还是被动外包给框架和 circumstances。

DSPy 的价值在于让你能专注深入任何一个要素，而不必同时操心其他——并且能共享社区沉淀的最佳实践。