音響イベント検出ディクテーション: 言葉を超えた意味を持つ音

この投稿は他のエンジニアリングノートよりも意図的に試験的です。Sounds with meaning は出荷された機能ではありません。早期の研究方向です: 音響理解音声入力は、ディクテーションの穏やかな流れを保ちながら有用な非言語信号を捕捉できるか?

非言語音響のギャップ

音声入力システムは通常、言葉でないものすべてを捨てます。クリーンな書き起こしには理にかなっていますが、情報を失います。会議では、笑い声が同意や緊張をマークできます。ジャーナルでは、長い一時停止が重要かもしれません。アクセシビリティワークフローでは、ドアベル、タイマー、赤ちゃんの泣き声が有用なコンテキストになりえます。

1 時間の会議後の典型的なディクテーション書き起こしがどう見えるか考えてみてください。言葉はそこにありますが、リズムは平らになります: 誰かが反対する前の長い一時停止、厳しいフィードバックを和らげた笑い、難しい質問の後の沈黙の瞬間。書き起こしをレビューする人間はそれらを記憶から埋めます。出席できなかったチームメイトには信号がまったくありません。音響イベント検出ディクテーションは、そのテクスチャの一部を書かれた記録に戻す方法の一つです、ユーザーにそれを語らせることなく。

リスクは明白です: すべての音がテキストになるべきではありません。背景音響の大半は無関係です。一部はプライベートです。一部は曖昧です。音響イベント検出ディクテーションが意味を持つのは、オプションで、ローカルファーストで、音がいつ書かれた出力を変えるかについて保守的であるときだけです。

AED vs 音声キャプショニング

音響イベント検出 (AED) はコンパクトな質問に答えます: 何のイベントが起こり、いつごろか? 音声キャプショニングは音響シーンの自然言語記述を書きます。ディクテーションには AED で十分なことが多いです。「laughter」や「doorbell」のようなタグはマーカーになりえますが、完全なキャプションは冗長すぎるかもしれません。

なぜ AED から始めるのか

AED タグは静かに失敗します。モデルが何かを「applause」とラベル付けしてそうでなかった場合、ユーザーは削除しやすい単一のブラケットマーカーを見るだけです。間違った音声キャプションは元に戻すのが難しいです: 周囲の段落を形作り、読者にバイアスをかけ、サマリーに残ります。信頼が 1 文ずつ構築されるディクテーション製品にとって、小さな誤ったタグのコストは、自信ありげに間違った文のコストよりはるかに低いです。早期のバイアスは自動散文ではなく小さな構造化マーカーに向かいます。マーカーはレビュー、削除、無視が容易です。

これがディクテーションに意味すること

会議では、非言語音響がオプションのマーカーを作れます: ジョークの後の「[laughter]」、決定の前の「[long pause]」、話者が中断されたときの「[doorbell]」。ジャーナリングでは、ユーザーに語らせることなく感情的なテクスチャを保持できます。アクセシビリティワークフローでは、環境音をユーザーが頼めば短いノートやリマインダーに変えられます。

具体的なスケッチ。ユーザーが会議マーカーをオプトインした会議ノートを想像してください。書き起こしは通常の散文と、まれでコンパクトなタグで読まれます: 「今週マイグレーションを出荷することに合意。[laughter] 次にロールバック計画を歩いた。[long pause] 誰かがインデックス変更を延期すべきか尋ねた。」読者は段落のステージ指示なしに、何が起こったかのより豊かな感覚を得ます。

ジャーナリングのスケッチはさらに狭いです。ユーザーが 1 日の終わりの素早いノートをディクテーションする。可聴の長い一時停止が「[reflection]」タグとして表面化し、ユーザーはレビュー時にそれを保持、編集、削除できます。何もジャーナルエントリの本文に自動的にコミットされず、見る機会が与えられます。

私たちはディクテーションを劇場的にしようとしているわけではありません。目標はすべての咳やキーボードクリックを書くことではありません。目標は狭い高信号イベントセットを検出し、それらのイベントがテキスト、タグ、または何もにならないかをユーザーが決められるようにすることです。

研究基盤

いくつかの公開研究ラインが関連します。CLAP は対照的言語-音響事前学習を探究します。BEATs は音響理解のための音声事前学習を研究します。AudioSet は音響イベントの大規模データセット、AudioCaps は音声キャプショニングのリファレンスポイントです。

これらは研究基盤であり、製品依存声明ではありません。Loqua のプロトタイプ業務は Mac ディクテーションの質問に焦点を当てています: どの音響手がかりがカーソル位置で有用か、どれを不可視に保つべきか、ユーザーは境界をどう制御できるか?

プロトタイプしているもの

三つの狭い動作をプロトタイプしています。一つ目、会議マーカー: 笑い声、沈黙、拍手、中断のためのオプションタグ。二つ目、ジャーナリング手がかり: 長い一時停止や可聴の苛立ちのためのユーザー承認タグ。三つ目、アクセシビリティアラート: ユーザーが頼めばリマインダーやノートになりうるローカル音響手がかり。

社内でスケッチしている UX は意図的に静かです。検出されたイベントはディクテーションされたテキストの隣の小さなレビュー表面にチップとして現れ、テキスト自体ではありません。ユーザーはチップをドキュメントにドラッグ、無視、または宛先固有のタグに変換できます。デフォルト動作は「同意なしに挿入しない」。デフォルトモードは、ユーザーが特定のワークフローのためにオプトインするまでオフです。

プロトタイプはローカルファーストでオプトインです。この方向のものは、プライベートな背景音響を静かに注釈すべきではありません。検出された音響が決して自動的に散文に入らない「マーカーのみ」モードもテストしています。それらは挿入前にレビュー可能なチップとして現れます。

未解決の難問

最も難しい問題は意味です。笑い声は同意、不快、皮肉、または何もを意味しえます。ため息は疲労、安堵、またはマイクノイズを意味しえます。モデルに弱い証拠から感情的解釈を発明させたくありません。二つ目の難問はプライバシー: 環境音はユーザーが期待する以上を明らかにする可能性があります。

三つ目の難問は共有空間です。厳しいオプトインがあっても、会議室のマイクは何にもオプトインしていない人々を聞きます。その部屋の笑い声を捕捉する非言語音響機能は、まだユーザーでない人々についての情報を捕捉しています。これが解決不可能だとは思いませんが、制約セットを重く形作ります: 検出器はユーザーのデバイス上でローカルに実行されるべき、マーカーは明示的なアクションなしに共有されるべきではなく、明示的にテストしていない環境クラスのデフォルトは推論より沈黙に傾くべきです。

そこで現在の標準は保守的です。音声キャプショニングディクテーションには明確なユーザー制御、可視マーカー、容易な削除が必要です。音響イベント検出ディクテーションをプロトタイプから出荷に移すバーは具体的です: 注意深いユーザーが正直と言うオプトインフロー、明示的にテストしていない環境でのデフォルトオフ動作、間違ったタグを 1 キーストロークで却下できる UX。それらが正しく感じるまで、これは出荷されたコア約束ではなく研究フロンティアの業務に留まります。