Context Window

上下文視窗是什麼，跟前面提到的「記憶」有什麼不同？

上下文視窗指的是模型在單一次生成回應時,能同時處理的文字總量上限,這個上限用「token」（模型處理文字的基本單位，粗略來說一個 token 大約對應零點七五個英文單字）來計算。系統提示、目前這輪對話的所有內容、任何被讀進來的文件、工具的說明文字,全部都會被算進同一個總額度裡,一旦加總超過這個上限,模型就沒辦法一次性看到全部內容,最早期的部分會被排擠出視窗之外。

這跟長期記憶是完全不同層次的東西：長期記憶是「特意設計來跨對話保存資訊」的儲存機制,通常存在資料庫或向量索引裡,需要的時候才被檢索、寫入上下文視窗;上下文視窗本身則單純是「模型這一次生成回應時,眼前擺著多少文字」的容量上限,它不是一種記憶系統,而是模型工作時的「桌面大小」——桌面再大,東西超過桌面範圍的部分,還是會被推到看不見的地方去。

上下文視窗這個限制為什麼會存在，是什麼原因造成的？

核心原因是模型內部的運算機制（自注意力機制,self-attention）在處理文字時,計算成本會隨著輸入長度的增加而快速攀升——模型要判斷每一個字跟其他每一個字之間的關聯性,輸入越長,需要比對的組合數量就越多,運算資源的消耗也隨之上升,這代表上下文視窗不是廠商刻意設下的人為限制,而是計算成本跟硬體能力共同決定的技術邊界。近年上下文視窗的容量之所以能大幅擴張,是因為模型架構跟硬體算力持續進步,讓原本負擔不起的運算成本逐漸變得可行。

另一個推力來自 Agent 場景本身的實際需求：如果 Agent 需要同時讀取一份長文件、記住多輪對話歷史、還要載入多個工具的說明文字才能決定該用哪一個,這些內容全部疊加起來很容易超過早期模型的容量上限,這也是為什麼隨著 Agent 應用越來越依賴同時處理大量輸入,擴大上下文視窗成為業界持續投入的方向之一。

上下文視窗具體怎麼影響 Agent 的實際表現，有哪些需要注意的細節？

第一個重要細節是「廣告容量」跟「有效容量」的落差：廠商公布的上下文視窗數字,代表的是模型技術上能接受的輸入上限,但獨立測試普遍發現,模型在處理接近這個上限的超長輸入時,實際的檢索跟推理品質會出現下降,尤其是被埋在輸入中段、不在開頭也不在結尾的內容,更容易被模型忽略或誤判——這代表「這個模型的視窗有多大」跟「這個模型在視窗被填滿時表現有多好」是兩個需要分開評估的問題,不能只看廠商公布的數字。

第二個重要細節是,對 Agent 場景而言,上下文視窗的消耗速度往往比單純聊天應用快得多——每呼叫一次工具、每讀取一份文件、每次跟其他 Agent 交換訊息,都會持續佔用同一個視窗額度,如果 Agent 需要完成的任務牽涉到連續多個步驟,前面幾輪呼叫的完整紀錄可能會不斷疊加,逼近甚至超過視窗上限;超過之後,系統通常需要透過摘要、捨棄較舊的內容,或是把部分資訊移出視窗改成需要時才檢索的長期記憶,來維持任務能繼續進行下去。第三個細節是輸出上限跟輸入視窗是兩件不同的事：即使模型能一次讀入大量文字,單次生成的回應長度通常另外設有上限,對需要一次產出大量內容（例如修改多個檔案）的編碼類 Agent 任務而言,輸出上限有時反而比輸入視窗更早成為瓶頸,需要拆成多個回合才能完成。

上下文視窗對我有什麼影響，該怎麼在實務上評估與運用？

如果你正在設計或使用一個 Agent 系統,理解上下文視窗的限制能幫助你避免一個常見的誤判：以為「視窗夠大」就等於「什麼都可以一次丟進去,讓模型自己整理」。實務上更務實的做法是,主動幫模型過濾跟排序哪些內容真正需要放進當前的視窗裡——把不常變動、可以整理成摘要的資訊搬到長期記憶裡按需檢索,只把真正跟這一步任務直接相關的內容放進視窗,而不是無條件地把所有能拿到的資料都塞進去,指望模型自己從雜訊裡挑出重點。

另一個實務上值得注意的判斷角度是,比較不同模型或不同方案時,不要只比較廣告出來的視窗容量數字,而要確認這個容量在你實際的使用情境（例如輸入長度多長、關鍵資訊落在輸入的哪個位置）下,實際的檢索品質表現如何——同樣兩個都號稱支援大容量視窗的模型,在你的具體任務上的實際可靠度可能有明顯落差,這個落差通常需要透過針對你自己場景的實測才能真正掌握,不能單純比較規格表上的數字高低。