Slide 1

Slide 1 text

AI長期記憶システム構築のための LLMマルチエージェントの取り組み 株式会社Awarefy 取締役CTO 池内 孝啓 @iktakahiro 2024年11月6日(水) #pharmax_tech_collabo

Slide 2

Slide 2 text

今回お話しすること アウェアファイのAIに搭載した「長期記憶」取り組みを、 「マルチエージェント」という軸で紹介します。 #AI長期記憶 #LLMマルチエージェント #フローエンジニアリング

Slide 3

Slide 3 text

池内 孝啓 ITベンチャー数社を経て、2011年3月に株式会社ALBERTへ入社。 2015年に執行役員として東証マザーズへのIPOを経験。 Takahiro Ikeuchi 取締役CTO 2019年より現職。AIメンタルパートナー「アウェアファイ」の開 発・事業責任者として、2020年5月にプロダクトをローンチ。2023 年4月、 「アウェアファイAI構想」を立ち上げ。 @iktakahiro

Slide 4

Slide 4 text

アウェアファイについて 01

Slide 5

Slide 5 text

心の領域 AI は、 × の スタートアップです。

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

アウェアファイのAIを支える技術 AI x 心の専門家 アウェアファイの事業ドメインは「メンタルヘルス」 。信頼性や安全性が求められる領域です。 開発チームに心の専門家(公認心理師、臨床心理士)が在籍し、開発チームとともにAIの振る舞いの設計や定性 評価、チューニングを実施しています。 AI x 高可用性 アウェアファイのAIは、ユーザーのみなさまの心の健康と成長を支えるためのAIです。必要なときに、素早く、 安定してサービスを提供することが強く求められています。 アウェアファイでは、高可用性を保つための工夫を行い、サービスの安定供給を実現しています。

Slide 9

Slide 9 text

「AI長期記憶」搭載の取り組み 02

Slide 10

Slide 10 text

AIの短期記憶とは ChatGPTの記憶の標準の範囲は「スレッド内コンテキスト」 メリット : 実装が単純 プロンプトの肥大化を抑制できる タスク毎に支持が異なるユーザーのメンタルモデルと一致 デメリット スレッドを切り替えるとコンテキストがリセットされる メモリー機能(※1)やカスタムインストラクション(※2)を利用した場合を除く ※ 1 https://openai.com/index/memory-and-new-controls-for-chatgpt/ ※ 2 https://openai.com/index/custom-instructions-for-chatgpt/

Slide 11

Slide 11 text

短期記憶の壁を乗り越える長期記憶 より親しみやすいAIの振る舞いの探求 過去のできごとに基づき、現在・未来の振る舞いを変化させることができる すべての情報を完全に記憶し、素早く取り出せるとは限らない ときには間違えることもある(ハルシネーション) 直近のできごとはよく覚えている 印象深いできごとはよく覚えている

Slide 12

Slide 12 text

AIメモリー構想設計初期のホワイトボード

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

高可用性を考慮した LLMマルチエージェント 03

Slide 15

Slide 15 text

AI機能の可用性に対する課題 生成AIの実行には数秒〜十数秒かかることも 前処理や後処理など、ステップが多段階に渡る 状態の途中保存やリトライ性を考慮しながら、システムを構築、運用する必要がある AWS Step Functions による エージェント構築

Slide 16

Slide 16 text

天候情報を取得(外部API) 1. プライマリ 生成AIによるコメント生成 2. 失敗した場合、セカンダリ生成AIに処理を委譲 a. DB に結果を書き込み・ユーザーに成功を伝える 3. 失敗した場合、ユーザーに失敗を伝える a. ※ AI長期記憶についてはより複雑なフローを構築しているため 同サービス内の別の機能の構成で説明しています。 高可用性への取り組み AWS Step Functions を活用し構築

Slide 17

Slide 17 text

LLMマルチエージェントの勘所 複雑なタスクを分割する タスクの分岐判定(メタAI) 前処理、後処理 LLMの使い分け RAG 高可用性をもたらす 負荷分散 フェールソフト

Slide 18

Slide 18 text

チャット内容の要約 チャットの応答 AIメモリーの生成 速度重視 品質重視 タスク分割+LLM適材適所+HA構成の例 構造安定性重視 OpenAI API GPT-4o mini OpenAI API GPT-4o OpenAI API GPT-4o プライマリモデル セカンダリモデル 複数サービス x 複数モデルで フェールソフト 複数サービス x 同一モデルで ロードバランシング LLMごとの特性を活かす (Structured Outputモードを利用) Azure OpenAI Service GPT-4o mini Amazon Bedrock Claude 3.5 Sonnet Azure OpenAI Service GPT-4o

Slide 19

Slide 19 text

LLMの冗長化 1回の処理に数秒〜十数秒の時間がかかる RPM (requests per minute) TPM (tokens per minute) の Limit の考慮 AI機能部分が単一障害点(SPOF)になりがち 例)OpenAI API の 90 days uptime は 99.87 %(11月5日時点) Fail Soft の構成をとるパターン サービスレベルにより、グレードの低いAIで処理を続行できるようにしておく 例)Claude 3 Opus → 処理できない場合 Claude 3 Sonnet を利用 同モデルの冗長化体制をとるパターン 例)Azure OpenAI Service →(処理できない場合)→ OpenAI 公式API を利用 AIが重要な位置を占めるほど、運用課題が大きくなる

Slide 20

Slide 20 text

Appendix - 1 開発フレームワーク LangChain Dify LangFlow モニタリング・オブザーバビリティ LangSmith Langfuse API抽象化・統合 LiteLLM 評価・テスト LangSmith Evaluation Langfuse LLMOpsを支えるツール・サービスたち

Slide 21

Slide 21 text

Appendix - 2 アウェアファイ事例・記事

Slide 22

Slide 22 text

ご清聴ありがとうございました