Ashwin Ugale

我為 LLM 功能撰寫評估、將它們整合到 CI 後就繼續前進。但通過的評估套件有一個盲點：它無法告訴你，當模型悄悄變差時，評估是否真的會失敗。綠燈不等於良好。

於是我建立了 muteval 來直接測量這一點。它借鏡軟體工程中的突變測試——你刻意破壞被測對象，然後檢查測試是否能捕捉到破壞。muteval 會讓系統退化（弱化提示規則、移除檢索文件、換成較弱模型），對每個退化版本重新執行你現有的評估套件，並回報這些注入的回歸被捕捉到的比例。未被捕捉到的，就是具體的覆蓋缺口。

Mutation score: 33% (2/6 caught)
SURVIVED: deleted "if the answer isn't in the context, say you don't know"

Enter fullscreen mode Exit fullscreen mode

關於它的運作方式。它內建約 18 種突變，每一種都模擬真實系統悄悄退化的情境：把「必須」軟化成「應該」、翻轉「不要」、移除或損壞檢索文件、打亂上下文、換成較便宜的模型，或是針對代理人設定破壞工具輸出。在進行任何突變前，它會先確認你的評估套件在原始系統上通過 —— 如果沒有通過，就沒有有意義的測量基礎。接著針對每個突變重新執行評估，按嚴重性排序存活的突變，並建議可填補每個缺口的評估。

它真的能找到真實問題嗎？我用它測試了 Vectara 的 open-rag-eval。它的引用檢查能捕捉到讓模型停止引用來源的突變 —— 但完全錯過了移除「答案不在上下文中時要說『我不知道』」規則的突變。模型在仍能引用來源的同時，卻可以自由編造內容，而引用檢查根本抓不到這種情況。一旦我加入對該行為的檢查，它就抓到了。

它純 Python 實作，無需依賴套件，可搭配 deepeval/RAGAS/promptfoo 的指標或它自己的檢查使用：

pip install muteval
muteval init      # scaffold a config
muteval check     # validate it, then muteval run

Enter fullscreen mode Exit fullscreen mode

接下來的發展方向，是讓工具能從多個角度評分評估套件，並建議你缺少的評估 —— 但我想先聽聽其他人如何處理這件事。如果你撰寫 LLM 評估：你如何知道它們是否足夠好？

Repo (Apache-2.0): https://github.com/AshwinUgale/muteval