AIエージェント開発におけるシステム開発とデータサイエンスの融合
いかにシンプルにかついかに精度の高いエージェントを作るかっていうところが、実社会では求められているもので、データサイエンスの仕事というよりかは、エージェント開発ってもうシステムエンジニアとか、そっちの世界かなというふうには実際に自分やっていて思うところで。
一年ちょい前ぐらいに、そっちの方向には会社の仕事としてはやらないぞっていう意思決定をした記憶がよみがえたわ。ADKの話のエピソードをしたときに、なんかそんな話した気がするよね。エージェントデベロップメントキットの話をさ、GCPの。
確かにやりましたね。
あれ?みたいな。できるやんみたいな。
そうですね、ありましたね。ちょうどADKのときにその話をしていて、エージェントが使うツールとかどう揃えるかみたいな話を進めていくことは多分、もう経験のある人たちがたくさんいるから、そこで価値を出していくことは難しいなと思ったっていう話をちょうどそのときにしていて。
自分も結構共感しましたね。
今逆に言うとエージェントを作るっていうところに向き合ってるわけでしょ?
そうなんですよ。やって気づいたこととしては、今どっちの話したように半分くらいがシステムを作るって話なんですけど、もう半分はやっぱりデータサイエンス的な素養もないといけないなと思っていて。
それは何かっていうと、データをどう扱うかっていう部分。
今回で言うと、いろんなテーブルデータとかデータベースとか画像動画、ありとあらゆるデータの形式があると思うんですけど、それをAIに理解できる形に落とし込まなきゃいけないわけなんですよ。
そこってシステム開発してた人ってあんまり経験なくて、どっちかっていうとデータサイエンスをやってた人が得意な話で。
データサイエンスをやってた人って今までデータをいかに機械学習とかモデルに組み込むかみたいな、どうやって特徴を抽出するかみたいなことばっかり考えてた人なんで、
その考え方がまんまAIエージェントの場合でも適用できて、
例えば動画をAIエージェントに理解させに行こうとした場合って、動画の中にある文字情報とかを抽出するモデルを適用させるとか、
画像処理を行ってからAIにとって必要な情報だけを抽出してあげるとか、テーブルデータとかもそうですね、さっき言った特徴量を1回作ってあげてからAIに渡すとか、
っていうことをしていくことで、いわゆるデータに対して前処理を行うことでAIはすごい効率的に情報を抽出できるみたいな、っていうところをやることが、
実は精度のいいAIエージェントの回答を得られるためには重要だよねってところも見えてきていて、
ただただ生データをAIに渡すのではなくて、前処理をしていく重要性みたいな。
なのでシステム開発とデータ処理、この2つをうまく組み合わせると、AIエージェントはすごい良いパフォーマンスを出せるよねっていう、そういうものなのかなと。
一方でデータ処理なんてもういらんやんっていう意見もあると思うんですよ。
まあね、わかるそれは。
コンテキストウィンドウの限界と大規模データ処理の課題
それは多分個人開発とかやってるような人たちが扱うデータ量だったら確かにいいのかもしれない。
クロードとかGPTとかジェミニとかが大量のコンテキストを扱えるようになってきてるから、
数ギガぐらいのデータ量だったら確かにそれを全部エージェントサーチみたいなのをして、
必要な情報を抽出すらできるし、今後もモデルが賢くなるとそこの見える幅は広くなってくるんですけど、
一方で会社の中とかで扱うデータって多分数テラとかもっと上ですよね。
大量のデータを扱うってなった時には多分現実的じゃないし、今後はまあそこの全体を舐めにいくようなサーチにどんだけお金かかるんだっけっていう話。
確かに。
会社はそこにお金は払えないし、
とかなってきた時にやっぱりデータをきれいに整えるっていうことが重要だったりするんで、
どっちがさっき言ったやデータを整えましょうとかAIが扱えるようにしていきましょうに舵を切ったって話はまんまAIエージェントの開発にも生きてくる部分なのかなと思うんですよ。
なるほどね。
あーそっか。
回り回ってみんなAIにとっていい方向って何だけを考えて動いているのかなと。
うんうんうんうん。
それがね分かってきたんですよねここ最近は。
確かに。でもなんかコンテキストウィンドウが広がっていってほとんどのこと解決できるじゃんっていう発想でちょっと留まってた感じは今の話聞いて思ってて。
でも確かにそんなユースケースはまああんまりないんだけど、スーテラとかの規模になった時なおへの対応能力はデータ整備だけじゃ無理だね。
そうですよね。
エージェント側を自分で整備しておかないと不可能な範囲がかなりありそう。
効率的な情報探索技術と古典的ツールの再評価
ここ最近お金がかかるが結構シビアになってきてるかなと思っていて。
そうね。
各AI企業はお金儲けに動いているんで。
まあまあまあ。
AI使えば使うほど金かかるよねっていうところが顕在化してきて。
で、そうなった時にいかに効率的に情報を探索できるかとかっていうことが今後は注目されてくる技術の一つかなっていう。
確かに。
ところでは今回のコンペは話は戻すんですけど、情報をいかに効率的に探索できるかっていうことを競うのが本質的なテーマのコンペになってるんですよね。
はいはいはい。
そこの観点でじゃあどういうふうにエージェントを作っていくかとかツールを組み込むかとかっていう工夫を色々試行錯誤している。
言ってることは分かった。
言ってることは分かったんだけどどうやるんだ。
そうですよね。
やり方が全く分かんないなと言ってやんすか。
マジで分かんないな。
自分も本当にどうやるんだっていうところから始まって色々と技術を調べていくと本当にそういうことを考えているような分野の研究ってたくさんあって。
有名なところでいくとリアクトっていうLLMの中では古典的な技術があるんですけど、リーズニングアンドアクティングなるほどね。
AIが例えばさっきのクエスチョンに対してデータを見に行く。
この作業を一旦AIが推論をしてじゃあ一回データを見に行きましょう。
データから必要なところを抽出してきてこれでさっきの質問に答えれるんだっけを一周回してみてうまくいったうまくいかなかったの結果が出ますよね。
そこに対してじゃあもう一回これでうまくいかなかったからフィードバックをかけて、
一回さっきの投入表の質問に対して次はあっちのデータを見てみようってところを何回も何回も繰り返して最終的に答えを見つけるみたいな。
っていう探索のループをエージェントシステムとして組み込んでおいて答えを出すっていうやり方があるんですけど、
そのイメージをどんどん拡張していくことで効率的な探索ができたりするんですね。
機械学習の勾配効果法みたいな感じだ。
でも近いですね確かに。最適機械を徐々に絞り込んで見つけに行くとか。
一回打って、であ柵がこっちにあるみたいですっていう。
まさにそのイメージかな。
わかりやすい例とかだったら、例えば富士山が世界遺産になった年の日本の総理大臣は誰みたいな質問があったときに、
今この質問って2つの情報を見に行かなきゃいけないんですね。
まず富士山が世界遺産になった年っていつなんだっけっていう情報の探索と、
そこから得られた答えに対してその何年っていう情報から日本の総理大臣の時代ごとの総理大臣の名前を見に行くっていう2つの探索。
これをマルチホップQAみたいな言葉で言ったりするんですけど、
複数の情報に対してクエスチョンとアンサーを得るみたいなっていうところの技術があって、
じゃあその時に最初に与えられた質問をまず2つに分割しておこうとか、
富士山が世界遺産になった年を探索するっていう1つ目のクエスチョンと、ある年の総理大臣を名前は何だっけっていうクエスチョンが2つ目になって、
それぞれで探索をかけるっていうクエスチョンの連続性と、そこで得られた情報を次のエージェントに引き継ぐみたいな、
っていう内部の推論の仕方を組み込んでいくみたいなシステムとして、
古典的ツールの有効性とAIエージェントへの応用
どんな質問なんだっけをまずはAIが理解をして、何を調べなきゃいけないんだっけってところを推論させるっていう、
結構エージェントにとっての前処理みたいな技術があったりとか、
はいはいはい。
とかとかこういろんなこういう基本的な技術がいっぱいあって、
それを1つ1つ組み込んでいくみたいな話があったり、
今聞いてる内容をクロードに打ちながらめっちゃ考えてるわ。
AIにとっての探索っていう話でもいろんな技術があるんで、
それを組み込みながら今回のデータ与えられてるデータセットに対して適切なものは何なんだろうを探索しながら当てはめるっていう、
そういうやり方になっていて。
結構あれに近いよね。最初に俺が話したような教科学習的なアプローチにも近いっちゃ近い。
そうですね、確かに。
どっちに行ったらいいのかっていう。リアクトっていうのがそもそもあれなんだね。
何回もアクションするもそうだけど、思考・行動・観測のループを回すっていうことなのか。
そうですね。
どっかを起点にする、さっき話してたみたいな旗を立てて、そこから行動をして、観測をして、また思考をしてっていうので最適解にアプローチしていく。
これって前処理が大事みたいな発想って、コンテキストウィンドウがめちゃめちゃ閉じてたとき、そんなに大きくなかったときに、
人間の判断に近いようにどうすればいいかって言って、ラグみたいなアプローチを取ってたのの、超大規模版みたいなことか。
確かにそうとも言えるか。
ラグとしてLLMが探索しやすいように、今だったらコンテキストサーチでカバーできるようなものも、
ラグとしてちゃんと構造化させてやっていくのがいいよね、みたいな発想だったわけじゃん、ラグって。
で、今あんま効かなくなったのって、おざかしいことをしなくてよくなったみたいなことになってきてる。
のの、テラバイト、ペタバイト級データでやろうとしたときにコンテキストウィンドウ足りない場合、やっぱり同じようなアプローチが必要だよね、みたいなことか。
まさにそうだと思いますね。別にラグは死んでいるわけじゃなくて、ユースケースに当てはまる場合はかなり有用なやり方だよね、っていうのがあったりとか。
なるほどね、確かに。
あー、そういうことか。
ナレッジベース、ナレッジグラフ、そしてソブリンAI
で、そのした処理のうちの一つに、データベースを全部グラフ化するみたいなのも、例えば一個手法として入るわけ?
あー、もちろん、そういうのもありますね。今回の場合は結構当てはまると思っていて、そのデータベースが何度も更新されるようなケースじゃなくて、決められたデータベースだから質問に対して答えを見つけてくるっていう話なんで、
であればもうデータベースを最初にベクトル空間に落とし込んで探索するっていうやり方は一つアプローチとしては、まあ、ありというか。
そうだね、そうだよね。
今さっきの富士山の話を聞いたときは、そういう質問の類だったらナレッジベース作る方、ナレッジグラフ作る方が絶対いいじゃんって。
俺は頭の中でそれが出たから。
そうですよね。
2013年っていう能動から富士山と織田市を探しに行くっていう探索だから、コンピキストがめちゃめちゃ複雑になってもグラフだったらいけるなみたいな。
そう思いますね。
そう思って、さっき言われたことをそのまんまクロードに投げたらナレッジベースのアプローチはあるよねって何かナチュラルに言ってきたから、感覚は多分つかめてる。
でも言われた話、全くその通りだし。
なんで今回のそのクエスチョンがいろんなありとあらゆるジャンルだったり質問の仕方をしてくるから、そこに合わせてじゃあデータをどう加工するべきかみたいなところ?
もしかしたら大事だったりするのかなとか。
そっか、いろいろ出てくるな。
単純にグレップみたいなものでキーワードを検索して周囲を探索するとか。
いや、あると思います。
面白いなと思ったら、イズグレップオールユーニードみたいな論文があって。
アテンションオールユーニードってやつだ。
だからグレップっていう、単純に文字列検索ですよね。
は本当に使えるのかみたいなことを検証した論文があって、結構最近それを読んでたんですけど、やっぱりタスクによってはグレップって実はラグとかよりもめちゃめちゃ正当率高いよねっていうのがあって。
それはイメージつきますよね。
決められた単語、文章から探索しようと思ったら、グレップはやっぱり大事で、わざわざラグにする必要なかったりするんで。
なってきたときに、やっぱり古典的な技術でも今回のコンピューターもしかしたらかなり効くよねっていう発見もあるかもしれないし。
そうだよね。
実際に会社の中で使ってくれたときにもグレップは全然使える技術だし、クロードとかの探索とかを横の画面で見ていくとグレップで必要な情報を探索したりするから。
クロードグレップめっちゃ使うよ。
めっちゃ使う。早いですからね。
それで思ったんだよね。なるほどなと思って。AIってグレップ好きだなって最近すげえ思ってる。
本当にそう思いますね。
結構俺、研究のとき使ってたんだよね、グレップ。使ってたから、人間がパイプとかで繋いでやっていくときすげえだるいなと思ったけど、AIにとってはものすごい使いやすいツールだみたいな。
そうですよね。
そういうツール群が見直されてるらしいね、最近。
そうなんだ。
AIエージェント開発におけるツールの整備とデータ加工の重要性
グレップとか、あとこの収録の前に動画編集の話したじゃん、AIで動画編集するみたいな。
で、Pythonで動画編集するときってFFMPEGみたいなやつを使うんだよね。
はいはい、確かに。
もしかしたら今回のこのコンテキストの中に動画があったら使ってるかもしれないんだけど。
FFMPEGのオプションとか細かい設定がマジでクロート向けすぎて、これまで人間が手で使うときにあんまり好まれないモジュールだったらしいんだよね。
そうなんだ。
けど、AIが出たことによってFFMPEGを、AIは別にマニュアル見てやるだけだから、どんなに複雑なロジックでも書けるわけだよね、その中に。
ってなってるから、利用頻度というか人気度合いがめちゃめちゃこの何年かで上がってるみたいな。
あとその代表格がグレップ、FFMPEGみたいなのいっぱいあるんだと思う。
あると思う。
オークとかもコマンドとして全然使ってるし。
そう、今俺も頭の中にあともう1個あったのはオークだった。
そうですよね。
シェルのスクリプトというか、シェルのコマンドが結構使われますよね。
うん、そうだよね。
でもよく考えたら確かにパソコンがわかりやすく処理するためにシェルのコマンド群はあって、それに人間が頑張って順応してあのコマンドを書いてたと思えば。
確かにそれが一番効率いいのかみたいな。
俺らもプログラム書くときグレップとかオークで最初にいろいろ情報を引き抜いてる方が早かったもんね。
早かったですね。めちゃめちゃ使えるツールなんですけど、逆に曖昧な質問とか。
今年一番盛り上がった会社は?みたいなフワッとした訂正的な質問とかもあったりするんですよ。
注目された会社は?とかっていうのを株式関連のデータベースから引っ張ってくるとかになると、注目されたをちゃんといい言葉に置き換えなきゃいけないとか。
そうなってくるとグレップ逆に使えなかったりするんで。
そうするとナレッジベース、ナレッジグラフとかができててとか、あとはナレッジグラフプラス構造化データのバズとかを定量的に出せるものと組み合わせてみたいな。
そうなってくるんですよね。
賢くなったわ今日。
エージェントをうまく動かすためにはこれまで世の中にあるいろんな技術をちゃんとAIが使えるようにツール整備しましょうねとか。
結局そういう話になってきて、最近流行りのハーネスを整えるっていう言葉でまとめちゃうことはできるんですけど。
確かに確かに。
実態としてはそういうこと。
AIが使えるように諸々の武器を準備してあげる作業になってくるかなっていうのと、データをちゃんと加工しましょうねとか。
っていうことをやるのが、これからのAIと付き合っていく人間のやるべきことなのかなと思っていて。
確かに。
さすがにそこまではコンペキストウィンドウが爆発していけるみたいな世界はさすがにないか。
なのかなとか。
賢いAIは確かにできてくるが、それを自由に各企業とかが扱えるかっていうとまたそうじゃなかったりするのかなとも思っていて。
最近とかソブリン製とかっていうのがよく言われてくる気がするんですけど、データの試験とかAIの試験とか、そういうものをビッグテックとか海外の企業に渡すんじゃなくて、自分たちでも当然みたいな考え方。
デブスリーっぽいね。
確かに確かに。
番組の締めとリスナーへの呼びかけ
隣のデータ分析屋さん、今回も面白いと思ったらフォローレビューよろしくお願いします。
番組の感想や質問は、ハッシュタグ隣の分析屋、隣のがひらがなで分析屋を漢字でお願いします。
またガイドラーに貼ってあるお手紙フォームからコメントを寄せてください。
ではまた。
ばいばーい。
