1.3 RAG 系統的核心架構

知道 RAG 是什麼之後，接著看它是怎麼組起來的。一個基本的 RAG 系統有兩個主角：檢索器和生成器，外加一個要事先做好的知識庫。

檢索器（Retriever）

檢索器負責「找」。它收到使用者的問題，從知識庫裡挑出最相關的幾段內容，交給下一步。

要判斷一段文字跟問題有沒有關係，不能只靠關鍵字比對，因為同一個意思可以有很多種說法。常見的做法是把文字轉成向量（vector），也就是一長串數字，用來代表這段文字的意思。意思相近的文字，向量也會比較接近。檢索器就是把問題也轉成向量，去找「最接近」的那幾段。

這部分會在第 2 章詳細介紹，包括向量怎麼來、怎麼計算接近程度、向量要存在哪裡。

生成器（Generator）

生成器負責「寫」，就是我們熟悉的 LLM。它收到的不再只是使用者的問題，而是一份問題加上參考資料的提示詞，然後根據這些資料寫出通順的答案。

這時候模型的角色比較像「閱讀理解加整理」，而不是憑記憶回答。第 4 章會講提示詞怎麼設計、資料怎麼放進去。

知識庫：事先準備好的資料

檢索器不會每次都去翻原始的 PDF 或網頁，那樣太慢，也很難找得準。實際上是先把資料處理成方便搜尋的形式，這一步在使用者提問之前就做完了，通常包含：

1. 載入：把各種來源（PDF、文字檔、網頁、資料庫）的文字讀進來。
2. 分塊（chunking）：把長文件切成一小段一小段，因為檢索的單位是段落，不是整份文件。
3. 嵌入（embedding）：用模型把每一段轉成向量。
4. 儲存：把向量和原文存進向量資料庫，方便之後快速搜尋。

這些是第 3 章的主題。

兩條路線

把整個系統分成「離線」和「線上」兩部分會比較好理解：

	離線（事先做）	線上（每次提問）
做什麼	載入、分塊、嵌入、存進向量庫	問題、檢索、組提示詞、生成
什麼時候執行	資料有新增或修改的時候	每一次使用者提問
主要用到	嵌入模型、向量資料庫	檢索器、LLM
對應章節	第 3 章	第 2、4 章

為什麼要把檢索和生成分開看

RAG 的答案好不好，取決於兩件事：

• 找得對不對：如果檢索找來的是不相關的資料，後面的模型再強也沒辦法。
• 寫得好不好：就算找對了資料，模型也可能誤讀、漏掉，或是沒照著資料回答。

所以後面第 6 章評估 RAG 的時候，會把這兩部分分開衡量，才知道問題出在哪一邊。