第 3 章

掌握 RAG

上一章的機器人再聰明，也不知道「你的店幾點打烊」。這一章我們給 AI 一座圖書館：把自己的文件變成「知識庫」，讓機器人先查資料、再回答——這個技術叫 RAG。本章用一份虛構的「星光咖啡 FAQ」全程實作。

本章目標

要學什麼: 從多個面向理解並掌握 RAG 的使用方法
學會的技能: 知識庫建構、文件匯入、Chunk 分割設定、索引模式選擇、檢索測試、把知識庫接到聊天機器人
能做出什麼: 公司內部文件檢索、客服 FAQ 機器人、技術文件 Q&A、產品手冊查詢

3.1什麼是 RAG？

RAG（Retrieval-Augmented Generation，檢索增強生成）解決一個核心問題：LLM 不知道你的私有資料。與其重新訓練模型（貴、慢、難），RAG 讓模型「開卷考試」，流程只有四步：

步驟	動作	比喻
① 建庫	把文件切塊（Chunk）、建立索引，存入知識庫	把書拆成小抄，做好目錄
② 檢索	使用者提問時，找出最相關的幾個片段	翻到相關的那幾頁
③ 增強	把找到的片段連同問題一起交給 LLM	把小抄墊在考卷旁
④ 生成	LLM 根據片段組織出回答	看著資料寫答案

重點
RAG 的美妙之處：資料更新即時生效（改文件不用重新訓練）、回答有憑有據（可以標註引用來源）、私有資料不外洩（在本地 Dify 上資料根本不出你的電腦）。

3.2建構知識庫

3.2.1準備一份範例文件

本章使用虛構店家「星光咖啡」的 FAQ 文件（samples/星光咖啡FAQ.txt），內容包含營業資訊、會員制度、商品、訂位外送、退換貨五個章節，每個問答用「Q：/A：」格式書寫。你可以替換成自己的文件——格式越規整，RAG 效果越好（本章最後會解釋為什麼）。

3.2.2建立知識庫並上傳文件

點左側欄的「知識庫」。第一次進來有三個選項，選擇官方推薦的「建立即用型知識庫」：

空的知識庫頁面，有三種建立方式 — **圖 3-1**知識庫入口。「建立自訂知識庫」是進階的流水線模式（見 3.5 節），初學先走推薦路線。

選擇資料來源支援三種：上傳檔案、同步 Notion、同步網站。點「選擇檔案」上傳 星光咖啡FAQ.txt（也支援 PDF、Word、Markdown 等格式）。
按「下一步」進入文字分段與清洗設定。

選擇資料來源畫面 — **圖 3-2**步驟一：選擇資料來源。除了本機檔案，也能直接同步 Notion 頁面或爬取網站內容。

3.2.3分段（Chunk）與索引設定

這一步是 RAG 品質的關鍵。文件會被切成一個個「分塊（Chunk）」，之後檢索是以分塊為單位進行的：

分段設定與預覽畫面，右側顯示分塊結果 — **圖 3-3**步驟二：左邊是分段設定，右邊按「預覽資料塊」能即時看到切分結果——我們的 FAQ 被切成 20 塊，每個 Q&A 恰好一塊。

設定項	意義	建議
分段識別符號	在哪裡切一刀。預設 `\n\n`（空行）	FAQ 類文件用空行分隔每個問答，效果極佳
分段最大長度	每塊的字元上限	太長→檢索不精準；太短→上下文不完整。500~1000 常見
分段重疊長度	相鄰塊之間重複的部分	約最大長度的 10%，避免資訊被切斷
文字預處理	清除多餘空白、URL 等	保持預設即可

接著選擇索引方式，這是兩條路線的分岔口：

高品質（推薦）：用 Embedding 模型把每個分塊轉成語意向量，檢索靠「語意相似度」——問「幾點打烊」能找到「營業時間」。需要先設定一個 Embedding 模型供應商（如 OpenAI、Cohere，或第 10 章的 Ollama 本地模型）。
經濟：用關鍵詞倒排索引，不需要 Embedding 模型、不花任何 Token。準確度略低，但對關鍵詞明確的 FAQ 類文件表現很好。

注意
我們的環境目前只註冊了 Anthropic（Claude 不提供 Embedding 模型），所以本章選擇「經濟」模式實作。之後若加入 OpenAI 或 Ollama 的 Embedding 模型，隨時可以在知識庫設定中切換成高品質模式並補做向量化。

索引方式選「經濟」檢索設定會自動變成「倒排索引」。
按「儲存並處理」Dify 開始切塊、建索引。

知識庫處理完成畫面，顯示嵌入已完成 — **圖 3-4**處理完成！文字檔案只要幾秒鐘。按「前往文件」查看成果。

知識庫文件列表 — **圖 3-5**知識庫的文件列表。之後可以隨時上傳更多文件、停用或重新處理個別文件。

3.3檢索測試：確認找得到再往下走

知識庫建好後，先別急著接機器人。左側選單的「檢索測試」可以直接輸入問題，看看知識庫會撈出哪些分塊——這是排查 RAG 問題最重要的工具：

檢索測試畫面，命中營業時間的分塊 — **圖 3-6**輸入「星光咖啡的營業時間」，右側立刻列出命中的分塊——正確找到了記載平日 8:00-21:00 的那一塊。

小技巧
如果檢索測試找不到預期的內容，先回頭調整分段設定（切太碎？切太大塊？），而不是先怪模型。RAG 的鐵律：檢索不到 = 回答不出。

3.4把知識庫接上聊天機器人

回到「工作室」，像上一章一樣建立一個聊天助手，取名「星光咖啡FAQ客服」。這次多做兩件事：

寫一個「看資料回答」的提示詞

你是「星光咖啡」的官方客服人員。請根據上下文提供的店家資訊回答顧客
問題，一律使用繁體中文、語氣親切。如果上下文中沒有相關資訊，請誠實
說明並建議顧客撥打客服專線 0800-123-456，不要自行編造答案。

「根據上下文回答」與「沒有資訊就誠實說」是 RAG 提示詞的兩大守則，能大幅減少幻覺。

在「上下文」區塊按「新增」選擇剛建立的星光咖啡 FAQ 知識庫，按「新增」完成掛載。

編排頁面，上下文已掛載知識庫 — **圖 3-7**「上下文」區塊出現了知識庫。從此每次對話，Dify 都會自動先檢索、把命中的分塊塞給模型。

3.4.1實測：資料裡有的問題

RAG 機器人正確回答會員等級問題 — **圖 3-8**問「會員有哪些等級？」——星塵、月光、星光三個等級與各自優惠全部答對，內容正是知識庫裡的資料，回答下方還標註了引用來源 `星光咖啡FAQ.txt`。

3.4.2實測：資料裡沒有的問題

機器人誠實表示沒有蛋糕品項資訊，引導撥打客服專線 — **圖 3-9**問「你們有賣蛋糕嗎？」（FAQ 裡沒寫）——機器人不亂編，誠實說明沒有資料並引導撥打客服專線。這就是提示詞守則發揮了作用。

3.5RAG 的成敗，八成取決於資料

同一套系統，餵進不同品質的資料，效果天差地遠。幾個實戰心得：

結構規整的文件是王道——本章的 FAQ 用「Q：/A：＋空行分隔」書寫，每個分塊恰好是一組完整問答，檢索命中率自然高。
小心 PDF 直轉的陷阱——PDF 轉文字常出現斷行錯亂、表格變亂碼。重要文件值得先手動整理成乾淨的文字或 Markdown 再上傳。
長文件先「段落化」——把意義完整的段落整理出來（一段講一件事），再交給 Dify 分塊，比直接丟原始文件效果好得多。
持續用「檢索測試」驗證——上傳新文件後，用真實會被問到的問題測一輪，找不到就調整資料或分段設定。

3.5.1進階路線預告：高品質索引、Rerank 與混合檢索

高品質（向量）索引：語意檢索，換句話說也找得到。需要 Embedding 模型。
Rerank（重排序）：先粗撈一批候選，再用 Rerank 模型精排，把最相關的排到前面。
混合檢索（Hybrid Search）：向量＋關鍵詞雙管齊下，兼顧語意與精確詞彙的命中。

這些都在知識庫的「檢索設定」中切換，等第 10 章用 Ollama 架好本地 Embedding 模型後，你可以回頭把這個知識庫升級成高品質模式，親自比較差異。

重點
新版 Dify 還提供「知識流水線（Knowledge Pipeline）」：把文件處理過程做成可自訂的節點畫布（資料來源 → 抽取 → 分塊 → 入庫），能精細控制每一步，並支援 Notion、網站爬取等多種資料源。學完第 5、6 章的工作流之後再回來玩它，會非常順手。

3.6本章回顧

RAG 四步驟：建庫 → 檢索 → 增強 → 生成。讓 LLM「開卷考試」。
分段（Chunk）設定決定檢索粒度；FAQ 類文件用空行分隔效果極佳。
索引兩條路：高品質（需 Embedding 模型、語意檢索）與經濟（關鍵詞、零成本）。
「檢索測試」是 RAG 的除錯神器：檢索不到 = 回答不出。
RAG 提示詞兩大守則：根據上下文回答、沒資料就誠實說。

機器人現在「能聊、有知識」，但還是被動的。下一章給它裝上手腳——讓 AI 自己決定用什麼工具完成任務，這就是 Agent。