コースを安定させる:LLMベースのアプリケーションの評価をナビゲートする
コースを安定させるためのナビゲーション:LLMベースのアプリケーション評価を効果的にする方法
LLMアプリの評価の重要性と開始方法
イントロダクション
Large Language Models(LLM)はとても注目されており、多くの人々がそれらをアプリケーションに取り入れています。関係データベースに対する質問に答えるチャットボット、プログラマが効率的にコードを書くのを支援するアシスタント、代わりに行動を起こす共同乗組員などがその例です。LLMの強力な機能により、迅速な初期の成功でプロジェクトを開始することができます。それにもかかわらず、プロトタイプから成熟したLLMアプリに移行するにつれて、堅牢な評価フレームワークが不可欠となります。そのような評価フレームワークは、LLMアプリが最適な性能に達し、一貫性と信頼性のある結果を保証するのに役立ちます。この記事では、以下をカバーします。
- LLMとLLMベースのアプリの評価の違い
- LLMアプリの評価の重要性
- LLMアプリの評価の課題
- 始めるための手順a. データの収集とテストセットの作成b. パフォーマンスの測定
- LLMアプリの評価フレームワーク
海賊のための救急アシスタントであるFirstAidMateyの架空の例を使用して、評価技術、課題、戦略を航海します。最後に、まとめと洞察をご紹介します。さあ、この啓蒙的な旅に出発しましょう!
LLM vs. LLMベースのアプリの評価
OpenAIのGPT-4、GoogleのPaLM 2、AnthropicのClaudeなど、個々のLarge Language Models(LLM)の評価は通常MMLUなどのベンチマークテストで行われます。しかし、この記事では、LLMベースのアプリの評価に興味があります。これらはLLMによって動力づけられ、LLMの呼び出しシーケンスを管理するオーケストレーションフレームワークなどの他のコンポーネントを含んでいます。よく使われるのは、レトリーバル・オーグメンテッド・ジェネレーション(RAG)で、LLMにコンテキストのドキュメントを提供して幻覚を回避します。要するに、RAGはコンテキストドキュメントをベクトルストアに埋め込み、関連するスニペットを検索してLLMと共有することを必要とします。LLMとは異なり、LLMベースのアプリ(またはLLMアプリ)は、1つまたは複数の特定のタスクを非常にうまく実行するために構築されます。適切なセットアップを見つけるには、いくつかの実験と反復的な改善が必要です。たとえば、RAGはさまざまな方法で実装することができます。この記事で議論されている評価フレームワークは、ユースケースに最適なセットアップを見つけるのに役立ちます。
FirstAidMateyは、”手がロープに引っかかり、腫れ上がったので、どうすればいいか、仲間よ?”といった質問に答える、海賊向けのLLMベースのアプリです。そのオーケストレータの最も基本的な形態は、単一のプロンプトで構成され、ユーザーの質問をLLMに与えて役立つ回答を求めます。最適な理解のために、LLMに海賊の言葉で回答するよう指示することもできます。拡張として、埋め込まれた応急処置のドキュメンテーションを持つベクトルストアを追加することができます。ユーザーの質問に基づいて、関連するドキュメンテーションを取得してプロンプトに組み込むことで、LLMがより正確な回答を提供できるようになります。
- メタ&ジョージア工科大学の研究者たちは、気候変動に対抗するための直接空気キャプチャの研究を加速させるための新しいデータセットと関連するAIモデルを公開しました
- 「Rustでの14倍のスピードブーストには、Polarsプラグインの使用がおすすめです」
- クラウドインスタンスのスタートアップスクリプトの構築
LLMアプリの評価の重要性
具体的な手順に入る前に、なぜLLMベースのアプリを評価するシステムを設定する必要があるのか、その理由について見てみましょう。主な目標は次の3つです。
- 一貫性: あらゆるシナリオで安定した信頼性のあるLLMアプリの出力を確保し、リグレッションが発生した場合に発見します。たとえば、特定のシナリオでLLMアプリのパフォーマンスを改善する際には、他のシナリオのパフォーマンスを犠牲にしないように警告を受けたいです。OpenAIのGPT-4のような独自のモデルを使用する場合、更新スケジュールに従う必要があります。新しいバージョンがリリースされると、現在のバージョンは時間の経過とともに非推奨になる可能性があります。研究によると、新しいGPTバージョンに切り替えることが常に良い結果をもたらすわけではないことが示されています。したがって、この新しいバージョンがLLMアプリのパフォーマンスにどのように影響するかを評価できるようにすることが重要です。
- 洞察: LLMアプリがうまく機能する場所と改善の余地を把握することができます。
- ベンチマーキング: LLMアプリのパフォーマンス基準を確立し、実験の効果を測定し、自信を持って新しいバージョンをリリースします。
この結果、以下の成果を得ることができます:
- ユーザーの信頼と満足感を得る:LLMアプリが一貫して動作するため。
- ステークホルダーの信頼を高める:LLMアプリのパフォーマンスや新しいバージョンが以前のものよりも改善されていることを示すことができるため。
- 競争力を向上させる:素早く改善を加え、自信を持って新しいバージョンを展開することができるため。
LLMアプリ評価の課題
上記の利点を読んだ後、LLMベースのアプリケーションの採用が有利であることが明らかです。しかし、その前に次の2つの主な課題を解決する必要があります:
- ラベル付きデータの不足:従来の機械学習アプリケーションとは異なり、LLMベースのアプリケーションは始めるためにラベル付きデータを必要としません。LLMは特定の例を示さなくても多くのタスク(テキスト分類、要約、生成など)をすぐに実行できます。これはデータとラベルを待つ必要がないため非常に素晴らしいことですが、一方でアプリケーションのパフォーマンスを確認するためのデータがないことも意味します。
- 複数の有効な回答:LLMアプリでは、同じ入力に対してしばしば複数の正しい回答が存在することがあります。例えば、チャットボットは類似の意味を持つさまざまな応答を提供するか、コードは同じ機能を持ちながら異なる構造で生成される場合があります。
これらの課題に対処するために、適切なデータと指標を定義する必要があります。次のセクションでそれを行います。
はじめに
データの収集とテストセットの作成
LLMベースのアプリケーションを評価するために、特定の入力とターゲットを持つテストケースのテストセットを使用します。これに含まれる内容は、アプリケーションの目的によります。例えば、コード生成アプリケーションでは口頭の指示が入力として期待され、コードが返されます。評価中に、入力はLLMアプリに提供され、生成された出力は参照ターゲットと比較することができます。以下はFirstAidMateyのいくつかのテストケースです:
この例では、各テストケースには質問が入力として含まれ、正しい参照回答が目標として含まれています。さらに、ヒストリカルな応答やユーザーフィードバックもテストケースに追加することができます。これにより、新しい回答が以前のものよりも改善されているか、ユーザーフィードバックが対応されているかどうかを確認することができます。理想的には、テストセットには検証済みの参照回答が含まれているべきですが、新しいモデルを古いモデルと迅速に比較したい場合は、ヒストリカルな応答とフィードバックを使用することもできます。
通常、データセットなしでLLMベースのアプリケーションの開発を開始するため、テストセットの早期構築が重要です。それは、現在のモデルの不具合の例を追加することによって、反復的に行うことができます。最初は開発者がLLMアプリで最も試行錯誤を行い、マニュアルテストに基づいて最初のテストケースを追加します。それでも、関係するテストケースの理解力がより高いビジネスまたはエンドユーザーをプロセスに早期に関与させることが重要です。テストセットを始めるためには、LLMを使用して、例えば知識ベースに基づいて入力とターゲットのペアを生成することもできます。時間の経過と共に、テストセットはエンドユーザーにとって最も重要なトピックの幅広いスペクトラムをカバーする必要があります。そのため、ユーザーフィードバックを収集し続け、パフォーマンスが低下しているトピックや十分に表現されていないトピックに対してテストケースを追加することが重要です。
評価パフォーマンスの測定
テストケースのセットが与えられたら、入力をLLMアプリに与えて生成された応答を目標と比較することができます。各入力に対して一つの正しい回答が存在しないため、リテラルに応答を参照回答と比較することはできません。応答は意味は同じでも異なる表現方法で表される場合があります。しかし、応答の品質を代用として評価するために、応答のいくつかの特性を評価することができます。テストする必要のある関連特性は、アプリケーションと利用可能なデータに依存します。以下はFirstAidMateyの応答の特性と評価指標の例です:
- 事実の一貫性:生成された回答が参照回答と事実的に整合しているかを評価するためにLLMを使用します。
- 海賊度合い:回答が海賊語で書かれているかどうかを評価するためにLLMを使用します。
- 意味の類似性:生成された回答と参照回答の埋め込み間のコサイン類似度を計算します。これは事実の一貫性よりも計算コストが低く、正しい回答と関連があるとは限りません。
- 冗長性:生成された回答の長さを参照回答の長さで割ります。冗長度が高いほど、LLMアプリの話し方が多弁になることがありますが、それがアプリの意図とは限りません。
- 遅延:LLMアプリが応答を生成するまでにかかる時間を測定します。これにより、より正確ですが遅い構成のトレードオフを行うことができます。
使用ケースに応じて、より多くの/異なるプロパティがあることがあります。たとえば、コード生成LLMアプリの場合、生成されたコードの構文の正確性という追加のプロパティがありますが、これはコードをコンパイラに渡して測定することで評価できます。以下の画像は、プロパティがLLMを使用して評価される様子を示しています。
すべてのプロパティがすべてのテストに対して評価されたら、各メトリックの平均スコアを計算し、基準/目標のパフォーマンスと比較することができます。RAGなどの異なる構成を試行中の場合、テストスコアは最も好ましい候補を示してくれます。正確さ、冗長性、遅延のトレードオフも明確になります。メトリックのスコアに加えて、失敗したケースはさらなる改善のための有用な洞察を提供することができます。失敗したテストの詳細をよく見て、LLMアプリをさらに改善するための有用な洞察を得てください。
LLMが回答を正しくできない場合、同じ回答を評価するのに信頼できるのかと思うかもしれません。自身の出力にバイアスがあるのではないでしょうか?確かに、それは直感に反するように聞こえますが、ここでの主なアイデアは評価は生成よりも簡単であるということです。絵画の作成と評価のたとえを考えてみましょう。絵画を作成する際には、構成、色、透視図法、光と影、質感、意図したメッセージなどの複数のプロパティを同時に考慮する必要があります。一方、絵画を評価する場合は、一度に1つのプロパティに焦点を当てることができます。完成した作品を判断する方が、ゼロから作るよりも簡単です。同じアイデアはLLMにも当てはまります。適切な応答を生成することは挑戦的かもしれませんが、既存の応答を批判的に評価することはより簡単です。参照応答がある場合、例えば事実の一貫性プロパティの場合は、評価はさらに可能になります。
LLMアプリ評価フレームワーク
最後のセクションですべてをまとめましょう。以下の画像は評価フレームワークの概要を示し、重要なフィードバックループを示しています:
- 評価プログラムにLLMアプリ、プロパティ、テストケースが渡されます。評価プログラムはすべてのテストケースをループして、テスト入力をLLMアプリに通します。その結果、プロパティをループして結果を収集し、メトリックとして評価します。
- 評価結果を記録してさらなる分析に使用します。メトリックに加えて、LLMアプリの構成(使用されるLLMとパラメータ、使用されるRAGコンポーネントとパラメータ、システムの提示など)を追跡することも重要です。これにより、最も有望な実験を簡単に区別し、アプリをさらに改善するための洞察を得ることができます。評価結果とLLMアプリの構成を独自のデータベースに保存するか、MLflowのようなツールを使用して、ユーザーフレンドリーなインターフェースに即座にアクセスできます。
- パフォーマンスに満足したら、新しいバージョンを内部もしくは外部のユーザーに公開することができます。
- プロジェクトの初期段階では、テストとフィードバックの収集を行うのは開発者です。後には、エンドユーザーからのフィードバックを直接的に(高評価/低評価やコメントを入力してもらう)または暗黙的に(対話の流れ、セッションの長さ、受け入れられたコードの提案など)収集できます。
- 収集されたフィードバックを分析して、テストケースを追加します。現在のモデルで十分に処理されない、過小評価された状況のためのテストケースを追加しましょう。
- 入ってくるフィードバックの傾向を把握し、LLMアプリを改善しましょう。状況によっては、オーケストレータ(単一のプロンプトではなく、独立したLLM呼び出しのチェーンを作成するなど)、検索プロセス(埋め込みを改善するなど)またはLLM(モデルやパラメータを変更したり、fine-tuningを検討するなど)を改善することができます。
ステップ1と2のイラストについては、次のJupyterノートブックをご覧ください。このノートブックは、このブログ投稿で説明されているコンセプトを示しています。プロパティ、テストケース、およびLLMアプリのバージョンを定義してEvaluatorに送信する方法を確認できます。評価結果を表示するだけでなく、さらなる分析のためにMLflowダッシュボードにもログが記録されます。ぜひチェックして、議論されたトピックをさらに具体化してください。
結論
LLMベースのアプリケーションの評価は、LLMアプリの開発において不可欠な要素です。このブログ投稿で紹介された評価フレームワークは、開発中の実験を比較しやすくし、一貫したパフォーマンスを確保し、さらなる改善のための洞察を提供します。
最初の課題である、ラベル付きデータの不足は、早期にテストセットを構築し、難解で代表されていないケースを追加することで解決できます。2番目の課題である、複数の正解が存在することは、生成された出力のさまざまなプロパティを見ることで克服することができます。これらのプロパティの一部は、簡単な式やルールで測定できますが、他のプロパティはLLMで評価することができます。
最後に、評価結果と収集されたユーザーフィードバックがLLMアプリのパフォーマンスを前進させる重要なフィードバックループを発見しました。結論として、体系的な評価はLLMアプリを成功に導くコンパスです!
著者の注:このブログ投稿の着想は、Radixのソリューションアーキテクトとしての私の経験に由来しています。Radixは、さまざまな産業向けに革新的な機械学習ソリューションとアプリケーションを開発するベルギーの人工知能会社です。LLMベースのアプリケーションについてさらに詳しく知りたい場合は、radix.aiを訪れるか、LinkedInで直接私に連絡してください。
特に明記されていない限り、すべての画像は著者によるものです。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles