評価駆動開発の概要
こんにちは、香谷です。 瀬谷さん、今日もよろしくお願いします。
よろしくお願いします。
今日は、ちょっと僕が持ち込んだ回なんですが、
Eval DrivenなアプローチでLLMエージェントの設計を行うっていうことについて、
書かれた論文ですね、をテーマにちょっと今日話したいなと思っております。
論文が、このEvaluation Driven Approach to Designing LLM Agents Process and Architectureってやつなんですが、
これって読まれたことってあったりされます?
この論文は読んでいなくて、香谷さんのようやくノートを読みました。
僕のメモノートね、最近書こうとしてる。
はい。
これ、概要を簡単に説明すると、
Evaluation Drivenって名前からなんとなく察する通り、
テスト駆動開発、テストドリブンディベロップメントの考え方を応用して、
LLMエージェントの開発プロセスに評価、
Evaluationを組み込むアプローチみたいなのを提案した論文って形ですね。
基本的にこの論文で最初取り上げられている背景と課題みたいな話で言うと、
我々ってソフトウェアエンジニアやってる意味として、
自動テストとかユニットテストとか、
そういう事前に定義された要件に基づいてテストケース作って、
デプロイ前に検証するって結構重点。
テストって一般的にはそういうものとかをイメージするかなと思います。
ただ、LLMエージェントには他にもいろいろ抗議するようなことが増えてますよねって話をしていて、
よりシステムレベルの評価が重要になってくるって話。
モデルレベルとかで評価するというよりかは、
プロンプト、ナレッジベース、ガードレールだったりとか、
いろんなコンポーネントで構成されるコンパウンドAIっていう、
言われるようなシステムが実際LLMエージェントになるので、
ソフトウェアでいうとこのE2Eテストみたいなものですね。
そういうようなレベルっていうのがより重要ですよねっていう話ですね。
ユニットテストっていうよりかは、
E2Eみたいなレイヤーのテストの方がLLMエージェントだと重要ですよねって話と、
あとは導入前のオフライン評価とか、
実行時モニタリング、トレーシングだけじゃなくて、
継続的に評価して評価カンテンスだって、
それを挙動に反映してだったりとか、
そういう評価をエヴァリエーションドリブンな設計だったりとか、
開発っていうのがより求められますよねっていうお話をしていますと。
結構ソフトウェアエンジニアリングだと、
シフトレフトっていうような言葉、
セキュリティだったりとかテストみたいなのを、
よりリリース前の直前でチェックするっていうよりかは、
要件定義だったりとか、
できるだけ開発プロセスの早いタイミングで考慮してやっていこうって、
シフトレフトって、
ストラクチャー編集者とかでも結構言われてたりするんですが、
もちろんそれもLMエージェント大事だと思うんですけど、
全体としてシフトライトとかって呼ばれるような、
リリースされた後評価だったりとか、
その挙動とかをもとにもう1回ちゃんと挙動を修正してっていうところが、
いわゆるソフトウェアとかプロダクト開発と同じと言えば同じなんですけど、
もうちょっとそこの重要性がより、
プロダクト価値っていうよりかは、
システムの挙動だったりとか、
そのレベルでより重要視されますよねっていうことを謳ってますと。
この3つですね、
システムレベルエバリエーションと、
エバリエーションドリブンデザイン、
ユーズオブエバリエーションリザルト、
評価結果の活用ですね。
みたいなところとかが既存のソフトウェアテストと、
ちょっとまことなるとこですよっていうのを最初に謳ってますと。
システムレベルでの評価の重要性
この辺、瀬谷さん感覚的には聞いてみて、
どうですか?同じですか?
そうですね。
なんかもう言ってることすべてが真っ当すぎるので、
なんか、
いやーそうですよねーという、
そうなんですよね。
なんかシステムに組み込むときって、
書かれてる通り、
例えばガードレールとかだと、
モデル単体でガードレール完璧に満たそうっていうよりは、
もう前段でキーワードマッチで弾いちゃうとか、
なんかそういう他の選択肢って普通に取ったりするので、
なんていうか。
ですね。その辺とかは、
そうですね。
なんかソフトウェアとか、
ウェブサービスみたいな形の中に組み込もうとすると、
またちょっと話は変わりますよね。
結局なんかUIとか、
そもそものユーザーからの見え方とかで、
ガードレールをめちゃくちゃ気にする必要がないみたいな体験とかって、
全然作り得るとは思うので、
ものによっては。
そういうとこだとそもそもガードレールってもの自体が、
ないことはなかなかないと思いますけど、
そんなにシビアにテストする、
評価するっていうモチベーションがないとかも全然あるかなとは思いますね。
この辺とか2Cとか2Bとかでも変わりそうで、
そうですね。
なんかないとは言わないんですけど、
2Cと比べると多分、
結構怪しい感じのプロンプトを入力する人って、
2Bでエンタープライズ企業とか入ってくると、
率は絶対減るのは間違いないと思うので。
契約、
そうですね。
なかなかチャレンジングの方ですね。
なかなかプロンプトインジェクションとかを試みる人もきっと、
現状だと2Bプロダクトとかの方が少ないだろうと思うので、
その辺とかの塩梅とかは。
結局システムレベルとか、
そのシステムのユースケースとかドメインとかで、
かつシステムレベルとかで考えないと、
結局適切な評価とかにはなりづらいですよねっていうことなんですけど、
他に何かあれですか、
LMプロダクトとかワークフローとかエージェント、
何でもいいんですけど、
テストとか評価に関して悩ましいこととか、
この辺難しいなみたいなものとかって、
今ぱっと思いつくものとかあったりされますか?
悩ましいもの、
そうだな。
ちょっと評価に関しては、
やっぱりテストとか評価に関しては、
これ書かれている通り、
継続的な評価とインテリティブに改善していく、
その評価の仕方とかを改善していくって、
すごい大事だと思うんですけれども、
そもそもLMを搭載した機能がそんなに受けなくて、
何かそんなにいらないような機能があったりとか、
そもそもLMを搭載した機能がそんなに受けなくて、
何かそんなにいらないような機能があったりとか、
そうだから、このプロダクト開発フロー全体の中で、
とはいいつつも、
強化ドリブンでやったほうがいいよなと思ってはいるんですけど、
この評価への投資具合とのバランスといいますか、
多分、
E2Eテストを書きすぎないほうがいいよねとかと、
ちょっと似てるようなものがあったりとか、
そもそも、
E2Eテストを書きすぎないほうがいいよねとかと、
ちょっと似てる感覚だと思うんですけど、
本当に感覚としては近い気はしますし、
結局、プロダクト新規で作るみたいな話で言うと、
顧客から評価されてないのに、
我々がシステムの評価してもしゃあないなみたいな、
顧客から評価されないことにはな、
みたいなところとかとちょっと近いのかもしれないが、
そうですね、その辺とか、
その辺りの始め時みたいな話とかはなかった気がするが、
実務レベルとかだと、
その辺とかは濃淡はありますよね。
これとかで言うと結構がっつり、
アーキテクチャーというかシステム組むってお話ですけど、
実際はもうちょっと、
特に昨今というか現時点だと、
もうちょっと泥臭く始めてっていう例とかが、
多いと思うので。
そうですね、
でもとはいえ割と初期の段階でも、
ある程度評価基準みたいなものは言語化していかないと、
何をゴールにプロンプトチューニングしていくんですか、
みたいなものが、
自分一人の感覚だけでとりあえずウェイでOKならいいんですけど、
他のチームメンバーとか巻き込んでやっていくときには、
評価プロセスモデルの提案
そういうのを言語化していかないと微妙になるんで、
この評価駆動っていうのは割と初期から、
そんなカチカチにやるのはあれですけど、
やっていってもいいんじゃないかなっていう感覚。
具体の中身まだ話してないんですけど。
でも評価基準は最初からいるんじゃないですか。
そうですね。
普通評価基準は最初からいる気がするし、
どうだろうな。
逆に普通にプロダクトなり何でもいいんですけど、
開発しようとすると、
どこまで作り込むとか磨き込むかとかはともかく、
評価基準っぽいものが自然と出来上がりますよね。
そうですね。
どこまできれいに言語化するかとか、
パターン揃えるかとか、データセットきれいに揃えるかとか、
自動的に評価を回すようにするかとか、
その辺はともかく評価基準が作ってる人間とか、
このDomain Expertの人の中にも、
ゼロって例とかも逆に難しそうな気もしますね。
何を考えてプロンプト書いてるんでしたっけみたいな。
通訳を見たときに何も感じてないんでしたっけみたいな。
感覚がある。
そんな感じですかね。
これは、
このシステムのライフサイクル全体にあたって、
評価みたいなのを組み込んで、
継続的なプロセスとして、
学習、ループ、サイクルを回しましょう、
というようなざっくりしたお話です。
この論文は、
このLMAgentをどうやって体系的に評価するかというところと、
継続的な評価を、
エージェントの設計とかアーキテクチャで、
どう実現するかというところに対して、
LMAgent評価のためのプロセスモデルというものだったりとか、
コンパレンスアーキテクチャというものを考案してくれてる、
という内容になります。
なので、基本的には評価駆動設計というものは、
ライフサイクル統合、フィードバックループ、継続的な学習と改善、
この三つの仕様原則に基づいた評価駆動設計というのがありますよね、
というのを主張していて、
それのもうちょっと具体評価、どう進めるかというプロセスモデルと、
それをシステム的にどう組み込むかというアーキテクチャモデル、
リファレンスアーキテクチャというものを提示しています。
プロセスモデル、どんなものがステップ、
考案されているかというのを簡単にお話しすると、
主要なステップは四つです。
まずは評価計画の定義です。
これは、いわゆるエージェントとかのあるべき姿を定義する、
いわゆる評価基準を作りましょうとか、そういう話ですね。
評価の目的とか、範囲とかシナリオとかまで含めて、
その辺り計画をまず立てましょう、というのがまずファーストステップです。
その次がテストケースの生成となっていて、
先ほどの評価計画基準に基づいて、
一般的なベンチマークを利用するのか、
さらにシナリオをこういうテストケースとか、評価データセットを取っているとか、
使う、作る、というところが次のステップ。
ここは、いわゆるドメインエキスパートの意見を活用、収集して反映したりとか、
必要に応じてLMを使って合成データを作りましょう、だったりとか、
HKSをカバーする必要もありますよね、みたいなところがお述べられています。
続きがオフライン、オンライン、問わず両方評価を実施します、というプロセスですね。
オンライン評価、ここで言っているのは、どちらかというと、
リリース後みたいな話とかが近いんだと思いますけど、
実際のリアルワールドの継続的なモニタリングだったりとか、
そういうところのことをオンライン評価と呼んでいますと。
あとは最終結果、最終の出力みたいなのはそうなんですけど、
中間プロセスとか、中間の生成物、アーティファクトも評価する必要がありますよね、
という話をしていたりとか、出力とかもユーザー満足度だったりとか、
リアルタイムな調整と評価
もうちょっとシステムレベルとかでの指標で見るというのも述べられていますと。
あとはユーザーフィードバックデータとかも含めてですね。
その次は分析と改善というシンプルなステップなんですが、
これもオンライン、オフライン両面で改善できますよね、という話をしていて、
シンプルにいわゆるソフトウェアで言うと、コード修正してもう一回リプレイし直してみたいな、
システムの改善収集、デプロイみたいなアプローチ。
これはあんまり具体な例は書いてなかったんですが、
運用中にリアルタイムに調整します、みたいな話をしていて、
これはプロンプトとかパラメーターとかっていうのを、
フィーチャートグルみたいな形で後からいじれるようにして、
それで調整するっていう話なのかもしれないですけど、
単純にデプロイとかコードの修正とかがっつり挟む以外にも、
リアルタイムにそういう挙動とかを調整するみたいなのが、
要素としては組み込まれてる感じでしたね。
あとはそれを求めて安全性みたいなこととか、
その辺を更新するとか、先ほどの評価計画のほうにも
一回反映するみたいなのを回しましょうっていうプロセスモデルを書いてくれてますと。
細かいところはともかく、
これも結構そんなにめちゃくちゃ違和感あるわけではないですよね。
あるべきのプロセスモデルを描いてくださいって言われたときの、
全体感というか、オーバービューみたいな話とかで言うと。
真っ当すぎてというか、
特に足すコメントがないぐらいの話ではあるんですけど。
運用中のリアルタイムな調整みたいなところで、
私はやったことないんですけど、
具体例として1個思い浮かんだのが、
ラングスミスが評価をしていくと自動で、
評価は人間が手動で、
これ良くないみたいなので評価していくんですけど、
評価っていうかアノテーションに近いかもしれないですね。
していったものを自動でプロンプトのフューショッツに加えていくみたいな、
そういう機能を提供していたりするので、
それは割とリアルタイムな調整の具体例として、
そういうのもあったりするかなって思いましたね。
リファレンスアーキテクチャの概要
それってラングスミス、ラングチェーンとかプロンプトハブあると思うんですけど、
あそこに入れてラングチェーンとかからプロンプトテンプとか呼び出してたら、
それで勝手に実プロダクトのやつも差し替わってくれるんですかね。
それは確かに近そうですね、だいぶ。
多分そんな感じなんだろうなと思いますね。
あともうちょっと、なるほどなと思った私が存じ上げなかったので、
思ったのは解釈的フィードバック、インタープリテイティブフィードバック。
どうしてその、なぜユーザーが不満を感じましたかとか、
フィードバック提供した誰とか評価の文脈、
なぜその出力が改善の余地ありと判断されたのかだったりとか、
そういったもうちょっと訂正的な情報とかも踏まえて、
フィードバックを捉える評価手法みたいなのがあるらしくて、
これは確かにLMエージェントとかプロンプトとか、
そのあたりの修正とかっていう意味とかだと別にそれに限らないですけど、
確かに重要なフィードバックの捉え方だなとは思いましたところと、
ですね、そんな感じかなで、
そうで次リファレンスアーキテクチャーをちょっと軽くお話しすると、
こっちは本当になんかざっくりオーバービューで、
僕の見た限りGitHubとか別にサンプル実装とかがあるわけではないので、
本当に何でしょうね、オーバービューって感じのリファレンスのアーキテクチャーだったんですが、
継続的な評価を設計の要素として組み込む評価ドリブルを実現するためのアーキテクチャーっていうところで、
提案されているものがあって、ちょっとコートだと説明しづらいので、
図とか気になる方は論文とかを直接見に行っていただきたいんですが、
レイヤーとしてはサプライチェーンレイヤー、エージェントレイヤー、オペレーションレイヤーって3つですね、
のがざっくりレイヤーとしては作られていますと。
基本的にエージェントレイヤーっていうのが、いわゆるエージェントの実行環境、実行されるところですかね。
エージェント自体が動くところ。
なので、エージェントレイヤーの実行結果がオペレーションレイヤーっていうところ。
ここが実際のエバリエーション評価を行ったりとか、それを貯めたりとか、
テストケース持ってて実行したりとかっていうところなんですけど、
そこの実行結果がオペレーションレイヤーによって継続的に評価されて、
その結果元にサプライチェーンレイヤーっていうものにフィードバックされて、
サプライチェーンレイヤーっていうのが生成された評価のデータだったりとかを収集して持っていて、
新しいテストケースとかを生成して、さっきのオペレーションレイヤーで実行するテストケース追加するだったりとか、
そういうようなレイヤー間の連携がされるっていうのが想定されてるっぽいですね。
なので、オペレーションレイヤーのところにいわゆるエバリエーターとかテストケースレポジトリとか、
エバリエーションリザルトレポジトリとか、セーフティーケースジェネレーターみたいなのが定義されていて、
ここが一番LMLopsとかの評価実行基盤、実行レイヤーとかに近いイメージですと。
それがテストケースジェネレーター、オンライン評価とかで例えば発見されたエッジケースっていうのは、
テストケースジェネレーターを通して新しいテストケースとして、
評価基準の管理
この場合はどこなんだ、サプライチェーンじゃなくてオペレーションレイヤーのどっかのDBとかに格納されるのかな、
として入って、それが次のオフライン評価に活用されますっていうようなところですね。
細かいところとかはともかく、基本的にライフサイクル全体で評価を中心にライフサイクル全体でフィードバックループを回しましょう。
オフラインおよびオンライン評価両方とも活用しましょう。
同時にモデルとシステムとか両方のレベルで適応的なチューニングを回しましょうっていうのが基本的な使用原則で、
基本的にはそれが一番大事なものなのかなと思いますと。
こんな感じなんですけど、どうですかこのアークテクチャイメージはきますか。
でもそうですね、たぶんざっくりサプライチェーンが人間というか我々開発者の行動を表していて、
オペレーションが評価と評価をするためのデータセットとか、
あとは実際のシステムがエージェントレイヤーと呼ばれているという感じで、
割と整理としては、なんでこの名前になってるんだろうなっていうのはあまり直感的にパッとはピンとは来てないですけど、
分け方としてはすごい分かるというか、そうですね。
名前が毎回サプライチェーンレイヤーってちょっと何だったかよく忘れちゃうんですけど、この名前つけられると。
そうですね、エージェントの実行基盤、エージェントレイヤーが実製、プロダクトに近いというか。
そうですね。
もので、オペレーションレイヤーって呼ばれるものがエバリエーションを実際に動かす、その他もろもろって感じで、
サプライチェーンレイヤーとかは、ここで見るとシステムっぽくなってるような気がするが、
システムでも人間でも、多分どちらでもワークするような感じな気はします。
ここがシステムになってなくてサプライチェーンレイヤーの評価計画立ててとかデザインしてとかデータ集めていったのが、
人間がラングスミスでやって、エバリエーションを動かすのもラングスミスでやってっていうのが、
もうちょっとシステムで自動的にマリオインするっていうのが、
それとこのリファレンスアーキテクチャに近くなるだろうなというイメージですね。
結構、せやなって感じですよね。分かるっていうか、良さそうみたいな。
そうですね。
ちょっと前に話したEvalGenか、
フーバリエーターとも結構似ているというか、
やっぱこういう形にみんな落ち着いていくんだろうなという感覚を受けましたね。
ですね。めちゃくちゃフーバリエーター、フーエバリエートザイバリエーターズでしたっけ。あれはかなり。
世界観としても近いですし、むしろ組み合わせて。
あっちの方がもうちょっと具体的に評価基準を継続的にアップロードするにはどうしたらというところのフォーカスだったと思うので、
ちょっとレイヤーとか言うと違いますけど、むしろ保管して参考にして使えるような内容になってそうな気がしますね、お互い。
そんな感じなんですか、リファレンスアーキテクチャは。
1点、論文の中でも注意みたいなので書いてたのは、
シンプルに実世界で大規模にちゃんと使われたわけじゃないよねとか、ドメイン特有の何かへの適用がいるよねとか、
システム的なスケーラビリティの検証はわかりませんみたいな話があったりとか、
実用された何かとかではないので、だからリファレンスアーキテクチャって名前なんだと思いますけど、
そこは一応注意ですってところを一応、論文内にとかでも言及されてます。
で、結構細かく見ていくといろいろとちょっと今回端折りましたけど、この論文内のところでオンライン評価とはオフライン評価とはについての定義みたいなところがあっているとか、
評価全般の概要を抑える意味でもわりと便利な、有用な内容だった記憶をしておりまして、
そういう意味でも結構良かった、面白い論文だったなってところと、ここからちょっと所感的な話になりますが、
バーセルとかもEval-Driven Developmentについてテックブログ書いてたりとか、
RayXさんとかも書かれてたりとかするように、やっぱりこの評価っていうものを前提にサイクル回しますっていうのは基本的にみんな考えることは同じかなと思っているので、
まさしくそれを体現するような内容だったなってところと、
とはいえ評価の評価基準とか指標みたいな話とか、システムレベルでどう定めるみたいな話だったりとか、
さっきの進め方、自動化とかリアルタイムでできたらいいのかもしれないけど、
それってどのタイミングでどう進めてどこまでどうやるんでしたっけっていうようなもうちょっと時間軸が入ってくるような話だったりとか、
そういうところとかはそれぞれおのおの頭悩ませながら今はやるしかないなっていうところ。
でもアーキテクチャーとかプロセスモデルはそのまま使うかをさておき、
普通にめちゃくちゃ参考になるものだと思うので、
なんとなく全体感とかをちょっと迷子になったときには戻ってこようかなって思えるような論文ではありましたね。
いまだに評価基準っていうものをどうやって管理しようかみたいなものを私の中でそんなに決まった甲斐がなくて、
適度に言語化ノーションとかでまずはしていったりはするんですけど、
あとその評価用のコードとか、
エデラマズジャッジとか普通のプログラミングで評価コードとかを書いたりするんですけど、
それである程度表現はできつつ、
でもそれでいいのかな。
評価基準って呼ばれているものをどうやってチームの資産として溜めていくのがいいんだろうなっていうのはまだそんなに私の中で甲斐がないですね。
それはそうなんだよね。
その辺とかはもはや新しいフォーマットを開発したいくらいなんだよな。
こういうふうにこのプロパティをこういうふうに管理するといいみたいなね。
YAMLというかXMLの使い方なのかもっと違う何かなのか分からないけど、
そういうのとか作りたいなって常々思いますね。
そうですね。
ある程度構造化しておくと別にどこに格納するにしても扱いやすいし、
プログラマブルに扱いやすくなってたら評価基準とかって言っても別に数万とかやる気とならないじゃないですか、すぐに。
そうですね。
言っても、あとそんなにやっても、そんなにやる場合って多分ここで話してるリファレンスアーキテクチャみたいなのがガンガン回ってる世界線とかで、
なんなら勝手に増えてるぐらいの世界線の話だと思うので。
確かにそういう構造化した形とかメタデータとかを付与された形で評価基準っていうのをいい感じのフォーマットでいい感じに定義して、
最初は別にSPCでもNotionでもJSONファイルリポジトリのように持っててもよいが、
どっかで何か増えてきたらDBに移してプログラマブルにアクセスできるようにするみたいなのは定期的にトライしては、
評価駆動開発の基本
そこまでやらなくてよかったなとか聞いてなかったら別にいいや、みたいなのとかを繰り返してる気がする最近。
確かにこの辺の舞台とかは、なかなか話しづらかったり、Tipsとかあっても自信がなかったりとか、
あとめちゃくちゃ細かすぎて話しづらかったりとか解説法とかの話とかもそうだけどあるので、公開しづらいレイヤーの話とかではありますよね。
そうですね。
公開しづらいかな、どうだろうな。公開しづらくないかな。
これで10分のLT作るのとか記事書くのがめんどくさそう。
評価基準の具体の中身は言いづらいなっていうのはありますね。
それはそうですね。
もはや何作ってるのかみたいなものがすごい明確になっちゃうから。
いや確かにな。VTTでしたっけ、書き起こし字幕を表現するやつあるじゃないですか。
時間があって話した人があってテキストがあってみたいな。
ああいう感じのフォーマットを生み出したいなって思いますね。評価基準は書く。
そうなんですよね。採用している会社がどれくらいあるかわかんないんですけど、
E2E文脈だとATDDっていうのがちょっと流行ってたのかな。
採用してた会社がいくつかあって、要は受け入れ条件ですね、スクラムの。
受け入れ条件をテストケースの文言にして、それをパスするE2Eをカスクみたいな、
そういうフォーマットを作られたことがあったりして、
理想論としてはそういう感じのフォーマットを生み出せると気持ちいいかもしれない。
確かに。受け入れテスト駆動開発、アクセプタンステストドリブンデベロップメントですよね、ATDD。
確かにATDDとか名前忘れましたけど、よく書かれる、なんだあれ、何でしたっけ。
BDDってこれですか。
BDDってこれですか。
When Then Verifyみたいなやつとか、あれもっとシンプルですけど、
ああいう系のやつとかでうまく構造化してみたい欲が何でだろうな、これは。
何でこんな欲が生まれるのか分かんないけど、こうするといい感じにやっぱり管理できそう感とか、
フレームワークとして分かりやすくなってたりとかすると便利だなと思いますしね。
ATDDとか存在は知ってるし、なんかちらほら記事とか例とか見たことあるけど、あんまちゃんと業務で使ったことはないんだよな。
どうだろう、使ってるかも。
でも受け入れ条件とかっていう意味だと確かに結構きっちりやってるが、
ATDDとは呼んでないから、公式のATDDとどれだけ差分があるものなのかが分かってないっていうのが違いかもしれない。
弊社も昔やっていたはずだが、今はやらなくなってたので、その理由深掘る面白いかもしれないな。
懐かしいな。前職でE2Eのフレームワークとか1か1から考えるときに、
ATDDのE2Eフレームワークとか調べて、いろいろとエグザンプル書いてた気がするな。
何も覚えてないですけど正直。
何試してたんだろうな、あのとき。
でも確かにATDDちょっと近そうですって、このフォーマットでまとめるとか、参考にしてまとめるとかは結構もしかしたら、
意外と一番はめやすいかもしれない。
はめることに意味があるかともかく。
そんな感じかな。
他に話したりないこととか評価回りとかあったりしますか。
オンライン評価の意義
評価回り〜。
評価回りじゃなくても別にいいけど。
なし。
なし。
なんかあった気がしたけど。
そうなんですよね。
いつも質問はゆるふわでしか考えてないから、思いついたやつから忘れてたりとかするから、
最後になると特に全く覚えてない。
収録終わったら思い出すんですけど。
もうちょっといつまで経っても学習サイクルが回ってないな。
ちょっと一個、オンライン評価の定義が書かれてるみたいな話がちらったったと思うんですけど。
そうですね、書いてあったはず。
これちょっと後で読んでみようと思いますけど。
ここ、私オンライン評価っていうフレーズを、私ソフトエンジニアリング出身なんで、
ラングスミスが言ってる用法で最初に知ったんですよね。
要は、ラングスミスのオンライン評価が何かっていうと、
実際に取られたログに対して自動で評価を実行していくっていうもので、
それはリアルタイムに実行してるからオンライン評価な気はするんですが、
機械学習バックグラウンドの方とお話ししたときに、
実際のログに対して評価を行うっていうだけだとオンライン評価感はなくて、
リアルタイムに実行されているっていうことがオンライン評価感があるみたいなことをおっしゃっていて、
そこが同じオンライン評価っていうフレーズでも微妙に言葉の定義が違うんだなっていうところで、
LMで新しくこの概念に触れた人と機械学習出身の人で微妙に感覚違うところ出てくるかもなとか、
そういうのをうっすら思ったりしましたっていう。
確かにそれはそうですね。
この論文だと今の例だと機械学習文脈。
オフラインが実ユーザーのアクセスじゃないとか制御された環境とかでの評価みたいな話。
ローカル環境とかそっちに近いような話って確か書いていて、
オンラインは実世界、英語圏とかでよくあるリアルワールドみたいな言い方してましたけど、
実際のユーザーのリクエストだったりとか多分プロダクト動いているプロダクトベースとかの話とかをオンライン評価って言ってた気がする。
僕も正直オンライン評価とかオフライン評価とかの正式な定義みたいなのをちゃんと精査して暗記してるわけじゃないので、
その時読んだ最新のいいなと思った定義とかで勝手にアップデートされてる気はしますけど、
オンラインとかはそうですね、プロダクションみたいなイメージとかは確かに強いですね。
オフラインとかがどっちかっていうと、今までのソフトウェア開発とかにはめるとユニットテストとかローカルでのテストとか、
そっちとかデータ、過去データ、そっちのイメージのほうが近いかもしれないですね、なんとなく。
今のところ定義のずれで困ったことがないんで、そんな気にするものでもないかもしれないですけど。
そういう意味で言うと、リアルタイムである必要性、逆に私そこまで感じてないから、
実際のログに対しての必要性っていうのは、
リアルタイムは厳密に言うと、多分リアルタイムとオンライン評価っていうのも内包する概念ではないんですけれども、
一応その中でもリアルタイムの名前が違うんで、
リアルタイムって言われてるんですけど、
実際にそういう機能があるんじゃないかとか、
おだしょー リアルタイムは厳密に言うと 多分 リアルタイムとオンライン
評価っていうのも内包する概念では あるとは思いますけど 完全イコール
ではないですよね オンラインでは あるけど 別にリアルタイムではない
っていうのは それはそれである 気がする 普通に 実際のユーザー
が使ってもらった上で評価する とかのほうが近い気がしますね
オンライン評価は ここで言ってる リアルタイムとかは 本当にリアル
タイムで何かチェックして 何なら 動きのチューニングもしちゃい
エージェント設計の未来
ましょうとか そっちの分明がある からリアルタイムっていう概念
があるんだとは思いますね そんな 感じですね
そんな感じで 今日はイーバルドリブン なヒルムエージェントの設計について
書かれた論文について話しました 瀬井さん 本日もありがとうございました
はい ありがとうございました
はい ありがとうございます
