はじめに

生成 AI を活用した機能の開発では、生成 AI が生成するアウトプットの質を維持・改善するためのタスクに携わることがあります。

たとえば、システム内で AI に与える指示（プロンプト）をチューニングしたり、タスクを実行する AI のモデルをより良いものに変更するといったタスクです。一見シンプルに聞こえるタスクですが、実際の作業には想像以上の手間がかかります（本当に）。

チューニングやモデル変更によって回答の質が下がるとユーザーに影響が出てしまうため、本当に質が向上しているのか、反対に質が低下している恐れはないのか、は慎重に検証する必要がありますが、この検証を人間が行うと評価に時間がかかったり、主観によるばらつきが発生したりする課題があります。

そこで注目されているのが「LLM-as-a-Judge」という手法で、人の代わりに LLM が LLM の評価をするというアプローチです。

今回は LLM-as-a-Judge のツールである「DeepEval」を PoC（Proof of Concept、実現可能性などの検証）してみました。PoC の内容や実際に使ってみた感想を書いてみたいと思います。

LLM-as-a-Judge とは

今回開発に取り組んだ AI 機能はユーザーに自然言語の形式で出力を返すものだったため、生成 AI の中でも自然言語の理解と生成に特化した LLM（Large Language Model、大規模言語モデル）を利用しています。

その LLM が生成したアウトプット（テキスト）を別の LLM に評価（Judege）させる手法のことを LLM-as-a-Judge と呼びます。

単語の一致度などの従来の統計的手法よりも、より人間に近い評価ができるとして注目されています。ただしバイアスなどの課題も存在するため銀の弾丸ではありません。

DeepEval とは

DeepEval is an open-source evaluation framework for LLMs.
https://deepeval.com/docs/getting-started?utm_source=GitHub

DeepEval は LLM のためのオープンソースの評価フレームワークです。Python のライブラリとして提供されています。

DeepEval を使わずとも、独自に評価のプロンプトを作成すれば LLM-as-a-Judge を実装可能です。

例：
今から与える入力が文法的に問題ないか、10 点満点でスコアを付けてください。

しかし自分たちで信頼性の高いプロンプトを作り上げるのは難しいですし、LLM の呼び出しやエラーハンドリング、データ処理など、実装コスト・保守コストが掛かります。DeepEval はそういった部分をフレームワークとして提供しつつ、組み込みの評価指標の提供、任意の評価指標の作成もサポートしているので、最も重要な「評価の設計」に集中することができます。

詳細な使用方法、コードの雰囲気、評価指標などの詳細はドキュメントをご覧ください。

DeepEval で PoC してみた

DeepEval の PoC について書いていきます。

背景・課題感

AI 機能をβ版として提供開始し数ヶ月が経過したことで、いくつかの課題が顕在化してきました。

1. プロンプトチューニングの困難さ

回答精度の向上や、回答のフォーマットの変更のためにプロンプトチューニングを行う機会がありました。そこでは以下のような検証が必要になります。

以前と比べてどれくらい精度が向上したか
予期せぬ副作用が出ていないか
etc…

こうした観点を人力で確認するのは時間や精度の問題で課題があり、プロンプトのチューニングのサイクルが回しづらい状態でした。

2. 新しいモデル導入の障壁

最近モデル（Claude Opus 4.1 や GPT-5 など）の導入はもちろんですが、コスト削減のために既存のモデルの中から今とは違うものを導入するという要件も「新しいモデルの導入」の 1 つです。

モデル変更による回答精度の劣化はユーザー体験の悪化を招くため十分に検証したいですが、人力で行うにはプロンプトチューニングと同じく時間や精度の面で難しい状態でした。

3. 新しい AI 機能の提供に時間がかかる

AI 機能開発では必ずプロンプトチューニングやモデル選定が必要となるため、上記と同様の課題に直面します。

それぞれ開発の違う場面で出てきた課題ですが、どれも LLM の出力の評価に関わる課題です。

PoC で特に重視した観点

PoC で特に意識した観点は以下です。

1. スコアが信頼できるか

人の評価を LLM の評価に置き換えて効率化を図るわけですが、その評価が信頼できないと意味がないですよね。信頼できるかどうかは以下の観点を意識しました。

信頼性

同じ入力に対してスコアにブレがあるかどうか。ある場合は抑えることができそうか
同じ入力（評価対象）に対して繰り返し測定してもスコアがばらつかないかの観点。スコアのばらつきが大きい場合には、スコアが上下したときに偶然なのか意味のある変化なのかを捉えることが難しくなる
例：3 回のテストの結果がそれぞれ 2 点, 8 点, 6 点となるようでは信頼性が低い（※ DeepEval は 10 点満点）

妥当性

スコアは妥当かどうか。人間の感覚と乖離していないか。
スコアが本当に評価したいものを評価できているかどうかの観点
例：内容の正確性を評価させるスコアなのに、誤った事実を混入させた内容でも点差がつかないのであれば、妥当性が低いということになる

感度

質を変更したときに差を検知できるか
評価対象の質に変化があったときに、変化が生じたことをきちんと検出できるかの観点
例：人の目で見て明らかなレベルの劣化が起きていても点数に十分反映されないのであれば感度が低く、性能劣化を見落とす確率が高くなってしまう

2. 学習コスト・開発効率

プロンプトチューニングや新機能開発にかかるリードタイムも短くするのはもちろんですが、それ以外にも別件の事情として、今後は AI 機能の開発をメインで行うチーム限らずどの開発チームも AI を開発できる状態にしていきたいという事情があったため、以下が重要な要素でした。

DeepEval の学習コスト
- AI 開発の知見が十分ではない開発チームも簡単に導入できる簡単さ
高速な開発
- 素早い設計
- 簡単な実行
- 実行時間が短いか

もちろん他にも観点はありますし、PoC をしながら気づいた点もありました。それらは以降にまとめていきます。

PoC してみた結果

1. スコアが信頼できるか

最終的に、PoC として大きな問題はないと判断しました。

当初 Summarization という要約に関する組み込み指標を試したところ、スコアが 0.8 を出したり 0.3 を出したりとばらつきが多く、信頼性に疑問が残る状態でした。

そこで、Summarization のような複数の観点を内包する複雑な指標ではなく、単一の観点で評価する方針に転換してみました。

変更前
- Summarization: うまく要約されているか（複合的）
変更後
- 網羅性：主要なポイントを含めているか
- 忠実性：正確な内容を保っているか
- 流暢性：文法的に正確で流暢か
- etc

結果、スコアの観点が絞られたためか、ブレは小さくなり人間の感覚に近い妥当なスコアを出してくれるようになりました。

続いて感度ですが、こちらは意図的に回答の質を落としてみるという方法でテストしました。

例えば正確性のカスタム評価指標を策定したとします。この指標の感度が十分なのかを保証するために、意図的に誤った情報を回答に盛り込んだ際のスコアも確認するのです。こちらも期待通りの低く妥当なスコアを出してくれたため、本番でも質の変化をうまく捉えてくれるだろうと判断しました。

より厳密なテストはまだまだ必要になるかもしれませんが、初期 PoC のレベルでは信頼性・妥当性・感度を含めて大きな問題はないという判断になりました。

2. 学習コスト・高速な開発

こちらも現時点では大きな問題はないと判断しました。

環境構築、実行、コーディング
- Introduction を見ていただくと分かりやすいですが、環境構築はパッケージマネージャーでインストールするだけなので手間はかからず、実行もコマンドラインや pytest からすぐ実行できます。コーディングもシンプルで記述量も少ないため、Python に慣れている人・チームには問題なさそうです。
実行時間
価指標の設計
- こちらの観点は少々懸念がありました。
- まず、DeepEval は組み込みでいくつかの評価指標を用意してくれていますが、どの指標を使えばよいのか判断に悩むケースが想定されます
- また、組み込み評価指標だけではなく、GEval を使ったカスタム評価指標を利用したい機会も十分想定されます。効果的な評価指標を設計するには知見が要求されます。
- こちらは、AI 機能を開発しているチームや DeepEval を PoC しているメンバーがその知見をドキュメントに落とし込み、開発チームはドキュメントを参考にしながら評価指標を設計し、必要があればサポートを依頼するという体制を取ることで解消しようとしています。

その他 DeepEval を使ってみた所感

良かった：柔軟性の高さ

DeepEval は GEval によるカスタム指標が定義可能で、どんな評価観点もスコアリングすることができます。AI 機能によってはその機能特有の評価観点を持ちたいこともあるでしょうから、この柔軟性はありがたいなと思いました。

その反面、効果的な評価指標を設計する力が問われるのは注意です。先ほどのリンクの中で GEval の背後の仕組みについて説明されていたり、追加情報のリンクが貼られていたりするので、そちらを読み込むことである程度解決できます。

懸念：結果の保存や可視化

DeepEval はテスト結果をクラウドに保存した場合に限っていい感じのグラフィカルな可視化を提供してくれます。

ローカルに json を保存することもできますが、その json を後からグラフィカルに可視化する方法は見当たりませんでした。クラウド保存が前提となっているのは気になる点でした。例えば S3 などの長期保存用ストレージに結果を保存し、後から見返したり比較したり分析したりするケースもあると思いますが、自分たちで可視化を作り込む必要がありそうです。

懸念：発展途上

DeepEval はまだまだ新しいツールで発展途上なため、バグを踏んだり、今後新しいツールに代替される可能性が常にあります。新しいツールが Python ライブラリである保証はないので、もしそうなってしまった場合には移行に時間がかかりそうです。こちらはそもそも LLM-as-a-Judge が比較的新しい概念なので仕方ないです。

終わりに

LLM-as-a-Judge に興味がある方で、DeepEval というツールについて気になっている方の参考に少しでもなれば幸いです。今後本格的な運用やさらなる PoC で得た知見を、またどこかの機会に記事にできたらと思います。

Discussion