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

LLMでIVRyのAI周りのソフトウェア開発がどう変化したか / How IVRy's sof...

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
Tweet

More Decks by Yuichiro Machida

Other Decks in Technology

Transcript

  1. ⾃⼰紹介 町⽥雄⼀郎 ~2015年 京都⼤学‧⼤学院で⾃然⾔語処理を研究。 ~2019年リクルートで飲⾷関連のアプリ‧WebのPMやデータ分析を担当。 ~2022年 エクサウィザーズでNLPエンジニア。チームリード 兼 EM ~現在

    株式会社IVRy ソフトウェアエンジニア / AIエンジニア 兼 EM 趣味: ボルダリング - 会社に壁を作ってあげると⾔われて⼊社しました(本当にできた)
  2. 営業時間の問い合わせは 1 お店までの道順は 2 忘れ物のお電話は 3 … IVRyは最短5分、⽉3,500円から電話業務を⾃動化/効率化することができます。⾃動応答や転送、 SMS返信などの機能に加えて、AIを活⽤した⾳声の要約や認識/対話まで多様な機能を提供しています。 お客様

    貴社 24時間 IVRyが応対 貴社に電話 SMS送信 ⾳声案内 留守番電話で録⾳ SMSでURL送信 ⾳声で⾃動応答 録⾳を⾃動で促す 転送して 従業員が対応 and more… 1. 問い合わせフォーム作成やCRM機能 2. 録⾳した⾳声のAIによる要約機能 3. AI⾳声での対話形式での回答 など、多様な機能をご提供しています。 IVRyについて
  3. ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU

    対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 モデル開発だけで数ヶ⽉ or ルールベースの闇へ ※白いところが AIモデル関連作業
  4. ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU

    対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 動く対話システムを構築するだけで⼀苦労 コード変更の敷居も⾼い ※白いところが AIモデル関連作業
  5. ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU

    対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 3. 全体を理解できる⼈がほぼいない メンテできず消えていく ※白いところが AIモデル関連作業
  6. ちょっと前まで対話システムの開発は⾮常に重かった AIモデル設計 データ収集 アノテーション 前処理 モデル学習 評価 発話 音声認識 NLU

    対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類 タスク実行 外部リクエスト DB更新 1. AIモデルが複数必要で開発が⼤変 2. 対話制御がとにかく複雑でバグの温床 3. 全体を理解できる⼈がほぼいない 精度以前にサービスとして 安定したものをつくれるのかが課題 ※白いところが AIモデル関連作業
  7. LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類

    タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 ⼀般的な質問であればほぼ 正しく理解できる
  8. LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類

    タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 バグの温床だったところが消え コードが⼀気にシンプルに
  9. LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類

    タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 3. 対話UXの改善に集中できる 多様なケースをたくさん 検証できるように
  10. LLMで驚くほどシンプルになった 発話 音声認識 NLU 対話状態管理 音声合成 発話文生成 更新処理 固有表現認識 意図分類

    タスク実行 外部リクエスト DB更新 LLMベースの対話処理 1. 個別AIモデル開発がほぼ不要 2. ⼀番複雑だった対話制御も簡略化 3. 対話UXの改善に集中できる 幅広いタスクをいかに⾼速に 検証できるかが課題 → ソフトウェアエンジニアリングスキル がより重要に
  11. 開発速度は⼤体2倍くらい LLM版のデモが完成。 他社提供開始 9⽉ 2⽉ 3⽉ 独⾃モデルでの開発を開始 4⽉ 6⽉ 10⽉

    LLM版の開発開始 レストラン予約のデモが完成 ChatGPTのAPIが公開される。 作ったものを即捨てる。 独⾃モデルは公開できるデモの完成までに約半年 LLMだと同等レベルのデモまで約3ヶ⽉
  12. (IVRyの考える) LLM Ops LLMで新たに発⽣する課題 1. ハルシネーション 2. プロンプトインジェクション 3. レスポンスの遅延

    4. OpenAIが落ちる あるタイミングでのopenaiのstatus 1. 勝⼿に予約を取る 2. 提供していないメニューを教える
  13. IVRyの考えるLLM安定化の試み APP main LLM パフォーマンス監視 OpenAIをはじめ、各LLMはまだ不安定。以下を計測。 1. Health Check -

    LLMの停⽌ = サービスの停⽌のリスク 2. Latencyの監視 - 極端に遅くなることがある。(対話システムだと致命的) - レスポンスをキャッシュするなどの⼯夫も必要。 他のLLMでバックアップ AWS Bedrockなどの代替の選択肢を用意。 1. プロンプトの調整 - LLMによってプロンプトの書き方が異なるので、事前に調整しておく backup LLM
  14. IVRyの組織体制 IVRyでは3ヶ⽉毎に変わるプロジェクト制を採⽤。 会社として部署というものがありません。 プロジェクト制の狙い - 変化に適応しやすい - 会社としての取り組み優先度を3ヶ⽉スパンで強制実施 - 検証したい仮説毎に適切なメンバー構成は変わる

    - LLM中⼼の新規プロダクトの価値検証をしたい - PoC⾼速検証が得意なメンバ構成 - 新しい有料機能を追加するための開発をしたい - データモデル設計から実運⽤まで⾒据えて⼿堅 く推進できるメンバ構成 - (失敗してもすぐに⽴て直せる) ある時期のプロジェクト構成 現在のプロジェクト構成
  15. プロダクト開発をドライブする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
  16. ⾃分のこの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エンジニアだからではなく、その時会社にとって何が重要なのか、それに 対して自分は何ができるかで役割が決まります
  17. おわりに - IVRyはLLM全振りの開発フローにすることで、たくさんの仮説を検証するこ とが新たな⽬標となった - サービスとして安定してLLMを利⽤するための⼯夫が必要になった - 組織も変化に対応できるようにしなければならない We are

    hiring! IVRyは全職種で絶賛採⽤中です - LLMを使い倒すプロダクトに関わってみたい - SWEという考えにとらわれず働いてみたい - オフィスでボルダリングしたい 是⾮ご応募ください!