Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
対話型AIプロダクトの今と展望 〜ChatBot・VoiceBotの開発技術を解説〜
Search
CyberAgent
PRO
December 14, 2023
5
1.2k
対話型AIプロダクトの今と展望 〜ChatBot・VoiceBotの開発技術を解説〜
CyberAgent
PRO
December 14, 2023
Tweet
Share
More Decks by CyberAgent
See All by CyberAgent
生成AIの強みと弱みを理解して、生成AIがもたらすパワーをプロダクトの価値へ繋げるために実践したこと / advance-ai-generating
cyberagentdevelopers
PRO
1
180
SNSマーケティングに革新! ABEMA サッカー動画切り出しを生成AIで自動化し、業務効率化を狙う! / abema-ai-marketing
cyberagentdevelopers
PRO
1
89
新卒1年目が挑む!生成AI × マルチエージェントで実現する次世代オンボーディング / operation-ai-onboarding
cyberagentdevelopers
PRO
1
170
バナー自動生成に向けたオープンなtext-to-templateモデルの構築 / creative-ai-opencole
cyberagentdevelopers
PRO
1
68
Argo Workflowsで構築するLLMを活用したコールセンターの自動要約プロダクトの立ち上げ / ai-argo-summarize
cyberagentdevelopers
PRO
1
60
大規模データ基盤チームのオンプレTiDB運用への挑戦 / dpu-tidb
cyberagentdevelopers
PRO
1
110
カメラを用いた店内計測におけるオプトインの仕組みの実現 / ai-optin-camera
cyberagentdevelopers
PRO
1
120
新しい映像体験WINLIVE競輪選手の体力を可視化するテクノロジーとその裏側 / winlive-sensing
cyberagentdevelopers
PRO
1
52
20周年を迎えたAmebaでのデータチームの挑戦: モノリスなデータ基盤における論理的データメッシュの構築 / ameba-mesh-gemini
cyberagentdevelopers
PRO
1
56
Featured
See All Featured
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
How to Think Like a Performance Engineer
csswizardry
19
1.1k
GraphQLの誤解/rethinking-graphql
sonatard
66
9.9k
The World Runs on Bad Software
bkeepers
PRO
65
11k
Intergalactic Javascript Robots from Outer Space
tanoku
268
27k
Practical Orchestrator
shlominoach
186
10k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
280
13k
Documentation Writing (for coders)
carmenintech
65
4.4k
Designing the Hi-DPI Web
ddemaree
280
34k
What’s in a name? Adding method to the madness
productmarketing
PRO
22
3.1k
Building Your Own Lightsaber
phodgson
102
6.1k
GitHub's CSS Performance
jonrohan
1030
460k
Transcript
対話型AIプロダクトの 今と展望 〜ChatBot・VoiceBotの開発技術を解説〜
青野健利 github: @brn twitter: brn227 - 開発責任者 at AI
Shift - Contributor of V8(~ 2018) 自己紹介
None
デジタルマーケティング分野のサービス開発を行う事業部。 全体の7割以上が技術職で構成され、広告取引の世界で培ったAI技術の適応領域を拡大中。 約350名を超える、エンジニア・研究者・データサイエンティスト・デザイナーが所属 DX AI D2C マーケ ティング AI クリエイ
ティブ 対話AI 新事業 小売 医療 行政 GovTech 開発組織 DataScienceCenter データサイエンティストの横断組織 事業へのデータサイエンスの応用・実装 AI Lab AI技術の研究開発を行う専門組織 国際学会への論文投稿など学術貢献も活発 AI Tech studio ビジネスサイドと連携したプロダクト開発 接客 イベント
デジタルマーケティング全般に関わる、幅広いAI技術の研究開発を目的に設立。 ビジネス課題の解決と学術的貢献を目指す。 ・KDD 2022 機械学習における観測遅延問題の 改善方法を提案 ・CVPR2022 研究開発の基礎技術となる指標や 分析方法を提案(3本の主著論文採択) ・ICML2022
高次元情報を用いた逐次的な 意思決定手法を提案 ・国際カンファレンス 「IEEE RO-MAN」基調講演 ・「ACM MMAsia 2022」にAI Lab の山口光太が登壇 ・「SNL2022」にAI Lab研究員の 大谷まゆが登壇 ・「日本経済学会春季大会」に AI Labの蟻生・森脇・加藤・竹浪が 登壇 ・言語処理学会第29回年次大会 (NLP2023)にて過去最多となる 13件の発表を実施 国際トップカンファレンス での採択&発表 登壇実績 2022年 論文採択数 約 50本
AI Shiftについて
VISION 人らしい世の中を創る 『AI vs 人間』『AIが人の仕事を奪う』といったように AIと人間が対立構造として捉えられることが多くあります。 当社の考えは少し異なり、 AIは人間が使ってこそ、 はじめて価値が出ると考えております。 AIが得意なことはAIに任せることで、本来、人間がすべき
『クリエイティブ、マネジメント、ホスピタリティ』などの仕事に集中出来る、 そんな人らしい世の中が実現出来ると考えております。
MISSION AIを民主化する AIは人類最大の革命と言われています。 上手く活用することができれば人類の驚異的な進歩となるでしょう。 しかしながら、現在それを自在に扱える企業や人はまだ限られています。 AIを必要とする企業や人が、最適に、且つ簡単に AIを使える 『AIが民主化された社会』 を実現することが当社の使命です。
AI Shiftのミッション
チャットボット事業 ボイスボット事業 対話型AIによる チャット対応の自動化 対話型AIによる 電話対応の自動化 生成AI活用による 会話要約の自動化 LLM活用事業
AI Messenger Chatbot
AI Messenger Chatbot
AI Messenger Voicebot
AI Messenger Voicebot
AI Messenger Summary
今後の展望 チャットボット事業 ボイスボット事業 LLMエンジンの追加 LLMによるシナリオ自 動生成 生成AIを活用した新規 事業 新規事業 ?
技術スタック フロントエンド バックエンド データベース その他ツール
• Audioチーム • 接客対話チーム • 強化学習チーム • 完全自動対話研究センター • 東北大学 乾健太郎 教授
• 名古屋工業大学 李 晃伸教授 産学連携 AI((ML/DS)チーム 研究体制
【1】AIを活用したChatBot・VoiceBotのシステム概観 【2】マルチテナントBotを支えるインフラ構成について 【3】管理画面の複雑なUIのフロントエンド開発 Speaker:石井 俊輝 Speaker:須永 大生 Speaker:栗崎 一真
AIを活用したChatBot・VoiceBot のシステム概観 株式会社 AIShift Backend Engineer 石井俊輝
自己紹介 いしい としき 石井 俊輝 【主な業務】 VoiceBot運用基盤/新規プロダクトの開発 2023年 CyberAgent
中途入社 所属: 株式会社AIShift @sugar235711
Agenda 1. リアルタイム応答Bot現行アーキテクチャ 2. 現行VoiceBotの課題と対話エンジンの内製化 3. 今後の開発展望
リアルタイム応答Bot 現行アーキテクチャ
プロダクト概要 自動応対可能なChatBot・VoiceBotを提供 • 個社ごとにシナリオ構築からBot運用まで一気通貫でサポート
プロダクト概要 自動応対可能なChatBot・VoiceBotを提供 • 個社ごとにシナリオ構築からBot運用まで一気通貫でサポート
システムの特徴 • マイクロサービス ◦ シナリオ構築/会話管理/Bot...etc ◦ 双方向のリアルタイム通信
• マルチテナントアプリケーション ◦ MySQLのデータベース分離によるセキュ リティ対応 ◦ Nginxによるサブドメインの割り当て
UI: ChatBot UI(管理画面+ウィジェット)/Backend Service
アーキテクチャ: ChatBot
アーキテクチャ: ChatBot • ChatBotのメイン • 回答の生成と履歴の 管理
アーキテクチャ: ChatBot • リアルタイムチャット実現のために WebSocketは使用していない
アーキテクチャ: ChatBot • リアルタイムチャット実現のために WebSocketは使用していない ➔ FirestoreのSnapShotListenerでドキュ メントの変更を検知
アーキテクチャ: ChatBot • 会話履歴の表示 • 有人チャットの開始
アーキテクチャ: ChatBot • サービス間のメッセージの やり取りはQueueを通す
アーキテクチャ: ChatBot • サービス間のメッセージの やり取りはQueueを通す ➔ メインプロセスに依存しな い非同期処理の実現 ➔ エラー時の再送処理の保
証
UI: VoiceBot UI(管理画面)/Backend Service
アーキテクチャ: VoiceBot
アーキテクチャ: VoiceBot • DialogFlowを使用し対話エンジンを構築
アーキテクチャ: VoiceBot • DialogFlowを使用し対話エンジンを構築 ➔ 顧客発話→STT→DialogFlow→TTS→VoiceApp→Twilio応答 ※DialogFlow:
シナリオベースのBotを作成できるGCPのサービス
現行VoiceBotの課題と 対話エンジンの内製化
既存のVoiceBot構築の難しさ DialogFlowではシナリオのフローを表示するUIが存在しない ➔ 手作業でフローを書き起こし、DialogFlow管理画面から入力する DialogFlow管理画面
フローの書き起こし
既存のVoiceBot構築の難しさ DialogFlowではシナリオのフローを表示するUIが存在しない ➔ 手作業でフローを書き起こし、DialogFlow管理画面から入力する •
リソースの多重管理(人為的ミス、工数増加) • バージョン管理が困難(シナリオを含めたアプリケーションのロールバック が難しい) • 自社独自のリソースとの連携が難しい(音声認識などのモデルがGoogle提 供のものに限られる)
シナリオ構築UI + 対話エンジン: DialogEngine DialogFlowの完全置き換えを目指し、UIと対話エンジン部分を内製化を行った スクラッチで実装 •
シナリオ構築部分 RDBによるグラフ管理 • Botのワークフローの履 歴管理 • 外部連携機能 SMS/Mail/SIP転送...etc
アーキテクチャ: DialogEngine(Admin, Bot)
アーキテクチャ: DialogEngine(Admin, Bot)
アーキテクチャ: DialogEngine(Admin, Bot) • シナリオ作成画面とAPIを新設
アーキテクチャ: DialogEngine(Admin, Bot) • シナリオ作成画面とAPIを新設 ➔ React Flow +
RDBで軽量なシナリオ描画、か つ強整合なグラフ構造を実現
アーキテクチャ: DialogEngine(Admin, Bot) • 適切な粒度にサービスを分割 • 各サービス間をgRPCで繋ぎ異 なるチーム・言語での開発を可 能に
アーキテクチャ: DialogEngine(Admin, Bot) • Botが動作するシナリオをRDBから取り出しRedis にキャッシュ
アーキテクチャ: DialogEngine(Admin, Bot) • Botが動作するシナリオをRDBから取り出しRedis にキャッシュ • 以降ログをRedisに書き込み、アプリケーションの メモリ使用量を抑えつつ素早い応答を実現
アーキテクチャ: DialogEngine(Admin, Bot) • DialogFlowで実現していた機 能をサービスに分割
アーキテクチャ: DialogEngine(Admin, Bot) • DialogFlowで実現していた機 能をサービスに分割 • 独自のエンジンを選択できる 拡張性を持たせる
今後の開発展望
1. 運用中VoiceBotのDialogEngineへ のシナリオ移行 2. Chat/Voiceのシナリオ構築サービ スの共通化 3. レガシーコードのリファクタリング
今後の展望 既存 1. LLMを活用のための基盤開発 2. 既存システムへのLLMを導入 3. 新規サービスの実装 新規
マルチテナントBotを支える インフラ構成について 株式会社 AIShift Backend Engineer 須永 大生
自己紹介 すなが だいき 須永 大生 【主な業務】 Chatbot,Voicebot開発/新規プロダクトの開発 2022年 CyberAgent
新卒入社 所属: 株式会社AIShift
利用ツール
アーキテクチャパターン ・マイクロサービス 採用した主な理由は2つあります。 ①開発の効率性 各サービスは独立してデプロイできるため、全体のリリースサイクルを速めることができます。AI ShiftではAIチームと開発チームが別れていることや、AIチームの中でも担当しているアプリケーショ ンが別れているので非同期的に開発ができることがメリットです。
②技術的な柔軟性 AIチームでは開発にPythonを利用しており、開発チームではGoを利用しています。 このように別の技術を同じプロダクトで利用できるのもメリットです。
ホスティング ・GCPを利用 FirestoreをChatbotで利用したかったので、GCPを選択しています。 (Firestoreを利用する理由は後ほどご紹介します) ・Kubernetes(GKE)を活用 Kubernetesを利用している主な理由は2016年当時に、Container管理ツールとして良い技術であると判 断したためです。 ・リソースはTerraform管理 Terraformでインフラを管理しています。 Terraformの実行環境としてTerraformCloudを利用していて、安全な実行環境と権限管理を実現していま
す。
CI/CD ・GitHub Actions アプリケーション側の基本的なCI/CDはGitHub Actionsを通じて実現されています。 ・ArgoCD Gitリポジトリに格納されたマニフェストファイルに基づいてKubernetesリソースを同期させます。これ により、デプロイメントの速度と一貫性が向上します。
DB(MySQL) ・フローの整合性 Botが動くフローの整合性が重要なサービスなのでRDB管理となっています。 ・マルチテナント ChatbotもVoicebotもマルチテナントサービスなのでRDBはテナントごとにわかれています。
DB(Memorystore、Redis) ・Botの会話内容の一時保存 何が発話されたのか、といった情報を一時的に保存し、Botが参照するために利用しています。 例えば、Voicebot以外のところに一時的に電話をつなぐ処理(外線転送)があり、前の会話の状態を 保存しておいて、外線転送からBotに戻ってきたときに再度コンテキストを復帰させる役割などがあり ます。
DB(Cloud Firestore) ・会話ログとして利用 Redisで一時保存した会話情報の永続書き込み先として利用しています。 ・セキュリティルール Botを利用するユーザー、オペレーター、Botの管理者などのデータ参照範囲をセキュリティルールを 利用して簡単に作成できます。
DB(Cloud Firestore) ・Botと有人の切り替えが楽 ChatbotではBotが応対する場合と人が応対する場合があるのですが、書き込み先はFirestoreに一 元化しています。これにより、フロントエンド側はBot発話やオペレータ発話のいずれかによらず、 Firestoreを一貫して参照するだけでよいです。 また、Chatbotの場合、Firestoreへの書き込みと同時にSubscribeしているClientへ自動配信されるこ
とも重要です。
Pub/Sub ・非同期的な会話書き込み ChatbotではPub/Subを利用して非同期的に会話を書き込んでいます。これにより、メッセージのロス トの防止やスケーラビリティを担保しています。 Voicebotでも一部Pub/Subを利用していますが、Chatbotとは違い、リアルタイム性が強いサービスな ので、下記の流れ以外の非同期的な部分で利用しています。
プロトコル ・REST I/FはOpenAPIで定義しており、これを参照することで、フロントエンドとバックエンドの間で齟齬が生まれな いようにしています。 ・gRPC 開発チームが開発しているアプリケーションとAIチームが開発しているアプリケーションの間はgRPCで連 携しています。gRPCを利用している理由は高速な通信やStreaming形式のRPCも提供している点です。 protoファイルをAIチームと開発チームで参照しあっています。 ・WebSocket
VoicebotではtwilioというWebサービスとBotが接続しますが、この間はWebSocketで接続されておりスト リーミング通信ができます。
フロントエンド 複雑な管理画面UIの開発
自己紹介 栗崎一真 2023.5 AI-SHIFT 中途入社 2023.5 AI-SHIFT 中途入社 X:
@KK_sep_TT 主な業務 chat bot, voicebot, 新規プロダクトのフロントエンド開発
Index • toB SaaS フロントエンド開発について • 使用技術 • どうやって複雑さに立ち向かうか
• 今後の展望
toB SaaS に求められる要件 あまり重要ではないこと 重要なこと • SEO • 初期ロードの速度
• 動作が軽いこと • 操作がわかりやすいこと SSRを使用しないSPAで構築
ChatBot, VoiceBot 管理画面開発 私たちの toB SaaS の特徴 • 複雑な画面が多い
• API 連携が多い • フロントにもロジックがある
使用技術 言語: Typescript UIフレームワーク: React 状態管理: Redux 認証: Firebase Auth
どうやって複雑さに立ち向かうか コンポーネント設計 純粋な関数への分割 ライブラリの利用
コンポーネント設計 ~ Atomic Design からの脱却 Atomic Design の問題点 •
コンポーネントの配置に悩む (特に Molecules or Organisms) • Atoms 以外で再利用性の高いコンポーネントは少ない • 実際に使用される場所から遠くに置かれて、どこから使用されているか分かりづらい
コンポーネント設計 ~ Colocation 依存関係が分かりやすくなった Atomic Design の Atoms 以外の大部分を使用するリソースと同じディレクトリに配置
Colocation: 関連するリソース同士を近くに置いておくという考え方
コンポーネント設計 ~ 多段階バケツリレー バケツリレー自体は悪いことではない (依存関係が分かりやすくなる) バケツリレー自体は悪いことではない (依存関係が分かりやすくなる)
– しかし複雑なUIではpropsを自身は使わないのに受け取るコンポーネントが現れることがある Bはpropsを自身で使用しないで子に流すだけ Bが親と子両方と密結合になってしまっている
コンポーネント設計 ~ コンポジションパターン Bが不要なpropsを受け取らなくなった Bの責務(レイアウト)が明確に Bがコンポーネントをpropsで受け取るように変更 【React】Context を使う前に #2 コンポジション
(ReactNode 型の Props) を使え https://qiita.com/honey32/items/4d04e454550fb1ed922c propsのバケツリレー対策でGlobal Stateを使うその前に... https://speakerdeck.com/taro28/propsnohaketuriredui-ce-teglobal-statewoshi-usonoqian-ni より詳しくは以下を参照
コンポーネント設計 ~ 試行錯誤 コンポーネント設計で考えることは多い 再レンダリング ディレクトリ構造 ビューとロジックの分離
コンポーネント粒度 コンポジション props設計 ユースケースに合わせて最適なアーキテクチャを考えていく必要がある state管理 CSS
純粋な関数への切り出し UIと関係ない複雑なロジックはReactから切り出して、純粋なTS関数とする 単体テストがやりやすい & 可読性の向上
複雑なロジックの例 • Firestore の データの詳細検索 ◦ Firestoreの検索はそこまで強くないのでTSで絞り込む必要がある。 •
グラフのnodeの変換ロジックをフロントが持つ ◦ フロントで node を繋げたりするので、nodeの型変換のロジックが必要 純粋関数を結構書く
ライブラリのちからを借りる ~ React Hook Form 管理画面には複雑なFormが多くある 自前で実装するのは大変 swap append
remove React Hook Form の便利なAPI useFieldArray • append • remove • swap 動的なフォームのサポート
ライブラリのちからを借りる ~ React flow フローチャートUIをサポート • Node, Edge のカスタマイズ性が高い •
高パフォーマンス • TSの型サポート
今後の展望 既存のリファクタ 新規プロダクト開発 コンポーネントの設計 Fetcher ライブラリの導入 Vite 移行
etc... 新機能の追加 完全新規プロダクト開発