100 萬 Token Context Window 實戰：合約、研究資料、Repo 可唔可以一次過讀晒？

先講結論：可以用，但要用得醒。 100 萬 token context window 嘅真正好處，係可以將以前要拆開十幾輪處理嘅材料，放入同一次分析：例如一份長合約、一批研究文件，或者一個已經整理過嘅程式碼庫。公開報道指，GPT-4.1 系列三個模型最高可處理 100 萬 context tokens；TestingCatalog 亦提到，大型文件同大型 codebase 係呢類能力嘅應用方向。

不過，100 萬 token 唔等於「有問必準」。技術分析指 GPT-4.1 針對長上下文處理、理解同資訊查找有相關訓練；但亦有分析提醒，1M context 雖然令人印象深刻，仍然未必足夠覆蓋所有真實工作流。 所以實務上最重要唔係問「塞唔塞得晒」，而係問：「資料乾唔乾淨？任務夠唔夠窄？答案可唔可以返去原文核對？」

三種常見材料：邊啲適合一次過讀？

場景	一次放入 1M context 嘅可行性	最適合做咩	咩情況唔好成包照入
單一完整合約	通常係合理候選	條款摘要、付款責任、終止權、責任限制、版本差異	附件太多、OCR 掃描質素差、需要正式法律意見
一批研究資料	好多時可行	跨文件比較、共同結論、矛盾點、證據矩陣	來源質素參差、需要逐句追溯、資料不停更新
整個 repo	要睇大小同清理程度	架構導覽、bug 定位、API 行為追蹤、重構建議	大型 monorepo、依賴目錄、generated files、二進位檔或測試資料太多

呢張表嘅重點係：1M context 令「一次睇到全局」更現實，但唔代表「原封不動成個 ZIP 掟入去」就係最佳做法。尤其係 repo，公開資料確實將大型 codebase 列為長上下文用途，但大型 codebase 唔等於任何未整理嘅專案都適合一次過塞入同一個提示。

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

單一完整合約通常幾適合長上下文，因為合約本身有章節、定義、條款編號同附件結構；公開資料亦將大型文件列為 1M context 可支援嘅方向。

但最大風險唔係模型「睇唔到」，而係佢輸出一段好順口、但你核對唔到嘅摘要。唔好只問：呢份合約有咩問題？可以改成：

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

咁樣做，模型會先回到條款同原文，而唔係一開始就代你下法律結論。對法務、採購或者商務談判嚟講，長上下文應該係初步整理同審閱工具，唔係最後法律意見。

研究資料：最有價值係跨文件對照

研究資料通常唔係差一篇摘要，而係差一個整合視角：邊啲結論一致？邊啲假設唔同？有冇數據互相矛盾？每份研究有咩限制？1M context 嘅優勢，就係可以喺同一次任務入面比較多份文件，而唔使逐篇摘要完再人手拼返埋一齊。

適合嘅任務包括：

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

呢類任務最好要求模型先做「證據矩陣」：每個結論旁邊列明來源文件、段落位置同原文摘錄。長上下文令模型更易同時參考多份材料，但外部分析仍提醒，1M context 唔等於可以完全取代檢索、分段處理同人工查核。

Repo：唔好成個 ZIP 直入，先清倉再分析

程式碼庫係 1M context 最吸引人嘅場景之一。TestingCatalog 將大型 codebase 同大型文件並列為 1M context 嘅應用方向；技術分析亦提到 GPT-4.1 針對長上下文入面嘅理解同資訊查找有訓練。

但 repo 最大問題係雜訊多。模型真正需要嘅，通常唔係所有檔案，而係同任務有關嘅架構、入口點、設定、核心模組同錯誤線索。直接上傳全個專案，好容易將寶貴 context 浪費喺無關內容。

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

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

比較穩陣嘅做法係：先畀目錄樹、README、架構文件同主要設定檔；再加入同任務相關嘅核心程式碼；最後補上錯誤訊息、重現步驟、測試失敗紀錄或者目標行為。咁樣比「全 repo 一次過丟入去」更容易令模型建立正確脈絡。

三個最易中招嘅誤會

1. 1M context 唔代表所有資料都應該全放

100 萬 token 上限令大型文件同 codebase 任務更可行，但模型唔會自動幫你分辨邊啲係垃圾資料、邊啲係關鍵證據。 如果入面有大量重複內容、掃描錯字、依賴目錄或者無關檔案，輸出自然會受影響。

2. 模型上限唔一定等於你個平台上限

「模型支援 1M context」唔代表每個 API、雲端部署或者產品介面都可以喺同一條件下用盡。Microsoft Q&A 有用戶回報，喺 Azure OpenAI 使用 gpt-4.1 時，低於 1M tokens 仍然遇到 context window exceeded；呢點較適合作為部署差異嘅提醒，而唔係所有環境都必然一樣嘅結論。

3. 長上下文唔等於完美搜尋

將材料放入 context，只代表模型有機會參考，唔代表佢一定穩定搵到每個關鍵片段。針對 GPT-4.1 1M context 嘅批判文章，就形容呢項能力雖然 impressive，但仍然不足以解決所有真實使用場景。

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

如果你要用 1M context 處理合約、研究資料或者 repo，可以照呢個順序做：

1. 先估 token。 唔好只睇頁數、檔案數或者 MB；唔同格式、語言同程式碼，token 化結果可以差好遠。
2. 先清資料。 刪走重複內容、無關附件、生成檔、依賴目錄、掃描雜訊同舊輸出。
3. 保留結構。 文件要留標題、頁碼、段落同條款編號；repo 要留路徑、檔名同目錄樹。
4. 先抽證據。 要求模型先列條款、段落、檔案路徑或者程式碼片段，再要求佢摘要、比較或者判斷。
5. 將問題問窄。 唔好問「全部睇完有咩問題」；改問「搵付款條款衝突」、「比較 8 份研究嘅結論差異」或者「定位呢個錯誤可能牽涉邊幾個模組」。
6. 高風險結果要覆核。 合約、財務、醫療、資安同 production code 變更，都唔應該只靠一次長上下文輸出拍板。

幾時應該改用分段或者檢索？

如果資料會不停更新、需要逐句可追溯引用、要做跨版本比對，或者 repo 大到包含大量無關模組，長上下文未必係唯一或者最佳方案。更實際嘅做法，係將 1M context 當成「整體理解層」，再配合檢索、分段摘要、測試紀錄同人工 review。呢個取態亦符合現有分析對 1M context 嘅提醒：能力好強，但仲未係所有真實工作流嘅完整解法。

最實用嘅一句話

• 完整單一合約：通常可以。 但要要求條款編號、原文片段同風險分類。
• 一批研究資料：好多時可以。 最適合做跨文件比較、共同結論同矛盾點整理。
• 整個 repo：只建議用於整理過嘅小至中型專案，或者任務非常明確嘅情況。 大型 monorepo、依賴目錄同生成檔太多時，應該先篩選，或者改用檢索流程。
• 即使塞得入，都唔好一次輸出就全信。 1M context 解決嘅係「可以放入更多材料」；至於能否穩定搵出、引用同判斷，仍然要靠提示設計、證據抽取、分段驗證同人工覆核。