DSPy 评测：别只调提示词，把 LLM 应用变成可评测程序

DSPy 解决的是 LLM 应用缺少工程化反馈回路的问题。它让开发者定义输入输出签名、组合模块，并用数据和指标优化流程，而不是永远在 prompt 文档里手工试错。

适合分类、问答、RAG、信息抽取、评估驱动改进等场景。

很多团队的 LLM 应用上线后很难维护，因为 prompt 改动没有评测基线。一个词改了，客服质量、检索摘要、分类准确率可能同时变化。DSPy 的意义在于把这些改动放进可测试的程序结构里。

它不保证模型一定更聪明，但能让团队更清楚地知道“为什么这个版本更好”。

DSPy 采用 MIT 许可，对商业产品友好。需要额外关注的是数据和模型：你用来优化的示例是否有权使用，评测集是否包含敏感信息，模型供应商是否允许对应用途。

许可证清晰不代表合规自动完成，但它减少了代码采用层面的阻力。

非技术负责人可以这样判断 DSPy 是否有价值：拿一个现有 AI 流程，要求团队写出 20 个真实样例和评分标准。如果连什么是“更好输出”都说不清，DSPy 也救不了项目。

如果样例和指标能定义清楚，DSPy 就可能帮助团队从“感觉调参”走向“评测改进”。

给 Codex 的任务应该是：读取 DSPy 文档，选择一个小任务，例如邮件分类或文档问答；创建 20 条样例；实现 baseline；定义评分；再用 DSPy 优化；输出优化前后对比。

不要一上来重写整个 AI 产品。先用一个可评测小任务证明方法有效。

DSPy 的上限是把 LLM pipeline 变成可以持续改进的系统。它尤其适合模型、提示词、检索和输出格式经常变化的团队。

它的短板是前期学习成本和数据准备成本。如果没有评测数据，它就会退化成又一种复杂框架。

为什么 DSPy 不只是 prompt 工具

DSPy 真正改变的是工作方式。普通 prompt 工程常常依赖经验和文档记录，而 DSPy 要求你把任务拆成模块，把输入输出说清楚，把好坏变成可计算指标。这听起来更麻烦，但对长期维护很有价值。

采用建议

如果你的 AI 功能只是一次性 demo，DSPy 可能偏重。如果你正在维护多步骤 RAG、信息抽取、分类或 Agent 判断链路，它值得进入技术评估。先选一个低风险任务做实验，不要把它当成所有 LLM 项目的默认框架。