AIエージェントが動かないときの原因とその対処

Transcript

1. AIエージェントが動かない ときの原因とその対処 ojisans解散ライブ#1 sadnessOjisan
2. AIエージェントフレームワーク利用者 向けの内容です
3. AIエージェントとは • 人工知能 (AI) エージェントは、環境と対話し、データを収集し、そのデータ を使用して自己決定タスクを実行して、事前に決められた目標を達成するた めのソフトウェアプログラムです。(※1) • 色々あるけど、ChatUIでタスクを依頼するようなやつはAIエージェント ※1: https://aws.amazon.com/jp/what-is/ai-agents/
4. AIエージェントの構成の１例 LLM tool memory workflow engine prompt タスクのstepで 何回も呼び出す step を LLM に作ら せることで自律性も 持たせられる
5. 開発者が出会う問題 LLM tool memory workflow engine prompt 結果が返ってこない 原因はどこ？
6. AIエージェントフレームワークの裏側を覗こう • AIエージェントを開発するために、LLMのAPIやSDKやフレームワークが提 供されている • OpenAI API: GPT を API 越しに利用できる • AI SDK(vercel): GPT や Gemini など複数のモデルをラップしたもの。SDK なので tool calling もできる • Mastra: AI SDK を組み込んだフレームワーク。ワークフローエンジン、 RAG、Context Memoryといった機能が簡単に使える
7. Mastra でエージェントを作った場合の構成 workflow nested workflow nested workflow nested workflow step step step Memory LLM tool Agent
8. Mastra でエージェントを作った場合の構成 workflow nested workflow nested workflow nested workflow step step step Memory LLM tool Agent 今日の気温は何度で すか？というプロン プトを受け取る 不正なプロンプトか どうか検査する 受け取ったプロンプ トを実行する 質問履歴からユー ザーの居住地を推論 する 天気APIにアクセスする コア。回答の生成、利 用するツールの推論な どを担う
11. Mastra でエージェントを作った場合の構成 workflow nested workflow nested workflow nested workflow step step step Memory LLM tool Agent 動きませんでし た！！！ 原因どこ！！！
12. AIエージェントフレームワークの実装を知る • Mastra を例に挙げる • Workflowエンジンとしては、基本的にはWorkflow や Step を配列で保持 し、逐次・並行に実行するだけ • Agentとしての機能は Vercel AI SDK を利用する
13. Vercel AI SDKの実装を知る • 多種多様な Model Provider を持つ • それぞれは共通の Class を継承しており、LLMの呼び出しは基本的にはどれ もそのモデルが提供している API を呼び出しているだけ • ただ、プロンプトの効率化、Tool呼び出しとその結果の反映を実現するため に、プロンプトがLLMを通して step に分解され、step ごとにタスクをこな していく
14. 最後は Web 標準 • LLM との通信は結局 fetch が使われており、HTTP や Web 標準の上で行わ れる • vercel/ai-sdk は Abort Signal が利用でき、Mastra 側からも渡せる。ワー クフローで実行したタイムアウトを tool に伝えられる。 • ストリーミングは SSE で行われる
15. Agent が進まない時はいつか workflow nested workflow nested workflow nested workflow step step step Memory LLM tool Agent • 無限ループ • エラーハンドリング不備 • 不要なリトライ 単純にタスクが多い 通信のコネクション不備
16. 無限ループ / 中断されたループ • 当たり前 • なんだけど、Mastra だとワークフローでもループを組めるので、うっかり ループがある • Human In the Loop の実装をミスった場合
17. 通信のコネクション不備 • SSEすると長時間接続する都合上、外的要因でコネクションが切られる可能 性はどうしてもある • イベント例として、通信相手のリソース枯渇、コネクション枯渇、再起動
18. リソース枯渇 • メモリやCPUを使い切る。当たり前 • と思いきや、環境によってはHTTPコネクション数にも気を払う必要もある ◦ 例えば CloudRun にはコネクション数上限がある ◦ LLMとの通信は時間がかかるのでコネクションを使い果たしやすい • SSE中にワークロードのリソースが枯渇すると停止したように見える • TIPS: Mastra使う場合は storage への trace 書き出しはやめた方が良い。メ モリとCPUがすごく逼迫する（最新版だと治ってるかも？
19. Unhandled Rejection • 普通は try-catch でコントロールするでしょ？と思いきや、AIエージェント 開発では貫通が発生しやすい事情がある • Mastraの場合、try-catch をかけるのはユーザーコードを書ける step の exectute の中くらい。その外側で発生したエラーを catch で救えない。 • コネクション数を使い果たすと、予期せぬところ、タイミングでEPIPE や ECCONRESET が発生する • Unhandled Rejection が貫通すると Agent そのものがダウンする。クライア ントの実装次第では、このときエラーではなく処理が止まったように見える ことがある
20. ネットワークの問題 • AIエージェントは外部のLLMやTool呼び出しで、インターネット越しに通信 を行う • 通信自体が途切れたり、レイテンシーが大きくなると、それに引きずられて 全体が遅くなる
21. タイムアウトとリトライに気を使うと、 解決できそう？
22. フレームワークやSDKのリトライに甘えない • Mastra の場合、retry config がワークフローにある • 指数バックオフできないのでオススメしない • retry は冪等であるべきだが、ワークフローを冪等にすることって可能です か？ ◦ Agent 呼び出し: 呼び出し自体は冪等 ◦ 永続化: 外的環境に影響あり ◦ ロギング: 外的環境に影響あり
23. 冪等な Retry • retry させたいものだけを retry させる仕組みが必要 ◦ retry させたいものを関数でラップするだけでOKみたいなIFだと使いまわしやすい • 指数バックオフやランダマイズなども欲しい ◦ ランダマイズしないと、スパイク起因のエラーをリトライさせると、同じタイミングでスパ イクするのでエラーが出続ける • そういうOSSがあるのでそれ使おう(vercel/async-retryなど)
24. タイムアウトを実装する • LLMの呼び出しは、SDKにタイムアウトの機能があるのでそれを使えば良さ そう • 一方で Context Memory, RAG, Tool 呼び出しのような非同期処理のタイム アウトは自前で用意する必要がある • ライブラリを使ってもいいが、簡単に Promise.race と setTimeout を組み 合わせたヘルパーを用意しておけば良いと思う • Mastra の場合、グローバルで設定できる機能もあるが、数値はグローバル で決まるものではないので使わない方が良い
25. エラーハンドリングを確実に行う • AIエージェントは普通のWeb開発と比べて、例外が起きやすいと思ってい る。例外が突き抜けないようにする。try catch 大事 • process.on をグローバルに置く防護層が必要になることも ◦ 例えば Mastra の場合、workflow の外に try catch が書けない ◦ クラウドの都合によっては EPIPE や ECONNRESET が起き、それが貫通することがある
26. 例外は投げない方が良いと思う • ワークフローを作る場合、その都度エラーをロギングしたり永続化するの は、リトライの都合上やらない方が良さそう • なのでワークフローから例外を投げるのではなく Result 型のようなものを 返して、ワークフローの最後のステップでまとめて異常系の永続化をする と、気軽なリトライができる
27. まとめ
28. • AIエージェントは 1つのコネクションが長くなりがち • 普通のWebサービスに比べるとリソースが枯渇がしやすい • 意図しない通信の切断があるのが特徴かもしれない • その結果、UIからはエージェントがタスク中に停止したように見える • エラー時のリトライ、非同期処理に対するタイムアウトを実装する