別讓「上下文視窗」成為你的工程陷阱：在長文本 RAG 中建立「語意錨點」的實戰經驗

在 AI Lab 的實際交付中，我們經常聽到一個令人興奮的指標：「上下文視窗（Context Window）已經支援 200K 甚至 1M tokens 了」。很多團隊因此產生了一種錯覺：既然能把整本書、整個程式碼庫直接塞進 Prompt，為什麼還需要複雜的 RAG（檢索增強生成）分片和索引？

但現實是，即便模型宣稱支援超長上下文，在生產環境下，你依然會遇到嚴重的「中間遺失」（Lost in the Middle）現象。當關鍵資訊被淹沒在海量無關文本的中間時，模型的召回率會斷崖式下跌。

我們在最近的一個企業級知識庫專案中，透過引入「語意錨點（Semantic Anchors）」機制，解決了長文本輸入下的精度崩塌問題。以下是具體的工程實踐。

1. 陷阱：過度依賴「全量輸入」

很多工程師的習慣是：只要 Token 數沒超限，就盡可能多地提供背景資料。這種做法在 Demo 階段表現良好，但在處理複雜邏輯推理時會出現以下問題：

- **注意力稀釋**：模型在處理 50k tokens 的輸入時，對第 20k-30k token 處的細節關注度最低。

- **雜訊干擾**：無關的冗餘資訊會誘導模型產生幻覺，將不相關的片段強行關聯到答案中。

- **成本與延遲**：輸入 Token 的線性增長直接導致首字延遲（TTFT）增加，且 API 成本激增。

我們不再追求「全量輸入」，而是採用一種「粗篩 $\rightarrow$ 精定位 $\rightarrow$ 錨點增強」的策略。

利用輕量級的 Embedding 模型進行初步檢索，獲取 Top-20 個相關片段。此時不追求絕對精準，而是確保關鍵資訊被包含在內。

這是核心步驟。我們不對檢索到的片段直接拼接，而是為每個片段生成一個唯一的【錨點 ID】和【摘要標籤】。

例如：

`[Anchor_01 | 財務報表-營收部分]: "2023年第三季度總營收為... (具體內容)"`

`[Anchor_02 | 合規條款-資料隱私]: "用戶資料儲存必須符合 GDPR 標準... (具體內容)"`

在 System Prompt 中明確要求模型：**「在回答問題時，必須在引用事實後標註對應的 [Anchor_ID]。」**

這種做法將模型的任務從「在海量文本中尋找答案」轉變為「在已標記的索引中匹配答案」。它強制模型在生成過程中回溯到具體的錨點位置，極大地降低了幻覺率。

為了防止語意在切片處被截斷，我們採用了 $512 \text{ tokens} + 10\%$ 重疊的切片策略。更重要的是，每個片段會攜帶其前一個片段的最後一句摘要作為「上下文橋接」，確保語意連續性。

根據問題的複雜度動態調整輸入規模。如果問題是簡單的事實查詢 $\rightarrow$ 提供 Top-5 片段；如果是綜合分析 $\rightarrow$ 提供 Top-20 片段並啟用錨點機制。

我們建立了一個簡單的驗證腳本：提取模型回答中的 `[Anchor_ID]` $\rightarrow$ 回溯到原始文件 $\rightarrow$ 計算答案與原句的語意相似度。如果相似度低於閾值且模型標註了錨點，則判定為「偽引用」，觸發重新生成或人工審核。

長上下文能力是模型的底層升級，但它不能替代工程上的精細化管理。在 AI Lab 的交付邏輯中，「能塞進去」不代表「能處理好」。透過建構語意錨點和結構化的引用機制，我們可以將 LLM 從一個「機率預測機」引導向一個「可追溯的知識處理器」。

記住：最好的 RAG 不是檢索最準的片段，而是給模型提供一套最清晰的導航地圖。