LLMアプリケーションの評価メトリクス策定のために考えたこと・やったこと

本記事では LLM を使ったアプリケーションに対して LLM の出力を評価する取り組みについて書いていきます。

ここのところ私が所属しているチームでは評価メトリクスの策定があらゆるところに効いてくるため最優先事項となっております。まだまだ道半ばで本当はしっかりした結果が出てからまとめて書きたかったのですが、アドカレで登録した日にちに間に合わなかったので途中までの経過をえいやで書き記します。

次のような目的で活用したいと考えています。

- 人の主観による評価の揺らぎをなくす

- モデルを変えた時のリグレッション確認ができるようにする

- 評価結果を使った自己改善の仕組みを作る

シンプルにLLMがプロダクトで使われるにあたって、その振る舞いが"正しい"かの基準を定める目的です。

LLMのアウトプットが特定のユースケースで使われる時には満たしたい条件がある訳ですが、それを言語化するイメージです。

結構プロンプトチューニングなどをしていると、そのチューニングをしている人の主観によった評価を都度してしまい、どんな条件を達成していればその LLM のアウトプットは　 "良い" と判断できるのか曖昧なまま進んでしまいます。

何回もチューニングを重ねる過程で見えてくる観点もあるため、最初からかっちりとした評価メトリクスを作るのは大体の場合において無理なんじゃないかという気もするのですが、後付けでも今後のメンテナンスの観点から評価基準を定めておいたり、プロダクト要件から落とした LLM 生成物の目的などを言語化しておくことは大事なんじゃないかと考えております。

次に、ただいま弊社では OpenAI の GPT-4 を活用しているのですが、コスト💰やTPM、特定のタスクの精度の観点から GPT-3.5 や Gemini Pro、ないし OSS モデルの活用を検討しています。

当然のことながら GPT-4 は最強なので、既存のプロンプトたちをそのまま他のモデルに差し替えて実行すると何らか品質の低下が観測されることでしょう。

それを改善するためにはプロンプトをいじったり、はたまたベースモデルを fine-tuning する必要があるかもしれません。先ほどとある意味同じ話ではありますが、そんな折に闇雲に「いい、悪い」を判断していると本当に改善しているか判断できないですし、改善の仕方も場当たり的になってしまいます。

なので、乗り換える前に評価メトリクスを定めてしっかり改善の判断ができるようにしたり、その指針とする狙いがあります。

最後にもう一つ期待しているのが、評価を使った LLM の自動改善です。

LLM のアウトプットに対して評価を行い、その評価ではスコアだけでなく理由も返すようにし、その理由と先ほどの生成物を LLM に出力してもらうことにより精度の改善が見込めないかと期待しています。

まずは自分たちで評価を始めようというよりは世の事例などを探してみました。

全体感を知るのにとても良かったなと感じたのは次の２記事です。

▼ 内容ざっくりまとめ

LLM のベンチマークメジャーなのが色々ある

だけどメジャーが故にモデルが pre-training or fine-tuning 時にこのベンチーマークに使われるデータに晒されている懸念がある

なので　LLM Leaderboard ってやつがいいよ

Open LLM leaderboard: Provided a wrapper on top of the LM evaluation harness

HELM: Evaluates Open LLMs on a wide variety of open datasets and metrics.

Chatbot Arena: Elo rating for instruction finetuned LLMs

評価メトリクスは traditional なやつとそうでもないやつがある

traditional -> reference text なる"正解"なワードを用いて、それへの近さなどをみる(今回はあまり使わなそうな気がする)

WER - "正解" の文字列との距離を測る

Exact match - 名前の通り

BLEU - reference text に含まれる nグラム（単語の連続）がどれだけ含まれているかに基づいて評価

nontraditional

embedding based

BERTScore - 候補と reference text それぞれ embedding してコサイン類似度を見る

MoverScore - ワードの距離の差分がある程度意味があるという仮定(vector(king) - vector(queen) = vector(man))を元に n-gram間のユークリッド類似性を計算

その他

Entailment score

BLEURT

Question Answering - Question generation (QA-QG)

LLM を使った評価

GPTScore

G-Eval

落とし穴

LLM も bias 持ってる

LLM アプリケーションの評価(LLMの評価とは別ジャンル)

プロンプトに求める性質のタイプ

knowledge-seeking

Text grounded - 与えられたテキストを元にいい感じに返してくるか

Creativity

どう進めるか

人間によるゴールデンスコア（基準となる高品質な評価）をつけたデータセットを用意

テストセット内のデータをスコアリング

Kendall 順位相関係数のような相関測定を使用して、人間による注釈スコアと自動スコアの相関を測定

0.7超えれば大体いいらしい

また、下記記事も LLM を使ったアプリケーションの評価の進め方をステップ by ステップで解説していて良かったです。

という訳で一通り LLM ないし LLM を使ったアプリケーションの評価について学んでみたところで、実際に自分たちのプロダクトでの評価基準を考え、また自動で実行できる部分に関してはそうする取り組みを行なっています。

ここでは具体の実装の How をどう選んだかと、実際の悩みポイント(まだ解けてない)を語ってこの記事を終わろうかなと思います。

プロンプトないし LLM の評価ツールとしては色々あり、以下に見たものをあげていきます。

LangChain 社は LangSmith というプロンプトロギングツールを備えているのですが、このツールは評価のための機能を備えています。

我々としては評価に使うデータセットは CSV などのファイル形式で用意してあり、LangSmith 上に逐一アップロードするのは余計な手間でしかなかったためここが少しネックでした。

ただ、この評価の機能を使わなくとも、Prompt を実行すると自動でログが取れるためそちらの閲覧でも代替はできるかなと感じました。

Ragas は名前にRAG と入っていることから分かる通り RAG パイプラインの評価ツールです。

下記のような評価指標の定義と、それを評価する実装を提供してくれています。

https://scrapbox.io/files/65858560a238610024a55e66.png

RAG 以外の部分の評価にはまた他の手段が必要ですが、RAG の評価に対しては見ておきたい観点を挙げてくれているので、こちらは活用していきます。

こちらは以下のような形で書くことができ、書き味は良さそうだったのですが TS でしか書くことができず(もしPython で書く方法見落としてたらすまない)、アプリケーションの何かしらを参照したくなったり、先述した Ragas などのライブラリと組み合わせる時に Python でないのがネックになるかなと感じたため断念しました。

- Evaluation 専用のプラットフォーム

- ただ機能差分として LangSmith との違いがそんなに見えず、LangChain との連携の優位性を考えると選ぶ理由は感じなかった

OpenAI 謹製の評価ツール。

いくつか見てきましたが結論としては LangChain で評価のプロンプトを実行し、その結果を LangSmith で見るに落ち着きました。

若干 LangChain にロックインされていってる感はありつつも、実行のお手軽さと、LangSmith の見やすい UI などを加味すると他の方法たちに比べると要求を多く満たしていました。

いくつか軸がある話なのですが、例えば評価を人でやるのか LLM でやるのか、はたまた別の機械学習モデルだったり単純なプログラミングで判定するのか。

なるべくなら実行コストの観点から自動化していきたいのですが、そんな簡単なロジックでは判定できなかったりするし、LLM は LLM でバイアス(最初と最後の情報に重きを置きがち、LLMのアウトプットを高く評価しがちなど)を持っていたりちょっと実行コストやコストがかかったりもするので場合によっては評価者として最適でなかったりします。

▼ バイアスを改善する手法

また、評価観点によってはそもそも自動化が難しいこともあり、例えば「〇〇が美味しいか」などの観点は主観でしか評価できず、サービス提供者が中央集権的に評価を行うことは難しいです。

なので、ユーザからの繰り返しのフィードバックを前提に漸進的に評価メトリクスが作られる or/and 改善される仕組みを作るなど別の思考が必要だなと感じています。

結構一律に評価を実装することはできず、評価したい対象によって適切な手段を都度見極めていくのが大事だなと感じています。

評価メトリクスを作っていて難しいなと感じるのが「これいつまでもできるな...」と感じることです。

なんならいくらでも凝りたい気持ちがあるのですが、私は今事業に対して LLM を活用していて、そんな悠長にもしてられないのでどこかで妥協する必要があります。

では終わらせるためにはどうすればいいのかという話ですが、これはプロダクトの要件と照らし合わせてユーザ体験を毀損しないラインを見極めること...なんだと思うのですが、そのラインもきっぱり見極めるの難しいというか結局ユーザに当てるしかない気がしています...。

以上、これまで調べて考えてきたこと・やったことをまとめてみました。

今は絶賛評価メトリクスを策定中のところです。あまり具体的な話が書けなくて悔しいところではありますが、また結果を出せたらどこかでまとめたいなと考えております。

やればやるほど自信を失っていくというか、ほんまにこれでええんか...という気持ちがいつまでも拭えないのですが、おそらく事業を前に進めるために良い塩梅を見極めて出す選定眼と勇気が必要になってくるのでしょう。

正直 LLM に限らず機械学習のアウトプットの評価をする経験は初めてなので、もっとこうした方がいいよという点があればぜひコメントいただけると嬉しいです。

それでは！👋