第 3 章 — 檢索增強生成
LLM Primer V: Building Real-World LLM Applications 章節走讀的第三篇。這一章從頭走過 RAG 管線,並把「在你十個最愛文件上會動的 demo」跟「撐得住真實語料的系統」區分開來。
這一章為什麼存在
基礎模型只知道訓練語料給它看過的東西,別的都不知道。你在做的產品大概率需要模型對訓練語料以外的東西推理 — 內部文件、上週的工單、客戶的訂單歷史、今天早上剛發的政策。檢索增強生成是把那個縫補起來的工程學科:查詢時從 system of record 撈相關材料、把它塞進 prompt、讓模型對著它生成。天真版就是一次嵌入呼叫、一個 top-k 查找。生產版是一條有切塊策略、查詢改寫、混合評分、reranker、還有評估迴圈的管線。第 3 章從頭走一遍,再走過那些把 demo 管線變成部署的技術。
3.1 五段管線與混合檢索
最小的 RAG 管線有五段,而且每一段跟其他段的互動事後看都很明顯。Loader 保留結構 — 標題、章節路徑、時間戳、來源 URL、存取控制標籤 — 因為下游的每一件事都倚賴 loader 留下的東西。切塊沿著文件的自然紋理切,不沿隨便一個 token 數切。Embedder 把 chunk 投影到向量空間,而那個空間的幾何完全由嵌入模型的訓練分布決定。Retriever 找最近鄰。Generator 拿著被檢索到的 context 去被 prompt,而框話語很重要:「只根據下面的 context 回答,否則回『我沒有這個資訊』」是生產 RAG 裡最有效的抑制幻覺樣板,單獨一個都比其他多。純密集檢索抓得到改寫、抓不到準確 ID;詞彙檢索抓得到 ID、抓不到語意;用 Reciprocal Rank Fusion 融合的混合檢索兩邊都拿到,再對融合後的 top-50 過一層 cross-encoder reranker,精準率還能再加十到二十個百分點。
3.2 品質活在切塊,或死在切塊
「每 500 個 token 切一次、重疊 50 個」這種預設值在意外多的一群通用語料上會動,在幾乎每一群專門語料上都會爆。結構化切塊器按 heading 層級走 HTML 或 Markdown,每個葉章節出一個 chunk,前面掛上祖先 heading 的麵包屑。父子切塊器把小的 child chunk 拿去嵌入來提高檢索精準度,但每一個命中在丟給 generator 前先擴到它的父段落,把檢索單位跟 context 單位解耦。語意切塊器沿著句子嵌入序列走,在主題轉折處切。組合起來 — 先結構、再在長章節內用語意 — 這兩個樣板可以應付真實語料裡幾乎每一種來源型別。而每一個 chunk 都帶著豐富的元資料 — 來源、URL、時間戳、標題路徑、語言、可視範圍 — 因為那些欄位就是讓被檢索到的 chunk 對系統其他部分「可歸屬、可過濾、可讀」的原因。
3.3 查詢改寫、多模態、text-to-SQL
使用者的查詢很少是理想的檢索查詢。Multi-query 展開會請模型出幾個改寫,對每一個檢索、再融合。HyDE — Hypothetical Document Embeddings — 請模型編一個像樣的答案,拿那個去嵌入而不是問題本身,理論根據是答案住在嵌入空間跟問題不同的區域。Step-back 提示產出一個較一般的版本、對兩者都檢索,讓模型用那個框架來回答具體案例。分解會把複合問題切成子問題,讓 retriever 一次處理一個。迭代式檢索讓模型自己決定下一步該撈什麼 — 這是 RAG 通往 agent 的橋。RAG 也不只是文字:CLIP 風格的圖文聯合嵌入空間支援多模態檢索,而 text-to-SQL 把資料庫 schema 當成檢索語料,對讀取副本產生帶 timeout 的查詢。一個 router 會根據每次查詢挑對的改寫,而不是一次跑全部。
第 3 章接下來會怎麼走
RAG 只是眾多能力裡的一個。生產級的助手很少靠檢索過活:它要撈客戶最近的訂單、去另一個系統查庫存、摘要結果、問一個澄清問題、還要自己決定什麼時候做哪一件事。那種行為的自然框話是代理式的 — 模型從一組工具挑一個、系統跑選中的工具、結果送回模型、然後迴圈繼續到任務完成。在那個框話下,檢索就是代理能伸手拿的一個工具。第 4 章把包裝變成代理:ReAct 迴圈、把工具 schema 當契約看、以及讓代理能跨回合維持狀態的三層記憶。
下一篇 — 第 4 章:AI 代理與工具呼叫。那個把「無狀態模型」變成「追著目標跑的行動者」的迴圈 — 帶工具、帶記憶、還帶著擋失控的硬邊界。
