LLM出力の自動評価

https://arxiv.org/abs/2309.15217

LLM出力評価の重要性と課題

（Source: https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/overview-what-is-prompt-flow?view=azureml-api-2 ）

LLMの出力は、基本的に信頼性においてプログラムによる出力よりも劣っています。これは、LLMの出力が毎回一定ではないためです。開発者は、できる限り期待通りの回答を常に得られるように、プロンプトの改善を繰り返します。一回一回の評価の質を高めるためには、出力を客観的に評価することが重要です。評価を目視で済ませようとすると評価結果の信頼性に疑問符がつくうえに、プロンプト改善に時間をかけたい開発者が評価に時間を取られてしまうことになります。

出力評価の役割は、開発段階でプロンプトチューニングの成果を高めることです。LLMベースのアプリの開発はさまざまなフローで行われますが、Microsoft Machine Learningで公開されているフロー図は一般的なワークフローモデルであると言えます。LLMを内包するサービスの開発のうち、プロンプトチューニングに関わるプロセスは、次のような順序を取ります。

1. プロンプトを作成
2. LLMに回答させる
3. 結果を評価する
4. プロンプトを改善して2に戻る

3のステップで、LLMによる出力が正しいかをチェックします。正しいと判定する基準は、LLMに実行させるタスクによりさまざまです。正解データとの完全一致を正解とみなす場合もあれば、多少の揺れを許容する場合もあります。タスクによっては正解データなしで評価するものもあります。事実を説明する文章を生成するタスクなら、ハルシネーションを防止するために事実かどうかのチェックをするでしょう。

LLM出力の評価における主要な課題は二つあります。評価コストの大きさと、客観性を確保することの難しさです。

最も原始的な方法は、手動での出力評価です。手動での確認は時間がかかります。開発者は製品の性能を高めるための本質的な作業に注力したくなるでしょう。回答のデータが大きいと更に手間が増えます。評価だけでなくその結果を文書にまとめる作業も含めれば丸一日潰れることもあるでしょう。人力による評価では、その客観性にも疑問符がつきます。二値分類のような正解を判断しやすいタスクなら目視でも処理しやすいですが、ハルシネーションの有無や言語としての流暢さの判定は人間の手に余るタスクです。 本号では、このような課題を解決する出力評価に関する基礎知識から、実際の評価の方法、それらを応用した最新の評価システムを紹介します。

基本的な知識① RecallとPrecision

LLM出力の評価でよく使われる評価値として、RecallとPrecisionというものがあります。これは本号での解説でも繰り返し言及します。出力評価に関する他の論文でも度々目にする概念なので、前提知識として解説します。
RecallとPrecisionは2値分類のタスクで使われる指標です。これらの指標では前提として、評価結果を4つに分類しています。以下の分類に従って、RecallとPrecisionを算出します。

（Source: https://towardsdatascience.com/precision-and-recall-made-simple-afb5e098970 ）

- 予測がPositive(陽性)の時に正解がPositiveである場合→True Positive(真陽性)
- 予測がPositive(陽性)の時に正解がNegative(陰性)である場→False Positive(偽陽性)
- 予測がNegative(陰性)の時に正解がPositiveである場合→True Positive(偽陽性)
- 予測がNegative(陰性)の時に正解がNegativeである場合→True Positive(真陰性

Recall(再現率)

Recallは、正解データがPositiveであるもののうち、Positiveであると予想できたものを指します。式ではTP/TP+FNになります。NegativeなデータをPositiveと間違えてでも、Positiveなデータを見落とさないことを重視する時などに使われます。感染症の検査で例えてみましょう。陽性者をもれなく検出して感染の拡大を防ぐことが求められる場合、偽陽性を出してでも陽性者を見落とさないようにしなければなりません。このような場合にRecallを重視します。

Precision (適合率)

Precisionは、出した予測のうち、正解(TRUE)であったものの割合をいいます。TP/TP+FPという式で計算されます。つまりPositiveとNegativeを取り違えないこと、間違いを少なくすることを重視するときに有効です。先ほどの感染症検査を例に取ると、陽性者を見落とさないことよりも陽性・陰性を取り違えないことが求められる場合、出した検査結果が全て正確でなければなりません。この場合、Precisionを採用するのがより適していると言えます。

基本的な知識② さまざまな評価指標

アルゴリズムによって評価する指標

編集距離

ある文字列の変更によって、目標とする文字列に置換するための操作の必要回数です。

ROUGE

主に要約や翻訳の精度を評価する際に使われる指標です。見本データをLLMの出力をどの程度再現できているか(recall)を計測できます。この時、評価値はn-gramの一致によって算出します。gramとは文を構成する要素のことです。通常は単語を指します。一致を判定する単位の大きさや、重みの考慮(どの単語の一致がより重要か)を行うかなどの性能によっていくつかのバリエーションがあります。

LLMによって評価する指標

流暢さ(fluency)

主に自動翻訳の評価に使います。言語としての自然さを評価します。

感情分類

カスタマーレビューやSNS投稿の分析で活躍します。入力された文章がどのような感情に基づくものかを評価します。

有害性(Toxicity)

攻撃的なコンテンツの生成を防止するために使います。人種差別や偏見にもとづく文章であるかどうかを評価します。

RAGで活用される指標

弊社が長らく取り扱っているRAGに使われる指標もあります。

文脈的再現性(Contextual Recall)

取得するべきコンテキスト(社内情報など)をどれだけカバーしているかを評価します。

文脈的正確性(Contextual Precision)

攻撃的なコンテンツの生成を防止するために使います。人種差別や偏見にもとづく文章であるかどうかを評価します。

忠実性(Faithfulness)

生成された回答がどれだけコンテキストに忠実であるかを評価します。

ここで紹介したものはほんの一部です。更に発展的な指標を知りたい場合は、ぜひMicrosoft Machine Learningのページをご覧ください。

（Source: https://learn.microsoft.com/en-us/azure/machine-learning/prompt-flow/overview-what-is-prompt-flow?view=azureml-api-2 ）

LLM出力評価のフレームワーク

LLMを内包するサービスの開発において、出力評価を客観的に、かつ自動で行うための基本的な概念について解説しました。さらに、最近では、評価の自動化というニーズを見越したかのように、出力の評価とプロンプトの改善というワークフローを合理化するフレームワークが開発されています。

RAGAS

RAGの出力を評価するための処理を簡単に実装できるようにするフレームワークです。RAGASの公式サイトで「メトリクス駆動開発」を掲げていることからわかるように、RAGの開発フローの中でも評価プロセスの合理化に特化したツールです。これにより、評価処理のベストプラクティスをフルスクラッチ開発よりも短時間で簡単に実装することができます。あらかじめ実装された評価処理をそのまま使用できるほかに、プロンプトテンプレートと評価用のデータセットの作成機能も提供しています。論文RAGAS: Automated Evaluation of Retrieval Augmented Generationでは、RAGASによる評価精度が人間による評価に近しい性能を出したことを報告しています。この実験では、正解データと出力データを比較して、その評価において人間による評価とどの程度近い成果を出せるかを計測します。このテストでは、RAGASによる評価は従来のフレームワークであるGPT ScoreおよびGPT Rankingよりも高い性能を出しています。

（Source: https://arxiv.org/abs/2309.15217 ）

RAGASがサポートするのはRAGに適した評価指標で、代表的なのはcontextual recall, contextual precision, answer relevancy, faithfulnessの4つです。contextual recallは先ほど解説した再現率を示す指標で、RAGシステムが取得したコンテキスト(社内情報などのデータベース)のうち、取得するべきものをどれだけ高くランク付して取得できているかを示します。contextual precisionは、取得したコンテキストに間違いが含まれていないかを示します。answer relevancyは回答そのものに対する評価指標です。回答がプロンプトとどれだけ関連しているかを示します。faithfulnessは回答がコンテキストの情報にどれだけ忠実に回答しているかを示します。

promptfoo

promptfooは、RAGASと似たコンセプト「テスト駆動開発」の考え方をプロンプトエンジニアリングに持ち込んだフレームワークです。しかし、アプリ開発フロー全体を効率化することを想定していると思われます。RAGASと比べて広い範囲のタスクをカバーしているのが特徴です。評価を行うコードを提供しているだけでなく、開発者がより本質的な部分に集中できるよう洗練されたUIを備えています。RAGASはライブラリとしてプログラムの中に組み込む用途を想定していますが、promptfooは設定ファイルの評価に使うパラメータをYAML形式で記述するだけでテストを実行できます。実際にpromptfooで評価を行っている様子を紹介します。

下の画像はpromptfooの設定ファイルです。設定のパラメータはそれぞれ次のような意味をもちます。
promptsは評価対象のプロンプトです。波括弧で囲まれた部分は変数です。下のtests以下で設定した値を代入することを示します。varsの部分では変数(二重波括弧{{}}で囲まれた部分)に代入する値を指定しています。topic:に続く値がそれぞれの試行で代入されます。topic: avocado toastのテストでは、

1. avocadoを含む文字列であるか
2. {1 / (output.length + 1)の意味}
   を評価するよう指定しています。topic:new york cityでは、ensure that the output is funnyという指定になっています。これは上述したような特定の指標を選択するスタイルではなく、valueで宣言したようなテキストであるかをLLMに判定させるようになっています。

プロンプトと各パラメータを指定したら、指定通りのコマンドを打つだけで評価を自動で行ってくれます。結果はコマンドラインで、以下のように出力されます。今回のテストは “ensure that the output is funny (おもしろいか)” です。

[PASS] と表示されたものは、 “ensure that the output is funny” に対して、LLMの評価を通過したもの、つまり面白いと判断したものです。一方で [FAIL]the content is enthusiastic about visiting New York City but not humorous と表示されている箇所は、funnyではなくenthusiasticであるとして扱いされています。生成されたツイートにはユーモラスな内容ではなく、ニューヨークの街に興奮している様子が書かれており、妥当な評価だと言えます。

評価の用意な環境

客観的なLLM出力の評価を自動化することが開発の効率化を助けるという観点から、さまざまな評価指標が考案され、それを運用するツールも開発されるようになりました。後発のツールは更なる効率化、UIの洗練によってデベロッパーフレンドリーを実現しています。これからこのようなツールが成長・普及することで、LLMの出力評価のハードルは徐々に下がっていきます。近いうち、大量のデータセットで客観的な指標に基づいて評価されているということは当たり前の条件になっていく可能性があります。フレームワークによる性能評価が常識になる頃に備えて、出力評価の重要性に目を向けてみるのはいかがでしょう。