第 6 章 · RAG：讓 AI 引用「你的、最新的」知識

第 1 章講過模型的兩大痛：會幻覺、知識停在訓練截止日。它不知道你公司的內部文件，也不知道昨天發生的事。**RAG（Retrieval-Augmented Generation，檢索增強生成）**就是為了治這兩個病而生——而且它是目前企業導入 AI 最主流的做法。

💡 一句話：RAG = 先去「查」相關資料，再把資料塞進 context、讓模型「根據資料」回答。 把「開卷考試」的概念用在 AI 上。

拆開這個名字你就懂它在幹嘛了：Retrieval（檢索）= 先查、Augmented（增強）= 拿查到的資料去補強模型、Generation（生成）= 讓模型根據補強後的內容產生答案。三個字剛好就是它的三個步驟，順序不能顛倒——先查、再補、後答。

為什麼需要 RAG？

想像你問一個很聰明但「只讀到去年、而且沒看過你公司文件」的顧問問題。兩種做法：

• 不用 RAG：直接問，他只能憑記憶答 → 可能過時、可能唬爛（幻覺）。
• 用 RAG：先從你的文件庫撈出最相關的幾頁塞給他，再叫他「只根據這幾頁回答」 → 答案有根據、能附出處、資料是最新的。

RAG 帶來三個關鍵好處：接地（有根據，減少幻覺）、時效（隨時更新知識庫即可）、可引用（能標出處，讓人查證）。

這三個好處分別對應到很具體的真實場景，你可以對號入座：

• 問公司內部文件：新人問「報帳流程是什麼？」「這個 API 的參數有哪些？」——答案藏在幾百份 Notion、Confluence、PDF 裡。RAG 幫他從整座文件庫撈出對的那幾段，不必自己翻。
• 客服知識庫：客服機器人回答「退貨要幾天」「這台機器 E3 錯誤怎麼排除」——這些答案本來就寫在你的知識庫裡，RAG 讓機器人照著你的官方說法回答，而不是自己編一套。
• 引用最新法規並附出處：法遵、醫療、財稅這種「答錯會出事」的場景，要求模型不只答，還要標明「這段話出自哪條法規、哪一頁」，方便人再去查證。這正是 RAG 的可引用價值——它把答案和來源綁在一起。

💡 一個判斷法：只要你的問題答案「寫在某份文件裡、而不是在模型的通用常識裡」，就是 RAG 的主場。問「什麼是通貨膨脹」不需要 RAG（通識），問「我們公司 Q3 的通膨假設是多少」就需要（藏在你的財報裡）。

為什麼不能只把整份文件塞給它就好？

你可能會想：既然模型窗口那麼大（第 1 章說動輒幾十萬 token），那我幹嘛還要「檢索」？直接把整份手冊、整個知識庫倒進 context，一次問它不就好了？

三個理由讓「全塞」在真實場景幾乎行不通：

• 塞不下：你公司的文件可能是幾千頁、幾百萬字，遠超任何模型的窗口。知識庫還會一直長大，窗口不會。
• 很貴又很慢：API 按 token 計費（第 1 章），每問一題都把整份文件重讀一遍，成本和延遲都爆表——明明答案只在其中一段。
• 塞越多、答越差：就算真的塞得下，把大量不相關的內容混進去，反而會稀釋重點、干擾模型（「該放什麼、放在哪」的取捨是第 3 章的地盤）。給它「相關的三段」，往往比給它「全部三百頁」答得更準。

RAG 的精髓就在這裡：不是讓模型讀得更多，而是幫它先篩，只把「這一題用得到」的那幾段遞到它面前。 像開卷考試時你不會把整個圖書館搬進考場，而是只翻到相關的那幾頁。

RAG 的完整流程

RAG 分兩個階段：事前建索引（把你的資料處理好、存起來）與當下查詢回答。

flowchart TB
    subgraph pre["事前：建立知識庫"]
    D[你的文件] --> C[切塊 Chunk]
    C --> E[轉成向量 Embedding]
    E --> V[(向量資料庫)]
    end
    subgraph now["當下：回答問題"]
    Q[使用者問題] --> QE[問題也轉成向量]
    QE --> R[到向量庫找最相似的幾塊]
    V --> R
    R --> RR[重排序 Rerank<br/>挑出最相關的]
    RR --> G[把資料+問題塞進 context<br/>讓模型作答]
    G --> A[有根據的答案 + 出處]
    end

一步步看：

1. 切塊（Chunk）：把長文件切成小段（例如每 300～500 字一塊）。因為你不會把整本書塞給模型，而是只給「相關的幾塊」。
2. 轉向量（Embedding）：把每一塊文字轉成一串代表「意思」的數字（回想第 1 章）。
3. 存進向量資料庫（Vector DB）：專門存這些向量、並能快速找「最相似」的資料庫。
4. 檢索（Retrieve）：使用者提問時，把「問題」也轉成向量，去向量庫找意思最相近的幾塊。
5. 重排序（Rerank）：對撈到的候選再用更精準的模型排一次，把最相關的挑到最前面。
6. 生成（Generate）：把「撈到的資料 + 問題」一起塞進 context，讓模型根據這些資料回答。

一個很有用的心法：前三步（切塊、轉向量、存庫）是事前一次做好的功夫，像圖書館員平常先把書分類上架；後三步（檢索、重排序、生成）是每次有人提問才即時跑的，像讀者來借書時館員去書架上找。分清楚這兩階段，你就不會把「建索引」和「回答」的問題搞混。

一步步拆解「為什麼」

流程你看過了，但每一步背後都有個「為什麼非這樣不可」。搞懂了，你才知道哪裡出錯要往哪調。

為什麼要切塊（Chunk）？

原理：檢索的單位是「一塊」，你怎麼切，就決定了撈回來的資訊長什麼樣。如果不切、整份文件當一塊，那要嘛塞不進窗口，要嘛撈回來一大坨都是雜訊；如果切得剛好，就能精準只撈出「講到這件事」的那一小段。

例子：一份 50 頁的員工手冊，如果整份當一塊，你問「特休怎麼算」，系統只能把整本還你（等於沒篩）。但若按「章節／段落」切成幾百小塊，系統就能只撈回「請假與特休」那三段遞給模型——乾淨、精準、省 token。

為什麼要轉成向量（Embedding）？

原理：電腦不會「讀懂」文字，但它會算數字。第 1 章講過，embedding 就是把一段文字的「意思」壓成一串數字（向量），而且意思相近的文字，數字也相近。有了這個，「兩段文字的意思有多接近」就變成一道可以計算的數學題——量兩個向量的距離就好。

例子：把「如何申請退款」和「退貨流程說明」各轉成一串數字後，即使它們沒有半個字相同，向量距離也會很近（因為講的是同一件事）；而「如何申請退款」和「員工旅遊公告」的向量就會離得很遠。這就是下一節「語意搜尋」能成立的底層原因。

🔧 動手試試：找一個線上的 embedding 或「文字相似度」小工具，輸入三句話——「怎麼退款」「退貨要退錢」「今天天氣真好」，看它算出來的相似度分數。前兩句會明顯比第三句高。你就親眼看到「意思」被變成了可以比大小的數字。

為什麼檢索是「問題也轉成向量」？

原理：既然文件片段都變成向量了，那要找「跟問題最相關的片段」，最直接的辦法就是把問題也用同一套 embedding 轉成向量，然後去向量庫找離它最近的幾塊。你問的和存的，被放進同一張「意思地圖」上比距離（回想第 1 章的意思地圖）。

例子：使用者打「筆電開不了機」，這句話被轉成向量後，系統去庫裡找最近鄰，撈回標題是「膝上型電腦無法開機的排除步驟」的那塊——即使兩邊用詞不同，因為「意思」在地圖上就是鄰居。

為什麼最後要「把資料塞進 prompt」再答，而不是讓模型自己想？

原理：這一步才是「治幻覺與知識截止」真正發生的地方。模型腦中沒有你的資料（知識截止、也沒讀過你的私有文件），但只要你把撈到的段落放進當下這次的 context，模型就能「看著這幾段」回答——它不必知道，它只要會讀。這就是為什麼 RAG 能救第 1 章那兩個病：不是把知識訓練進模型，而是臨場把資料遞到它眼前。

例子：prompt 實際上長得像這樣——「以下是相關資料：〔撈到的三段〕。請只根據上面的資料回答使用者的問題：『我們的退貨期限是幾天？』，並標明你引用了哪一段。」模型於是照著那三段答「30 天」，還附上出處，而不是憑空猜一個數字。

🔧 動手試試：不用架任何系統也能體驗 RAG 的精神——複製一段官方文件（例如某產品的退換貨條款）貼進 ChatGPT／Claude，然後在下面打「請只根據上面這段文字回答：可以換貨幾次？並引用原文。」你會發現它變得很「乖」、不亂編——這就是「把資料塞進 context」的威力，RAG 只是把「貼文件」這步自動化了。

核心魔法：語意搜尋（不是關鍵字搜尋）

傳統搜尋是比對關鍵字：你搜「筆電」就找不到只寫「notebook」或「膝上型電腦」的文件。

RAG 用的是語意搜尋：因為每段文字都被轉成「代表意思的向量」，意思相近的向量距離就近。所以你搜「筆電」，也能撈到談「膝上型電腦」的段落——它比對的是意思，不是字面。

💡 實務上最強的是混合搜尋（Hybrid Search）：關鍵字搜尋（精準抓專有名詞、型號）＋語意搜尋（抓同義、相關）兩個一起用，再 rerank，效果最好。為什麼要兩個一起？因為語意搜尋雖然懂同義，卻常對「精確字串」失手——你搜產品型號「X-2000」或錯誤碼「E3-14」，語意搜尋可能覺得「差不多的都算」而撈回一堆相近型號，這時反而是老派的關鍵字比對更靠譜。兩者互補。

常見的向量資料庫有 pgvector（PostgreSQL 外掛）、Pinecone、Weaviate、Qdrant 等，先知道名字就好。

🔧 動手試試：拿你手邊任何一個內建搜尋（公司 Wiki、購物網站、雲端硬碟）做個對照實驗——先用「正式名稱」搜一次，再換「口語同義詞」或英文搜一次（例如「發票」vs「收據」、「筆電」vs「notebook」）。多數傳統搜尋第二次會撈不到或變少，你就體會到為什麼 RAG 要改用「比意思」的語意搜尋。

切塊策略：RAG 好不好用，一半看這裡

「怎麼切塊」聽起來很枝微末節，卻是 RAG 成敗關鍵：

• 切太大：一塊塞太多雜訊，稀釋重點（回想第 3 章 context rot）。
• 切太小：語意被切斷，撈到半句話沒頭沒尾。
• 較好的做法：按語意單位切（段落、章節），並讓相鄰塊稍微重疊，避免把一句話從中砍斷。

為什麼「重疊」有用？舉個具體的坑：假設一段話是「本產品保固兩年，但人為損壞不在此限」，如果剛好從中間切成「本產品保固兩年」和「但人為損壞不在此限」兩塊，使用者問「人為損壞有保固嗎」時，可能只撈到後半塊、丟了「保固兩年」的前提，答案就殘缺。讓相鄰塊各多含幾十個字的重疊，就能保住這種「跨越切口」的完整語意。

🔧 動手試試：挑一份你熟的文件（履歷、產品說明、一篇文章），拿筆把它「切塊」看看——先每 3 句一塊，再改成「按小標題」一塊。想像使用者可能問的三個問題，判斷哪種切法能讓「對的那一塊」剛好被撈到。你會親身體會到「切塊策略」不是玄學，而是實實在在影響命中率。

進階：RAG 也在進化

• GraphRAG：不只存「片段」，還建一張「知識圖譜」（誰跟誰有關係），適合需要跨多份文件、多跳推理的問題。
• Agentic RAG：讓 agent（第 7 章）自己決定「要不要查、查幾次、查什麼」，而不是死板地固定查一次。

先知道有這些方向即可，別一開始就上重武器。

怎麼知道你的 RAG 有沒有做好？

RAG 常見的失敗有兩種，各自要看不同指標（這也是第 10 章「評估」的一個縮影）：

這兩種失敗要分開看，因為修法完全不同：撈不到，你要回頭調「切塊」和「檢索」（塊切得對不對、要不要加關鍵字搜尋、要不要 rerank）；撈到了卻答錯，問題出在「生成」那一步（prompt 要更嚴格地叫它「只依據資料、不得自行補充」）。搞錯病灶，藥就開錯。

⚠️ 最常見的誤會：「RAG 就不會幻覺了」。錯。如果撈到的是錯的、或不相關的資料，模型照樣會給你一個很有自信的錯答案。 RAG 降低幻覺，但不是免死金牌——所以要評估。

重點回顧

• RAG = 先檢索、再生成：治「幻覺」與「知識截止」，讓 AI 引用你的、最新的資料並附出處。名字三個字就是三步驟：檢索 → 增強 → 生成。
• 為什麼不「全塞」：文件塞不下、成本高、而且塞越多雜訊反而答越差——RAG 是幫模型先篩，只遞相關的那幾段。
• 流程：切塊 → 轉向量 → 存向量庫 → 檢索 → 重排序 → 生成；前三步事前建好，後三步臨場才跑。
• 每一步的「為什麼」：切塊決定撈回的單位、embedding 把「意思」變成可計算的數字、檢索把問題丟進同一張意思地圖比距離、最後把資料塞進 context 讓模型「看著答」——這才是治幻覺的關鍵。
• 核心是語意搜尋（比對意思，不是關鍵字）；實務首選混合搜尋 + rerank。
• 切塊策略是成敗關鍵：按語意切、適度重疊（避免把一句話砍斷）。
• RAG 不是免死金牌：撈錯資料照樣答錯，一定要評估檢索命中率與忠實度（兩種失敗、兩種修法）。

到這裡，階段二（工作流與知識）完成了。接下來進入最熱門、也最容易被神化的主題——AI Agent。下一章我們拆穿它：它其實只是「一個會用工具的迴圈」。