# AIエージェントとLLMの生成AI
みんなのPython勉強会 in 長野 #4
4/26, 2025
辻真吾(www.tsjshg.info)
--- # 自己紹介 - 辻 真吾(つじしんご) - Pythonを使ったデータサイエンスが得意です - 大学の研究所に所属 - 『みんなのPython勉強会』を運営するStart Python Club(stapy)の共同設立者 - Python、データサイエンス、アルゴリズムに関する著書多数 - 近況 - ずっとpandas使ってましたがPolarsに入門し使いやすさと速度に驚愕している - 2年ぶりにRustを書いて、「継承より合成」という設計思想を知り感嘆している - 文章埋め込みモデルE5のfine tuningに手を出しその不思議に魅了されている --- # Start Python Club (stapy) - ほぼ月に1回『みんなのPython勉強会』をおもにzoomで開催 - メイントーク2つLT最大3つの構成 - お気軽にご参加ください - 来月なんと10周年 - 久しぶりのリアル開催(東京)を5月19日(月)19時から予定 - トーク、LT随時募集しております --- # もくじ - AI研究は常にエージェントをめざす - AIエージェントの基本 - AIエージェントに関する3つの研究論文を紹介 - AIエージェントの現状と未来予想 --- # エージェントアプローチ 人工知能(1997年出版)
[共立出版](https://www.kyoritsu-pub.co.jp/book/b10010674.html)から第2版が2008年にでてます -- # エージェントとは?(P31から引用)
-- # 当時のエージェント 1980年代から1990年代に起こった第2次AIブームの研究成果 決定木やニューラルネットワークを使った例も紹介しているものの、基本的にはif-thenルールで動く普通のプログラム -- # いまどきのAIエージェント 学習済みのLLM(Larget Language Model)を使って作られたエージェントに自然文で指示を出し、複雑なタスクを自律して解決してくれることが期待される - 推論(reasoing, 論理的な思考) - 計画(planning) - 実行(tool execution) --- # エージェントの基本 -- # 2024/4に出た調査論文
https://arxiv.org/abs/2404.11584
-- # AIエージェントを使ったシステムの構造
-- # 推論と計画の重要性 - 複雑な問題を正確に捉え、それを解くためには正しい推論が必要(人でも同じこと) - 推論したあとに計画を作る必要がある - さまざまな方法が提案されている(すみません詳しくは知らないです) - external module-aided planning, reflection and refinement, memory-augmented planningなどなど - 1つの例として、計画を有向グラフで表現するPlan Like a Graph(PLaG)を紹介 ---
https://arxiv.org/html/2402.02805v2
-- # カルツォーネ(包み焼きピザ)を作る工程
Step 1. オーブンを220度余熱する(10分)
Step 2. 生地をのばす(10分)
Step 3. 具材を詰める(15分)
Step 4. 形を整える(5分)
Step 5. カルツォーネを焼く(25分)
最短何分でカルツォーネを作れるでしょうか?
--
- タスクを達成するのにかかる最小の時間を答えさせる - 工程を有向グラフで表現して指示と一緒に渡す - PLaG - explicit graphはグラフ構造を隣接リストの構造で明示 - PLaG - BaGは説明の中で隣接リストを明示して、こういう感じのグラフを作ってから計算しようと指示する -- # 結果1
-- # 結果2 隣接リストを明示的に与えるより、説明文の中で紹介して自分でグラフを作らせるBaGの方が若干性能が良い
-- # 結果3
手順が複雑になると急激に性能が低下する -- # 結論
論文の著者自ら「LLMをデジタルデバイスや汎用的なエージェントに仕立てあげられるのか疑問」と言っている。 ---
[https://arxiv.org/abs/2410.10934](https://arxiv.org/abs/2410.10934) -- # 論文の概要 - いまだ定まっていないAgentの評価方法を確立するためにAgent-as-a-Judgeというフレームワークを提案 - DevAIというエージェントにコードを書かせるベンチマークデータセットも作成して公開 - これまでの単純なLLMを使った評価と違い、エージェントを使った仕組みは人の判断と一致率が良い -- # 文字を埋め込んだ絵を作るライブラリ
[https://www.factsmachine.ai/p/hidden-in-plain-sight](https://www.factsmachine.ai/p/hidden-in-plain-sight) -- # タスクの例 - 途中経過も評価できるようなベンチマークデータセットを作る
-- # DevAIデータセット
全部で55問 -- # 参加選手
- 3つともマルチエージェントアーキテクチャ - OpenHandsは内部ではおしゃべりだけど、出力は簡潔 - コストは裏側でChatGPT-4oなどのAPIを呼ぶ料金? -- # 結果1
- 3人の人間による評価 - 55問中1問解くのがやっと - そもそも動作止まる率もそれほど高くない - DevAIのデータセットは難しいのでこれを解けるAIエージェントの出現が待たれる --
- ■は最終結果だけを見て判断、□は内部のやりとりも見て判断(赤字はヒトの判定とのズレ) - LLMを使ったものよりマルチエージェントアーキテクチャの方が優秀(ヒトとのズレが小さい) --- # OpenAIから4/2にでた論文
- 2024年のICML(国際的な機械学習の学会)に投稿された20の論文を選び、AIエージェントに研究を再現してもらう - タスクを分解してそれらの依存関係を木構造で表現したものを人手で作成(rubric) - Rubricのノードごとに評価すれば部分点をあげられる
https://arxiv.org/abs/2504.01848
-- # 論文一覧
Nodesの列は全体を何個の細かなタスクに分割したかを示す -- # 研究の全体像
- 細かなタスクごとに`reproduce.sh`を作らせる - このシェルスクリプトを実行した結果で評価 - [実際のタスクはこちら](https://github.com/openai/preparedness/blob/main/project/paperbench/data/papers/all-in-one/rubric.json) -- # プロンプトの例
これに加えてタスクごとのプロンプトなどを用意 -- # Rubric(指示書)と判定方法
・各タスクの依存関係を木構造(グラフの一種)で表現
・各ノードごとに0/1を判定
・タスクに重みを付けてスコアの合計を上(根)へ伝搬
・根に割当たる数値を最終的な再現率とする
・タスクごとの判定は判定AIエージェントにやってもらう(F1スコア83%)
-- # 結果1
- OpenAIからの論文なのに、まさかのANTHROPIC製CLAUDEが1番 -- # ルール変更 - モデルはEND_TASKという状態をとれる - CLAUDE以外のモデルは制限時間(12時間)を大きく残して終了してしまう - END_TASKを禁止するルール変更 -- # o1が一番!
- きちんとEND_TASK状態を選択していたCLAUDEの性能が大幅に低下 - 制限時間を延ばしても性能が上がらない -- # ヒトとの比較
- AIは最初の1時間で最高性能に到達し以後ほとんど改善しない - ヒトは立ち上がりは遅いが理解が進むと仕事が一気に加速する - AIとヒトがどう協力すべきかの参考になる結果 --- # AIエージェントの現状 - 順番を指示してもステップ数が増えると崩壊するので理路整然としたタスクの遂行はいまのところ無理そう - 短時間で大雑把にタスクをこなすのは得意 - 細かなタスクの判定にも使えそう -- # AIエージェントはどこまで進化するか? - LLM(大規模言語モデル)の生成AIはそれっぽいことを言うことが基本機能 - プロンプトでかなり動作を制御できるのは事実 - さらなる進化には理路整然と考えることを可能にする必要がある - ここで技術革新が起きるかどうか -- # 第4次AIブームへの展望 - 現在のAIは膨大な量の情報を素早く処理するのが得意 - ヒトの指示のもと、情報を検索、集約させるというタスクに使うのが良さそう - 個人的にはAGIは量子コンピュータの実用化と同じくらいの時期ではないかと思っている --- ご清聴ありがとうございました🙇♂️