MLflow 2.8「LLM-as-a-judge」メトリクス、およびRAGアプリケーションのLLM評価におけるベストプラクティス（パート2）を発表

本日、MLflow 2.8が、当社の「LLM-as-a-judge」メトリクスをサポートしたことを発表できることを嬉しく思います。これは、人間が判断したメトリクスの近似値を提供しながら、時間とコストの節約に役立ちます。以前のレポートでは、「LLM-as-a-judge」という手法がDatabricksドキュメント AI Assistantにおいて、いかに効率を高め、コストを削減し、人間のスコアと80%以上の一貫性を維持するのに役立ったかについての導入事例を説明しました。その結果、時間（人間の労働力で2週間かかっていたものがLLM審査員では30分に）とコスト（タスクあたり20ドルから0.20ドルに）の大幅な節約が実現しました。また、RAG（Retrieval Augmented Generation）アプリケーションの「LLM-as-a-judge」評価のベストプラクティスに関する以前のレポートに続き、以下にパート2を掲載します。データクリーニングと組み合わせて、同様の方法論を適用し、独自のRAGアプリケーションのパフォーマンスを評価および調整する方法を順を追って説明します。以前のレポートと同様に、「LLM-as-a-judge」は、LLMベースのアプリケーションの有効性を測定するために必要な評価手法群の中で、有望なツールの1つです。多くの状況で、これは最適な選択肢であると考えています。（チャットボットからの応答のような）非構造化出力を、自動で、迅速に、そして低コストで評価できます。この意味で、私たちはこれを人間による評価の優れた補完機能であると考えています。人間による評価は、より時間がかかり高価ですが、モデル評価のゴールドスタンダードです。

評価にサードパーティのLLMサービス（OpenAIなど）をご利用の場合、当該LLMサービスの利用規約が適用されることがあります。

MLflow 2.8: 自動評価

LLM コミュニティでは、自動評価のために"審査員としての LLM"の利用が模索されており、私たちはその理論を本番プロジェクトに応用しました。最先端のLLM (GPT、MPT、Llama2モデルファミリーなど) を使用し、各基準に対して単一の評価例で自動評価を行うことで、コストと時間を大幅に節約できることがわかりました。MLflow 2.8では、LLM評価のための強力でカスタマイズ可能なフレームワークが導入されています。MLflow Evaluation API を拡張し、GenAI メトリクスと評価例をサポートするようになりました。toxicity、latency、トークン などのすぐに使えるメトリクスに加えて、faithfulness、answer_correctness、answer_similarity のように、default の判定者として GPT-4 を使用するいくつかの GenAI メトリクスも利用できます。MLflow には、GenAI メトリクスであっても、いつでもカスタムメトリクスを追加できます。MLflow 2.8 の実際の動作を、いくつかの例で見てみましょう！

LLM-as-a-judge手法でカスタムGenAIメトリクスを作成する際には、審査員として使用するLLMを選択し、採点尺度を定め、その尺度における各評点の例を提示する必要があります。MLflow 2.8で`professionalism`のGenAIメトリックを定義する例を以下に示します。

前回のレポートで見たように、評価例 (上記のスニペットの `examples` リスト) は、LLM が判定するメトリクスの精度向上に役立ちます。MLflow 2.8 では、EvaluationExample を簡単に定義できます。

MLflow 2.8 では、お客様が必要とする一般的なメトリクスに対応するため、いくつかの GenAI メトリクスをすぐに使える形でサポートしています。アプリケーションの `model_type` (「question-answering」など) を指定すると、MLflow Evaluate API が一般的な GenAI メトリクスを自動的に生成します。次の例で「Answer Relevance」を使用しているように、「extra」メトリクスを追加することもできます。

パフォーマンスをさらに向上させるために、これらのすぐに使える GenAI メトリクスに対して、判定モデルとプロンプトを変更することもできます。以下は、[評価] タブで GenAI メトリクスを視覚的にすばやく比較するのに役立つ MLflow UI のスクリーンショットです。

また、対応する eval_results_table.json で結果を表示したり、Pandas データフレームとして読み込んでさらに分析したりすることもできます。

RAG アプリケーションへの LLM 評価の適用: パート 2

次の一連の調査で、Databricks ドキュメント AI アシスタントの本番運用アプリケーションを再検討し、入力データの品質を向上させることでパフォーマンスを改善できるかどうかを確認しました。この調査から、チャットボットの回答の正確性と読みやすさを高め、トークン数を減らしてコストを削減し、速度を向上させるために、データを自動的にクリーンアップするワークフローを開発しました。

RAG アプリケーションの効果的な自動評価のためのデータ クリーニング

私たちは、チャットボットの応答パフォーマンスに対するデータ品質の影響と、パフォーマンスを向上させるためのさまざまなデータクリーニング手法について調査しました。これらの調査結果は一般化でき、チームがRAGベースのチャットボットを効果的に評価するのに役立つと考えます。

• データクリーニングにより、LLMが生成した回答の正確性が最大で+20%向上しました（5段階評価で3.58から4.59へ）。
• データクリーニングの予期せぬ利点は、必要となるトークンが少なくなることでコストを削減できる点です。データクリーニングにより、コンテキストのトークン数が最大-64%削減されました (インデックス付きデータの965538トークンからクリーニング後の348542トークンへ)。
• LLMによって、より良く動作するデータクリーニングコードは異なります。

RAGアプリケーションにおけるデータの課題

RAGアプリケーションには、ウェブサイトページ、PDF、Googleドキュメント、Wikiページなど、さまざまな入力データ型があります。業界や顧客から最も頻繁に使用されるデータ型は、ウェブサイトとPDFです。当社のDatabricks Document AI Assistantは、公式のDatabricksドキュメント、ナレッジベース、およびSparkドキュメントページをデータソースとして使用します。ドキュメントのウェブサイトは人間が読める形式ですが、その形式はLLMには理解しにくい場合があります。以下は一例です。

ここでは、Markdown形式とコードスニペットの言語オプションにより、各言語に対応する例を提示するための分かりやすいUIが提供されます。しかし、このUIがLLM向けに純粋なMarkdown形式に変換されると、コンテンツが繰り返し現れる複数のコードブロックに変換されてしまい、理解が困難になります。その結果、mpt-7b-chat にコンテキストを与えて「How do you configure a different default catalog name?」という質問をしたところ、「``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ``` ```」という回答を返しました。これはコードブロック記号の繰り返しです。他のケースでは、LLMが指示に従えず、質問を繰り返し始めてしまいます。同様に、ウェブページには、ブラウザがより良いUIをレンダリングするために利用する様々なアイコン、画像、特殊記号が含まれていることがあり、これらもLLMを混乱させます。注: 代替アプローチとして、プロンプトを変更してフォーマットマークアップを無視させる方法があります。しかし、私たちは特定のアプリケーションに合わせてプロンプトをさらに調整することを想定しており、プロンプトが過度に複雑になったり不安定になったりすることは避けたいと考えています。

データ クリーニングはパフォーマンスを向上させます。

LLM-as-judge を活用し、Markdown ファイルやウェブページから無関係なフォーマット トークンを削除するためのクリーンアップ コードを反復的に見つけ出す簡単なワークフローを作成しました。以下は、単一のドキュメントがクリーンアップの前後でどのように表示されるかの例です。ドキュメントがその構造と意味の両方を保持していることを示しています。

また、ドキュメントのクリーンアップによってLLMのコンテキストウィンドウで使用されるトークン数が大幅に削減され、コストと時間が節約されることも明確にわかります。データクリーニング後、MPT-7B-Chatからの回答に改善が見られました。

自動評価のために、今すぐ MLflow 2.8 をお試しください

分析のパート2では、MLflow 2.8を使用して、LLM-as-a-judgeでRAGアプリケーションを評価しました。データクリーニングと自動評価により、さまざまなLLMを迅速かつ効率的に比較対照し、RAGアプリケーションの要件を検討できるようになりました。開始に役立つリソース：

• MLflow 2.8 ドキュメント
• RAG向けMLflow評価のチュートリアル
• Q&A のための MLflow 評価チュートリアル
• LLM-as-a-judgeメトリックを用いたRAGアプリケーションの評価、パート1
• データクリーニングのコードサンプル（gist）