先把上下文視窗當成預算，而不是容量
長文件問答最常見的誤解，是把模型可接受的最大 token 數視為可以放心填滿的空間。實際上，系統提示、對話紀錄、使用者問題、檢索內容、引用資訊與模型輸出都會競爭同一筆預算。文件塞得越多，不只推論成本與延遲上升，無關段落也可能稀釋關鍵證據，使模型在相似條款、不同版本或重複敘述之間選錯依據。
工程上應先定義每次請求的預算配置：保留多少空間給回答與引用，多少給對話脈絡，剩餘部分才交給文件證據。預算也不應固定套用所有問題。查詢單一條款時，少量精準段落通常優於整份文件；要求跨章比較、時間線整理或多文件歸納時，則需要擴大證據範圍，或將任務拆成多階段處理。
切分的目標是保留可回答的語意單位
固定字數切分容易實作，卻可能把標題與內文、表格與說明、條款與例外拆開。較穩健的做法是先依文件結構切分，再以長度限制做第二層處理。章節、段落、清單、表格列與頁面位置都應盡量保留，並附上文件名稱、版本、章節路徑、日期與權限等中繼資料。這些資訊既能改善檢索，也能讓回答提供可查證的來源。
重疊區段能避免答案落在邊界，但重疊過多會造成索引膨脹，並讓相同內容重複進入提示。若文件具有明確階層，可採父子切分：用較小區塊建立檢索向量，命中後再取回所屬的較大章節。這通常比單純加大所有區塊更能兼顧命中精度與上下文完整性。對表格、程式碼、合約條款等特殊內容，則應設計專用解析方式，而不是強迫它們遵循一般散文的切分規則。
摘要負責壓縮，檢索負責選擇
摘要適合保存全局輪廓，例如文件目的、章節主題、主要實體與時間範圍；它不適合取代需要精確措辭的原文。摘要會省下 token，但也會遺失限定條件、否定句、例外與數值關係。合約、規範、操作程序或技術參數若只使用摘要回答，很容易產生語意正確但細節錯誤的結論。因此，摘要應協助路由與理解，最終答案仍應回到原始段落驗證。
檢索的核心則是從大量內容中選出少量證據。向量相似度適合語意近似，關鍵字搜尋較能處理產品代碼、錯誤訊息、法規編號與專有名詞；實務上常使用混合檢索，再以重新排序模型或規則排除低價值結果。可依問題類型採用不同策略：
- 事實查詢：優先取得含有明確實體與原句的少量區塊，避免不必要的廣泛摘要。
- 跨章比較：先分解比較面向，分別檢索各章證據，再於第二階段整合。
- 整份文件摘要：先產生分段摘要，再合併成高層摘要，同時保留原文引用位置。
- 多輪追問：重寫查詢時保留必要指涉，但不要把全部聊天紀錄無條件送入模型。
- 高風險回答：要求引用原文、標示衝突或證據不足，並避免用摘要補齊缺失資訊。
用可觀測的流程決定取捨
切分大小、候選數量與摘要層級沒有通用最佳值，應以代表性問題集評估。測試資料要涵蓋精確查找、跨段推理、版本衝突、無答案問題、表格內容與權限限制。除了答案是否合理，也要檢查引用是否真正支持結論、必要段落是否被檢索、錯誤發生在解析、召回、排序還是生成階段。若只看最終回答，很難知道應調整模型、索引或提示。
上線後應記錄每次請求的 token 分配、命中區塊、排序結果、引用與延遲，但要避免寫入不必要的敏感原文。當證據超出預算時，可先去除重複區塊，再依相關性與來源可信度裁切；若問題本身需要大範圍推理，則改用查詢分解、分層摘要或多階段生成。成熟的設計不是把最多內容交給模型，而是讓每一段上下文都有明確用途，並讓工程團隊能解釋答案為何成立、又在哪些情況下不應作答。