Weekly AI Agents News! - Speaker Deck

Slide 1

Slide 1 text

Weekly AI Agents News @ottamm_190

Slide 2

Slide 2 text

最終回 • １年間ありがとうございました。多くの方に読んで頂けて光栄です。 • LLMを使い倒す側面でAIエージェントの発信を続けてきました。 • 今ではどの企業もエージェントを取り組むようになったのではないでしょうか。 • まだの方は、今からでもエージェント技術が社会課題の解決策になるか検証してみませんか。 • これからもエージェントを中心とした基礎技術がより一層重要になると思います。 • 資料を読み続けた方は、界隈の潮流がわかったと思います。 • ちょうど一年というタイミングで一度、発信を止めて別のことに注力しようと思います。 • これからも先端技術で社会に役立ちそうな技術があればレポートを定期的に作る予定です。 • お楽しみに。

Slide 11

Slide 11 text

LLMsのライティング能力を評価するための包括的なベンチマークの提案 WritingBench: A Comprehensive Benchmark for Generative Writing WritingBench • ６つのドメイン（学術・エンジニアリング、金融・ビジネス、政治・法律、文学・芸術、教育、広告・マーケティング） • 創造的・説得的・情報的・技術的な執筆タスクを網羅 • ファインチューニングされた批評モデルを活用し、スタイル、フォーマット、長さなどの指標で評価実験結果 • GPT-4o、Claude-3.5-Sonnet、Gemini-1.5-ProなどのLLMsを評価した結果、DeepSeek-R1 が最も高いスコアを記録 • 教育、学術・エンジニアリング分野のタスクで性能が比較的高く、文学・芸術の分野ではばらつきが大きかった傾向 • ほとんどのLLMが 3,000トークンを超えると品質が低下 • Deepseek-R1 でも 5,000トークン以上で性能が低下 • 多くのモデルはオリジナリティに欠けた無難な表現を多用しがち • Deepseek-R1 や 3.5-Sonnet は比較的創造的な表現ができたライティングタスク主な評価指標学術・エンジニアリング論文要約、研究提案、実験レポート、特許文書 1. 論理的整合性 2. 学術的適切性 3. 引用の適正性 4. 専門用語の正確性 5. データの正確性金融・ビジネス市場調査、投資分析、営業レポート、契約書作成 1. 財務分析の正確性 2. 市場動向の洞察力 3. リスク評価の適切性 4. 戦略的思考力 5. ビジネス文書の明瞭性政治・法律政策文書、法的意見書、判決文、規制分析 1. 法的適合性 2. 政策分析の深さ 3. 証拠の適用 4. 議論の説得力 5. 形式的要件の遵守文学・芸術小説プロット、脚本、詩作、キャラクターデザイン 1. 創造性 2. 物語構造の整合性 3. キャラクターの発展 4. 情緒的影響 5. 文体の表現力教育授業計画、学習教材、試験問題、入学広報 1. 教育的有効性 2. 学習者の理解度 3. 構造の明確性 4. インタラクティブ性 5. 評価基準の適切性広告・マーケティング SNS投稿、スローガン作成、プロモーション記事、ブランドストーリー 1. ブランドメッセージの明確性 2. ターゲットオーディエンスの適合性 3. コピーの魅力 4. SEO最適化 5. コンバージョン効果 3月24日更新分評価

Slide 46

Slide 46 text

推論の長さと推論の深さのどちらが精度向上に寄与するのか The Relationship Between Reasoning and Performance in Large Language Models -- o3 (mini) Thinks Harder, Not Longer OpenAIのo1-mini, o3-mini (m), o3-mini (h) という異なるモデルを比較し、推論トークンの使用量と精度の関係を体系的に分析するより優れたモデルは、長い推論チェーンを必要とするのか、それともより効果的に推論を行うのかを検証する推論トークン数の増加は必ずしも精度向上をもたらさない • o3-mini (m) は o1-mini より高い精度を達成しているが、推論トークン数は増えていない → 効率的な推論を実行 • o3-mini (h) は o3-mini (m) より約４%向上したが、推論トークンを2倍以上使用 → 計算コストが増大推論チェーンが長くなるほど精度は低下 • 全てのモデルで推論トークン数が増えるほど精度が低下 • しかし、この影響はo3-mini (m) や o3-mini (h) のような高性能モデルでは小さい数学領域ごとの特徴 • 離散数学の問題では推論トークンの消費が多い • 微積分や代数学の問題は比較的少ない推論トークンで解答可能 • 難易度が高い問題ほど推論トークン数が増加より優れたモデルは「深く考える」が「長く考えない」 • o3-mini (m) は、より少ないトークン数でより正確な回答を生成 • o3-mini (h) は、より多くのトークンを使用することで精度をわずかに向上 • モデルが賢くなるにつれ、「長く推論する」よりも「効率的に推論する」ことが精度向上の要因となる LLM の最適化には「単純に推論チェーンを長くする」のではなく、「推論の質を向上させる」ことが重要推論 3月10日更新分

Slide 53

Slide 53 text

プロンプト最適化手法のサーベイ Automatic Prompt Optimization via Heuristic Search: A Survey 1. どの空間で最適化をするか 1. ソフトプロンプト空間：プロンプトをベクトルの形で扱い、勾配に基づいて最適化する 2. 離散プロンプト空間：プロンプトをそのままテキスト列として扱い、置換や追加・削除などのテキスト操作で最適化する 2. 何を最適化するか 1. Instruction-only：指示文（タスクの説明部分）のみを最適化 2. Instruction & Example：指示文に加え、いくつかの入出力例（Few-Shotの例示）の最適な組み合わせまで含めて同時に最適化 3. Instruction & Optional Example：必要に応じて例示を加える/加えないも含めて最適化 3. どういう指標を最大化/最小化するか 1. タスク性能（精度、再現率、F値など） 2. 安全性・倫理性（有害出力や差別表現の回避） 3. 汎化性能、マルチ目的最適化（性能と安全性を同時に高めるなど） 4. どのような手法でプロンプトを修正するか 1. Zero-Parent（親なし）：LLM自体やベイズ的アプローチなどを活用して、まったく新しい候補プロンプトを生成する 2. Single-Parent（親1つ）：既存の1つのプロンプト候補をもとに、LLMで言い回しを変える、特定の単語を置換・追加などして新候補を作る 3. Multiple-Parent（親複数）：2つ以上の既存プロンプトを組み合わせたり、差分を取ったり、交叉する 5. 探索アルゴリズムは何を使うか 1. バンディットアルゴリズム：候補群の中から「最も良いかもしれない」ものを選びつつ、未知の候補も少し試して最適化する 2. ビームサーチ：多くの候補を同時に保持しながら、性能が低い候補を段階的に絞る 3. モンテカルロ探索：ランダムサンプリングやMCTSで試行錯誤しながら有望なプロンプトを洗練 4. メタヒューリスティクス：進化的アルゴリズム、シミュレーテッドアニーリング、Hill Climbingなど 5. 逐次改善（Iterative Refinement）：勾配下降など連続的最適化を行う自己進化 3月10日更新分

Slide 64

Slide 64 text

CLINEに全部賭けろ Cline とは何か • Cline は「コーディングエージェント」のことを指し、Devin / Cursor / Copilot Agent などの AI コーディングツールを含む。 • 従来の AI コーディング支援ツールと異なり、Cline は自律的にコードを生成・実行し、圧倒的な速さで開発を進める。 AI とプログラミングの変化 • AI がプログラムの実装を支援する段階を超え、プログラマと同じ土俵に立った • Cline は環境情報を取得し、試行錯誤のスピードを人間の何倍にも高める • AI のコーディング能力は情報量によって大きく左右され、Cline はこの情報不足を解消することで AI の性能を最大化する Cline の活用と実績 • Cline を用いると、例えば 15 分で 700 行のコードをテスト込みで完成させることが可能 • AI が得意なタスク（数学的処理、アルゴリズム、明確な仕様のある実装）は圧倒的に速い • ただし、複雑な文脈理解や長期的なコンテキスト保持はまだ苦手プログラマに求められる新しいスキル 1. コンテキストの記述能力 - AI に適切な情報を提供する力 2. ドメイン知識の整理能力 - プログラムをどう構造化するかの判断力 3. AI の特性を理解する直感 - 何を AI に任せ、何を人間が補うべきかの見極めプログラマ不要論への反論 • AI により「コードを書く作業」は簡単になったが、プログラミングの本質である「抽象化し、適切な構造を考える」というスキルは不可欠 • AI の性能は「使う人間のスキル」に依存し、高度な AI を扱うには相応の知識が求められる • AI の登場によってプログラマが不要になるのではなく、より高度な役割へ進化するだけなぜ Cline は「パンドラの箱」なのか • Cline は環境情報を吸い上げるため、コマンドを自由に実行しようとするためセキュリティリスクが極めて高い • 許可リスト（Auto Approver）があるものの、人間の判断がボトルネックになり、次第に制約が緩くなっていく • 企業のセキュリティ担当者にとっては悪夢のようなツールになり得る https://zenn.dev/mizchi/articles/all-in-on-cline

Slide 68

Slide 68 text

AIエージェントを開発するために注力すべきポイント実際の開発から得た3つの知見 1. AIエージェントに「何を」任せるべきか？ • AIエージェントは「目的を達成するための手段」であり、導入の意義を明確にすることが重要 • 例えば、大量の問い合わせ対応や定型文書の作成はAI向きだが、既存システムとの整合性を考慮しないと業務の煩雑化を招く • 現場の業務フローを整理し、エキスパートの知見を取り入れながら、AIを適切な範囲で活用すべき 2. AIエージェントに「どこまで」任せるべきか？ • AIにすべての判断を任せるとトラブルを招き、人間がすべてをチェックすると自動化の効果が薄れるため、「判断の幅」と「安全設計の明確化」が必要 • 判断の幅: 何を基準にAIが判定するかを定義することで、不適切な出力を防ぐ（例: 採用AIのスカウトメールの適切な送信設計） • 安全設計:不要なデータを持たせない。ルールベースの仕組みと組み合わせ、誤作動時にはシステムを停止するなどの対応策を用意 3. AIエージェントを「どう」運用すべきか？ • LLMを活用したAIエージェントは、リリース後も運用しながら最適化することが重要 • ユーザーフィードバックや利用データをもとにプロンプトやパラメータを調整し、回答精度を向上させる • 理想は、人間の手を最小限に抑えながらAIが自動的に学習し、運用改善できる仕組みを作ること結論 • 何を任せるか: 目的を明確化し、業務フロー全体を整理 • どこまで任せるか: AIの判断範囲を明確にし、安全設計を整備 • どう運用するか: データを活用し継続的に改善、最終的にはAIの自律学習を目指す AIエージェント開発は試行錯誤の連続だが、適切な設計と運用によって生産性向上と業務変革の可能性を秘めている。小規模なトライアルから始め、段階的に発展させるのが望ましい。 https://forest.watch.impress.co.jp/docs/serial/aidev/1662583.html

Slide 70

Slide 70 text

OpenAI’s Deep Research Team on Why Reinforcement Learning is the Future for AI Agents 背景と開発経緯 • Deep Researchはより長い推論や多段階のタスクをこなす必要があるため、E2Eの強化学習（RL）で最適化されている • 既存のフローを人間が細かくプログラミングするのではなく、モデル自体が試行錯誤しながら検索や分析の手順を学習することで、柔軟かつ高性能なエージェントを実現した主な特徴・使い方 1. 包括的レポート作成 1. 5分から30分ほど時間をかけ、複数のウェブサイトやソースを横断的に検索・整理し、詳細なレポートを生成する 2. レポートには引用元（URLなど）を明示するため、利用者が情報源を検証しやすい 2. 柔軟な検索戦略・タスク処理 1. 従来の単純なプロンプト＋応答型とは違い、初期段階でユーザーから追加の条件や意図を引き出す（Clarification）機能を備え、最適な検索計画を立てる 2. 途中で得られる検索結果に応じて、探索方針を動的に変更する柔軟性がある 3. 多様なユースケース 1. コンサル的な市場リサーチ・企業分析・プログラミング関連情報収集 2. 旅行計画・高額商品の比較・教育・医療論文探索技術的ポイント o3モデルのファインチューニング • Deep Research はWeb検索とPython実行などの外部ツール操作を組み込んだタスクで特化学習している高品質データセットの重要性 • 大規模かつ質の高い学習データセットを整備・最適化したエージェント型の今後 • 複数のツール・データソースをまたいで総合的に推論するエージェントの開発は、今後さらに進む見込み https://www.youtube.com/watch?v=bNEvJYzoa8A&t=1s

Slide 72

Slide 72 text

AI Engineer Summit 2025: Day 1/OpenAI: Building Agents the Right Way OpenAIが「エージェント」を正しく構築する際のポイントを解説した。エージェントとは、LLMとツールへのアクセス機能を組み合わせ、外部システムとの連携や複数回の推論を自律的に行えるAIアプリケーションを指す。抽象化は最小限にとどめるいきなりフレームワークを導入しすぎるとシステム全体の挙動が不透明になり、問題が起きたときに原因追及や最適化が難しくなる。最初はより低レベルのAPIやコードで直接やりとりし、失敗パターンやボトルネックを把握してから抽象化を行うのが望ましい。まずはシンプルな単体エージェントから始める複雑なマルチエージェント構成に最初から飛び込むと、失敗の原因やユーザニーズを把握しづらい。単一タスクに特化したエージェントをまず動かして、実際のユーザからのフィードバックを得ることで、どの部分を強化すべきか優先度を定められる。複雑化が必要なら複数エージェント連携（ネットワーク）へ拡張大きなタスクを複数のエージェントで分担し、「ハンドオフ」という仕組みで会話コンテキストごと別のエージェントに引き継ぐ。これにより各エージェントが得意分野を担当しながら、ユーザとの対話は一貫性を保てる。プロンプトはシンプルに、ガードレールは並行実行で扱う本来のタスク指示に過剰な安全策や制約を詰め込みすぎず、リスクが高い操作や内容だけ別途ガードレールを適用する。これにより、タスク遂行時の柔軟性と安全性のバランスを取りやすくなる。総じて、「まずは小規模・単機能なエージェントを試験的に導入し、失敗ポイントやユーザニーズを明確化したうえで段階的に発展させること」が推奨されており、安全性と信頼性を担保しつつ、エージェントをより複雑なタスクへ拡張していくアプローチが示されています。 https://www.youtube.com/live/L89GzWEILkM

Slide 73

Slide 73 text

AI Engineer Summit 2025: Day 1/ Missing Pieces of Workflow Automation 背景と導入 • AIを活用したエンタープライズのワークフロー自動化の現状を解説 • 2023年にはGenAIの活用が一般企業にも浸透 • 2024年にはRAGやエージェント技術が主流となり、ワークフロー全体の自動化が進んでいるワークフロー自動化の具体例 • カスタマーサポート問い合わせ → RAGを活用した回答 → チケット発行 → IT運用チーム → エンジニアリング部門 → 問題解決 • コンテンツ制作トリガー検知 → 承認 → 調査・執筆 → 編集・レビュー → 出版ワークフロー自動化の課題以下の要素が欠けており、本格的なワークフロー再設計を妨げている。 1. コネクターの不足: 既存のITシステムとエージェント技術を統合する仕組みが未成熟 2. ROIと信頼性: ビジネスインパクトが明確でないと投資が進まない 3. ビジョナリーの不足: 業界専門家とAI技術者の連携が不足 4. 標準化の欠如: エージェントの構築・導入・展開の統一基準がない 5. データとシステムの統合不足: エージェントが十分なコンテキストを取得できない 6. 協調的UXの設計不足: AIエージェントと人間の適切な役割分担が未確立 7. AIガバナンスの確立: セキュリティや倫理的問題への対応が不十分 8. 制御のバランス: 人間とエージェントの意思決定範囲を最適化する必要 9. エージェントのライフサイクル管理: 技術進化に応じたエージェントの更新が課題結論 • ワークフローの単純な自動化ではなく、AI技術を活かした「ワークフローの再設計」が求められる。 • これらの欠落部分を埋めることで、AIエージェントをより効果的に導入できる。 https://www.youtube.com/live/L89GzWEILkM

Slide 76

Slide 76 text

AI Engineer Summit 2025: Day 2/ Swyx「Why Agent Engineering」 1. 確立されたユースケースこれまでのエージェント技術の中で、PMFが確認され、実際に多くの企業が導入しているユースケース ① コーディングエージェント：GitHub Copilot、Code Interpreter、AIペアプログラマー価値：開発スピードの向上、バグの削減、エンジニアの生産性向上 ② カスタマーサポートエージェント: ChatGPT Enterprise、Intercom AI: 顧客サポート対応の自動化、Zendesk AI: FAQや問い合わせの自動対応価値：サポートコスト削減、24時間対応の実現、ユーザー満足度向上 ③ Deep Research エージェント：Elicit: 論文の要約やデータ抽出、Perplexity AI: リサーチの補助、Semantic Scholar: 論文検索の強化価値：研究スピードの加速。膨大なデータの効率的な分析。 2. 成長中のユースケース現在、急速に進化しており、今後の展開が期待されるユースケース ① エージェント＋RAG：企業向けFAQボット、法務・財務エージェント価値：リアルタイムデータを活用した応答、情報の正確性向上 ② エージェント＋検索：Eコマースエージェント: 価格比較、最適な商品の推薦価値：検索時間の削減、ユーザーに最適な情報の提供 ③ エージェント＋センシング：スマートファクトリーエージェント: 機械の動作監視、メンテナンス予測、ヘルスケアモニタリングエージェント価値：リアルタイムな意思決定、人間の介入なしでの自動処理 ④ マルチエージェントシステム：エンタープライズAIオペレーション: 営業、マーケティング、財務エージェントが連携、自律走行車: 価値：より複雑なタスクの自動化、エージェント同士の最適化 3. 不要とされるユースケース（アンチユースケース）エージェントのユースケースとして繰り返し登場するが、実際にはあまり需要がない、または効果が限定的なもの ① フライト予約エージェント既存の予約システムが十分に最適化されている。ユーザーが手動で選択したい傾向がある。 ② Instacart注文エージェント食材選びは個人の好みに依存し、完全な自動化が難しい。間違った注文が発生すると顧客体験が悪化。 ③ TED Talks検索エージェントそもそもユーザーはTED Talksを探すことに強いニーズを持っていない。通常の検索で十分。 https://www.youtube.com/watch?v=D7BzTxVVMuw

Slide 79

Slide 79 text

AI Engineer Summit 2025: Day 2/ Bloomberg: Challenges to Scaling Agents for Generative AI Products AI 製品のスケーリングの課題 • Bloombergにおける AI製品のスケーリングには、技術的・組織的な課題が多数存在 (1) エージェントの信頼性と精度の確保 AIエージェントの回答が一貫性を欠く・事実と異なる・文脈を誤解するなどの問題が発生する例：「米国の過去 5 四半期の CPI（消費者物価指数）」を取得する際、間違えて月次データを取得する (2) LLMのエラー累積問題 LLMを用いたエージェントは、複数のモデルが連携することでエラーが連鎖的に増幅するリスクがある。例：「決算発表の自動要約」 → 「要約の分析」 → 「投資判断レポート生成」のように、複数のステップを AI が処理する場合、最初のステップのエラーが後のステップに伝播し、大きな誤りとなる (3) モデルのアップデートと互換性維持モデルアップデートのたびにエージェントの挙動が変わり、下流システムが予期しない影響を受ける例：LLMが新バージョンになった際、リサーチエージェントの挙動が変化し、データの解釈が変わる (4) AIエージェントの拡張性と開発スピードの両立初期では単一エージェントで済むが、スケールするにつれてエージェントの数が増え、管理が複雑になる。例：リサーチエージェントが、金融業界の特定分野（AI・半導体・EV など）ごとに異なる専門知識を持つ必要がある。 (5) AIのコストとパフォーマンスの最適化 LLM の推論コストが高く、スケールするほど運用コストが増大する。例：AI を用いた決算発表の要約生成に高額な GPU リソースが必要。 https://www.youtube.com/watch?v=D7BzTxVVMuw

Slide 80

Slide 80 text

AI Engineer Summit 2025: Day 2/ Brightwave: Knowledge Agents for Finance Workflows ナレッジエージェントとは、膨大な金融データを収集・分析し、迅速な意思決定を支援するAIエージェントのことを指す金融の課題投資銀行・プライベートエクイティ（PE）のアナリスト・アソシエイト 1. M&Aや投資案件の事前調査において、数千ページに及ぶ資料を短期間で分析する必要がある。 2. 競争的な取引では、他のチームよりも早く、リスク要因や資産の価値を評価しなければならない。 3. ジュニアアナリストは膨大なデータ処理を短期間で求められるため、人的負担が非常に大きい。 4. 企業買収の際、投資対象企業の財務データ、契約書、訴訟情報を短期間でリスク含めて分析する。ミューチュアルファンドやヘッジファンドのアナリスト 1. 決算期には、数十〜百以上の企業の財務報告・決算発表・通話記録を分析する必要がある。 2. 株式リサーチや業界分析を行う際、個別企業レベルの分析と、業界全体の動向を同時に把握する必要がある。 3. 企業の発表やニュースの情報を見逃さず、迅速に投資判断を下すことが求められる。 4. 企業の決算発表やアナリストコールの内容を自動で要約し、比較分析する機関投資家（アセットマネージャー、ファンドマネージャー） 1. 既存のポートフォリオにおいて、リスク管理や投資判断のために、複数の情報ソースを統合的に分析する必要がある。 2. ベンダー契約の内容（例：早期解約条項など）を詳細にチェックする必要があるが、契約書は膨大な量になる。 3. 市場の変化をいち早く察知し、リスクを最小限に抑えるためのリアルタイムな情報分析が求められる。 4. 保有資産のリスク分析、契約書のクロスチェックする企業の財務・戦略部門（コーポレートファイナンス・IR担当者） 1. 競合M&Aや資金調達の際企業や市場環境の動向を分析し、自社の戦略に反映させる必要がある。 2. M&Aや資金調達の際、デューデリジェンスを短期間で完了させる必要がある。 3. 競合企業の財務戦略を分析し、市場ポジショニングの決定をサポート、資金調達の際の投資家向けピッチ資料の作成支援する最適なUI/UX設計 • 「AIが10,000ページを読んだ後の思考プロセス」をどう可視化するかが設計上の課題 • ただのチャット形式ではなく、インタラクティブなUIが必要 https://www.youtube.com/watch?v=D7BzTxVVMuw

Slide 81

Slide 81 text

AI Engineer Summit 2025: Day 2/ Ramp: AI Agents: the Bitter Lesson Bitter Lesson（苦い教訓）とは？ • Bitter Lessonとは、AI研究者 Rich Sutton が2019年に発表したエッセイの中で提唱した概念 • 計算リソースの増加と学習によって向上するシステムが、手作業で設計されたシステムを最終的に打ち負かすというもの結論計算リソースにスケールするシステムを構築せよ • 「賢いアルゴリズムの設計」よりも、「より多くの計算リソースを活用できるシンプルなシステム」を構築する方が、長期的に見て有効。 • AIはルールベースのシステムではなく、学習ベースのアプローチで進化していく。研究者のエゴを捨てる • 「私たちは高度な知的システムを設計できる」というエンジニアのプライドは捨てるべき • 「機械に学習させる方が結局強い」という現実を受け入れることが重要今後のAIの方向性 • AIはより大規模なデータセットと強力な計算リソースを活用する方向に進んでいく • 例：OpenAIのGPTシリーズやDeepMindのGatoなど、汎用的なAIが計算リソースを活用してスケールすることでより強力になっている AIエージェント設計のポイント 1. ルールベースの設計は最小限にする • AIエージェントの行動を詳細にプログラムするのではなく、「自己学習できるシンプルなフレームワーク」を構築すべき 2. 計算リソースを活用する • より大規模なモデル、より多くのデータ、より強力な計算環境（GPU、TPU）を活用することで、AIの性能を向上させる 3. 手作業のコードは削減し、学習に依存する • 「多くのコードを書く」のではなく、「AIにコードを書かせる」方向へシフト • 例：プログラムを書くAI（Codex）や、バックエンドをAIが担当するアーキテクチャ（AIがデータベースを直接操作する） https://www.youtube.com/watch?v=D7BzTxVVMuw

Slide 90

Slide 90 text

エピソード記憶をどのように効果的に実装し、統合するか Position: Episodic Memory is the Missing Piece for Long-Term LLM Agents LLMエージェントが「長期的な記憶を持ち、過去の情報を適切に活用できる」ようになるにはどうあるべきか？以下の能力を全て備えることが必要 • 長期記憶（Long-term Storage）継続的な対話や長期間のタスクにおいて、過去の経験を記憶し続ける能力 • 明示的推論（Explicit Reasoning）記憶を意識的に検索し、それを用いて推論できる能力 • シングルショット学習（Single-shot Learning）一度の経験から新しい知識を学習できる能力 • 個別事象の記憶（Instance-specific Memories）具体的なイベントを詳細に保存し、再利用できる能力 • コンテキスト記憶（Contextualized Memories）いつ、どこで、なぜ特定のイベントが起こったのかを記憶し、それを適切に関連付ける能力現在のアプローチと課題インコンテキストメモリ • KVキャッシュ圧縮や長いシーケンスの処理能力向上が進められている • ただし、メモリのサイズには依然として制約があり、長期的な記憶保持は困難外部メモリ • RAGやGraphRAGなどの手法が開発されている • しかし、エピソード記憶に必要な「文脈情報の関連付け」が不足しているパラメトリックメモリ • 微調整や知識編集によって、モデルの内部パラメータを変更する手法 • ただし、個別のイベントを記憶し、適切な文脈で活用する能力は限定的 2月24日更新分メモリ研究ロードマップ • エピソードの保存方法 • 連続する入力データのエピソード単位の分割方法 • 過去のエピソードの検索と再利用性 • 検索の最適化 • エピソードをパラメトリックメモリへ統合する方法 • エピソード記憶を評価する方法

Slide 95

Slide 95 text

システムがエージェンシーを持つかどうかは参照フレームが不可欠 Agency Is Frame-Dependent エージェンシーの概念が観測者のフレームに依存することを哲学的・強化学習の観点から論じるフレーム依存的だとエージェントの定義が観測者依存になる以下の4つのエージェンシーの基本要素すべてがフレーム依存的である 1. 個体性（Individuality） • システムがエージェントであるためには、まず環境から独立した個体である必要がある。しかし、その境界をどこに設定するかは恣意的である。例えば、強化学習エージェントにおいて、ニューラルネットワーク全体をエージェントとみなすのか、それとも特定の層のみをエージェントとみなすのかは観測者の選択に依存する。→ 個体性はフレーム依存的である。 2. 行動の源泉（Source of Action） • システムがエージェンシーを持つためには、その行動の原因がシステム自体にある必要がある。しかし、因果関係をどのように定義するかによって、行動の源泉をどこに求めるかが変わる。例えば、壁が鉄球によって倒れる場合、壁が「行動した」と言えるかどうかは因果モデルの設定次第である。→ 行動の源泉はフレーム依存的である。 3. 目標指向性（Normativity） • エージェンシーには目標を持ち、それに基づいて行動を調整する能力が求められる。しかし、すべての入力-出力システムは「目標を持つ」と解釈することが可能である。例えば、壊れたサーモスタットが常に室温を20℃に設定する場合、その「目標」は20℃に保つことだとみなすことができる。このように、目標の有無を判断するには、外部からの追加の原則が必要となる。→ 目標指向性はフレーム依存的である。 4. 適応性（Adaptivity） • エージェンシーは、環境の変化に応じて適応する能力を含む。しかし、「適応的である」と判断する基準は、参照する枠組みによって異なる。例えば、あるポリシー（方策）が変化することを適応とみなすかどうかは、選択する基準次第である。→ 適応性はフレーム依存的である。 2月24日更新分 Agent Framework

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text