Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

shogomuranushi
May 11, 2023
1.2k

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

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

shogomuranushi

May 11, 2023
Tweet

More Decks by shogomuranushi

Transcript

  1. ChatGPT Meetup Tokyo #1 2023/05/11 Shogo Muranushi @ABEJA ノーコード x

    ChatBotで遊んでたら ReActを実装しそうだった話
  2. 村主 壮悟(むらぬし しょうご) ABEJA, Inc. - CTO室:室長 - リテール領域システム開発G:マネージャ -

    プラットフォームG:意思決定者的に口出す人 - コーポレートIT(セキュリティ):意思決定者的に口出す人 自己紹介 2 無免許になりました
  3. ABEJAでの取り組み① ~ 全社でのChatGPT Plus / APIの補助 ~ 6 御多分にもれず、全社でのChatGPT Plus

    / APIの補助をしています。 GitHub Copilot X や Microsoft 365 Copilot とかも生産性爆上げしそうなので注目中。
  4. ABEJAでの取り組み② ~ ABEJA Insight for Retail での取り組み① β開発中 ~ 7

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

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

    と Serving を行うレイヤーに加えて、入力するデータソー スの指定や簡易な検索画面を実装予定。そのまま本番環境のAPIとして利用可能。 ただし、LangChainやLlamaIndex等の動向を注視しながら(2週間単位くらいで実装やコンセプトが変わるので)、何 をどう抽象化するのが効果的か検証・検討中。ベクターデータベースを国産フルマネージドサービスとして作るのも面 白そう。社内で欲しい。あとAutoGPTとかも面白いですよね。
  7. ABEJAでの取り組み④ ~ ABEJA LLM Series の取り組み① ~ 10 > 個人情報や企業の機密情報を取り扱う際にデータ

    のハンドリングが可能な環境を構築しており、プラ イバシー保護および情報漏洩のリスクマネジメント に対応したサービス提供を行なっています。  => オプトアウトしても、サービスの脆弱性を突か れたりすると漏洩するよね。 特徴① 特徴②
  8. フェーズ1:課題 1. おおむね1回500トークンくらい使ってた OpenAI の gpt-3.5-turbo のAPI利用料は $0.002 / 1K

    tokens つまり、だいたい $0.001/回 2. Sentryの通知量は暴発すると月間数十万いくこともある 仮に50万回で計算したら $500 /月 うん。少し高いな。全部が全部を解析する必要ないか... 15
  9. フェーズ3:足りないこと 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
  10. フェーズ4: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
  11. フェーズ4:Make 等の iPaaS で OpenAI API を叩くことのメリット 1. ReAct は現時点ではできないけど、

    LangChain に無いAPIも実装できる。Make だと1,427個も.. BigQuery, ElasticSearch, GitHub, Asana, ClickUp, Gmail, etc… 2. サーバ管理不要でノーコードで Slack bot を簡単に作ったり、アレ・コレ・ソレとチェーンを繋げて多種 多様なサービスで GPT の力を借りられる 46
  12. フェーズ4:LangChainとかの中身の気持ちになれた 1. 現時点でポピュラーなのは LangChain や LlamaIndex で Notion なり Google

    Docs とかの情報を Embedded してベクトルサーチに突っ込み検索する方法ですが、 2. この方法だと Notion API や Slack API で直接検索して、詳細情報を取得して、中身を要約して貼り付け ることもできる a. データ更新のたびにEmbeddedしなくて良いメリットは大きい。が、検索精度はサービスに依存。 ただし、サービス側もGPT関連技術で検索精度上げてくるだろうし、依存させるのもあり? 3. 一応プロンプトインジェクション対策も可能な状態になる 47
  13. フェーズ4:最後に 1. AutoGPT でも API 仕様を解釈してサービスを利用して情報取得することも可能になりそう a. ただし OpenAPI 前提や、うまく解釈できないケースとかもあったりしそう。

    2. iPaaS は既にインテグ済みなので上のケースよりは早く実装できそう a. ただし AutoGPT が優秀になれば対応するAPIで負けることもある気も 3. どちらでも良いけど、より楽により簡単に実装できる世界線の芽が出始めている 4. 色々試して妄想したり、アンチパターンを発掘して共有したり、より良いモノを創っていきましょう 48