「LLMの評価にLLMを使用する」
「LLMの効果を実際に試し、評価する方法」
ChatGPTに何百万通りもの異なる方法で行動をお願いすることができます：栄養士、言語教師、医師など。OpenAI API上で多くのデモや製品が公開されているのは驚きではありません。しかし、LLMが特定の方法で行動するのは簡単ですが、与えられたタスクを正確に遂行できるようにすることはまったく別の話です。
問題は、私たちが気にする多くの基準が非常に主観的であるということです。回答は正確ですか？応答は一貫性がありますか？何かが幻想されましたか？評価のための数量化された指標を構築することは難しいです。主に、人間の判断が必要ですが、多数のLLMの出力を人間がチェックするのは費用がかかります。
さらに、LLMには調整できるパラメータがたくさんあります。プロンプト、温度、コンテキストなど。特定のデータセットでモデルを微調整して、自分のユースケースに合わせることができます。プロンプトエンジニアリングにより、モデルに深呼吸をさせたり[1]、リクエストをより感情的にする[2]ことで、パフォーマンスが向上する場合があります。調整や実験の余地はたくさんありますが、何かを変更した後は、システム全体が良くなったのか悪くなったのかを判断できるようにする必要があります。
人間の労働は遅くて高価なため、これらのより主観的な基準に対して自動的な指標を見つけるという強い動機があります。興味深いアプローチの1つは、LLMを使用してLLMの出力を評価することです。結局のところ、ChatGPTが質問に対して良い、一貫した応答を生成できる場合、与えられたテキストが一貫性があるかも判断できるのではないでしょうか？これにより、潜在的なバイアス、技術、機会のいくつかの可能性が開かれるため、詳しく見ていきましょう。
- テック業界でデータサイエンティストの仕事を手に入れた私の履歴書を解剖する
- 究極のハイブチュートリアル：ビッグデータ管理とクエリの必須ガイド
- 「マルチプレーナーUNet：すべての3Dセグメンテーションタスクに対応した1つのUNet（データが少ない場合でも）- ローコードアプローチ」
LLMのバイアス
もしLLMを使用してメトリクスや評価者を構築することについて否定的な感情を抱くのであれば、その懸念は正当です。これは既存のバイアスをさらに広める恐ろしい方法になるかもしれません。
例えば、G-Evalの論文では、研究者たちはLLMに基づいた評価が、人間が書いた要約よりもGPT-3.5の要約に高いスコアを与えていることを示しましたが、人間の審査員は人間が書いた要約を好むです。
また、”Large Language Models are not Fair Evaluators”というタイトルの研究[3]では、2つの選択肢のうちどちらがより良いかを選ぶように求められた場合、選択肢の提示順序には大きなバイアスがあることがわかりました。例えば、GPT-4はしばしば最初の選択肢を選好し、ChatGPTは2番目の選択肢を好む傾向がありました。同じ質問を順序を反転させて問うことで、LLMの回答が一貫しているかどうかを確認することができます。彼らは後に、オプションの順序を変えてLLMを複数回実行することで、このバイアスを軽減するための技術を開発しました。
評価者の評価
結局のところ、私たちはLLMが人間の評価者と同等または同様にパフォーマンスを発揮できるかどうか知りたいと思っています。これは科学的な問題としてアプローチできます。
- 評価基準を設定する。
- 人間とLLMに基準に従って評価を依頼する。
- 人間とLLMの評価の相関を計算する。
この方法により、LLMが人間の評価者にどれだけ近いかが分かります。
実際に、これと同様の研究はすでにいくつか存在し、特定のタスクでは、従来の評価指標よりもLLMの方が優れた結果を出すことが示されています。また、完全な相関が必要なわけではありません。多くの例に対して評価を行えば、評価が完全ではなくても、新しいシステムがより良いパフォーマンスを発揮しているかどうかの一部のアイデアを得ることができます。人間の評価者にとって心配なエッジケースをLLM評価者を使用してフラグ付けすることもできます。
LLMを中心とするいくつかの最近提案されたメトリクスと評価者を見てみましょう。
G-Eval
G-Eval [4]は、まず評価基準を概説し、その後、モデルに評価を依頼することで機能します。たとえば、要約や対話生成のタスクに使用することができます。
G-Evalには以下のコンポーネントがあります：
- プロンプト。評価タスクとその基準を定義します。
- 中間手順。評価のための中間手順を概説します。これらのステップをLLMに生成するように実際に要求します。
- スコアリング関数。LLMのスコアをそのまま受け入れる代わりに、トークンの確率を見て最終スコアを取得します。つまり、1から5の間で評価を求める場合、LLMが与える数値（例えば「3」とする）だけではなく、各ランクの確率を見て加重スコアを計算します。これは研究者が通常、評価の中で一つの数字が支配的であることを見つけたためです（例えば、「3」を主に出力する）、そして、LLMに10進数の値を返すように求めても、まだ整数値を返す傾向があるからです。
G-Evalは、BLEUやROUGEなどの従来の参照ベースのメトリクスよりも、人間の判断との相関が比較的低いということが明らかになりました。表面上は、LLMに評価を実行するように要求するだけなので、かなり簡単に見えます。また、タスクをさらに細分化することも試すことができます。
FactScore
FactScore（Atomicity Scoreにおける事実の精度）[5]は、事実の精度を測るための指標です。そこでは、原子的な事実を単位として扱い、特定の知識源に対する信頼性を基にします。
評価では、生成物を小さな「原子的」事実（例：「彼はニューヨークで生まれました」）に分割し、各事実が与えられた正解知識源によってサポートされているかどうかをチェックします。最終的なスコアは、サポートされた事実の数を総事実の数で割ることで計算されます。
論文では、研究者はLLMに人物の伝記を生成させ、それを真実の知識源としてWikipediaの記事を使用しました。同様の手順を人間が行った場合のLLMのエラー率は2％未満でした。
RAGAS
さて、検索拡張生成（RAG）のためのいくつかのメトリクスを見てみましょう。RAGでは、まず外部の知識ベースから関連する文脈を検索し、その事実に基づいてLLMに質問をするのです。
RAGAS（Retrieval Augmented Generation Assessment）[6]は、RAGの評価のための新しいフレームワークです。これは単一のメトリクスではなく、複数のメトリクスの集まりです。論文で提案された3つのメトリクスは、信頼性、回答の関連性、文脈の関連性です。これらのメトリクスは、LLMの評価をより簡単なタスクに分解する方法を完璧に示しています。
信頼性は、回答が与えられた文脈に基づいているかどうかを測定します。これはFactScoreと非常に似ており、まず生成物をステートメントのセットに分解し、それぞれのステートメントが与えられた文脈によってサポートされるかどうかをLLMに問い合わせます。スコアはサポートされたステートメントの数を全ステートメントの数で割って計算されます。信頼性については、研究者は人間の注釈者と非常に高い相関関係を見つけました。
回答の関連性は、回答が実際の質問に対応しているかどうかを捉えようとするものです。まず、LLMに答えに基づいて質問を生成するように要求します。生成された質問と元の質問の類似性を計算することで（埋め込みを作成し、コサイン類似性を使用）、これをn回行い、類似性スコアを平均化することで、回答の関連性の最終値を得ることができます。
コンテキストの関連性は、提供されたコンテキストがどれだけ関連しているかを指します。つまり、提供されたコンテキストには、質問に答えるために必要な情報のみが含まれています。理想的な場合、私たちは質問に答えるために正しい情報をLLMに提供し、それだけです。コンテキストの関連性は、与えられたコンテキストから回答に関連する文を抽出するようLLMに求めて、関連する文の数を全文数で割ることで最終スコアを算出します。
こちらでさらなる指標と説明（オープンソースのGitHubリポジトリも含む）を見つけることができます。
重要なポイントは、評価をより小さなサブ問題に変換できることです。テキスト全体がコンテキストによってサポートされているかどうかを尋ねる代わりに、特定の小さな事実がコンテキストによってサポートされているかどうかだけを尋ねます。回答が関連しているかどうかについて直接的な数字を与える代わりに、与えられた回答に対してLLMに問題を考えさせます。
結論
LLMの評価は、さらに注目されていく非常に興味深い研究トピックです。さまざまなシステムが本番環境に達し、より安全性の高い環境でも適用されるようになるにつれて、さらに注目を集めるでしょう。
また、これらの指標を使用して、LLMのパフォーマンスを本番環境で監視することもできます。出力の品質が低下し始めた場合に気づくために使用することができます。特に医療などのミスのコストが高いアプリケーションでは、ガードレールやエラーの検出・削減システムの開発が重要になります。
LLMを評価基準として使用する際には、確かに偏見や問題があるものの、オープンマインドで研究問題として取り組むべきです。もちろん、評価プロセスには依然として人間が関与することになりますが、自動指標は特定の状況でパフォーマンスを部分的に評価するのに役立つ可能性があります。
これらの指標が常に完璧である必要はありません。ただし、製品の開発を適切な方向に導くために十分に機能する必要があります。
フィードバックと提案に感謝します。Daniel RaffさんとYevhen Petyakさんに特に感謝します。
元記事はMedplexity substackで公開されました。
- Yang, Chengrun、他。Large Language Models as Optimizers。arXiv、2023年9月6日。arXiv.org、https://doi.org/10.48550/arXiv.2309.03409。
- Li, Cheng、他。Large Language Models Understand and Can Be Enhanced by Emotional Stimuli。arXiv、2023年11月5日。arXiv.org、https://doi.org/10.48550/arXiv.2307.11760。
- Wang, Peiyi、他。Large Language Models Are Not Fair Evaluators。arXiv、2023年8月30日。arXiv.org、https://doi.org/10.48550/arXiv.2305.17926。
- Liu, Yang、他。G-Eval: NLG Evaluation Using GPT-4 with Better Human Alignment。arXiv、2023年5月23日。arXiv.org、https://doi.org/10.48550/arXiv.2303.16634。
- Min, Sewon、他。FActScore: Fine-Grained Atomic Evaluation of Factual Precision in Long Form Text Generation。arXiv、2023年10月11日。arXiv.org、https://doi.org/10.48550/arXiv.2305.14251。
- Es, Shahul、他。RAGAS: Automated Evaluation of Retrieval Augmented Generation。1、arXiv、2023年9月26日。arXiv.org、https://doi.org/10.48550/arXiv.2309.15217。
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
