T最新テックトレンド

スケーラブルなLLM評価パイプライン：GenAI時代のAIエージェント開発を加速する秘訣

AI Engineer
0:00--:--

生成AIの波は、私たちの技術的景観を劇的に変化させています。OpenAIのGPTシリーズから、AnthropicのClaude、そしてGoogleのGeminiに至るまで、大規模言語モデル（LLM）は日々進化を遂げ、その能力は驚くべき速度で向上しています。これに伴い、LLMを基盤とした「AIエージェント」の開発が活発化しており、ビジネスにおける新たな価値創造のフロンティアとして注目されています。

しかし、この急速な進化の裏側には、開発者たちが直面する複雑な課題があります。特に、AIエージェントが期待通りに機能し、ビジネス目標に貢献しているかを正確に把握するための「評価（Evaluation）」は、GenAI時代において最も重要な、しかし最も難しい領域の一つとなっています。

本記事では、AI Engineering World's FairでのDat Ngo氏による発表に基づき、スケーラブルなLLM評価パイプラインの構築に焦点を当てます。Arise AIのAIアーキテクトであるDat Ngo氏は、Day 0からobservabilityとevalsの構築に携わってきた経験から、RedditやDuolingoといった世界トップクラスのAIチームがどのようにこの課題に取り組んでいるかを共有しました。私たちは、その深い洞察と具体的なアプローチを掘り下げ、読者の皆様がGenAI開発を加速させるためのヒントを提供します。

GenAI開発の核心 - ObservabilityとEvaluationの融合

AIエージェントを開発し、運用する上で、私たちは常に2つの根本的な問いに直面します。

  1. Observability（可観測性）: アプリケーションで何が起きているのか？問題の根本原因を特定できるか？
  2. Evaluation（評価）: 構築したAI製品が基準通りに機能しているか？

これら2つの要素は、GenAIシステムの健全な開発と運用に不可欠であり、究極的には「実験と改善」という目標に集約されます。システムをどこで改善すべきか、どのように反復すべきかを知るために、ObservabilityとEvaluationは密接に連携する必要があります。

Observabilityとは何か？

Observabilityは、システムが実際に何をしているのかを理解するための基盤です。従来のソフトウェア開発ではログ、メトリクス、トレースが主要なツールでしたが、AIシステム、特にLLMベースのエージェントにおいては、その複雑性から新たな視点が必要となります。

Dat Ngo氏は、Observabilityの具体例として以下の点を挙げます。

  • トレースとスパン: これらは、リクエストがシステム内をどのように伝播し、どのコンポーネントが関与し、どれくらいの時間がかかったかを詳細に記録します。AIエージェントの内部動作を深く掘り下げ、ボトルネックや予期せぬ挙動を特定するために不可欠です。例えば、LangChainのようなフレームワークを使用している場合、各チェーンやツール呼び出しが独立したスパンとして表現され、全体の処理フローを視覚的に把握できます。
  • 会話レベルの観測: AIプロダクトマネージャー（AI PM）のような非技術的な役割を持つ人々にとっては、個々のトレースの詳細よりも、ユーザーとの会話全体がどのように進行しているか、どのような問題が発生しているかを把握することが重要です。これにより、製品のUX（ユーザー体験）やビジネスへの影響をより直接的に評価できます。
  • アナリティクス（ダッシュボード）: 過去のデータに基づいて集計されたメトリクスを視覚的に表示するダッシュボードは、トレンドの把握や異常検知に役立ちます。例えば、一定期間におけるLLMのレイテンシ、コスト、トークン使用量、または特定の評価スコアの推移などを監視することで、システム全体の健全性を一目で確認できます。

最近では、LLMチームは大きく2つの特殊なニッチに分かれつつあるとDat Ngo氏は指摘します。一つはモデルゲートウェイやインフラストラクチャを担当する「プラットフォームチーム」で、コストやレイテンシなどのシステム性能に重点を置きます。もう一つは、ビジネスロジックに特化し、アプリケーションを構築する「LLMチーム」で、主に「評価」の結果に関心があります。これらのチーム間の責任分担を理解することは、適切なObservability戦略を立てる上で重要です。

Evaluationとは何か？

Evaluationは、構築したAI製品が実際にビジネス目標や技術的基準に従ってどの程度機能しているかを定量的に判断するプロセスです。Dat Ngo氏は、Evaluationを「Signal（信号）」と表現し、何がうまくいっていて、何がうまくいっていないかを理解するための重要な手段であると強調します。

LLMベースのエージェントにおいては、手動による評価はスケーラブルではありません。例えば、Duolingoのような大規模なサービスでは、1つのユーザーとの会話の「トレース」に対して、実に約20もの評価（Eval）を実行しています。これを手動で行うことは現実的ではなく、自動化された評価パイプラインが必須となります。評価は単なるモデルの性能指標だけでなく、開発プロセス全体をガイドし、意思決定を支援する羅針盤の役割を果たすのです。

アプリケーションに最適な評価メトリクスを設計する

効果的なLLM評価パイプラインを構築するためには、アプリケーションの特性に応じた適切なメトリクスを選択することが不可欠です。Dat Ngo氏は、以下の4つの主要なメトリクスカテゴリと、開発段階と本番運用段階でそれぞれ重視すべき点を提示しました。

1. LLM as a Judge (LLMを評価者として使用)

これは、別のLLMに、生成された応答やプロセスを評価させる手法です。人間が評価するよりもはるかにスケーラブルで、様々なタスクに適用できます。

  • 異なるタスクへの適用: 質問応答、要約、情報抽出など、多岐にわたるタスクに対応するテンプレートベースの評価が可能です。
  • Encoder-only BERTトークン分類器: LLMを評価者として使用するだけでなく、より軽量で高速なモデル（例: BERTベースの分類器）も利用できます。これらはLLMよりも10倍安価で、1～2桁高速に評価を実行できるため、大規模な評価においてコストと速度の面で大きなメリットをもたらします。
  • RAG (Retrieval Augmented Generation) システムの評価: RAGは、外部知識ベースから情報を取得し、それを基にLLMが応答を生成するシステムです。その評価は多角的であり、Query、Retrieved Context、Generated Answer、そして時にはGround Truth Answerの各要素間の関係性を評価します。
    • QA Correctness: 生成された回答がGround Truth Answer（真の回答）と比較してどの程度正確か。
    • Answer Relevance: 生成された回答がユーザーのQuery（質問）にどの程度関連しているか。
    • Context Recall: 取得されたコンテキストが、Ground Truth Answerをサポートする情報をどの程度含んでいるか。
    • RAG Relevance: 取得されたコンテキストが、Queryにどの程度関連しているか。
    • Groundedness/Faithfulness: 生成された回答が、取得されたコンテキストに対してどの程度事実に基づいているか。

なぜLLM評価が良い指標なのか？Dat Ngo氏は、認知的な観点から「思慮深く、簡潔で正確な要約を生成すること」は、「すでに書かれたコーパスに対する比較分析を行うこと」よりもはるかに難しいと説明します。つまり、LLMはクリエイティブな生成よりも、既存の情報を評価することに長けているため、信頼性の高い評価指標となり得るのです。

2. Code/Logic Based Evals (コード/ロジックベースの評価)

特定のロジックやルールに基づいて行われる評価です。LLMや人間の介入なしに実行できるため、非常に安価で高速です。

  • 構造化された検証: 出力が特定の構造（例：JSON形式）に従っているか。
  • キーワードの有無: 出力に特定のキーワードやフレーズが含まれているか、または含まれていないか。
  • 正規表現マッチング: 出力が特定のパターン（例：日付形式、URL）に一致するか。
  • 型チェック/バリデーション: 生成されたコードの構文が正しいか、期待される型に一致するか。
  • 成功したPython/TypeScriptの実行: 生成されたコードが実際に実行可能で、期待される結果を返すか。
  • Rouge/Bleu: 要約や翻訳の品質を評価する伝統的なメトリクス。

これらの評価は、システムが基本的な要件を満たしているか、あるいは特定の誤りを犯していないかを迅速にチェックするのに適しています。

3. Annotations (アノテーション)

人間が手動でデータにラベル付けを行うことで、高品質な評価データセットを作成します。

  • ゴールデンデータセット: 信頼できる人間の専門家がラベル付けしたデータセット。これは、LLM as a Judgeの性能を検証・チューニングするための「真実の基準」となります。
  • ラベル付けの粒度: 良好/不良、正確/不正確、あるいは0-1のスコアリング。
  • ノート（テキスト）: 人間が評価した際の詳細なコメントや洞察。
  • 合成生成データ: 特定のシナリオをカバーするために合成されたデータで、アノテーションの補完に使用されることもあります。

Dat Ngo氏は、プロチップとして、LLM as a Judgeをゴールデンデータセットで実行することを推奨します。これにより、「LLMは私が信頼するものをどの程度近似できるか？」という問いに答え、LLM as a Judge自体の信頼性を定量化し、チューニングすることが可能になります。

4. User Based Feedback (ユーザーベースのフィードバック)

本番環境でユーザーから直接得られるフィードバックは、AI製品の実世界でのパフォーマンスを測る上で最も貴重な情報源です。

  • 高評価/低評価: ユーザーが生成された応答に対して好意的か否かを直接示す。
  • 応答の承認/拒否: 生成されたコンテンツがユーザーのタスク解決に役立ったか否か。
  • 顧客が人間へのエスカレーション: AIエージェントがユーザーの質問に対応できなかった場合、どれくらいの頻度で人間が介入する必要があったか。
  • 会話の予期せぬ終了: ユーザーが会話を途中で放棄した頻度。
  • 推薦CTR (Click Through Rate): AIが推薦したアイテムがどの程度クリックされたか。
  • 顧客の採用率: AIエージェントが顧客にどの程度受け入れられ、利用されているか。

これらのビジネスメトリクスは、AIエージェントが最終的に事業目標に貢献しているかを判断するための究極的な指標となります。

開発段階では、LLM as a Judgeやコード/ロジックベースの評価が中心となり、迅速な反復と基本的な品質保証に役立ちます。一方、本番運用段階では、ユーザーフィードバックやビジネスメトリクスが、製品の市場適合性や実際の価値を測る上で不可欠です。これらのメトリクスをバランスよく組み合わせることで、GenAIアプリケーションのライフサイクル全体を通じて、継続的な改善を可能にする評価パイプラインを構築できます。

AIエージェントの自己改善サイクルを構築する

AIエージェントは、単一の静的なモデルではなく、継続的に学習し、改善していく「自己改善システム」として捉えるべきです。Dat Ngo氏は、この自己改善サイクルを2つの連携する円として説明します。

  1. エージェントの改善サイクル (Improve Agent):

    • データ収集 (Collect Data): まず、Observabilityツール（トレース、ログなど）を通じて、エージェントの実際の運用データを収集します。これにより、エージェントがどのように機能し、どのような入力に対してどのような出力を生成しているかを知ることができます。
    • 評価実行 (Run Evals): 収集したデータに対して、前述の多様な評価メトリクス（LLM as a Judge、コード評価など）を実行します。これにより、エージェントのパフォーマンスの良し悪しを定量的に把握します。
    • 失敗の特定 (Collect Dataset of Failures): 評価結果に基づき、エージェントが期待通りに機能しなかった「失敗」の事例を特定し、データセットとして収集します。例えば、ハルシネーション（幻覚）を起こした応答、誤ったツール選択、不適切な制御フローなどが該当します。
    • ゴールデンデータセットのアノテーション (Annotate for Golden Dataset): 収集した失敗事例の一部、または特に重要な事例について、人間の専門家が手動で正しい挙動や期待される出力をラベル付けし、「ゴールデンデータセット」を構築します。これは、後の改善の指針となります。
    • プロンプト/モデルの改善 (Improve Prompt / Fine-Tune): 失敗の原因を分析し、それに基づいてエージェントのプロンプトを改善したり、基盤モデルをファインチューニングしたり、エージェントのオーケストレーションロジックを変更したりします。

  2. 評価自体の改善サイクル (Improve Evals):

    • 失敗の特定 (Collect Dataset of Failures): エージェントの改善サイクルと同様に、評価が低信頼度で実行された、あるいは矛盾する結果を示した事例を特定します。これは、評価者としてのLLMが間違った評価を下したケースや、コードベースの評価ロジックに欠陥があったケースなどが該当します。
    • ゴールデンデータセットのアノテーション (Annotate for Golden Dataset): これらの評価の失敗事例に対しても、人間の専門家が正しい評価結果をラベル付けし、ゴールデンデータセットを構築します。
    • 評価プロンプト/ゴールデンデータセットの改善 (Improve Eval Prompt / Golden Dataset): 評価自体の失敗の原因を分析し、LLMを評価者として使用している場合はそのプロンプトを改善したり、評価ロジックを修正したり、あるいはゴールデンデータセット自体を拡張・修正したりします。

この2つのサイクルは密接に連携し、継続的に繰り返されます。Dat Ngo氏は、AIエンジニアリングチームにとってのプロチップとして、「速度」の重要性を強調します。1ヶ月に2回のイテレーションしかできないチームと、4回のイテレーションができるチームでは、時間の経過とともにAI製品の品質に指数関数的な差が生まれるでしょう。迅速なフィードバックループと改善サイクルを確立することが、GenAI開発成功の鍵を握ります。

複雑なAIエージェントアーキテクチャの評価戦略

AIエージェントの複雑化は、評価の難易度をさらに引き上げます。単一のLLMコールではなく、複数のLLM、外部API、アプリケーションコードが連携し、複雑な制御フローを持つシステムが一般的になりつつあります。

チャット-ツー-購入ルーターのケーススタディ

Booking.comの「トリッププランナー」は、LLMをベースとした旅行代理店のようなAIエージェントの好例です。これは、フライトやホテルの予約、旅程の提案など、様々なタスクを実行するために、複数のコンポーネントを連携させる「ルーター」アーキテクチャを採用しています。

このルーターは、ユーザーからの入力（例：「ニューヨークへの旅行を計画して」）を受け取ると、以下のような一連のプロセスを実行する可能性があります。

  1. ユーザーインテントの分類: ユーザーの目的（フライト検索、ホテル予約、サポートなど）を特定。
  2. 商品比較: 類似商品の価格や特徴を比較するAPIを呼び出す。
  3. 検索APIの呼び出し: 実際のフライトやホテルの情報を取得する。
  4. 商品ランキング: 検索結果をユーザーの好みに合わせて並べ替える。
  5. 商品要約: 取得した商品の詳細をユーザーにわかりやすく要約する。
  6. 顧客サポート: ユーザーが特定の問題を抱えている場合にライブエージェントにエスカレートする。
  7. 注文追跡: 予約状況を確認する。

このような複雑なフローを持つシステムを評価する際には、以下の点を考慮する必要があります。

  • コンポーネントレベルの評価: 個々のLLMコール、内部APIコール、あるいはアプリケーションコードの各ステップで評価を実行できます。例えば、特定の検索APIが正確な情報を返しているか、商品要約が適切に行われているかなどです。
  • 入出力全体の評価: 特定のコンポーネントだけでなく、より大きなワークフロー全体の入出力も評価対象となります。例えば、ユーザーの初期入力に対する最終的な応答が、全体の目標を達成しているか。
  • 制御フローの評価: 特に重要なのは、エージェントが適切な経路を選択しているかを評価することです。Dat Ngo氏は、もしエージェントが制御フローの早い段階で誤ったパスを選択した場合、その後のすべての処理は無意味になる可能性があると指摘します。
    • 条件付き評価: あるコンポーネントの評価が失敗した場合、その後の依存するコンポーネントの評価をスキップすることで、時間とコストを節約できます。例えば、フライト検索が失敗した場合、その後のホテル予約や旅程生成の評価は行わないといった具合です。

Arise AIのコパイロットエージェントアーキテクチャ

Arise AIは、AIシステム自体のトラブルシューティングや評価を行うための「AIコパイロットエージェント」を構築しています。このアーキテクチャは、ユーザーからの質問に対して、以下のような複数の専門エージェントを連携させます。

  • Tabular Agent: モデルインサイト、データドリフト、品質チェック、パフォーマンス監視、特徴量分析などの表形式データに関するタスク。
  • Eval Agent: カスタム評価の作成、ダッシュボード生成、評価プロンプト生成など、評価関連のタスク。
  • Analysis Agent: 異常診断、データセット生成、スパイクチャット分析などの分析タスク。
  • Search Agent: カラム検索などの検索タスク。
  • Prompt Agent: プロンプト最適化、埋め込み要約などのプロンプト関連タスク。
  • Computer Vision Agent: クラスタ分析などの画像関連タスク。

このような複雑なマルチエージェントシステムにおいて、人間が手動で全ての挙動を評価することは不可能です。Dat Ngo氏は「5年後、10年後、AIシステムを評価するのは人間ではなく、AIだろう」と語り、AIによるAI評価の必要性を強調します。Arise AIのコパイロットは、その第一歩となるアーキテクチャです。

エージェント評価のさらなる複雑性

エージェントの評価は、個々のLLMコールやAPI呼び出しのトレースを見るだけでは不十分です。

  • トレースの複雑化: エージェントが実行するパスは長くなり、非常に多くの分岐や再帰を含む可能性があります。
  • エージェント全体のパス分析: エージェントがどのように意思決定を下し、どのツールを呼び出し、どのような順序でプロセスを実行したか、その全体の「パス」を理解することが重要です。
    • パスの頻度: 特定のツールがどれくらいの頻度で呼び出されたか。
    • パスにおける評価: 特定のパスを辿った場合に、各ステップでどのような評価結果が得られたか。例えば、「コンポーネント1→2→3」のパスでは評価が良好だが、「コンポーネント1→2→4」のパスでは評価が低下する、といった傾向を把握します。これは、依存関係や特定のコンポーネントの組み合わせが問題を引き起こしている可能性を示唆します。
  • フレームワーク非依存性: 開発チームはLangChain、CrewAI、手書きのコードなど、様々なエージェント構築フレームワークを使用します。評価パイプラインは、これらの多様な環境からデータを収集し、一貫した方法で分析できる必要があります。
  • 軌跡 (Trajectory) 評価:
    • 特定の入力に対して、エージェントがどのようなコンポーネントを、どのような順序で呼び出すかという「期待される軌跡」を定義し、実際の軌跡と比較して評価します。
    • この軌跡データは、入れ子になったキーバリューペアのシーケンスとして表現でき、LLMもこのような構造を理解して評価するのに適しています。
    • さらに、軌跡評価は、必ずしも厳密なGround Truth Answerを必要とせず、「この一連のプロセスは全体として期待される結果につながったか？」という視点で創造的に評価を行うことも可能です。

ガードレールとObservability+Evalsのバランス

GenAIアプリケーションの安全性と信頼性を確保するために「ガードレール」の導入を検討する組織も少なくありません。しかし、ガードレールは銀の弾丸ではありません。

ガードレールの役割と限界

ガードレールは、AIエージェントが危険なコンテンツを生成したり、不適切な行動をとったりするのを防ぐための安全対策です。

  • リスクの軽減: 不適切な応答や誤ったツール利用といった「既知の危険」を回避するのに役立ちます。これはユニットテストのようなもので、特定の条件下での振る舞いを保証します。
  • コスト: ガードレールは、アプリケーションの実行パスに追加のチェックポイントを設けるため、レイテンシ（遅延）としてユーザーエクスペリエンスに影響を与える可能性があります。
  • 複雑性: 元々のAIシステムに加えてガードレールという別のシステムを導入することは、全体の複雑性を増大させます。2つのシステムが互いに連携し、一方がもう一方をチェックするという構図は、デバッグやメンテナンスをより困難にする可能性があります。
  • 根本原因ではない: Dat Ngo氏は「多くの人がガードレールを調整すべきものだと誤解している」と強調します。「いやいや、まずプロンプトを直してください」と。ガードレールは症状を抑えるものですが、問題の根本原因は、エージェントのプロンプト設計やオーケストレーションロジック（システム1）にあることが多いのです。ガードレールは、システム1の弱点をカバーするための「システム2」として機能しますが、真の解決策はシステム1自体の改善にあります。
  • 完璧ではない: ガードレールは「既知の既知（known knowns）」の脅威に対しては効果的ですが、「未知の未知（unknown unknowns）」、つまり予測不能なユーザー入力やLLMの予期せぬ挙動に対しては、完全には対応できません。LLMのユーザーは「クレイジー」な質問をする可能性があり、ガードレールだけでは全てをカバーできないのが現実です。

Observability + Evalsの真価

ここでObservabilityとEvaluationが真価を発揮します。

  • 未知の挙動への対応: ObservabilityとEvaluationの組み合わせは、ガードレールが対応できない未知の挙動や予期せぬ結果を発見し、診断し、改善するための唯一の有効な手段です。
  • OpenTelemetry (OTel) の重要性: 分散システムやマイクロサービスアーキテクチャでは、複数のサービスやDockerコンテナにまたがる非同期なプロセス全体でデータを追跡する必要があります。OpenTelemetryは、この課題を解決するためのオープンスタンダードであり、Dat Ngo氏はArise AIが2年半前にOTelファーストの戦略を採用し、それが非常に成功したと語ります。OTelを利用することで、システム全体にわたる詳細なトレースを収集し、LLMエージェントの複雑なフロー全体を可視化・評価することが可能になります。
  • 自信度スコア (Log Prob) の活用: 自動回帰モデル（多くのLLMがこれに該当）を使用している場合、モデルは各トークン生成の対数確率（Log Probability）を出力できます。このLog Probは、特定の応答に対するモデルの「自信度」を示す指標として利用でき、評価の信頼性を補完するのに役立ちます。
  • 自動最適化の未来 (Meta-Prompting): Dat Ngo氏は、LLMの評価と改善をさらに自動化する未来についても言及しました。それは「メタプロンプティング」と呼ばれるアプローチです。エージェントの入力-出力ペアと、それに対する評価結果を別のLLMに与え、「このデータセットにおける失敗を修正する新しいプロンプトを生成せよ」と指示することで、LLM自身がプロンプトの改善案を自動で生成できるようになります。これにより、開発者は手動でのプロンプトエンジニアリングの負担を軽減し、より迅速な改善サイクルを実現できる可能性があります。

これらの技術と戦略を組み合わせることで、私たちは単に既存のバグを修正するだけでなく、AIエージェントが進化するにつれて出現する新たな課題にも対応し、より堅牢でインテリジェントなGenAIシステムを構築できるようになるでしょう。

結論

GenAIの時代において、AIエージェントの開発はかつてないほどの興奮と可能性に満ちています。しかし、そのポテンシャルを最大限に引き出し、ビジネスにおける実用的な価値を創出するためには、堅牢でスケーラブルな評価パイプラインが不可欠です。

Dat Ngo氏がAI Engineering World's Fairで示したように、Observabilityは「何が起きているか」を理解し、Evaluationは「期待通りに機能しているか」を判断するための羅針盤です。これら2つを融合させることで、LLM as a Judge、コードベースの評価、アノテーション、ユーザーフィードバック、ビジネスメトリクスといった多様なツールを組み込み、継続的な自己改善サイクルを回すことが可能になります。

特に、Booking.comの旅行プランナーやArise AIのコパイロットエージェントのような複雑なシステムにおいては、個々のコンポーネントだけでなく、制御フロー全体や軌跡を評価する高度な戦略が求められます。ガードレールはリスクを軽減するものの、根本的な解決策はエージェントの設計自体にあり、OpenTelemetryのような分散トレーシング技術が、この複雑な環境を可視化し、評価する上で中心的な役割を果たすでしょう。

AIエンジニアリングの未来は、AIがAIを評価し、AIがAIを改善する世界へと向かっています。この変革期において、本記事で紹介した戦略とツールは、開発者の皆様がGenAIの無限の可能性を解き放ち、より信頼性の高い、より高性能なAIエージェントを構築するための強力な指針となるはずです。

参考文献

  • Engineering Better Evals: Scalable LLM Evaluation Pipelines That Work by Dat Ngo (AI Engineer World's Fair)
  • OpenTelemetry Documentation
  • Arise AI Official Website

免責事項: 本記事は、Dat Ngo氏の発表内容に基づき、筆者の解釈と追加情報を含んで構成されています。特定の製品や技術を推奨するものではなく、GenAI開発における評価の重要性と多様なアプローチを理解することを目的としています。

← 一覧に戻る