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

ChatGPT Meetup Tokyo #1
2023/05/11
Shogo Muranushi @ABEJA

Transcript

1. ChatGPT Meetup Tokyo #1 2023/05/11 Shogo Muranushi @ABEJA ノーコード x ChatBotで遊んでたら ReActを実装しそうだった話
2. 村主 壮悟（むらぬし しょうご） ABEJA, Inc. - CTO室：室長 - リテール領域システム開発G：マネージャ - プラットフォームG：意思決定者的に口出す人 - コーポレートIT（セキュリティ）：意思決定者的に口出す人 自己紹介 2 無免許になりました
3. 会社紹介 3
4. ABEJAでの取り組み 4
5. 会社紹介 5 2018年11月のGoogleによるBERTの発表をキッカケに本モデル開発にいたり、2022年に大規模GPTモデルとして完成 4年越し
6. ABEJAでの取り組み① ~ 全社でのChatGPT Plus / APIの補助 ~ 6 御多分にもれず、全社でのChatGPT Plus / APIの補助をしています。 GitHub Copilot X や Microsoft 365 Copilot とかも生産性爆上げしそうなので注目中。
7. ABEJAでの取り組み② ~ ABEJA Insight for Retail での取り組み① β開発中 ~ 7 AI体験をしてもらうために一旦は生のAPIをそのまま叩き、使い方を見てどのようなプロンプトが合うのか、どういう データを繋げると効果が高いのかをチャットサービスとして検証するためにサービス組み込み中。 会話履歴をFirestore、スレッド管理をCloudSQLへ。LangChainを使えば変わるんだろうなと思いつつ、ひとまず生 APIを使い下周りの実装や工夫ポイントをチームでノウハウためつつ、LangChainの実装が安定するのを正座で待機 （足が痺れて先に実装するかもだけど） 開発中
8. ABEJAでの取り組み② ~ ABEJA Insight for Retail での取り組み② β開発予定 ~ 8 店舗での売上におけるPDCAを支援する機能で、PDCA機能というものがある。 店舗での施策案をサジェストしたり、振り返りの壁打ち相手としてもChatGPTは有効。 チャット以外の用途でのサービスへの組み込み、有効性の検証。 目標設定 施策登録 振り返り MLによる売上や来客者数等の予測 GPTによる施策のサジェスト New 振り返りの壁打ち New
9. ABEJAでの取り組み③ ~ ABEJA Platform での取り組み① β開発予定 ~ 9 精度検証をサクッと行えるように、以下のような Indexing と Serving を行うレイヤーに加えて、入力するデータソー スの指定や簡易な検索画面を実装予定。そのまま本番環境のAPIとして利用可能。 ただし、LangChainやLlamaIndex等の動向を注視しながら（2週間単位くらいで実装やコンセプトが変わるので）、何 をどう抽象化するのが効果的か検証・検討中。ベクターデータベースを国産フルマネージドサービスとして作るのも面 白そう。社内で欲しい。あとAutoGPTとかも面白いですよね。
10. ABEJAでの取り組み④ ~ ABEJA LLM Series の取り組み① ~ 10 > 個人情報や企業の機密情報を取り扱う際にデータ のハンドリングが可能な環境を構築しており、プラ イバシー保護および情報漏洩のリスクマネジメント に対応したサービス提供を行なっています。　 => オプトアウトしても、サービスの脆弱性を突か れたりすると漏洩するよね。 特徴① 特徴②
11. フェーズ１：サーバの管理めんどくさいな 11
12. フェーズ１：サーバの管理めんどくさいな 1. Slackと連携する何かを作りたいな a. そういえば Sentry のエラーメッセージって引き継いだ時に対処がわかりずらいから、エラーメッ セージの解読や対処方法をChatGPTに回答させるのはどうだろう的 12
13. フェーズ１：サーバの管理めんどくさいな 1. Slackと連携する何かを作りたいな a. そういえば Sentry のエラーメッセージって引き継いだ時に対処がわかりずらいから、エラーメッ セージの解読や対処方法をChatGPTに回答させるのはどうだろう的 2. SlackのWebhookを受けてOpenAIにリクエスト送るサーバ管理するの面倒だな。LambdaとかどのAWS アカウント使うかも面倒だし a. Slack Platformはなぜか不安定？コールドスタートで動かない？ 3. そういえばMake (integromat)がWebhookを受けられるな。使ってみるか 4. SentryからWebhookで受け取って、OpenAIで解析、Slackに通知 13
14. フェーズ１：解析結果 14
15. フェーズ１：課題 1. おおむね1回500トークンくらい使ってた OpenAI の gpt-3.5-turbo のAPI利用料は $0.002 / 1K tokens つまり、だいたい $0.001/回 2. Sentryの通知量は暴発すると月間数十万いくこともある 仮に50万回で計算したら $500 /月 うん。少し高いな。全部が全部を解析する必要ないか... 15
16. フェーズ２：SlackのReactionで解析するようにする 16
17. フェーズ２：Reactionで解析するようにする 1. 常に毎回解析するのは高コストなので、Slackの特定のリアクションに反応して解析する処理を作成す る。せっかくリアクションを反応させるなら複数のリアクションを分岐させて反応を分けさせよう 17
18. フェーズ２：:age1: スタンプで要約を、:error: スタンプで対処方法を 1. Eventを受け取った直後に該当スタンプのみ後 続処理するようにフィルタをしている。なぜな らば、Eventが全て飛んでくるのでフィルタす る必要がある。 a. Slack側で通知飛ばす前にフィルタできれ ば良いのに...。無駄にOps(課金単位)を消 費する。Lamdbaとかでも無駄に動いてし まうのでなんとかして欲しい 18
19. フェーズ２：リアクションが付いているチャンネルとメッセージを取得し、条件分岐 19
20. フェーズ２：トラブルシュートと要約のプロンプトを作る 20
21. フェーズ２：Slackに応答させる 21
22. フェーズ２：再掲 22
23. フェーズ２：結果 23
24. フェーズ３：あれ？これReAct作れるんじゃない？ 24
25. フェーズ３：ReActとは 25
26. フェーズ３：先に完成系 26
27. フェーズ３：先に完成系 27
28. フェーズ３：先に完成系 28
29. フェーズ３：Webhook → 入力した人のユーザ名、アイコンURLを取得し偽装投稿 29
30. フェーズ３：Reasoning 30
31. フェーズ３：ルーティング 31
32. フェーズ３：トラブルシュート 32
33. フェーズ３：トラブルシュート完成系 33
34. フェーズ３：要約 34
35. フェーズ３：要約完成系 35
36. フェーズ３：カレンダー① 36
37. フェーズ３：カレンダー② 37
38. フェーズ３：カレンダー② 38
39. フェーズ３：カレンダー③ 39
40. フェーズ３：カレンダー④ 40
41. フェーズ３：カレンダー完成系 41
42. フェーズ３：足りないこと、出来なかったこと 1. 処理を順番に実装する、もしくは処理を分岐させて処理させることは可能 2. ただし、処理の結果をもとに別の処理を類推させるのはできなかった a. OpenAIのAPIで次の行動を分岐させることは出来ても、動的にワークフローを構成することが難しい 42
43. フェーズ３：足りないこと 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
44. フェーズ４：感想 44
45. フェーズ４：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
46. フェーズ４：Make 等の iPaaS で OpenAI API を叩くことのメリット 1. ReAct は現時点ではできないけど、 LangChain に無いAPIも実装できる。Make だと1,427個も.. BigQuery, ElasticSearch, GitHub, Asana, ClickUp, Gmail, etc… 2. サーバ管理不要でノーコードで Slack bot を簡単に作ったり、アレ・コレ・ソレとチェーンを繋げて多種 多様なサービスで GPT の力を借りられる 46
47. フェーズ４：LangChainとかの中身の気持ちになれた 1. 現時点でポピュラーなのは LangChain や LlamaIndex で Notion なり Google Docs とかの情報を Embedded してベクトルサーチに突っ込み検索する方法ですが、 2. この方法だと Notion API や Slack API で直接検索して、詳細情報を取得して、中身を要約して貼り付け ることもできる a. データ更新のたびにEmbeddedしなくて良いメリットは大きい。が、検索精度はサービスに依存。 ただし、サービス側もGPT関連技術で検索精度上げてくるだろうし、依存させるのもあり？ 3. 一応プロンプトインジェクション対策も可能な状態になる 47
48. フェーズ４：最後に 1. AutoGPT でも API 仕様を解釈してサービスを利用して情報取得することも可能になりそう a. ただし OpenAPI 前提や、うまく解釈できないケースとかもあったりしそう。 2. iPaaS は既にインテグ済みなので上のケースよりは早く実装できそう a. ただし AutoGPT が優秀になれば対応するAPIで負けることもある気も 3. どちらでも良いけど、より楽により簡単に実装できる世界線の芽が出始めている 4. 色々試して妄想したり、アンチパターンを発掘して共有したり、より良いモノを創っていきましょう 48
49. * 本文章は人間によって作成されました 49
50. ご静聴ありがとうございました 50