為什麼 AI 有時候會「迷路」？—— RAG 檢索增強生成的工程實踐

一個現實問題

你的 AI 系統在回答問題時，經常引用過時的資料、編造不存在的細節，或者乾脆說「我不確定」。這不是模型能力不足，而是它被要求做一件不可能的事——記住所有資訊，然後準確提取。

現實中的企業資料每天都在變化：產品說明更新了，合規條款改了，員工換了聯絡方式。想讓 AI 即時掌握所有資訊，唯一可靠的方式不是重新訓練模型，而是讓它在回答時即時查詢最新資料。這就是 RAG（檢索增強生成）要解決的核心問題。

RAG 的基本架構：兩步驟

RAG 系統由兩個獨立階段組成：

**第一步：索引建構**

- 從文件庫、資料庫、API 等來源抽取文字

- 將文字切分為適當大小的片段（通常 500-1000 字）

- 將每個片段透過 embedding 模型轉為向量（768 維至 3072 維不等）

- 將向量存入向量資料庫（如 Milvus、Pinecone、Chroma）

**第二步：即時檢索與生成**

- 使用者提問時，先將問題轉為相同維度的向量

- 在向量庫中執行近似最近鄰（ANN）搜尋，找到最相關的幾個片段

- 將原始問題＋檢索到的片段一起發送給 LLM 進行回答

關鍵點：檢索環節和生成環節完全解耦。模型不再需要從訓練資料中回憶事實，而是從當前資料中獲取證據。

工程中的實際挑戰

1. 文件切分策略

直接按固定長度切分會導致語意斷裂。更好的做法是：

- 按段落／標題自然切分

- 對長文件使用層次化切分（文件級→章節級→段落級）

- 保留片段之間的上下文關聯（前一個片段的最後 100 字作為下一個片段的開頭）

2. 檢索品質

不是所有檢索結果都相關。經驗做法：

- 設定檢索閾值，過濾相似度低於某值的片段

- 對檢索結果做重排序（reranking）：用一個小模型評估每個片段與問題的真實相關性

- 調整 top_k（通常 5-15 個片段），避免資訊過載

3. 索引更新延遲

當來源文件變更後，向量庫需要同步更新。對於高頻更新的內容：

- 採用增量更新策略，只更新變更部分的向量

- 或使用批次處理視窗（如每小時批量更新一次）

為什麼 RAG 不是萬靈丹

RAG 可以顯著提升事實準確性，但它有幾個固有局限：

1. **檢索錯誤**：如果向量庫中根本沒有包含答案的片段，系統會返回錯誤或編造內容

2. **上下文限制**：即使檢索到相關片段，LLM 可能無法正確處理多個有衝突的資訊來源

3. **計算開銷**：每次請求都要進行 embedding＋向量搜尋，延遲通常增加 50-500ms

實際配置建議

對於中小規模企業系統（文件量 < 10 萬筆）：

- 使用開源方案：LangChain + Chroma + 任意 LLM

- Embedding 模型：bge-large-zh（中文優化）或 text-embedding-3-small

- 檢索策略：top_k=8 + 簡單閾值過濾

對於大規模系統（文件量 > 50 萬筆）：

- 使用商業向量庫（Pinecone、Weaviate）

- 多層索引策略：粗篩用快速 embedding，精篩用 reranker

- 快取層：對常見查詢做結果快取，減少向量搜尋呼叫

RAG 不是讓 AI 更聰明的魔術，而是讓 AI 更誠實的工程。它承認 AI 的局限性，並用可驗證的證據來彌補。

---

*原文連結：https://www.smallfiredragon.com/science/rag-engineering-practices-20260727*