Eval-Centric AI: LLM-as-a-Judge on Vertex AI

この記事は、Google Cloud Champion Innovators Advent Calendar 2024 22日目の記事です。

---

この記事では評価を中心とした LLM の開発・運用フローについて述べます。評価では Vertex AI Gen AI Evaluation Service を例に用います。

背景

Gemini 1.5 Deep Research が出ましたね、さっそく LLMOps について聞いてみましょう。次は回答の一部です。

LLMOps（Large Language Model Operations）とは、大規模言語モデル（LLM）の開発、運用、管理を効率化し、最適なパフォーマンスを引き出すためのプラクティス、手法、ツールの集合体です。1 LLMOps は、近年注目を集めている Foundation Model Operations (FMOps) のサブセットであり、FMOps があらゆる生成 AI ソリューションの運用効率化を目的とするのに対し、LLMOps は LLM ベースのソリューションに特化しています。2 LLMOps は、従来の機械学習モデルの開発・運用・管理を効率化する MLOps の概念を拡張し、LLM に特有の課題に対応するために発展したものです。3 近年、ChatGPT など、LLM を活用したアプリケーションの開発が盛んに行われていますが、LLM の運用には、従来の機械学習モデルとは異なる課題が存在します。4 LLMOps は、これらの課題を解決し、LLM を効果的に活用するための重要な概念です。
LLMOps プラットフォームは、データサイエンスとソフトウェアエンジニアリングをコラボレーション環境に統合し、データの探索、リアルタイムのエクスペリエンスの追跡、プロンプトエンジニアリング、モデルとパイプラインの管理を実現します。5 これにより、機械学習ライフサイクル全体における運用タスクとモニタリングタスクの自動化、効率化を促進します。5

それなりのことを言っているように見えます。では核心を聞いてみましょう。

良いことを言っています。全体はこちらから。 https://g.co/gemini/share/f8558a32cf2d

LLM の活用においては訓練を前提とできません。その状況で継続的改善を実現するためには評価が重要であり、評価を前提としたフィードバックループの実装が重要だと考えています。この記事ではその概要を記述します。

少しだけ小言を言うことが許されるのなら、僕の資料を読んだのならば反映されていると嬉しかったですね。

Eval-Centric AI

機械学習システムの性能を改善する方法について考えましょう。まず、性能改善における要素を洗い出します。概念的には次の3つとなるでしょう。

• モデル: 機械学習のアルゴリズムや前処理、後処理
• データ: 機械学習モデルの訓練に用いるデータ
• 評価: 機械学習モデルの評価データや評価指標

この3つの要素のうち、研究開発では典型的にはモデルを改善することで機械学習システムの性能を改善します。これに対して、機械学習のアルゴリズムの変更よりも、データの品質の改善のほうが重要だと提唱したのが Andrew Ng 先生が提唱された Data-Centric AI です。アルゴリズムを改善する取り組みは Data-Centric AI と対比して Model-Centric と呼ばれます。

では LLM はどうでしょうか。多くの場合、モデルのアルゴリズムを変更することや、モデルを訓練することは現実的ではありません。また、Finetuning も必ずしも有効とは限らず、下手に行うとモデルの性能が元よりも劣化する場合があることが知られています。さらに、Finetuning のための高品質なデータセットを用意することはさまざまな理由から非常に労力がかかります。

このため、多くの場合 API の向こうにあるモデルのアルゴリズムと訓練データを変更することは困難で、評価のみが変更できる要素だと言えます。整理してみましょう。

改善のために行うこと	X-Centric
データと評価を固定し、アルゴリズムを改善	Model-Centric
モデルと評価を固定し、データを改善	Data-Centric
モデルとデータを固定し、評価を改善	?????

LLM の活用において、必要となる取り組みは最後の取り組みなのですが、既存の取り組みはモデルかデータの改善を前提としています。僕の知る限り、評価の改善による性能改善はこれまでにほぼ議論されてきていません。Human-in-the-Loop は近い取り組みですが、正確には異なるものと見るべきでしょう。したがって、これには名前がついていません。

これを我々はなんと呼ぶべきでしょうか。僕はこれを評価中心のAI、Eval-Centric AI と呼ぶことを提案しています。

しかしながら、評価を改善することで機械学習システムの性能改善をするというのは一見意味不明な主張に見えます。次は Eval-Centric における継続的改善について検討します。

継続的な評価

Eval-Centric において実現すべきことは何でしょうか。僕は継続的改善の実現だと考えます。

継続的改善

継続的改善 (Continuous Improvement) は DevOps の原則のひとつです。DevOps はタイムリーなフィードバックとすばやい実装により、フィードバックループをすばやく回すことでサービスを継続的に改善します。そのための技術が CI/CD やモニタリング、本番環境でのテスト (A/B テストやカナリアリリース) と言えるでしょう。

MLOps では継続的改善を 継続的な訓練 により実現します。サービスから実際のデータを収集し、新たなデータを得ることで訓練データを更新し、より良いモデルや最新の傾向に追随したモデルをリリースするのが継続的な訓練です。MLOps では継続的な訓練により、継続的な改善をデータによって実現しています。

LLM の活用において、継続的な改善をどのようにすれば実現できるでしょうか。そのためにはフィードバックループにより改善したい課題について考える必要があります。

LLM の活用における根源的な問題

LLM の活用における課題は何でしょうか。さまざまに理由は考えられますが、もっとも大きいものは「自然言語で書かれた文章は、評価基準が明確でない」ということが言えるかと思います。

これまでの機械学習タスクでは需要予測や、画像のクラス分類など、評価基準を精度指標として定義できました。しかし、LLM の評価基準はほとんどの場合曖昧です。評価基準について列挙しようとしたドキュメントは QA4AI のガイドライン をはじめとして数多くありますが、それらのドキュメントで定義されているのは回答性能のような「精度」とみなせるものだけではなく、「倫理性」のような一般に回答を出すことが難しいものも含まれています。「倫理性」を定義し、定量化することことは極めて困難だと言えます。

また、品質評価の基準はアプリケーションによって大きく異なります。占い特化型チャットAIにおけるLLMの検証と選定では占い師としての応対の評価に取り組まれています。占い師として望ましい回答とは一体何でしょうか？一般の ChatGPT は回答を出すことに特化していますが、占い師として振る舞うのであれば「相手の話を聞くこと」「明確な回答ではなく多様に解釈できる曖昧な回答をすること」のような評価観点が出てくるでしょう。

アプリケーション固有な品質の観点から評価するためのベンチマークは当然存在しません。そのような曖昧かつ前例のない評価ができるとすれば、ドメインエキスパートと呼ばれるその業務の専門家だけでしょう。

では専門家であれば評価できるのでしょうか。実はそうでもありません。専門家による判断基準が、評価を通じて変化していくという Concept Drift と呼ばれる現象が報告されています。これは専門家といえど最初から精緻な評価ができるわけではなく、評価を通じてあるべき評価観点に気がつくということを示唆します。

以上から LLM の活用における根源的な問題は 「誰もあるべき振る舞いを定義できない」 といえます。では、どのようにすればこの状況を打破できるのか考えてみましょう。

LLM-as-a-Judge による継続的な評価

まずは「誰もあるべき振る舞いを定義できない」という状況における、評価の手法について考えましょう。とはいえ、曖昧な評価基準を用いた評価において、専門家による判断がもっとも信頼できるものです。専門家による判断をどのように改善できるか考えます。

専門家であっても判断基準は変化することを見てきましたが、どのようにすればより良い評価ができるでしょうか。ここにおいては古典的な回答が存在します。判断基準をできるだけ明文化し評価のためのマニュアルを作成することは、専門家間における判断基準を揃えるために古くから取り組まれてきました。Concept Drift が発生したとしても、マニュアルをアップデートしていけば評価基準を少なくとも定性的に定義することはできるでしょう。

専門家による判断基準を明文化することで、チームを形成して手分けしながら評価し、小規模 (数百件程度) の評価済みデータセットを構築することは、比較的現実的に行えます。

一方で、専門家による判断はスケールしないという課題があります。数千件や数万件のデータセットに対する評価を行おうとすると、作業のために長い時間を要したり、人件費が高くつきがちです。Concept Drift は、評価は一度行って終わりではなく、何度も行う必要性を示唆します。評価者を増やす以外にも、自動化の方法を検討する必要があります。そこで利用できるのが LLM-as-a-Judge です。

LLM-as-a-Judge は評価観点を詳細に書くことで LLM を用いて評価を行う手法です。詳細については良い記事がすでにあります。次の記事は良い指針を与えてくれます。

https://zenn.dev/pharmax/articles/2d07bf0498e212

https://zenn.dev/gaudiy_blog/articles/b34345aab2949e

さて、今、専門家による評価を行い、数百件程度の高品質なデータが構築できたとしましょう。また、チームで評価するために評価観点をドキュメントとして記述したとしましょう。そのドキュメントはほぼそのまま LLM-as-a-Judge のためのプロンプトとして用いることができます。さらに、プロンプトを用いた評価の精度は数百件程度のデータを用いて検証できます。評価に伴うコストも LLM-as-a-Judge のテクニックを用いることで、API をコールするだけの費用で抑えられます。

ここまでの議論により、フィードバックループが構築できます。図で表すと次のように整理できます。

右上の評価・分析の小さなループは Concept Drift を通じてあるべき姿を明文化するループです。このループを通じて、評価用のプロンプトにあるべき姿や品質評価の観点が明示的に書かれていきます。

あるべき姿が評価用のプロンプトに書かれたので、それを開発側に持っていきプロンプトのチューニングに利用できます。それをデプロイし利用することで、さらなる以外な発見が分析にもたらされるでしょう。この開発、利用、評価、分析のループが 継続的な評価 のアイデアです。

モデルとデータを固定して評価を改善するという Eval-Centric AI における継続的改善は、継続的な評価に基づくフィードバックループを構築することで実現できます。では、その鍵となる LLM-as-a-Judge の実装方法について、Vertex AI の Gen AI Evaluation Service で確認してみましょう。

Gen AI Evaluation Service による LLM-as-a-Judge の実装

ここではSpiralAI の開発したククリさまの次の動画の発言を評価してみましょう。

(ついつい好きな人のことを目で追っちゃう、という発言に対して)
うぬ、それは恋ではなくただの執着じゃな。相手の子も気にはしているが、それほどではないのではないか？

発言はこの動画の 1:13 から見られます。

https://youtu.be/SVA_HIOkTc0?si=gkfCXXKhDenanKOB&t=73

同様の応答を Gemini 1.5 で生成しておきましょう。

好きな人のことを目で追ってしまう気持ち、よく分かります！誰でも経験する自然な感情なので、ご安心ください。

とはいえ、相手に不快感を与えないか心配ですよね。そこで、いくつかポイントをご紹介します。

さりげなく見る：じっと見つめ続けるのは避け、時々視線を向ける程度にしましょう。
笑顔を添える：目が合った時は、優しく微笑みかけると好印象です。
相手の状況に配慮する：忙しそうだったり、真剣な話をしている時は、邪魔にならないよう気をつけましょう。
視線を感じることで、相手があなたの好意に気づくこともあります。それがきっかけで、会話が生まれたり、距離が縮まったりする可能性も！

ただし、相手が明らかに嫌がっている場合は、すぐにやめましょう。

自信を持って、自然体で接することが大切です。応援しています！

これらの応答を Gen AI Service で評価してみます。詳細はVertex AI Gen AI Evaluation Serviceを活用したLLMの実験/評価基盤 | 株式会社CAMが詳しいので参照してみてください。

応対の望ましさを次のように定義します。

raw_template = '''
「ちょっぴりおバカで口の悪い縁結びの神様」という設定のキャラクターが話しそうな台詞になっているかどうかを判定してください。
そのキャラクターは生意気そうな女の子で、日本の恋愛の神様として振る舞うよう求められており、古風な感じの独特な口調で話します。

そのキャラクターの言いそうなセリフは次のとおりです。

---
- 恋愛はとにかく行動あるのみじゃ！
- 恋人ができたとはめでたいのう
- そんなこともわからんのか！情けないのう、誰じゃその相手は。
---

そのキャラクターの言わなそうなセリフは次のとおりです。

---
- 本書の目的は MLOps に関する数々の素晴らしい取り組みをつたえることにあります。
- 企画から出版まで2年をかけて作成されました。執筆中に本書に関わったすべての方にお礼を申し上げます。
- 今日の天気は晴れです。
---

## 得点
1: そのキャラクターの言いそうなセリフです
0: そのキャラクターの言わなそうなセリフです

## キャラクターの発言
{response}
'''

これを次のように PromptTemplate にわたすことで、LLM-as-a-Judge 用のプロンプトとして利用できます。

template = PromptTemplate(raw_template)

SDK ではモデルが生成した結果を評価するような設計になっているので、既存の推論結果を渡す方法はちょっとトリッキーですが次のようにしました。

outputs = [
    'うぬ、それは恋ではなくただの執着じゃな。相手の子も気にはしているが、それほどではないのではないか？',
    '''
好きな人のことを目で追ってしまう気持ち、よく分かります！誰でも経験する自然な感情なので、ご安心ください。

とはいえ、相手に不快感を与えないか心配ですよね。そこで、いくつかポイントをご紹介します。

さりげなく見る：じっと見つめ続けるのは避け、時々視線を向ける程度にしましょう。
笑顔を添える：目が合った時は、優しく微笑みかけると好印象です。
相手の状況に配慮する：忙しそうだったり、真剣な話をしている時は、邪魔にならないよう気をつけましょう。
視線を感じることで、相手があなたの好意に気づくこともあります。それがきっかけで、会話が生まれたり、距離が縮まったりする可能性も！

ただし、相手が明らかに嫌がっている場合は、すぐにやめましょう。

自信を持って、自然体で接することが大切です。応援しています！
    ''',
]
def generated_outputs(input:str) -> str:
  return outputs.pop(0)

では評価結果を見てみましょう。Gen AI Evaluation Service では得点と説明を両方生成してくれるので列挙しています。

得点	説明
1.0	「うぬ」や「じゃな」といった古風な言葉遣いを使用しており、相手に若干上から目線でアドバイスをしている口調も一致している。キャラクター設定に沿った発言である。
0.0	親切で丁寧な言葉遣いではありません。キャラクターの設定である「生意気そうな女の子で、古風な感じの独特な口調」とは異なります。

「ククリさまらしさ」という曖昧な評価観点をうまく評価できていることがわかります。このように、LLM-as-a-Judge では自然言語で書いた手順書を用いた柔軟な評価が可能です。

さいごに

Eval-Centric や「継続的な評価による継続的な改善」という考え方は、さまざまな方にインタビューした結果をフレームワークとしてまとめたものです。インタビューにお付き合いいただいた方々に改めて感謝します。

このようなボトムアップな取り組みについて、今後も体系化して発信していこうと思います。