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評価を書いている方：評価の良さをどのように判断していますか？

リポジトリ（Apache-2.0）： https://github.com/AshwinUgale/muteval