100 萬 Token Context Window 怎麼用：合約、研究資料與 Repo 的實務邊界

合約：可以一次讀，但要問成審閱任務

完整單一合約通常是 100 萬 token context window 的合理場景，因為合約本質上是有章節、條款與定義的長文件；公開資料也把大型文件列為 1M context 可支援的方向。^[6]

真正的風險不是模型讀不到，而是輸出變成一段漂亮但不可查核的摘要。不要只問「這份合約有什麼問題」。更好的方式，是把任務限制在定位、整理、引用與標示風險：

請依條款編號整理付款義務、終止權、責任限制、保密義務與違約效果。每一點都要附上原文片段，並標示需要法律專業確認的地方。

這種提示讓模型先回到條款，而不是直接下結論。對法務、採購或商務談判來說，長上下文應該是初步審閱與整理工具，不是最後的法律判斷。

研究資料：最適合做跨文件對照

研究資料的價值通常不在單篇摘要，而在跨文件整理：哪些結論一致、哪些假設不同、哪裡有數據矛盾、每份研究的限制是什麼。1M context 的優勢，就是讓模型在同一次任務中比較多份文件，而不是把每篇研究分開摘要後再人工拼接。

適合的任務包括：

1. 把多份報告整理成同一張比較表。
2. 找出所有文件共同支持的結論。
3. 標示互相衝突的定義、假設或結果。
4. 抽取每份研究的方法、樣本、限制與未回答問題。
5. 產生下一輪研究問題或訪談大綱。

研究資料特別適合先要求「證據矩陣」：每個結論旁邊列出來源文件、段落位置與原文摘錄。長上下文讓模型更容易同時參考多份材料，但外部分析仍提醒，1M context 並不等於能取代檢索、分段處理與人工查核。^[3]

Repo：不要整包 ZIP，先整理再讓模型讀

程式碼庫是 1M context 最吸引人的場景之一。TestingCatalog 把大型 codebase 與大型文件並列為 1M context 的應用方向；技術分析也提到 GPT-4.1 針對長上下文中的理解與資訊查找進行訓練。^[6][1]

但 repo 的問題是雜訊密度高。模型真正需要的通常不是所有檔案，而是和任務相關的架構、入口點、設定、核心模組與錯誤線索。直接把整包 repo 上傳，常會把上下文空間浪費在無關內容上。

通常應先排除或延後加入：

• node_modules/、vendor/ 等第三方依賴目錄
• 大型 generated files，除非問題正是生成結果
• build artifacts 與暫存輸出
• 二進位檔、圖片、模型權重
• 大量 fixture、snapshot 或測試資料
• 與任務無關的歷史輸出、備份檔與臨時檔

比較穩的輸入順序是：先給目錄樹、README、架構文件與主要設定檔；再加入與任務相關的核心程式碼；最後補上錯誤訊息、重現步驟、測試失敗紀錄或目標行為。這樣比整包丟入更容易讓模型建立正確的程式脈絡。

三個常見誤會

1. 1M context 不是「所有資料都該全丟」

100 萬 token 的上限讓大型文件與 codebase 任務更可行，但它不會自動幫你篩掉雜訊。^[6] 如果資料裡有大量重複、生成內容、依賴、掃描錯字或與任務無關的檔案，模型仍可能把注意力花在低價值材料上。

2. 模型上限不一定等於平台上限

「模型可支援 1M context」不代表每個 API、雲端部署或產品包裝都能在同一條件下使用完整長度。Microsoft Q&A 上有使用者回報，在 Azure OpenAI 使用 gpt-4.1 時，低於 1M tokens 仍遇到 context window exceeded；這比較適合作為部署差異的警訊，而不是所有環境的通用結論。^[4]

3. 長上下文不等於完美檢索

把材料放進上下文，只代表模型有機會參考它，不代表模型一定會穩定找到每個關鍵片段。針對 GPT-4.1 1M context 的批判文章，就把這項能力描述為令人印象深刻、但仍不足以覆蓋所有真實工作場景。^[3]

建議工作流：先清資料，再要求證據

如果你要把合約、研究資料或 repo 放進長上下文，可以用這個順序處理：

1. 先估算 token。 不要只看頁數、檔案數或 MB 大小；不同格式、語言與程式碼的 token 化結果會差很多。
2. 先清資料。 刪掉重複內容、無關附件、生成檔、依賴目錄、掃描雜訊與歷史輸出。
3. 保留結構。 文件要保留標題、頁碼、段落與條款編號；repo 要保留路徑、檔名與目錄樹。
4. 要求先抽證據。 讓模型先列出條款、段落、檔案路徑或程式碼片段，再要求它下結論。
5. 把任務問窄。 不要問「全部看完有什麼問題」；改問「找付款條款衝突」、「比較 8 份研究的結論差異」或「定位這個錯誤可能牽涉的模組」。
6. 高風險結果分段驗證。 合約、財務、醫療、資安與 production code 變更，都不應只依賴一次長上下文輸出。

什麼時候該改用分段或檢索？

如果任務需要反覆更新資料、逐句可追溯引用、跨版本比對，或 repo 大到包含大量無關模組，長上下文不一定是唯一或最佳方法。這時可以把 1M context 當成「整體理解層」，再搭配檢索、分段摘要、測試紀錄或人工 review。這也符合現有分析對 1M context 的提醒：能力很強，但還不是所有真實工作流的完整解法。^[3]

最實際的結論

• 完整單一合約：通常可以。 但要要求條款編號、原文片段與風險分類。
• 一包研究資料：常常可以。 最適合做跨文件比較、共同結論與矛盾點整理。
• 整個 repo：只建議用在整理過的小到中型專案或明確任務。 大型 monorepo、依賴目錄與生成檔很多時，應先篩選或改用檢索流程。
• 即使塞得下，也不要直接相信一次輸出。 1M context 解決的是「能放入更多材料」；是否能穩定找出、引用與判斷，仍需要提示設計、證據抽取、分段驗證與人工覆核。^[3][4]