昨天談機制可解釋性,我們往模型內部鑽,想看清權重與神經元如何組成一個念頭;今天把視線拉回外面——一個再聰明的模型,腦中的知識也停在訓練截止那一刻,問它上週的財報、公司內部的規章、剛更新的 API,它只能靠記憶硬掰,於是幻覺。檢索增強生成(RAG, Retrieval-Augmented Generation)就是替這顆封閉的腦袋接上一條外部知識管線:先去資料庫撈出相關段落,再把段落連同問題一起餵給模型,讓它「看著資料回答」而不是「憑印象回答」。這不是新玩意,Lewis 等人在 2020 年就提出,但到了 2026,它已經是幾乎每個企業級 LLM 應用的地基。
📖 學
為什麼需要 RAG:參數記憶的三個破口
LLM 把知識壓進權重裡,這叫參數記憶(parametric memory)。它有三個先天破口:一是過時,訓練完就凍結,世界卻繼續走;二是幻覺,模型傾向給出流暢但未必正確的答案,尤其在冷門事實上;三是不可溯源,你無法要它指出「這句話出自哪份文件」。RAG 的核心主張很樸素:把一部分知識搬到模型外面的非參數記憶(non-parametric memory)——一個可以隨時更新、可以引用出處的外部索引。回答時臨場檢索,模型負責「理解與組織」,資料庫負責「提供事實」。這正好接得上前幾天談的 context engineering:RAG 本質上就是一套「動態、按需組裝上下文」的工程手段。
一條 RAG 管線的五個環節
把 RAG 拆開,是一條有明確工序的流水線。
第一步,切塊(chunking)。 你不可能把整份 300 頁的手冊塞進模型,得先切成小段。切多大是門手藝:太大,一塊裡混了多個主題,檢索精度下降、也浪費 context;太小,語意被切斷,一句話的上下文散在兩塊裡。常見起手式是每塊約 200 到 500 個 token,並讓相鄰塊重疊(overlap)10% 到 20%,避免把一個完整概念從中間劈開。更講究的做法會依語意邊界切(段落、標題、句子),而不是機械地按字數切。
第二步,嵌入(embeddings)。 每一塊文字丟進一個嵌入模型,轉成一串固定長度的浮點數向量,常見是 768、1024 或 1536 維。這個向量是文字的「語意座標」:意思相近的句子,座標也相近。「怎麼重設密碼」和「忘記登入密碼怎麼辦」用詞不同,但向量距離很近——這就是語意搜尋能超越關鍵字比對的地方。
第三步,存進向量資料庫(vector database)。 幾萬、幾百萬個向量要能被毫秒級檢索,靠的是近似最近鄰(ANN, Approximate Nearest Neighbor)索引,例如 HNSW 這類演算法。查詢時把使用者的問題也嵌入成向量,再到庫裡找「距離最近的 k 個」,距離通常用餘弦相似度(cosine similarity)衡量。
第四步,檢索與重排(retrieval & reranking)。 第一輪檢索求快,通常撈回較寬的候選,例如 top-20;但「向量相近」不完全等於「真的相關」。於是加一道重排:用一個較重、較準的 cross-encoder 模型,把問題和每個候選段落成對一起讀,重新打分,只留最相關的 top-3 到 top-5 進 context。這一步常常是準確率提升最明顯的地方,而成本只加在那 20 個候選上,不會拖垮全庫。
第五步,生成(generation)。 把篩選後的段落連同原始問題,組成一段提示詞交給 LLM,並明確要求「僅根據提供的資料作答,並標註出處」。模型輸出答案,理想上每句都能追溯到某個 chunk。
Hybrid search:語意不是萬能
純語意檢索有個盲點:遇到精確字串——產品型號 X-42B、錯誤碼 ERR_507、人名、法條編號——語意向量反而模糊,因為這些詞沒什麼「意思」可言,它們就是要逐字命中。這時傳統的關鍵字檢索(如 BM25,一種基於詞頻的稀疏檢索)反而更可靠。Hybrid search(混合檢索) 就是兩者並用:同時算稠密向量(dense,語意)與稀疏向量(sparse,關鍵字)的分數,再加權融合。以 Pinecone 的實作為例,用一個 alpha 參數調配比例,alpha=1 是純語意、alpha=0 是純關鍵字(等同 BM25)、預設 0.5 各半。實務上混合檢索幾乎總是打敗單一策略,尤其在專有名詞多的技術文件與電商場景。
RAG vs 微調 vs 長上下文:三派之爭
2026 了,「知識要放哪」仍是每個團隊都得表態的問題。微調(fine-tuning) 是把知識焊進權重,適合教模型「風格、格式、領域語感」這類難以言傳的能力,但拿它灌事實既貴又難更新,改一個數字得重訓。長上下文(long context) 這兩年窗口衝到數十萬甚至百萬 token,有人喊「直接全塞進去、RAG 該退場了」;但塞得進不代表用得好——context 越長,中段資訊越容易被忽略(「lost in the middle」效應),每次呼叫都重讀整份文件也是實打實的 token 成本與延遲。RAG 的優勢正在於只取需要的那幾段:知識更新只要重建索引、天然可溯源、成本可控。務實的共識是三者互補:微調管「怎麼說」,RAG 管「說什麼」,長上下文放大單次能容納的檢索結果。
2026 的新前沿:Agentic RAG 與 GraphRAG
樸素 RAG「檢索一次、回答一次」在複雜問題上會卡住,兩條路線正在補強它。
Agentic RAG 把檢索變成一個可迭代的決策迴圈:模型先判斷「這題該不該檢索、該查什麼」,檢索回來後自我評估「證據夠不夠、要不要換關鍵字再查一輪」,甚至拆解成子問題分頭檢索再彙整。檢索不再是死板的前置步驟,而是 agent 手裡一個可以反覆呼叫的工具。
GraphRAG 則換掉「一堆扁平文字塊」的知識表示。它先用 LLM 從文件抽出實體與關係,建成一張知識圖譜,再對圖上的社群做摘要。好處是能回答「跨文件、需要串連多個事實」的全域性問題——例如「這份卷宗裡所有人物之間的關係網」——這類問題純向量檢索很難拼齊。微軟的 GraphRAG 區分 local search(以實體為中心組上下文)與 global search(社群摘要 map-reduce)。代價是建索引貴,不過 2026 已有 LightRAG、LazyGraphRAG 等變體把成本砍掉數十到數千倍。
常見的兩種翻車
RAG 上線後最常見的兩類失敗都不在「生成」,而在「檢索」。一是檢索不到(retrieval miss):答案其實在庫裡,但因為切塊切壞了、嵌入模型不夠貼領域、或問法和原文用詞落差太大而撈不出來——模型拿不到料,只好幻覺或說不知道。二是上下文汙染(context pollution):撈回一堆「看似相關、實則無關甚至矛盾」的段落,把正確資訊淹沒,模型被雜訊帶偏。前者靠改善切塊、換領域嵌入、加 hybrid search、加 reranking 來救;後者靠更嚴的重排門檻、減少 top-k、以及在提示詞裡明確要求「資料不足就說不知道、不要編」。一個健康的 RAG 系統,評估重點永遠先看檢索品質(recall 與 precision),再看生成品質。
🧠 記
- RAG 的本質是替 LLM 接上非參數記憶:先檢索、再生成,讓模型「看著資料回答」,對治過時、幻覺與不可溯源。
- 標準管線五步:切塊 → 嵌入 → 存向量庫 → 檢索與重排 → 生成;切塊常用 200–500 token 並重疊 10–20%,嵌入常見 768/1024/1536 維。
- 重排(reranking) 用 cross-encoder 對候選重新精算相關性,常是準確率提升最有感的一步,成本只加在少數候選上。
- Hybrid search = 稠密(語意)+ 稀疏(BM25 關鍵字),專有名詞、型號、錯誤碼場景特別需要,通常勝過單一策略。
- 三派分工:微調管「怎麼說」、RAG 管「說什麼」、長上下文放大單次容量;長上下文有「中段遺失」與成本問題,不能全靠塞。
- 2026 前沿:Agentic RAG(可迭代、自我評估的檢索迴圈)與 GraphRAG(知識圖譜,擅長跨文件全域問題)。
- 最常見的翻車在檢索端:檢索不到與上下文汙染;評估先看檢索品質(recall/precision),再看生成。
✍️ 實踐
給自己 15 分鐘,手動走一遍 RAG 的「檢索」直覺,不寫程式也行。先找一份你熟悉的長文件——一份產品手冊、一篇論文、或你自己的一份會議紀錄,約十頁。第一步做人腦切塊:挑三段,分別想像它們該切成幾塊、邊界該落在哪,你會立刻體會到「按字數硬切」會怎麼劈斷語意。第二步設計一個刁鑽的問題,答案明確落在文件某處,但你故意用和原文完全不同的措辭來問——這模擬的就是使用者真實的問法。第三步分別想:純關鍵字搜尋這個問題,會不會因為用詞不同而漏掉?純語意呢?如果你的問題裡含一個型號或專有名詞,關鍵字反而更準嗎?最後花五分鐘,把這份文件貼進你常用的 AI 工具,用你設計的刁鑽問法提問,觀察它答得準不準、有沒有標出處、有沒有把不相關的段落也扯進來。這一輪走下來,你對「為什麼切塊、hybrid、reranking 存在」的體感,會比讀十篇教學都深。
🔗 延伸學習
- Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (Lewis et al., 2020) — RAG 的原始論文,提出參數記憶 + 非參數記憶的框架,一切的起點。
- Pinecone: Hybrid Search 指南 — 稠密 + 稀疏混合檢索的官方實作說明,含 alpha 加權參數。
- Microsoft GraphRAG 官方文件 — 知識圖譜式 RAG,local/global search 的設計與用法。
💬 問 AI
我想深入理解 RAG(檢索增強生成)在實務上的取捨,請針對以下幫我拆解:
1. 用一個「企業內部知識庫問答」的具體案例,從頭走一遍 RAG 管線:
切塊、嵌入、向量庫、檢索、重排、生成,每一步的關鍵決策與常見陷阱。
2. 我的文件裡有很多產品型號和錯誤碼,為什麼純語意檢索會失準?
hybrid search 具體怎麼補救?alpha 參數該怎麼調?
3. 同樣一批知識,什麼情況該用微調、什麼情況該用 RAG、
什麼情況直接靠長上下文全塞?請給我一個判斷清單。
4. 如果我的 RAG 老是「檢索不到」或「答案被無關段落汙染」,
分別該從切塊、嵌入、reranking、提示詞哪裡下手?請給排查順序。
5. 什麼時候該從樸素 RAG 升級到 agentic RAG 或 GraphRAG?
各自適合哪種問題、代價是什麼?