前言：關於這個系列

「從零打造 RAG 系統：檢索、生成與落地全紀錄」，會用 30 天的時間，把一套 RAG（Retrieval-Augmented Generation，檢索增強生成）系統從零開始建置的完整過程記錄下來——包含資料前處理、Embedding 與向量資料庫、檢索優化、生成與評估，一路到最後的落地部署。

在正式動手之前，第一天我們想先回答一個最根本的問題：為什麼我們需要 RAG？

LLM 很強，但它有一個致命傷

大型語言模型（LLM）在這幾年進步飛快，寫程式、寫文章、回答問題樣樣行。但只要用得夠久，你一定遇過這個狀況：

你問它一個具體的問題，它一臉自信地給你一個「聽起來很對，但其實是錯的」答案。

這個現象有個專有名詞，叫做 幻覺（Hallucination）。LLM 之所以會產生幻覺，本質上是因為它的運作方式：模型是透過在訓練資料中學習「文字之間的統計關係」，來預測下一個最可能出現的詞。它沒有一個內建的「事實資料庫」可以查詢，它只是在做「看起來很合理的接龍」。

幻覺常見的幾種情況：

• 知識過時：模型的訓練資料有截止日期，無法得知之後發生的事情
• 知識沒學到：訓練資料裡本來就沒有涵蓋到的內容（例如企業內部文件、私有知識庫）
• 記憶不精確：模型「記得」某個知識的大致輪廓，但細節（數字、人名、日期）記錯了
• 過度自信：模型不擅長說「我不知道」，遇到不確定的問題，還是會硬生出一個答案

對於閒聊或創意寫作，幻覺可能無傷大雅。但如果你要拿 LLM 做知識問答、客服系統、內部文件檢索這類需要「說真話」的應用，幻覺就是一個沒辦法忽視的問題。

兩種直覺的解法，以及它們的問題

面對這個問題，一般會想到兩種解法：

解法一：微調（Fine-tuning）

把企業自己的資料拿去微調模型，讓模型「記住」這些知識。

問題：

• 成本高、需要一定規模的訓練資料與運算資源
• 資料一旦更新（例如公司政策改了），就得重新訓練，維護成本高
• 微調後的模型仍然可能產生幻覺——因為知識還是被「壓縮」進模型參數裡，模型仍然是在「回憶」而非「查閱」

解法二：把所有資料塞進 Prompt

既然模型不知道，那乾脆把相關資料整段貼進 Prompt 裡，讓模型直接參考。

問題：

• Context window（上下文長度）有限，塞不下太多資料
• 就算 context window 夠大，塞入大量不相關的內容也會拉低生成品質、拉高成本與延遲
• 不可能每次都把「全部知識庫」貼進去

RAG：讓模型「先查資料，再回答」

這就是 RAG 要解決的問題。RAG 的核心概念其實很直觀：

與其要求模型「記住」所有知識，不如讓模型在回答之前，先去外部知識庫「查」相關的資料，再根據查到的資料來生成答案。

這跟人類解決問題的方式很像——遇到不確定的問題，我們不會硬凹答案，而是去查資料、看文件，再統整出回覆。

RAG 系統大致上分成三個環節：

1. Indexing（索引建立）：把知識庫的文件切分、轉換成向量（Embedding），存進向量資料庫，方便之後快速查詢
2. Retrieval（檢索）：使用者提問後，把問題也轉成向量，去向量資料庫中找出最相關的幾段內容
3. Generation（生成）：把檢索到的內容連同使用者的問題一起交給 LLM，讓模型根據這些「有憑有據」的資料來生成回答

用一張簡單的流程圖來理解：

使用者提問
    │
    ▼
問題轉向量 ──────► 向量資料庫（已預先建好索引）
    │                      │
    │              找出最相關的 K 筆資料
    │                      │
    ▼                      ▼
        組合成 Prompt（問題 + 檢索到的內容）
                │
                ▼
              LLM 生成回答
                │
                ▼
          回覆使用者（附上引用來源）

RAG 解決了什麼問題？

回頭對照前面提到的幻覺成因，RAG 的優勢就很清楚了：

而且相較於微調，RAG 有幾個明顯優點：

• 成本較低：不需要重新訓練模型，只需要維護知識庫
• 可追溯：可以清楚知道答案是根據哪份文件生成的，方便驗證正確性
• 即時更新：知識庫更新後，馬上就能反映在回答上，不用等重新訓練

當然，RAG 也不是萬靈丹，它有自己的挑戰——例如檢索不精準時反而會誤導模型、Chunking 策略設計不好會影響效果、多文件交叉引用的處理等等。這些正是我們接下來 30 天會一一拆解的內容。

這個系列接下來會怎麼走

明天開始，我們會先從整體架構切入，接著進入資料前處理、Embedding 與向量資料庫的建置，再一路做到檢索優化、生成品質評估，最後完成一套可以實際落地的 RAG 系統。整個系列大致規劃如下：

• Day 1-4：RAG 基礎與環境準備（今天在這裡）
• Day 5-9：資料前處理
• Day 10-14：Embedding 與向量資料庫
• Day 15-20：檢索優化
• Day 21-26：生成與評估
• Day 27-30：落地部署與總結

如果你也對 RAG 有興趣，歡迎跟著我們一起走完這 30 天，我們明天見！

參考資料方向（可依實際引用補充）：

• Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020)
• 相關 LLM 幻覺研究論文或技術部落格