RAG 是什麼:讓 LLM 讀你的資料

幾乎每家想導入 AI 的台灣企業，跑到第二週都會撞上這三個英文字：RAG。

通常是這樣：第一週老闆說「我們也要 AI 啊」，試了 ChatGPT 跑得不錯，叫團隊內部部署一套。第二週開始問題冒出來——「為什麼它不知道我們公司去年的銷售數字？」、「為什麼它答錯我們的退費政策？」、「能不能讓它讀我們 Notion 裡的所有文件？」

這時候技術 team 開始查資料，撞到一個詞：RAG。

RAG(Retrieval-Augmented Generation，檢索增強生成)是讓 LLM 在回答前先去檢索外部資料，把相關片段塞進 prompt，再生成答案的架構。它解決的是「模型訓練時不知道你公司資料」這個問題。

簡短版：RAG 是「讓 LLM 讀你的資料」最常見的方法。

RAG 解的問題

LLM 知道公開網路上的東西(到訓練 cutoff 為止)，但它不知道：

• 你公司內部的 SOP
• 你客戶的訂單紀錄
• 你產品 last week 的更新
• 你部門的 meeting note
• 你保固政策的精確條款

把這些資料 fine-tune 進模型？成本高、難更新、容易蓋掉模型原本的能力。

把資料全部塞進 prompt?context window 不夠、成本太貴、而且模型在長 context 容易迷路。

RAG 的折衷做法：每次回答前，先撈出最相關的幾段資料，只把那幾段塞進 prompt。 既不用改模型，也不用塞整個資料庫。

RAG 怎麼運作

標準流程分兩階段。

索引階段(一次性 / 定期更新):

公司文件 → 切塊(chunk) → 每塊算 embedding → 存進 vector database

查詢階段(每次使用者問問題):

使用者 query → 算 query 的 embedding → 在 vector DB 找最相似的 chunks
            → 把 chunks 塞進 prompt → LLM 讀完 chunks 生成答案

具體例子。使用者問「我們去年 Q3 的客戶滿意度多少？」：

1. 系統算這句話的 embedding(把句子變成向量)
2. 在 vector DB 比對，撈出 top 5 最相似的內部文件 chunks(可能是滿意度報告、會議紀錄、季度 review)
3. 把這 5 個 chunks 塞進 prompt:「根據以下資料回答：[5 個 chunks 內容] 問題：我們去年 Q3 客戶滿意度多少？」
4. LLM 讀完生成答案，並引用具體 chunk

整個流程使用者看不到。對使用者來說，就是「我問，它答」。

RAG 跟 Fine-tuning 差在哪

新手最常搞混。簡單分：

	Fine-tuning	RAG
解什麼問題	改模型風格、語氣、特定任務技能	讓模型能讀外部 / 即時資料
改什麼	模型參數	不改模型，改 prompt
更新成本	高(每次資料變動都要重 train)	低(改 vector DB 即可)
適合場景	模型「不會做某類任務」	模型「不知道某些事實」
典型用例	生成特定格式 JSON、扮演特定角色、學會繁中標點	客服查 FAQ、法務找條款、研究比對文獻

多數企業以為自己需要 fine-tuning，實際上需要 RAG。

理由：大部分企業的 AI 痛點不是「模型不會回答」，而是「模型不知道我們的事」。Fine-tuning 改不了這個——它讓模型「更會講話」，但不會讓它「知道更多事實」。

RAG 跟 MCP 差在哪

兩者都是讓 LLM 接外部資料，但路徑不同。

RAG 是 pull-based、提前索引。 把資料切塊、算 embedding、存好。查詢時撈最相似的塞 prompt。適合靜態或半靜態的大量文件(SOP、文獻、產品文件)。

MCP 是 push-based、即時呼叫。 模型決定要查什麼，呼叫 MCP server,server 回傳結果。適合動態的、需要最新數據的查詢(訂單、即時庫存、CRM、code repository)。

實際 production 系統常常兩者都用:RAG 處理文件知識，MCP 處理結構化系統。

2026 年 RAG 常見的坑

RAG demo 容易，跑得好不容易。常見錯誤：

Chunk 切錯。 切太碎(每塊 100 字)→ 失去上下文，模型看不懂。切太粗(每塊 5000 字)→ 一個 chunk 包好幾個主題，retrieval 抓不準。實務上 200-800 token、有重疊邊界的 chunk 通常較好。

Embedding 模型選錯。 OpenAI text-embedding-3-small 對英文好，對繁中一般。bge-m3、Cohere multilingual 等對多語言更好。在繁中場景一定要實測，別預設英文最強的模型在繁中也最強。

只用 vector search，沒做 hybrid。 純 semantic search 在「精確關鍵字查詢」上輸 BM25。production RAG 多半是 vector + keyword(BM25)+ rerank 三段式。

沒做 contextual chunking。 每個 chunk 單看可能失去上下文(「他在第三季提到」——他是誰？哪個公司？)。Anthropic 提出的 contextual retrieval 是把每個 chunk 加一段「這 chunk 屬於哪份文件、哪個段落」的描述後再 embed，大幅改善 retrieval 品質。

只評估 LLM 輸出，忘了評估 retrieval。 模型答錯，可能是 retrieval 沒抓到對的 chunk。要分開評估 retrieval recall@k 跟最終回答品質。

對台灣企業的判斷

如果你正在評估要不要做 RAG:

第一，先問你的痛點是「模型不會做」還是「模型不知道」。 如果是後者，RAG。

第二，先看你的資料品質。 Garbage in, garbage out。如果你的內部文件本身就過期、錯誤、沒結構，RAG 答出來的東西也會爛。先把文件整理好，RAG 才有意義。

第三，從低風險場景開始。 客服 FAQ、內部 knowledge base 查詢、文件摘要——這些任務即使答錯後果也不嚴重，適合 RAG 第一站。法務、醫療、合規等高風險場景再開始用，要有人類審核迴圈。

第四，別用「我們要做 AI」當 KPI。 用「客服處理時間從 8 分鐘降到 3 分鐘」、「員工找文件時間少 70%」這種具體 metric。RAG 的價值在它解的具體問題，不是它本身。

收尾

RAG 是 LLM 跟你的資料之間的橋。

它不是 sexy 的技術——沒有 emergent abilities、沒有「驚艷的對話能力」——但它是 2026 年企業 AI 落地最常用的架構。

下一篇 chronicle:Embedding 是什麼——RAG 為什麼能找到「相似」的 chunk，背後的數學基礎。

周詠晴（編輯：廖玄同），《RAG 是什麼:讓 LLM 讀你的資料》，矽基前沿 [Si]gnals，2026-04-25。https://signals.tw/articles/what-is-rag/