別在 AI 交付中迷信「長上下文」：為什麼「精準切片 + 語意路由」才是生產環境的效能底線

在 AI Lab 的實際交付過程中，隨著模型上下文視窗（Context Window）從 128K 擴展到 1M 甚至更多，很多團隊產生了一個危險的錯覺：「既然模型能吃下整本書，我為什麼還要費勁地做複雜的 Chunking（切片）和 RAG 策略？」

這種「全量餵入」的思維在 Demo 階段非常驚豔，但在真正的生產環境（Production）中，它往往是效能崩潰和成本失控的導火線。

「長上下文」的三個工程陷阱

在實際部署一個企業級知識庫助手時，如果你簡單地將所有相關文件全部塞進 Prompt，你會迅速撞上這三堵牆：

1. 「迷失在中間」 (Lost in the Middle)

儘管模型宣稱支援百萬 token，但注意力機制並非均勻分佈。大量實驗證明，模型對 Prompt 開頭和結尾的資訊捕捉最強，而中間部分的資訊極易被忽略。當你把 50 個文件片段全部堆在一起時，關鍵答案如果落在第 25 個片段，模型大概率會告訴你「文件中未提及」。

2. 推論延遲的線性增長

TTFT (Time to First Token) 與輸入長度呈正相關。在低延遲要求的對話場景中，使用者無法忍受因為你塞了 100K 的背景資料而導致的 5-10 秒首字延遲。對於商業應用，回應速度就是轉換率。

3. Token 成本的無謂浪費

在 API 呼叫模式下，每一萬個 token 都是真金白銀。如果一個問題只需要 500 字的精準片段就能回答，而你每次都發送 50K 的上下文，你的營運成本將增加 100 倍。

從「全量餵入」到「語意路由」：工程化路徑

一個成熟的 AI 工程團隊應該建構的是一套「漏斗式」的資訊檢索鏈路，而不是一個簡單的「大桶」。

第一層：語意路由 (Semantic Routing)

不要直接進入向量檢索。先透過一個輕量級的分類器（或 LLM-based Router）判斷使用者的意圖。
- 意圖 A (通用問答) $\rightarrow$ 直接呼叫基礎模型。
- 意圖 B (特定產品手冊) $\rightarrow$ 定向路由至 product_manual 索引空間。
- 意圖 C (即時資料查詢) $\rightarrow$ 呼叫 Tool/API 而非檢索文件。
透過路由，我們可以將檢索範圍瞬間縮小到最相關的子集。

第二層：精準切片與多粒度索引 (Multi-granular Indexing)

放棄單一的固定長度切片（如每段 500 字）。採用「父子索引」 (Parent-Document Retrieval)：
- 子塊 (Child Chunks)：極小粒度（如 100-200 字），用於高精度的向量匹配。
- 父塊 (Parent Chunks)：較大粒度（如 1000 字），當子塊命中後，將整個父塊提供給 LLM 以保證上下文完整性。
這樣既保證了檢索的精度（Precision），又保證了生成的品質（Recall）。

第三層：重排序 (Reranking) 的強制介入

向量檢索（Cosine Similarity）只能找到「看起來像」的內容，不能找到「真正有用」的內容。在 Top-K 片段回傳後，必須引入一個 Cross-Encoder 重排序模型（如 BGE-Reranker）。
將 Top-50 的候選集透過 Reranker 精篩至 Top-5 $\rightarrow$ 這才是餵給 LLM 的最終上下文。

實戰總結：AI Lab 的交付準則

在 AI 工程化中，「少即是多」是一個鐵律。一個高效能的交付方案應該是：
1. 極簡的 Prompt：只包含必要的指令和經過精篩的 Context。
2. 深层的檢索鏈路：路由 $\rightarrow$ 子塊匹配 $\rightarrow$ 父塊還原 $\rightarrow$ 重排序 $\rightarrow$ 生成。
3. 嚴格的 Token Budget：為每個請求設定硬性的上下文上限，強制工程團隊優化檢索品質而非依賴模型視窗大小。

不要讓你的系統變成一個依賴於「運氣」和「超大視窗」的黑盒，要把確定性交給工程鏈路，把創造力交給模型生成。