こんにちは！GameWithサービス開発部テクニカルプログレスグループの@shgxです。

LLM（大規模言語モデル）をプロダクトに組み込む際、多くの開発者が直面する大きな壁、それがLLMの評価です。LLMの出力は確率的で揺らぎがあり、「完璧な正解」が存在しないことも多いため、その品質をどう測り、どう改善していけば良いのか、頭を悩ませるポイントではないでしょうか。

本記事では、この根深い課題に対する強力なアプローチとして LLM as a Judge、つまりLLM自身に評価を行わせるという考え方について解説します。

なぜLLMの評価はこれほど難しいのか？

LLMの評価が困難である理由は、大きく2つに分けられます。

1. 出力の不確実性

LLMの出力には、本質的に不確実性が伴います。

ハルシネーション（幻覚）や誤情報のリスク: もっともらしい嘘を生成してしまう可能性があります。
出力の揺らぎ: 同じプロンプトを入力しても、実行するたびに異なる結果が返ってくることがあります。（これはtemperatureパラメータを0に設定することで抑制可能ですが、創造性が失われるトレードオフもあります）

2. テキスト評価そのものの難しさ

自然言語の評価は、数値計算のように単純ではありません。

主観性: 何を良い回答とするかは、評価者によって意見が分かれることがあります。
文脈依存: 同じ表現でも、文脈によって評価が大きく変わるため、評価基準が複雑化します。
リファレンスの欠如: 決まった正解文を用意することが難しいです。

機械翻訳の評価で使われるBLEUやROUGE、意味的な類似度を測るBERTScoreといった指標もありますが、これらも万能ではありません。特に、ドメイン固有の知識が求められるタスクでは、結局のところ独自に評価データセットを構築する必要に迫られ、一歩進むごとに新しい指標が襲ってくるような状況に陥りがちです。

解決策としてのLLM as a Judge

このような課題を乗り越えるためのアプローチがLLM as a Judgeです。これは、時間とコストのかかる人手による評価を、LLM自身に代替させるという考え方です。

このアプローチには、主に2つのメリットがあります。

迅速かつ低コストな評価: 人間による評価は主観的で多くの工数がかかります。LLMに任せることで、このプロセスを大幅に効率化し、迅速かつスケーラブルな評価サイクルを実現できます。
人間と同等の一貫した評価: LLMは、膨大なテキストデータから得られた普遍的な知識を持っています。明確な評価基準さえ与えれば、人間のように気分や体調に左右されることなく、一貫した基準で判断を下すことが期待できます。

では、具体的にどうすればLLMの判断を、人間の判断に近づけることができるのでしょうか？

LLM as a Judgeを実装する3つのポイント

鍵となるのは評価プロンプトの作り込みです。LLMにモデルの出力を定量的、かつ説明可能に評価させるためのプロンプトを設計します。

例えば、以下のように「事実性(accuracy)」「論理一貫性(coherence)」「明確さ(clarity)」の3つの観点で、スコアと評価理由をJSON形式で出力させるプロンプトが考えられます。

LLM APIのJSONモードなどを使って、決まった形式で取得できるようにすると良いでしょう。

以下の[モデル出力]について、3つの批判的観点
【事実誤認(accuracy)、論理一貫性(coherence)、曖昧さ(clarity)】
それぞれを0.0~1.0の小数で採点し、JSON形式で返してください。
各スコアの後に、スコアを0.0→1.0にした理由を1文ずつ添えてください。

例出力フォーマット:
{
  "accuracy": 0.40, // 根拠を一文
  "coherence": 0.55, // 根拠を一文
  "clarity": 0.30 // 根拠を一文
}

[モデル出力]
{ここに評価したいLLMの出力テキストを挿入}

このような評価プロンプトを効果的に機能させるためには、以下の3つのポイントが重要です。

1: 評価基準（OKとNGの境界）を明確に言語化する

ドメインエキスパートと協力し、どのような出力が良くて、どのような出力がダメなのかを具体的に定義します。「この単語が含まれていたらNG」「こういう構成になっていればOK」など、YES/NOで答えられるようなクローズドクエスチョンに落とし込むと、LLMも判断しやすくなります。

2: 少数のサンプルを例示して、評価精度を高める

LLMに評価のニュアンスを伝えるため、評価例をいくつか提示するFew-shotが有効です。「この出力はスコア0.8。なぜなら〜」「この出力はスコア0.3。なぜなら〜」といった具体例を示すことで、評価の精度と一貫性が向上します。ただし、1つの評価に多くの観点を詰め込みすぎると逆に混乱を招くため、観点はシンプルに保ちましょう。

3: 評価理由やスコアの計算過程を出力させる

なぜそのスコアになったのか？という理由をLLMに出力させることで、人間はLLMの判断プロセスを検証できます。これにより、評価システム全体がブラックボックス化するのを防ぎ、説明可能な評価が実現します。興味深いことに、近年の研究ではLLM自身が生成したハルシネーションを高い精度で検知できる（例: SelfCheckGPTで93%検知できた）ことも示されており、このアプローチの有効性を裏付けています。

評価を継続するための仕組みづくり

評価は一度きりで終わりではありません。モデルの改善サイクルを回すためには、評価結果を継続的に蓄積し、分析する仕組みが必要です。

BigQueryやFirestoreのようなデータベースに結果を保存するだけでも第一歩ですが、入力・出力・評価結果を紐づけてトレースし、管理・分析できる状態にするのは思いのほか大変です。そこで、LLMアプリケーション向けのLLMOpsツールを活用するのが現実的な選択肢となります。

LLM as a Judge を意識した代表的なサービスとしてLangSmithやLangfuseがあります。

LangSmith: LangChainが提供する高機能なツール。トレース、デバッグに加え、評価・分析機能も充実しています。
Langfuse: よりシンプルで、トレースログとプロンプトの管理、データの蓄積にフォーカスしています。

これらのツールは、多くの場合、既存のアプリケーションコードに数行追加するだけで導入できる場合もあります。langfuseの例では、以下のような感じで入力から出力までを個々のやり取りでトレース可能です。また、トレースと共に自動で評価を付けることも可能です。

まとめ: 定量評価がもたらす未来

LLMの技術は日進月歩で、モデルもプロンプティング技術も目まぐるしく進化しています。こんなに変化が速いなら、細かい評価や分析は無意味では？と感じる瞬間もあるかもしれません。

しかし、スピード感が求められる開発の中でも、定量的に評価できる仕組みを持つことで見える景色が大きく変わると考えています。

ステークホルダーへの説明責任: 感覚的に良くなったではなく、Accuracyが15%向上したので、このモデルを採用します、といったデータに基づいた提案ができ、自信を持った意思決定が可能になります。
継続的な改善サイクルの実現: どこが、どのように悪かったのかを具体的に把握できるため、的確な改善アクションに繋げられます。

LLM as a Judge の仕組みを構築するのは、決して楽な道ではありません。しかし、この説明可能性を追求することこそ、LLMという不確実な技術をプロダクトとして昇華させるエンジニアの腕の見せ所ではないでしょうか。