前言

昨天我們談到為什麼需要 RAG——本質上就是為了解決 LLM 的幻覺問題，讓模型「先查資料、再回答」。今天要更進一步，把 RAG 系統拆開來看，搞清楚裡面到底有哪些環節，之後幾天的內容才有一個清楚的地圖可以對照。

RAG 的三大環節

RAG 系統可以拆成三個主要階段：Indexing（索引建立）、Retrieval（檢索）、Generation（生成）。前者是離線階段，後兩者是線上（使用者提問當下）階段。

【離線階段】
原始文件 → 清洗/切分（Chunking） → Embedding → 存入向量資料庫
                                                    │
                                                    ▼
【線上階段】                                    （索引已就緒）
使用者提問 → 問題轉 Embedding → 向量相似度搜尋 → 取回 Top-K 相關段落
                                                    │
                                                    ▼
                        Prompt 組裝（問題 + 檢索結果） → LLM 生成 → 回覆使用者

1. Indexing（索引建立）

這是整個 RAG 系統的地基，發生在系統上線之前（也會隨著知識庫更新而重跑）。主要工作：

• 文件載入：把 PDF、Word、網頁、Markdown 等各種格式的原始資料讀進來
• 清洗與切分（Chunking）：把長文件切成適合檢索的小段落
• 向量化（Embedding）：把每個 chunk 轉成一組數值向量
• 建立索引：把向量存進向量資料庫，並建立可以快速搜尋的索引結構（如 HNSW、IVF）

這個階段做得好不好，直接決定了後面檢索的品質上限——如果 Chunking 切得亂七八糟，後面再怎麼調 Prompt 都很難補救。

2. Retrieval（檢索）

使用者送出問題後，系統即時做的事情：

• 把使用者的問題也轉成向量（用跟 Indexing 階段相同的 Embedding 模型）
• 拿這個向量去向量資料庫做相似度搜尋，找出語意最接近的 K 筆 chunk
• （進階）加上 Rerank、Hybrid Search 等機制進一步提升精準度

這階段的目標很單純：在有限的 K 筆結果裡，盡量把「真正相關」的內容排進來，把不相關的雜訊擋在外面。

3. Generation（生成）

拿到檢索結果後，把它們和使用者的原始問題一起組成 Prompt，丟給 LLM：

System: 請根據以下參考資料回答問題，如果資料中沒有答案，請誠實告知使用者查無相關資訊，不要編造。

參考資料：
[Chunk 1 內容]
[Chunk 2 內容]
...

問題：{使用者問題}

LLM 根據這些「有憑有據」的資料生成回答，理想情況下還能附上引用來源，方便使用者查證。

為什麼要先弄懂這個架構？

因為後面幾天我們會分別針對這三個環節深挖：

• Day 5-9：Indexing 階段的資料前處理與 Chunking
• Day 10-14：Indexing 階段的 Embedding 與向量資料庫
• Day 15-20：Retrieval 階段的檢索優化
• Day 21-26：Generation 階段的 Prompt 設計與評估

先把整體地圖建立起來，之後每天的內容才知道自己在解決哪一塊的問題，不會見樹不見林。

小結

RAG = Indexing（把知識變成可查詢的向量）+ Retrieval（查到相關內容）+ Generation（根據內容生成回答）。三個環節環環相扣，任何一環出問題，整個系統的回答品質都會受影響。明天我們會進入實作前的準備——技術選型。