Recommandé
Contenu connexe
Similaire à BEDOREにおける対話エンジンの開発と運用
Similaire à BEDOREにおける対話エンジンの開発と運用 (20)
BEDOREにおける対話エンジンの開発と運用
- 3. 目次 • 自己紹介 • BEDOREの会社紹介 • BEDOREにおける職種・組織について • BEDOREプロダクトの概要 • BEDOREにおける機械学習 • BEDOREを運用する上で遭遇した課題と対処法 • 今後の展望 3
- 4. 自己紹介 • 氏名 – Nasuka Sumino – @naohachi89(NSK) at Twitter • 所属 – アルゴリズムエンジニア & ソフトウェアエンジニア at BEDORE (2017/10 - 現在) • キャリア – プライバシ保護データマイニングの研究 at 大学院 (2013/4 - 2015/3) – 機械学習エンジニア atリクルートジョブズ(2015/4 - 2017/10) 4
- 5. BEDORE(会社)の概要 • 自然言語処理領域でプロダクト・ソリューションを提供する事業会社 • プロダクト事業では後に紹介するSaaSの対話エンジンを開発・提供 • ソリューション事業ではプロジェクト的にコンサル・分析・開発を実施 • 2016年に親会社のPKSHA Technologyからスピンアウトして創業 – 自然言語処理に関連する領域をBEDOREが担い、動画解析や最適化等の他の 領域をPKSHAが担当 5
- 7. BEDOREにおける職種・組織について ソフトウェアエンジニア(SE) アルゴリズムエンジニア (AE) プロダクトチーム ソリューションチーム 継続的なプロダクトの機能 開発・運用 機械学習モデルの改善 技術調査 テクニカルセールス モデリング R&D 新規プロダクト・APIの開 発 • ソフトウェアエンジニア・アルゴリズムエンジニアの2種類の職種が存在 • プロダクト・ソリューションでチームが分かれており、各エンジニアの役割もチームに よって異なる 7
- 8. BEDOREにおける機械学習エンジニア ソフトウェアエンジニア(SE) アルゴリズムエンジニア (AE) プロダクトチーム ソリューションチーム 継続的なプロダクトの機能 開発・運用 機械学習モデルの改善 技術調査 テクニカルセールス モデリング R&D 新規プロダクト・APIの開 発 • ソフトウェアエンジニア・アルゴリズムエンジニアの2種類の職種が存在 • プロダクト・ソリューションでチームが分かれており、各エンジニアの役割もチームに よって異なる 8 機械学習エンジニア@MLSE?
- 10. BEDORE(プロダクト)の概要 • BtoB( toC) で提供しているSaaS型の対話エンジン – BEDOREは社名であると同時にプロダクトの名称 • 主に問い合わせ対応などに利用 • 2016年のリリースから現在まで数多くの企業に導入 10
- 11. BEDORE(プロダクト)のシステム概要 • コンテンツを登録するダッシュボード + 対話APIで構成 • ダッシュボードからクライアント企業の担当者がFAQデータ(後述)を登録 • 登録されたデータで機械学習モデルを学習 • エンドユーザーからの質問に対して、機械学習モデルで回答を選択 • 全てのクライアント企業の機械学習モデルを1プロダクトで管理 client userend user 対話API ダッシュボード メッセージアプリ メッセージ 機械学習 モデル FAQ 回答 11
- 13. BEDOREにおける機械学習 質問例 回答 クラス ログインパスワードを忘れた パスワードの再発行はこちらから行ってくださ い ~~~~ 0 ログインパスを再発行したい パスワードの再発行はこちらから行ってくださ い ~~~~ 0 BEDOREのマニュアルはどこ？ マニュアルはこちらにあります https:~~~~ 1 BEDOREの利用料はいくら？ 利用料はXXX円になります 2 … ... ... • FAQは質問例と回答の対で構成され、これを機械学習の訓練データとして利用 • 回答の種類をクラスとして、ユーザーからのメッセージに対する回答の選択をマ ルチクラス分類問題として解いている BEDOREにおけるFAQの例 13
- 14. 対話エージェントの継続的な学習について • クライアント企業が保持するFAQ等のデータを元に初期設定・チューニングを行い、 対話エージェント(=機械学習モデルを使って返答するエージェント)をリリースする • リリース後は初期FAQでは想定されていないような質問が来るため、そうした質問に 対応するにはリリース後の継続的な運用(=訓練データの整備と再学習)が必要とな る • BEDOREではクライアント企業の対話エージェント運用担当者が任意のタイミングで ダッシュボードから学習を実施できる 初期設定・ チューニング 運用 (データ追加・再学習) 14 リリース
- 15. 学習を行うアーキテクチャーと学習フロー 15 メッセージ アプリ ダッシュボード client user end user 対話API 学習サーバーメッセージ 回答 ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 16. 学習を行うアーキテクチャーと学習フロー 16 以下の流れで学習を実施 メッセージ アプリ ダッシュボード client user end user 対話API 1.学習のリクエスト 学習サーバーメッセージ 回答 ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 17. 学習を行うアーキテクチャーと学習フロー 17 以下の流れで学習を実施 メッセージ アプリ ダッシュボード client user end user 対話API 1.学習のリクエスト 2.学習サーバー 起動 学習サーバーメッセージ 回答 ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 18. 学習を行うアーキテクチャーと学習フロー 18 以下の流れで学習を実施 メッセージ アプリ ダッシュボード client user end user 対話API 1.学習のリクエスト 2.学習サーバー 起動 学習サーバー 3.ソースの clone・学習 メッセージ 回答 ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 19. 学習を行うアーキテクチャーと学習フロー 19 以下の流れで学習を実施 メッセージ アプリ ダッシュボード client user end user 対話API 1.学習のリクエスト 2.学習サーバー 起動 学習サーバー 3.ソースの clone・学習 メッセージ 回答 4. 学習済みモデルのアップロード ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 20. 学習を行うアーキテクチャーと学習フロー 20 以下の流れで学習を実施 メッセージ アプリ ダッシュボード client user end user 対話API 1.学習のリクエスト 2.学習サーバー 起動 学習サーバー 3.ソースの clone・学習 メッセージ 回答 4. 学習済みモデルのアップロード 5. 学習済みモデルの ダウンロード ● 対話API ○ 機械学習モデルを用いて 返答を選択(=推論)するAPI ○ 常時起動 ● 学習サーバー ○ モデルの学習を実施するサー バー ○ リクエストに応じて起動
- 21. 機械学習的システム的なBEDOREの特徴まとめ 21 • BtoB( toC ) で提供 • 機械学習ドリブンなプロダクト – 機械学習モデルなしにプロダクトが成立しない • 継続的な学習が必要 • 任意のタイミングで学習が実施されうる • 全てのクライアントの機械学習モデルを1プロダクトで管理している
- 22. 機械学習的システム的なBEDOREの特徴まとめ 22 • BtoB( toC ) で提供 • 機械学習ドリブンなプロダクト – 機械学習モデルが機能しない • 継続的な学習が必要 • 任意のタイミングで学習が実施されうる • 全てのクライアントの機械学習モデルを1プロダクトで管理している プロダクトを運用する中で遭遇した、 これらの特徴に関連する課題と対策についてお話しします
- 24. 課題一覧 課題1. モデルの予測性能が突然急激に低下する問題 課題2. 互換性の欠如によるエラーの発生 課題3. デプロイに時間がかかる問題 課題4. 学習に異常に時間がかかる問題 24
- 26. 課題: モデルの予測性能がある日突然低下し、調査に時間を要した • あるクライアントでモデルの予測性能がある日突然急激に低下した • 学習時に指標を保存していなかった・訓練データセットの保存を行っていなかった為 に原因究明に時間を要した • 予測性能が急激に下がることは稀だが、モデルの予測結果に関する問い合わせは それなりの頻度で発生するため対応に日常的に工数がかかっていた 26
- 27. 対策: 学習時の状況を保存し、調査を容易にした • 訓練データのスナップショットを保存しておき、学習を再現できるようにした • 正解率や訓練データ数・クラス数などを学習毎に保存するようにした – 著しく予測性能が下がった場合はSlackにアラートを投げる – 保存した情報はアラートを投げる為だけでなく分析にも役立つ • 例: FAQの分類クラス数が増えたため精度が下がっている、といったことが 一目で分かる • モデルが間違えた事例について学習毎に分析用のログを出力するようにした – 予測されたFAQ・正しいFAQに関する質問例や回答、予測確率を出力 – モデルの分類が間違っている原因の分析や、FAQの構成の見直しに利用 27
- 29. BEDOREにおけるソースコードの互換性について • BEDOREでは対話APIサーバー(=推論サーバー)のソースとモデル学 習のソースを1レポジトリで管理している • 両者のバージョンが整合している場合は問題ないがバージョンが整合 せず、且つ実装に互換性がないとエラーが発生する 29 モデル学習時のソースが 新しい モデル学習時のソースが 古い 推論時のソースが新 しい 問題なし (後方)互換性がないとエラー が発生 推論時のソースが古 い (前方)互換性がないとエラー が発生 問題なし
- 30. 課題2-1: 後方互換性の欠如によるエラーの発生 • BEDOREでは全ての対話エージェントの機械学習モデルを全ての対話APIサーバー にロードしている • 対話エージェントごとに学習日時は異なるため、過去全てのバージョンのソースで学 習されたモデルを最新の対話APIにロードできる必要がある • BEDOREでは機械学習の前処理等を担うオブジェクトと機械学習モデル(以後纏めて ML Modelと呼ぶ)を学習毎にシリアライズしているが、 – ML Modelのclassのpropertyがリネームされたりclassの置き場が変わると ロード時にエラーが発生する 30 - 企業AのML Model(2019/1/28に学習) - 企業BのML Model(2018/1/28に学習) - 企業CのML Model(2017/1/28に学習) - … 対話APIサーバー
- 31. 対策: CIによる後方互換性の担保 • 後方互換性が保たれているかを検証するテストをCIで実施し、エラーを未然に防ぐよ うにした • 検証方法 – ML ModelをS3からダウンロード – ダウンロード後に以下の項目を検証 • 新しいソースコードでML Modelをロードできるか • モデルの予測時にエラーが発生しないか 31
- 32. 課題2-2: 前方互換性の欠如によるエラーの発生 • BEDOREでは学習サーバーは常に最新のリリースブランチからコードを取得し、学習 を行う • 一方で、対話APIサーバーではリリースブランチにmergeをしてからデプロイ作業を 行う • そのため、mergeしてからデプロイを実施するまでの間にクライアントの運用担当が モデルを学習させると、新しいコードで学習したモデルが古いコードのAPIサーバー に配布されてしまう • このケースでも、互換性を担保するように実装していないと前述のパターンと同様に ML Modelのロード時にエラーが発生する 32
- 33. 対策: CIによる前方互換性の担保 • 前方互換性が保たれているかを検証するテストをCIで実施し、エラーを未然に防ぐよ うにした • 検証方法 – 新しいコードで学習を実施してML Modelをシリアライズ – 現行のリリースブランチのコードでシリアライズしたML Modelを正常にロード し、予測できるかを検証 33
- 34. 課題2-3: ライブラリのバージョンが上げられない • 開発やモデル改善のためにライブラリのバージョンを上げたい • 一方で無闇にバージョンを上げると互換性の問題でエラーが発生する – 実装に互換性があるか否かはCIでデプロイ前に検知できるようになった – しかし、CIでは互換性がないことは検知できても問題の解決には至らない • ライブラリのバージョンを上げるにはデプロイのタイミングで新しいソースコードで学 習を実施しなければならないが、事前の確認なく弊社都合で学習を実施するのは好 ましくない 34
- 35. 対策: SLAの更新 • 製品のアップデート時に自動で学習が行われる場合がある旨をSLAに追加 • SLAの更新によってデプロイ時に予め新しいソースコードで学習を実施し、 機械学習モデルと対話APIのバージョンを整合させることが可能になった • BtoBの機械学習システムにおいてはシステム提供側がモデルを学習出来るような SLAにしておくことは非常に重要 – モデルを学習できないとレガシーなコードが残り続けて開発効率が下がり、モデ ルの性能改善も難しくなる 35
- 40. デプロイの流れ 製品のアップデートは週次で実施しており、以下の手順でデプロイを実行している 対話API(New) 対話API(Old) 1. EC2を起動しソースをclone 2. 全エージェントのモデルをS3 からsync 3. 立ち上げたEC2をELBにつける 40
- 41. デプロイの流れ 製品のアップデートは週次で実施しており、以下の手順でデプロイを実行している 対話API(New) 対話API(Old) 1. EC2を起動しソースをclone 2. 全エージェントのモデルをS3 からsync 3. 立ち上げたEC2をELBにつける 4. 古いEC2をELBから切り離す 41
- 42. デプロイの流れ 製品のアップデートは週次で実施しており、以下の手順でデプロイを実行している 対話API(New) 対話API(Old) 1. EC2を起動しソースをclone 2. 全エージェントのモデルをS3から sync 3. 立ち上げたEC2をELBにつける 4. 古いEC2をELBから切り離す 42
- 43. デプロイの流れ 製品のアップデートは週次で実施しており、以下の手順でデプロイを実行している 対話API(New) 対話API(Old) 1. EC2を起動しソースをclone 2. 全エージェントのモデルをS3から sync 3. 立ち上げたEC2をELBにつける 4. 古いEC2をELBから切り離す 43 課題: 全エージェントのモデルをsyncする為デプロイに時間がかかる
- 44. デプロイの課題対策(Doing) 学習済みモデルをS3ではなくEFS(Elastic File System)からロードすること でモデルsyncを省略 対話API(New) 対話API(Old) ● 学習毎に最新のモデルをEFSに保存 ○ バックアップとしてS3にも保存 ● 対話APIサーバーは常にEFSから モデルをロード ● ボトルネックになっていたモデル ダウンロード時間を短縮 44
- 46. 学習に異常に時間がかかる問題 • FAQ数が少ない対話エージェントでも想定以上に学習時間がかかっていた • 調査の結果、プロダクトの初期フェーズで実装した予測精度向上のための 幾つかの施策が学習時間の増加に影響を与えていることが判明した 46 • 全対話エージェントに対して各施策の有無による予測性能の変化を評価し、 コストに対してパフォーマンスが見合わない施策を削除した • 何かを追加するのは容易だが、(特にBtoBでは)削除にあたって労力を 要するので施策の追加にあたっては事前の評価をきちんと行うべき 課題 対策
- 47. Take away • 学習時の状況を簡単に再現・把握できるようにする • 学習済みモデルと推論コードの互換性をCIで担保する • (BtoBで)機械学習プロダクトを提供する場合は自社でモデルを学習できるようなSLA にする • 施策の追加は事前のコストとパフォーマンスの見積もりをした上で慎重に行う 47
- 48. 今後の展望 48
- 49. 今後の展望: 機械学習モデルのServing APIの分離 • 現状は対話APIサーバーは機械学習に関係ないロジックと機械学習に関するロジッ クが入り混じっている • そのため、機械学習に関係ないデプロイを行う際にも機械学習周りのロジックを意識 しながら実装・デプロイしなければならない – 逆もまた然り • 機械学習に関連するロジックだけを担うAPIサーバーに分離し、疎結合にしていきた い 49
- 51. WE ARE HIRING !!! • 自然言語処理・機械学習を用いたプロダクト開発に興味ある方を募集してます！ – アルゴリズムエンジニア・ソフトウェアエンジニアどちらも募集してます – 今日はお話し出来ませんでしたが、新プロダクトの開発やソリューション事業も行 なっているのでそちらにご興味がある方もぜひ • 自然言語処理以外にも、PKSHAでは動画解析や最適化、需要予測など他のドメインで も人材を募集しています！ • 興味を持たれた方は会社のHPからご連絡いただくか、連絡しにくければ私のtwitterア カウントにDMをお送りください – 会社HP: https://www.bedore.jp/recruit/ – twitter: @naohachi89 51