ノーコード x ChatBotで遊んでたら ReActを実装しそうだった話

Slide 1

Slide 1 text

ChatGPT Meetup Tokyo #1 2023/05/11 Shogo Muranushi @ABEJA ノーコード x ChatBotで遊んでたら ReActを実装しそうだった話

Slide 2

Slide 2 text

村主壮悟（むらぬししょうご） ABEJA, Inc. - CTO室：室長 - リテール領域システム開発G：マネージャ - プラットフォームG：意思決定者的に口出す人 - コーポレートIT（セキュリティ）：意思決定者的に口出す人自己紹介 2 無免許になりました

Slide 3

Slide 3 text

会社紹介 3

Slide 4

Slide 4 text

ABEJAでの取り組み 4

Slide 5

Slide 5 text

会社紹介 5 2018年11月のGoogleによるBERTの発表をキッカケに本モデル開発にいたり、2022年に大規模GPTモデルとして完成 4年越し

Slide 6

Slide 6 text

ABEJAでの取り組み① ~ 全社でのChatGPT Plus / APIの補助 ~ 6 御多分にもれず、全社でのChatGPT Plus / APIの補助をしています。 GitHub Copilot X や Microsoft 365 Copilot とかも生産性爆上げしそうなので注目中。

Slide 7

Slide 7 text

ABEJAでの取り組み② ~ ABEJA Insight for Retail での取り組み① β開発中 ~ 7 AI体験をしてもらうために一旦は生のAPIをそのまま叩き、使い方を見てどのようなプロンプトが合うのか、どういうデータを繋げると効果が高いのかをチャットサービスとして検証するためにサービス組み込み中。会話履歴をFirestore、スレッド管理をCloudSQLへ。LangChainを使えば変わるんだろうなと思いつつ、ひとまず生 APIを使い下周りの実装や工夫ポイントをチームでノウハウためつつ、LangChainの実装が安定するのを正座で待機（足が痺れて先に実装するかもだけど）開発中

Slide 8

Slide 8 text

ABEJAでの取り組み② ~ ABEJA Insight for Retail での取り組み② β開発予定 ~ 8 店舗での売上におけるPDCAを支援する機能で、PDCA機能というものがある。店舗での施策案をサジェストしたり、振り返りの壁打ち相手としてもChatGPTは有効。チャット以外の用途でのサービスへの組み込み、有効性の検証。目標設定施策登録振り返り MLによる売上や来客者数等の予測 GPTによる施策のサジェスト New 振り返りの壁打ち New

Slide 9

Slide 9 text

ABEJAでの取り組み③ ~ ABEJA Platform での取り組み① β開発予定 ~ 9 精度検証をサクッと行えるように、以下のような Indexing と Serving を行うレイヤーに加えて、入力するデータソースの指定や簡易な検索画面を実装予定。そのまま本番環境のAPIとして利用可能。ただし、LangChainやLlamaIndex等の動向を注視しながら（2週間単位くらいで実装やコンセプトが変わるので）、何をどう抽象化するのが効果的か検証・検討中。ベクターデータベースを国産フルマネージドサービスとして作るのも面白そう。社内で欲しい。あとAutoGPTとかも面白いですよね。

Slide 10

Slide 10 text

ABEJAでの取り組み④ ~ ABEJA LLM Series の取り組み① ~ 10 > 個人情報や企業の機密情報を取り扱う際にデータのハンドリングが可能な環境を構築しており、プライバシー保護および情報漏洩のリスクマネジメントに対応したサービス提供を行なっています。　 => オプトアウトしても、サービスの脆弱性を突かれたりすると漏洩するよね。特徴① 特徴②

Slide 11

Slide 11 text

フェーズ１：サーバの管理めんどくさいな 11

Slide 12

Slide 12 text

フェーズ１：サーバの管理めんどくさいな 1. Slackと連携する何かを作りたいな a. そういえば Sentry のエラーメッセージって引き継いだ時に対処がわかりずらいから、エラーメッセージの解読や対処方法をChatGPTに回答させるのはどうだろう的 12

Slide 13

Slide 13 text

フェーズ１：サーバの管理めんどくさいな 1. Slackと連携する何かを作りたいな a. そういえば Sentry のエラーメッセージって引き継いだ時に対処がわかりずらいから、エラーメッセージの解読や対処方法をChatGPTに回答させるのはどうだろう的 2. SlackのWebhookを受けてOpenAIにリクエスト送るサーバ管理するの面倒だな。LambdaとかどのAWS アカウント使うかも面倒だし a. Slack Platformはなぜか不安定？コールドスタートで動かない？ 3. そういえばMake (integromat)がWebhookを受けられるな。使ってみるか 4. SentryからWebhookで受け取って、OpenAIで解析、Slackに通知 13

Slide 14

Slide 14 text

フェーズ１：解析結果 14

Slide 15

Slide 15 text

フェーズ１：課題 1. おおむね1回500トークンくらい使ってた OpenAI の gpt-3.5-turbo のAPI利用料は $0.002 / 1K tokens つまり、だいたい $0.001/回 2. Sentryの通知量は暴発すると月間数十万いくこともある仮に50万回で計算したら $500 /月うん。少し高いな。全部が全部を解析する必要ないか... 15

Slide 16

Slide 16 text

フェーズ２：SlackのReactionで解析するようにする 16

Slide 17

Slide 17 text

フェーズ２：Reactionで解析するようにする 1. 常に毎回解析するのは高コストなので、Slackの特定のリアクションに反応して解析する処理を作成する。せっかくリアクションを反応させるなら複数のリアクションを分岐させて反応を分けさせよう 17

Slide 18

Slide 18 text

フェーズ２：:age1: スタンプで要約を、:error: スタンプで対処方法を 1. Eventを受け取った直後に該当スタンプのみ後続処理するようにフィルタをしている。なぜならば、Eventが全て飛んでくるのでフィルタする必要がある。 a. Slack側で通知飛ばす前にフィルタできれば良いのに...。無駄にOps(課金単位)を消費する。Lamdbaとかでも無駄に動いてしまうのでなんとかして欲しい 18

Slide 19

Slide 19 text

フェーズ２：リアクションが付いているチャンネルとメッセージを取得し、条件分岐 19

Slide 20

Slide 20 text

フェーズ２：トラブルシュートと要約のプロンプトを作る 20

Slide 21

Slide 21 text

フェーズ２：Slackに応答させる 21

Slide 22

Slide 22 text

フェーズ２：再掲 22

Slide 23

Slide 23 text

フェーズ２：結果 23

Slide 24

Slide 24 text

フェーズ３：あれ？これReAct作れるんじゃない？ 24

Slide 25

Slide 25 text

フェーズ３：ReActとは 25

Slide 26

Slide 26 text

フェーズ３：先に完成系 26

Slide 27

Slide 27 text

フェーズ３：先に完成系 27

Slide 28

Slide 28 text

フェーズ３：先に完成系 28

Slide 29

Slide 29 text

フェーズ３：Webhook → 入力した人のユーザ名、アイコンURLを取得し偽装投稿 29

Slide 30

Slide 30 text

フェーズ３：Reasoning 30

Slide 31

Slide 31 text

フェーズ３：ルーティング 31

Slide 32

Slide 32 text

フェーズ３：トラブルシュート 32

Slide 33

Slide 33 text

フェーズ３：トラブルシュート完成系 33

Slide 34

Slide 34 text

フェーズ３：要約 34

Slide 35

Slide 35 text

フェーズ３：要約完成系 35

Slide 36

Slide 36 text

フェーズ３：カレンダー① 36

Slide 37

Slide 37 text

フェーズ３：カレンダー② 37

Slide 38

Slide 38 text

フェーズ３：カレンダー② 38

Slide 39

Slide 39 text

フェーズ３：カレンダー③ 39

Slide 40

Slide 40 text

フェーズ３：カレンダー④ 40

Slide 41

Slide 41 text

フェーズ３：カレンダー完成系 41

Slide 42

Slide 42 text

フェーズ３：足りないこと、出来なかったこと 1. 処理を順番に実装する、もしくは処理を分岐させて処理させることは可能 2. ただし、処理の結果をもとに別の処理を類推させるのはできなかった a. OpenAIのAPIで次の行動を分岐させることは出来ても、動的にワークフローを構成することが難しい 42

Slide 43

Slide 43 text

フェーズ３：足りないこと 1. ただし、以下のようなことができれば…？ a. LangChainのように予め使う予定のmodule（GoogleカレンダーAPIやNotion APIなど）のクレデンシャルを設定し moduleとして複数のLLMを定義 b. OpenAI APIでゴールから逆算してタスクに分解する c. 分解されたタスクを解決していく。必要に応じて動的にタスクを分解してmoduleを選択する d. moduleを呼び出す際のAPI（GoogleカレンダーAPIなど）のお作法は事前にIndexして解釈できるようにとか。もしくはAutoGPT相当な実装も面白い 2. iPaaSにAutoGPTが組み込まれたらかなり強くなりそう。非常に期待 43

Slide 44

Slide 44 text

フェーズ４：感想 44

Slide 45

Slide 45 text

フェーズ４：Description Ops より合わせやすい？ 1. Description Ops（LangChain系）はクエリがDescriptionに影響する a. Descriptionに引っかかるようにクエリとDescriptionの調整が必要（LLM決定の精度は両方に依存） 2. 本手法のルーティング（free translation routingと名づける）では、クエリを意訳してルーティングを明示的に決める（LLM決定精度はクエリのみに依存） 45 ref: https://speakerdeck.com/peisuke/langchain-toolsnoyun-yong-togai-shan

Slide 46

Slide 46 text

フェーズ４：Make 等の iPaaS で OpenAI API を叩くことのメリット 1. ReAct は現時点ではできないけど、 LangChain に無いAPIも実装できる。Make だと1,427個も.. BigQuery, ElasticSearch, GitHub, Asana, ClickUp, Gmail, etc… 2. サーバ管理不要でノーコードで Slack bot を簡単に作ったり、アレ・コレ・ソレとチェーンを繋げて多種多様なサービスで GPT の力を借りられる 46

Slide 47

Slide 47 text

フェーズ４：LangChainとかの中身の気持ちになれた 1. 現時点でポピュラーなのは LangChain や LlamaIndex で Notion なり Google Docs とかの情報を Embedded してベクトルサーチに突っ込み検索する方法ですが、 2. この方法だと Notion API や Slack API で直接検索して、詳細情報を取得して、中身を要約して貼り付けることもできる a. データ更新のたびにEmbeddedしなくて良いメリットは大きい。が、検索精度はサービスに依存。ただし、サービス側もGPT関連技術で検索精度上げてくるだろうし、依存させるのもあり？ 3. 一応プロンプトインジェクション対策も可能な状態になる 47

Slide 48

Slide 48 text

フェーズ４：最後に 1. AutoGPT でも API 仕様を解釈してサービスを利用して情報取得することも可能になりそう a. ただし OpenAPI 前提や、うまく解釈できないケースとかもあったりしそう。 2. iPaaS は既にインテグ済みなので上のケースよりは早く実装できそう a. ただし AutoGPT が優秀になれば対応するAPIで負けることもある気も 3. どちらでも良いけど、より楽により簡単に実装できる世界線の芽が出始めている 4. 色々試して妄想したり、アンチパターンを発掘して共有したり、より良いモノを創っていきましょう 48