企业级大模型上下文窗口管理：架构设计与优化策略

在目前的主流大模型应用场景中，多轮对话基本上成为大模型的基本应用形式，但这里有一个很多人都忽略的问题，那就是上下文窗口管理；注意这里所说的是上下文窗口管理，而不是上下文管理。

为什么要强调上下文窗口管理，原因是因为模型上下文窗口会直接影响到大模型的输入以及系统的稳定性。

首先我们要明确一个前提，对模型本身来说不存在多轮对话，所谓的多轮对话只是从使用者的角度来说；把与模型的每轮对话保存下来，然后下次对话时把之前的对话内容带上，这就是所谓的多轮对话。

而这种行为有一个专业的名词叫——历史记录或者大模型记忆，正是因为大模型本身没有记忆能力，因此才需要把对话内容记录下来。

OK，现在了解了真实的多轮对话之后，我们再来讨论模型上下文窗口问题。

受限于技术原因，所以大模型一次能够处理的数据是有限的，当数据超长时会导致模型的处理性能急速下降，因此才会有一个窗口来限制模型的输入和输出。

这就像你家的门一样，它有长宽高，当一个东西超过了长宽高，那么它就无法进入到门里面，除非你把超长的部分给截掉。

这里我们还要明确一件事，模型上下文窗口是模型本身存在的特性，和多轮对话无关。之所以强调这句话，是因为有部分人认为是因为多轮对话的远呀才导致模型有上下文窗口限制，这是没弄清楚两者之间的关系。

模型的上下文窗口是一个固定值，在模型发布的时候一般会公布其最大上下文窗口的大小值；比如说现在的主流大模型上下文窗口已经达到了128K，甚至更大。

但不管多大的上下文窗口，其总有一个限度，因此在多轮对话中，当对话数达到一定的次数，超长是肯定的；因此怎么解决这个问题呢？

所以，这里我们就需要控制多轮对话的内容长度，防止其超出模型的上下文窗口限制。当然，你也可能会说我用了很长时间的模型，也没遇到过超出上下文窗口限制的问题啊？

原因在于很多模型厂商或系统厂商默认帮你做了截取，把超长的部分直接给丢掉了。

上下文窗口在固定的情况下，我们在使用模型时有下面一个公式：

上下文窗口 >= 输入 + 输出

也就是说在与大模型的一次对话过程中，我们输入给模型的内容+模型输出的内容不能超过模型上下文窗口的大小。

但是在一轮对话过程中，输入是由哪些参数组成的？

在一轮对话中，输入= 系统提示词(system_prompt) + 用户问题(query) + 参考文档(docs) + 历史记录(chat_history)。

其中，系统提示词长度基本上是固定的，用户问题一般也是几个字到最多几百个字，正常情况下应该是几十个字；所以，在输入中，主要不可控的是残酷文档和历史记录的长度。

历史记录是由之前的多轮对话组成，在每轮对话中又包括用户问题和模型回复。

所以说，我们要控制参考文档的数量和长度，以及历史记录的数量和长度，只有这样才能避免我们的上下文窗口超长。

之所以要控制这个长度，窗口大小>=输入+输出，如果输入占了太多，那么输出就会变少，甚至可能会出现输出时话说了一半就没下文了。

那怎么控制参考文档和历史记录的长度呢？

这里有两种方式，一种是控制其数量，不管历史记录和参考文档有多少，我们只去最近的五个或十个，其它的都给丢掉；另一种方式就是，计算总的tokens值，直接根据上下文窗口大小进行截取，也不管是否会丢失语义。

这里作者主要采用第一种方式，虽然说会丢失部分数据，但至少能够保证当前数据的语义是完整的，但也有一定概率出现超长的情况；而第二种方式虽然说能保证绝不超长，但可能会丢失文档的连贯性，这种语义不全的文档还不如不要。

总之，在模型应用中上下文窗口管理是一个很重要的环节不论是RAG，AIGC还是Agent等与模型相关的技术，都无法避免这个问题。