LLMの応答をLLMに評価させる「LLM-as-a-Judge」の活用
GenAIOpsの3つめの段階「デプロイ後の運用フェーズ」での評価について説明した。このフェーズでは、プロダクション環境へデプロイ後も、品質・安全性などを継続的に評価し改善を続けることになる。
「アプリケーション開発フェーズでは、手動で作成した正解データを用いてクオリティを評価していました。しかし運用時にはリアルタイムの正解データが存在しないため、別の評価手法が必要になります。そこでモデルベースの評価アプローチとして『LLMの応答をLLMに評価させる』手法であるLLM-as-a-Judgeを採用しました」
LLM-as-a-Judgeは、LLMの評価プラットフォームであるConfident AIのドキュメント「Leveraging LLM-as-a-Judge for Automated and Scalable Evaluation」を参考に、「LLM の出力」と「評価基準（Criteria）」を与えて、基準に基づいてLLMにスコアを付けさせるSingle Output Scoring（正解データなし）を採用したと説明した。
評価基準（Criteria）としては、次の2つを独自に定義したという。
1つ目は適切さ（Appropriateness）。LLMの出力がガイドラインに沿って適切に修正されているかというもの。2つ目がフォーマットの一貫性（Formatting Consistency）。不要な改行や空白などが付与されておらず、フォーマットの一貫性が保たれているかを評価するものだ。
今回開発したアプリケーションのアーキテクチャは、次図のようになっている。このうち赤の点線部分がLLM-as-a-Judgeに当たる。
ただし、LLM-as-a-Judgeは完全に信頼できるとは言えず、人間による評価結果と比較して信頼性を測ることが重要だと語った。今回はユーザーの声を集めやすい社内システムであるため、定量的なスコアを継続的にモニタリングしつつ、ユーザーフィードバックを収集していく予定だ。
さらに今後は、本番環境に入力されたDDLと、LLMが生成したDDLが蓄積されていくため、 出力されたDDLでアノテーションして事後評価を実施したり、本番環境のデータセットでファインチューニングしたりしていきたいと述べた。
最後に、全体のまとめとして、得られた学びを3つのポイントで解説した。
まずは、LLMアプリケーションは評価が重要かつ難しいということ。Amazon BedrockやOpenAIでブラックボックスなAPIを扱えば作るだけなら簡単にできる。しかし、そのクオリティを他社に説明したり担保したりするのは難しい。今回は、最初に評価を設計し、チューニングと評価サイクルを高速に回すことができたが、3つの評価プロセスでユースケースごとに都度判断が必要になり、評価設計の妥当性判断が困難になりやすいと感じたという。
2番目のポイントは、テストデータの作成が大変だったということ。今回は手動で作ったため、多くの時間を要しており、精神的な負荷も高かった。テストデータを自動でLLMに生成させる手法も存在するが、別途プロンプト作成とチューニングが必要になる。結局、どこかで人間による正確性チェックは入れた方がいいと感じたという。
3番目のポイントは、性能が低いモデルほどプロンプトチューニングの工数・難易度が増加したこと。最初は、Claudeの3つのモデル（Haiku／Sonnet／Opus）のそれぞれでチューニングを進めていたが、Haikuは今回のタスクに対して性能が低すぎてチューニングを断念したそうだ。また、後から出た3.5 Sonnetで一気にチューニングが楽になったと、その実感を語ってくれた。
