Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
LLMでIVRyのAI周りのソフトウェア開発がどう変化したか / How IVRy's sof...
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
Yuichiro Machida
December 05, 2023
Technology
820
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
LLMでIVRyのAI周りのソフトウェア開発がどう変化したか / How IVRy's software engineering was changed after LLM
2023/12/5 機械学習に隣接するソフトウェアエンジニアリングの魅力(
https://layerx.connpass.com/event/301128/)での発表資料
Yuichiro Machida
December 05, 2023
More Decks by Yuichiro Machida
See All by Yuichiro Machida
実運用で学んだ 音声対話システムの評価とテスト
ymachida
1
150
累計2500万着電を支える大規模 電話自動応答サービスのアーキテクチャ / Architecture of a Large-Scale Automated Phone Response Service Supporting 25 Million Cumulative Calls
ymachida
10
11k
Other Decks in Technology
See All in Technology
AI時代のAPI開発を加速する品質ガードレール / API Quality Guardrails in the AI Era
yokawasa
0
140
React Nativeでの OTA Updateって、 どう説明する?
ichiki1023
0
150
IoTデバイスを繋げるプロトコルMatterをAndroidで使用する方法
harutiro
0
120
MCPゲートウェイを作って運用してわかったこと — Agent時代の権限管理の現在地
mtpooh
10
3.1k
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
590
ミイダス株式会社 テックチームのご紹介 / MIIDAS Tech Team
miidas
0
150
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
330
AI Made Us Faster at Solving the Wrong Problems
marceloancelmo
0
160
オブザーバビリティを高める AI エージェント体験を考える / Designing AI Agent Experiences That Enhance Observability
aoto
PRO
2
300
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
280
全社共通データ基盤をつくる。ソニーのDatabricks活用とデータガバナンス設計の裏側
sony
0
420
検証フェーズはAIの回答を判断するための学習機会
toru_kubota
2
500
Featured
See All Featured
Testing 201, or: Great Expectations
jmmastey
46
8.3k
How to build an LLM SEO readiness audit: a practical framework
nmsamuel
2
930
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
194
17k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
58k
The Limits of Empathy - UXLibs8
cassininazir
1
700
Building Experiences: Design Systems, User Experience, and Full Site Editing
marktimemedia
1
620
How to audit for AI Accessibility on your Front & Back End
davetheseo
0
570
Odyssey Design
rkendrick25
PRO
2
860
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
450
The Cult of Friendly URLs
andyhume
79
7k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
1k
Transcript
LLMでIVRyのAI周りの ソフトウェア開発が どう変化したか
⾃⼰紹介 町⽥雄⼀郎 ~2015年 京都⼤学‧⼤学院で⾃然⾔語処理を研究。 ~2019年リクルートで飲⾷関連のアプリ‧WebのPMやデータ分析を担当。 ~2022年 エクサウィザーズでNLPエンジニア。チームリード 兼 EM ~現在
株式会社IVRy ソフトウェアエンジニア / AIエンジニア 兼 EM 趣味: ボルダリング - 会社に壁を作ってあげると⾔われて⼊社しました(本当にできた)
今⽇の話 以下の内容についてお話します - IVRyでは⾳声認識ベースの次世代のAI電話を開発中 - 以前から開発していたが、LLMの登場で作り直した - LLMを中⼼に据えることで - これまでのAIモデルベースの開発が⼤きく変わり
- 新しくLLMの安定化が必要になりました - IVRyの考える、変化に素早く適応するための開発組織構造もご紹介
営業時間の問い合わせは 1 お店までの道順は 2 忘れ物のお電話は 3 … IVRyは最短5分、⽉3,500円から電話業務を⾃動化/効率化することができます。⾃動応答や転送、 SMS返信などの機能に加えて、AIを活⽤した⾳声の要約や認識/対話まで多様な機能を提供しています。 お客様
貴社 24時間 IVRyが応対 貴社に電話 SMS送信 ⾳声案内 留守番電話で録⾳ SMSでURL送信 ⾳声で⾃動応答 録⾳を⾃動で促す 転送して 従業員が対応 and more… 1. 問い合わせフォーム作成やCRM機能 2. 録⾳した⾳声のAIによる要約機能 3. AI⾳声での対話形式での回答 など、多様な機能をご提供しています。 IVRyについて
電話⾃動応答SaaSの開発 - ⾃動応答ロジック - 発着信処理 - 設定‧管理画⾯ - ⾃動応答ルール設定 -
通話履歴 - 書き起こし‧要約 - 電話帳 …
1. LLMで対話システムの開発がどれくらい加速したか
LLMを中⼼にした⾃動応答を作りました 体験デモ番号: 050-1808-7048
ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU
対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 モデル開発だけで数ヶ⽉ or ルールベースの闇へ ※白いところが AIモデル関連作業
ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU
対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 動く対話システムを構築するだけで⼀苦労 コード変更の敷居も⾼い ※白いところが AIモデル関連作業
ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU
対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 3. 全体を理解できる⼈がほぼいない メンテできず消えていく ※白いところが AIモデル関連作業
ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU
対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 3. 全体を理解できる⼈がほぼいない 精度以前にサービスとして 安定したものをつくれるのかが課題 ※白いところが AIモデル関連作業
LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類
タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 ⼀般的な質問であればほぼ 正しく理解できる
LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類
タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 バグの温床だったところが消え コードが⼀気にシンプルに
LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類
タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 3. 対話UXの改善に集中できる 多様なケースをたくさん 検証できるように
LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類
タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 3. 対話UXの改善に集中できる 幅広いタスクをいかに⾼速に 検証できるかが課題 → ソフトウェアエンジニアリングスキル がより重要に
開発速度は⼤体2倍くらい LLM版のデモが完成。 他社提供開始 9⽉ 2⽉ 3⽉ 独⾃モデルでの開発を開始 4⽉ 6⽉ 10⽉
LLM版の開発開始 レストラン予約のデモが完成 ChatGPTのAPIが公開される。 作ったものを即捨てる。 独⾃モデルは公開できるデモの完成までに約半年 LLMだと同等レベルのデモまで約3ヶ⽉
1. ハルシネーション 2. プロンプトインジェクション 3. レスポンスの遅延 4. OpenAIが落ちる LLMで新たに発⽣する課題 1.
勝⼿に予約を取る 2. 提供していないメニューを教える
(IVRyの考える) LLM Ops LLMで新たに発⽣する課題 1. ハルシネーション 2. プロンプトインジェクション 3. レスポンスの遅延
4. OpenAIが落ちる あるタイミングでのopenaiのstatus 1. 勝⼿に予約を取る 2. 提供していないメニューを教える
1. ハルシネーション 2. プロンプトインジェクション 3. レスポンスの遅延 4. OpenAIが落ちる LLM安定化 LLMで新たに発⽣する課題
仕組みで担保 ブログ記事etcを御覧ください
IVRyの考えるLLM安定化の試み APP main LLM パフォーマンス監視 OpenAIをはじめ、各LLMはまだ不安定。以下を計測。 1. Health Check -
LLMの停⽌ = サービスの停⽌のリスク 2. Latencyの監視 - 極端に遅くなることがある。(対話システムだと致命的) - レスポンスをキャッシュするなどの⼯夫も必要。 他のLLMでバックアップ AWS Bedrockなどの代替の選択肢を用意。 1. プロンプトの調整 - LLMによってプロンプトの書き方が異なるので、事前に調整しておく backup LLM
2. ⾼速検証のためのIVRyの組織体制について
IVRyの組織体制 IVRyでは3ヶ⽉毎に変わるプロジェクト制を採⽤。 会社として部署というものがありません。 プロジェクト制の狙い - 変化に適応しやすい - 会社としての取り組み優先度を3ヶ⽉スパンで強制実施 - 検証したい仮説毎に適切なメンバー構成は変わる
- LLM中⼼の新規プロダクトの価値検証をしたい - PoC⾼速検証が得意なメンバ構成 - 新しい有料機能を追加するための開発をしたい - データモデル設計から実運⽤まで⾒据えて⼿堅 く推進できるメンバ構成 - (失敗してもすぐに⽴て直せる) ある時期のプロジェクト構成 現在のプロジェクト構成
プロダクト開発をドライブする2つのサイクル Project Sprint サイクル 3ヶ⽉ 1週間 開始時に決める こと 会社としてこの期間に注⼒すること、 しないこと
スプリント中にどのPJの案件をやるか オーナー Project Owner (職能はまちまち) PdM+EM (単⼀のScrum POは不在) メンバ Sales/Mkt/Product等の各職能 Product系 PdM/エンジニア/デザイナ 指標 OKR Velocity, 4keys(未整備) リリース後の事業数値 https://speakerdeck.com/yrhorita/ivrys-product-development
⾃分のこの1年 1Q: 主要機能の⼤きめプロジェクト - PdM + PM + SWE 8名
2Q: LLM全振りの次世代電話のデモ作成プロジェクト - CEO + PdM + SWE/AIE 2名 3Q: 次世代電話の他社連携機能開発プロジェクト - PdM + SWE/AIE 2名 + QAE 4Q: 次世代電話と既存機能の統合プロジェクト - PdM + SWE 2名 + QAE CEOもどこかの プロジェクトにいたりします ここはAIE / SWE兼務 このときはSWEとして参加 ここはSWE要素強め X部のYエンジニアだからではなく、その時会社にとって何が重要なのか、それに 対して自分は何ができるかで役割が決まります
おわりに - IVRyはLLM全振りの開発フローにすることで、たくさんの仮説を検証するこ とが新たな⽬標となった - サービスとして安定してLLMを利⽤するための⼯夫が必要になった - 組織も変化に対応できるようにしなければならない We are
hiring! IVRyは全職種で絶賛採⽤中です - LLMを使い倒すプロダクトに関わってみたい - SWEという考えにとらわれず働いてみたい - オフィスでボルダリングしたい 是⾮ご応募ください!