“ 模型上下文管理是模型使用的基礎，其直接影響到模型的輸出結果?！?/strong>

在目前的主流大模型應用場景中，多輪對話基本上成為大模型的基本應用形式，但這里有一個很多人都忽略的問題，那就是上下文窗口管理；注意這里所說的是上下文窗口管理，而不是上下文管理。

為什么要強調上下文窗口管理，原因是因為模型上下文窗口會直接影響到大模型的輸入以及系統的穩定性。

模型上下文窗口管理

首先我們要明確一個前提，對模型本身來說不存在多輪對話，所謂的多輪對話只是從使用者的角度來說；把與模型的每輪對話保存下來，然后下次對話時把之前的對話內容帶上，這就是所謂的多輪對話。

而這種行為有一個專業的名詞叫——歷史記錄或者大模型記憶，正是因為大模型本身沒有記憶能力，因此才需要把對話內容記錄下來。

OK，現在了解了真實的多輪對話之后，我們再來討論模型上下文窗口問題。

受限于技術原因，所以大模型一次能夠處理的數據是有限的，當數據超長時會導致模型的處理性能急速下降，因此才會有一個窗口來限制模型的輸入和輸出。

這就像你家的門一樣，它有長寬高，當一個東西超過了長寬高，那么它就無法進入到門里面，除非你把超長的部分給截掉。

這里我們還要明確一件事，模型上下文窗口是模型本身存在的特性，和多輪對話無關。之所以強調這句話，是因為有部分人認為是因為多輪對話的遠呀才導致模型有上下文窗口限制，這是沒弄清楚兩者之間的關系。

模型的上下文窗口是一個固定值，在模型發布的時候一般會公布其最大上下文窗口的大小值；比如說現在的主流大模型上下文窗口已經達到了128K，甚至更大。

但不管多大的上下文窗口，其總有一個限度，因此在多輪對話中，當對話數達到一定的次數，超長是肯定的；因此怎么解決這個問題呢？

所以，這里我們就需要控制多輪對話的內容長度，防止其超出模型的上下文窗口限制。當然，你也可能會說我用了很長時間的模型，也沒遇到過超出上下文窗口限制的問題??？

原因在于很多模型廠商或系統廠商默認幫你做了截取，把超長的部分直接給丟掉了。

上下文窗口在固定的情況下，我們在使用模型時有下面一個公式：

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

也就是說在與大模型的一次對話過程中，我們輸入給模型的內容+模型輸出的內容不能超過模型上下文窗口的大小。

但是在一輪對話過程中，輸入是由哪些參數組成的？

在一輪對話中，輸入= 系統提示詞(system_prompt) + 用戶問題(query) + 參考文檔(docs) + 歷史記錄(chat_history)。

其中，系統提示詞長度基本上是固定的，用戶問題一般也是幾個字到最多幾百個字，正常情況下應該是幾十個字；所以，在輸入中，主要不可控的是殘酷文檔和歷史記錄的長度。

歷史記錄是由之前的多輪對話組成，在每輪對話中又包括用戶問題和模型回復。

所以說，我們要控制參考文檔的數量和長度，以及歷史記錄的數量和長度，只有這樣才能避免我們的上下文窗口超長。

之所以要控制這個長度，窗口大小>=輸入+輸出，如果輸入占了太多，那么輸出就會變少，甚至可能會出現輸出時話說了一半就沒下文了。

那怎么控制參考文檔和歷史記錄的長度呢？

這里有兩種方式，一種是控制其數量，不管歷史記錄和參考文檔有多少，我們只去最近的五個或十個，其它的都給丟掉；另一種方式就是，計算總的tokens值，直接根據上下文窗口大小進行截取，也不管是否會丟失語義。

這里作者主要采用第一種方式，雖然說會丟失部分數據，但至少能夠保證當前數據的語義是完整的，但也有一定概率出現超長的情況；而第二種方式雖然說能保證絕不超長，但可能會丟失文檔的連貫性，這種語義不全的文檔還不如不要。

總之，在模型應用中上下文窗口管理是一個很重要的環節不論是RAG，AIGC還是Agent等與模型相關的技術，都無法避免這個問題。

本文轉載自??AI探索時代?? 作者：DFires