RAG 的定義
RAG 是 Retrieval-Augmented Generation 的縮寫，中文常譯成檢索增強生成。做法分兩步：先從企業自己的資料裡找出跟問題相關的內容，再把這些內容交給語言模型，並要求模型根據內容回答。
這個詞出自 2020 年 Lewis 等人的原始論文，論文裡的資料來源是維基百科的向量索引。現在一般講 RAG，指的是先查資料、再生成答案這個結構，查資料那一步用什麼技術，並沒有規定。
老闆問的是怎麼確保模型不亂講，RAG 這三個字回答不了。RAG 只保證模型看過資料，不保證照資料講。看完資料的模型，仍可能多加一句、改掉數字，或把「許多」說成「一律」。
重點在答案能對回原文，不在資料庫的選擇
採購時常提出的問題是該用哪一種向量資料庫。順序要反過來，先確認：模型講的每一句話，都要能指回原文的某一段。指不回去，使用者無從查證，企業也無從負責。
開發團隊實作的資料問答服務，語料是使用者撰寫的長文件 PDF，共約 1,600 份，原始檔約 9GB，最後整理成約 1.3 萬則逐字節錄。
這個專案沒有用向量資料庫。
也沒有做 embedding。這個服務靠的是檢索之後的那一層驗證。
逐字驗證：模型挑片段，程式比對，對不上就丟
開發團隊把工作切成兩半：
- 模型讀整份文件，挑出一字不改的連續片段。
- 程式把原文和片段各做一次 NFKC 正規化，去掉所有空白，再用字串搜尋在原文裡定位。
- 找不到的丟掉。長度不足 10 字的也丟掉。
實際跑過的一輪：約 1,600 份文件，模型輸出約 1.5 萬則片段，通過約 1.3 萬則，丟掉的約占一成，沒有整份失敗的文件。以上為輸出紀錄加總後取的約略值。沒有這道比對，被丟掉的這些會原樣進到答案裡。
- 長文件 PDF約 1,600 份
- 模型挑片段約 1.5 萬則
- 程式比對原文正規化後用字串搜尋定位
- 對不上就丟掉約一成含不足 10 字的
- 通過約 1.3 萬則
實跑一輪的約略值。
整條流程的分工
這個服務依使用者選的條件產出一份報告，流程如下。模型不碰資料庫，只看得到程式給的資料包。
| 步驟 | 內容 | 執行者 |
|---|---|---|
| 拆題 | 把問題拆成要查的項目 | 模型 |
| 取資料 | 依條件從資料庫與靜態檔案取出資料包 | 程式 |
| 比對 | 用門檻比對資料 | 程式，不呼叫 AI |
| 寫作 | 根據資料包寫成句子 | 模型 |
| 驗證 | 檢查出處與數字，不合格整句拿掉 | 後端驗證層 |
對不上的時候
- 數字：全是占位符，由程式從資料填值。模型自己寫的任何數字，阿拉伯數字或國字都一樣，整句拿掉。
- 出處：每一句都要標明引用哪一筆資料。找不到出處，或數字對不上，整句拿掉。
- 原文：模型只回節錄的編號，原文由前端即時讀取。報告只存編號，資料下架後，引用就跟著消失。
同一批工作裡，開發團隊另做過一個客服問答版本，規則更嚴。要點裡的數字必須出現在引用的來源或使用者的問題裡。驗證失敗，帶著原因重試一次；再不過，只拿掉有問題的要點。要點全被拿掉，就不硬答，回「還沒整理好」並轉人工。
這個版本的檢索是 BM25 這種關鍵字計分，加上同義詞展開。信心門檻由測試題量出來，放在應答得出的題目最低得分，和不該答的題目最高得分之間。得分不夠，就列出最接近的幾題，轉人工。
- 關鍵字計分BM25 加同義詞展開
- 對照信心門檻由測試題量出來
- 驗證要點數字須在來源或問題裡
- 得分不夠列出最接近的幾題轉人工
- 驗證失敗帶原因重試一次仍不過就拿掉問題要點
- 要點全被拿掉回「還沒整理好」轉人工
客服問答版本的流程。
需要向量檢索的情況
關鍵字比對的弱點，是使用者的說法和原文用字不同就找不到，同義詞表能補一部分，但要有人維護。出現下面的情況，才值得評估向量檢索：
- 使用者的問法和原文用字差很遠，同義詞表追不上。
- 語料很大，寫法又不統一，沒辦法預先整理成問答。
就算換成向量檢索，變的只是找資料那一步。模型挑的片段能否對回原文，仍然由程式比對決定，和檢索用什麼技術無關。
價格不讓模型決定
乖獸廚房的 AI 方案生成用的是同一個原則：模型不負責事實。
計價方式、每人價格、附加服務，都由後台的規格決定。後端用後台規格覆蓋模型輸出，菜的道數超過規格上限就修剪。模型負責的是方案名稱這類需要創作的部分。
給模型的資料先縮小。候選菜用 SQL 預先篩過：依日期推算季節，依場地判斷室內外，從描述判斷是否為素食。同類服務、價位與人數相近的過往案例，也放進提示詞。提示詞分段管理，每次修改都留版本，可以回滾。
資料問答的權限與個資
答錯是一種風險，答出不該公開的內容是另一種。上面那個服務的做法：
- 語料預設不公開，要有明確的狀態才放行。這個閘門在後端強制，不是只在畫面上隱藏。
- 明細只回遮罩後的識別碼。輸出時，信箱、識別碼、電話只遮那一串，其餘照原文。
- PDF 裡含可辨識人臉的照片先全部隱藏。交叉驗證的結果，含人臉的沒有漏網，沒有人臉的也沒被誤排除。
篩個資要用專門的人臉判定，不能拿照片內容分類代替。分類裡標成「人物合照」的有近 300 張，其實是空走廊。人臉判定是 AI 做的，開發團隊抽驗後認為可靠。
資料問答上線前的安全檢查，可以看弱點掃描與滲透測試的差別。
單份的成本與耗時
開發團隊的量測條件如下：2026-10-06，模型 claude-haiku-4-5，測試環境，使用真實金鑰，12 份文件。每份平均 0.0166 美元，已含驗證時的第二次模型呼叫；12 份合計 0.23 美元；每份耗時 12 到 32 秒。以上為測試環境的量測值。
實作上的幾個取捨
程式比對不夠時，寧可留空
把資料歸到某個類別時，程式先做初步比對。初步比對難免判錯，要靠複核改判；另有一批怎麼看都判不定。這一批讓欄位留空，不硬填。留空只是少一個欄位，填錯的資料會帶著錯誤被引用出去。
模型把「許多」寫成「一律」
模型整理要點時，會把原文的「許多」「原則上」寫成「無法」「一律」。語氣一變，意思就變了。開發團隊加了規則，要求保留來源的語氣。使用者主張原文寫法不同時，答案不直接否定，改成表示不確定。
日誌只能證明呼叫成功，不能證明答對
日誌裡的成功，只代表模型有回應、格式正確，答案正確與否看不出來。要確認答案是否正確，只能把答案對回原文或規格。
預先整理答案與即時回答的取捨
預先整理好的答案可以事先逐題審過，但換個問法就接不住。即時回答接得住各種問法，代價是每一句都要當下驗證。
不適合的情況
- 資料還沒整理。文件散在各人電腦，版本不一，沒人說得出哪份是最新。驗證只能對回企業提供的原文，原文互相矛盾，答案就會把矛盾講出來。先整理資料，再談 RAG。
- 只要通用問答。問題不依賴自有資料，例如寫信、翻譯、問常識，不需要 RAG，用通用模型就好。
- 答錯後果很重，又沒有人可以把關。逐字驗證擋得住模型編造，擋不住原文本身過時。
評估前的準備
已經有一批文件的話，先挑幾個使用者最常問的問題，各自附上認為正確的原文段落。有了這份對照，才談得出檢索與驗證的做法。可以直接聯絡開發團隊，也可以先看AI 服務。找廠商另見軟體外包廠商的評估與簽約前查核。
