前面幾天，我們已經陸續認識了 RAG 中的各個元件。從最開始的資料前處理、Chunking、Embedding，到後面的向量資料庫、Retriever、Reranker，一路走到 Context 與 Generation。每個元件單獨來看似乎都不算複雜，但真正讓 RAG 得以運作的，是這些元件串接在一起後形成的完整流程。因此今天先不介紹新的元件，而是把前面學過的內容重新走過一次，看看一份文件究竟是如何一路變成最後的答案。

RAG 想解決的問題，在 DAY1 已經提過：語言模型雖然能產生流暢的回應，但知識受限於訓練資料的時間範圍，也可能在缺乏依據的情況下產生看似合理卻與事實不符的內容。RAG 的作法，是在模型生成答案之前，先從外部知識來源取得與問題相關的內容，再把這些內容作為回答的依據。因此 RAG 並不是單純的把問題丟給模型，而是在問題與答案之間，多插入了一段「先找資料，再根據資料回答」的過程。

整條流程大致可以拆成兩個階段。第一個階段式建立知識庫，也就是把原始文件整理成可以被搜尋的形式；第二個階段則是使用者實際提問後，系統及時找出相關資訊、交給模型產生答案。這兩個階段前後相連，任何一個環節出了問題，都可能一路影響到最後的回答品質。

在建立知識庫時，原始文件往往格式不一，可能是 PDF、Word、掃描影像，也可能夾雜多欄排版、頁首頁尾、表格與圖片，因此需要先經過前處理，轉換成結構一致、內容乾淨的文字，並保留檔名、頁碼等中繼資訊，作為之後追溯來源與檢驗檢所正確性的依據。前處理如果做得不好，錯誤會沿著整條 Pipeline 往下游傳遞，而不會在後面的環節被修正——這也是為什麼前處理雖然不起眼，卻往往決定了系統的下限。接著是 Chunking，把整份文件切成較小的片段，因為使用者提問通常只針對文件中的一小段內容、切太細會失去上下文，切太粗又會讓多個主題混雜在一起，稀釋掉真正相關的資訊，因此需要在兩者之間取捨，並透過保留一定的重疊區間，降低重要資訊剛好落在切割點上而被拆散的風險。切好的片段接著透過 Embedding 模型轉換為向量，讓語意相近的文字在向量空間中彼此靠近，也讓「兩段文字意思像不像」從難以量化的語言學問題，變成可以直接計算的數學問題；同時必須確保索引階段與查詢階段使用的是同一個 Embedding 模型，這是後續一切檢索結果得以成立的前提。最後這些向量連同中繼資料，會被存進向量資料庫，透過索引結構讓日後的相似度搜尋得以在大規模資料中快速完成。走到這裡，知識庫才算真正建立完成。

接下來進入使用者提問後的流程。假設有人問「特休一天需要提前幾天申請？」，這段文字會先經過與索引階段相同的 Embedding 模型轉換成向量，才能與向量資料庫中的內容比較。Retriever 的任務就是在這個共同的語意空間中，找出與提問距離最接近的候選片段——但候選結果不代表每一筆都同樣重要，這也是為什麼流程中還需要 Reranker,針對這批候選片段重新計算與問題的相關程度，並依分數重新排序，把真正值得參考的內容留在前面。經過這兩層篩選後，系統手上終於有了一份品質較好的片段清單，這些片段組裝起來就是準備交給語言模型參考的 Context。

有了 Context 之後，系統會把它與使用者原始的提問一起送進語言模型並透過提示詞告訴模型「請根據以下內容回答問題」，模型才會根據這兩項輸入產生最終的回應。這也是為什麼 Retrieval 與 Generation 雖然前後相連，卻是性質不同的兩個階段；前者負責找到與問題相關的資料，後者負責根據問題的資料產生答案。即使 Retriever 與 Reranker 都找到了正確的資料，語言模型也不保證一定能正確理解或運用它；反過來；如果一開始檢索到的就是錯誤或不相關的內容，模型即使把這段內容讀得再透徹、答案再流暢，最後產生的答案仍然建立在錯誤的基礎之上。

把整條流程串起來看，會發現 RAG 其實一直在回答兩個問題：有沒有找到正確的資料，以及找到資料後，模型有沒有正確利用它。這兩個問題分別對應 Retrieval 與 Generation 兩個階段，彼此相連卻各自獨立，也正因為如此，當最後的答案出現錯誤時，我們很難只憑答案本身判斷問題出在哪裡。錯誤有可能來自前處理階段沒有把雜訊過濾乾淨，也可能是 Chunking 的切分方式不合理，或是 Embedding 模型的語意表達能力不夠，又或者是 Retriever 沒有找到關鍵片段、Reranker 把重要的內容排到了後面、Context 缺少了必要的資訊，甚至是語言模型明明拿到了正確的 Context，卻沒有妥善運用。單看最終答案，我們無從得知問題究竟是卡在這條長長的流程中的哪一個環節。

這正是為什麼 RAG 系統需要一套系統性的評測方法，而不能只靠「答案對不對」這一個粗略的標準去判斷整體品質。真正有意義的評測，應該要能幫助我們定位問題發生在哪個階段，進而知道該從哪裡著手改善——這也是本系列接下來要進入的核心。從下一篇開始，我們會正式進入 RAG 評測，並且先從 Retrieval 這一端談起，因為在確認答案是否可靠之前，我們首先要知道的是：系統到底有沒有找到對的資料。