RAG 入門：API 不會被訓練，那要怎麼讓 AI 根據公司文件回答？

在〈向老闆解釋 API 不會被訓練的兩年〉裡，我提到 API 就像每次見面都會失憶的顧問：什麼都懂，但不記得你們公司。

那問題來了：如果希望 AI 能回答「我們的退貨規則是什麼」「這台機器的錯誤代碼 E07 怎麼處理」，又不想（也沒辦法）訓練模型，該怎麼辦？

最常見的答案就是 RAG。

RAG 是什麼？用「開書考」來理解

RAG（Retrieval-Augmented Generation，檢索增強生成），名字很長，概念其實很簡單：

AI 不用把公司文件背起來。每次有人問問題，系統先去文件裡找出相關的段落，再把這些段落和問題一起交給 AI，請它根據資料回答。

就像開書考：考生不用背整本課本，考試時翻到相關的那幾頁，看著內容作答就好。AI 的「理解和表達能力」負責作答，「答案依據」則來自你提供的資料。

RAG 的運作流程

RAG 分成兩個階段：事前準備和回答問題。

事前準備・把文件整理成可搜尋的資料庫

公司文件▶ 轉成純文字▶ 切成小段落▶ 轉成向量存起來

文件有更新時，只要重新處理那一份就好

回答問題・每次提問都會跑一次

使用者提問▶ 找出相關段落▶ 段落＋問題交給 AI▶ 附來源回答

AI 只看到和這個問題有關的幾段內容，不是整個資料庫

幾個名詞先搞懂

名詞	白話說明
切段（Chunking）	把長文件切成一段一段，例如每段幾百字，方便只取出需要的部分
向量（Embedding）	把一段文字轉成一串數字，意思相近的文字，數字也會相近
向量資料庫	專門存向量、能快速找出「意思最接近」的段落的資料庫
檢索（Retrieval）	根據使用者的問題，找出最相關的幾段內容
重新排序（Rerank）	找出候選段落後，再用另一個模型挑出真正最相關的幾段
引用來源（Citation）	回答時標示依據的是哪份文件、哪一段

向量搜尋的厲害之處，在於它比對的是意思而不只是字面。使用者問「東西壞了可以退嗎」，即使文件裡寫的是「商品瑕疵退換貨規定」，也找得到。

RAG 和其他做法比較

要讓 AI 根據公司資料回答，RAG 不是唯一選擇：

做法	怎麼做	適合	限制
直接放進提示詞	每次把整份文件貼進去	文件很少，例如幾頁 FAQ	文件一多就塞不下，而且每次都要付全部內容的費用
長上下文＋快取	利用大上下文模型一次放大量文件，搭配上下文快取省錢	文件量中等、不常變動	文件持續增加時成本和速度會變差
兩段式 AI 路由	先用便宜模型判斷要看哪份知識檔，再把那份檔案和問題交給 AI 回答	知識可以整理成幾份到幾十份主題文件	判斷錯檔案就答不出來，主題文件太多時不好選
RAG（向量檢索）	用向量搜尋從大量段落中找出相關內容	文件多、常更新、需要附來源	要建資料流程，檢索品質決定回答品質
微調	用範例資料調整模型本身	要固定的語氣、格式或分類行為	不適合用來「記住」會變動的知識，成本高

這裡要特別強調：微調比較像是在教 AI「怎麼說話」，RAG 才是讓 AI「知道最新的事實」。公司的產品規格、價格、規定隨時在變，用 RAG 更新一份文件就好，不用重新訓練。

我的看法：做 RAG 之前先想清楚的五件事

1. 文件不多，先別急著上向量資料庫

很多團隊一聽到 RAG，就開始研究要用哪套向量資料庫。但如果你的文件只有幾十頁，直接整份放進提示詞，再搭配上下文快取，通常就夠用了，而且效果往往更好，因為 AI 能看到完整內容，不會漏掉沒被檢索到的段落。

文件再多一點、整份放不下的時候，也還不一定需要向量資料庫，可以先試試下一段介紹的「兩段式 AI 路由」。向量檢索真正派上用場，是在文件多到連「選檔案」都很困難、內容經常更新、或需要控管誰能看什麼的時候。

2. 資料品質決定八成的結果

RAG 最常見的失敗，不是模型不夠聰明，而是資料本身有問題：

新舊版本的規定同時存在，AI 不知道該信哪一份
掃描版 PDF 只有圖片，根本取不出文字
表格轉成文字後欄位錯亂
重要資訊藏在圖片或附件裡

所以導入 RAG 的第一步，往往是整理文件：刪掉過期版本、把 PDF 轉成乾淨的文字（可以參考〈Claude Code 省 Token 技巧〉提到的 MarkItDown）、在文件裡標明版本與生效日期。

3. 中文和專有名詞，建議用混合搜尋

向量搜尋擅長找「意思相近」的內容，但對產品型號、料號、錯誤代碼這類字面完全要一樣的東西，反而不一定準。例如搜尋「E07」，可能會找到意思相近的「E08」。

實務上比較穩的做法是混合搜尋：同時做傳統的關鍵字搜尋和向量搜尋，再把結果合併排序。

4. 一定要附來源，而且允許它說「不知道」

RAG 的價值在於「有依據」，所以提示詞裡一定要要求 AI 引用來源，並且在資料不足時直接說找不到。例如：

請只根據 <資料> 中的內容回答使用者的問題。
- 每個重點後面標註來源文件名稱。
- 如果資料中找不到答案，請直接回答「目前的文件中沒有這項資訊」，不要自行推測。

<資料>
{檢索到的段落}
</資料>

使用者問題：{問題}

這比讓 AI 自由發揮安全得多，使用者也能自己點回原文確認。

5. 權限要在「檢索」時就處理

如果公司文件有分等級，例如主管才能看的薪資規定，不能只靠提示詞叫 AI「不要說」。正確做法是在檢索階段，就依照提問者的身分過濾掉他不能看的文件，讓 AI 根本拿不到這些內容。

不用向量資料庫的 RAG：兩段式 AI 路由

這是我自己在專案裡實際用的做法，也是我認為大多數中小型知識庫最划算的起點。

想法很簡單：與其把所有文件切碎、轉向量、建資料庫，不如先把知識整理成幾份主題明確的 Markdown 檔，再讓 AI 分兩段處理：

第一段・便宜的模型負責「選檔案」

使用者提問▶ 分析語意▶ 選出要看的知識檔

只看「檔案清單和說明」，不看內容，所以又快又便宜

第二段・主力模型負責「回答」

讀取選中的 md 檔▶ 知識＋問題包進 Prompt▶ 依據資料回答

AI 只拿到和問題有關的那幾份知識，回答更準、Token 也更少

第一步：把知識整理成主題檔案

例如一家手搖飲店的客服知識庫，可以整理成這樣：

knowledge/
├── 會員制度.md      # 點數規則、會員等級、生日禮
├── 退換貨規定.md    # 飲品瑕疵、做錯飲料、退款流程
├── 門市資訊.md      # 各門市地址、營業時間、公休日
├── 菜單與價格.md    # 品項、價格、甜度冰塊選項
└── 外送與訂購.md    # 外送平台、預訂、團購規定

再準備一份目錄，用一兩句話說明每份檔案在講什麼，這份目錄就是第一段 AI 選檔案的依據。

第二步：用便宜的模型選檔案

第一段只需要判斷語意，不需要很強的模型，用各家最便宜、最快的模型就夠了：

你是客服問題的分類助理。請根據使用者的問題，從下方知識庫目錄中，
選出回答時需要參考的檔案。

規則：
- 最多選 2 份檔案
- 如果問題和所有檔案都無關，回傳空陣列
- 只輸出 JSON，不要有其他文字

<知識庫目錄>
會員制度.md：點數怎麼累積與兌換、會員等級、生日優惠
退換貨規定.md：飲料做錯或有問題怎麼處理、退款方式與期限
門市資訊.md：各門市地址、營業時間、公休日
菜單與價格.md：所有品項與價格、甜度冰塊調整、加料選項
外送與訂購.md：外送平台、電話預訂、團購優惠
</知識庫目錄>

使用者問題：我的飲料少了珍珠，可以退錢嗎？

輸出格式：{"files": ["檔名.md"]}

AI 會回傳 {"files": ["退換貨規定.md"]}，程式再去讀取這份檔案。

第三步：把知識和問題包進 Prompt

第二段才用主力模型，把選中的檔案內容和使用者問題一起送出，回答的 Prompt 就和前面「附來源、找不到就說不知道」那段一樣。

這樣做，本質上就是 RAG：先檢索、再生成。只是「檢索」這一步，從向量搜尋換成了讓 AI 讀目錄來判斷。

檔案變大了？那就再切段

如果某份檔案越寫越長，例如「菜單與價格.md」有好幾十個品項，也不用急著換架構，可以再往下切一層：

依照 Markdown 的 ## 標題，把檔案切成段落
目錄改成列出「檔案＋段落標題」
第一段 AI 改成選「段落」，而不是選整份檔案

你會發現，這其實就是 RAG 的「切段」，只是切的依據是你自己定義的標題結構，人看得懂、也好維護。

這個做法的優缺點

	兩段式 AI 路由	向量資料庫 RAG
需要的基礎建設	幾份 Markdown 檔＋一份目錄	切段流程、Embedding、向量資料庫
維護方式	直接編輯 md 檔，改完立刻生效	文件更新後要重新處理、重建索引
除錯	看第一段選了哪個檔案，一眼就知道問題出在哪	要檢查切段、向量、相似度分數
檢索的聰明程度	由 AI 理解語意來判斷，連換句話說也能理解	依向量相似度，可能找到字面像但不相關的段落
成本	每次多一次便宜模型的呼叫	每次多一次 Embedding 計算與資料庫查詢
規模上限	知識檔數量多到目錄放不下、AI 難以判斷時就會吃力	可以處理大量文件

要注意的地方

選錯檔案就答不出來：這是最大的風險。可以讓第一段最多選 2～3 份檔案增加容錯，並且把每次選了哪個檔案記錄下來，定期檢查。
目錄的說明要寫好：第一段 AI 完全靠目錄判斷，說明寫得越具體，選得越準。這也是為什麼要用使用者會說的話來寫，例如寫「飲料做錯怎麼辦」，而不只是「退換貨政策」。
知識檔可以搭配快取：同一份知識檔常常被重複使用，搭配上下文快取可以再省一筆費用。

什麼時候該升級成向量資料庫？當知識檔多到目錄本身就很長、AI 開始常常選錯，或是文件數量會持續大幅成長（例如幾千份歷史客服紀錄）時，再考慮換成向量檢索也不遲。很多時候，兩段式路由就能撐很久。

導入 RAG 的四個階段

不需要一開始就自己從零打造：

階段	做法	適合
1. 先用現成工具驗證	把文件上傳到 ChatGPT、Claude 的專案功能，或 NotebookLM 這類工具，直接試問	先確認「AI 根據這些文件回答」到底有沒有用
2. 兩段式 AI 路由	把知識整理成主題 md 檔，用便宜模型選檔案、主力模型回答	知識量中等，想用最少的基礎建設上線
3. 使用雲端託管的檢索服務	各大雲端和 AI 平台都有提供文件檢索服務，上傳文件、呼叫 API 即可	要整合進自己的系統，但不想自己維護檢索流程
4. 自己建置向量檢索	自己處理切段、向量化、資料庫、檢索與排序	有特殊需求、資料不能外流，或要高度客製

我的建議是一定要從第一階段開始，確認有效之後，大多數情況走到第二階段就夠用了。很多時候試了才發現，真正的問題是文件太亂，而不是缺一套向量資料庫。

怎麼知道 RAG 做得好不好？

RAG 最怕的是「感覺好像可以」。建議準備一份測試題庫：

收集 30～50 個真實會被問到的問題
為每一題寫好標準答案和應該引用的文件
每次調整切段方式、檢索數量或提示詞後，都把整份題庫跑一次
檢查：有沒有找到對的文件？答案正不正確？找不到時有沒有老實說？

有了題庫，優化才有依據，不然每次修改都只是憑感覺。

常見問題速查

症狀	可能原因	解法
回答牛頭不對馬嘴	檢索到的段落不相關	調整切段大小、加入關鍵字搜尋、加入重新排序
回答只有一半	答案被切到兩個段落	段落之間保留重疊，或增加取回的段落數量
回答了舊規定	新舊文件並存	刪除過期文件，或在資料中標註生效日期
明明有資料卻說找不到	使用者用詞和文件差很多	混合搜尋、在文件中補充常見說法
自己編答案	提示詞沒限制	要求只能根據資料回答，找不到就說不知道

結語

RAG 的本質，其實就是我在 API 那篇文章說的：AI 不需要被訓練，而是每次都把對的資料帶給它。RAG 只是把「帶資料」這件事自動化、規模化。

如果你正打算讓 AI 回答公司內部的問題，與其先煩惱要選哪套向量資料庫，不如先把文件整理成幾份主題清楚的 Markdown 檔、準備一份測試題庫，再用兩段式 AI 路由跑跑看。這幾件事做好了，RAG 就成功了一大半。