RAG 是什麼？白話看懂
RAG 讓 LLM 先查文件再回答，能減少幻覺、補上引用，也更適合企業知識庫與即時資料。
RAG 讓大型語言模型先查文件，再根據資料回答，能降低幻覺，也方便加上引用來源。
說真的，這招很實用。LLM 很會講，但也很會唬爛。你丟給它一個問題，它可能講得像真的，結果細節全錯。
RAG，中文常叫檢索增強生成，就是把「先查資料」塞進回答流程。它不是讓模型變聰明，而是讓模型先看資料再開口。這對客服、內部知識庫、法務、醫療都很有用。
這篇就用白話拆給你看。你會看到它怎麼運作、為什麼大家愛用、又在哪些地方會翻車。
| 項目 | 數字 | 意義 |
|---|---|---|
| RAG 相關論文 | 2020 | 這個做法在學術界正式成形。 |
| Google Bard 錯誤事件 | 約 1000 億美元 | 一次答錯，市場反應很兇。 |
| Retro 模型規模 | 約 25 倍更小 | 檢索式設計可省很多參數。 |
| 資料形式 | Embeddings | 文字常先轉成向量再做搜尋。 |
RAG 為什麼會紅
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
LLM 的問題很直接。它不是資料庫。它記得訓練時看過的模式，卻不保證知道昨天更新的政策。你如果拿它來回答公司規章，錯一條就很麻煩。
RAG 的解法很土，但很有效。先去文件、網站、PDF、資料庫找相關內容，再把找到的片段丟給模型生成答案。模型就不是憑空猜，而是照著材料寫。
這也是為什麼很多團隊先做 RAG，再想微調。因為 retrain 一次很貴，文件更新卻很快。你不會想為了改一份 FAQ，就重跑整個模型訓練流程。
- 降低對舊訓練資料的依賴。
- 可把引用來源一起帶出來。
- 不用每次改文件就重訓模型。
- 可接 PDF、內網文件、網頁與資料庫。
RAG 的流程怎麼跑
講白了，RAG 就是兩段式。第一段是檢索。系統先把文件切成 chunk，轉成 embeddings，存進向量資料庫。第二段是生成。使用者問問題時，系統先找最相關的片段，再交給 LLM 回答。
這裡每一步都可能出包。chunk 切太大，搜尋不準。切太小，脈絡會斷。retriever 找到的資料如果不夠準，模型就會拿錯材料做回答。
所以很多產品不是只靠向量搜尋。它們會混合 sparse search、dense retrieval，還會加 reranking。因為真正上線時，最怕不是找不到，而是找錯。
“RAG is a way of improving LLM performance, in essence by blending the LLM process with a web search or other document look-up process to help LLMs stick to the facts.” — Ars Technica
Wikipedia 也提到，實務系統常加 query expansion、memory、rerank。這些不是裝飾，是補洞。因為純向量搜尋很常抓到「差不多」的段落，不一定是最有用的段落。
你可以把 RAG 想成考試作弊版的開書考。模型不是背答案，而是先翻書，再寫出看起來合理的內容。差別在於，書翻錯了，答案還是會錯。
RAG 最適合哪些場景
如果資料會一直變，RAG 就很香。像客服中心、產品文件、法規查詢、公司內部知識庫，這些地方都需要最新內容。模型靠訓練記憶很難跟上。
另一種適合的場景，是你需要交代來源。像法務、醫療、金融，使用者不只想要答案，還想看你根據哪份文件講的。這時候 citations 很重要，不然誰敢直接信。
但別把它想太神。RAG 只能讓模型更接近來源，不代表它一定懂上下文。如果你餵進去的資料本身就亂，模型還是可能一本正經地講錯話。
- 企業知識助理。
- 客服機器人。
- 法規與合約查詢。
- 醫療與研究摘要。
- 電商商品與庫存問答。
RAG 也有不少坑
第一個坑是檢索錯。你找到了文件，不代表找到對的段落。第二個坑是生成亂解讀。模型看到一段文字，可能會把說明文當結論，然後直接寫歪。
第三個坑是 prompt stuffing。很多系統把檢索結果塞到問題前面，希望模型優先看見。這招有用，但也很脆弱。順序、格式、截斷長度，都會影響答案品質。
第四個坑是評估難。你很難只看一個準確率，就知道整條管線有沒有問題。因為檢索、排序、生成，三段都會影響結果。
- 檢索準，不代表答案準。
- 引用有了，不代表內容對。
- chunk 切法會影響召回率。
- reranking 常常比模型本身更重要。
數字怎麼看這件事
Wikipedia 提到幾個很有感的數字。Google Bard 曾因 JWST 錯誤回答，引發約 1000 億美元等級的市值波動。這種錯法很貴，因為大家對 AI 失誤的容忍度很低。
另一邊，Retro 類型的設計顯示，檢索式架構可以用更小的模型做出接近的表現。文中提到的規模差距大約是 25 倍。這代表資料查詢和模型參數，不一定要硬拚。
但有個重點。Retro 是從設計階段就把 retrieval 放進去。RAG 則是比較像後掛式方案。前者整合更深，後者更容易接到現有系統。
- RAG 在 2020 年左右進入主流討論。
- Google Bard 錯答事件牽動約 1000 億美元市值。
- Retro 類架構可把模型做得小很多。
- RAG 比較適合快速接到既有產品。
RAG 背後的產業脈絡
我覺得 RAG 會紅，不是因為它高深，而是因為它夠務實。企業不想每週重訓模型。企業想要的是：文件更新後，系統隔天就能查到。
這也是為什麼向量資料庫、embedding API、reranker 這幾年一起爆。它們不是單獨在賣產品，而是在補 LLM 的缺口。你可以把它看成 AI 應用的基礎設施。
早期大家很愛講模型大小。現在很多團隊更在意資料管線。因為真正在意答案的人，不會問你模型有幾億參數，只會問你答得對不對，有沒有來源。
如果你要做一個真的能上線的 AI 助理，RAG 幾乎是基本功。沒有它，你很容易做出一個很會聊天、但一查就破功的系統。
接下來怎麼做
如果你正在評估 RAG，先別急著看 demo。先看它抓什麼資料，chunk 怎麼切，rerank 有沒有做，引用能不能回到原文。這些細節比模型名字更重要。
我會建議你先拿一組真實問題測。找 20 到 50 題就夠。看檢索命中率、答案正確率、引用可追溯性，再看延遲。很多系統 demo 很漂亮，上線後就開始漏氣。
說白了，RAG 不是萬靈丹。它是把 LLM 拉回資料現場的一種方法。做得好，它很穩；做不好，它只是把錯誤包裝得更像真的。
如果你要下一步，我建議先從一個小知識庫開始。先把檢索、引用、評估三件事做好，再談更複雜的 agent、工具調用和多輪記憶。