今天的核心議題

將 RAG 系統從單純的部署階段，提升到持續優化的層次。我們將學習如何用科學方法（A/B 測試），透過客觀數據來評估不同模型或策略的效果，從而做出數據驅動的決策。

為什麼 RAG 系統需要科學實驗？

「我覺得這個答案更好」—— 這種主觀判斷在工程與產品決策中是不可靠的。一個 RAG 系統的優化可能涉及多個變量：

• 不同的切塊（Chunking）策略：按句切、按段切，還是用更複雜的遞歸切塊？
• 不同的檢索器（Retriever）：使用傳統的 BM25，還是基於向量的 ANN 檢索？
• 不同的重排器（Reranker）：是否加入第二階段的重排，來提升精準度？
• 不同的 LLM 模型：GPT-4、Claude 3，還是開源模型？

如果沒有嚴謹的評估方法，你將無法客觀地知道哪種策略真正帶來了提升，每一次的「優化」都可能只是猜測。科學實驗能幫助你：

• 量化效果：用客觀指標（如準確率、延遲）來衡量變化。
• 支撐決策：用數據說服團隊，而不是憑直覺。
• 避免副作用：在小範圍測試新功能，避免因新功能引入錯誤或性能問題，影響所有用戶。

如何設計 RAG 系統的 A/B 測試框架？

一個完整的 A/B 測試流程包括：實驗設計、指標選擇、數據收集與統計分析。

1. 實驗設計

定義目標

首先，明確你要測試什麼以及期望達到什麼效果。例如：「測試新的檢索策略能否將答案準確率提升 5%，同時保持延遲不變。」

設定對照組與實驗組

• 對照組（A 組）：維持現有的 RAG 系統版本。
• 實驗組（B 組）：部署你想要測試的新策略或新模型。

分配流量

將一小部分用戶流量隨機分配給實驗組（如 10%），其餘流量則分配給對照組。確保分配是隨機的，以避免樣本偏差。

2. 指標選擇

選擇能夠量化 RAG 效果的客觀指標，這比單純的「準確率」更為全面。

離線評估指標（Offline Metrics）

檢索準確度：

• Hit Rate@k：前 k 個檢索結果中是否包含相關文檔。
• MRR (Mean Reciprocal Rank)：相關文檔在檢索結果中的排名。

上下文品質：

• Context Precision：檢索到的文檔中，有多少是真正有助於回答問題的。
• Context Recall：模型是否從所有相關文檔中提取了所有關鍵資訊。

線上評估指標（Online Metrics）

回答品質：

• Answer Faithfulness：答案是否忠實於檢索到的文檔。
• Answer Relevancy：答案與用戶問題的相關性。

用戶行為指標：

• Click-Through Rate (CTR)：用戶是否點擊了答案中的引用來源。
• Session Time：用戶與 AI 助理對話的時長。
• Feedback Score：用戶對答案的點讚或點踩分數。

性能指標：

• Latency：端到端響應延遲。
• Token Consumption：每次交互消耗的 LLM Token 數量。

3. 數據收集與統計分析

數據收集

在實驗運行期間，你需要記錄 A 組和 B 組的所有相關指標。

統計分析

• 顯著性檢驗：使用統計方法（如 t 檢驗）來判斷 A 組和 B 組的指標差異是否具備統計學意義，而不是偶然的結果。
• 多變量分析：如果 B 組在準確率上勝出，但在延遲上變差，你需要權衡利弊。

決策

• 成功：如果實驗組（B 組）在目標指標上有顯著提升，且沒有明顯負面影響，則可以考慮將其全面推廣。
• 失敗：如果沒有達到預期效果，或者引入了新的問題，則應停止實驗，並根據數據分析結果進行下一次優化。

四、RAG 專有評估挑戰

在 RAG 系統中，評估比傳統的 A/B 測試更複雜。

主要挑戰

評估策略

自動化評估

• LLM-as-Judge：使用更強大的 LLM 模型評估答案品質
• 語義相似度：比較生成答案與標準答案的語義相似性
• 引用準確性：驗證答案中的引用是否正確對應檢索文檔

人工評估

• 專家標註：領域專家對答案進行品質評分
• 眾包評估：利用眾包平台進行大規模評估
• 用戶反饋：收集實際用戶的滿意度評分

五、實驗設計最佳實踐

實驗設計原則

1. 單一變量測試：每次只測試一個變更，避免混雜效應
2. 足夠樣本量：確保統計檢驗有足夠的檢驗力
3. 運行時長：考慮時間週期性，避免週期性偏差
4. 分層抽樣：確保不同用戶群體的代表性

常見陷阱與避免方法

今天的決策清單

• [ ] 我們是否已經建立一套標準的 A/B 測試框架？
• [ ] 我們已經定義了衡量 RAG 效果的關鍵指標嗎？
• [ ] 我們是否有能力進行統計學上的顯著性檢驗？
• [ ] 是否已準備好應對主觀性答案的人工標註流程？
• [ ] 我們有足夠的流量和時間來進行有意義的實驗嗎？

想想看

1. 在 A/B 測試中，如果我們發現實驗組的延遲增加，但準確率顯著提升，你會如何向產品經理解釋這個權衡，並提出你的決策建議？

2. 如何用 LLM 本身來自動化地評估 RAG 系統的回答品質，以替代昂貴的人工標註？

3. 在沒有足夠流量進行 A/B 測試的初期階段，你還有哪些方法可以評估 RAG 系統的效果？

4. 當面臨多個相互競爭的指標時（如準確率 vs 延遲 vs 成本），如何設計一個綜合評估框架來做出最佳決策？