RAG（Retrieval-Augmented Generation）的出發點，是語言模型的知識來自訓練資料，有時間範圍，也不會涵蓋企業內部、經常異動的規章。RAG 的做法，是在生成答案之前，先從外部知識庫檢索相關內容，再把檢索結果與原始問題一併交給語言模型，效果類似開卷作答。整個系統因此分成檢索與生成兩個階段，表現同時取決於資料有沒有找對，以及模型有沒有用對。

知識庫的建立，從前處理開始。企業文件常見 PDF、Word、掃描影像等異質格式，前處理負責轉換成結構一致、內容乾淨的文字，並保留檔名、頁碼等中繼資訊。接著 Chunking 將文件切成較小的片段，粒度需要在語意完整與檢索精準之間取捨，並以重疊區間降低關鍵資訊被切散的風險。Embedding 再把片段轉成向量，讓語意相近的文字在向量空間中彼此靠近，且索引與查詢必須使用同一個模型。最後，向量與中繼資料存入向量資料庫，透過近似最近鄰索引，在大規模資料中快速完成相似度搜尋。

使用者提問之後，問題先轉成向量，由 Retriever 找出距離最近的候選片段。Top-K 決定回傳的筆數，設太小會漏掉相關內容，設太大會混入雜訊；純向量檢索對數字、代號等需要精確匹配的內容有限制，因此常搭配關鍵字搜尋，形成混合檢索。候選片段再交給 Reranker 重新排序，挑出最相關的前幾筆，組成 Context，連同提問與提示詞一起送進語言模型，產生最終回答。

這條流程的每個環節環環相扣，前面的缺陷會一路往下游傳遞，而不會在中途被修正。前處理殘留的雜訊會變成檢索結果中的干擾，切分不當會讓關鍵資訊分散，檢索漏掉的資料，模型再強也無從補起。當最終答案出錯，只看答案本身，很難判斷問題卡在哪個環節，這正是需要系統性評測的原因。

RAG 評測分成檢索品質與回答品質兩個方向，各以四個指標檢視。檢索品質關心「有沒有找到對的資料」：Context Precision（上下文精確度）檢查找回來的內容準不準，Context Recall（上下文召回率）檢查必要資訊有沒有漏，Context Entities Recall（實體召回率）檢查數字、日期、名稱等關鍵事實齊不齊，Noise Sensitivity（雜訊敏感度）則檢查 Context 混入雜訊後，答案還穩不穩，這個指標與前三者相反，分數越低越好。

回答品質關心「找到之後有沒有用對」：Answer Relevancy（答案相關性）檢查回答有沒有對準問題，Faithfulness（忠實度）檢查回答有沒有超出 Context 的範圍，Factual Correctness（事實正確性）檢查回答與標準答案吻合到什麼程度，Topic Adherence（主題連貫性）檢查多輪對話中有沒有守住預先定義的主題。四個指標各自對照的對象不同，依序是原始問題、檢索到的 Context、標準答案與參考主題，因此能抓到的問題也不同，無法互相取代。

指標的價值，不在於得到一個分數，而在於依分數回頭定位問題。實務上較有效率的排查順序，是先看檢索的四個指標，確認資料有沒有找對、找全；再看 Faithfulness，確認模型有沒有照著資料回答；接著看 Factual Correctness，確認答案對不對；最後以 Answer Relevancy 與 Topic Adherence，確認有沒有切題、有沒有守住主題。分數偏低時，再對應回前處理、Chunking、Embedding、Top-K、Reranker、Prompt 與 Guardrail（護欄）等環節逐一檢查。

30 天的內容，從 RAG 存在的理由出發，經過知識庫建立、檢索、重排序與生成，接著以評測指標建立判斷標準，最後落實到實作與調參，構成一套從原理、建置到驗證與改善的完整框架。RAG 系統的品質，取決於整條流程中每一個環節，而評測提供了判斷哪個環節出問題的依據，讓每一次調整都能以 baseline 驗證，而不是憑感覺。