#8: Who Validate the Validator? - 継続的な評価をアップデートする仕組み -

継続的にLLMアプリケーションの評価基準や自動評価をアップデートする仕組みであるEvalGenについて書かれた論文「Who Validates the Validators? Aligning LLM-Assisted Evaluation of LLM Outputs with Human Preferences」について話しました。

ポッドキャストの書き起こしサービス「LISTEN」は⁠⁠⁠⁠⁠⁠⁠⁠こちら⁠⁠⁠⁠⁠⁠⁠

Shownotes:

https://arxiv.org/abs/2404.12272

https://www.sh-reya.com/blog/ai-engineering-flywheel/

https://www.chainforge.ai/

https://github.com/wandb/evalForge/tree/main

https://blog.langchain.dev/aligning-llm-as-a-judge-with-human-preferences/

⁠

出演者：

seya(⁠⁠⁠⁠⁠⁠⁠@sekikazu01⁠⁠⁠⁠⁠⁠⁠)

kagaya(⁠⁠⁠⁠⁠⁠⁠@ry0_kaga⁠⁠⁠⁠⁠⁠⁠)

サマリー

このエピソードでは、「Who Validate the Validator?」という論文を基に、評価基準のアップデートと継続的な評価の重要性について議論されています。特に、EvalGenというフレームワークを用いたプロセスが紹介され、評価基準の生成やテストの自動化について詳しく解説されています。また、評価基準の改善と自動化のための仕組みや、eValue.J及びChain4Gなどの具体的な実装方法が議論されています。さらに、LangSmithによる自動アノテーションとそのフローについても触れられています。評価基準のアップデートが求められる中、エンジニアは継続的な評価の仕組み作りについて語り、特にユーザーフィードバックや自動評価を用いたプロダクト改善の方法に焦点を当てています。

評価の評価について

AI Engineering Nowの部屋と申します。加賀屋さん、よろしくお願いします。

加賀屋です。よろしくお願いいたします。

今日はですね、Who Validate the Validator? という論文についてお話ししていこうと思います。

タイトル通りなんですが、評価の評価みたいな話で、もうちょっとちゃんと言うと、

評価基準とその評価基準に合わせた自動評価の実行を、

どうアップデートしていきますかっていう感じの論文なんですが、

ちなみに加賀屋さんはこれまで、LLMプロダクトの評価とかをしていて、

こういうところめんどくさかったなとか、こういう思い出とかってあったりされますか?

そうですね。それで言うと、これって本当にタイトルの通り評価の評価みたいな話。

多分プールの関心を監視する人みたいな、そういう笑い話的な話。

ちょっと絡んでくる話だと思うんですけど、

評価してみているんだけど、この評価でいいんだっけっていうもの。

そこの迷いとかはソフトウェア開発の時より圧倒的に大きいというか、

例えば弊社で言うと、ドメイン的になかなか管理会計とかって理解できないかったりとか、

その微妙なこの時のこのシーンとかだと、こっちの文句の方が自然なんだよねみたいなのって、

そもそも知識として持ってなかったりとかするので、

こんな感じの中、多分こういう感じで出たらいいんだろうなって評価基準考えてやってみたけど、

その評価基準自体が間違ってますみたいなっていうのがやっぱり多々あるので、

そういう意味とかで、このWho validate the validatorsみたいなのは本当にめちゃあるあるというか、

一番困るところな気がしますね、まず真っ先に。

そうですね、何かそういう、何だろうな、

作っていく上で他の人に見てもらったら全然違う評価基準であったとか、

自分でも自分が今の出力を見ていく中で、

こういうのはそんな問題じゃないけど、こういうのは問題だからちゃんと検証できるようにしたいなとか、

そういう、この論文の中でクライテリアドリフトという現象について研究があるんですけど、

何かというとですね、評価基準は一回作って終わりっていう感じじゃなくて、

評価していく中でとか、プロダクト運用していく中で変わっていくものなので、

継続的にこの評価基準とそれをテストするためのデータセットをアップデートしていく必要があるよねっていうところを、

大元の課題感として提供されているのが、

そんなところをですね、そういう課題を解こうとして、この論文の中では、

EvalGenのプロセス

EvalGenという名前のフレームワークを作っていて、

そういう評価基準とか、そのテストをする行動とかをうまいこと改善していきましょうというのが紹介されていたりしますので、

今日はですね、そのワークフローがどういう流れで実行されているのかとか、

そういうのをちょっと解説できればなと思っております。

では、そんなEvalGenの詳細について語っていこうと思うんですが、

この前にですね、ちょっと補足情報として、

この論文を書いている方がですね、シュレヤさんという研究者の方で、

結構ですね、この方がアプリケーション文学のLLMの評価についての研究を結構積極的にしてくださっている方で、

この方のブログの中で、データホイールを作っていこうとか、

なんか結構浮世離れしていないというか、結構実践的なワークフローの話とかをよくしてくれているので、

ご興味あったらぜひフォローしてみていただけると、

多分有益な情報がいっぱい手に入るんじゃないかなという感じです。

というところで、次にですね、早速なんですけど、

この論文の中で紹介されているディバルジェンの詳細について紹介していくんですが、

まず最初に大枠だけパッとお伝えしていきますと、

全体の流れとしては、まずこの実際の出力結果、

評価したい対象のLLMシステムが出力した結果をいっぱい用意しておいて、

まず人間がそれをいっぱい評価していくと。

この論文の中ではフェアワイズ評価、

その出力結果が良いか悪いかみたいなものであったりとか、

これフェアワイズじゃないか、

単純なGoodとBadをつけるみたいな例を示していたりとかもしています。

そういった人間のアノテーションの結果を基に、

LLMが評価基準を制定しますと。

こういう評価基準で評価したらいいんじゃないっていうのを、

LLMがサジェストしてくれるんですけど、

それを人間が見てですね、そのまま採用したりとか、

ちょっと手動でいじったりとか、

あとはこれはいらないかなという感じで選んで、

評価基準が決定されると。

この作られた評価基準を基にテストするためのアサーション、

PythonコードとかLLM Judgeのプロンプトとかを訂正して、

自動で評価が実行できるようにするという感じですね。

その実際に作られたアサーションを基に評価が実行されて、

カバレッジレポートと呼ばれているものが出ます。

これが人間の評価とどれくらい合っているかというのを

どれくらい合ってますかというのをレポートしてくれるものになります。

人間が4証言で評価の結果が何%どれにあるかみたいなものを

示してくれてるんですけど、

人間が正しいと判断してて、

LLMが正しいと判断しているのが何%、

人間が誤っていると判定しているのに

LLMが合っていると判定しているものが何%みたいな感じで、

人間の整合とLLMの整合にかける2みたいな感じで、

それぞれ何%ぐらいがどこに収まりますかみたいなものを出してくれるので、

それを見てもっと改善の余地あるなという感じで

ループを回していくみたいなそんな感じのワークフローです。

評価の改善と成果

というのが大まかな全体像なんですが、

ここまで聞いて自分で作るってなったときに、

ここまでよく分からないなみたいなのを知ってみました。

そうですね。

人間がPairwiseの人間の評価をもとに、

LLMが評価基準だったりとか、

LLMがアドジャッジするようなプロンプトをまず自動生成するですかね、

EvalGen自体は。

そうですね。

テストするためのAssertionのPythonコードを作成する。

これも自動生成してくれるって話だったと記憶してるんですが、

このPythonコード自体はこのLLMアザージャッジを実行するためのコード、

これをやってくれるコードが自動生成されるだけですよね。

何が言いたいかというと、

例えば評価基準として何文字いないですっていうのは、

コードでテストかけるじゃないですか、ユニットテストみたいな。

そこまで自動生成するっていうかは、

LLMで評価するプロンプトとそれを実行するPythonコードを

自動生成してくれるってことですよね、多分。

どういうふうにそこまで。

公社があるの、公社っていうのは、

LLMアザージャッジをするためのプロンプトが含まれるっていうのは、

そこは確かですね。

そうですよね。

さすがにここはLLMじゃなくて、

コードで例えばチェックしたほうが確かだからPythonコードを作るんです、

みたいなとこまではさすがにやってくれないだろうなとは思うんですけど、

単純に物によってはそういう形で落とし込めるんだったら、

そっちでやったほうが早いし安いし、正確ではあるし、

いいはいいじゃないですか、そっちのほうが。

もし自分が似たようなものを作るんだったら、

ちょっと骨は折れますが、

そういうコードベース、

今までのユニットテストに近いやつでチェックできるものっていうのは、

それに落とし込めるほうがいいなとは思っているので、

そういうのとかむしろ作ってみたいなと思いながらまず聞いてたのと、

レポートってあれですよね、

一応生徒してる人間の評価とどれだけずれてるかみたいな話だったりとか、

これってLM評価のほうが微妙っぽいよねとか、

もちろん逆のパターンあるかもしれないですけど、

そういうのがパッと分かるので、

どこがどうずれてるとか、どこが一致してるとか、

みたいなのが多分分かるから、

それもとにいろいろ修正、また改善していけばいいなと。

これが評価の、

RachelBoschが評価の評価に持つわけなんですけど、

これを見て、基本的に結構私が今まで、

LMアドバンテージみたいなのを作っていたときって、

理容性みたいな、

実際に実際に作っているときに、

人間目線だと間違ってるのに、

LMが正しいと判定しちゃっている、

みたいなものを減らしたくなる。

なぜかというと、

それのせいで問題を見逃してしまう、みたいなものを避けたいので。

なので、こういうやり方をしているときに、

LMの評価に対して、

LMの評価に対して、

LMの評価に対して、

この4小言でレポートが出てくれることによって、

分布を減らしたいなってなるから、

一旦、理容性は仕方ないけど、

利用性は減ってればOKみたいな、

そういう感じになって、

より厳密的なワークフローで、

評価機能改善ができるみたいな、

それを参考に使うというふうに思ってます

ですね こういうのとか 一曲 この辺の人間のというか ドメインエキスパートの方に評価してもらったときはこうだったけど

僕が書いたLMR The Judge こう言ってるな みたいなのを 頭の中でマッピングしながら直してとか

泥臭いってやるとそうなったりとかすると思うので その辺とか勝手にレポート出てくれるのはシンプルに嬉しいですし

評価基準の改善

まさしく評価の評価 プールの監視員を監視するための何か考えて楽しいなと思いますね

そうですね この辺のレポート出すみたいなものは地味に嬉しいというか

私 今までやってきたLMR The Judgeの改善みたいなものって 結構目検査でスコアずれてるものピックアップして

全数の中で何%とかが全然判断できてなかったので こういうレポートがあるだけでちゃんと改善できてるんだなっていう実感が得られやすくなるかなっていう感じですね

そうですね めちゃくちゃ思い当たる節はあるし ある程度運用に乗ったりとか この辺とかにリソース避けるような状況とかになったらまた別なんですけど

あれと他も直近01じゃないけど1から何かきっとみたいな機会が多いので そうするとやっぱこの辺の仕組みないせいで自作で頑張りますかって言われると後回しになるので

そういう機会があったらやっぱり自作で頑張っていきたいなっていうふうに思うので 自作で頑張っていきたいなっていうふうに思うので

というところで そんな既存のものがあるのかっていうところで 具体的なeValue.Jの実装方法みたいなところについてもちょっと触れていきたいんですけれども

私が論文読んだりとかした限りでは 具体的なプロンプトとか 今ちょうどこれあったらいいよねって話してたカバレッジレポートのロジックとかは多分

ロジックは別にそんな難しくないから作ればいいだけではあるんですけど 読み合わせがなかったので

ちょっと何らかこの論文を紐解きながら言える必要があるのかなという感じですね

一応ですね 論文の中ではChain4Gっていうライブラリを使ってこのeValue.JのUIを作っていますよっていう言及はあるんですけど

なんかこのChain4G自体がeValue.Jのロジックをサポートしているっていうよりは

なんか結構これがDeFiっぽいやつ いろんなLLMのプロンプトノードとかをつなげて

GUIでプロンプトをつなげるワークフローが作れるよみたいなやつなんで

残念ながらこの中にはeValue.Jのロジックはなさそうでしたという感じですね

なんですけどなんか結構このeValue.Jの論文が出た後に

インスパイアされましたって言って作ってる人が何社かあって

例えばワンドビーの人が独自にですね eVal4Gっていうものを作っていて

この中に結構さっき言った人間のアノテーションから評価基準を生成するとか

あと評価基準からこのアクセサションのいろいろなロジックのプロンプトを出してくれるとか

なんかそれを作るためのプロンプトとか結構細かく書いてあるので

なのでなんかちょっと自分で実装したいなってなったときは

なんかこの辺参考にしてみるのはいいかなという感じですね

でもう一社目についたのはあのラングスミス

まあ私はもうこのラングスミスにすごい挑んで開発しているんですけれども

なんかラングスミスが多分6月か7月ぐらいにこのeVal4Gにインスパイアされましたって言って

その自動で改善するエレレマザージャッジを作れる機能を出しましたよっていうの

まあリリースノートとともに発表していて

ただですね確かにインスパイアされてるんですけれども

ちょっと中身微妙に違くて

なんかラングスミスがサポートしているのがオンライン評価とか

評価で自動エレレマザージャッジで実行したスコアがついていて

そのスコアを人間が見ていって

でなんかこのスコアちょっとおかしくねってなったものをコレクションって呼んでるんですけど

これ違うよねって理由とともにマークをつけると

それ用のデータセットに保存されていて

そのデータセットからこのエレレマザージャッジのフロントの中に

フューショットとして入っていくことによって

評価機が自動で改善されていきますよみたいなものをリリースしていました

なので確かに自動でそういうアノテーションをもとに改善していくみたいなところは

当初はしているんですけれども

評価基準を生成するとか

エレレマザージャッジのフロントを自動で生成するとか

なんかそういうところは特になかったんで

それはちょっと違うかなっていうイメージもありつつ

このフューショットで与えていく方式でどれくらいうまくいくかは

ちょっとこんなに検証はできてないんですけれども

とりあえず始めていくには結構いい機能であるかなという感じでしたね

そんな感じだったんですが

どうですかなんか実装できそうですか

自動アノテーションのフロー

今回その問いなんですね

実装できるか問われるっていう

そうですね

なんかちょっと話戻りますけど

単純にChainForge結構面白そうだなと思いながらまず

聞いててなんかパッと見てるだけですけど

もう少しそのプロンプトというかワークフローの仮説検証みたいなのに特化した

ディファインみたいに近いというか

なんかその実行結果みたいなのを保存するみたいな

実験の結果を生んだらみたいなのがあったりとか

なんかこれ何だろうこの変数みたいなやつの方

定義できてるとか

またちょっとディファインとは多分厳密にちょっと違う目的というか

ユースケースで使えるって話とかで

その手元とかでそういうのをちょっと作ってみて試すみたいなとこで言うと面白い

ChainForgeも面白そうだなっていうところと

LangSmithのやつもLangSmithのやつは

ChainForgeってそうですよねそんな感じですよね多分ちょっと

確かに何かグラフ表示してる部分とかあるから

何かさっきのカバレッジレポート出すみたいなの

割とシンプルにかけたりするのかもしれないねこれ

そうですねなんかちょっとノードとか作れるっていうのは一緒なんですけど

テキストフィールドノードとかいろいろ複数にかけるから

これもしかしたら並列なんか入っていい感じにやって

まとまってくれるとかだったら結構嬉しいユースケースはありそうだなっていうので

そういう中にChainForge触ってみようかなと

LangSmithはこれなんか僕最近全然LangSmith触ってないんで

あの分からないんですけど

この機能でこの機能はLMR The Judge LangSmith側が提供してる

まあ多分プロンプト多少いじれると思いますけど

LMR The Judgeをやるプロンプトがまずあって

そこにパラメータとしてそのFewShotのところが

ひたすら追加されていくみたいな感じのイメージなんですか

そうですねなんか下のオンライン評価とかで

オフライン評価でもそうなんですけど

LangSmithにプロンプトみたいなのを登録できて

その中でカーリーブレイスFewShotみたいな感じの

文字別にしているとそこに追加していくよみたいなそんな感じ

確かになんかそういうのあった気がするな

そこにLangSmith側とかでグローバル変数じゃないですけど

そういうのがあってダウンテーションしてデータセットとか作ったら

そこに勝手に入るから参照できるますよねってやつか

これなんか適当なというか雑なことを言うんですけど

そこのカーリーブレイディッドデータセットでしたっけ

に例えば1000件ぐらいデータ追加されてたら

1000件FewShotに追加されるってことなんですか

確かそこがこれもしかしたら間違ってる情報かもしれないんですけど

確かドキュメントにはそのデータセットの中から

確かその件数も絞れるはずで

確かランダムに何件か選ぶみたいな

そんな感じの書きぶりだったというのがあります

ランダムなのか

そうですねランダムだと

なんでランダムなんだろう

質問に出てくるかでそうですけど

だからランダムにその配分されるならされる前提で

我々もその考慮しておかないといけないことがたくさんありそうなんで

結構重要な仕様な気がしますけど

なるほどな確かにこれはこれで普通に

運用としてはやりやすそうというかイメージは湧きますよね

ラングスミスにそれこそデータ流してて

定期的にいろいろとぽちぽちアノテーションしながら

フィーショットに使うデータ足していって

それで勝手に動いてくれるっていうのとかは

運用としてはフローをプロセスとしては回しやすそうだなっていう感じはするので

ラングスミスにまとめるのとかはある種この手軽さとか

インテグレートされてる感だなっていうのは思いつつも

インスパイアのされ方は自由だよなっていうと

思いましたねインスパイアでそのままパクらなきゃいけないわけじゃないから

そうですね

ラングスミスの

すみませんどうぞ

流水ノートの中にしっかりこの論文への言及があって

どうそうなのかって思ってたんですけど

ここまで同じじゃないかと思いました

大きめな何かそのやりたい方向性みたいなやつを

ラングスミスにもする上での嬉しさみたいなのにちょっとしてったら

こんな感じのプロセスになりそうだなって感じですね

そうですね

でも実際

このプロセスだと人間がプロセスをするだけのコストなので

お手軽に始められていいですね

ただ定期的にその評価って本当に良くなってるんだっけっていうのも

観測手段みたいなものは特に自分たちで用意しなきゃいけないから

別途評価の評価を定期的に回すとかなのか

この評価のズレを発見する頻度みたいなのが下がってきたよね

みたいなのに判断するのかとか

その辺考えるところがあるかなっていう

そうですね

この辺とかはレポート発行

評価基準のアップデートと継続的評価

そのうちレポート発行する機能とかつきそうなので

まあまあそれはそれで待つかって言いつつ

おっしゃる通りミニマムにやるんだったら

一月なのか一月に一回要望の

要望リスト保守するみたいな時間の

エレベーションオフィス版みたいな

とりあえず全部見てみますみたいなことをやりますってところから

多分やり始めるだろうなって思いましたまずは

やっぱりね

そんな感じかな

まあでも確かになんか

細いところとかはワークフローというか全体の概要とかプロセスとか

やりたいこと的にはめちゃくちゃわかるし

そうだよなとか

なるほどなって感じ

なのでめっちゃ良さそうな感じはする

はいそうですね

まとめっぽい話にはおりますが

私もこれワークフローとしてはかなり

妥当に思えるというか

やっぱりこの評価基準の

今これって言ってるのがラングシューティングの方じゃなくて

今言われてるのは

かなり妥当に思えており

評価基準のプレートみたいなものがすごい

散々になりがち

一度一度評価していくのも結構めんどくさいんで

なのでこの辺をうまいことできる仕組みを作れると

嬉しいなというところで

私はこんな実装にここから数ヶ月を

使っていきたいなという

そんな意気込みですね

何か語りたいテーマとか出れば

いろんな話があります

意気込み

そうですね

僕もなんかエンジニア的には結構この評価とか

あともうちょっと

ユーザーフィードバックとかを元にした

オンライン評価とかを含めて

この辺の一連のサイクルみたいなのをちゃんと実装する

もしかしたらUIみたいなところとかも込めて

っていうところがエンジニアとしては一番

特にAIプロダクトとかLMプロダクトでいうと

興味あるところではあるので

一番この辺でやりたいし

僕もやっていきたいなっていう領域だなと思いつつ

この辺とかね

もう1年2年するとまた話は変わるんでしょうけど

やっぱその

01とかやってるとなかなかここに正直

めっちゃ時間割けるかって言われると

結構よくもあるともうちょっとカジュアルに

最初アルファ版作るみたいなことを

やりがちだったりとかするので

その辺とかがフェーズとかによって

でもそうですね

3年後5年後みたいなところとか見ていくと

ここが結構LMプロダクトを作る上で

面白ポイントの何個かあるうちの

代表的な1個みたいな感じになりそうな

なるとこだと思うので

僕もやりたいなと思いつつ

僕の数ヶ月どっちかっていうと多分もうちょっと

01っぽいことをやることのほうが多そうだな

とりあえずは

そうですね

この仕組みが

いろんなプロダクトで

汎用的に使えるものとして作れたら

そういうアルファ版みたいなものでも

気軽に投入みたいなものができるみたいな

どんなAIプロダクトでも評価をもとに

改善プロセスを早く回せますよみたいなことが

言える気がしてるんですけど

結局

どうなんだろうな

プロダクトのユーアイにつるる部分みたいな

エンジニアリング基盤の構築

ところもあるかもしれないので

夢物語かもしれないと思いつつ

何かしらで

組みを作りきってみるっていうのはやってみたいな

そうですね

プロダクトの性質とか

プロダクトレベルなのか機能レベルなのかとかで

多少の必要度合いみたいなのが

確かにあるとは思いつつ

そんなプロンプトを変えるってこと自体に

そんなに頻度がないというかニーズがないというか

逆にもっとそれ以外のとことかでむしろ

ビルドを作って

作り直しみたいなのが入るみたいなケースとかが

あるんだったら

そっちの方があれなんで

そうですね

それで言うと僕は一応B2Bサーズの会社なので

最近マルチプロダクトとかコンパウンドスタートアップ

みたいなものとかの単語とかがすごい

ホットというかよく聞くんですけど

僕の認識が誤ってたらなんですけど

コンパウンドスタートアップって言われるところの

代表例の会社が

結局もうちょっとエンジニアリングの部分とかで

やってることって例えば

サーズでアナリティクスみたいな機能とかって

だいたいどこからもどのサーズでも必要

エンプラとかに出そうすると

それをコンパウンドの

そういう思考で最初からやろうと思ってたので

先にアナリティクスを共通基盤みたいな感じで

使えるようにしちゃうと

例えばAってプロダクトからは共通のやつ使うだけでいいし

アナリティクスを作るっていうコストは浮くし

むしろ専門チームが作ってるから

他の強豪散策が片手間で作ってる

アナリティクスと比べるとそもそも優れてるし

そういうとことかで

基盤 新しくプロダクト作ると

このエンジニアリングコストが下がってるのがある種

有意みたいなのを何かで見たことがある気がしていて

LMプロダクトも同じように

そういうのとかを最初から試行して

この辺の自動評価みたいなところを

基盤として作って

逆にプロンプティングみたいなところとか

ラグなのかエージェントなのか詳細分かんないですけど

そこを高速に変えることに

意味があるプロダクトみたいなのを

いっぱい共通基盤を用意しながら作っていく

みたいなのは

なんとなくコンパウンドスタートアップとか

マルチプロダクトみたいな話聞きながら

ありえそうだなって最近思っていたので

個人的にはそういうプロダクトの作り方

エンジニアリング基盤の作る

みたいなのをやってみたいなってめっちゃ思いますね

具体わかんないけど

こんな感じかな

多分実装できるはず

やっていこうかなと思っております

今日は

EvalGenという評価の

イベントとか自動評価のプレートを

うまくやっていくプレーマークについて

話してきました

それではご視聴

ありがとうございました

ご視聴ありがとうございました

ありがとうございました

ありがとうございました