DSPy 上下文工程：构建生产级 LLM 应用的实战指南

上下文工程已成为开发复杂大型语言模型（LLM）应用的关键学科。本文深入探讨了上下文工程的基础概念，解释了其核心工作流并阐明了实际应用。

什么是上下文工程？

上下文工程旨在弥合简单提示与生产就绪型 LLM 应用之间的鸿沟，它被定义为在给定任务中，有效管理和适配信息以适应 LLM 上下文窗口的艺术和科学。它远远超越了基本的提示工程，采取了一种更全面、更系统的方法。

上下文工程的关键特征包括：

整体方法： 突破单一查询提示的局限，将复杂问题分解为多个可管理子问题。
模块化代理： 这些子问题通常由多个 LLM 驱动的代理解决，每个代理都配备了针对其任务的特定上下文。代理的能力和规模可根据任务复杂性而异。
动态上下文： 提供给 LLM 的上下文不限于初始输入；它还包括处理过程中生成的中间标记，例如推理步骤或工具输出。
编排工作流： 代理之间的信息流被精心控制和编排，形成连贯的系统管道。
多样信息源： 代理可以从各种来源访问上下文，包括通过检索增强生成（RAG）访问外部数据库、工具调用（如网络搜索）、记忆系统或少量示例。
可操作智能： 代理旨在根据其推理采取明确定义的行动，从而实现与其环境的动态交互。
系统评估与可观测性： 生产级系统需要使用指标进行持续评估，并监控标记使用、延迟和成本效益。

为什么不将所有内容都传递给 LLM？

尽管现代 LLM 拥有越来越大的上下文窗口，但简单地将所有可用信息喂给它们通常会适得其反。研究表明，过多或不相关的数据可能导致“上下文中毒”或“上下文腐烂”等问题，从而降低模型的理解能力，增加幻觉，并损害性能。这强调了系统性上下文工程方法的必要性，而不仅仅是依赖更大的上下文容量。

为什么选择 DSPy？

DSPy 框架提供了一种声明式方法来构建模块化 LLM 应用，使其成为演示上下文工程原则的优秀工具。DSPy 明确区分了 LLM 模块的输入和输出“契约”与决定信息流的底层逻辑。这种分离简化了开发并提高了鲁棒性，相对于传统的非结构化提示方法具有显著优势。

考虑一个任务，LLM 需要生成一个具有特定结构（铺垫、笑点和完整呈现）、以喜剧演员声音表达并格式化为 JSON 的笑话。在传统的提示设置中，提取特定字段（如笑点）需要手动后处理，如果 LLM 偏离预期格式，则容易失败。这种非结构化提示也使得难以确定系统的精确输入和输出。DSPy 通过实现结构化、可预测的输出来解决这些挑战。

DSPy 的 Signature 机制允许开发者明确定义 LLM 任务的输入、输出及其数据类型，确保结构化和可预测的结果，而无需手动解析或容易出错的字符串操作。像 dspy.Predict 这样的模块随后处理从输入到输出的转换。一个关键优势是 DSPy 内置的自动模式验证，它使用 Pydantic 模型并通过重新提示 LLM 自动尝试纠正格式错误，显著增强了鲁棒性。此外，实现像思维链（LLM 在最终答案之前生成推理步骤）这样的高级技术也得到了简化。通过简单地切换模块类型，可以指示 LLM 用自我生成的推理填充其上下文，从而提高输出质量。

多步交互与代理工作流

DSPy 的架构将 Signatures（系统依赖）与 Modules（控制流）解耦，简化了多步代理工作流的创建。这种模块化促进了复杂 LLM 应用的设计。

顺序处理

上下文工程倡导将大问题分解为更小的子问题。这一原则应用于顺序处理，其中一个整体任务被分配给多个专门的 LLM 代理。例如，在笑话生成中，一个代理可能负责从查询中生成一个笑话想法（铺垫和笑点），而第二个代理则将此想法扩展为完整的笑话呈现。这种模块化设计允许为每个代理配置适当的能力和资源（例如，使用较小的模型进行想法生成，使用更强大的模型进行最终笑话创建），从而优化性能和成本。

迭代细化

迭代细化是另一种强大的模式，它使 LLM 能够反思并改进自己的输出。这涉及一个反馈循环，其中一个充当评论者的“细化”模块对前一个 LLM 的输出提供反馈，然后初始 LLM 使用此反馈迭代地增强其响应。

条件分支与多输出系统

编排控制流是上下文工程的核心。这允许条件分支和多输出系统，其中一个代理可能生成响应的多个变体，然后选择最佳的一个。例如，一个系统可以并行生成多个笑话想法，使用一个“笑话评判”模块来评估并选择最有趣的，然后只将选定的想法扩展为完整的笑话。

工具调用

LLM 应用通常需要与外部系统交互，这种能力由“工具调用”提供。工具可以是任何函数，由其描述和输入数据类型定义。DSPy 通过 dspy.ReAct（推理与行动）等模块促进了这一点。该模块使 LLM 能够推理用户的查询，确定是否需要外部工具（例如，新闻获取功能），生成必要的函数调用和参数，执行工具，然后将结果整合到其最终响应中。LLM 会动态决定是调用更多工具还是在收集到足够信息后结束其过程。这种机制确保代理可以采取明确定义的行动，通过推理和行动的循环与外部资源交互。

高级工具使用 — 草稿本和文件 I/O

除了简单的 API 调用，上下文工程中的高级工具使用包括使 LLM 能够与文件系统交互。这允许代理执行复杂的、多步骤的任务，例如读取、写入和搜索文件，甚至执行终端命令，将它们从被动文本生成器转变为用户环境中的活跃代理。

MCP 服务器

MCP（多能力平台）服务器代表了一种为 LLM 提供专用工具的新兴范式。遵循客户端-服务器架构，LLM 作为客户端从 MCP 服务器请求操作，然后服务器执行任务并返回结果。这种方法对上下文工程尤其有利，因为它允许精确声明系统提示格式、资源访问，甚至受限的数据库交互，从而增强应用程序控制和安全性。

检索增强生成（RAG）

检索增强生成（RAG）是现代 LLM 开发中的一项基础技术，旨在将外部、最新且上下文相关的信息注入 LLM。RAG 管道分两个阶段运行：预处理阶段，数据语料库被准备并存储为可查询格式；推理阶段，用户的查询触发相关文档的检索，然后将这些文档提供给 LLM 以生成响应。这使得 LLM 代理能够从各种来源访问信息，用外部数据补充其内部知识。

良好 RAG 的实用技巧

分块元数据： 为了有效的 RAG，在预处理过程中考虑为每个数据块生成和存储额外的元数据，例如“此分块回答了哪些问题”。此元数据可以提高检索准确性。
查询重写： 直接使用用户的原始查询进行检索可能效率低下，因为措辞多样或缺乏上下文。查询重写技术通过优化查询来解决此问题——纠正语法、用对话历史进行上下文化或添加关键词——以更好地匹配语料库。假设文档嵌入（HYDE）是查询重写的一种特定形式，其中 LLM 生成用户查询的假设答案，然后此假设答案用于检索，这通常对搜索面向答案的数据库有效。
混合搜索和 RRF： 将语义搜索（使用向量嵌入和相似性度量）与基于关键词的搜索（如 BM25）结合通常会产生更好的结果；这种方法称为混合搜索。当采用多种检索策略时，倒数排名融合（RRF）可以有效地将它们的结果组合成一个优化的列表。
多跳检索： 多跳检索涉及将最初检索到的文档传回给 LLM 以生成新的、优化的查询，从而实现后续数据库搜索以获取更深层的信息，尽管会增加延迟。
引用： 从检索到的文档生成响应时，可以提示 LLM 包含对其来源的引用，从而提高透明度并允许模型首先制定利用内容的计划。
记忆： 对于对话式 LLM 应用，管理“记忆”至关重要。记忆系统，如 Mem0，通常结合检索和工具调用机制。LLM 可以动态决定在观察到新数据时存储或修改信息，然后在后续交互中通过 RAG 检索相关记忆以告知其响应。

最佳实践和生产注意事项

除了核心上下文工程技术，在生产中部署 LLM 应用还需要遵循一些最佳实践，尤其是在评估和可观测性方面。

优先设计评估： 优先进行评估设计：在功能开发之前，为成功设定明确的指标。这指导了应用程序的范围和优化。理想情况下，使用客观、可验证的奖励（例如，用于分类的验证数据集）。如果不能，则定义启发式评估函数（例如，RAG 分块的检索计数）。人工标注是另一种选择。作为最后手段，LLM 可以充当评判，比较和排名在不同条件下生成的响应。
几乎所有地方都使用结构化输出： 始终偏爱结构化输出而非自由形式文本。这增强了系统可靠性，简化了调试，并支持鲁棒的验证和重试机制。
为失败而设计： 在提示和模块设计期间预测失败场景。像任何健壮的软件一样，LLM 应用应构建为优雅地处理错误并最大程度地减少意外状态。
监控一切： 全面监控至关重要。DSPy 与 MLflow 的集成，或 Langfuse 和 Logfire 等替代工具，能够跟踪单个提示和响应、标记使用和成本、模块延迟、成功/失败率以及模型随时间的性能。

上下文工程标志着从基本的提示工程向开发复杂、模块化 LLM 应用的重大演变。DSPy 等框架提供了系统应用这些模式所需的工具和抽象。随着 LLM 能力的不断进步，上下文工程将仍然是生产环境中有效利用大型语言模型力量不可或缺的一部分。