LLM-as-a-Judgeを実際に利用して見えてきた課題について

こんにちは、株式会社JMDC デジタル＆データ新規事業本部の渡辺です。今年、JMDCではアドベントカレンダーに参加しています。 qiita.com 本記事は、JMDC Advent Calendar 2025 8日目の記事です。

LLM-as-a-Judgeとは？

ChatGPTが登場してからちょうど3年が経過しましたが、依然として「生成AI」はホットトピックと言っても過言ではありません。実際、毎月のように何かしら大きな話題が上がっており、OpenAI, Anthropic, Googleといった主要3社もリリースやアップデートを現在も繰り返しています。そのたびに、ユーザからは「賢くなった」や「前のバージョンの方が好みだった」、「過去解けなかった問題が遂に解けるようになった」といった様々な感想が上がっています。

しかしながら実際の性能の良し悪しはタスクや個人の主観によるところも大きく、人によって意見がしばしば割れます。特に特定の業務に組み込んで使う場合は、採用するAIモデルや構成の選定根拠が必要になる一方、一度開発すると変更コストも大きいため、客観的な評価が重要です。かと言って、実際に定量化しようとすると、大量の評価サンプルに対してチューニング毎に人手で評価するとコストがかかってしまいます。

そのため、この評価自体を生成AI、特に言語生成AIであるLLM (Large Language Model, 大規模言語モデル) に担わせよう、という考えが一般的になってきました。 *1 LLMを用いた評価の自動化・効率化を行うアプローチを総称して、LLM-as-a-Judge と呼びます。

本稿では、この LLM-as-a-Judge を実際の社内データ×RAGを用いた質問応答で活用し、その際に直面した課題と、それを踏まえてのLLM-as-a-Judgeの限界や付き合い方について整理してみます。

本稿を読む上で

実際のデータやコンテキスト、結果の詳細・数値については、残念ながら本稿でご紹介できないため、あくまで結果や観察された事象の概要を綴った文字中心のものとなります
またここで述べる事象や仮説も、あくまで一つのRAG事例内での実験・分析に依るものであり、汎用性は保証できないため、参考程度に留めてください

LLM-as-a-Judge の特徴

具体的なタスクと課題について説明する前に、 LLM活用が一般利用される中で登場した LLM-as-a-Judge の特徴について、少し整理しておきます。

従来AIでの評価との比較: 動的な正解定義・メタ評価

生成AI主流以前の従来AIは、数値やラベルといった単純な値を出力するものが主でした。そのため、その正解となる値を事前に定義しておき、その値との一致率や近さで精度を計測します。

一方で、LLMの出力はテキストといった複雑で多様な値です。正解例を幾つか示す事はできても、生成されうる全てのテキストに対して正解スコアを割り当てる関数を、人が事前に定義する事は困難です。しかしLLMを用いて、プロンプトと正解例(あれば)を与える事で、評価関数を動的に構築する事ができるようになりました。

ただしこれで問題が解決したわけではありません。従来の評価指標 (正解ラベルとの一致率など) は、人間が定義したルールがそのまま評価関数になっていました。 LLM-as-a-Judge では「LLMに作らせた評価関数」がブラックボックスであるため、その妥当性を別の手段で検証する必要があります。いわば「評価器そのものを評価する」メタ評価が不可欠になるわけです。そしてこの検証の鍵となるのは、人による評価との比較である事を後で述べたいと思います。

人によるAI評価との比較: 均一化・スケーラビリティ

人手評価と比べたときの LLM-as-a-Judge の特徴は、大きく以下の2点です。

評価基準の一貫性
- 人の場合
  - 評価者によって基準が異なる
  - 同一評価者であっても、評価を進めるうちに基準が変わりうる
- LLMの場合
  - 同一モデル・同じプロンプトであれば、ほぼ同一のアウトプットになる事が期待できる (設定次第だが、再現性を担保可能)
スケーラビリティ
- 人の場合
  - (クラウドソーシングであっても) 評価人員を手配するリードタイムや、教育コストが一般には発生
  - 特に学術的・専門的な知識が必要な場合、そういった人材の希少性も増し確保が困難
- LLMの場合
  - APIや計算資源さえ用意できれば、大量の評価を即座に実行可能
  - LLMは学術的な情報も基本的に学習しており、知識のカバー範囲が広い (ただし理解度や知識の深さについては怪しいため、適用範囲については慎重に見ていく必要あり)
  - 今後もLLMの進化により、同一性能でもコスト自体は下がる傾向が期待

一方で、LLMにより出力の分散を抑えられたとしても、学習データや学習方法に起因するバイアスは持ちうること、また評価対象のドメイン知識をどこまでカバーしているのかは別途検証が必要になります。これらの点も後半の課題のところで改めて触れます。

RAG評価への導入

大規模言語モデルはとても優秀ですが、実務で利用する多くのケースでは、業務知識や専門知識を注入する事が必要不可欠です。よく知られている通り、RAG (Retrieval-Augmented Generation) はこれを実現する一般的な手段です。ここからは、RAGによる質問応答システムを対象に、LLM-as-a-Judge を使って評価を行う話に絞ります。

ここでは下図のように、RAGで生成したAI回答を、ユーザの質問及び実際の回答例と比較して評価させる方針で進めます。評価項目としては、「質問に対してどれだけ正しく・十分に答えられているか」という解決度合いを0-100のスコアで出力させました。*2 なお初期段階では、どういった観点で評価すべきか、が不透明であったため、まずはシンプルな設定で挙動を観察する事を優先していました。検証を進めるうちに、この点を見直す必要性が明らかになるのですが、それについては後ほどコメントします。

ちなみにRAGに関しては、RAGAS 等のRAG評価フレームワークがよく知られていますが、ここでは純粋にLLMに回答を評価させるセットアップのみ考えます。

実務適用で直面した課題

今回の検証では、LLM-as-a-JudgeをRAG評価に用いたときに、主に次の3点が問題として浮かび上がりました。

分散・ノイズ：スコアの非一貫・不安定性
- 同一LLM・同一サンプルでも、評価が大きく変動しうる
知識欠如：評価LLMの専門性欠如
- ドメイン特有の概念や用語を理解しておらず、誤判定が起きる
バイアス：冗長バイアス
- 実際には質問への回答となっていなくても、周辺情報量の多さにより、回答が過大評価される

これらは完全に独立な課題ではなく、例えば、専門性欠如はスコアの分散やバイアスの一要因でしょう。またこの3点以外にも様々な重要課題はあります。

しかしながら、いずれも LLM-as-a-Judge のサーベイ等*3でも議論されている既知の事実ではありますし、比較的普遍的な課題であろうと考えています。実際にこういった課題がある事を意識しておかないと、誤った意思決定にも繋がりますし、サーベイは網羅的であるものの濃淡がついていないため、本稿では改めてこの3つを取り上げたいと思います。なお各課題の対策は共通するものも多いため、このセクションでは踏み込まず、最後にまとめて紹介いたします。

スコアの非一貫・不安定性

1つ目の課題は、評価スコアが一貫しない事がある、という課題です。より正確には、プロンプト・入力固定で、温度パラメータを0ではない値に設定して*4複数回推論させた場合に、 LLMが出すスコアが大きくブレる (分散が大きい)、というものです。これは必ずしも評価に限らず、LLMにスコア算出させる際に起きうるものです。

勿論、出力の多様性を増すために温度をわざわざ入れているわけなのですが、辿り着く結論・評価としてなるべく一貫性を持って同じような値になってほしい、という期待があります。しかしながら実際にスコアを出させてみると、想定以上に大きくこの値が変動する事が確認されました。これは温度を0にすれば解決、という課題ではなく、そもそも温度0の場合のスコアをどの程度信頼してよいのか、温度のチューニングが必要なのか、といった問題提起に繋がっています。

このスコア分散が大きくなる要因としては、(温度によるサンプリング不定性を除くと) 主に以下の3つが考えられるかと思います。

評価基準の曖昧さ
- そもそもプロンプト内で評価観点・項目の基準が十分に言語化されていないと、LLMがその場の「雰囲気」でスコアを決めてしまう
  - 実際、同一データセットに対し、異なるLLMを用いてスコア算出をさせると、そのスコア分布が大きく変動する事も確認済み
データの特性
- 根本的に回答判定が難しい = 人間の評価者同士でも意見が割れるようなサンプルでは、LLMのスコアもどうしてもブレやすい
LLMの不安定性
- (人が容易に判断可能なケースにおいても) ちょっとした文面やプロンプトの違いで結果が変動しうる
  - 今回は入力の回答とプロンプトは固定だが、評価出力時の出だしの文章における僅かな差異でも影響しうる

この中で1はプロンプトの変更だけで済むためすぐに対処可能ですが、実際には基準の明文化を行っても、それなりに分散は残る事が判明しました。よって、2や3といった要因も無視できないであろう、と考えられます。

いずれにせよ、LLMの出すスコアが安定しない場合、全体精度評価に影響を与えてしまう可能性があり、誤った意思決定につながってしまいます。*5 もちろんサンプル数を増やしたり、統計的検定で判断したり、なども考えられますが、依然として、RAGや評価LLMを変えた事による同一サンプル内での変化が信頼できず、エラー分析等がやりづらいため、なるべくLLMの出すスコアを安定させる事が望ましいでしょう。

評価LLMの専門性欠如

RAGでは、回答に必要なドメイン知識を検索で取得し、LLMにコンテキストとして与えていました。一方で LLM-as-a-Judge では、コンテキストとして、実際の回答や回答時の検索結果しか与えない事も多いです。*6 それは回答を一から作成する場合にはドメイン知識が必要であるが、答え合わせの方は非専門家でもできる簡単なタスクである事が多いためである、と推察されます。

しかしながら答え合わせにも専門知識がいるケースは十分に考えられるはずです。実際、今回RAGを検証したタスクは、クローズドメインで高度な専門知識を要するものでした。素人が、回答例とLLMの回答を突き合わせても、すぐには判断が難しいケースもそれなりに含まれていました。

実際に誤判定を見ていく中で、クローズドメイン特有の用語定義が曖昧な事によると思われるミスが思いの外目立ちました。例えば、ある同一の対象に対して複数の表現が存在する場合*7、LLMの回答と実際の回答が、同一の対象を指しているのにも関わらず、異なる表現であるため、 LLMは異なる回答 (False Negative) として評価してしまう事があります。反対に、指し示すものが異なるにも関わらず、表現が類似しているため*8に同一のものと判定されてしまう場合 (False Positive) もありました。

こういった類の過ちは、単語の概念・定義を正しく知らないと解決できないので、オープンデータで学習したLLM単体では対処が難しいです。評価LLM側にもドメイン知識を与える（RAG的に文脈を供給する／ドメイン特化モデルを用いる）か、評価プロンプトで用語定義や同義語の扱いを明示するといった工夫が必要になります。いずれにせよ「答え合わせも決して単純作業とは限らない」という点を意識し、評価LLMに求められる専門性についても検討する事が重要です。

冗長 (情報量) バイアス

最後に取り上げるのは、LLMが持つバイアスに関するものです。まずは実際にエラー分析を進めた際の経緯からお話しします。

実はデータソースの中に、過去の問合せ履歴と社内資料とが含まれていたのですが、それぞれのソースだけを検索対象とした際に、評価の振る舞いが一部異なる事に気づきました。具体的には、社内資料のみをソースとした場合に、False Positive の割合が高くなる傾向にありました。実際の生成回答例を見たところ、問合せ履歴は比較的コンパクトな回答になるのに対し、社内資料は情報密度が高く、様々な情報を引っ張ってきている事が観察されました。

これらの観察結果を踏まえ辿り着いた仮説としては、情報量の多い文章程、それが質問への直接的な回答となっていなくても、良い評価をしてしまう傾向にある、というものです。

実際に類似の現象がLLMが持つ一般的なバイアスの一つとして知られており、冗長バイアス (Verbosity bias / Length bias) と呼ばれています。これは内容の正しさとは別に、文章が長いほど良い評価になる傾向を指します。実際に人が評価する場合でも、こういった考えやバイアス (長いレポート=手間がかかっている=努力を評価) はあるでしょう。仮に冗長でない場合は、文章量が多いという事は情報が詰め込まれています。これは、文章が長いほど良いと判断する冗長バイアスが、関連情報が多いほど高評価を与える「情報量バイアス」*9としても現れていると考えられます。

なお最近のLLMは質問に対する回答だけでなく、参考情報・関連情報・次のアクション案を出してくる事が多いかと思います。これは、ユーザの質問に直接回答するだけではなく、気を利かせて様々な情報を提示する事を良し、とするようチューニングされているからだと推察されますが、 LLMが評価する場合に「情報量バイアス」を持つ事はむしろ自然な挙動だと思われます。

これ以外にも様々なバイアスが実際は知られていますが、ここでは取り上げません。興味ある方は先の注釈で言及したサーベイ等を参考にしてください。

これら課題を踏まえて

上記3つの課題を本当に解消しようとすると、LLM自体の再学習・ファインチューニングに踏み込む必要があるため、そう簡単ではありません。しかしながら、既存のLLMの中でも実施できる事は幾つかあります。ここでは以下2つの全体対策と、スコア非一貫・不安定性に関する個別の対策・論点についてご紹介します。

人間による評価との比較

何度か言及したように、人間、特にそのタスクの専門家による評価結果と比較する事が何よりも重要です。これは実行コストが高いため、なかなか実施が難しいのですが*10、評価の自動化を行う以上は絶対に避けられないものです。逆に言えば、如何にして専門家による評価回数を減らしつつ、LLMによる自動評価の信頼性を担保するか、が重要となってきます。

そのためにはチェックを行うサンプリングの工夫が必要です。具体的には以下2点が挙げられます。

スコア分散の大きなサンプルへの重点化
- スコア分散が大きなサンプルは、LLMの専門性欠如や判断が難しいものである、と考えられる
- そのため、こういったサンプルに人の基準を付与する事が重要である
  - 場合によっては、プロンプトの中に Few-shot examples として追加するとよい
正解/不正解の境界サンプルへの重点化
- ざっくりと正解/不正解を分けるスコア閾値を見つけ、その付近にあるものはチューニングによって影響されやすい、と考えられる
- そのため、この領域を優先的に人がレビューする事で、評価基準とLLMの判断傾向のズレを把握

また1度の実施だけではなく、可能な限り継続的に進める事が重要です。例えばデータソースの変更といった回答の性質 ("確率分布")が大きく変わりうる際には、なるべく実施すべきでしょう。あるいはデータのセグメント (例えば質問種別・トピック) を切り、不一致しやすいものに絞って、評価を見ていくのも良さそうです。

このように、LLM-as-a-Judge を人間評価の完全代替として捉えるのではなく、人間の評価工数を減らしつつ精度保証を補完する道具として活用していくべきでしょう。

評価基準の精緻化

スコアの非一貫性や冗長バイアスは、評価基準の曖昧性とそこから生まれるLLM側判断の恣意性に依る部分が大きいと考えられます。そのため、プロンプト内への評価基準の明確化は特に重要です。

具体的には以下のような内容をプロンプトに反映させる事が有効でしょう。

評価項目と点数基準を規定
- 最終的なスコアとは別に、評価項目とその点数をLLMに出力させる
- さらには評価項目毎に、採点"前に"その根拠も抽出させる (Chain-of-Thoughtを明示的に行わせる)
  - 根拠を1度抽出させてから評価させることで、冗長バイアスを抑制 (を期待)
  - その根拠を確認する事で、LLMが捉えきれていない観点も明らかになる
評価サンプルの追加
- 良い回答と悪い回答の両方を用意
- 特にLLMが判断を誤りがちなサンプルを追加
- サンプル追加にあたっては、最終結果だけでなく、上記評価項目と点数も併せて記載
ドメイン知識の反映
- よく使われる専門用語の説明や注意点を追記
- 同義語の列挙

上記のようなプロンプトの改善・工夫の積み重ねにより、改善できる部分はそれなりに大きいと考えられます。

スコア非一貫・不安定性解消に向けて：温度チューニングとスコア平均の検討

ここではスコアが非一貫・不安定である課題について、もう少しだけ深堀をします。これまで述べた対策を取り入れ、

2つ目に述べた評価基準の精緻化
(必要なら) データセットの見直し (難易度で分ける、人でも判断が分かれるものは分離等)・クレンジング
1つ目の人による評価結果との比較や、スコア分散の大きなサンプルを確認し、要因を推察

といったサイクルを回して評価軸と評価データを早い段階で改善していく事は有効です。

一方で、評価側の修正だけでなく、推論時サンプリングに関するアンサンブル平均を取る、といったモデル推論側の単純な対策も効果的です。ただし計算コストが増大するため、なるべく評価側を優先して改善する方が望ましいでしょう。

またモデル推論側の改善点として、以下の論点も重要でしょう：

単に再現性を担保するためだけに温度0に設定してよいのか？
- 具体的には、温度0のスコアと、温度を上げた時のスコア平均値が一致するのか？
- 一致しない場合はどうすべきか？

残念ながらこちらも正確な検証は実施できず、あくまで個人の観察の域を超えないのですが、幾つかサンプルを見て確認した範囲内では、温度を上げてスコア平均を取ったものの方がより適切に見えました。また実際に初手で温度を上げて試していた理由もあります：

以前の経験から温度を多少上げた方が欲しい回答を得られやすい感触があった (あくまで個人の経験です)
温度0にしてしまうと局所最適解に陥りやすく、CoTのような推論を行う場合は、多少温度を上げた方がより良い解に辿り着きやすいのでは、という個人的な仮説 (あくまで仮説です)

いずれにせよ、より良い評価モデルを作るためには、温度0におけるLLMのスコアを鵜呑みにせず、きちんと温度調整含めた実験と人手評価の比較で決める、といった地道な検証が必要となるでしょう。

重要な余談

ここまで色々述べてきましたが、実は今回取り組んだタスクでは、ユーザが最終的な引用結果を確認する必要性があったため、 LLM-as-a-Judge は途中で利用するのをやめ、純粋に検索精度の方を評価する方向に舵を切っています。もちろん、LLM-as-a-Judge をやった事でデータに対する理解・課題も深まりますし、可能なら両軸で見るのが望ましいです。いずれにせよ、どういう評価を採用するか、がデータサイエンス・機械学習をやる上では最重要論点である事を、この取り組みでも改めて認識できました。

総括

他にも様々な対策・工夫は考えられると思いますが、本稿でお伝えしたかった事を改めてまとめておきます：

LLM-as-a-Judge は完全自動化の手段ではなく、人手の評価と必ず比較する事でスケールさせやすいアプローチに過ぎない
(LLMに限らない事ですが) 評価基準を明確に規定し、対象データセットの改善もなるべく早期に進めるべし
1. 上記評価基準が明確に定まれば、RAG構成や適切な温度・スコア算出も決定可能
LLM自体のチューニングを行わなくとも、人手評価との比較やエラーサンプルの具体的な確認を行い、プロンプトチューニングで解決できる範囲は一定ある

生成AI時代においても、データサイエンスの基本に立ち返り、評価定義・データ構築・実験と検証のサイクル、を丁寧にやっていきましょう！

最後にこのプロジェクトに一緒に参画いただき、学びを与えてくださったチームメンバと、本記事をレビューいただいた方々に感謝したいと思います。明日９日目は、楊さんによる「GoプロジェクトのCI・CDの高速化の話」です。お楽しみに！

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！データサイエンティスト/フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co

まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co

★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！

Tweets by jmdc_tech twitter.com

bsky.app

*1:歴史的な経緯を正しく把握しているわけではないですが、ChatGPT登場以降ですと、Wang and Liang et al., 2023やLiu and Iter et al., 2023(いわゆるG-Eval)あたりで注目を浴び始めた、と理解しています。

*2:なおOK/NGの二値にしてしまうと、正解判定水準の制御等がしづらいため、よくある二値分類モデルと同様に連続的なスコアで出力させています。つまり、最終的な二値判断は人間との評価比較結果に基づいて決定したスコアの閾値で制御可能ですし、またサンプル別のスコア分散 (後述) や、チューニング時のスコア変化が可視化でき、詳細な情報の抽出が可能となります。

*3:ちょうど去年の同時期にLi and Dong, et al., 2024やGu and Jiang, et al., 2024、Li and Jiang, et al. 2024といったサーベイが出ています。

*4:LLMの出力回答の多様性を制御するパラメータで、小さいと再現性の高い回答を返すが、大きいと予期しづらい多様な回答を返します。0に設定すると、理論上は同じ入力に対しては出力は固定されますが、実装上はGPU並列化やバッチ処理等に起因して計算順序が変わり、浮動小数点の演算特性によって、完全には固定されない事が知られています。

*5:実際に初期の頃は、同じRAGにも関わらず、正解率が10%近く変動していました。

*6:例えば、サーベイ論文では、法務領域のRAG付評価LLMをわざわざ取り上げているため、それほど一般的な構成ではないと考えられます。

*7:身近な例で言うと、大判焼き/今川焼/御座候といった、ほぼ同一の菓子なのに地域によって全く異なる言葉で呼ばれ、知らないと混乱する感じでしょうか。

*8:同じく身近な例で言うと、お好み焼き/広島のお好み焼き、のような素人には些末な(?)な違いが、特定の人達にとってはハレーションとなる感じでしょうか...

*9:一般的な用語ではなく、本稿特有の呼び方となります。

*10:実際に、今回のRAG検証でも業務知識を持った人による評価はあまり実施できませんでした。