iOSにおけるWakeword検知機能の実装

Editor's Notes

• #2: iOSにおけるWakeword検知機能の実装というタイトルで発表します。よろしくお願いいたします。
• #3: 簡単な自己紹介をさせてください。伊賀裕展ともうします。 株式会社エクサウィザーズのソフトウェアエンジニアとして現在は主にCareWiz ハナストというプロダクトのiOSアプリ開発を行なっています。
• #4: 本日はWakeword検知のiOSアプリでの実装に関してお話いたします。さて、まずそもそもWakeword検知とはどのような機能でしょうか。 Wakeword検知とは音声認識などの処理を起動させるためのキーワードを検知する機能を意味します。 例えばiPhoneでのHey Siriの活用などが馴染み深いのではないでしょうか。
• #5: 本日お話しするCareWizハナストでは音声のみでアプリを操作するためにウェイクワード検知を活用しています。
• #6: 音声でのアプリ操作といっても今ひとつイメージがつきずらいかもしれません。 簡単な数十秒程度の動画を用意いたしましたので、まずはご覧いただければと思います。 動画 0:27から 先ほどは記録する場合のフローの動画でした。 もう一つ連絡機能を使用する場合の動画もご参考までに共有いたします。 動画 1:47から
• #7: 先ほどご覧いただきましたデモの操作をシーケンスで図解してみると図のようになります。 ウェイクワードを検知し、記録、連絡といったコマンドワードを検知、自由発話を文字起こしし、バックエンドに送信しています。
• #8: 本日はウェイクワード検知の部分に焦点をあて解説し、その後音声でアプリを操作する際のUI・UXに関してもお話しします。
• #9: さて、本日のアジェンダです。 まずDemoでもご覧いただいたWakeword検知に関して、モデルの作成からアプリへの組み込みまでをご説明します。 次にSoundAnalysisと組み合わせて誤検知を減らす取り組みに関してご説明します。 その後、音声によるアプリ操作に関して、UI・UX観点で気をつけていること、どのように実装しているかをお伝えします。
• #10: まずはウェイクワード検知からご説明します。
• #11: 多くの場合にそうであると思いますが、ハナストでもウェイクワードの検知をEdge AIで行っています。 主な理由は2点で、パフォーマンスとセキュリティです。 ウェイクワードは通信環境にかかわらず、発話から検知・反応まで可能な限り高速にしたいです。 また、ウェイクワード検知のために全ての音声をバックエンドに流すのはセキュリティ上好ましくありません。 これらの理由より、Edgeでの処理が適していると考えています。
• #12: ウェイクワードの検知にあたり2つのアプローチを考えました。 1つは分類モデルです。 一定の秒数ごとに一定の秒数の発話がウェイクワードであるかどうかを判定します。 もう一つはラベリングモデルです。 こちらは時系列の各音に対して、その音がウェイクワードに関連する音なのかどうかをラベリングします。
• #13: 分類モデルでは検知したかどうかの判別が行いやすいですが、発話とみなす音の秒数によって性能が変わってきます。 ラベリングモデルはその点安定しますが、検知したかどうかの判別が難しくなります。
• #14: 今回はアプリでの検知結果の判定のしやすさを優先し、分類モデルを採用しました。
• #15: 学習ロジックとしては、Long Short Term MemoryやRecurrent Neural Networkが使用されることが多いようです。 音声の認識のためには前後の文脈が重要になりますが、これらのモデルは学習に前後のデータを使用し反映させるためコンテキストも考慮した推論ができるようになります。
• #16: ウェイクワード検知機能をアプリに組み込むまでの流れをご説明します。 モデルを学習するためのベースデータを収集し、そのデータをもとに学習用のデータを作成します。 作成したデータをモデルに学習させ、アプリに組み込める形に変換します。 その後、アプリに組み込みリリースを行います。 それぞれにフォーカスを当てて内容を確認していきましょう。
• #17: ベースデータの収集においては正例と負例とノイズを収集します。 正例では年齢、性別などデータにバリエーションを持たせることが重要になります。 環境音ノイズは様々な種類を取得するべきですが、使用が想定される場所のノイズ音を取得できるとより効果的です。
• #18: 取得したベースデータから学習用データを作成します。 具体的には正例、負例のデータと環境音ノイズを混合したり、データの一部を除去したりします。
• #19: それぞれの作業イメージは図のようになります。 このようにすることでベースデータからバリエーション豊かな学習用データを作成することができます。
• #20: 先ほどご説明したLSTMやRNNを用いてモデルを作成し、環境音ノイズを加えて編集したデータで学習を実施します。
• #21: 学習の際に1点留意すべきことがありますので、ご紹介します。 ウェイクワード検知のモデルにおいては誤検知率が低くなることが大変重要になります。 例えば、誤検知しない確率が99%だとしても2分程度の時間の間に1度誤検知してしまい、ユーザーの体験が大きく損なわれます。 そのため、誤検知率をいかに抑えられるように学習させるかに注意する必要があります。
• #22: 作成したモデルをアプリに組み込むことを考えます。 代表的な方法としてはCoreML Tools、 TensorFlow Liteなどがあるかと思います。
• #23: CoreML ToolsはApple によって提供されているツールです。 PytorchやTensorFlowなど様々なライブラリによって作られたモデルをCore ML モデルに変換することができます。 Core ML モデルはNeural Engineが使用できることにより、パフォーマンスが高くなる可能性が高いため、まず検討したい方法です。
• #24: TensorFlow LiteはGoogleによって提供されています。 こちらも様々なライブラリで作成されたモデルをモバイル端末で実行可能なモデルに変換できます。 TensorFlow LiteのモデルはAndroidでも使用可能なため、両OSをサポートしている場合とくに候補に上がるかと思います。 最近では種々の制約はありますが、Core ML Delegateを使うことでCore ML モデル同様にNeural Engineを使用することができるようです。
• #25: アプリに組み込む際の流れを確認します。CoreMLモデルに変換した場合を例に取ります。 CoreMLモデルはプロジェクトに含めると自動的に対応したクラスが生成されるためそちらを初期化します。
• #26: AVAudioEngineを使用し、音のStreamを取得しモデルに流します。 この際にモデルの推論実行に必要なデータ形式に変換することが重要になります。
• #27: 取得した音を用いてモデルで推論を実施し、実施結果のConfidenceをもとに処理を決定します。 この際に必要なConfidenceの値はユーザー側で調整できるようにすると、感度調整といった形でユーザービリティを高められるかもしれません。
• #28: まとめます。 ウェイクワード検知とは何かをお伝えしました。 ウェイクワード検知によって、音声によってアプリの機能を起動させることができます。 また、ウェイクワード検知モデルを作成し、アプリに組み込むまでの流れの概要をお伝えしました。
• #29: 次にSoundAnalysisによる機能改良についてご説明します。
• #30: Wakewordを検知するために音声を流し続けていますが、必ずしも人の音声が含まれているデータだけが流れてくるわけではありません。 大部分の区間はそれ以外の環境音や人の声以外の音が流れてきます。 そのため、環境音をWakewordとして誤検知するということもありえます。
• #31: そこで、Wakeword検知モデルに流れる前に人の音声を含む音のみを通すフィルターを置くことで機能改良が図れるのではないかと考えました。 Appleが提供するFrameworkにそのようなものはあるのでしょうか。
• #32: 調べたところSoundAnalysisが使用できそうだということがわかりました。
• #33: Sound AnalysisはiOS13から導入されたフレームワークで、音の分類を行うことが可能です。
• #34: 導入された当初は分類のためのモデルを自作する必要がありました。 https://developer.apple.com/videos/play/wwdc2019/425/
• #35: iOS15でビルトインのモデルが使用できるようになりました。 WWDCでの説明によると約300種類の音を分類することができるようです。
• #36: ビルトインモデルで判別できる音を出力してみました。
• #37: 目を凝らしてみますと分類可能な音の中にspeechがあることがわかります。 人の発話を分類できるようです。
• #38: 以上からSoundAnalysisを使用して人の音声データを含む音のみを通すフィルターを作成することができそうです。
• #39: 具体的な実装を概観してみましょう。 まずストリームの音の処理を行うためSNAudioStreamAnalyzerを使用します。
• #40: SNClassifySoundRequestを使用することでビルトインのモデルを使用することができます。
• #41: Observerを設定してrequestをanalyzerに追加します。
• #42: AudioEngineで取得した音声をanalyzerに流します。
• #43: 解析結果は先ほどanalyzerにセットしたSNResultObservingを継承したクラス経由で行います。
• #44: 検知結果をSNClassficationResultにキャストし。
• #45: 検知結果のidentifierを使用し、検知結果からspeechのもののみを取得、confidenceを取得します。
• #46: confidenceが一定の値を超えていた場合に検知したと判断し、検知時の処理を実行します。
• #47: 先ほどまでの実装によって、SoundAnalysisを使用した人の音声が含まれる音のストリームのみを通すフィルターを追加することができました。
• #48: まとめます。 SoundAnalysisのビルトインモデルを使用することで人の会話を判別することができます。 ウェイクワード検知モデルの前段階に配置することで誤検知が低減できるように活用した事例をご紹介しました。
• #49: さて、ウェイクワードの検知はそれを行なって終わりではありません。 検知後に繋げる必要があります。その辺りをお話しします。
• #50: ウェイクワードを検知した際にはまず、ユーザーにそのことをフィードバックする必要があります。 また、ウェイクワード検知後の機能につなげるひつようもあります。
• #51: まずユーザーへのフィードバックについてみていきます。 画面のUIでのフィードバックではユーザーへの伝わりやすさを重視し、PrimaryColorの画面を全面に出すことで検知を伝えています。
• #52: 実装についてもご紹介します。 非常にシンプルになっていて、ウェイクワード検知時にtrueに変更されるプロパティを用意し、
• #53: アプリのベースとなるViewでプロパティの変更を検知し画面を表示するようになっています。
• #54: 次に音声でのフィードバックについてもご紹介します。 ウェイクワードを検知する際に必ずしもユーザーは画面を見ているわけではありません。 そのため、手が使えず画面を確認できない場合でもウェイクワードを検知したことがわかるように音でのフィードバックも重要になります。
• #55: ハナストではウェイクワード検知時にAVSpeechSynthesizerで「はい？」という発話をさせることで音声でのフィードバックを実現しています。
• #56: 実装に関しても簡単にご紹介します。 AVSpeechSynthesizerを初期化し、utteranceで発話させたい内容を定義します。 AVSpeechSynthesisVoiceで言語を設定し、speakメソッドを呼び出すと発話させることができます。 これをウェイクワード検知のタイミングで行うという実装になります。
• #57: さて、ウェイクワードの検知はそれ単体で完結する訳ではなく、次の機能につなげる必要があります。 この際にウェイクワードに続く処理を音声で行いたいことも多く、音のStreamの操作が必要になります。 また、音声のみの操作だけではなく、素早く確実なインタラクションのためにUI側の操作を受け付けるようにすることも重要です。
• #58: セッション冒頭でご紹介しましたように、ハナストではウェイクワードを検知した後に記録、連絡という機能に繋げています。 記録というコマンドを検知すると記録機能に連絡という発話コマンドを検知すると連絡機能へと遷移します。
• #59: この流れの中で、HeyWizというウェイクワードを検知したあとはコマンドワードを検知する機能に音声のStreamを振り分け直す必要があります。 また、記録、連絡という発話をコマンドワードとして検知したあとはそれぞれの機能を実行するために音声Streamの振り分けを再度行います。
• #60: 先ほどのご説明の通り、音声での操作だけではなく、ユーザーによるUI操作もサポートしています。 例えば、コマンドワードの検知の際には記録、連絡機能にそれぞれのボタンを押下することでも遷移できます。 また、記録、連絡それぞれの機能においてバツボタンを押すことで機能をキャンセルすることが可能です。
• #61: 音声Streamの振り分けの実装に関してご紹介します。 例としてウェイクワード検知後にコマンドワード検知機能に音声を振り分け直す場合をみてみます。 ウェイクワードを検知した場合に変更されるisSttRecognizingの変更を検知し、startSttCommandWordメソッドを実行します。
• #62: startSttCommandWordメソッド内でコマンドワード検知用のRecognizerを実行します。
• #63: 音声ストリームの振り分けのためにaudioEngineに対してremoveTapを実行し、
• #64: installTapによって、audioEngineからの音声ストリームが流れる先を再設定します。 今回はコマンドワード検知用のrecognizerに音声を流し込むようになっています。 removeTapとinstallTapによって音声の振り分け先を変更する方法をご紹介しました。
• #65: まとめます。 ウェイクワード検知はUIと音の双方のフィードバックが重要であることをお伝えしました。 また、ウェイクワードは検知して終わりではなく、その後の機能につなげる必要があり、音声ストリームの振り分けなどが必要なことをお伝えしました。 それだけではなく、確実性の高いUIへの操作を並行して提供していることもお伝えいたしました。
• #66: 最後に全体のまとめに入ります。
• #67: 本日はまずウェイクワード検知モデルを作成し、アプリに組み込むまでの流れをお話ししました。 データ収集から実際にアプリに組み込むまでの流れを一通りみていきました。 次にSoundAnalysisフレームワークを用いて人の音声のみを通すフィルターを作り誤検知率を低下させる試みに関してお話ししました。 最後に音声で操作するアプリのUIやUXに関してお話ししました。画面でのフィードバックだけではなく音によるフィードバックも重要であること、 音声による操作とUIによる操作を両立していることなどをお伝えしました。
• #68: 以上で発表を終わります。ご清聴いただきありがとうございました。