--- title: "上下文脈絡（Context）" slug: context language: zh-TW source: https://aiterms.tw/learning/what-is-context updated_at: 2026-06-27 tags: [自然語言處理, 大型語言模型, 生成式AI, Prompt工程, source:arxiv] ipas_term: false type: deep-dive --- # 上下文脈絡 是什麼？ > AI 模型在生成回應或進行預測時，所能參考與記憶的輸入資訊範圍及歷史對話內容。 ## 核心概念 在人工智慧與大型語言模型（LLM）的語境中，「上下文脈絡（Context）」是指模型在處理當前任務、生成回答或進行預測時，所能參考、存取與記憶的輸入資訊集合。如果你將 AI 想像成一位正在參加開卷考試的學生，那麼 Context 就是擺在桌上的考卷題目、考前給予的指示清單，以及過去幾分鐘內學生自己已經寫下的草稿與答案總和。 Context 是決定模型輸出品質的最關鍵要素之一。這是因為現代神經網路（尤其是基於 Transformer 架構的模型）本質上是「無狀態（Stateless）」的函數。它們不像人類的大腦會自然累積長期記憶，每一次對 API 發起請求時，模型都是在一個完全歸零的狀態下醒來。因此，為了讓模型能夠接續先前的對話、理解複雜的背景知識或是遵守特定的行為規範，我們必須在每一次對話時，將所有相關的歷史紀錄與外部資訊打包在一起，這就是建構 Context 的過程。 在技術指標上，Context 的容量通常被稱為「上下文視窗（Context Window）」，其計量單位為 Token（詞元，約等於 0.75 個英文單字或 0.5 個中文字）。上下文視窗的長度決定了模型一次性所能「看見」的資訊廣度。早期的 GPT-2 模型上下文視窗僅有 1024 Tokens，相當於一頁半的 A4 文件；而現今最先進的模型如 Gemini 1.5 Pro，其上下文視窗已經達到驚人的 200 萬甚至更高 Tokens，這相當於能一次載入數十本長篇小說、幾百小時的音訊文字紀錄或是整個中大型專案的軟體程式碼。Context 長度的突破，標誌著 AI 應用從單句問答邁向系統級知識處理的全新紀元。 ## 運作原理 理解 Context 在底層如何運作，必須深入探討 Transformer 架構的幾個核心機制：注意力機制、位置編碼與 KV Cache。 一、 自注意力機制（Self-Attention Mechanism） Transformer 的靈魂在於「注意力機制」。當我們將一段包含上萬個 Token 的 Context 餵給模型時，模型並不是像人類一樣由左至右逐字閱讀。相反地，模型會同時檢視這整段 Context 中的所有 Token，並計算每一個 Token 與其他所有 Token 之間的「關聯權重（Attention Weights）」。例如，在處理句子「銀行今天匯率不錯，我打算去那裡換錢」時，模型透過注意力機制，能夠精確計算出「那裡」這個代名詞與 Context 激發距離較遠的「銀行」有著極高的語義關聯。這種全局的關聯計算，正是模型能理解長篇 Context 的底層邏輯。然而，標準注意力機制的計算複雜度是 Context 長度的平方級（O(N^2)），這意味著當 Context 變長兩倍，運算量會暴增四倍，這也是長期以來限制 Context 長度的主要數學瓶頸。 二、 旋轉位置編碼（Rotary Position Embedding, RoPE） 由於注意力機制本身沒有「順序」的概念（它將所有輸入視為一個無序的集合），模型必須透過「位置編碼」來標記每個 Token 在 Context 中的絕對或相對位置。現代大模型普遍採用 RoPE 技術，這是一種透過複數空間旋轉來優雅表示 Token 相對距離的數學方法。近年來，許多研究人員透過對 RoPE 的頻率進行縮放（如 PI 內插法或 YaRN），成功在不重新從頭訓練模型的情況下，將原本僅支援短 Context 的模型強行擴展至百萬級別的長 Context，這也是為何開源模型上下文長度得以快速躍升的底層原理。 三、 鍵值快取（Key-Value Cache, KV Cache） 在生成文字時，模型是一個字一個字往外吐的（自迴歸生成）。每一次生成新 Token 時，模型都需要重新查看過往的所有 Context。為了避免浪費算力重複計算歷史 Context 的注意力特徵，工程師設計了 KV Cache 機制。KV Cache 會將 Context 中已經處理過的 Token 的 Key 矩陣與 Value 矩陣暫存在顯示卡（GPU）的 VRAM 記憶體中。因此，在實際運作中，Context 的長度不僅受限於算力，更受到 GPU 記憶體容量的嚴格物理限制。這也催生了如 PagedAttention 等動態記憶體管理技術，以期在有限的硬體資源下支撐更龐大的 Context 處理需求。 ## 實際應用 長上下文視窗技術的成熟，徹底解鎖了眾多極具商業價值與革命性的實際應用場景： 首先是檢索增強生成（RAG, Retrieval-Augmented Generation）的深度進化。在短 Context 時代，RAG 系統必須將企業知識庫切割成非常細小的片段（Chunking），精確檢索出 top-k 片段後再送給模型，這容易導致語意斷裂與上下文碎片化。現在，憑藉著超長 Context 的優勢，企業可以直接將整份數百頁的財報、數千頁的法律合約或是完整的 ISO 規範文件一股腦地作為 Context 輸入，讓模型進行全局閱讀與交叉比對，找出隱藏在不同章節間的邏輯矛盾或是潛在風險。 在軟體工程與自動化開發領域，Context 的長度直接決定了 AI 輔助編程工具的威力。透過將整個專案的 Repository（包含架構文件、API 設計、多個關聯原始碼檔案）載入 Context，開發輔助工具（如 GitHub Copilot Enterprise 或是 Cursor IDE）不再只是猜測下一行代碼，而是能夠理解全域變數的傳遞路徑、系統架構的相依性，甚至能夠在理解全局的情況下進行大規模的重構（Refactoring）與架構遷移。 在影視娛樂與多輪長時間互動對話中，Context 讓角色扮演（Role-playing）與虛擬伴侶變得更加真實。AI 能夠在長達數月、數以千計的回合對話中，無縫記住使用者的喜好、過去發生的事件細節、甚至是很久之前設定的虛構世界觀與人物性格設定。這種依賴 Context 維繫的記憶連續性，是打造具有沉浸感的人機互動體驗不可或缺的基石。 最後，在數據分析與時序處理上，長 Context 使得將數以萬計的系統日誌（Log）、金融交易紀錄（Time-series data）直接丟入模型進行異常偵測（Anomaly Detection）與趨勢分析成為可能，大幅降低了傳統機器學習特徵工程（Feature Engineering）的門檻。 ## 常見誤區 關於 Context，業界流傳著許多似是而非的觀念，最普遍的誤區包含以下幾點： 第一大誤區是「上下文長度（Context Window）越大，模型表現一定越好」。許多廠商會將百萬 Context 作為行銷噱頭，但實際上，隨著 Context 中塞入的資訊量增加，模型很容易遭遇「迷失在中間（Lost in the Middle）」效應。研究顯示，現有模型在提取放置於 Context 開頭與結尾的資訊時表現極佳，但對於深埋在 Context 中段的關鍵細節，其檢索成功率會呈現 U 型斷崖式下跌。此外，輸入無關的雜訊 Context 反而會干擾模型的注意力分佈，導致其給出錯誤甚至幻覺的回答。因此，精心挑選與清理 Context 往往比單純無腦塞入所有資料更為重要。 第二個誤區是「把微調（Fine-tuning）與上下文學習（In-Context Learning）的職責搞混」。許多開發者試圖透過微調來讓模型「記住」一本操作手冊的內容，這其實是非常低效且容易失敗的做法。模型權重（Weights）適合用來學習「行為模式、邏輯推理、語言風格與廣泛的通用知識」；而 Context 則適合用來提供「當下需要的精確事實、私人數據與即時更新的動態資訊」。如果你的目的是讓模型根據特定文件回答問題，把它放入 Context 絕對比耗時費力的微調來得精準可靠。 第三個誤區是將「Context 與長期記憶畫上等號」。如前所述，Context 是一種「工作記憶（Working Memory）」，當 API 呼叫結束，這段 Context 在運算層面上就煙消雲散了。如果不搭配外部的向量資料庫（Vector DB）或是記憶管理模組（如 LangChain 的 Memory 元件）來持久化這些紀錄並在下次對話時重新注入，模型是不會自動「記住」你上週跟它說過的話的。 ## 與相關技術的比較 將 Context 置於 AI 技術棧的整體脈絡中進行比較，能幫助我們更精確地選擇架構： Context (In-Context Learning) vs. 微調 (Fine-Tuning)： 這兩者是知識注入的兩大流派。微調就像是讓學生花一個月時間去上補習班，改變大腦的神經網路結構以適應特定的考試題型，過程緩慢、昂貴且難以隨時修改。而將資訊放入 Context 進行 In-Context Learning（如 Few-shot prompting），就像是直接把講義帶進考場，成本極低、可以動態替換內容，且不會改變模型原本的基礎能力。在知識密集型任務中，目前業界的共識是「Context 優先，微調輔助」。 Long Context Models vs. RAG (檢索增強生成)： 隨著支援百萬 Token 的模型問世，有人提出 RAG 即將被淘汰的論調。然而，這是一個嚴重的過度推論。首先，Long Context 的運算成本極高（每次推論都必須計算幾百萬個 Token 的 Attention），這在商業量產服務中是難以承受的。其次，RAG 系統能夠確保精確的溯源（知道資料來自哪個文件段落），並且有效過濾無關雜訊。未來的趨勢是兩者互補：RAG 負責從 10 億 Token 的知識海中過濾出 10 萬 Token 的精華，然後再交由具有強大 Context 整合能力的 Long Context 模型進行深度的推理與綜合分析。 Transformer Context vs. RNN/LSTM 的隱藏狀態 (Hidden States)： 在深度學習早期，處理序列數據主要依賴 RNN（遞歸神經網路）或 LSTM。它們處理 Context 的方式是透過不斷更新一個內部狀態向量（Hidden State），將歷史訊息壓縮起來。這種方式的優點是理論上可以處理無限長度的輸入且記憶體佔用小，缺點是不可避免地會發生嚴重的資訊遺忘（梯度消失問題），且無法進行平行運算。Transformer 徹底拋棄了遞歸結構，將所有 Context 攤平放在一個巨大的注意力矩陣中同時處理，這帶來了前所未有的理解力與平行計算效率，但也帶來了對記憶體空間的巨大需求，這是當前 AI 發展在硬體架構上最核心的博弈之一。 ## 常見問題 ### 當模型的上下文視窗（Context Window）宣稱有一百萬 Tokens，這代表我可以直接把所有資料都丟給它嗎？ 理論上可以，但實務上並不建議這樣做。首先，超長上下文的運算成本極高，會導致回應速度（TTFT）大幅變慢，且 API 計費會呈指數級成長。其次，目前的大型語言模型普遍存在「Lost in the Middle（迷失在中間）」的現象，亦即模型對於放在上下文開頭與結尾的資訊記憶深刻，但往往會忽略或遺漏放在中間段落的關鍵細節。因此，即使模型支援百萬 Tokens，先透過向量檢索（RAG）過濾出最相關的片段再組合成 Context 給模型，依然是兼顧效能與準確率的最佳實務。 ### AI 模型是如何「記住」先前的對話上下文的？它在伺服器端會永久保存我的對話嗎？ 無狀態的 API（如標準的 OpenAI 或 Anthropic API）本身不會「記住」任何對話。每一次你發送新訊息時，開發者的程式或聊天介面都會將「過去的所有歷史對話紀錄」與「最新訊息」重新打包成一個完整的 Context，一次性發送給模型處理。模型是透過 Transformer 架構中的「KV Cache」來計算並暫存這些上下文的特徵矩陣以加速生成。當該次請求完成，伺服器記憶體中的 KV Cache 通常會被清空，除非平台有特別提供 Session 暫存機制（如 Context Caching）。 ### 如果我的專案超過了模型支援的最大上下文長度，我該如何解決？ 當資訊量超出最大 Context 限制時，有幾種常見的工程解法：1. 實作檢索增強生成（RAG）：將大文件切分為多個 Chunk 並建立向量索引，只將與使用者問題最相關的 Chunk 放入 Context。2. 摘要層遞法（Recursive Summarization）：讓模型先對文件的各個章節分別進行重點摘要，然後將摘要內容組合起來作為最終的 Context。3. 使用圖數據庫（Graph Database）：將文件轉換為知識圖譜，透過精確的實體關聯檢索來取代暴力的全文輸入。這些方法都能有效突破 Context 上限，同時保持良好的推理品質。 --- 深度解說頁：https://aiterms.tw/learning/what-is-context 快查頁：https://aiterms.tw/terms/context 最後更新：2026/06/27