昨天談代理式 AI,結尾提到 agent 需要長期記憶——把重要資訊寫進外部儲存、需要時再檢索回來,而那套機制的正式名字就是今天的主角:檢索增強生成(Retrieval-Augmented Generation,RAG)。RAG 的核心主張只有一句話:別讓模型只靠腦袋裡背下來的東西回答,先去外部知識庫「查資料」,把找到的相關片段塞進上下文,再讓模型根據這些真實資料生成答案。這一步之所以重要,是因為它同時解掉了大型語言模型三個結構性痛點——知識有截止日、會一本正經地胡說(幻覺)、碰不到你的私有資料。
📖 學
為什麼需要 RAG:模型的三個先天限制
大型語言模型的知識是「凍結」的。它的參數在訓練那一刻定型,訓練資料有個截止日期,之後發生的事——新產品、新法規、上週的財報——它一概不知。你問它今天的股價,它要嘛拒答,要嘛硬掰一個。
第二個問題是幻覺(hallucination)。模型的本質是預測「聽起來最合理的下一個字」,而不是「查證過為真的事實」。當它對某個問題沒把握時,不會誠實說不知道,而是流暢地編出一個看似可信的答案——引用不存在的論文、捏造一段法條、給錯 API 用法。這在閒聊無傷大雅,在企業客服、醫療、法律場景卻是災難。
第三個問題最實際:私有資料。再強的通用模型也沒讀過你公司的內部文件、產品手冊、客戶紀錄。你不可能為了讓它懂這些,就每次都重新訓練一個模型——成本高、資料一更新就過時。RAG 的解法優雅得多:把知識留在外部資料庫,回答前臨時檢索、動態注入。知識更新只要更新資料庫,模型本身完全不用動。這也是為什麼 2026 年 RAG 仍是企業導入 AI 最主流的架構——它便宜、可控、答案可追溯到來源。
RAG 的完整流程:切塊、嵌入、檢索、重排、生成
一套 RAG 系統分成兩個階段。**離線建索引(indexing)**是事前把知識庫準備好;**線上查詢(retrieval + generation)**是使用者問問題時即時發生的事。
離線階段第一步是切塊(chunking)。你不能把一整份 50 頁的 PDF 整個丟給模型,得先切成一段段可檢索的小單位(chunk)。切塊看似瑣碎,卻是成敗關鍵——切太大,一個 chunk 裡混了太多主題,檢索精準度下降;切太小,單一 chunk 缺乏足夠上下文,模型讀了也拼不出完整意思。
第二步是嵌入(embedding)。用一個嵌入模型把每個 chunk 轉成一串浮點數向量(通常幾百到數千維),這串數字捕捉了這段文字的「語意座標」。語意相近的文字,向量在高維空間裡也彼此靠近。所有 chunk 的向量都存進向量資料庫,建好索引。
線上階段,使用者的問題也用同一個嵌入模型轉成向量,然後在向量資料庫裡找出「與問題向量最接近」的前 K 個 chunk,這就是向量檢索。接著做重排(reranking):初步撈回來的候選未必都精準,用一個更精細的 rerank 模型重新打分、排序,篩出真正最相關的幾段。最後把這幾段 chunk 連同原問題組成 prompt,交給 LLM 生成最終答案。業界常見的比例是:檢索 20 條、重排後留 5 條、實際塞給模型 3 到 5 條。
向量資料庫與相似度:語意檢索的底層
向量檢索靠的是「相似度」而非「關鍵字匹配」。傳統搜尋是字面比對——你打「筆電」,它找含「筆電」二字的文件。向量檢索則比對語意:你打「輕薄的工作電腦」,即使文件裡一個相同的字都沒有,只要語意接近就能被找到。衡量兩個向量有多接近,最常用的是餘弦相似度(cosine similarity),看兩個向量夾角的餘弦值,值越接近 1 代表方向越一致、語意越像。
問題是,知識庫動輒上百萬個向量,每次查詢都跟全部逐一算相似度太慢。所以向量資料庫(如 Pinecone、Milvus、Weaviate,或用 PostgreSQL 的 pgvector 擴充)採用**近似最近鄰(ANN)**演算法,如 HNSW,用犧牲一點點精準度換取數量級的速度提升。選向量資料庫時,要權衡的通常是檢索速度、召回率、可擴展性,以及能否跟既有資料庫整合。
Hybrid Search:向量與 BM25 各補一刀
純向量檢索有個盲點:它擅長語意、卻常常「認不得」精確的字面。碰到產品型號、專有名詞、罕見技術術語、錯誤代碼這類需要「一字不差匹配」的查詢,語意向量反而容易失手——因為它把字義糊成了語意,而你要的正是那個精確的字串。
解法是混合檢索(hybrid search):把老牌的關鍵字演算法 BM25 和向量檢索並用。BM25 是資訊檢索領域數十年的基石,靠兩件事打分:查詢詞在文件裡出現得多不多,以及這些詞在整個語料裡有多罕見(越罕見越有鑑別力)。BM25 精準抓字面,向量負責抓語意,兩者互補。實務上用**倒數排名融合(Reciprocal Rank Fusion,RRF)**把兩套排名合併,得到的 NDCG(排序品質指標)穩定高於單用任一種。2026 年的共識是:一套認真的 RAG 系統,起手式就該是「hybrid 檢索 + reranker」,而不是純向量。
進階武器:GraphRAG、Agentic RAG 與切塊策略
基礎 RAG 有它的天花板,而 2026 年的進階方向主要往三處走。
切塊策略是投報率最高的一環。除了固定長度硬切,更聰明的是語意切塊(semantic chunking)——逐句計算相鄰句子的向量相似度,當語意明顯轉折(相似度跌破門檻)時才切開,讓每個 chunk 剛好是一個完整概念。研究顯示語意切塊比固定長度切塊的檢索準確度通常高出 10 到 20%。更激進的是命題式切塊(源自 Dense X Retrieval),把段落拆成一條條「自成一格的原子事實陳述」,每條當成獨立 chunk,精準度極高。
GraphRAG(源自微軟研究院)則跳脫「文件是一串扁平文字」的假設。它從文件抽取實體(節點)與關係(邊),建成知識圖譜,再把圖譜查詢和向量檢索搭配使用。它的殺手鐧是多跳推理(multi-hop)——回答「A 的老闆投資的公司,總部在哪個城市」這種需要串連多個事實才能推導的問題,是扁平檢索難以應付的。
Agentic RAG 則把昨天講的 agent 思維接回 RAG:不再是「查一次就生成」的單次流程,而是讓模型有「能動性」——判斷檢索結果夠不夠好,不夠就改寫查詢、換資料來源、多查幾輪,甚至同時調度向量庫、網路搜尋、SQL 查詢。它能自我修正、能處理需要多步驟拆解的模糊問題,代價是更慢、更貴、更難除錯。2026 年的成熟做法是 Adaptive RAG:用一個查詢分類器,把簡單問題丟給便宜的簡單管線,只有真正複雜的問題才動用 agentic 或 graph 的重型火力。
評估與常見坑:檢索品質決定一切
RAG 最反直覺、也最該刻進腦子的一句話是:答案的品質,上限由檢索品質決定。如果檢索階段根本沒撈到正確的 chunk,再強的模型也只能基於錯誤或不全的資料硬答——垃圾進、垃圾出。很多人一遇到 RAG 答錯就急著換更大的模型,其實九成問題出在檢索端:切塊切壞了、嵌入模型不合領域、沒做重排、沒上 hybrid。
所以評估要從第一天就做,而且要分開量「檢索」和「生成」兩段。常用框架如 RAGAS,會拆成幾個維度:context precision / recall(撈回來的 chunk 準不準、全不全)、faithfulness(答案是否忠於檢索到的內容、有沒有超出資料亂編)、answer relevance(答案切不切題)。2026 年有六成的新 RAG 專案從一開始就導入系統化評估,而 2025 年初這比例還不到三成——因為大家終於認清,沒有評估就是在盲修。常見的坑還包括:chunk 之間丟失上下文、metadata 沒善用(加了 metadata 過濾的檢索精準度可從 73% 拉到 82%)、以及誤以為「把超長文件全塞進大上下文視窗」就能取代檢索——正解是兩者互補,RAG 負責撈出對的料,長上下文負責在充足篇幅裡細緻整合。
🧠 記
- RAG 的動機:解掉 LLM 三大先天限制——知識有截止日、會產生幻覺、碰不到私有資料;知識放外部資料庫,更新資料庫即可,不用重訓模型。
- 完整流程:切塊(chunking)→ 嵌入(embedding)→ 存入向量資料庫 → 向量檢索(找語意最近的前 K 條)→ 重排(reranking,篩出真正相關的)→ 塞進上下文生成。常見比例:撈 20、重排留 5、餵給模型 3–5。
- 向量檢索比的是「語意相似度」(常用餘弦相似度),不是關鍵字;上百萬向量靠 HNSW 等近似最近鄰演算法加速。
- Hybrid search = BM25(精準抓字面、型號、術語)+ 向量(抓語意),用 RRF 融合排名;2026 年起手式就該是「hybrid + reranker」。
- 進階三方向:語意/命題切塊提升檢索準度、GraphRAG 用知識圖譜做多跳推理、Agentic RAG 讓模型自我修正多輪檢索;Adaptive RAG 依問題難度分流管線。
- 鐵律:答案品質上限由檢索品質決定(垃圾進垃圾出);評估要分開量檢索與生成(RAGAS 的 context precision/recall、faithfulness、answer relevance),從第一天就做。
✍️ 實踐
挑一份你手邊真實的資料——公司的產品 FAQ、一本操作手冊、或你自己累積的筆記,動手搭一套最小 RAG。用 LangChain 或 LlamaIndex 這類框架,先跑最樸素的版本:固定長度切塊、一個開源嵌入模型、pgvector 或本地 FAISS 當向量庫,問三五個你知道正確答案的問題,觀察它撈回來的 chunk 對不對。
接著別急著加功能,先做一次「檢索體檢」:把每次撈回的 chunk 印出來人工看,判斷是「檢索沒撈到對的料」還是「料對了但模型答歪」。這一步會逼你親眼看見「檢索決定成敗」這句話的重量。確認問題出在檢索端後,再依序試三招——改成語意切塊、加上 BM25 做 hybrid、接一個 reranker——每加一招就重測同一批問題,你會清楚感受到每個環節各自貢獻了多少準確度。
🔗 延伸學習
- RAG Best Practices 2026: Chunking, Reranking, Hybrid Search — 把 2026 年切塊、重排、hybrid 三大核心實務講清楚的實戰指南。
- Optimizing RAG with Hybrid Search & Reranking(VectorHub by Superlinked) — 深入 BM25 + 向量 + 重排如何互補的技術文章。
- Choosing the Right RAG Strategy:Chunking, Agentic RAG, and GraphRAG — 進階 RAG 架構的決策指南,幫你判斷何時該上 GraphRAG 或 Agentic RAG。
- Mastering RAG Evaluation: Best Practices & Tools for 2026 — RAG 評估方法與工具(含 RAGAS 各項指標)的完整整理。
💬 問 AI
想把今天的概念變成能上手的東西,可以請 AI 幫你為一份真實資料設計一套 RAG 方案並點出風險。把下面這段貼給它,換成你的情境:
我想為以下這份資料建一套 RAG(檢索增強生成)問答系統,請扮演資深 AI 工程師幫我規劃:
【我的資料】(在此描述:資料類型、大概篇幅、格式,例如「約 200 頁的產品操作手冊 PDF,含大量表格與型號」)
【使用者會問的問題類型】(例如「操作步驟查詢、故障排除、規格比對」)
請針對這個情境,給我:
1. 切塊(chunking)策略建議,並說明為什麼(固定長度 / 語意 / 命題式,如何處理表格與型號)。
2. 是否需要 hybrid search(BM25 + 向量),以及重排(reranking)要不要加,理由是什麼。
3. 這個情境有沒有必要上 GraphRAG 或 Agentic RAG,還是基礎 RAG 就夠。
4. 我該用哪些指標評估這套系統,以及最可能踩到的三個坑。
請具體、務實,不要空泛的原則,直接給我可以照做的建議。