上下文工程是一种构建动态系统的学科，旨在为LLM提供完成任务所需的一切。它超越了传统的提示工程，关注模型在生成响应时所知道和感知的一切，包括系统指令、对话历史、检索到的知识等。上下文工程是高级LLM驱动系统的核心能力，能将LLM从简单的聊天机器人转变为强大的自主代理。
译自：Context Engineering: Going Beyond Prompt Engineering and RAG
作者：Janakiram MSV
最初的大语言模型（LLM）开发浪潮主要集中在提示工程上 —— 精心设计正确的问题或指令，以引出期望的答案。LLM 开发者和爱好者们以巧妙的单次提示（one-shot prompts）而自豪，例如“你是一位 X 专家。像 Z 一样做 Y”；因此，“提示工程师”这个术语也越来越受欢迎。然而，随着 LLM 驱动的应用程序变得越来越复杂和更适合生产环境，开发者们意识到，取得良好的结果不仅仅是编写一个巧妙的查询。于是，上下文工程应运而生，这是一种更广泛、更强大的方法，它专注于模型在生成响应时所知道和感知的一切。
本文介绍了上下文工程，解释了它对于 LLM 应用程序开发的重要性，并展示了它与传统提示工程和检索增强生成（RAG）的不同之处。
什么是上下文工程？
上下文工程是一门构建动态系统的学科，该系统为 LLM 提供完成任务所需的一切。要理解这一点，必须认识到 LLM 的“提示”不仅仅是一个单独的文本字符串，而是模型在产生输出之前看到的整个上下文窗口的输入。除了直接的用户问题之外，此上下文还包括多个组件。
上下文工程是一门构建动态系统的学科，该系统为 LLM 提供完成任务所需的一切。
例如，一个精心设计的上下文可能包含一个系统消息，其中包含设置模型角色和规则的指令、用户的查询或命令、到目前为止的对话历史或状态的摘要、AI 已经学习的任何长期记忆或存储的事实、从外部来源检索到的文档或数据，甚至 AI 可以调用的工具或函数的输出。
简而言之，上下文工程将“模型在生成响应之前看到的一切”视为关键输入。
上下文工程涉及组装各种组件，包括基本提示、记忆、来自 RAG 管道的输出、来自工具调用的输出、定义良好且结构化的输出格式以及护栏。虽然护栏可能存在于上下文之外，但将控制 LLM 行为的规则包含在提示中是一种常见的做法。请注意，护栏是上下文工程的可选组件。
至关重要的是，上下文工程将思维模式从仅仅编写提示转变为设计一个系统。你编写的提示仅仅成为该系统的一个子集。同样重要的是如何构建和管理所有支持信息。这包括仔细注意格式设置和管理上下文窗口限制。LLM 对输入有固定的令牌限制，因此上下文工程师必须决定哪些信息最相关，以及如何压缩或截断不太重要的内容。本质上，上下文工程是一种整体方法，涉及每次调用模型时，管理和优化模型的短期“工作记忆”。
上下文工程 vs. 提示工程
上下文工程与开发人员已经熟悉的提示工程技术有何不同？关键区别在于范围。提示工程通常指的是编写有效的提示字符串，例如清晰地表达用户的请求和指令以指导模型。它通常是一次性的，专注于“在某个时刻对模型说什么”。
上下文工程是提示工程的超集。
相比之下，上下文工程关注的是“当你说出它时，模型知道什么——以及它为什么应该关心”。上下文工程不仅调整单个提示的措辞，还考虑整个交互，包括是否应在主要指令之前和之后包含信息、如何合并先前回合的记忆以及如何格式化检索到的事实等因素。提示工程发生在上下文窗口内，而上下文工程确定什么填充该窗口。因此，上下文工程是提示工程的超集。
另一种对比两者的方法是检查它们的结果和持久性。提示工程的思维模式通常会导致反复试验，你调整措辞，运行模型，看看输出是否有所改进，并根据需要重复该过程。对于一个输入，它可能会产生良好的结果，但对于稍微不同的情况，它可能会失败，从而需要进一步调整。
另一方面，上下文工程强调系统化的、可重复的框架。通过设计如何生成和维护上下文，你的目标是在各种输入和场景中实现一致的性能。它更像是一种类似于软件架构的架构方法，而不是编写单个子程序。这对于必须处理边缘情况和各种用户查询而无需每次手动调整提示的应用程序至关重要。
总而言之，提示工程涉及编写准确和精确的指令，以引出 LLM 的预期响应。相比之下，上下文工程是构建整个信息环境，以便模型可以处理它遇到的任何情况。开发人员发现，后者是高级 LLM 驱动系统所需的核心能力。
上下文工程 vs. RAG
检索增强生成，通常称为 RAG，将搜索步骤与大型语言模型相结合，允许在生成之前从外部知识库中获取权威段落并将其注入到提示中。这使模型能够使用最新的事实来回答，而不是仅仅依赖于其冻结的训练数据。该模式首先出现在 2020 年的一篇论文中，现在已成为 微软、谷歌 和 Nvidia 等公司的标准实践，因为它能使响应有根有据，并大大减少幻觉。
RAG 成为上下文工程赖以将响应扎根于事实数据的组件之一。
相比之下，上下文工程是管理模型所看到的一切的更广泛的技巧 —— 系统指令、对话历史、工具输出和任何检索到的文本 —— 并以模型可以使用的任何方式在有限的上下文窗口内安排这些元素。RAG 成为上下文工程赖以将响应扎根于事实数据的组件之一。
RAG 解决了确保语料库超过模型的上下文窗口时获得准确答案的特定问题。然而，其功效仍然依赖于上下文工程来确定哪些片段是相关的、分配多少令牌以及将它们放置在何处，以便用户的问题仍然突出。实验表明，如果检索返回不相关或重复的段落，这些额外的令牌会挤满窗口，将关键提示推出焦点，并允许幻觉在即使使用 RAG 的情况下也会重新出现。
开发人员试图通过过渡到摄取 128,000 个或更多令牌的长上下文模型来绕过检索。然而，基准测试显示，一旦窗口充满低价值文本，就会出现更高的延迟、增加的 GPU 内存使用量和质量下降。RAG 通过仅发送少量排名最高的段落来避免这些成本，尽管它引入了新的基础设施，例如必须维护和调整的向量存储和检索器。一个务实的指导方针是，只要知识库大于或比上下文窗口更具动态性，就选择 RAG，并且仅当独立文档舒适地适合限制时才依赖长上下文。
上下文工程将 LLM 从简单的聊天机器人转变为强大的自主代理背后的智能。
即使在设计简单的 RAG 堆栈时，你也必须决定如何嵌入检索到的段落。定位、格式化和压缩是影响最终准确性的上下文工程选择。
简而言之，RAG 是一种强大的策略，嵌入在更广泛的上下文工程学科中。后者协调检索以及压缩、记忆、放置和格式化，以便在完全正确的时刻提供完全正确的信息。
结论
上下文工程将 LLM 从简单的对话式聊天机器人转变为强大的自主代理背后的智能。通过在有限的上下文窗口中刻意管理系统指令、记忆、检索到的知识、工具输出和护栏，开发人员为代理提供了在各种任务中进行推理、决策和自主行动所需的情境感知。
该学科还强制执行护栏、压缩噪声并平衡令牌预算，确保决策在运行时保持有根有据和高效。在代理工作流程中，一个代理的输出为另一个代理提供信息，一致的上下文设计成为保持意图完整性、减少错误传播并最终提高端到端系统性能、整体可靠性和用户信任的协议。
