音声データ解析パイプラインの Software Engineering / Context Engineering

mita data vol.3

Transcript

1. ⾳声データ解析パイプラインの Software Engineering / Context Engineering 2026/01/29 Hiroyuki Moriya
2. 2 東京⼤学で神経科学の研究に取り組む。DMMに て、データサイエンティストとしてデータ分析‧機 械学習に取り組む。その後、Microsoftにて MSN/BingのSWEとして牽引。 2024年にIVRy⼊社。現在はIVRy Analyticsという プロダクト開発を主導。 Hiroyuki Moriya AI engineer / SWE X @Yamori_ds ⾃⼰紹介
3. 世は⼤LLM時代 3
4. 何ができるようになったのか？ 4
5. ⾮構造化データを定量的に扱えるようになった 5
6. 今⽇のトピック： ⾳声から価値を産むための データ解析パイプライン 6
7. 7 今⽇のトピックを通してお伝えしたいこと • 「LLMを使ったプロダクト」がどんどん増えています。 • LLMの出現によって、プロダクトの可能性は⼤きく広がりました が、⼀⽅で、基礎的なエンジニアリング部分の重要性は増してい ます。 • 「LLM」という過渡的なシステムに依存したプロダクトを作る上 で、エンジニアリングが必要だという話をします。
8. 8 1. IVRy Analyticsについて 2. プロダクトの課題 3. 解決策 4. まとめ アジェンダ
9. IVRy Analytics 9
10. 対話型音声 AI SaaS 月額3,000円からカスタムAI電話をカンタンに作成できるサービス。 全ての電話業務を誰でもすぐにAIを使って効率化できます。 10
11. ダイヤルプッシュとAIの対話をハイブリッドで設定し、 受けたい電話と⾃動化したい電話を分類。電話業務を効率化できる 業態に合わせた自由な応答設定 11
12. 12 AIラベリング 通話データ AI解析指標 “コミュニケーションデータを 事業示唆に変換する SaaSプロダクト ” 定量化 分類
13. 音声という非構造化データを 定量的に解析・可視化できる 13
14. IVRy Analyticsのアーキテクチャ 14 S3 ECS BigQuery Codatum LLM batch処理 可視化
15. 15 1. IVRy Analyticsについて 2. プロダクトの課題 3. 解決策 4. まとめ アジェンダ
16. Software Engineering 16
17. 17 Software Engineering ソフトウェアを効率的‧スケールできる形で開発‧運⽤する技術全般
18. LLMがシステム上の ボトルネックになる Challenge Software Engineering⾯の難しさ 18
19. 19 再掲：アーキテクチャ Problem S3 ECS BigQuery LLM batch処理
20. 20 Challenge: LLMがシステム上のボトルネックになりがち Problem S3 ECS BigQuery LLM batch処理
21. 21 • LLM APIは⼤量のデータを処理することを想定してデザインされてない。 • LLM batch APIは、完了までの時間‧Storage制約などでハマらなかった。 • ⼀定間隔でtriggerされるbatch systemだと、その間に滞留する全通話を適 切に解析し終えることができなかった。 なぜLLMがシステム上のボトルネックになるのか？
22. スケールできる設計にする 22 Solution
23. 23 最初の対策：LLMのfallback S3 ECS BigQuery LLMs batch処理
24. 24 fallbackでもダメになってきた Problem S3 ECS BigQuery LLMs batch処理
25. 25 • fallbackを設定しても、単位時間あたりで捌ける通話には限界があった。 • 通話ごとに解析に使われるモデルが違ってしまうのも、それほど好ましくな いという話もある。 fallbackの限界
26. 26 対策：通話終了後の即時解析 S3 SQS/Lambda BigQuery LLMs 即時解析
27. 27 • 単位時間あたりのLLM APIへの負荷を軽減できるようになった。 • 仮に解析に失敗した場合は、定期実⾏のbatchを⽤意して、解析させるよう にした。 Lambdaによる、通話の即時解析
28. 28 • 今まで話した取り組みは、2025年前半に取り組んでいた内容。 • LLM APIの性能も進化しているので、今のアーキテクチャにこだわり続ける 必要もなくなってきた。 • その瞬間に最適なアーキテクチャを選択するエンジニアリング⼒と、LLM APIの進化に合わせて、そのアーキテクチャを捨てる覚悟が必要。 • エンジニアリング⼒がないと、コーディングエージェントの出⼒に盲⽬的に 従うことしかできなくなる。 しかし
29. Context Engineering 29
30. 30 Context Engineering LLMの出⼒を最適化するための⼿法全般 from 12-factor-agents
31. 改善が わかりづらい Challenge #1 安定した結果が 出ない Challenge #2 Context Engineering⾯の難しさ 31
32. 32 Challenge #1 Promptを変えても、改善がわかりづらい Problem • Promptを変更して、iterationを回すだけだ と、「なんとなく良くなった気がする」 • 雰囲気でPromptを書くことになりがち。
33. データセットを⽤意する 33 Solution
34. 評価データセットを⽤意して、実験を⾏う 34
35. Promptの機械的な改善のススメ 35 DSPy: GEPA AlphaEvolve • Prompt改善が⾯倒な場合は、評価セットを基準に機械的に改善するとラク
36. 36 Challenge #2 安定した結果が出ない Problem この通話は対応に 満⾜していますか？ LLM True / YES / そうです / はい … Prompt 出⼒ • LLMの出⼒に⾃由度があると、LLMをシステムに組み込む障壁になりがち
37. Structured Output 37 Solution
38. Structured outputによる結果の安定化 38 • LLM出⼒の構造化を強制することで、データパイプラインに組み込みやすく なる。
39. Prompt改善以外の⾊々なアプローチ (a.k.a. Context Engineering) も試す 39 • 世の中には、Prompt改善以外の⾊々なアプローチが考えられている • LLMの進化も早いので、昔は出来なかったアプローチも、今なら可能なこと がある（ex: Context⻑が改善） 例えば... • Contextに⼤量のデータを突っ込んでみる • LLMへのリクエストを複数回に分けてみる • LLMからコード実⾏させてみる
40. 40 まとめ: • LLM時代においても、基礎的なエンジニアリング⼒の重要性は変わらない ◦ 丁寧に作ることで、他社プロダクトとも差別化できるはず • ⼀⽅で、LLMの進化に伴って、仕組みが不要になる速度も増しているので、 プロダクト‧アーキテクチャを捨て続ける覚悟は必要
41. 41 We are Hiring!