RAG：合法讓 AI
帶小抄進考場的技術
一小時，搞懂 RAG（Retrieval-Augmented Generation，檢索增強生成）到底在幹嘛。 上完這堂課，「向量資料庫」「embedding」「語意檢索」這些名詞會從咒語變成常識—— 而且你會知道它跟「建一個資料庫」根本是兩回事。
第 1 章 · 開場破題閉卷考的天才，為什麼一直唬爛
先想像一個場景：
你認識一位超狂的學霸。他讀過的書多到嚇死人，講話頭頭是道，寫作文行雲流水。 但他有兩個致命弱點：第一，他的知識停在畢業那一天——之後世界發生什麼事他一概不知； 第二，考試的時候如果碰到不會的題目，他不會空白，他會用超有自信的語氣掰一個答案給你， 掰得有模有樣，連他自己都信了。
這位學霸，就是 LLM。而他考的每一場試，都是閉卷考——只能靠腦袋裡訓練時記下的東西作答。
他沒讀過你公司的員工手冊，
但他還是會回答。
這就是問題所在。
所以閉卷考的學霸有三大死穴：
- 不知道你的私有資料。你的公司文件、你的筆記、你的產品手冊——訓練資料裡通通沒有。
- 知識過期。訓練截止日之後的事，他一律不知道，但不妨礙他發表意見。
- 不會就掰。他的本性是「生成看起來合理的文字」，不是「查證事實」——這就是「幻覺」的來源。
那怎麼辦？重新訓練一個懂你公司文件的模型？太貴，而且文件一改又要重練。 把全部文件每次都貼進對話？文件一多就塞爆（而且貴到哭）。
與其逼學霸「背下你的所有資料」，不如讓他考試的時候可以翻資料。 每次有人提問，先去你的文件堆裡把「跟這題最相關的幾段」翻出來， 夾在考卷旁邊給他看，再讓他作答。這就是 RAG—— Retrieval（檢索：把相關資料翻出來）+ Augmented（增強：夾進考卷）+ Generation（生成：學霸看著資料寫答案）。
整堂課抓住這一句就夠了：「RAG = 先翻書、再作答。」 前半段「翻書」叫檢索，後半段「作答」叫生成。接下來我們把這兩段拆開講透。
第 2 章 · 核心比喻考場裡的神隊友
開卷考聽起來很美好，但考過開卷考的人都知道一個殘酷真相： 資料帶得越多，越翻不到重點。 抱一整箱講義進考場，鐘響開始翻，翻到交卷還在翻——開卷考死最慘的，往往是資料帶最多的人。
LLM 也一樣。它的「桌面」（context window，一次能讀的文字量）有限， 你不可能把 200 頁的文件整箱倒給它，而且就算塞得下，資訊太雜它也會抓錯重點。 所以真正的關鍵不是「能不能翻書」，而是——誰幫你翻到對的那一頁？
登場：兩人一組的考試小隊
想像這場開卷考不是一個人考，是兩人小隊：
- 🔍 翻書手——考前就把你的所有資料讀過一輪，剪成一張張小抄卡片， 並且按照「內容意思」整理好。考試鐘一響，他聽完題目，唰唰唰三秒抽出最相關的三張卡片，拍在桌上。 他不負責作答，他只負責找。他甚至不用很聰明，但手要快、要準。
- ✍️ 寫手——就是第 1 章那位文筆爆棚的學霸（LLM）。他看著翻書手遞來的卡片， 用自己的話把答案寫得漂亮、講得白話、統整成一段人話。 卡片上沒有的，他（理論上）不該自己加戲。
這個分工就是 RAG 的全部靈魂：
- 翻書手 = 檢索（Retrieval）階段：從一大堆資料裡，快速找出跟問題最相關的幾段。
- 寫手 = 生成（Generation）階段：把找出來的內容消化，生成自然語言的回答。
- 兩人之間傳遞的卡片 = 交棒點：檢索的輸出，就是生成的輸入。整個 RAG 系統的品質， 取決於卡片找得準不準、寫手守不守規矩。
因為這兩件事需要的能力完全不同。「在一百萬張卡片裡三秒找到對的那張」需要的是又快又便宜的比對能力， 根本不需要會寫作文；「把三張卡片寫成一段通順人話」需要的是語言能力，但不需要記得一百萬張卡片。 讓學霸自己翻一百萬張卡片？慢、貴、桌子還放不下。讓翻書手自己寫答案？他只會把卡片原文丟你臉上。 分工，才是 RAG 聰明的地方。
本課的貫穿範例：滷味店秘笈
接下來全程用同一個例子。假設你開了一家滷味店，多年心血寫成一本 200 頁的《滷味秘笈》： 配方、滷製時間、客訴處理、每日 SOP 全在裡面。 現在你想做一個「新員工問答機器人」——員工用 LINE 問問題，機器人根據秘笈回答。
直接把問題丟給 LLM？它沒讀過你的秘笈，會掰一套「通用滷味理論」給你。 這正是 RAG 的主場：翻書手負責翻秘笈，寫手負責回 LINE。 下一章，我們先解剖翻書手。
第 3 章 · 檢索 RETRIEVAL神隊友怎麼在 200 頁裡秒翻到那一頁
翻書手的工作分成兩個時期：考前準備（一次做好，之後重複用）和 考試當下（每次有人提問就跑一遍）。我們用步進器全程跟拍—— 按「下一步」，看《滷味秘笈》怎麼一路變成三秒可查的小抄系統。
重點放大：什麼是 embedding？（保證無公式版）
剛剛生產線裡最玄的一步，就是「把文字變成意義座標」——術語叫 embedding（嵌入向量）。
別怕，它的直覺其實超簡單：
想像一張巨大的「意義地圖」。每一段文字，都可以在這張地圖上釘一根圖釘。 釘的位置不是照筆畫、不是照注音，而是照「意思」：
- 「太鹹了怎麼補救」和「鹹度過高之補救措施」——用字幾乎沒重疊，但意思像雙胞胎，圖釘釘在隔壁。
- 「豆干滷 45 分鐘」和「本月營業額報表」——意思八竿子打不著，圖釘隔了十萬八千里。
- embedding 模型（一種專門做這件事的 AI）負責幫每段文字算出圖釘座標——實際上是一長串數字，但你只要記得「意思越近、座標越近」就夠用一輩子。
有了意義地圖，「找相關資料」就從「比對字面」變成「比距離」： 把使用者的問題也釘上地圖，看哪幾張卡片的圖釘離它最近，抽出來就對了。 這就是所謂的向量相似度搜尋——聽起來很厲害，本質就是在地圖上找鄰居。 而專門存這些座標、負責快速找鄰居的資料庫，就叫向量資料庫。
🎮 動手實驗：關鍵字警衛 vs 語意雷達
口說無憑，直接玩。下面是《滷味秘笈》切出來的五張卡片， 請你挑一個「新員工會問的問題」，看看傳統關鍵字搜尋（比對字面，像 Ctrl+F） 和語意檢索（比意義距離）各自交出什麼成績。
📇 知識庫裡的五張卡片：
👇 選一個問題丟進去：
※ 相似度百分比為教學示意值，非真實模型即時計算。
1️⃣ 字面一樣時，關鍵字搜尋也能贏。問「豆干」查「豆干」，Ctrl+F 又快又準——關鍵字搜尋不是廢物。
2️⃣ 換句話說，關鍵字就瞎了。「太鹹」vs「鹹度過高」、「奧客」vs「客訴」——人類換個說法毫無壓力，字面比對直接暴斃。
3️⃣ 語意雷達給的是「排行榜」，不是「有／沒有」。它永遠能排出最近的幾張卡片——這也是雙面刃：就算庫裡根本沒有答案，它還是會硬撈幾張「最不遠」的給你。檢索品質是 RAG 的第一道生死關。
第 4 章 · 生成 GENERATION拿到小抄之後，換學霸上場
翻書手把三張卡片拍在桌上了。接下來的問題是：這些卡片怎麼「餵」給 LLM？ 答案樸實到你可能會失望——就是把卡片內容當成文字，直接夾進 prompt 裡。 沒有神秘通道、沒有把知識「灌進模型腦袋」，就是複製貼上等級的操作。
員工問「客人說太鹹怎麼辦？」，你的程式實際送給 LLM 的考卷長這樣：
【卡片 C】客訴處理原則：先道歉、再補償小菜一份、最後記錄於交接本…
【卡片 D】每日打烊前，滷汁需過濾並冷藏保存…
LLM 收到這張「組裝考卷」之後，做它最擅長的事：讀懂、消化、統整、用人話回答——
🗣️ 模型的回答（示意）：
「別慌，分兩件事處理：對客人——先道歉，補一份小菜，並記錄到交接本（卡片 C）； 對那鍋滷汁——加等量清水和少許冰糖回滷十分鐘補救（卡片 A）。」
注意它做了幾件關鍵字搜尋永遠做不到的事： 把兩張不同卡片的內容組合成一個完整答案、 自動忽略不相關的卡片 D（打烊 SOP 跟這題無關）、 而且是用回答問題的口吻講，不是把原文丟你臉上。 這就是「Generation」三個音節的全部價值：開卷考不是抄書比賽，是看著資料寫出自己的答案。
兩階段怎麼銜接？一張圖看懂
寫手再會寫，翻書手翻錯頁就全毀了。如果檢索撈回來的是打烊 SOP 和營業額報表， LLM 也只能對著錯的資料硬寫——而且寫得跟真的一樣流暢。 所以 RAG 系統出包時，永遠先檢查檢索撈到了什麼，再來怪模型。 八成的「RAG 回答很爛」，兇手是翻書手，不是寫手。
第 5 章 · 核心對決「我建個資料庫就好了吧？」——差很多，差在這
每次講完 RAG，一定有同學舉手：「等等，我把秘笈打進資料庫，做個搜尋功能，不就好了？ 幹嘛搞什麼向量、什麼 LLM？」 好問題，這正是本課的大魔王題。我們讓兩位選手同場競技三回合，你自己看差在哪。
左邊選手：純知識資料庫（文件存好 + 關鍵字搜尋，像公司內網的文件系統）。 右邊選手：RAG（語意檢索 + LLM 生成）。
第一回合：換句話說 —— 「太鹹」事件
新員工小美在 LINE 上問：「客人說太鹹怎麼辦？」
- 🗄️ 純資料庫：在文件裡搜尋「太鹹」……秘笈裡寫的是「鹹度過高之補救措施」。
字面對不上，系統回：
查無資料。小美再試「很鹹」「好鹹」「鹹爆」——通通查無資料。 小美放棄系統，直接打給你。你半夜十一點接到電話。系統宣告死亡。 - 📡 RAG：「太鹹怎麼辦」和「鹹度過高之補救措施」在意義地圖上是鄰居， 一撈就中。小美三秒拿到答案，你繼續睡覺。
→ 差異一：純資料庫比對「字」，RAG 比對「意思」。 人類天生就是換句話說的生物，沒有人會照著你文件裡的措辭提問。 這不是小缺陷，這是關鍵字系統在真實世界的第一死因。
第二回合：就算找到了 —— 「40 頁 PDF」事件
這回合我們讓純資料庫贏在起跑點：小美這次搜「客訴」，真的命中了！系統回傳—— 《客訴暨異常事件處理辦法（v3，含附錄）》，40 頁。
- 🗄️ 純資料庫：它的工作到此結束。它是個誠實的倉庫管理員： 你報貨號，它把整箱原封不動搬給你。要在 40 頁裡找到「先道歉還是先補償」？ 自己讀，孩子。客人在櫃檯等著，小美在翻目錄。
- 📡 RAG：檢索只撈出相關的那幾段，LLM 再把它們濃縮成 「先道歉 → 補小菜 → 記交接本」三步驟，直接回答小美問的那個問題。 還能追問：「如果客人要退錢呢？」——再檢索、再回答，像對話，不像查檔案。
→ 差異二：純資料庫交付「原文」，RAG 交付「答案」。 找到文件只是完成一半——「從文件到答案」中間那段理解、篩選、統整的工， 純資料庫留給人類，RAG 交給 LLM。
第三回合：跨文件整合 —— 「開新分店」事件
店長問了一個大題目：「如果我要開第二家分店，秘笈裡哪些 SOP 需要先標準化？」
- 🗄️ 純資料庫：搜「分店」……秘笈裡根本沒有「分店」這個詞（你又還沒開過）。查無資料。 就算你手動翻，答案也散落在滷汁保存、員工訓練、供應商名單等十幾個不同章節裡—— 資料庫沒有能力把它們「湊成一個答案」，因為它根本不理解問題在問什麼。
- 📡 RAG：語意檢索撈出所有跟「流程、標準、交接」意思相近的段落， LLM 讀完後生成：「建議優先標準化三件事：滷汁配方計量化（目前寫『適量』的有 12 處）、 每日 SOP 檢查表、客訴處理流程……」——一個秘笈裡沒有現成答案、卻是從秘笈內容推出來的回答。
→ 差異三：純資料庫只能回答「文件裡寫過的」，RAG 能回答「文件內容能推出來的」。 因為多了一顆會理解、會綜合的腦（LLM），零散的段落才能變成觀點。
別誤會這是「資料庫過時了」的故事。RAG 的肚子裡就有一個資料庫（向量資料庫，存卡片和座標），
很多正經系統還會關鍵字＋語意兩路並用（術語叫混合檢索）——查貨號、查訂單編號這種精確比對，
關鍵字反而是王者。正確的理解是：
RAG = 資料庫（存）＋ 語意檢索（懂你在問什麼）＋ LLM（把找到的變成答案）。
純資料庫是一座圖書館；RAG 是圖書館加上一位聽得懂人話的館員。差的從來不是那些書，是那個人。
| 情境 | 🗄️ 純知識資料庫 | 📡 RAG |
|---|---|---|
| 換句話說提問 | 字面對不上 → 查無資料 | 意義地圖找鄰居 → 照樣命中 |
| 找到之後 | 丟給你整份原文，自己讀 | LLM 消化成直接回答問題的人話 |
| 答案散在多份文件 | 無法整合，逐份自己翻 | 跨段落統整成一個答案 |
| 擅長的事 | 精確查找（編號、庫存、報表） | 用自然語言問知識、要解釋 |
（這張表是給你考前抽背用的——上面三回合的故事才是本體。）
第 6 章 · 學以致用你下個專案，大概率就會撞到它
這堂課不是通識課。你是用 AI 工具寫程式、想做 Agent 的人—— 以下四個場景，就是 RAG 會出現在你人生裡的地方。
① 「幫我的文件做一個問答機器人」——經典 RAG 專案
個人筆記庫、公司內部文件、產品說明書、課程講義……只要有人說出 「我想直接用問的，不想自己翻」，就是 RAG 的招牌案型。 你現在已經知道整條生產線：切塊 → 算座標 → 存向量資料庫 → 問題進來 → 撈卡片 → 組 prompt → 生成。 Vibe coding 的好消息是：每一步都有現成的函式庫和服務，你不需要自己實作任何一步的內部細節—— 但你需要懂每一步在幹嘛，不然出了問題連該罵哪一段都不知道。
② Agent 的「查資料」工具——RAG 是 Agent 的外接大腦
做 Agent 時，檢索通常被包裝成一個工具（tool）—— 例如透過 MCP 這類協定掛給 Agent 一個「搜尋知識庫」的工具。差別在於：
- 傳統 RAG：每個問題進來都固定先檢索，流程寫死。
- Agent + 檢索工具：Agent 自己決定要不要查、查什麼、查幾次。 問「你好嗎」它不查；問「我們的退貨政策」它會呼叫檢索工具，甚至換幾組說法多查幾輪。
你會發現這只是把「翻書手」從流水線工人升級成「學霸可以隨時使喚的助手」—— 概念一模一樣，只是誰握有「要不要翻書」的決定權變了。
③ Context window 的救星——為什麼不「全部塞進去」
你一定會想：「現在模型的 context window 那麼大，把整份文件塞進去不就好了？」 小文件——對，就這麼做，十頁的東西別折腾什麼向量資料庫，直接全文貼進去又準又省事。 但文件一旦上了量級：
- 錢：每問一題都把 200 頁重新塞一次，token 費用按次燃燒。RAG 每次只塞最相關的幾段。
- 塞不下：知識庫成長到幾千份文件時，再大的窗口也是杯水車薪。
- 雜訊：塞一堆無關內容，模型反而容易被帶偏。開卷考帶一整箱講義進場的下場，第 2 章講過了。
④ Debug 心法：出事先驗「翻書手」
你的 RAG 專案上線後回答很爛，怎麼辦？記住第 4 章的鐵律，照這個順序查：
- 先印出檢索結果。看撈回來的卡片跟問題有沒有關係。八成的爛答案，兇手在這裡： 切塊切得太碎（卡片語意殘缺）、切太大（一張卡片混了三個主題）、或庫裡根本沒這份資料。
- 再看組裝的 prompt。指示有沒有講清楚「只根據參考資料回答、沒有就說不知道」？
- 最後才調模型。換更強的模型是最貴、也最常被高估的解法。 給學霸換一個更貴的學霸，救不了翻錯頁的翻書手。
「想用問的查自己的文件」→ 經典 RAG 管線。
「Agent 需要查外部知識」→ 把檢索包成工具掛給它。
「文件只有幾頁」→ 別建 RAG，全文塞 context 就好。
「查訂單編號、精確欄位」→ 用傳統資料庫查詢，別硬上語意檢索。
「RAG 答得很爛」→ 先印檢索結果，再檢查 prompt，最後才換模型。
第 7 章 · 結業考畢業前，五題定生死
全對的人，從此聽到「向量資料庫」不再肅然起敬。答錯也沒關係，解釋就在下面。
🎓 帶走這 5 句話（其他都可以忘）
- RAG = 先翻書、再作答：檢索找出相關段落，生成把段落寫成人話。
- embedding 是意義地圖上的座標：意思越近、釘得越近，所以換句話說也找得到。
- 檢索的輸出就是生成的輸入，交棒方式就是夾進 prompt——模型本身一毫米都沒被改動。
- 純資料庫比對字面、交付原文；RAG 比對意思、交付答案。
- RAG 出包，先驗翻書手（檢索結果），最後才怪寫手（模型）。
你可以微笑著說：
「就是幫一個很會寫但畢業後就沒讀書的學霸，
請了一位考前整理小抄、考中秒翻重點的神隊友。」