如果你是一名用戶，擁有兩個不同的 RAG 應用，如何評判哪個更好？對於開發者而言，如何定量迭代提升你的 RAG 應用的性能？
顯然，無論對於用戶還是開發者而言，準確評估 RAG 應用的性能都十分重要。然而，簡單的幾個例子對比並不能全面衡量 RAG 應用的回答質量，需要採用可信、可復現的指標來量化評估 RAG 應用。
本文將從黑盒和白盒兩個角度來討論如何定量地評估一個 RAG 應用。
01.黑盒方法 V.S. 白盒方法
我們把評估 RAG 應用類比爲測試一個軟件系統，可以從兩個途徑來評估 RAG 系統的好壞，一個是黑盒方法，一個是白盒方法。
當以黑盒方式來評估 RAG 應用時，我們看不到 RAG 應用的內部，只能從輸入給 RAG 應用的信息和它返回的信息來評估 RAG 的效果。對於一般的 RAG 系統，我們只能訪問這三個信息：用戶提問（User's query）、RAG 系統召回的引用上下文（retrieved contexts）、RAG 系統的回答（RAG's response）。我們使用這三個信息來評估 RAG 應用的效果，黑盒方式是一種端到端的評估方式，也比較適用於評估閉源的 RAG 應用。
當以白盒方式來評估 RAG 應用時，我們能看到 RAG 應用的內部所有流程。因此內部的一些關鍵組件就可以決定這個 RAG 應用表現的好壞。以常見的 RAG 應用流程爲例，一些關鍵的組件包括 embedding model、rerank model 和LLM。有的 RAG 具備多路召回能力，可能還會有 基於詞頻的搜索方法（term frequency search） 算法，更換和升級這些關鍵組件也能爲 RAG 應用帶來更好的效果。白盒方式可以用來評估開源 RAG 應用，或者提升自研 RAG 應用。
02.黑盒的端到端評估方法
黑盒條件下評估指標
在 RAG 應用是一個黑盒的情況下，我們只能訪問這三個信息：用戶提問（User's query）、RAG 系統召回的引用上下文（retrieved contexts）、RAG 系統的回答（RAG's response）。它們是 RAG 整個過程中最重要的三元組，兩兩相互牽制。我們可以通過檢測這三元組之間兩兩元素的相關度，來評估一個 RAG 應用的效果。
提出下面這三個對應的指標得分：
-
Context Relevance: 衡量召回的 Context 能夠支持 Query 的程度。如果該得分低，反應出了召回了太多與 Query 問題無關的內容，這些錯誤的召回知識會對 LLM 的最終回答造成一定影響。
-
Faithfulness: 這個指標衡量了生成的答案在給定的上下文中的事實一致性。它是根據答案和檢索到的上下文計算出來的如果該得分低，反應出了 LLM 的回答不遵從召回的知識，那麼回答出現幻覺的可能就越大。
-
Answer Relevance: 側重於評估生成的答案與給定查詢提示的相關性。對於不完整或包含冗餘信息的答案，會分配較低的分數。
拿 Answer Relevance 舉個例子:
Question: Where is France and what is it’s capital?
Low relevance answer: France is in western Europe.
High relevance answer: France is in western Europe and Paris is its capital.
如何定量計算這些指標?
對於“Where is France and what is it’s capital?”這個問題，一個低相關性的答案是 "France is in western Europe." 這是通過人類的先驗知識分析得出的結論，能否有辦法定量地打分，這個回答是 0.2 分，另一個回答是 0.4 分？並且客觀上要保證 0.4 分的效果確實比 0.2 分得好。
另外，如果每個回答都需要人類來打分，那就要安排大量的勞動力，制定一定的指導標準，讓他們來學習這個準則並遵守它來打分。這種方法耗時耗費，顯然不太現實，能否有辦法自動化地來打分？
好在，現在先進的 LLM 比如 GPT-4，已經可以達到一個類似人類標註員的水平。它可以同時滿足我們上面說的兩個需求，一是能定量客觀公正地進行打分，二是可以實現自動化。
在這篇論文 LLM-as-a-Judge（https://arxiv.org/abs/2306.05685）裏，作者提出了 LLM as a judge 的可能性，並在此基礎上進行了大量的實驗。結果顯示，強大的 LLM judge（如 GPT-4）能夠很好地匹配控制和衆包人類偏好，達到了 80% 以上的一致性，與人類之間的一致性水平相同。因此，LLM 作爲 judge 是一種可擴展且可解釋的方法，可以近似獲取人類偏好，否則讓人類打分將會非常昂貴。
你可能會覺得 LLM 和人類打分者得到 80% 的一致並不是表明 LLM 和人類十分一致。但要知道，任何兩個不同的人，在受過指導的情況下，對這類主觀問題進行打分，也不一定能達到 100% 的一致。因此，GPT-4 與人類達到 80% 一致說明了 GPT-4 完全可以成爲一名合格的 judge。
關於具體 GPT-4 是怎麼打分的，我們還是拿 Answer Relevance 舉個例子，我們使用下面這個 prompt 向 GPT-4 提問：
There is an existing knowledge base chatbot application. I asked it a question and got a reply. Do you think this reply is a good answer to the question? Please rate this reply. The score is an integer between 0 and 10. 0 means that the reply cannot answer the question at all, and 10 means that the reply can answer the question perfectly.
Question: Where is France and what is it’s capital?
Reply: France is in western Europe and Paris is its capital.
GPT-4 的回覆：
10
可以看到，只要預先設計好一個合適的 prompt，比如上例這個 prompt，只要把 Qustion 和 Reply 替換掉，就可以自動化地評測所有 Q-A 對。因此，怎麼設計 prompt 也很重要，上例這個 prompt 只是一個樣例，實際的 prompt 爲了讓 GPT 打分更加公正和魯棒，往往是一個很長的內容。這就要用到一些高級的 prompt 工程技巧，比如 multi-shot， 或 CoT(Chain-of-Thought)思維鏈技巧。在設計這些 prompt 時，有時還要考慮 LLM 的一些偏見，比如 LLM 常見的位置偏見：當 prompt 比較長時，LLM 容易注意到 prompt 裏前面的一些內容，而忽略一些中間位置的內容。
好在關於 prompt 的設計我們不用去太關心，這些 RAG 應用的評估工具都已經設計集成好了。社區和時間可以幫助檢驗它們設計的 prompt 的好壞。我們更需要關心的其實是，大量訪問 GPT-4 這種 LLM，需要消耗太多 API key。未來期待有更便宜的 LLM 或本地 LLM，能達到當好一個 judge 的水平。
需要標註 ground-truth 嗎？
大家可能已經注意到了，上面的例子裏並沒有用到 ground-truth，它是人類寫好的可以回答對應提問的標準回答。比如可以定義 Ground-truth 和 Response 之間的一種指標，叫作 Answer Correctness，它是用來衡量 RAG 回答的正確性的。打分原理和上文 Answer Relevance 使用 LLM 打分的方式是一樣的。
因此，如果有 ground-truth，評估指標就更加豐富，即可以從更多角度來衡量 RAG 應用的效果。但在大多數情況下，獲得標準好 ground-truth 的數據集是很昂貴的，可能需要花大量的人力和時間來進行標註。有什麼辦法可以實現快速標註嗎？
既然 LLM 可以生成一切，那讓 LLM 來根據知識文檔，來生成 query 和 ground-truth 是可行的。比如在 ragas 的 Synthetic Test Data generation 和 llama-index 的 QuestionGeneration 中都有一些集成好的方法，可以直接方便地使用。
我們來看 ragas 中根據知識文檔生成的效果：
根據知識文檔生成的 questions 和 answers（https://docs.ragas.io/en/latest/concepts/testset_generation.html）
可以看到，上圖生成了許多 query questions 和對應的 answers，包含對應的 context 出處。爲保證生成問題的多樣性，還可以選擇各種各樣的question_type生成的比例，比如 simple question 和 reasoning question 的佔比。
這樣，我們就可以方便地直接用這些生成的 question 和 ground-truth，去定量評估一個 RAG 應用，再也不需要去網上找各種各樣的 baseline 數據集，這樣也可以評估企業內部私有的或自定義的數據集。
03.白盒的評估方法
白盒條件下 RAG pipeline
在白盒視角下看 RAG 應用，我們可以看到 RAG 內部的實現 pipeline。以常見的 RAG 應用流程爲例，一些關鍵的組件包括 embedding model、rerank model 和 LLM。有的 RAG 有多路召回能力，可能還會有 term frequency search 算法。很顯然，測試這些關鍵組件也能體現出這個 RAG pipeline 在某一步的能力上的效果，更換和升級這些關鍵組件也能爲 RAG 應用帶來更好的性能。
下面我們分別介紹如何評估這 3 個典型的關鍵組件：
怎麼評估 embedding model 和 rerank model
Embedding model 和 rerank model 一同完成相關文檔的檢索功能。上文中，介紹了 Context Relevance 這一指標，這一指標可以用來評估召回的文檔的相關性。但一般對於有 Ground-truth 的數據集，人們更常用信息檢索召回領域裏的一些確定性的指標來衡量召回的效果。相比於 LLM-based 的 Context Relevance 指標，這些指標計算更快、更便宜、也更加確定性（但需要提供 ground-truth contexts）。
信息檢索常用的指標
在信息檢索召回領域，常用的指標包括考慮排名的指標和不考慮排名的指標。
考慮排名的指標對於召回的 ground-truth 文檔的在所有召回文檔中的排名是敏感的，也就是說，改變召回的所有文檔之間的相關順序，會使得這個指標得分發生變化，而不考慮排名的指標則與之相反。
比如在上圖中，我們假設 RAG 應用召回了 top_k=5 個文檔，其中，A、C 和 E 文檔是 ground-truth。A 文檔排名爲1，它的相關性得分最高，並且得分向右依次減小。
如果 B 和 C 文檔調換了位置，那麼考慮排名的指標得分就會發生變化，而不考慮排名的指標的得分則不會發生變化。
下面是一些常見的具體指標：
不考慮排名的指標
-
上下文召回率(Context Recall)：系統完整地檢索到了所有必要的文檔的程度。
-
上下文精確率(Context Precision)：系統檢索到的信號（與噪音相比）的程度。
考慮排名的指標
-
平均精確率（AP）測量檢索到的所有相關塊並計算加權分數。數據集上的AP的平均值通常被稱爲MAP。
-
倒數排名（RR）測量您的檢索中第一個相關塊出現的位置。數據集上的RR的平均值通常被稱爲MRR。
-
歸一化折扣累積增益（NDCG）考慮了您的相關性分類非二元的情況。
最主流評估 Benchmark：MTEB
Massive Text Embedding Benchmark（MTEB）是一個全面的基準，旨在評估文本嵌入模型在各種任務和數據集上的性能。MTEB 涵蓋了 8 個嵌入任務，包括雙語挖掘(Bitext Mining)、分類、聚類、成對分類、重新排序、檢索、語義文本相似度（STS）和摘要。它涵蓋了總共 58 個數據集，跨越了 112 種語言，使其成爲迄今爲止最全面的文本嵌入基準之一。
MTEB: Massive Text Embedding Benchmark
https://arxiv.org/abs/2210.07316
可以看到，在 MTEB 裏包含 Retrieval 任務和 Reranking 任務，在 RAG 應用評估 Embedding 和 Rerank 模型時，要重點關注這兩個任務得分較高的模型。在 MTEB的論文 （https://arxiv.org/abs/2210.07316）建議中，對於 Embedding 模型，NDCG 是最重要的指標；對於 Rerank 模型，MAP 是最重要的指標。
在 HuggingFace 上，MTEB 是大家非常關注的 leaderboard。然而，由於數據集是公開的，可能目前有一些模型對這個數據集已經在一定程度上過擬合了,這會使得在實際的數據集中的性能下降。所以在評測召回效果時，也需要更多地關注業務偏向的自定義數據集上的評測性能。
如何評估 LLM？
一般情況下，生成過程可以直接使用上文介紹過的由 Context 到 Response 這一步的 LLM-based 的指標，即 Faithfulness 來評估。
但對於一些比較簡單的 query 測試，比如標準答案只有一些簡單的短語的，也可以使用一些經典的指標。比如 ROUGE-L Precision、Token Overlap Precision。這種確定性的評估也需要有標註好的 ground-truth context。
ROUGE-L Precision 測量生成的答案和檢索到的上下文之間的最長公共子序列。
Token Overlap Precision 計算生成的答案和檢索到的上下文之間 token overlap 的精度。
比如下面這種相對簡單問題可以還是可以用 ROUGE-L Precision、Token Overlap Precision 這些指標來評估。
Question: How many Index types does the latest version of Milvus support?
Reply: As of last month, Milvus support 11 Index types.
Ground-truth Context: In this version, Milvus support 11 Index types.
但要注意，這些指標在提問複雜的 RAG 場景下不太適用，這時就需要用 LLM-based 的指標來評估。比如像下面這種開放性的提問：
Question: Please design a text search application based on the features of the latest version of Milvus and list the application usage scenarios.
04.常用的評估工具介紹
目前開源社區已經出現了專業的工具，用戶可以使用它們來方便快速進行定量評估。下面我們介紹目前比較常見好用的 RAG 評估工具，以及它們的一些特點。
Ragas（https://docs.ragas.io/en/latest/getstarted/index.html）：Ragas 是專注於評估 RAG 應用的工具，通過簡單的接口即可實現評估。Ragas 指標種類豐富多樣，對 RAG 應用的框架無要求。也可以通過 langsmith（https://www.langchain.com/langsmith）來監控每次評估的過程，幫助分析每次評估的原因和觀察 API key 的消耗。
Continuous Eval（https://docs.relari.ai/v0.3）：Continuous-eval 是一個用於評估 LLM 應用 pipelines 的開源軟件包，重點放在檢索增強生成（RAG）pipelines 上。它提供了一種更便宜、更快速的評估選項。此外，它還允許創建具有數學保證的可信的集成評估管道。
TruLens-Eval：Trulens-Eval 是專門用於評估 RAG 指標的工具，它對 LangChain 和 Llama-Index 都有比較好的集成，可以方便地用於評估這兩個框架搭建的 RAG 應用。另外，Trulens-Eval 也可以在瀏覽器中啓動頁面進行可視化地監控，幫助分析每次評估的原因和觀察 API key 的消耗。
Llama-Index：Llama-Index 是很適合用來搭建 RAG 應用，並且它目前的生態比較豐富，目前也在快速迭代發展中。它也包含評估 RAG 的功能和生成合成數據集的功能，用戶可以方便地對由 Llama-Index 本身搭建的 RAG 應用進行評估。
除此之外，還有一些評估工具，它們在使用功能上，與上述的這些大同小異。比如 Phoenix（https://docs.arize.com/phoenix）、DeepEval（https://github.com/confident-ai/deepeval）、LangSmith、OpenAI Evals（https://github.com/openai/evals）。這些評估工具的迭代發展也非常快，關於具體的功能與使用方式可以查閱相應的官方文檔。
05.總結
對於 RAG 應用的用戶和開發者來說，評估 RAG 應用的性能在實踐中至關重要。本文將從黑盒和白盒兩個角度介紹定量評估 RAG 應用的方法，並介紹一些實用的評估工具，旨在幫助讀者快速理解評估技術並能夠迅速上手。如需瞭解更多關於 RAG 的信息，請參考本系列的其他文章《RAG 修煉手冊｜一文講透 RAG 背後的技術》《RAG 修煉手冊｜RAG敲響喪鐘？大模型長上下文是否意味着向量檢索不再重要》。