在正式開始之前，先說明一下接下來幾篇文章的架構。
RAG 評測大致可以分成兩個方向：一是檢索品質評估，關心的是「有沒有找到對的資料」；二是回答品質評估，關心的是「找到資料之後，模型有沒有正確利用它」。
檢索品質評估，我們會依序介紹 Context Precision（上下文精確度）、Context Recall（上下文召回率）、Context Entities Recall（實體召回率）、Noise Sensitivity（雜訊敏感度）這四個指標；回答品質評估，則會介紹 Answer Relevancy（答案相關性）、Faithfulness（忠實度）、Factual Correctness（事實正確性）、Topic Adherence（主題連貫性）。這八個指標合起來，會構成我們判斷一個 RAG 系統表現好壞的完整框架。今天先從第一個指標開始：Context Precision

先看一個例子。假設使用者問「特休一天需要提前幾天申請？」，Retriever 找回了五個候選片段：第一個片段明確說明特休申請需要提前幾天提出；第二個片段說明特休申請的核准流程；第三個片段是員工請假的一般規定，與這次問題有些關聯但不夠直接；第四個片段是加班申請規定，跟這次問題幾乎無關；第五個片段是員工旅遊辦法，同樣無關。如果我們只問「有沒有找到答案」，這次檢索似乎是成功的，因為真正需要的資訊確實在找回來的內容裡。但如果進一步問「找回來的這五筆內容，有多少是真的相關」，答案就沒有那麼理想了——五筆裡面只有兩筆真正切題，其餘三筆都是雜訊。Context Precision 想回答的，正是這個問題：檢索內容與問題的相關程度究竟有多高。

這裡可以做一個對照，假設有兩個 RAG 系統面對同一個問題。系統 A 找回三個片段，三個都與問題相關；系統 B 找回五個片段，只有第一個相關，其餘四個都不相關。如果只看「有沒有找到正確答案」，兩個系統都算成功，因為兩者都包含了關鍵資訊。但顯然系統 A 的檢索品質更好，因為它交給語言模型的內容更集中、雜訊更少；系統 B 雖然也找到了答案，卻讓語言模型必須從大量無關內容裡篩出真正有用的部分。這也是為什麼「有沒有找到答案」不足以評估一個檢索系統的好壞，我們還需要知道「找回來的內容裡，有多少比例是真正相關的」。

這裡也可以順便釐清一個容易混淆的概念：Context Precision 關心的是「找回來的東西裡，有多少是對的」，而稍後 Day13 要談的 Context Recall，關心的則是「真正需要的東西裡，有多少被找回來了」。前者關注的是雜訊多不多，後者關注的是有沒有遺漏。這兩者聽起來很像，卻是從完全不同的角度在看同一次檢索結果，之後會更深入說明。

Context Precision 偏低，通常代表 Retriever 找回的內容裡混入了太多無關片段，而這背後可能有很多原因。可能是 Chunking 切得太粗，導致一個片段裡同時包含特休規定、請假流程與其他不相關的資訊，只要其中一小段語意相符，整個片段就會被檢索回來；也可能是 Embedding 模型本身的語意表達能力不足，讓真正相關的內容在向量空間中沒有排到夠靠前的位置；也可能是 Retriever 的 Top-K 設得太大，找回的候選數量遠超過實際需要，多出來的部分自然成了雜訊；甚至可能是使用者的提問本身不夠明確，讓 Retriever 難以精準鎖定真正相關的內容。這也是為什麼 Reranker 在整條流程裡扮演重要角色——即使 Retriever 找回的候選結果中混雜了不少無關內容，只要 Reranker 能把真正相關的片段排到前面、把不相關的排到後面，最終選入 Context 的內容依然可以維持不錯的精準度。

Context Precision 之所以重要，不只是因為它反映了檢索階段本身的品質，也因為它會間接影響後面的生成階段。如果送進語言模型的 Context 中夾雜大量無關資訊，模型就必須從中辨認出真正有用的部分，這不僅拉長了輸入內容、增加運算成本，也提高了模型被無關資訊誤導的風險。因此理想的情況，不是讓 Retriever 找回越多內容越好，而是讓找回的內容盡可能集中在真正相關的範圍內。

不過這裡也要特別提醒一個容易掉入的陷阱：Context Precision 高，不代表這次檢索就完全沒有問題。假設回答問題真正需要的資訊有好幾項，而 Retriever 只找到了其中一項，但那一項確實精準相關，這時候 Context Precision 會很高，因為找回來的內容全部都相關；然而其餘沒被找到的資訊，等於完全遺漏了。換句話說，找得準，不代表找得全。這正是下一篇要談的主題——Context Recall，也就是真正需要的資訊，究竟有多少被成功找回來。