評価の評価について
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という評価の
イベントとか自動評価のプレートを
うまくやっていくプレーマークについて
話してきました
それではご視聴
ありがとうございました
ご視聴ありがとうございました
ありがとうございました
ありがとうございました
