大模型上下文窗口長度為何很“卷”？一文看懂

最近很多人發現：隨著LLM越來越熱，大模型的上下文窗口的長度也越來越長了。

以openAI為例，僅在今年GPT-4就從一開始的4K、8K拓展到了128k（此為GPT-4-turbo支持的上下文窗口長度）。國內大模型賽道玩家比如百川智能，10月底發布的Baichuan2大模型，上下文窗口長度已突破至192K。

就在上個月，另一家AI公司Anthropic推出Claude2.1，其LLM模型的上下文窗口長度更是達到了200K（其實國內AI服務商如零一萬物、月之暗面等也稱已達到同一長度）。

數據參考自網絡，排名不分先后

眼看大模型可支持的上下文窗口長度越來越長，很多人表示：未來沒有更長，只有更卷。

但上下文窗口長度的突破真這么容易嗎？為什么這么多頭部人工智能企業都在上下文窗口長度這點上“卷”得不亦樂乎？上下文窗口長度技術上的突破能帶來哪些價值？

如果你也好奇，下面我們一起來看看。

大模型上下文窗口長度突破難嗎？

根據對主流LLM廠商采訪的整理，延長大模型上下文窗口長度涉及算力、算法、工程能力等方面，其實整體的實現難度并不低。

比如超長上下文窗口會有更高的算力需求，僅Transformer模型中自注意力機制的計算量，就會隨著上下文長度的增加呈現平方級增長。

眾所周知，算力就意味著高投入，尤其是存儲和訓練這塊。據媒體報道：目前很多的顯存容量和帶寬就還跟不上超長上下文的使用需求。此外，顯存壓力也是實現超長上下文窗口無法忽視的點。

兼顧文本長度和推理速度，對于訓練算法和工程能力是另一大考驗。因為一般情況下，隨著計算量暴漲，會導致用戶等待時間變長，而且反饋速度和效度也會受影響。

為了不影響推理速度，可能嘗試模型降級（如變大模型為小模型），或者功能降維（例如減少計算量、犧牲即時存儲等基礎功能）等方法，但這樣很容易導致模型性能和應用價值大打折扣。

在這樣的情況下，要想保障實現較長的上下文窗口長度，同時保持應有的性能，意味著：硬件配置、算法優化、工程代碼性能等方面，都需要同步強化，這也讓文本長度的升級面臨著較高門檻。

上下文窗口長度為何越來越卷？

雖然有難度，但面對提升對話框容量所能帶來的價值，“卷”依然成了自然而然的選擇。

比如隨著上下文窗口長度的增加，可以提供更豐富的語義信息，有助于減少LLM的出錯率和「幻覺」發生的可能性，用戶使用時，體驗能提升不少。

同時，它能解決很多人在長對話或長文檔推理這類業務上的痛點，也能很好地應用于智庫、調研、科研、教育等這類此前涉足不深的業務場景。

另外，作為大模型的核心技術之一，很多LLM服務商也將「長文本輸入」視為自身底座大模型的差異化競爭力，從而熱心于上下文窗口長度的拓展。

文本長度技術突破能帶來哪些價值？

對于普通人來說，隨著上下文窗口長度的發展，進行長時間對話或處理長文檔資料時，不會因為聊得久而失去上下文記憶，也不會因為“超出文本限制”的提示語而被輕易打斷。

畢竟200K的超長上下文窗口足以滿足普通人甚至海量級別的文本輸入需求（比如200K的超長上下文窗口版本，可以處理約40萬漢字規模）。

處理文本密集型文檔或進行長篇創作時，也能從容地應對，不擔心容量限制而輸入不了，或者出現信息丟失或模型「幻覺」等情況，能進一步提升生成精度和效度。

對于企業來說，搭建內部信息知識庫時，需要處理海量數據集。隨著上下文窗口長度延長，搭配大語言模型單次能完成的容量也能大幅提升。

鑒于這一技術在處理長對話和長文檔中的應用，目前，還有一些AI廠商針對已有大模型推出了超長文本擴展技術，以拓展現有的模型文本長度。

值得注意的是：增加上下文長度并不是提升語言模型性能的唯一條件，就像上面提到的，拓寬容量限制的同時，其實算力、算法、工程實現、模型構架等方面會面臨更多的挑戰。要想確保容量拓展后，依然保持較高的性能和生成質量，配套的軟硬件條件其實都能跟上。

備注：本文原創，首發司普科技，參考澎湃新聞、機器之心等，僅做分享。