RAG 不是搜尋框：它其實是在幫模型補「可驗證的上下文」
很多人第一次聽到 RAG，會把它想成「幫 ChatGPT 接一個搜尋框」。
這個理解可以拿來入門，但如果你真的要做產品，這句話會害你。因為搜尋框只負責找資料，RAG 要處理的是另一件更麻煩的事：在模型回答前，把正確、夠新、夠完整、可引用的上下文放到它面前。
RAG 這個詞最常被追到 2020 年 Meta / FAIR 那篇 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks。那篇 paper 的重點不是「向量資料庫很酷」，而是 parametric memory 和 non-parametric memory 的分工。模型參數裡有一部分世界知識，但這些知識更新慢、來源不透明，也很難精確改掉。外部檢索系統則可以放最新文件，還能提供 provenance，也就是「這句話根據哪裡來」。
放到今天的產品語境，RAG 解的其實是三個問題。
第一，模型不知道你的私有資料。
你的退款政策、產品限制、客戶合約、內部 SOP，不會自動存在模型裡。就算你把資料貼進 prompt，資料一多也不可能每次全塞。RAG 是把「需要時才拿相關資料」做成系統。
第二，模型知道的東西可能過期。
產品價格改了、API 參數改了、競品功能改了，模型不會因為你網站更新就自動更新。這也是為什麼 OpenAI 自己的文件把 retrieval / file search 放在 tools 裡，而不是只靠模型本體記憶。OpenAI retrieval guide 和 file search docs 都把它當成讓模型存取外部知識的工具層。
第三，模型需要被逼著引用資料。
如果你只是問「請根據資料回答」，模型還是可能把資料和常識混在一起。真正的 RAG 系統要讓每個關鍵結論都能回到 chunk、文件、URL 或版本號。不然它講得再順，你也不知道哪句是查到的，哪句是補的。
RAG 的基本流程其實很土
不要被框架嚇到。
一個最小 RAG，大概就是：
- 把文件轉成乾淨文字
- 切成 chunk
- 幫 chunk 做 embedding
- 使用者提問時，把問題也做 embedding
- 找出相近 chunk
- 必要時 rerank
- 把最後幾段塞進 prompt
- 要求模型只根據 context 回答
- 回答時附來源
這裡面沒有魔法。比較接近一條很脆弱的資料管線。
Embedding 只是把文字轉成向量，方便做語意相似度搜尋。OpenAI 的 embeddings docs 也講得很白：embedding 適合用在 search、clustering、recommendations、classification。它不是事實驗證器。向量距離近，只代表語意像，不代表那段就是答案。
這也是很多 RAG demo 上線後爆掉的原因。
使用者問：「Enterprise plan 可以退費嗎？」
系統找到了「Enterprise plan payment terms」、「refund policy」、「billing FAQ」。看起來都相關。但真正答案可能在 sales contract 裡一段很短的 exception。你如果只拿 top 3 vector search 給模型，它就會用最像答案的那段硬答。
Chunk 不是越細越好
很多教學會給一個固定 chunk size，比如 500 tokens 或 1000 tokens。
這種數字可以當起點，但不能當信仰。
FAQ、產品文件、API docs 可以切短一點，因為問題通常集中。法律文件、研究報告、財報、合約條款則不能亂切。你把條件、例外、定義拆開，模型就會只看到半個規則。
比較好的做法是先照文件結構切：標題、章節、段落。太長再拆。每個 chunk 也不要只存 text，要存 metadata：title、section、source URL、updated_at、doc_version、owner。
很多 RAG 不是壞在模型，是壞在你把文件切成一堆沒有身份的碎肉。
Rerank 是 demo 和產品的分界線
單純向量搜尋通常只做 recall。它先把「可能相關」的東西撈上來。
但要不要放進 prompt，最好再經過 rerank。Cohere 的 rerank docs 就是這個思路：先召回一批候選，再用更適合 relevance ranking 的模型重排。這會多一點成本和延遲，但能減少「語意很像但不是答案」的情況。
實務上可以先 top 20 retrieval，再 rerank 到 top 5。不要一開始就 top 3 直接丟給模型。
最重要的功能：拒答
RAG 系統最危險的不是找不到答案。
最危險的是找不到答案還回答。
所以 prompt 裡要明確寫：如果 context 沒有答案，就說資料不足。流程上也要設門檻：retrieval score 太低、來源版本太舊、結果互相矛盾、沒有可引用來源，就不要硬答。
這件事對 SEO 內容也一樣。
如果你用 RAG 產教學文，資料裡沒有實測，你就不要寫「實測證明」。資料裡只有官方 docs，就不要假裝自己用過。現在 Google 對 helpful content 和 review quality 一直強調第一手經驗、證據、比較方法、原創資訊，官方文件也明講內容要對人有幫助，而不是只為搜尋引擎製作。Google helpful content guidance 其實跟 RAG 的精神很接近：不要用漂亮文字包裝空資料。
結論
RAG 不是搜尋框。
它比較像模型回答前的資料稽核流程：找資料、挑資料、引用資料、拒絕亂答。
如果你只做 vector search + prompt，會得到一個很會講話的知識庫玩具。如果你加上 metadata、rerank、版本控制、引用和拒答，才開始像能上線的系統。
所以做 RAG 時不要先問「用哪個框架」。
先問：模型回答前，它到底看到了什麼？這些東西夠不夠？如果不夠，它會不會閉嘴？
這三個問題，比你用 Pinecone、pgvector、Qdrant 還重要。