Intro

我們昨天用 workflow 架構了我們的 Baseline RAG，並且跑出了對應的回答
我們今天有三個需求：

• 首先我們需要一個 End-to-End 的指標來評估我們 RAG 系統的好壞
  • 用的是需要有 reference_answer 的 correctness
• 我們需要有 Component-Wise 的指標，協助我們判斷：
  • 究竟是檢索的時候就錯了
  • 還是其實有檢索到答案，錯是在 synthesize 的階段
• 由於 correctness 是需要有 reference_answer 的，有沒有辦法用其它不需要答案的來近似它
  那我們就開始吧

End-to-End Evaluation: Correctness

• 我們昨天有跑出兩份答案，一份是把 retriever 的 top-k 設成 3，另一份是把 top-k 設成 8

• 我們分別對兩份答案使用 correctness evaluator 計算 correctness score

• 來人，我們上圖
  

• x 軸是 query 的 id, y 軸是對應的 Correctness score (1-5) 越高越好

• 可以看到 top-k=8 的版本 (藍色圓點) 都給出了 5 分滿分

• 而 top-k=3 的版本：

  • 在第 2 題和第 5 題也給出了滿分
  • 其他則是有高有低

• 由於題數不多，我們人工確認過，top-k=8的答案都是正確答案，而 top-k=3 除了滿分題以外，都是錯誤的

  • 原始結果的傳送門

• 這反映了我們先前的直覺，由於 llm 傾向於給出部分分數，所以就算答的不好 correctness 也不會直接是最低分

• 但以產品角度來說，我們的階段性目標確實應該設為大部分都要給出滿分評價，少部分沒有滿分的是 corner 或者 fail case

• 最後我們給出 rag pipeline 的單一數值指標，就是把所有題目的 correctness 取平均

top-k=8: 5.0
top-k=3: 3.125

小結

• End-to-End 的 Evaluation(這邊是 correctness) 可以讓我們針對兩個不同的 pipeline 進行整體的評估
• 我們可以把這個整體的評估的指標當成優化目標，下次改了 pipeline 就再跑一次
• 但問題就來了，今天當評估指標不好，我要怎麼知道我要去改 pipeline 的哪邊呢? 這就要用到我們的 component-wise evaluation

others

• 想知道 correctness 靠不靠譜，或者怎麼增強？ -> Day21: Evaluating the correctness evaluator
• 關於 correctness 的使用範例 -> Day19: evaluator in llama-index

Component-Wise Evaluation: Context Relevancy and Faithfulness

• 剛剛給出了我們 RAG pipeline 的 correctness 只有 3.125 分(我們的目標是5分)
• 那我們要怎麼知道是哪裡出的問題呢？
• 一般的 RAG pipeline 我們可以很簡單的切分成兩個部分：
  • 根據問題找資料: Retrieval
  • 根據資料回答問題: Synthesize
• 因此我們使用 Context Relevancy:
  • input 是 query 以及 檢索回來的 Context
  • output 是這些 Context 到底跟 query 有沒有關
• 以及 Faithfulness
  • input 是 檢索回來的 context 以及 llm 的 response
  • output 是 這個 response 有沒有照著 context 回答
• 來人，上圖
  
• 首先是我直接拼接了 topk=8, topk=3 的結果，來擴充我們的資料筆數
• 這張圖的 x 軸是 faithfunless Score: 0 代表沒有照著 context 答，1代表有
• 這張圖的 y 軸是 Context Relevancy Score: 越高代表檢索回來的內容與 query 越相關
  • 為了不要讓點都黏在一起，我在畫點的時候加上了些微擾動

我們先看一下這張圖的四個象限代表著什麼：

• 首先是左下角：
  • Retrieval 失敗 × Synthesis 也失敗
  • 低相關內容，模型還沒照內容答 → 完整失誤（檢索先錯、生成再錯）。
• 接著是右下角:
  • Retrieval 失敗 × Synthesis 忠實
  • 檢索到的內容跟問題不太相關，但模型有乖乖「根據不相關的內容」回答。
    • 直觀的理解是：因為檢索不到相關內容，模型回答我沒辦法回答這個問題
  • 以rag pipeline 來說：問題重點在 Retrieval：要把相關內容找對，否則就算忠實，答也不會對。
• 然後是左上角:
  • Retrieval 成功 × Synthesis 失敗
  • 有找到對的內容，但模型沒有依內容回答（可能幻想、忽略依據或格式跑掉）。
  • 這個時候有可能是 context 太長，模型的生成被干擾了
  • 問題重點在 Synthesis：需要加強遵循依據、約束生成。
• 然後是右上角：
  • Retrieval 成功 × Synthesis 也忠實
  • 兩段都對，理想狀態
  • 但還是有可能回答的不好，這種情況發生就是我們的 evaluator 要改改了。

我們接著分開看看是 topk=3 的問題還是 topk=8 的問題：

• 首先我們把 context score 依照 0.5 直接劃分成 0/1
  
• 這邊我們看到了，主要瓶頸在 Retrieval：
  • context_binary=0 的 5 筆全部來自 topk=3；而 topk=8 都出現在 (1,1)。
  • 這暗示 拉高 top-k 明顯改善檢索相關性。
• 目前沒有左上角的情況發生：
  • 代表一旦檢索到對的 context，生成大多數時候都「會照著內容回答」。
  • 短期內我們應該先投資在檢索部分，CP 值最高。

最後我們檢查當 faithful_score 跟 context_binary 都是 1 的時候，我們 correctness 的分數：

它的原始回答在：這裡

• 這題的原始 query 是：
  • "課程中目前保留需要訓練多少時間的作業？",
• 參考答案是：
  • "課程中保留需要訓練模型的作業，這些作業通常需要特別花時間，可能長達三到四個小時才能完成。"
• 錯誤答案是：
  • "課程中每一個作業通常留給大家三週的時間來完成，前兩個作業的截止日期特別延後到10月17號。"
  • 模型誤把訓練多少時間，當成是作業要寫多少時間
• 這邊是 context relevancy 給出的 feedback

"1) 是否與使用者問題主題相符？
評估：是，相符（2/2）
回饋：檢索到的內容主要在說明作業的規劃與繳交期限，包含「每一個作業基本上都留給大家三週的時間來完成」、「前兩個作業截止日延後到10月17日」及「最後一個作業截止日為明年1月9日」等明確時程資訊，這直接對應到使用者在詢問「課程中保留多少時間給作業／需要訓練的作業」這類與作業時程有關的問題。

2) 檢索到的內容能否單獨用來完整回答使用者問題？
評估：可以（2/2）
回饋：文中明確指出「基本上的每一個作業…都是留給大家三週的時間來完成」，這足以直接回答「每個作業保留多少時間」的問題。另外也列出例外（前兩個作業延後到10月17日、最後一個作業截止在1月9日），因此該段內容可單獨用來完整回應使用者對於作業所保留時間的詢問。說明：若使用者特別指「需要訓練（training）時間」為某類技術性訓練或模型訓練的具體運算時長，文中並無提及，但就作業可用時間（可完成期限）而言，檢索內容已足夠。

總分：4.0

[RESULT] 4.0"

• 可以看到與 response 相同的誤解
• 此外也可以看出，context relevance 是藉由回答兩個問題給出對應的分數：
  • 是否與使用者問題主題相符？
  • 檢索到的內容能否單獨用來完整回答使用者問題？
• 在沒有 reference_answer 的情況下，確實有可能因為誤解了 query 的意思而產生錯誤的回答

小結

• 我們這邊藉由 Context Relevancy 與 Faithfulness 嘗試抓出我們想要改善系統，具體要先改什麼
• 藉由 Context Relevancy 確實可以發現大部分的情況就是 context 裡面根本沒有答案導致的錯誤，也就是 retrieval 的問題
• 而 context 有找對，但是 synthesize 卻回答錯的情況在我們現在的資料集沒有發生
• Context Relevancy 與 Faithfulness 都不需要 reference_answer 就可以回復，這是他們很大的優點
• 但也因為沒有 reference_answer錨定，所以誤解 query 的本意的情況就有機會發生
  • 這個 context_relevancy 對，Faithfulness也對，但是 correctness 錯的情況，大致上就是我們整體系統提升的關鍵資料

其他

• 在意查找的 context 要留存的話，其實可以把 context relevancy 與每個 retrieved 的 node 一同計算
• 但這樣的問題是呼叫成本太高
  • 一個可能我們就改用 ollama 的 model
  • 一個可能我們就 compact，要它一次性的評估多個 retrieved 的 node
    • 這樣的話就和我們 Day10: CitationQueryEngine 與 Workflow 做的是類似的事了
• 這邊有一個常見的坑位是：誤以為 Faithfulness 錯就是 synthesize 的問題
  • 由於 RAG 系統是先查找再回答
  • 因此真的要確認是不是 synthesize 的問題，要看的是 condition 在 context relevancy 對，而 Faithfulness 錯的情況
  • 如果單純因為 Faithfulness 錯，我們就斷定是 synthesize 的問題，轉而去優化 synthesize
  • 很容易變成去是優化:
    • 模型要回答我不知道
    • 要基於錯的 context 產生出與使用者需求沒什麼關係的回答
  • 以使用者的角度來說，這都沒有完全解決他的問題
  • 而這也揭示：在做這類 Component-Wise 的優化的時候，最後還是要回頭做一次 End to End 的 Evaluation
    • 因為很有可能，我們錯誤的優化了奇怪的目標

Correctness Proxy 的嘗試：

• 到目前我們驗證並且分析我們的 RAG 系統都還算是成功，但我們仍然有一個很大的問題，Correctness 是需要 reference_answer 的
• 沒有 Correctness，很多事情我們都不能做，所以問題又來了：
• 有沒有什麼辦法是不需要 reference_answer，又可以近似我們的 Correctness 的
• 第一個嘗試是 answer relevancy，他做的事情是直接 prompt llm 回答 這個 答案有沒有回答到使用者的問題
  • 所以他的 input 只需要 query 以及 response
  • 這個也是我們可以加在 workflow 的步驟，反思：讓模型先自己看一下自己的答案有沒有回答到人家的問題
    BUT, 這是我們跑出來的結果
    
• 他的 x 軸 是 Answer Relevancy 的分數，可以看到大部分都是 1
• 他的 y 軸 是 Correctness Score，可以看到這比較符合實際情況，在 Top 3 的情況下大部分的回答都是錯的
• 難道這代表 Answer Relevancy 是個沒用的東西嗎?
  • 也不是，只是他沒辦法如我們直觀想像的去反應出他可以不依靠 reference_answer 的情況下作為 Correctness Score 的 Proxy
  • 在其他資料集上這仍可能是個有用的方法

那什麼適合作為沒有 reference_answer 情況下 correctness 的 proxy 呢?

• 這張圖的繪圖邏輯和上一張是一樣的，x軸是我們的 proxy
• y 軸是 correctness score
• 可以看到當 correctness_binary 給出 0 的時候，我們的 proxy 也是給 0
• 大部分 correctness_binary 給 1 的時候，我們的 proxy 也是給 1
• 只有一筆資料漏了，proxy 給出了好的結果，但實際上是錯的
• 這個 proxy 是什麼呢? 就是把 context_relevancy 以及 faithfulness 取 min
  • 阿，原來青鳥就在身邊

小節

• 大部分的情況下，我們都沒有 reference_answer 可以做使用
  • 頂多就是 prompt 最好的 chat-gpt 來生成
  • 人工來寫出大量的 reference answer 幾乎是不切實際的事情
• 但分析還是要做，要怎麼辦呢？
  • 我們首先測試了 answer relevancy，但是違反直覺的是，它並沒有很好的代理了 correctness 的工作
  • 這其實也反映了，相關不一定是答對
• 而我們最後也看到，在有查到相關文本，並且也有如時的回覆的情況下，它確實就比較接近我們想要的答案
  • min(context_relevancy, faithfulness) 就是這種情況
  • 雖然最後我們的 proxy 還是漏了一題，但以沒有 reference answer 的情況下來說，這也已經很好了
• 那關於這樣的一題在實務上怎麼辦呢？
  • 一個思路是我們就把所有的自行判定通過的情況交由人工來標註，回頭分析這個 proxy 不正確的 case，進一步優化我們的系統
    • 所以我們後續會介紹 label-studio
  • 人工只需要判斷這個是對的或者是錯的，也只會有相對少量的情況需要真的人工進行 reference_answer 的撰寫
    • 或者就像 chatgpt一樣，開個可以按爛的按鈕

Summary

• 我們今天首先關注在 end to end 的優化指標，在我們的情況下 correctness 很適合
  • 這個指標要留著，讓我們後續 pipeline 有改動的時候，重新驗證我們的 before after
• 接著我們關心 component-wise 的 evaluation，這可以協助我們分析出我們應該要先優化系統的哪一部分
  • 我們看到一個很大的坑位是 rag 系統是順序進行的，所以在分塊驗證的時候也應該要逐步做
  • 我們成功的診斷出 top-k=3 會做得不好的本質原因是 Retriever 段就做不好了
  • 也討論到，分塊優化是好事，但是我們優化前跟優化後，最主要都還是要關注在: 這個優化真的有解決我們的問題嗎?
• 最後，由於不是所有情況下都有 reference_answer 可以用，我們嘗試尋找替代 correctness 的 proxy
  • 我們測試了 answer relevancy，但是看起來不太 work，告訴我們相關不代表答對
  • 我們最後回頭發現了，在每一步都有做好的情況下，整體做對的機率是相當高的，而這個就是我們的 proxy
  • 我們的 proxy 並不完美，它還是有會錯，也幸運的被我們成功發現了
    • 這部分的後續就是把一系列 proxy 通過的 case 拉出來人工檢查，人工只要檢查對錯，僅有錯的情況下需要協助寫 reference answer 成為我們寶貴的資料
    • 並且可以留待後續分析是不是有什麼 case 我們的 proxy 特別容易錯

其他

• 關於 context relevancy 段，其實還可以細分是 rerank 段出的問題，還是 retriever 段出的問題
  • 做法就是直接比較 retriever 跟 rerank 結果的 context relevance
• 我們成功的發現了 topk=3 的問題是 retriever 段，而我們也直接用暴力法解決 (拉高 topk=8)，並且得到正確答案
  • 這個方法在本地文本就沒有相關答案的情況下，並不 work
  • 我們後續會嘗試看看 CRAG，發現本地文本沒有，就自己去網路找，來看看能不能解決
• 如果錯誤發生在 synthesize 段，由於我們是使用 context 生成的資料，所以其實我們有 reference_context 的 ground-truth，我會基於這樣的資料來修改 synthesize 的方法
  • 如果不是 context 生的資料怎麼辦?
    • 那就用 context 生一次，看看能不能生出錯誤的 case