aptpod Tech Blog

株式会社アプトポッドのテクノロジーブログです

AWS Fargateで発話箇所を自動検出するシステムを作った話

f:id:aptpod_tech-writer:20210623183848j:plain

こんにちは。製品開発グループにて機械学習の研究開発まわりを担当しているきしだです。
現在、研究開発の一環として、「デバイスから収集された時系列データから、発話された箇所を自動で検出するシステム」を開発しています。現在はまだ試作段階ですが、この試作品を用いて実際に利用機会があるかどうか検証しているフェーズです。そこで、今回はこの試作内容をテックブログにてご紹介します。

※ 現在こちらの試作品にご興味がある方々を募集しております。試しに利用してみたい、という方がいらっしゃいましたらぜひこちらまでお問い合わせください。

ことの背景

走行データをフィードバックデータとして活用する

弊社のプロダクトであるintdashは、各デバイスから収集した高頻度の時系列データを伝送・管理するミドルウェア的要素を持っています。収集および可視化にはそれぞれアプリケーションが提供され、その間をつなぐパイプラインとして様々なデータリソースを活用できます。

利用ケースとしては、走行する車のエンジン回転率や前方方向を撮影した走行動画、走行位置などを走行データとして記録しておき、走行時におかしなところがないか後からチェックしたいケースが挙げられます。例えば、最近発表があった大阪ガス様の"AI/IoTによる工事現場自動検出システム" では、走行ルートから工事現場という特定の要素を検出し、後から工事現場の配置状況を走行時のフィードバックとして確認する運用フローをサポートしています。

このように、走行状況を後からフィードバックデータとして利用したいケースは、他案件でも需要があることが確認できています。ここでは"おかしなところ"を検出しておくことで、フィードバックデータの価値をより高めることができる点がポイントです。

フィードバックデータの価値を高める難しさ

しかし検出を行うためには、検出を行うためのトリガーが必要です。

ここでいうトリガーは、"スピードが80km/hを超えた"というような単純なしきい値で定義付けできるものもあれば、 "道に穴が空いている" というような、数式化するには骨が折れるような定義付けも含まれます。現状では後者に対する需要が高まっており、機械学習を使ってソリューションを検討する場合が多いですが、機械学習では精度の担保にリスクがついてまわったり、開発リソースがコントロールしづらいため、機械学習に知見がないと手を出しにくい領域です。

一方でこのような作業を人手で行うと、一日数時間の走行データを最初から最後まで目でみて、異常がないかチェックすることになり、時間が非常にかかってしまいます。加えて複数人にスケールすると、判断基準がぶれたりしてチェック内容が正確でなくなったりと、課題はなかなか無くなりません。

フィードバックデータの価値を"発話箇所"で高める

そこで少し発想を変えてみて、

  • トリガーの判断は人間が行いつつ
  • 判断時の記録を運転しながらできるようにし
  • 後から確認すれば記録を見れるようになる

とすれば、フィードバックデータの価値を高められるのでは?と考え「音声を使って"おかしなところ"を記録し、後から見れるようにする」ことを思いつきました。

運転中に人が"穴があった!"といい、その発話した時間帯をシステムに記録しておけば、後から見たときにその発話箇所を参照することで、"穴があった"箇所を確認できます。トリガー自体の開発は行わなくとも、走行時の記録を簡易的にシステム化することで、ユーザーの業務改善フローを簡単に実現することができ、システム導入にあたる効果検証を素早く行うことができます。

ということで、まずはこのシステムの効果検証を行うべく、intdashに取り込まれたデータから、発話した箇所を検出して検索する機能を試作品としてつくってみました。

機能の概要

前置きが長くなりましたが….
ユーザーの利用フローは以下を想定します。

  1. 走行中に気づいたことがあったらドライバーがマイクを通して発言を行う
  2. システム上でデータ収集が完了したあと、サーバー側で音声データを解析し、発話されている時間範囲を検出する
  3. ユーザーは検出結果をダッシュボード画面で確認する
  4. ユーザーは発話された場所に移動し、確認したい時間範囲のデータの様子を観察する

ユーザーの目線では、「走行中に気づいたことを話していれば、あとからその箇所を確認できるようになる」という、至ってシンプルなシナリオとなります。

実現方法

アーキテクチャ

今回実現するにあたって、全体のアーキテクチャ構築にはAWS Fargateを用いたコンテナの並列処理を行える構成を採用しています。Fargateを用いることで、以下のことを期待できます。

  • 計測の数に応じて、フレキシブルにコンテナのリソースをアサインすることができる
  • 処理の負荷が高くなった場合、処理を分散させスケーリングする構成を容易にたてることができる

もともと発話検出を行う環境をコンテナ化していたのもあり、コンテナの操作のみを意識したシステム構築を可能にするサービスとして、非常に親和性が高かったため採用にいたりました。

今回は、以下のような役割をもつ “Manager“ を実装し、AWS Lambda にデプロイしています。

  • intdash側の計測状態の監視
  • Fargateのクラスタへのタスクの投下
  • タスクステータスの管理

最終的に、以下のような構成になりました。

f:id:aptpod_tech-writer:20210621112634p:plain
構成イメージ

  • デバイス上で計測を開始し、データをサーバーにためます
  • 計測が終了すると、AWS LambdaにデプロイされているManagerが計測終了を検知し、発話箇所検出が動作するコンテナを立てます
  • コンテナのジョブの状況はDynamo DBなどのキャッシュに利用できるサービスを用いてキャッシュしておき、ジョブのステータスによりリトライなどの処理に用います
  • コンテナ上で検出された発話の検出結果はサーバーに送付されます
  • 検出結果は VM2M Data Visualizerなどの可視化アプリケーションで確認します

非常に簡単な構成ですが、検証レベルでは充分運用が可能な性能を提供できます。構築自体も1日程度でサクッとできました。

発話検出のロジック

発話検出のロジックについては、現段階だとサービスの仮説検証段階ということもあり、発話の検出を行うモデル開発は行わず、こちらの inaSpeechSegmenter を利用しました 。

github.com

モデルの詳細についてはこちらの論文で確認することができます。

今回の利用ケースでは、精度・パフォーマンス共に利用可能なレベルだったので、こちらを一旦採用することにしました。

実際に動かしてみる

それでは、実際に動かしてみましょう。

今回は、車の代わりにiPhoneを使って手軽に動画・音声をアップロードできる intdash Motion を用いてアップロードします。「Motionを利用して走行動画を撮影しながら、”車が止まったところ”を記録し後から確認する」という利用シーンを想定します。

Motionで計測を開始すると、アップロードできていることがVM2M Data Visualizerから確認できます。

f:id:aptpod_tech-writer:20210621113744p:plain
Visual M2M Data Visualizer 画面

それでは、Motion上で計測を終了します。終了すると、AWS Lambda上にデプロイしたManagerが計測終了を検知し、Amazon ECS上でコンテナを立てます。

コンテナが新たに立てられ、タスクが開始されていることを確認します。

f:id:aptpod_tech-writer:20210621113946p:plain
Amazon ECS クラスター画面

この時、発話検出の処理時間はかかりますが、計測を生成する度にコンテナが生成されるため、くりかえし計測を生成しても処理がスタックすることがありません。請求にかかるリソースも計測が生成された分発生するのみです。

f:id:aptpod_tech-writer:20210621114507p:plain
並列にコンテナが立ち上がった時

本来は自分自身で設計・実装しなければいけないところなので、このあたりを考える必要がない点は非常に楽ですね。

さて、コンテナのタスクが完了しました。 それでは、発話の検出が反映されているか見てみましょう。

f:id:aptpod_tech-writer:20210621114658p:plain
検出結果後

無事、検出されていることが確認できました。 早速、検出された区間を参考に、最初に"車が止まったところ"を確認します。

f:id:aptpod_tech-writer:20210621114746g:plain
検出結果の様子

すぐに確認できましたね。検出した時間帯を記録しておくと、動画の中で確認した気づきがどの時間帯なのかはっきりわかり、すぐに対象のデータにたどり着くことができました。

まとめ

今回は、弊社で実施している研究開発のうち、”発話箇所を自動検出するシステム”の効果検証の取り組みについてご説明しました。
冒頭の再掲にはなりますが、現在試作品を試してくださる方々を募集しております。もしご興味がある方がいらっしゃいましたらこちらまで問い合わせください!