你一定看過這種畫面：問 AI「我們公司的退貨期限是幾天」，它語氣超肯定地回你「14 天」，但你們明明寫的是 7 天。它不是故意騙你，而是它根本不知道你們的規定，只好憑訓練資料「合理猜測」。這種一本正經地胡說八道，就是 AI 幻覺，也是企業導入 AI 客服最大的地雷。RAG（檢索增強生成）就是專門解決這件事的技術。
這篇要解決的問題：怎麼讓 AI 只根據「你提供的資料」回答，而不是憑空亂編，並一步步建出一個能上線的知識庫客服。 適合誰讀：想導入 AI 客服或內部問答的中小企業、客服與行銷主管、產品與營運人員，零到中階都適合，不需先懂機器學習。 讀完你會得到：對 RAG 的清楚理解、一套可照做的建置步驟、可複製的 Prompt、Workflow 流程圖、一段進階的檢索調校心法，以及一個含成果數據的台灣案例。
為什麼一般 AI 客服會「亂講話」？
直接拿 ChatGPT 或 Claude 當客服，最常出三種狀況：
- 編造不存在的政策：問到它沒學過的公司規定，它會用「最像答案的話」填空，講得頭頭是道卻是錯的。
- 資訊過期：模型的訓練資料有時間截止點，去年改過的價格、今年新出的方案，它通通不知道。
- 無法引用來源：你問它「這是寫在哪份文件」，它答不出來，因為它本來就不是「查」出來的，是「想」出來的。
問題的根本在於：通用模型的知識是「死的」，而且是「它的」，不是「你的」。客服要的是準確回答你們家的規定，不是世界上的平均答案。
要修正這件事，有兩條路：一是把模型拿你的資料重新訓練（微調，fine-tuning），成本高、更新慢、資料一改就得再訓練一次；二是 RAG——不動模型，而是在它回答前把正確資料「餵」給它。對絕大多數企業客服場景，RAG 是 CP 值高出一截的選擇，這兩條路的取捨我們在 微調 vs RAG 的完整比較 裡有更細的拆解。這也是為什麼 RAG 成為現今 AI Agent 落地的標準配備。
核心概念：RAG 是「開書考試」，不是「背書考試」
理解 RAG 最好的比喻，是把 AI 想成一個考生：
- 沒有 RAG（閉卷考）：考生只能靠記憶答題。記得的就答對，不記得的就硬掰，這就是幻覺。
- 有 RAG（開書考）：考試前，助理先依題目幫他翻到課本相關那幾頁、攤在桌上，他只要「照書回答」。答不出來也能說「課本沒寫」。
那個「幫忙翻書、把相關頁面攤開」的動作，就是 RAG 的核心——檢索（Retrieval）。模型再根據翻到的內容**生成（Generation）**答案，合起來就是「檢索增強生成」。
而「怎麼判斷哪幾頁跟題目最相關」，靠的是把文字轉成向量、比對語意距離的技術。這套底層機制如果想徹底搞懂，建議讀 AI 嵌入向量（Embedding）一次搞懂，它是整個檢索能不能撈準的根。
下面用一張表，對照三種做法的差異：
| 做法 | 資料來源 | 更新方式 | 幻覺風險 | 適合場景 |
|---|---|---|---|---|
| 通用模型直接問 | 模型訓練知識 | 需重新訓練 | 高 | 通用聊天、發想 |
| 微調（Fine-tuning） | 訓練進模型參數 | 重新微調，慢且貴 | 中 | 特定語氣/格式風格 |
| RAG（檢索增強生成） | 你的外部知識庫 | 更新文件即可 | 低 | 客服、內部問答、文件查詢 |
關鍵差異一句話：RAG 把「答案的依據」從模型腦袋裡，搬到你能隨時更新的知識庫裡。 資料是你的、可控的、可更新的，這就是它能壓低幻覺的根本原因。想把這套思路系統化成一座可長期維護的知識庫，可以延伸讀 AI 知識庫怎麼建。
實際教學：五步建出你的知識庫客服
下面以「中小企業電商客服」為例，帶你走完一輪。流程不綁特定工具，n8n、Dify、Coze 或自寫程式都套得上。
Step 1：整理你的資料來源
RAG 的品質上限，由你餵的資料決定。先把客服會用到的文件集中：
- 常見問題 FAQ、產品規格、退換貨政策、運費與物流說明、保固條款。
- 清掉過期與互相矛盾的內容。如果同一個問題在兩份文件答案不同，AI 也會混亂。
- 統一格式，盡量用「一個問題對一段清楚答案」的結構，檢索效果最好。
這一步沒有捷徑，垃圾進、垃圾出。整理資料佔了整個專案約六成的功夫，請務必認真對待。如果你連 FAQ 都還沒整理成型，建議先用 AI FAQ 產生器的方法 把第一版常見問答快速生出來，再來切塊。
Step 2：切塊（Chunking）與建立向量索引
文件太長不能整份丟進去，要切成一段段「chunk」。切太大，撈進來雜訊多；切太小，語意被切斷。實務上常用的起點是每段約 300 到 500 字，段落間保留少量重疊，避免句子被硬切。
切好後，用「嵌入模型（Embedding Model）」把每段文字轉成一串數字（向量），存進向量資料庫（如 Pinecone、Qdrant、pgvector）。你可以把向量想成「每段文字在語意空間裡的座標」，語意越接近的段落，座標越靠近。這個「轉座標」的步驟非常關鍵，選錯嵌入模型或沒做正規化，後面檢索全盤皆輸，背後原理在 AI 嵌入向量解析 講得最透。
Step 3：設計檢索流程
使用者一提問，系統就：
- 把問題也用同一個嵌入模型轉成向量。
- 拿這個向量去向量資料庫裡，找出座標最接近的前幾段（通常取 3 到 5 段）。
- 這幾段就是「課本攤開的那幾頁」，即將餵給模型。
這裡有個常被忽略的調校點：取幾段（Top-K）要測。取太少可能漏掉答案，取太多會塞進雜訊、稀釋重點。建議從 4 段開始，再依實測微調。
Step 4：組裝 Prompt，餵給模型生成答案
把撈到的資料當成「唯一可參考的來源」放進 Prompt，並明確下指令：只能依據這些資料回答。這一步的 Prompt 寫法是成敗關鍵，完整範例見下一節。寫不順手時，可以用我們的 Prompt 產生器 先生一版骨架再調整。
Step 5：加上引用與兜底規則
最後兩道保險，決定了客戶信任度：
- 引用來源：要求模型在答案後標出依據哪段資料，方便人工抽查與客戶查證。
- 兜底（Fallback）：知識庫裡找不到時，強制回覆「這部分我不確定，幫你轉接專人」，而不是讓它硬擠一個答案。寧可承認不知道，也不要編一個。
到這裡，一個會「照你的資料回答、答不出來會誠實轉真人」的客服雛形就成形了。如果你想用更完整的對話框架把這個雛形包成正式產品，可參考 AI 聊天機器人建置指南；想再進一步讓它能查訂單、發退款，可結合 MCP 讓 AI 接上你的系統工具，並參考 AI 客服代理實作。
範例：可複製的 Prompt 與 Workflow 流程圖
RAG 客服 Prompt 範本
下面這段是給模型的系統指令（system prompt），{{檢索到的資料}} 與 {{使用者問題}} 由你的程式或 n8n 動態填入：
你是「○○電商」的客服助理。請嚴格遵守以下規則回答顧客：
【最高原則】
1. 你只能根據下方「參考資料」回答，不得使用參考資料以外的任何知識。
2. 若參考資料中找不到答案，必須回覆：「這部分我不太確定，幫您轉接專人協助 🙏」，
嚴禁自行推測或編造。
3. 回答結尾以 [來源] 標註你依據的是第幾段參考資料。
【語氣】
親切、簡潔、用台灣口語的繁體中文，一次只回答顧客問到的問題。
【參考資料】
{{檢索到的資料}}
【顧客問題】
{{使用者問題}}重點在第 1、2 條：先用「只能根據參考資料」鎖死範圍，再用「找不到就轉專人」堵住亂編的出口。這兩句話就是把幻覺壓到最低的核心。想更系統地把這套回答風格、語氣、規則沉澱成可重用的資產，可參考 AI 知識庫的建立方法。
Workflow 流程圖（文字版）
顧客在官網／LINE 提問
↓
問題轉成向量（嵌入模型）
↓
到向量資料庫檢索最相關的 4 段資料
↓
有撈到相關資料？
├─ 有 → 把資料填進 Prompt → 模型依資料生成答案 → 附上 [來源] → 回覆顧客
└─ 沒有 → 回覆「不確定，幫您轉接專人」 → 通知客服人員接手
↓
記錄問答日誌 → 定期檢視常被轉真人的問題 → 補進知識庫最後那條「補進知識庫」的迴圈很重要：每一次「答不出來」都是知識庫的待辦清單。持續回填，系統會越用越聰明。更多可直接套用的自動化藍圖，看 工作流知識庫。
進階：更深入的一層
跑通基本流程後，多數人會卡在同一個地方——「答案明明在知識庫裡，AI 卻撈不出來」。這通常不是模型笨，而是檢索這一層沒調好。以下是把 RAG 從「能用」推到「好用」的四個進階手法。
第一，混合檢索（Hybrid Search）。 純向量檢索擅長抓「語意相近」，但對精確字詞（料號 SKU、型號、訂單編號）反而會漏。實務上最穩的做法，是把向量檢索（抓語意）和關鍵字檢索（抓精確詞，如 BM25）兩種結果合併再排序。顧客問「我的訂單 #A1729 到哪了」時，混合檢索才能準確撈到含該編號的那段。
第二，重排序（Reranking）。 第一輪先用向量寬鬆撈 20 段「候選」，再用一個更精準的重排序模型，從這 20 段裡挑出真正最相關的 4 段餵給模型。等於「先海選、再決選」，能明顯壓低雜訊。
第三，查詢改寫（Query Rewriting）。 顧客的問法常很口語、很省略，例如多輪對話裡只丟一句「那退款呢？」。在檢索前，先讓一個輕量模型把它補成完整問句「請問退款多久會退到我的帳戶？」，檢索命中率會大幅提升。這也是讓 RAG 客服能撐住多輪對話的關鍵。
第四，知道 RAG 的天花板在哪。 RAG 解決的是「拿到正確片段」，但它不會幫你做跨文件的複雜推理或多步驟任務。當問題需要「同時查三份文件再交叉計算」，單靠 RAG 會吃力，這時要往 多代理協作（Multi-Agent） 的架構走，讓不同 Agent 分工檢索與彙整。
下面把四種進階手法整理成對照表，方便你判斷該不該上：
| 進階手法 | 解決的痛點 | 上手難度 | 建議何時導入 |
|---|---|---|---|
| 混合檢索 | 料號/編號等精確詞撈不到 | 低 | 知識庫含大量代號時優先 |
| 重排序 | 撈進來的段落雜訊多、不夠準 | 中 | 基本檢索已通、要再拉高準確率 |
| 查詢改寫 | 多輪對話、口語省略導致漏答 | 中 | 客服要支援連續對話時 |
| 多代理協作 | 跨文件推理、多步驟任務 | 高 | 單純檢索已不夠用時 |
一個務實的順序是：先把混合檢索和兜底規則做好（投報率最高），準確率撞牆時再加重排序與查詢改寫，最後才考慮多代理。 不要一開始就把架構疊到最複雜，那只會拖慢上線又難維護。
常見錯誤
- 資料沒整理就上線：餵進過期、矛盾的文件，RAG 一樣會給錯答案，只是錯得「有根據」。
- Chunk 切太大或太小：整份文件當一塊，檢索撈不準；切到剩半句話，語意又斷裂。
- Prompt 沒鎖死範圍：少了「只能根據參考資料」，模型還是會偷用自己的知識亂補。
- 沒有兜底規則：讓模型「無論如何都要給答案」，等於默許它在沒資料時亂編。
- 檢索 Top-K 沒測就定：照預設值用，常常不是漏答案就是塞雜訊。
- 只用向量、不用混合檢索：料號、訂單編號這類精確詞一律撈不到，顧客一問就破功。
- 上線後不看日誌：不去分析哪些問題被轉真人、哪些答錯，知識庫永遠補不齊。
最佳實務
- 資料分層：把「政策類」（退貨、保固）和「商品類」（規格、庫存）分開索引，檢索更精準。
- 保留更新時間戳：每段資料標註最後更新日期，方便定期盤點過期內容。
- 關鍵答案保留人工確認：涉及金額、法律、退款等高風險回答，設成需專人覆核再送出。
- 小步快跑：先用最常見的 20 題 FAQ 跑通整套流程，驗證有效再擴充，別一開始就想塞完所有文件。
- 建立評測題庫：準備 50 到 100 題標準問答當「考卷」，每次改完設定都跑一遍，量化準確率有沒有進步，而不是靠感覺。
實際案例：台中電商「退貨詢問」客服改造
背景：台中一家經營居家用品的電商，每天 LINE 官方帳號湧入大量詢問，其中近半是重複的退換貨、運費、出貨時間問題。三人客服小組整天在複製貼上罐頭回覆，下班後的訊息累積到隔天，常被客訴「已讀不回」。
導入前：
- 平均首次回覆時間：約 4 小時（離峰）至隔日（夜間）。
- 客服每天約 35% 工時花在回答重複問題。
- 曾發生工讀生記錯退貨天數、回覆錯誤政策的客訴。
導入做法：他們用 n8n 串接向量資料庫，把 FAQ、退換貨政策、運費表共約 60 份文件切塊建索引，套上前面那組 Prompt，接到 LINE 官方帳號。設定找不到答案就自動轉真人並標記，並每週檢視被轉真人的問題回填知識庫。
第二個月的進階優化：上線後他們發現一類問題老是答不準——顧客丟訂單編號問進度，純向量檢索撈不到。於是他們加上混合檢索，把訂單編號用關鍵字精確比對；同時補上查詢改寫，處理「那退款呢？」這種多輪省略句。這兩個小調整，讓原本約 12% 該答而漏答的問題降到 3% 以下。
導入後（上線兩個月）：
- 約 七成五的常見詢問由 AI 直接答完，無需真人介入（第一個月為七成，加上進階檢索後再升一級）。
- 平均首次回覆時間從數小時縮短到數秒（常見題）。
- 客服重複問題工時下降約 35%，人力轉去處理客訴與選品等高價值工作。
- 因為答案全來自統一知識庫，回覆錯誤政策的客訴歸零。
- 每月省下的客服工時，換算約等於多出半個人力，相當於一名兼職客服的成本。
關鍵不是「上了 AI」，而是「上了一個只敢照公司資料回答、不懂就誠實轉真人的 AI」，並且持續用日誌回填、用進階檢索補強。這正是 RAG 的價值。需要協助評估自家場景，可以直接 與我們聯絡。
免責聲明：本文數據為示意性的台灣中小企業情境，實際成效因資料品質、流量、工具與調校而異，導入前請以自身情況評估，並對涉及金額、法律與退款等高風險回答保留人工查核。
結論
RAG 的精神可以濃縮成一句話：與其逼 AI 背下你的公司，不如讓它開書考試。 它不改模型、不必重訓，只要把正確資料整理好、檢索進來、用 Prompt 鎖死範圍、再加上引用與兜底，就能把「一本正經胡說八道」的通用 AI，變成「只照你資料回答」的可靠客服。
落地的順序也很清楚：先整理資料（最花功夫但最重要）→ 切塊建索引 → 設計檢索 → 寫好鎖範圍的 Prompt → 加引用與兜底 → 看日誌持續回填，準確率撞牆時再上混合檢索與重排序。從 20 題 FAQ 的小範圍開始驗證，跑通了再擴大，是風險最低的路。
下一步該往哪走，就看你的目標：想讓客服長出「查訂單、發退款」的真本事，去了解 MCP 如何讓 AI 連上你的系統工具 與 AI 客服代理的完整實作；還在猶豫要 RAG 還是微調，先讀 微調 vs RAG 的取捨 再決定。
❓ 常見問題 FAQ
RAG 是什麼的縮寫？
RAG 和直接把資料貼進 Prompt 有什麼不同？
RAG 真的能完全消除 AI 幻覺嗎？
建一個 RAG 知識庫客服需要會寫程式嗎？
知識庫資料更新了，RAG 需要重新訓練嗎？
RAG 和微調（Fine-tuning）到底該選哪一個？
我的資料很多是表格和 PDF，RAG 處理得了嗎？
怎麼知道我的 RAG 系統到底準不準？
🔗 延伸閱讀
- AI Agent 是什麼？從入門到實戰
- MCP 是什麼？讓 AI 連上你所有工具
- AI 客服代理：用 Agent 接住第一線詢問
- 微調 vs RAG：該選哪一個？
- AI 嵌入向量是什麼？一次搞懂 Embedding
每週把這類實戰教學寄給你
訂閱 AgentAI 智庫情報週報，新的 Prompt、AI Skills、工作流與教學第一時間收到。
免費 · 隨時取消