定位：RAG 到底是什麼
把「檢索」接在「生成」前面，讓模型用外部知識回答——而不是只靠參數裡記得的東西。
RAG（Retrieval-Augmented Generation）是一種系統模式：使用者提問時，先從外部知識庫檢索相關片段，再把這些片段與問題一起組成 prompt，交給 LLM 生成答案。模型不必把公司手冊、最新規章、產品規格全部「背進權重」；它只要在推理當下拿到對的上下文。
RAG 不取代模型，也不等於「再訓練一次」。它把知識更新從「重訓／微調」改成「更新索引」——文件改了，重建或增量寫入向量索引即可，不必動模型權重。
為什麼幾乎每個企業 LLM 應用都會碰到它？因為純參數模型有三個結構性痛點：
RAG 對這三點的共同策略是：把答案所需的事實，從「模型記憶」改為「檢索結果」。模型負責理解問題、組織語言、遵守指令；事實來源則交給可審計、可更新、可權限控管的知識庫。
切塊策略留給 Chunking 篇，混合檢索與 Reranking 留給混合檢索篇，評測指標留給 RAG 評估篇；Agent loop、MCP／A2A、Runtime 分別留給 Agent 編排篇、MCP 篇與 A2A 篇、Agent Runtime 篇。本篇只把「端到端 pipeline 與核心痛點」講清楚。
端到端 Pipeline
離線建庫與線上問答是兩條時間軸；面試時要能完整走一遍切塊 → embedding → 索引 → 檢索 → 組 prompt → 呼叫 LLM。
兩條時間軸唯一的交會點是索引（兩列各出現一次的同一個東西）：離線每份文件寫進去一次，線上每次提問讀出來一次。面試時先講清楚這兩條的觸發時機不同，再談 Top-k，才不會被追問打亂。
- 切塊（Chunking）：把長文切成可嵌入、可檢索的片段；太大則噪音多，太小則失去語境。
- Embedding：用同一套 embedding 模型把 chunk 變成向量。
- 建索引：寫入向量庫（或混合關鍵字索引），附上來源、標題、權限等 metadata。
- 檢索：問題也做 embedding，取 Top-k 相似 chunk（或再加關鍵字／重排，見混合檢索篇）。
- 組 Prompt：系統指令 + 檢索到的上下文 + 使用者問題，組成一次 LLM 呼叫。
- 呼叫 LLM：模型在「給定上下文」下生成；理想情況是引用片段、少發明。
一個最小可用的 prompt 骨架長這樣（示意）：
實務上還會加引用格式、來源 URL、多輪對話歷史——但地基不變：檢索結果是生成的條件輸入，不是可選裝飾。
架構座標：各元件分工
把「文件進系統」到「答案出系統」拆成幾個可替換的積木，方便和 Vector DB、搜尋引擎、LLM Gateway 對上號。
| 元件 | 職責 | 常見落點 | 本手冊相關篇 |
|---|---|---|---|
| Chunker | 決定「一筆知識」的粒度與重疊 | ingest pipeline / ETL | 後續《Chunking 與檢索策略》 |
| Embedder | 語義空間映射；query 與 doc 必須同一模型族 | 模型 API / 自架 embedding 服務 | 與 LLM Serving 線相關 |
| Vector Index | 近似最近鄰（ANN）、過濾 metadata | 專用 Vector DB 或搜尋引擎向量欄 | 《向量資料庫基礎》 |
| Retriever + Prompt | 取 k、排序、塞進 context window | 應用後端 / Orchestration 層 | 本篇；進階見 Hybrid／Rerank |
| LLM | 在約束下生成；不負責「記住公司知識」 | 供應商 API 或自架推論 | LLM Gateway／Inference Serving |
積木可替換：換 Vector DB 不必換 LLM；換 embedding 模型通常要整庫重嵌。
用模型 A 建庫、用模型 B 嵌問題，相似度數字沒有可比意義。換 embedding 模型＝視為新索引，而不是「熱更新一個參數」。
何時用 RAG：與微調、長上下文對照
面試常問「為什麼不 fine-tune？為什麼不把文件全塞進 context？」——用目標差異回答，而不是口號。
| 手段 | 擅長 | 不擅長 | 更新成本 |
|---|---|---|---|
| 純 Prompt / 長 Context | 單次任務、少量文件、原型 | 知識量大、要權限過濾、要引用來源 | 每次請求重送全文；token 貴 |
| RAG | 大量可變知識、私有語料、可引用 | 改變模型「風格／格式習慣」本身 | 更新索引即可；相對便宜 |
| Fine-tune | 語氣、格式、領域用語、特定推理習慣 | 把整庫事實塞進權重當百科 | 重訓／再對齊；慢且貴 |
實務常是組合拳：用 RAG 管事實，用輕量 fine-tune 或 system prompt 管口吻與輸出格式。
檢索錯了、Top-k 塞了矛盾片段、或 prompt 沒要求「依上下文／否則不知道」，模型一樣會編。RAG 把「可引用依據」送進窗口，但檢索品質與提示約束決定上限——這也是 Chunking 篇、混合檢索篇與 RAG 評估篇各自獨立成篇的原因。
選型口訣可以記成三問：
- 知識會不會常改、要不要權限與出處？→ 偏 RAG。
- 要不要改變模型說話方式或固定 JSON schema 遵從度？→ 偏 prompt／fine-tune。
- 單次就能塞完、且很少重複查同一批文件？→ 先試 長上下文，再決定要不要上索引。
互動 · 切塊與 Top-k 如何決定召回
同一個問題、同一份知識庫，只改切塊長度、重疊率、Top-k、分數門檻與 context 上限，看召回與「答案要件有沒有進到窗口」如何改變。
第 2 節講的是 pipeline 的順序，這一節講的是它的參數。下面的知識庫是五份固定的中文文件（退貨政策、換貨作業、會員權益、配送 FAQ、舊促銷公告），其中退貨政策裡有兩個句子是回答問題的必要事實：一句寫期限、一句寫包裝要求，而且兩句相鄰。切塊邊界落在什麼位置，決定了它們是被完整包在某一塊裡、還是被切成兩半——這正是 chunking 最常見的失敗模式。
左圖的縱軸是文件字元位置（五份文件由上往下接續）、橫軸是檢索分數，每個 chunk 是一條橫條：它的高度＝這一塊涵蓋的字元範圍，所以拉高重疊率時相鄰橫條會在縱軸上互相疊住；虛線是分數門檻。最右側兩條粗標記是「答案要件」所在的字元區間——看它是被某一條橫條完整涵蓋，還是剛好騎在兩條的交界上。右圖是同一次檢索的另一面：選中的塊依序堆進 context window，越過上限線的以斜紋畫在外面，代表它被截掉了。分數是以查詢詞權重 × 詞頻 × 由本次切塊算出的 IDF 當作相似度的教學代理，不是真的 embedding 餘弦相似度。
值得停下來看的是重疊率那一格：把它從 0% 拉到 40%，塊數只多幾塊、token 成本幾乎沒變，但原本被邊界切斷的那個要件會突然被某一塊完整包住。這就是 overlap 存在的理由——它不是為了提高分數，而是為了讓「事實不被切在接縫上」。
地基之上：刻意不展開的後續
知道邊界，才不會在面試或設計時把整座冰山塞進一篇「綜合手冊」。
| 主題 | 本篇只點到 | 深入篇會做什麼 |
|---|---|---|
| Chunking / 檢索策略 | 塊太大／太小會傷召回 | 固定長度 vs 語意切塊、overlap、parent-child |
| Hybrid + Reranking | 純向量可能漏關鍵字命中 | BM25＋向量、RRF、cross-encoder 二階段 |
| RAG Evaluation | 「感覺變好」不夠 | 召回／忠實度、離線集、LLM-as-judge |
| Agents / MCP / A2A | RAG 是「讀知識」；Agent 還會「做動作」 | 工具呼叫、多 Agent 委派、Runtime |
把內部文件檢索進 prompt，屬於 RAG。若還要「開單、改庫存、打外部 API」，那是工具／Agent 編排——協定層見 MCP／A2A，不要把兩條線混成一個黑盒。
面試折衷與實務清單
能畫 pipeline、能說痛點、能講清與 fine-tune 的分工，就已經是合格的 RAG 地基答案。
面試常問的不是「唯一正解」，而是你能否說出每個決策點的兩端折衷。下表每一列是一個決策軸：左欄／右欄是該軸上的兩個對立做法（各列含義不同，以儲存格文字為準），最右欄是答題時要主動補上的風險。
| 決策點 | 一端做法 | 另一端做法 | 留意 |
|---|---|---|---|
| Top-k | 小 k：噪音少、省 token | 大 k：召回高、易塞爆窗口 | 無 rerank 時盲目加大 k 常變差 |
| 更新頻率 | 批次重建：簡單一致 | 增量 upsert：新鮮度高 | 刪改文件要同步刪舊向量，避免幽靈依據 |
| 權限 | 檢索前依 ACL 過濾 | 生成後再檢查 | 應在檢索側過濾，避免敏感 chunk 進 prompt |
| 引用 | 強制列出 chunk id／URL | 自由生成 | 要可稽核就強制引用格式 |
（1）一小撮「標準問答＋應命中文件」當回歸集；（2）prompt 寫明「僅依上下文／否則不知道」；（3）索引與來源系統的刪改同步策略。沒有這三樣，RAG 很容易變成「會說話的錯資料管線」。