理解大型語言模型的上下文視窗：為什麼你的長文件會被截斷

當你將數百頁的 PDF 餵給大型語言模型時，它可能會先同意「我理解了」，隨後給出的答案卻與原文矛盾。這不是模型變笨了——這是上下文視窗（Context Window）的硬性限制。

什麼是上下文視窗

上下文視窗是模型一次能「看到」的 token 總數。它包括：

- 你的輸入（提示詞 + 上傳的文件）

- 模型生成的回覆

- 系統指令

典型的 128K token 視窗約等於 90,000 個中文字元。看起來很多，但一旦超過這個限制，舊資訊就會被丟棄，且無法恢復。

為什麼它會「遺忘」

模型使用滑動視窗機制：每處理一個新的 token，舊 token 會從注意力機制中逐漸淡出。這不是在某個點突然清空，而是逐步降低關注權重。結果就是你發現模型對文件前幾頁的細節提問時，給出了模糊甚至錯誤的回答。

實用的解決方案

1. 分段處理 + 結果彙整

不要一次性上傳整份文件。將內容按章節拆分為多個短提示詞，分別處理，然後人工彙整結果。這在法律和醫療文件處理中最有效。

2. 使用支援檢索的插件

許多平台提供「文件問答」功能，底層使用向量資料庫（Vector DB）進行語意檢索。系統先把你上傳的文件切片並向量化，然後針對你的問題只檢索相關的段落，再餵給模型。這能保持高準確率，同時避免視窗限制。

3. 提問時明確引用位置

與其問「這篇文章說了什麼」，不如問「關於第 3.2 節的內容，作者的主張是什麼」。精確定位可以減少模型從大量無關資訊中搜尋的難度。

4. 壓縮摘要

對超長文件，先用模型生成一個結構化摘要（保留標題、關鍵數據、結論），再基於摘要進行追問。這比直接追問原文的準確率更高。

選型建議

如果你經常處理長文件：

- 查看平台是否支援「文件對話」或「知識庫」模式

- 確認 token 視窗是否真能容納你的文件（注意 token 數 > 字元數）

- 對重要結論，用「分段處理」或「檢索增強」方式驗證

上下文視窗不是參數設定的門檻，而是當前架構的本質限制。了解它的運作方式，才能避免「模型什麼都懂」的錯覺。

---

*本文不涉及具體廠商對比，僅討論技術原理。*