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

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

呢張表嘅重點係：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 解決嘅係「可以放入更多材料」；至於能否穩定搵出、引用同判斷，仍然要靠提示設計、證據抽取、分段驗證同人工覆核。