RAG 與向量資料庫：
先查再答
同一個模型、同一個問題、同一個 temperature=0——唯一的差別是有沒有先查手冊。 下面是真實紀錄：一份模型絕不可能背過的虛構咖啡機手冊，四個問題， 紅色是它編出來的、綠色是手冊裡真有的。點問題切換：
右邊的實驗場是真的 Python（在你的瀏覽器裡跑，不用安裝任何東西）。 首次載入約需 30–60 秒，正好夠你讀完第 1 節。手冊 12 段的真向量已打包在裡面， 檢索是現場算的——改壞了重新整理就復原。
RAG：先檢索，再生成
開場那四組對照值得各看一眼，它們是三種不同的失敗：
| 問題 | 無 RAG 發生了什麼 |
|---|---|
| Q1 首次使用／Q2 除垢 | 整套流程都是編的（裝咖啡液體、倒白醋跑 15–30 分鐘）——語氣自信、格式漂亮，全錯。這叫幻覺。 |
| Q3 磨太細 | 咖啡通識大多講對了——但答不出「防堵塞保護自動停機」這種只在你手冊裡的規格。 |
| Q4 保固 | 「2 年」矇對了（常見值），細節全編——矇對的和編造的長得一模一樣，你無法分辨哪句可信。 |
模型的知識來自訓練語料：有截止日期、沒看過你的私有資料、記憶又是模糊的統計。 要它回答「你家的事」，就得把資料在提問當下遞給它——這就是 RAG 解的問題。 有 RAG 的版本不只答對，還會指出處（「根據手冊段落【段落 3】…」）， 答不了的說「手冊中沒有提到」——可信度是這樣來的。
向量資料庫：存 embedding、查最近鄰
第 1 課你算過 cosine 最近鄰；文件只有 12 段時用 numpy 就夠（右邊 1️⃣ 正是這樣做的）。 但文件變成十萬段，就需要專門的資料庫：建索引加速查詢、管理增刪、存 metadata。 入門首選 chromadb——兩行就能開始，內建預設 embedding 模型：
正式環境常見 Qdrant（獨立服務、支援過濾與分片）—— 本站 llm-apps 系列的 Qdrant 課有完整實作， 學完這課想動真格的可以接著上。
拆開管線：沒有魔法，只有五步
檢索到的段落是怎麼「進到」模型的？答案樸素到令人安心：貼進 prompt。
| 步驟 | 做什麼 | 本課對應 |
|---|---|---|
| 1 切塊 chunking | 文件切成段，一段講一件事 | 手冊 12 段 |
| 2 向量化 embed | 每段算 embedding 存入向量庫 | jina-embed 1024 維 |
| 3 檢索 retrieve | 問題算向量、cosine 排序取 top-k | 右邊 1️⃣ |
| 4 組裝 augment | top-k 段落＋規則貼進 prompt | 右邊 3️⃣ 印給你看 |
| 5 生成 generate | 模型照段落回答、查無則明說 | 右邊 2️⃣ 的綠卡 |
其中第 4 步的 system prompt 有一句關鍵咒語：「手冊裡沒有的資訊， 要說『手冊中沒有提到』」——它把模型從「編一個答案」的預設行為扳成「承認查不到」。 右邊 3️⃣ 印出了實測時真正送給模型的完整 prompt，一個字都沒藏。
進階流派：GraphRAG 與多模態 RAG
基本 RAG 的弱點：問題的答案散在很多段、要先把關係接起來時 （「這家公司過去三年的策略轉變是什麼？」），top-k 段落各自為政、接不出全貌。 GraphRAG（微軟開源）先用 LLM 把文件抽成「實體－關係」圖譜＋社群摘要， 檢索時沿著圖找、用摘要答全域問題：
多模態 RAG則是把「文件」的定義擴大：簡報的圖表、掃描的表格、產品照片 也用多模態 embedding 模型向量化，跟文字一起檢索。 兩者都屬「知道有這回事」的延伸——先把基本 RAG 做穩，真的撞到牆再升級。 想在真環境把 RAG 完整做一遍，本站 llm-apps 系列的 RAG 課是下一站。
本課名詞速查卡
發講義用的濃縮版——一個名詞一句話：
| RAG | 先檢索再生成：回答前把相關段落塞進 prompt——企業落地最常見架構，治「編造」與「不知道你家的事」。 |
| 向量資料庫 Vector DB | 存 embedding、查最近鄰的資料庫（Chroma／Qdrant）——RAG 的檢索層。 |
| 幻覺 Hallucination | 模型自信地編造不存在的事實——RAG＋「查無則明說」規則是最常用的解法。 |
| GraphRAG / 多模態 RAG | 融合知識圖譜與圖像表格的進階檢索——答案散在多處、接得起關係才答得了時用。 |
換你動手
在右邊 1️⃣ 把 top-k 從 3 拉到 5，觀察第 4、5 名的相似度掉到多少、內容跟問題還有沒有關係。top-k 越大越好嗎？
把實驗區改成 MY_Q = 3（保固）、MY_K = 1——只給一段答得了嗎？什麼樣的問題只靠 top-1 就夠、什麼樣的一定不夠？
設計一個「檢索一定失敗」的問題（手冊沒寫的事，例如冰滴咖啡）。先猜：檢索會回什麼？靠什麼擋住模型開始編？
卡住了？三題在 notebook 最後一格都有折疊解答——先自己做，再打開對照。
情境測驗
離開前試試看：下面的情境都真的會遇到。每題選一個你認為的最佳做法，選了馬上看得到解釋。
Q1 情境題
公司要做內部規章問答機器人，試用時發現模型常把規定講錯、還講得很有自信。要讓回答可信，最該做的是？
可信要靠「有據」：RAG 讓每個回答都建立在當下檢索到的原文上，能指出處、能說查無，規章改了重新入庫即可——這正是它成為企業標配的原因。A 只是求它，擋不住本課 hero 那種自信編造（模型不知道自己在編）；C 短期可行但貴又慢，而且塞進大量無關條文會稀釋重點、答錯率反而上升（第 1 課的 context window 教訓）；D 成本高、更新慢（規章一改就要重練），而且微調改的是「行為風格」，對「精確記住條文」並不可靠——知識類需求先 RAG，是業界的預設順序。
Q2 錯誤診斷
同事看了無 RAG 的實測回答（節錄如下），說：「你看，連保固 2 年都答對了，模型本來就會，不用做 RAG。」他哪裡看錯了？
這段是實測紀錄：手冊只寫「2 年保固；人為損壞、摔落、未除垢的水垢堵塞不保固」——回答裡的「合約」「電源斷電」「水質過鹹」「強光直射」通通是生成的。危險不在錯，在對錯混在一起且語氣一致：使用者沒有手冊可對照，只能全信或全疑。B 無中生有，這個模型沒有上網能力，答對是因為「2 年」是家電保固的高頻值；D 是常見誤解——這次實測本來就是 temperature=0，決定性抽樣只是讓輸出穩定，穩定地編造還是編造。A 的結論建立在「恰好抽對的一個字」上。正解是讓回答有出處：RAG。
Q3 情境題
你把公司 200 頁的產品手冊做成 RAG，但偷懶把「整份 PDF 抽出來的全部文字」當成一個 chunk 存進向量庫。會發生什麼事、該怎麼切才對？
切塊（chunking）決定檢索的「解析度」：一個 chunk＝一次只能整塊給。全文一塊時，任何問題都命中同一塊，等於退化成「每次把整份手冊塞進 prompt」——token 爆炸、無關內容稀釋重點，而且一個向量要代表 200 頁的語意，跟任何具體問題的相似度都變得模糊。本課手冊切成 12 段、一段講一件事，Q2 檢索才能精準地把「除垢」那段排到 0.7；這是 A 想不到的代價。C 過度信任工具——切塊策略（大小、重疊、按語意或章節）是你要做的設計決策，庫只存你給的東西；D 搞錯了主要傷害，慢是小事，答不準才是大事。