導入 RAG 之前，這 5 個問題沒想清楚就別急著動手
先說結論
- 資料安全不是配角：RAG 的知識庫往往比模型本身更敏感，搞錯存取控制就等著出事
- 準確率跟成本是蹺蹺板：chunk 切得越細、rerank 做越多，準確率越高，但 latency 和費用也一起爬
- 沒有評估機制的 RAG 就是黑箱：部署之後如果不持續量化表現，你根本不知道它什麼時候開始爛掉
你的資料放哪、誰能看，想清楚了嗎？
這是很多人跳過的第一步。RAG 架構的核心是一個向量資料庫，裡面存的是你把企業文件 embed 之後的向量——但不代表原始文字就消失了。多數架構還是會把 source chunk（原文片段）一起存著，方便做 citation。
問題來了：如果你的知識庫混了財務報告、HR 政策和產品技術文件，你的 retrieval 有沒有做 row-level access control？員工 A 問問題，系統會不會把只有高管才能看的文件片段一起撈出來丟給 LLM？
這在 SaaS 產品更複雜——你可能要對每個租戶隔離向量空間，或者在 retrieval 階段動態過濾 metadata。Pinecone、Weaviate 都有支援這類過濾，但架構設計要提前想好，不是事後能輕鬆補的。
另一個常被忽略的點：LLM API 呼叫。如果你用的是 OpenAI 或 Anthropic 的 API，那 retrieved chunk 的內容是會被送出去的。你的資料合規條款允許這件事嗎？有沒有把敏感欄位在送入 prompt 前先做遮蔽？
準確率的底線在哪裡，你們有沒有量過？
「RAG 比直接問 LLM 準確」這個說法是真的，但準確多少、夠不夠用，要看場景。
一個常見的誤區是：把 RAG 上線，然後用「感覺回答還不錯」來驗收。這不夠。RAG 系統的運作邏輯裡有個關鍵環節是 retrieval 品質——如果召回的 chunk 根本不對，LLM 再強也沒用，甚至會幻覺式地用錯誤文件片段編出一個聽起來很合理的答案。
建議在上線前至少要跑這幾個評估維度：
| 評估項目 | 說明 | 常用工具 |
|---|---|---|
| Retrieval Recall | 正確文件有沒有被召回 | RAGAS、自訂 eval set |
| Answer Faithfulness | 答案有沒有忠實反映 retrieved 內容 | RAGAS |
| Answer Relevance | 答案有沒有真正回答問題 | LLM-as-judge |
| Latency P95 | 第 95 百分位的回應時間 | 自己打壓力測試 |
沒有這些數字，你不知道「夠不夠好」，也不知道改了哪個參數之後是進步還是退步。
成本結構長什麼樣，你算過嗎？
RAG 的成本不只是 LLM API token 費用，全鏈路拆開來大概長這樣：
- Embedding 費用：初次建索引 + 文件更新時的增量 embed，文件量大的話這塊不小
- 向量資料庫費用：Pinecone、Qdrant Cloud 依向量數量和查詢量計費，自建的話是 infra 成本
- Reranker 費用：如果你上了 Cohere Rerank 或類似服務，每次查詢都有額外費用
- LLM API 費用：Retrieved chunk 通常讓 context window 膨脹，token 用量比純對話高很多
- 維護人力：chunk 策略調整、資料更新 pipeline、評估跑批，這些都要工程時間
一個中型企業的知識庫（假設 50 萬份文件、每天 1 萬次查詢），月費很容易超過台幣 15-30 萬，要事先估清楚。
查詢延遲你能接受多高？
這個問題直接影響架構選型。RAG 的全鏈路包含：embedding query → vector search → rerank（可選）→ LLM generation，每個步驟都有延遲。
如果你的場景是內部知識問答，用戶等個 3-5 秒可以接受。但如果是客服 bot 或嵌在工作流程裡的自動化 agent，超過 2 秒就會讓體驗變差。
幾個降延遲的常見做法：
- 向量搜尋用 ANN（近似最近鄰）而非精確搜尋
- Reranker 只對 top-k 做，不要全量過
- 如果 query 類型重複性高，考慮 semantic cache（把相似問題的回答暫存起來）
- LLM 選用比較小但夠用的模型，或者用 streaming 輸出改善感知速度
不過這裡又回到蹺蹺板問題——每個降延遲的手段幾乎都會犧牲一點準確率或彈性，要在 benchmark 上看數字決定，不要靠直覺。
誰來維護這個系統，維護頻率怎麼定？
RAG 不是部署完就結束的系統。知識庫要更新、chunk 策略可能要調整、embedding model 可能要升版（升完要重建索引）、評估 pipeline 要定期跑。
你得想清楚：
- 誰負責知識庫的資料治理（過時文件要怎麼處理？）
- 有沒有自動偵測「回答品質下滑」的機制，而不是等用戶投訴
- embedding model 如果從 text-embedding-ada-002 換到新版，遷移計畫是什麼
這個問題的重要性經常被低估。很多企業第一版 RAG 上線很順，三個月後知識庫沒人維護、舊文件沒清掉，準確率慢慢爛掉，但沒人發現——因為也沒人在量。這種情況跟 AI agent 系統缺乏有效管控的問題有點像，部署之後就以為沒事了，直到出問題才回頭看。
情境案例：一家製造業導入 RAG 的踩坑過程
某台灣製造業客戶在 2025 年底導入 RAG，目標是讓工程師能快速查技術文件。初期的問題是 chunk 切太大（每段 1000 tokens），導致 retrieval 精準度低；後來改成 512 tokens + overlap，準確率明顯提升。
但真正的坑在資料更新：他們的技術文件每季更新，但沒有建 incremental update pipeline，導致舊文件和新文件並存在向量庫裡，LLM 有時會引用已過時的規格。最後花了兩個月補建資料版本管理，才把這個問題解掉。
教訓是：chunk 策略和資料生命週期管理，要在第一版就設計進去，不要留給「以後再說」。
延伸思考：RAG 解決了問題之後，下一個問題是什麼？
很多團隊在 RAG 跑起來之後，會開始問：「那我可以讓它主動去查、主動去做事嗎？」——這就是 agent 化的起點。但 agent 引入了更複雜的管控需求，尤其是工具呼叫和多步驟推理帶來的不確定性。
另一個方向是把 RAG 接上更結構化的知識圖譜（Graph RAG），讓它不只能查文件，還能推理實體之間的關係——這在法規合規、供應鏈分析等場景有明顯優勢，但實作複雜度也跳一個量級。
如果你正在評估整個 AI 工具堆疊怎麼選型，可以參考2026 年真正好用的 AI 工具推薦，裡面有依情境拆開的建議。
FAQ
Q：RAG 一定要用向量資料庫嗎？ A：不一定。小規模場景（幾百份文件）可以用 BM25 全文搜尋就夠了，甚至直接放 in-memory。向量資料庫的優勢在語意搜尋，適合文件量大、查詢措辭多樣的場景。規模小的時候上向量庫反而是過度工程。
Q：Embedding model 要怎麼選？ A：先看語言支援——如果你的文件是繁中，OpenAI 的 text-embedding-3-large 或 Cohere Embed v3 支援多語言，效果都不錯。如果有隱私考量不想走 API，可以用 BGE 系列的本地部署版。選完之後一定要在自己的資料集上跑評估，不要只看排行榜。
Q：RAG 跟 fine-tuning 要怎麼選？ A：白話講：RAG 解決的是「讓模型知道新知識」，fine-tuning 解決的是「讓模型改變行為風格或學會特定格式」。如果你的問題是「模型不知道我們公司的產品規格」，用 RAG；如果問題是「模型回答風格跟我們品牌不符」，才考慮 fine-tuning。兩者也可以並用。
Q：RAG 系統上線後怎麼知道它在變差？ A：最實際的做法是在 production 裡加 thumbs up/down 的 feedback 機制，配合定期跑 offline eval set。也可以用 LLM-as-judge 自動評分每次回答的 faithfulness，超過閾值就觸發警報。沒有監測機制的 RAG，就算在爛你也不會知道。
Q：文件更新很頻繁，向量庫維護成本會不會很高？ A：關鍵是設計好 incremental update 流程，不要每次全量重建。大多數向量資料庫支援 upsert——你只需要把新增或修改的文件重新 embed 並更新對應向量，舊的不動。文件有版本號或 hash 的話，偵測「哪些需要更新」就更省力。
常見問題
RAG 一定要用向量資料庫嗎？
不一定。小規模場景（幾百份文件）可以用 BM25 全文搜尋就夠了，甚至直接放 in-memory。向量資料庫的優勢在語意搜尋，適合文件量大、查詢措辭多樣的場景。規模小的時候上向量庫反而是過度工程。
RAG 跟 fine-tuning 要怎麼選？
白話講：RAG 解決的是「讓模型知道新知識」，fine-tuning 解決的是「讓模型改變行為風格或學會特定格式」。如果你的問題是「模型不知道公司產品規格」，用 RAG；如果是「回答風格跟品牌不符」，才考慮 fine-tuning。兩者也可以並用。
RAG 系統上線後怎麼知道它在變差？
最實際的做法是在 production 加 thumbs up/down feedback 機制，配合定期跑 offline eval set。也可以用 LLM-as-judge 自動評分每次回答的 faithfulness，超過閾值就觸發警報。沒有監測機制的 RAG，就算在爛你也不會知道。
文件更新很頻繁，向量庫維護成本會不會很高？
關鍵是設計好 incremental update 流程，不要每次全量重建。大多數向量資料庫支援 upsert——只需要把新增或修改的文件重新 embed 並更新對應向量，舊的不動。文件有版本號或 hash 的話，偵測哪些需要更新就更省力。
Embedding model 要怎麼選？
先看語言支援——繁中文件的話，OpenAI 的 text-embedding-3-large 或 Cohere Embed v3 支援多語言效果不錯。若有隱私考量不想走 API，可以用 BGE 系列本地部署版。選完之後一定要在自己的資料集上跑評估，不要只看排行榜。
分享這篇
