対話型音声AIアプリケーションの信頼性向上の取り組み

Transcript

1. ~ Webアプリケーション以外でどうSREを実践するのか ~ 対話型⾳声AIアプリケーションの 信頼性向上の取り組み 2025/07/11

2. LLMを組み込むと、最⾼のプロダクトが作れる！ 2

3. LLMを組み込むと、最⾼のプロダクトが作れる！ 3

4. LLM APIを利⽤した 対話アプリケーション運⽤の 取り組み 4

5. 5 LLM APIのプロダクトへの組み込み LLM APIの監視・運用 Hiroyuki Moriya AI engineer /

   SRE ⾃⼰紹介

6. 6 SRE NEXT 2025 Co-Chair 好きなWebSocketのCloseEventコード: 1005 Ryuichi Watanabe SRE

   ⾃⼰紹介

7. 7 1. IVRyについて 2. LLM API 3. WebSocket 4. まとめ

   アジェンダ

8. IVRyについて 8

9. confidential 会社紹介 9 会社名 代表取締役 事業内容 住所 資本⾦等 設⽴年⽉ 株式会社IVRy（アイブリー）

   奥⻄ 亮賀（Ryoga Okunishi） クラウド型AI電話SaaS（アイブリー）の運営 〒108-0073東京都港区三⽥三丁⽬5-19 住友不動産東京三⽥ガーデンタワー10F 46.1億円（準備⾦含む） 2019年3⽉

10. 10 電話⾃動応答サービス プロダクト

11. 11 システムアーキテクチャ

12. 12 システムアーキテクチャ

13. 13 システムアーキテクチャ

14. IVRyの技術スタック 14

15. 電話は今でも最重要連絡⼿段 15

16. 16 あらゆる業種‧企業規模のお客様に導⼊

17. 対話型AIアプリケーションの難しさ LLM APIの プロダクト運用 Challenge #1 WebSocketの プロダクト運用 Challenge #2

    17

18. LLM API part 18

19. ハルシネーションの 抑制 Challenge #1 LLM APIの安定運用 Challenge #2 LLM APIを本番運⽤する難しさ

    19

20. ハルシネーションの抑制 20

21. 21 LLMはハルシネーションする Problem

22. 困難は分割せよ 22 Solution

23. AI workflowによる実装 23 1つのタスクを複数のLLM componentで分割して処理する → validation‧error分析が⾏えるようになり、安定した結果を出⼒できる

24. 確認を怠らない 24 Solution

25. ⾃動 電話 e2e test 25

26. 26

27. 27

28. 28

29. 29 Merge code Deploy latest code Execute automated phone E2E

    tests Monitor on Datadog LLM Observability 電話 e2e testをコードマージ時に 実⾏させる

30. 30 Datadog LLM Observability による監視

31. LLM APIの安定運⽤ 31

32. システム障害は多くの影響を引き起こす 32 Problem

33. LLM APIは不安定である 33 LLM API Status in one day

34. 完璧を求めない 34 Solution

35. 35 Fast, stable, and cheap Slower, more $$$ Stability &

    performance > latest models 自分たちのユースケースに合っ たモデル選定をする。

36. システム監視を怠らない 36 Solution

37. 37 Datadog Inferred Servicesによる 外部通信の監視

38. 38 Inferred serviceを通して、多くのmetricsを監視できる

39. 最悪の事態に備える 39 Solution

40. 40 複数のLLM APIを利用して、 fallbackシステムを実装する LLM fallback strategy

41. 困難は分割せよ / 確認を怠らない 01 ハルシネーションの抑制 完璧を求めない / システム監視を怠らない 02 会話を自然な速度にするために

    最悪の事態に備える 03 障害への対策 まとめ： LLMをプロダクト 運⽤するために 41

42. WebSocketプロダクト運⽤ 42

43. なぜ突然WebSocket？ 43

44. 44 Simplified system architecture

45. 45 Simplified system architecture

46. WebSocketの特徴 46

47. WebSocketの特徴 • RFC6445 で定義されている • 双⽅向通信‧全⼆重通信 ◦ クライアントとサーバーの両⽅が同時にデータを送受信可能 ◦ HTTPとは異なり、リクエスト‧レスポンスの概念がない

    • 接続を⼀度確⽴したあとは、明⽰的に切断されるまで維持される ◦ HTTPのように毎回接続を確⽴するオーバーヘッドがない • GitHub Actionsのログをリアルタイムでみれたり 47

48. • ハンドシェイク (HTTPアップグレードリクエスト) • WebSocket接続の確⽴ • データフレームの送受信 • WebSocketの切断 WebSocketの通信フロー

    48

49. ハンドシェイクはHTTP通信によって⾏われる 49

50. 50

51. なぜWebSocketを使うのか 51

52. なぜWebSocketなのか • 低遅延性 ◦ 発話から応答までの遅延がユーザー体験に影響する ◦ 数百ミリ秒の遅延でも会話のテンポが損なわれ、不⾃然に感じられる • 効率的なデータ転送 ◦

    HTTP通信はやり取り毎に100byte以上のリクエストヘッダーがつく ◦ WebSocketの場合は数byte程度 52

53. WebSocketを使ったアプリ運⽤の難しさ 安全なデプロイの難しさ 53

54. 安全なデプロイ(課題) • デプロイのたびに⼀部の通話がエラーとなっていた • Graceful shutdownは設定されていた • なぜ？？ 54

55. わかっていたことと調査 • エラーログが出ているわけでもなく原因は不明 • 終了処理中のメトリクスを⾒れるようにしたりトレースを⼊れることで落ちてい る箇所を特定する⽅針にしたが原因は不明だった 55

56. 横断的分析 56 Solution

57. ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ • アプリケーションの問題ではなかった • StopTimeoutは120秒が最⼤値 • 1通話の最⼤時間がその時間を⼤きく超えて正常に終了できていなかった •

    drainの時間を伸ばすことで通話の最⼤時間内に強制終了しないようにする 57

58. ALB -> ECS構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 58

59. ALB -> ELB構成におけるデプロイで何が起きるのかの把握不⾜ https://aws.amazon.com/jp/blogs/news/graceful-shutdowns-with-ecs/ 59

60. WebSocketでもHTTPでも、調査アプローチは同じ • アプリケーションの運⽤で気を付けることに違いはある • プロトコルを理解するために使っているライブラリを読んだりする必要はある • トレース‧メトリクスの導⼊、o11yの改善やデバッグのノウハウを貯めるな ど、信頼性を⾼めるためにやることは⼤きく変わらない 60

61. ⾳声対話システムのSLI/SLO 61

62. ⾳声対話システムの「信頼性」が低いと？ • 「すみません、よく聞こえませんでした」を繰り返される • 話しかけて数秒経って返事がくる • 全く関係ない内容の返答が返ってきたり • 機能的には良くても、ユーザーはフラストレーションを抱える 62

63. 信頼性に向き合う必要がある • 漠然と「もっと良くしよう」と考えるのではなく、何を、どれくらい良くするの かを明確にする • 信頼性を客観的に評価し、改善していくためにSLI/SLO • SREのノウハウ ◦ CUJを⾒つけ信頼性の指標となるものを決める

    ◦ 「ページの表⽰速度がX秒以内」「エラーコード5xxの発⽣率がY%未満」 63

64. ⾳声対話システムでSLI/SLOを扱う難しさ • ユーザー体験が定量化しづらい ◦ ユーザーの体験は「ちゃんと会話できたか」という主観的なもの ◦ HTTPレスポンスのように明確な成功/失敗が定義しづらい • 会話失敗の原因が複雑 ◦

    インフラ、LLMの応答ミス、⾳声認識の精度低下 • Webと異なりセッションベースでの設計が必要 ◦ Webのように1リクエスト=1トランザクションではない 64

65. ユーザーに届けたいものを再考する 65 Solution

66. Webアプリケーション共通のノウハウ • ユーザーの「⽬的達成」を最上位のSLOとする • 最も重要なのは、ユーザーがシステムを通して⾃⾝の⽬的を達成できること • ユーザー体験に紐づくSLI/SLOを「解釈層ごと」に切り出すことで計測可能性を ⾼める • 「⽬的達成」を阻害する要因を考えていく

    ◦ ⼤きく分けて⼆つの種類がある 66

67. システムエラー‧対話のエラー、両⾯から考える システム的 Anomaly 対話的Anomaly 67

68. なぜ分類するのか • ユーザー体験の複合的理解 ◦ ユーザー体験がシステム要因と対話要因のどちらに、どれだけ影響されてい るか理解できる ◦ ユーザーからの「使いにくい」というフィードバックが、実はシステムの応 答が遅いからなのか、それとも会話がうまく成⽴しないからなのかを、デー タに基づいて判断できるようになる

    68

69. システム的Anomaly • いわゆるインフラ層の失敗を指している ◦ アプリケーションの計算量による遅延、DBの性能が上限 ◦ LLM/⾳声合成の応答遅延/失敗数 • ⼀⽅で、「LLMが返してきた内容が意味不明だった」などの対話品質は、こ の層だけでは捉えられない

    69

70. 対話的Anomaly • ユーザーの主観的な体験に直結する対話の失敗 • 「話が通じなかった」「変な返事をされた」「⽂脈が⾶んだ」など • システム的には「成功」と⾒えるが、UXとしては失敗 • この値をトラッキングすることによってユーザーの「⽬的達成率」を追える 70

71. まとめ 71

72. まとめ • システム特性を理解し、可観測性を⾼め、安定性を担保 ◦ ユーザーの⽬的達成を最優先にした信頼性向上 ◦ 不安定なLLMに依存しながらも、ユーザー体験を守る設計と運⽤ ◦ システム的 Anomaly∕対話的

    Anomaly を切り分け、SLI/SLO を設計 • 新しい技術スタックでも、SRE の基本は変わらない 72

73. ブースやってます！ 73

74. 採⽤してます！ 74

75. ご清聴ありがとうございました 75