“ 上下文工程是一种复杂的提示词方法论，其作用是为了解决模型上下文窗口限制所导致的问题。”
最近在优化RAG的增强问题，也就是提示词的封装，包含系统提示词，用户问题，历史记录和召回文档等；然后就发现一个平常没有关注的问题，那就是模型上下文窗口大小以及其带来的问题。
我们都知道模型的上下文窗口是有大小限制的，哪怕随着模型技术的发展其窗口大小也越来越大，但总归有一个限制；而在这个窗口中不但包含了用户问题，还同时包含了历史记录和参考文档；特别是在多轮对话中，随着对话次数的增多，很容易就达到了上下文窗口的限制。
当然，可能很有人会说，我在使用模型的时候聊天好多轮但都没有报超长错误啊；原因是模型厂商默认给你做了上下文裁剪，当上下文超过模型窗口时会默认丢弃之前的对话，这也是大模型“失忆”的原因。
模型上下文窗口
模型上下文窗口限制，这是一个客观存在的事实；但可能很多人到现在都没搞明白这个上下文窗口到底是怎么算的，特别是在多轮对话中，比如说上下文窗口与输入输出之间的关系？
模型上下文窗口因模型不同，其值也不同；但我们要明白一件事，那就是模型上下文窗口是指模型能够处理的最大数据长度，其计量单位是Token，如果不知道什么是token的，自己去查。
因此，模型上下文窗口包含了输入和输出；特别是在多轮对话中的处理最为显著。
举例来说，一个模型的上下文窗口是1000token；你输入用了100token(包含问题，系统提示词，参考文档等）；然后模型回答问题用了两百token，这时模型的上下文窗口就还剩700token；然后在第二轮对话中，假如你的输入还是用了100token，第二轮回答也是用了200token，那么由于历史记录的存在，第二轮对话消耗了多少token?
100 + 200 + 300(第一轮对话的输入和输出100+200)，这时就用了600token，那么再对话一次，在第四次对话的时候，上下文窗口就超限了。这时应该怎么办？
默认情况下会对上下文进行截取，丢掉最开始的第一轮对话内容或者前200个token。
当然，以上内容都是基于多轮对话和有记忆功能存在的前提下，如果是单轮对话或者没有记忆，那么只要单次没有超出模型上下文限制，那么就不会有问题。
由于目前大部分的应用场景都是基于多轮对话，因此基于以上情况就面临一个问题，上下文超长是一个必然的过程；那么，怎么才能让模型更好地输入和输出呢？
这时，提示词工程和上下文工程的作用就体现出来了；在这里我们要明白一个前提，不管模型的上下文限制是多少，对模型来说它接受的最终形式就是一串提示词。
而这就是提示词工程要做的事情，但这里为什么又搞出了一个上下文工程呢？
在大模型应用中，提示词工程一般是指静态的提示词，其作用是为了在单次对话中，尽可能的引导模型，让其表现达到最好；但是，在多轮对话中，提示词最终的来源很复杂，包括用户问题，系统提示词，历史记录和参考问题；特别是历史记录。
上下文工程虽然很多人都认为它是一个新概念，但事实上我们在开发过程中已经在使用它了；比如说在langchain的提示词模板中拼接历史记录和参考文档就属于上下文工程的一部分。
上下文工程可以简单理解为是提示词工程的一种复杂情况，由于历史记录和参考文档的存在；特别是随着多轮对话，历史记录会逐渐增多，这时怎么保证在尽可能不丢失历史记录的前提下，还能保证最终的提示词不会超出上下文窗口，以及使用什么样的提示词结构才能让大模型更好的理解和输出，这就是上下文工程所需要解决的问题。
为了解决这个问题，因此有了历史记录压缩技术，提示词结构设计，参考文档处理等一系列技术问题。
总之，上下文工程的目的是为了解决在模型上下文有限的情况下，尽可能的让模型表现的更好，输出更高质量的回答。
