在大模型技术日新月异的今天，我们不再仅仅满足于撰写巧妙的提示工程 (Prompt Engineering)。更重要的是，我们需要构建一个围绕人工智能模型的完整环境，使其能够可靠且大规模地工作。这就是上下文工程 (Context Engineering) 的核心概念。本文将深入探讨什么是上下文工程，为何它至关重要，以及如何将其应用于实际场景中，并最终指出它在大模型应用中的关键地位，甚至超越了提示工程。
什么是上下文工程？它与提示工程的区别？
提示工程专注于精心设计向模型提出的问题或指令，就像一位优秀的提问者，力求问出精准且有价值的问题。然而，仅仅拥有好的问题是不够的。上下文工程更进一步，它关注的是在提出问题之前，模型已经“知道”什么——包括记忆、数据、工具、对话历史、系统消息，甚至是环境元数据。简单来说，提示工程是“问”，而上下文工程是“准备”。
想象一下一个客户支持场景。一个客户在使用某电商平台的购物券时遇到了问题，前来咨询。如果我们只依赖提示工程，简单地问模型“客户的购物券为什么无法使用？”，模型很可能给出泛泛的答案，例如“可能是因为购物券已过期”、“可能是因为订单金额未达到使用条件”等等。但是，如果结合上下文工程，我们可以让模型提前“了解”客户的个人资料（会员等级、已领取的优惠券、历史订单）、过去的客服记录、产品的详细信息以及当前活动的规则，那么模型就能更准确地判断出问题的根源，例如“客户的购物券只能用于购买特定商品”，并给出更有效的解决方案。
因此，上下文工程就像舞台搭建，为人工智能模型提供执行任务所需的必要道具——文档、摘要、历史信息、API访问权限、工具定义等，并以正确的顺序和格式进行组织，确保模型能够理解并有效利用这些信息。
上下文工程的重要性：解决幻觉与提高可靠性
大型语言模型 (LLM) 依赖于输入tokens 进行工作。它们本身并不“知道”超出上下文窗口之外的任何信息。这意味着，如果缺乏足够的上下文，模型就很容易产生幻觉 (Hallucinations)，给出不相关的或错误的回应。
虽然简单的提示调整可能在演示环境中表现良好，但在实际生产环境中，当上下文发生变化时，这些调整往往会失效。例如，一个用于生成产品描述的模型，在训练数据中只包含了少量特定类型的产品信息。当用户要求生成其他类型的产品描述时，模型可能会因为缺乏足够的上下文而生成不准确或不完整的内容。
上下文工程的核心价值在于它能够处理动态需求。它可以根据实时的用户交互或任务进展，定制模型可以访问的数据和工具。例如，在一个医疗诊断应用中，上下文工程可以根据患者的症状、病史和检查结果，为模型提供相应的医学文献和诊断工具，从而帮助医生做出更准确的判断。
在金融领域，风险评估模型的准确性至关重要。通过上下文工程，模型可以访问实时的市场数据、客户的交易历史、信用评分以及相关的法规政策，从而更全面地评估风险。反之，如果缺乏这些关键信息，模型可能会做出错误的风险评估，导致严重的经济损失。
上下文工程的关键实践：五个核心步骤
成功实施上下文工程需要遵循一系列关键实践，以确保模型能够有效地利用上下文信息并产生可靠的结果。
-
精选 (Curate): 仔细选择相关的文档、日志、记忆或API。这一步至关重要，因为不相关的上下文信息不仅会浪费计算资源，还可能干扰模型的判断。例如，在开发一个法律咨询机器人时，我们需要精选相关的法律条文、判例和行业规范，而不是将所有法律文献都一股脑地塞给模型。
-
结构化 (Structure): 在用户提示之前，分层构建系统消息、历史记录和工具模式。清晰的结构有助于模型理解信息的层级关系和不同来源，从而更好地利用上下文信息。例如，我们可以先提供系统消息，明确模型的角色和任务目标，然后提供对话历史，帮助模型理解用户的意图，最后提供工具模式，指导模型如何使用外部工具。
-
压缩 (Compress): 总结或分块信息，以在不丢失意义的情况下适应token限制。大型语言模型的输入长度有限制，因此我们需要对上下文信息进行压缩，以确保模型能够处理尽可能多的信息。例如，我们可以使用摘要算法将冗长的文档压缩成简短的摘要，或者将大型文档分成多个小块，分别输入模型进行处理。
-
动态更新 (Update dynamically): 上下文是不断演变的。考虑记忆、检索到的数据和工具输出。随着用户与模型的交互，上下文信息会不断变化，例如用户的提问、模型的回答、工具的输出等等。因此，我们需要动态更新上下文信息，以确保模型始终能够访问最新的信息。例如，在一个客户支持应用中，我们需要实时更新客户的咨询历史、产品的状态以及最新的活动信息。
-
监控和优化 (Monitor and refine): 监控“上下文稀释”现象，确保相关信息始终保持优先地位。随着上下文信息的增加，模型可能会难以区分哪些信息是重要的，哪些信息是不重要的，从而导致“上下文稀释”现象。因此，我们需要监控模型的表现，并不断优化上下文信息的选择和组织，以确保相关信息始终保持优先地位。例如，我们可以使用注意力机制，让模型更加关注重要的上下文信息。
上下文工程的类比：优秀的图书管理员
如果说提示工程是提出一个好的问题，那么上下文工程就像扮演图书管理员的角色——不仅要精心设计问题，还要储备正确的书籍、摘要、工具和历史记录，以便人工智能能够真正回答这个问题。一个好的图书管理员不会仅仅知道问题的答案，更重要的是，他知道在哪里找到答案，并且能够帮助读者快速找到所需的资料。
实际案例：客户支持中的上下文工程
在客户支持场景中，上下文工程意味着实时决定模型可以看到哪些信息——客户的个人资料、过去的工单、产品手册、当前聊天记录——以便其能够准确回复。仅仅依靠提示工程是远远不够的。例如，当一个客户询问关于订单退款的问题时，模型需要访问客户的订单信息、退款政策以及客服历史记录，才能给出准确的答复。如果仅仅问模型“如何处理客户的退款请求？”，模型可能会给出一些通用的建议，例如“请客户提供订单号”、“请客户说明退款原因”等等，但这些信息可能客户已经提供了，因此模型并没有真正解决问题。
对上下文工程的质疑与反驳
一些人认为，高级LLM最终将能够自我优化提示，从而使手动工程变得过时。但即使模型能够自我优化提示，它仍然需要正确的上下文才能理解任何事物。上下文工程解决的是系统层面的问题，而不仅仅是文字表达上的问题。
想象一下，即使一个拥有超强学习能力的学生，如果缺乏必要的教材和学习资源，他也无法取得好的成绩。同样，即使一个拥有强大推理能力的模型，如果缺乏必要的上下文信息，也无法做出准确的判断。
总结：上下文工程是未来的基石
目标：构建能够自动在正确的时间向模型提供正确上下文的系统。
原因：对于扩展、可靠性和防止幻觉至关重要。
方法：精选、结构化、压缩、更新、监控。
如果您正在构建任何基于LLM的工具，而不仅仅是一次性演示、助手、代理、企业应用程序——那么上下文工程就是骨干。提示调整会有所帮助，这是肯定的。但如果没有上下文工程，您将一直在与幻觉和不可预测的结果作斗争。上下文工程已经超越了提示工程，成为大模型技术应用的关键。
未来，随着大模型技术的不断发展，上下文工程的重要性将日益凸显。我们相信，只有通过不断完善上下文工程，才能真正释放大模型的潜力，并将其应用于各种实际场景中，为人类带来更大的价值。