エージェントの評価手法
こんにちは、かがやです。今日もちょっと収録しているんですが、 瀬戸さん、よろしくお願いします。
よろしくお願いします。
今日はですね、Agent-as-a-judge っていう研究ペーパーについて話をしていこうかなと思っていますと、
すごい簡単に概要を話すと、 LLM-as-a-judge にインスパイア着想を得ていて、
いわゆるエージェントを評価するためのエージェントみたいな話ですね。
ざっくり言うと、そんな感じの研究実装になっているんですが、
瀬康さん、エージェントの評価で困ることだったりとか、 それこそLLM-as-a-judgeって結構得られていると思いますが、
LLM-as-a-judgeのLMの部分ってどんな感じの実装なんですか?
数個のLMとかプロンプトとかで動いているぐらいの感じのイメージなんですか?
基本とプロンプト1個だけというか、 評価基準みたいなものが何種類かあって、
それぞれに対してLMで評価するのが適切そうなのが、
LLMプロンプト1個書いて、
イエス・ノーか頭にスコア付けさせるとか、 そういうのでやっているみたいな感じですね。
そうですよね。 僕もLM-as-a-judgeとかやっているところはそんな感じですし、
LM-as-a-judgeはみんなそんな感じなんじゃないかなとは思って、
エージェントアドジャッジの話にちょっと戻すと、
まずそもそもエージェントの評価にエージェントを使いましょうみたいな話になるんですけど、
そもそも今のAIエージェントの評価手法の課題みたいなところの話、
ペーパー論文内とかで研究されているものとか簡単にお話しすると、
まず一番最初言われていたのは最終アートプットのみに基本着目しているので、
エージェントの逐次的な試行プロセスみたいなのを無視しがち、
中間部分のフィードバックが欠如しているよねっていうところ。
そこが課題だっていう話をしていて、
エージェントって大抵内部で試行だったりとか、
マルチエージェントだとエージェント間とかでコミュニケーションみたいなのが走って、
ある種段階的に行動することになるので、
そこの試行と行動の軌跡をちゃんと考慮した評価とかフィードバックができないとダメなんじゃないか。
結果があって途中式間違ってたらどうするんですかみたいなところ。
そこを理解できる必要はあるよねっていう話ですね。
まずそもそもそこが1個課題だよねっていう話をしてましたと。
Dev AIデータセットの概要
あともうちょっとエージェントアザージャッジから少し話は逸れるんですが、
割と開発周りの話なんですけど、
SDAベンチとかあとHuman Evilとか、
あの辺の開発系のタスクのベンチマークで、
エージェントじゃなくて単純なシンプルALMのプロンプトとかでも結構解けちゃったりするとか、
そのベンチマークとしてそもそももうちょっといいやつがあるんじゃないかっていう話とかもしてますと。
これは付随してですね。
図にまとめると、エージェントがどのようにタスクを解決してるかっていうのを詳細に把握して、
特に中間部分とかも評価把握するってことが難しい。
ちょっと難しい。
人間がこの後コストがかかりすぎる。
なので、ALMアドジャッジに着想を得て、
エージェントを評価するためのエージェントを考えましたみたいな話が書いていて。
多分、ラングチェーンのテックブログに最近あった、これは何て読むんですかね。
SC、SAIPなのかな。
SAIPか。
これもちょっと多分モチベーションは結構似てるんじゃないかなと思って。
やっぱ最終的な結果の評価をしても、
実際に改善していくってなると、
具体的にどこが悪いんだっけみたいなものを特定できないと、
改善につながらないっていうのが実際あるので、
このモチベーションはすごくわかるというか、
そうですよねという感じですね。
まさしくエージェントフローエンジニアリングみたいなフローを書いてる、
ワークフローとかデバッグしてても、
どこでどういう感じなのか分かんないと、
別に何も判断のしようがないので、
そこを含めてALMアドジャッジみたいなことできる方がスケールするよね、
みたいなのを長期的で見ればそうだよなっていうのは思います。
結果的にこの論文の貢献というか、
結局どういうことでしたっけみたいなのを話すと、
主な成果貢献っていうものは3つ主張していて、
3つ、4つ、3つかな。
1個はAI開発タスク用のデータセット、
Dev AIっていうものを公開しましたっていう話をしてますと、
これもうちょっと僕もそんなに軽くしか見れてないので、
ですがもう少し後で詳細は触れますが、
そういうものを作りまして公開しましたって話と、
またこのDev AI使ってオープンソースのコード生成エージェント、
具体的にはMetaGPTとGPTパイロットとQOpenDevのOpenHands、
この3つでこのDev AIで実際にそれを評価してみてみたいなことをやって、
さらに人手とALMアドジャッジとエージェントアドジャッジでどう変わるか、
評価プロセスの重要性
みたいなのをまとめましたっていうような内容になってます。
めちゃくちゃ作ってるじゃないですか。
エージェントアドジャッジも僕もちょっと軽くしか見てないんですが、
多分実装は公開されてるので、そんなにヘビーな実装ではないので、
1日ぐらいでパーって見て、
時間があったら今度全都会まとめるかなと思いますけど、
そんな感じですね。
何か今まででツヤさん気になるところとかあったりしますか。
この後お話いただくとは思うんですけれど、
エージェントで評価って、エージェントアドジャッジっていうのを
具体的にどうやってるのかなっていうところと、
なぜそれをやっているとこの数々のデータセットやGPTパイロットとか、
そういうものが生まれたのかっていう、
そことの接合みたいなものがちょっと気になってますね、今は。
ありがとうございます。
MetaGPTとGPTパイロットとOpenHandsは元からあるやつですね。
そういうことか。
これはOpenDevyn、OpenHandsは旧OpenDevynのいわゆるコード生成エージェント、
Devynみたいなやつですね。
これ使って評価しましたよみたいな話。
そういうことか。
だと思いますね、確か。
なるほど、なるほど。
なので、このエージェントアドジャッジのLMアドジャッジとの比較とかする上で、
使ったフレームワークがこの多分3つみたいな話なはず。
エージェントアドジャッジの詳細がどうみたいな話とかはちょっとまた後で、後ろでって感じですね。
ちょっとだけ、今回エージェントアドジャッジの話ですが、
Dev AIっていうデータセットの話出たので一応ここ軽くさらっておくと、
これ多分逆賞としては、
データセットフォーオートメイテッドAIデベロップメントみたいな名前なのかなってDev AIですと。
これなんか僕はあんまちょっとざっくりしかいないのでそんな把握してないんですけど、
最近Devynとかコード生成分野でいわゆるエージェントシステムっていう結構出てきたよねって話をしていて、
そのエージェントシステムとか実際のAIシステム開発のリアルを評価するベンチマークが不在だよねって話をしてますと。
既存のSWAベンチとかHuman Evilって開発プロセスの一部のみだったりとか、
こういうエージェントみたいなところが想定してないので、
開発の中間段階とか長期的な開発、
多分保守とかメンテとかその辺で話したんですかね。
に対する評価指標みたいなのは不十分だよねみたいな話をしていて、
そこを克服するようなベンチマークを作りたかったよみたいな話をしてますと。
ざっくり単一のLMでは解決できない、
人間とかエージェントのシステムでないと解けないタスク、シナリオみたいなのをできるだけ盛り込みましたよだったりとか、
中間段階も評価する、開発プロセスを重視して評価するみたいなデータセット、
評価できるデータセットになっていて、
このパスハット1っていうのかな。
僕がそうやって呼んでるんですが、
モデルが1回のトライで正しいコードを生成できる確率というよりかは、
もうちょっと中間段階の正しさ、確からしさみたいなのを評価できるみたいなのを一応目指してるようですと。
結構要件みたいな、ちょっと音声だと届けられないんですけど、
これデータセットDev AIの中、取ってきた1行の例、
こういうのとかが入ってて、ネームとかクエリとかタグとかがあって、
多分この要件っていうのが有効非巡回グラフ、タグっていうものとかで構造化されていて、
それがここなんですよね、Requirement。
カテゴリーとか、どっかにこのインポート、
この多分要件として中間段階としてこのインポートみたいなのが書かれてるべきみたいな話とかなのかな。
カテゴリーとかそういうのとかがあって、
そういうところも、これは多分要件とか中間段階とかに近いのが出るとかも評価できるみたいなデータセットになってるっぽいですね。
なので、Requirementとかもタグとかになってるから、
それ結構いい感じに取ってこなきゃいけないから、
評価する側もちょっとだけ面倒な気もしなくもないけど、
みたいな感じの、ざっくりそんな感じです。
Dev AI何か気になるところとかありました?
確かにベンチマークでこういう中間のステップまで評価するみたいなものって、
今までそんなにあんまりパッと出てこないんで、
こういうのを見るとこのワークフローとかモデルはここまではうまくやれてるけど、
エージェントの設計と機能
ここはできてないんだなみたいなものが評価しやすそうなので、
今おっしゃってたように面倒くささも確かに増えそうではあるんですけど、
面白いアプローチのデータセットだなっていう感じですね。
リクワイアメントとかも複数あったりとか、
これもたぶん順序かな、みたいなものがあったりとか、
前提条件みたいなプロパティとか持ってたりするので、
ここのリクワイアメントに到達するためには前提条件ここを満たしてなきゃいけないね、
みたいなものとかもたぶんハドレルになってると思うんですよね、作り的には。
そういうのとか見てて、
試行の部分とか中間段階とかも見れるみたいな一応設計になってるそうって感じですね。
中でエージェントアザージャッジの本体のほうの話とかに移っていくと、
作りとしてはそんなにペーパー内とかにそんなに情報なくて、
収録する直前のGitHubの存在に気づいて全然見れてないのであれなんですけど、
ざっくり言うとダイアグラム的にはインプットがあったら、
モジュール的にはグラフ、ロケート、サーチ、リトリーブ、リード、アスク、
でプランニングとメモリーっていうのがあって、
アスクでアウトプットが出るみたいなざっくりそんな感じのモジュールのリストになっていて、
それぞれざっくり話すとグラフのモジュール、最初インプット受け取って、
グラフモジュールが動くっぽいダイアグラムが書かれてるんですが、
これは要するにプロジェクトの構造、プロジェクトを読み込んでファイルだったりとか、
コードをいい感じにチャンクするみたいな処理をしている感じですね。
ロケートっていうのはフォルダとかファイルの配置場所だったりとかパスとかですね、
その辺を特定したりとか指定させるようなモジュールがあり、
あとはコードとか画像とか動画とか文章とかを読み取って要件の検証するみたいな、
リードに特化したモジュールがあり、
さらにコードとかコードスニッペットみたいなものを検索とか依存関係取っていきますよみたいな、
検索、リトリーブ、サーチかな、モジュールがあり、
あとは取得モジュール、これがリード、リトリーブか、リトリーブモジュールとかが長文、
リードミーとかドキュメントとか、コードから何かリトリーブのとこですね、検索しますみたいなモジュールとか、
あと特定の要件が満たされているか判断するみたいな、
これはリフレクションみたいなやつですね、
メモリ、記憶持っておくとか、プランニング出すみたいな、
こんな感じのモジュールがあるっぽいですねと、
作り的にはエージェント系の何かとかでよく見るような、
わりかし感じなんじゃないかなって気はしている、ざっと見た感じ。
結構いろいろ作ってみて、
もともと完璧なエージェントアドバッジの開発は今回のPoCのフォーカスじゃないので、
ワークフローのデザインとかプロンプトの最適化とか、
その辺の高度なエージェントシステムを作るって方自体は、
結構今後の課題ですよってそもそも書いているので、
エージェントアドバッジの作り、システム自体のクオリティみたいなのが、
元からそこまで追い求めてないっていうのが前提としてありつつも、
結構面白いというか、なるほどなって思ったのは、
例えばプランニングモジュールとか入れてみたけど、
やっぱりここが不安定になるので結構難かったですねみたいな話とか、
メモリとかも過去の履歴が今の変な履歴が入ってて、
あんまりそうに反して効果的に作れなかったよみたいな話だったりとか、
さっきのリトリーバル、リトリーブ検索のモジュールみたいなの作ってはみたが、
今そんなに高々数百行ぐらいのコードしか生成してないので、
別にそんなにこのモジュールが生きなかったよみたいな話だったりとかしていて、
この辺はさっきのAgent as a Judgeシステムの、
Agent as a Judge Agentっていうのかな、
の作り込みのとことかで今後多分いろいろと解消していく話なんだと思いますけど、
その辺そもそも難しかったよみたいな話とかをしているのがちょっと面白かったです。
エージェントの評価結果
そうですね。これファーストインプレッションとしては、
めっちゃ全部使うとめっちゃお金かかりそう、
遅そうっていうのを見たんですけど、
今話してたような試行錯誤というか、
この用途だと検索モジュールそんなにいらないとか、
なんかこのモジュール化されているのがいいですよね。
に応じてこれはいるいらないみたいな、
そういう取捨選択ができそうな、そこが大事そうだなっていう。
そうですね。その辺のモジュールの使い分けだったりとか、
ツールユーズみたいな、どのときにどのモジュール呼ぶみたいなのの、
決定権とかもAgentに渡しているかどうかみたいなのはまだ把握できてないんですけど、
モジュールにしているのはモジュール性というか、
モジュール切ってんだなって感じですけど、
このツキュレのほうがいいだろうなとは思いますけど。
まあそういうふうに。
そうね。
逆なんかしている部分って多分ASKのとこなんですよね。
要件が満たされているか見るみたいなところだったりとか。
基本的にはそこで、それ以外のところとかはいい感じにコード取ってきますとか、
過去のやつを覚えておきますとか、プランニングしますとか、
小文みたいなところから必要なとこ引っこ抜いてきますみたいなところだったりとか、
読み取りますとか。
なので、Otherjudge部分の本質的にはこの質問モジュール、
多分ASKモジュールかな、しかないんじゃないかなって気はしている。
そうですね。言い方あれですけど、
要するにLLM Otherjudgeもプロダクト開発で使うAIシステムみたいに、
ガチで作ってみましたみたいな感じなのかなっていう。
そうですね。実はちゃんと読んでない、僕の今の認識で話すと、
この読み取りモジュールとか、リトリーバルモジュールとかに近しいものとかって、
みたいなのとかを一応あった上で、
LLM Otherjudge的なこととかやってたりしてたりもするので、
じゃあ俺がやってるのはこれはAgent Otherjudgeかみたいなのを思いながら思ってました。
エージェントでこのモジュール多分動かしてないから、
別にエージェントではない。
Agent Otherjudge、エージェントではないんですけどね。
これ分かりづらいですよね。
Agent Otherjudgeはエージェントがジャッジしてるみたいな話だからいいのか。
そんな感じですね。
実装を見つけるの直前になって読み切れなかったので、
これはこれで読んでまた記事とかにまとめたいですね。
一応エージェントOtherjudgeの性能がどうなりましたみたいな話、
最後に軽く触れておくと、
Dev AIベンチマーク使って、
さっきのMetaGPT、GPTパイロット、オープンハンズ、
このコード生成エージェントを評価しましたよ。
その出力を人間指導とLLM Otherjudgeと、
このAgent Otherjudgeでまさに評価しましたっていうところですと。
論文内の記述とかそのまま紹介すると、
人間の評価と比較すると、
Agent Otherjudgeの一致率は90%になりましたと。
LLM Otherjudgeのほうは70%でしたと。
時間的にも人間の評価と比べると、
時間的にもコスト的にも97%ぐらい削減しましたよみたいなところとかで、
コストの削減とか時間の削減で言うと、
LLM Otherjudgeも多分変わらないんです。
ほぼ変わらないと思うんですけど、
人間評価との一致率みたいなところで90%と70%なので、
Agent Otherjudgeよくね、みたいな感じの結論でしたね。
評価手法の比較
ちょっとこれ論文見てみないと分かんないですけど、
LLM Otherjudgeって呼んでるものが中身次第かな。
そこは中身次第というか、
LLM Otherjudgeのこっちがしょぼい可能性とかも全然もちろん。
適当なプロンプトで70%でしたって言われてる可能性もなくはない。
そうなんですよね。
70%ちょっと低いような感覚はなんとなくある。
もうちょい頑張れそうな気がするので。
逆にあれなんですかね。
プロンプトとかは、
さっきのAgent Otherjudgeのコンポーネントとか見ると、
リトリーバルのモジュールとか入れるモジュールだったじゃないですか。
LLM Otherjudgeやってるときってその辺のモジュール一切ないってことは、
単純に情報足りなさそうだなみたいな。
本当にいないんだとしたら。
私もLLM Otherjudgeのプロンプト書いてるときって、
基本的に文脈情報とかデータ数に入ってるんで、
入れてることが多いので、
全くないってことは上にあるモジュールがないってことは、
そんなにないなという気持ちがしたので、
このAgent Otherjudgeのエージェント要素が、
このモジュールをどれが適切かをうまいこと最適化してくれるみたいな、
うまいことをクールで選んでくれるみたいな、
そういう要素があるなら、
良さそうかなという感じではあるんですが、
じゃないなら、
既存のLLM Otherjudge手法とめちゃくちゃ違うかっていうと、
どうなんだろうっていうのは。
エージェント評価の重要性
1個のエージェントシステムっぽく作りました以外の何物でもないっていうか、
あんまちょっとちゃんと作って、
LLM Otherjudgeと同じだよね。
同じなんじゃないかなって説はなくはないですし、
こう見てる感じでも、
Agent Otherjudgeのさっきのモジュールとかは出てくるコードがありそうなんですけど、
そのLLM Otherjudgeの部分とかがどうやってるかって、
コード上はなさそうなんですよね。
コード上もないし、論文のペーパーとか見てる限り、
数値もうちょっときれいに詳しく求めてくれたりとかはあるんですけど、
そのプロンプトとかが公開されてるわけでもないので、
そのLLM Otherjudgeのところね。
なのでちょっとその辺結局、
数値の話とかは正直分からんな。
でもやっぱ最終成果物だけ評価テストするよりかは、
やっぱ中間フィードバック欲しいよねっていうのは、
っていうところなのと、
元々フローエンジニアリングとか、
エージェンティックワークフローとかも、
単一プロンプトよりもそういうワークフロー組んだ方が精度高くなるよね、
みたいな話じゃないですか。
それとLLM Otherjudgeとかも高めようとすると同じだよねって言われると、
それは別にそうなんじゃないかなって思う。
基本的には。
なので中身の話とか具体はともかく、
エージェンティックワークフローの評価に、
またエージェンティックワークフローみたいな使うところの不確実性みたいなところが高まるとこ、
どうコントロールするかみたいなのはあれど、
LLMよりエージェンティックワークフローとかで評価した方が評価も良くなるよねって言われると、
その構造自体は別に間違いはなさそうだなって気がする。
そういう感じで捉えるのがいいんじゃないかなと思っています。
ちょっと分からないところは、
さっきの中間フィードバックのところとかは、
エージェントアウトジャッジでないと中間フィードバック提供できないのかって、
あんまり関連性はちょっと分かってない。
結局エージェントを評価するなら、
こちらもエージェントでもっとジャッジの評価精度高めるぜぐらいのノリにしか感じられてないので、
この辺の中間フィードバックの話どこ行ったんだっけっていうのはちょっと僕は理解しきれてないので、
もうちょいコードとか含めて読まないとなと思っています。
あとはリレーティッドワークスみたいなところに結構LMRジャッジの先行研究とかまとめられてるので、
シンプルにLMRジャッジとかこの辺のペーパー探してるときにはそこ見るといろいろ見つかるので、
単純にインデックスとして便利だなっていうところと、
あとこれ実装されてない部分とかでいうと、
このFlywheelみたいな効果をメモリーのモジュールとかあったように、
いい感じで学習して進化していくエージェントアドバッジ作りたいよねみたいなとか書いてて、
これからの展望の話ですけど、
せやなって感じの内容のことが書かれてましたっていうのがざっくり感想ですね。
すみません、バーッと話しちゃいましたけど、
せやさん的に何かちょっと話したいこと聞きたいことわからないこととかあったりしました。
確かに冒頭にちょっと触れてたラングチェーンが最近出したタイサイペ、
あれは結構シンプルに各中間ステップでLMRジャッジやるぜみたいなそんな感じだったんですけど、
あれのそことの差分、あれのアプローチの仕方そんな違和感はなかったというか、
すごいシンプルだったんでそうだよねっていう感じだったんですけど、
確かにエージェント要素がどの辺にあるのかっていうのはちょっとパッとはわからなかったので、
そうですね、コードとかも読まないとかなって感じたので、
僕がちゃんと記事にまとめることを祈っておいてください。
僕もサイペとか軽くしか読んでないですけど、
もうこれサイペでいいのかな。サイペじゃない気もしてるけど。
わかんない。
絶対サイペじゃない気もしてるけど。サイペって呼んでますけど、
サイペの方が中間フィードバックを取るっていう意味とかで言うと、
ベターというかわかりやすいソリューションだなとは思います。
だってサイペってあれですよね、本当に各ノードというか、
中間の部分そのままLMRジャッジしますみたいな話ですよね、究極。
というふうに、そうですね、例テーブルで表示しますよみたいな感じに。
そうですよね。だから都度都度最後だけじゃなくて、
都度都度ジャッジしますみたいな話なので、
サイペとかの方がさっきの中間フィードバック、
エージェントのシステムにおいては重要だよねっていう課題に対しては、
直接的に解いてそうな気はしていて、
エージェントアザジャッジのところはやっぱりLMRジャッジの精度上げるんだったら、
こっちもエージェントだみたいなテンションなのかなとは思っており、
それ自体は間違ってるかって言われると、
そこまで別にいらないよねっていうコスパ的な判断と変わると、
精度高めようとしたときの1個の方向性としてそっちに進むみたいなのは、
そうだろうなと思うので、みたいな感じでしたね。
はい、どうですか、ぜひSeaさんも。
中間フィードバックの役割
職仕事でもエージェントアザジャッジ対応したくなりましたか。
まあ、でも長く使いきそうな部分のLMRジャッジには応用していきたいなというのはあるかもしれないですね。
なんか作り込んでいったら結果的にちょっと近いものとかには生まれそうな気はしますかね、そもそも。
エージェンティックな部分が薄いだけで別に、
モジュール群は大体結構割と持ってる気はするんですよね、
LMRジャッジとか結構プロダクトのやつやろうとしてるところって。
これはあれか、コード生成エージェントの評価してるから、
ロケートとかプロジェクトの構造を把握してコードを分解するとか、
その辺とかもちろん細かいのは違いますけど、
必要なコンテキストとかを事前に作って渡すのかとか、
コードとかへ取ってくるみたいな処理が挟まってるのかとかやると結構近くはなるので、
みたいな感じで、
我々とか特にSeaさんの方とかLMRジャッジとか結構好きだと認識しているんですが、
こっちもエージェントアザジャッジとか出てきて、
また別の回のネタにしようと思ってますけど、
エージェンティックラグとかその辺とか増えてきたので、
本格的にエージェンティックアプリケーションみたいな時代が来つつあるんだろうな、
みたいなのすごい感じるっていう感じですね。
そんな感じで今回はエージェントの評価をエージェントでやるっていう、
エージェントアザジャッジについて話しました。
お付き合いいただきましてありがとうございます。
ありがとうございました。