用编译模式重构大语言模型工作流的实战思考

提示词工程正在告别玄学艺术阶段，演进为一门成熟的工程学科。过去人们常通过调整形容词或语气词并凭肉眼观察几个样本来调优大模型，寄希望于它能按预期输出。这种试错手段效率低且极不可靠，一旦模型升级或输入分布变化，之前打磨的文本就会失效。

框架的核心在于把提示词从手写文本变成可编译的程序。开发者无须纠结文本措辞，只需定义好输入输出的签名以及优化目标，交由优化器通过少量示例自动迭代出适配目标的表达。业界对这类工具有各种讨论，例如探讨如果它真的那么好为什么有人在用的 Writing 或者是 An essay If DSPy is So Great, Why Isn't Anyone Using It 话题。

这种转变促使开发人员从调音师转型为架构师。实际应用中，逻辑与表达被成功解耦。传统方式下指令和示例总是混杂，而模块能像 Python 函数那样定义：

import dspy
# 定义签名：输入是 question，输出是 answer
qa_signature = dspy.Signature('Question -> Answer')
# 使用 ChainOfThought 模块，此时无需手动写 "Let's think step by step"
predict = dspy.ChainOfThought(qa_signature)

当开发者需要把底层架构从 GPT-4 换成 Claude 3 或 Llama 3 时，不用重新手动测试全部文本，再次运行编译流程即可获取适配的表达。在真实开发中，人们常发现任何足够复杂的 AI 系统都在无意中实现了一个充满临时补丁的 DSPy 简化版，正如人们常说的那样：Any sufficiently complicated AI system contains an ad hoc, informally-specified, bug-ridden implementation of half of DSPy。

与此同时，必须建立起可量化的评估闭环。传统手动调优常常拆东墙补西墙，而基于度量指标并在验证集上运行的模式，能让算法自动挑选更有效的示例。然而在探索过程中，开发者往往要经历多个阶段：从遭遇格式错误返回垃圾数据的阶段，到处理各种失败情况，再到集成检索增强生成的 RAG 环节，以及评估改进效果的困惑期。当尝试切换模型发现原本的代码无法适配时，就会陷入 Why good engineers write bad AI code 的反思。

观察生态层面的数据会发现，目前 LangChain 的月下载量达到 222M，而该框架的月下载量为 7M，这种巨大的鸿沟引发了部分人的怀疑。尽管如此，JetBlue、Databricks、Zoro UK、VMware、Sephora 以及 Replit 等在生产环境落地该技术的企业依然一致反馈了积极成效。这些采用 DSPy 的企业能以极快速度测试新模型，即便原有提示词无法直接平移也能轻松应对。

维护成本同样随之大幅下降。在复杂的检索生成管道中，链条往往极长，任何微调都会引发连锁反应。采用编译模式后，提示词变为编译产物，维护的只是高层逻辑代码，免去了庞大文本库的困扰。当这些条件同时成立时，系统变得更具可维护性，开发者应当顺应这一趋势编写高质量 AI 代码。如果不论面对何种复杂场景，上述架构条件、指标评估体系以及模块化签名全部同时成立时，下一步不应继续编写零散的文本文件，而是应当立即交由优化器执行编译流水线；反之，若未能在验证集上设定好明确的度量指标，或者输入输出签名定义不清晰，那么盲目运行编译流程的步骤将会失效。大规模支撑复杂智能体工作流时，依赖手动调优的模式已无生存空间，全面转向编译模式才是用确定性流程取代不确定猜测的必由之路。