AI和大模型——上下文工程

一、上下文

在前面的相关的文章中已经对上下文进行各种分析说明，包括在CPU和GPU编程以及其它的一些情况下。所谓上下文应该已经有一个清晰的概念。其实理解上下文非常好明白其中的意思，但可能对不少人来说，真正说向别人清晰的表述上下文可能有些复杂。
可以简单的把上下文理解为执行某个具体任务的所有相关环境条件。在不同应用场景中上下文因此就有了不同的描述，如果在大模型的场景下，上下文就是发送给大模型的所有的信息，这个信息不光包括提示词，还有可能有各种资料等。

二、上下文工程

在大模型的上下文中，它必然存在着一个大小的限制，不可能无限制的增长。这就和现实中人的学习一样，再聪明的人，其学习知识和技术的内容总有一个限度。在大模型中，把接受上下文的大小，称之为上下文窗口。那问题就来了，当上下文超过窗口大小时怎么办呢？
在目前的大模型中，一般是通过压缩或丢弃一些信息。压缩还好处理，丢弃谁呢？会不会丢弃一些关键的信息？会不会破坏上下文的完整性和准确性从而导致输出结果的非预期？这就是前面提到过的上下文腐化。一个明显的例子就是长时间的与大模型对话，问同样的问题，得到的结果可能完全不同。
怎么处理这个问题呢？在上下文腐坏里给出技术性的解决方案。在本文中，给出工程性的解决方案，即在有限的上下文窗口中把最相关的内容在恰到好处的时间点上打包进去。即动态的管理大模型的上下文的技术，这就是上下文工程——Context Engineering。

三、提示词工程和上下文工程

在前面的分析中可以看到，其实提示词和提示词工程与上下文和上下文工程是紧密相连的。换句话说，提示词是上下文的一部分，而提示词工程也可以成为上下文工程的一部分。
但可以清楚的明白，这些技术工程，其实和大模型本身并不耦合，所以它可以完全独立于大模型形成一个独立的工程。表现出来就是一系列的程序如Claude Code，Codex，Cursor以及国产Trae等。

四、分析

上下文工程的内容其实通过前面的Harness、Agent等学习已经包含了。现在分析一下，让其能够更清晰的表现出来。对于上下文来说，它一般分为两类：

1. 静态上下文
   静态上下文相对来说容易理解，它包括各种系统定义的提示词如角色定义、格式输入输出以及相关的具体指令；一些已经指定的知识库特别是专业的文档、术语定义、示例等等；输入输出的限制如内容或文档的各种格式（JSON，XML，MD，HTML等等）。
2. 动态上下文
   动态上下文是对当前交互内容的动态实时处理。一般为分三步即数据获取、压缩和打包。数据获取有很多种情况，有用户的输入、错误日志、搜索的数据等等，通过它们组成最原始的相关数据内容。最典型的就是RAG技术，当然它也包括一些对话历史和状态的管理等；压缩其实就是把内容进行压缩,原因就是上面的上下文窗口限制，所以需要通过压缩把内容限制大小塞进上下文窗口中（大多数的所谓技术都是为解决资源不足的问题）。具体方法可以是硬压缩（摘要或剪枝等）或软压缩（分块等）。而它们最终的目的仍然是要把整体处理后的内容发送回大模型获取结果，而各种处理后，数据的相关性可能会有位置或语义的变化。也就是说，而大模型对这些位置和语义关联是非常敏感的，所以需要重新对其进行打包，组成更合适的位置顺序和相关语关联顺序，从而在送入大模型后能够获取更准确的结果。

五、总结

上下文工程的实现，可以对相关的大模型进行具体应用场景的定制并针对具体的场景进行更专业的处理。可以这样说，上下文工程让AI变得更准确、智能和可靠。