Day12 我們學到 Context Precision 在看「找回來的資料夠不夠精準」，Day13 則進一步問「真正需要的資訊有沒有被找回來」。今天要把這個問題拆得更細——因為即使整段 Context 看起來與問題高度相關，我們仍然可能漏掉某個真正關鍵的資訊。

延續特休申請的例子。假設使用者問「特休一天需要提前幾天申請？」，Retriever 找回的內容是「員工申請特休時，應提前向主管提出申請」。這段文字看起來確實與問題相關，語意上也說得通，但真正回答這個問題所需要的關鍵數字——也就是究竟要提前幾天——卻完全沒有出現。這時候我們會發現，「相關」和「關鍵資訊完整」是兩回事，而這正是今天要介紹的指標，Context Entities Recall，想要捕捉的問題。

在深入之前，先說明一下什麼是 Entity。Entity 可以簡單理解成文本中具有特定意義、可以被清楚辨識的關鍵資訊，例如數字、日期、人名、編號這類具體事實。以特休申請為例，「應提前申請」是一段描述性的文字，而「3 天」則是一項具體的 Entity——同樣都跟問題有關，但一個是抽象的敘述，一個是精確的答案。在企業 RAG 的情境裡，這類 Entity 經常大量出現：客戶名稱、合約編號、金額、日期、部門代號，都屬於這個範疇，而且它們往往不是「錦上添花」的補充資訊，而是直接決定答案正確與否的關鍵。

這也是 Context Recall 與 Context Entities Recall 之間的差異所在。Context Recall 問的是「真正需要的資訊，有沒有被找回來」，關注的是整體必要資訊的覆蓋程度；Context Entities Recall 則進一步問「其中關鍵的 Entity，有沒有被完整找回來」，把觀察的顆粒度縮得更細。可以把三個指標串起來理解：Context Precision 看的是找回來的內容準不準，Context Recall 看的是該找的資訊有沒有漏，Context Entities Recall 則是在「有找到、也大致相關」的前提下，進一步檢查其中最關鍵的具體事實是否完整。

為什麼漏掉一個 Entity 可能造成很大的差異？可以想像知識庫裡同時存在好幾個部門的特休規則——研發部需要提前 3 天申請，業務部則是提前 5 天。如果 Retriever 只找到「員工申請特休需要提前申請」這樣一段沒有指名部門、也沒有標出具體天數的描述，語言模型即使讀懂了這段文字，也無法判斷使用者問的究竟是哪個部門的規定，更別說給出正確的天數。一般描述性的文字提供的是語意方向，而 Entity 提供的則是回答問題所需要的確切依據；一旦缺少後者，即使前者看起來再相關，答案也很難真正命中。

這種情況特別容易發生在 Chunking 切分不當的時候。假設原始文件把「研發部特休規則」「提前 3 天申請」這兩項資訊剛好切進了不同的片段，而 Retriever 只找回了其中一個，那麼即使那個片段確實與問題相關，最終送進語言模型的 Context 裡，關鍵的天數就會不見。這也是為什麼 Context Entities Recall 偏低時，除了檢查 Retriever 本身，也值得回頭檢視 Chunking 的切分方式，是否把原本該綁在一起的關鍵資訊拆散到了不同片段裡。

這三個指標放在一起看，會提供比單一分數更完整的診斷資訊。假設 Context Precision 很高，代表找回來的內容大多相關；但如果 Context Recall 偏低，代表真正需要的資訊可能漏了不少；如果連 Context Entities Recall 也偏低，那就更明確地指出問題出在哪裡——不是完全沒找到資料，而是資料裡缺少了真正決定答案的關鍵事實。這也是為什麼不能只看單一指標判斷檢索品質好不好，而要從相關性、完整性、關鍵資訊完整性這三個層次，一層一層地觀察 Retrieval 的表現。

到目前為止，我們已經從三個角度檢查過 Retrieval：找回來的準不準、該找的資訊有沒有漏、關鍵的 Entity 有沒有找齊。但還剩下最後一個問題：如果 Retriever 確實找到了正確的關鍵資訊，卻同時混入大量不相關的內容，系統是否還能穩定作答？這已經不完全是「有沒有找到」的問題，而是「找到之後，面對雜訊會不會受到干擾」的問題，這就是下一篇要討論的 Noise Sensitivity。