46
1 音声認識とフロー体験 非同期音声会議 ラジオ番組支援システム 「音声インタフェースシステムの 効果的設計と評価に関する研究」より 西本卓也(東京大学) 2011-01-11

Nishimoto110111twcu p2

Embed Size (px)

Citation preview

Page 1: Nishimoto110111twcu p2

1

音声認識とフロー体験非同期音声会議

ラジオ番組支援システム

「音声インタフェースシステムの効果的設計と評価に関する研究」より

西本卓也(東京大学)

2011-01-11

Page 2: Nishimoto110111twcu p2

2

研究の背景[第1章]

インタフェース技術の発展

スイッチ、キーボード、マウス、タッチ操作、3D-CG, ポストPC, ... 音声:音声認識、音声合成、音声対話、擬人化エージェント

課題:成功する事例は限られている

技術は完璧ではない 誤認識を起こすのは音声認識だけ?

さまざまなモダリティの役割を適切に割り当てることは難しい

新しい技術は新しいバリアを作ることもある Graphical User Interface と視覚障害者

Raman (1997) Auditory User Interface 単純なモダリティ置換では不十分

要求

インタフェースの設計者・開発者のための「方法論」

その「方法論」の有効性の証明、音声技術への適用

Page 3: Nishimoto110111twcu p2

3

音響的・言語的に最も可能性の高い単語列を出力する

隠れマルコフモデル(HMM)/ベイズ決定則/N-gramモデル

課題:頑健性,未知語,「完璧ではない」

背景:音声認識技術の原理と構成

音響分析 探索

音響モデル 発音辞書 言語モデル

学習 学習

音声データベース テキストデータベース

入力音声 認識結果

)()()|(maxarg)|(maxarg~

XPWPWXPXWPW

WW==

Page 4: Nishimoto110111twcu p2

4

背景:テキスト音声合成技術(TTS) 大量の音声データによる統計学習アプローチの成功

課題:聞きやすさ,テキスト解析,「完璧ではない」

音声信号処理

韻律制御

合成単位選択 音声合成単位

漢字かな混じり文

音声信号

テキスト解析

読み,構文情報,アクセント型

読み,基本周波数パターン,継続時間長,パワーパターン

Page 5: Nishimoto110111twcu p2

5

インタフェースの理論 [1.2節]

行為の3階層モデル [Rasmussenn] 技能ベース、規則ベース、知識ベース

人間の情報処理特性モデル [Card et.al.] 知覚系、認知系、運動系

数値的に明確化 べき法則、Fitts's Law

行為の7段階モデル [Norman] 実行の淵

目標を立てる、意図を形成する、行為系列を特定化する、行為を実行する

評価の淵 システムの状態を知覚、状態を解釈、状態と目標を比較評価

道具型と秘書型

物理的世界

心理的世界実行の淵

評価の淵

応用:Macのメニュー

Page 6: Nishimoto110111twcu p2

6

提案:インタフェースの原則 [1.3節]

インタフェースの基本原則 [小林1993] [西本1994]

操作労力:位置移動最少、指定操作回数最少、指定操作容易性

システムの透過性:理解容易性、手順連想容易性、フィードバック

頑健性:誤入力防止、修復容易性

インタフェースの構成原則 [小林1993] [西本1994]

初心者保護、熟練者優遇、上級利用移行支援

インタフェースの導入原則 [西本2008]

有用性:必然性、動機付け、発見支援

適合性:ユニバーサルデザイン、状況の考慮、邪魔をしない

妥当性:妥当な評価、反復的な改良

原則そのものは特定の手段に依存しない主張

Page 7: Nishimoto110111twcu p2

7

音声認識:動機付けと楽しさ [西本1999]

音声認識ゲームを用いた実験(被験者10人)

さんすうのおけいこ(暗算ゲーム)

あー言えばこー言う(フリートーク)

順に述べよ!(記憶クイズ) いずれも「ドキュメントトーカ V3」の付属ソフトウェア (Windows 95対応)

質問「音声認識システムを楽しいと感じたことがありますか?」

回答 はい:7人 いいえ:3人認識率が低くても楽しめる人がいる

認識率が高くても楽しめるとは限らない

Page 8: Nishimoto110111twcu p2

8

フロー体験モデル

チクセントミハイ1975 による「動機付けと楽しさ」のモデル

没入の経験/「主体的に流れている」感覚

挑戦と技能が均衡した状態 → 楽しさ 技能が低いと不安

技能が高いと退屈

能力を必要とする挑戦的活動が必要

フローをもたらす体験

チェス,山登り,ダンス

仕事:外科手術

ネットサーフィン

BBS・チャット参加

「遊びだから楽しい」とは限らない

フロー

退屈

不安

無感動

挑戦

技能 high

high

Page 9: Nishimoto110111twcu p2

9

フロー体験の構成要素 課題を達成できる見通し

行為への意識の集中

明確な目標

直接的なフィードバックの感覚

深い没入状態

自分の行為を統制しているという感覚

自己と対象の融合(自己意識の消失)

時間経過の感覚の変化

Page 10: Nishimoto110111twcu p2

10

自己目的性の性質 音声認識を使っている感覚は各体験にどれくらい似ている?

5段階評価、各被験者における順位を平均 友情とくつろぎ:「いい音楽を聴く」など

危険と運:「サメのいる海に潜る」など

問題解決:「クイズを解く」など

創造:「何か新しいものを設計・発見する」など

目立つ:「大勢の観客の前で演技をする」など

競争:「競争して走る」など

結果

問題解決 創造 目立つ → 類似性高い 演技=表現活動とも類似

友情とくつろぎ 危険と運 競争 → 類似性低い 「システムを親しみやすくする手段」ではない?

Page 11: Nishimoto110111twcu p2

11

音声認識における前向きな挑戦 感じたことがある:7人 ない:3人

なかなか認識してくれないとき

発音やアクセント、リズム、高さを変えてみた

何度も誤認識されたときの再入力

だだっ子に言い聞かせるような感じ

異国の人に向かって話し掛けている感じ

音声認識に失望したり腹がたったことは?

発音が悪いのでうまく認識してくれない

自分の喋り方にがっかりした

「問題解決」としての音声認識

うまく認識されないときの試行錯誤=自分に対する不満

Page 12: Nishimoto110111twcu p2

12

音声認識を「楽しむ」ためには 認識性能が悪いことは負の要因ではない

うまく使うための知的で前向きな努力

フロー体験ありと回答した5人:音声認識を楽しんだと報告 時間感覚の変化,行為の統制,フィードバックこれらのうち2つ以上の経験がある

自己の行為の統制

質問:自分の操作に対して明確なフィードバックが得られていると感じたことがありますか? 「こんな風に発音した方が認識されやすいだろうなと意識してしゃべって、それが当たっていると感じたとき」

「自己の行為の統制」感覚→音声認識におけるフローの存在

行為の統制を支える「インタフェースの透明性」

インクリメンタル音声検索の試作

Page 13: Nishimoto110111twcu p2

13

・・・

・・・

・・・

・・・

・・・

・・・

複数の人間が時間を共有せずに音声で相互に発言し会話をできるメディアの実現

非同期音声会議システム [第3章]リアルタイム型 非同期・蓄積型

1way

2way

インターネットラジオラジオアーカイブ音楽配信

ボイスチャットインターネット電話 提案メディア

Page 14: Nishimoto110111twcu p2

14

試作したAVMシステム Voyager: ユーザエージェント

Windows上で動作/全二重録音再生機能

Voxer: メッセージ受信サーバ/対話再生サーバ Windows/Perl上で動作

データベース登録

再生音声作成

ユーザ サーバ

クライアント

録音/再生

メッセージ受信サーバ登録・蓄積

対話再生サーバ再生メッセージ作成

要求

送信

送信

Page 15: Nishimoto110111twcu p2

15

目的:文章入力のための音声認識の有用性を示す

使いやすさ?/バリアフリーに貢献? 背景=1990年代後半:PC用音声認識(ディクテーション)ソフトの実用化

2009年ごろ~:iPhone用音声入力Twitterクライアントの実用化

着眼点:音声と文字によるコミュニケーションを再考

「音声」が捨てられているために起きる失敗?

操作労力の仮説 肉声の録音は,キーボード文字入力と比較して,少ない労力で情報伝達

理解容易性の仮説 文字では実現できない豊かなコミュニケーションが可能

発言者の確認が容易 セキュリティ向上

頑健性の仮説 音声を聞くことを主目的にすれば不完全な音声認識結果にも価値はある

肉声によるメッセージの利用

Page 16: Nishimoto110111twcu p2

16

話し言葉の技能の活用 インタフェース構成原則(熟練者優遇)からの着想

音声コミュニケーションの熟練者はどんな効率的な会話を?

話し言葉の「技能」を生かすべき

漸次性 思いつくままに次々に喋るような話し方

共有されている情報の省略

認知的負荷の小さい表現

オーバラップ発話や相槌 オーバラップ発話を前提とした会話のモデル化

会話における相槌の役割

非同期型音声会議システム AVM の設計

Asynchronous Virtual Meeting system

Page 17: Nishimoto110111twcu p2

17

音声の検索や流し読みの実現 透過性原則の要求

音声録音ソフトにおける「透過性」の配慮 「レベルメーター」「録音ボタン」「再生ボタン」など

「音声」の見えない「中身」を可視化する手段が必要

「文字の掲示板」にはスレッド表示という可視化手段がある

提案:音声認識の利用

GUIでは音声メッセージを文字のように操作

音声認識は聞きたい音声を選ぶための手段

音声で録音されたメッセージを音声で再生

Page 18: Nishimoto110111twcu p2

18

音声メッセージの相互参照 非同期型メディアによる双方向的な議論

発言の双方向的編集行為が不可欠

例:読んだ発言の一部を引用しコメントする

どの発言に対する返答であるか

発言のどの部分に注目しているか

オーバラップ発話を相互編集の代替として利用

どの発言に対して、割り込みが行われたか

発言のどの部分の再生中に、割り込みが行われたか

音声再生中に自由なタイミングで割り込み(barge-in)を許す

日常会話から類推しやすい操作体系

メッセージの関連付けをユーザに委ねる

Page 19: Nishimoto110111twcu p2

19

メッセージのツリー構造 始終端検出により区切られた音声

その音声に付随する付加情報

音声の録音と同時に、再生音声との時間的関係を示すリンク情報が追加される

おはよう。今朝も冷えますね。ところで・・

そうですね。

おはよう

付加情報

再生音声

返答音声

メッセージ60人程度だと。 たしか。

近いといえば・・・

そういえば、プロ野球の人数は? わかる?

そうそう

はい

あんまり知らない。

Page 20: Nishimoto110111twcu p2

20

再生における問題点 時間情報に忠実に再現:完全重ね合わせ

複数のメッセージが重なり合うと聞きづらくなる

親メッセージに割り込ませる形で再生

聞き取りやすさは大幅に改善

相槌のような短い発話でも親メッセージが分断されるため聞きづらくなる

そうなんですか親メッセージ子メッセージ はい

会議ですが 延期になりまして それでですね・・・

そうなんですか親メッセージ子メッセージ はい

会議ですが 延期になりまして それで

Page 21: Nishimoto110111twcu p2

21

再生方法の改良 メッセージに属性を付加

Insertメッセージ 長時間の発話

再生時に親メッセージに割り込む形で再生

Overlapメッセージ 相槌等の短時間の発話

再生時に親メッセージに重ねる形で再生

そうなんですか

親メッセージ

子メッセージ はい

会議ですが 延期になりまして それで

Overlap Insert

Page 22: Nishimoto110111twcu p2

22

録音方法の改良 BISP(Barge In to Stop Playing) システム再生中にユーザが喋ったらそれを録音する

「相槌」(短い言葉)を喋った場合

システムの再生音声は止まらない

ユーザの相槌は記録される

「非相槌」(長い文章)を喋った場合

システムは再生音声を止めてユーザの声を聞く

ユーザの喋った文章は記録される

相槌も打ちやすくなり、長い発言も安心して可能

Page 23: Nishimoto110111twcu p2

23

再生音声の作成手順

そういえば、プロ野球の人数は? わかる?60人程度だと。 たしか。近いといえば・・・

(2) 子となるメッセージを再帰的に検索、付加情報を元に親メッセージに挿入ただしOverlapメッセージは無視する

(3) 元メッセージとの相対時間を元にOverlapメッセージを付加する

そういえば、プロ野球の人数は? わかる?そういえば、プロ野球の人数は? わかる?60人程度だと。 たしか。そういえば、プロ野球の人数は? わかる?60人程度だと。 たしか。近いといえば・・・そういえば、プロ野球の人数は? わかる?60人程度だと。 たしか。近いといえば・・・

はい そうそう

そういえば、プロ野球の人数は?そういえば、プロ野球の人数は?そういえば、プロ野球の人数は?

(1) ルートのメッセージを検索

60人程度だと。 たしか。

近いといえば・・・

そういえば、プロ野球の人数は? わかる?

そうそう

はいoverlap

overlap

メッセージ構造

Page 24: Nishimoto110111twcu p2

24

非同期音声会議:実験

目的:文字BBSに対する非同期音声会議の優位性を示す

課題:クイズを提示し、チーム内で議論し結論を出させる

AVMとBBSの2つのシステムで実験 AVMの音声認識にはViaVoice98(IBM)を使用

録音された音声を実験者がリスピークしてその結果をシステムに登録

研究室(京都工芸繊維大学)内の学生各5名1チーム

実験後にアンケートを実施

次にあげるスポーツのうち、プロ選手登録数が1000人に一番近いスポーツをあげてください。

競輪、競艇、騎手(中央競馬会)、ボウリング、サッカーJ1リーグ、スノーボード、オートレース、野球、Vリーグ

Page 25: Nishimoto110111twcu p2

25

結果:音声と文字のメッセージの比較 メッセージの分析結果

メッセージの特徴 AVM:話し言葉的で短く簡潔、くだけた表現

例:「60人ちゃうかったっけプロ野球って」

BBS:書き言葉的で長い文章

例:「70多くて80人が1球団の現役選手であると思います」

AVM BBS

被験者交替数 20 24

入力されたメッセージ数 71 24

1回あたりの平均入力メッセージ数 3.5 1

1メッセージあたりの平均文字数 32.4 235.7

全メッセージ文字数 2303 5657

Page 26: Nishimoto110111twcu p2

26

メッセージの文字数削減の効果 AVMではより簡潔なメッセージでコミュニケーションが可能

0

10

20

30

40

50

60

0-50 51-100

101-150

151-200

201-250

251-300

301-350

351-400

401-450

451-500

1メッセージ中の文字数[文字]

全メッセージ中

の割

合[%]

AVM

BBS

Page 27: Nishimoto110111twcu p2

27

実験結果からの考察 AVMはBBSと同等に利用できた

誤認識を含んだテキスト表示について

誤認識を多く含んでいても音声メッセージの選択には非常に有用

BISP機能

発話区間検出の失敗が多く、使用感が低下

本実験の用途での発言しやすさは達成されていた

AVMによって

[1] 話し言葉的な音声会話を非同期的に実現 … ○

[2] 話し言葉の漸次性が活かされた … ○

[3] BISPが発言しやすさに貢献した … △

[4] 誤認識を含んだ認識結果も有効利用 … ○

[5] BBSの代替として機能した … ○

Page 28: Nishimoto110111twcu p2

28

AVM研究の貢献 課題

サーバに実装する音声認識の性能向上

より会話しやすくするための改良 既読発言の再生を省略する

単語途中での分割を防ぐ

電話回線や携帯情報端末による実現

VoiceCafe(2000-2003) [video] 科学技術振興事業団・平成11年度委託開発課題 (株)ネットイン京都 他「コミュニティ形成支援機能を持つ音声会議システム」

「ニコニコ動画」(2006年)

投稿動画の特定の再生時間上にユーザがコメントをつけられる

時間と空間を越えて擬似的にリアルタイム通信の感覚が得られる 音声によるコメントは実現されていない

Page 29: Nishimoto110111twcu p2

29

ラジオ放送支援システム [西本2006]

ラジオ=身近で重要なメディア 特に高齢者や視覚障害者にとって

コミュニティFM放送局が増えている 地域に密着できる

災害時に重要、行政からの期待

課題 地域情報の提供には取材が必要

小規模な放送局では取材活動は困難

地域住民による投稿が重要

「オラビー(O'ra-be)」の開発

IPA未踏ソフトウェア創造事業

小規模なラジオ放送局の音声投稿番組を支援

Page 30: Nishimoto110111twcu p2

30

ラジオ放送現場の要求 求められていたもの

音声投稿を電話で常時受付

放送前に内容確認、簡単な操作で送出

生放送中に差し替えや並べ替えを

現場スタッフの要求

放送中はさまざまな作業を同時に行う

コンピュータの専門知識を持たない

直感的で確実なツールが必要

Page 31: Nishimoto110111twcu p2

31

音声投稿の意義 聴取者がリアルタイムに番組参加

従来:文字=ファクス、電子メール

ニュアンスの欠落や変化のおそれ

音声投稿 より正確に、個性などを含めて豊かに

災害時の速報性、状況報告、安否確認

ソーシャルネットワーキング 地域住民が肉声で近況を伝え合う

高齢者や障害者の生活の質向上

ラジオ番組の制作支援ツールの提案(2001年)

番組は「枠」で構成されている

枠を単位としたキューシート編集支援

対話的な録音インタフェース/音声コマンド操作の有効性

Page 32: Nishimoto110111twcu p2

32

音声投稿:技術的課題の克服 放送=公共性

内容の事前チェックが必須

電話による生放送はチェック困難

留守番電話 送出までに煩雑な作業

放送中に差し替えられない

音声ファイルの編集 波形エディタ=時系列

内容という単位で編集できない

提案システム=ドラッグとクリックだけによる操作 素材のダウンロードと検聴

キューシートの作成と再生

再生中のキューシートの変更

Page 33: Nishimoto110111twcu p2

33

素材の構成と送出

投稿された音声素材(アイテム)

CastStudio=素材の構成と送出生放送中に使えるシステム

Page 34: Nishimoto110111twcu p2

34

検聴シート(インスペクタ)

へ移動

Page 35: Nishimoto110111twcu p2

35

ダウンロード完了

Page 36: Nishimoto110111twcu p2

36

トリミング操作

クリック

検聴(音声の再生)

Page 37: Nishimoto110111twcu p2

37

検聴済み素材

Page 38: Nishimoto110111twcu p2

38

色の変更が可能

Page 39: Nishimoto110111twcu p2

39

キューシートに配置

Page 40: Nishimoto110111twcu p2

40

キューシート再生

クリック

Page 41: Nishimoto110111twcu p2

41

再生が完了した素材(アイテム)は

自動的にリサイクラーに移動

Page 42: Nishimoto110111twcu p2

42

音声素材

ジングルなど(ステッカーアイテム)

ステッカー:事前に作成された効果音や音楽投稿素材の前後や間に挟む

Page 43: Nishimoto110111twcu p2

43

電話投稿受付 要素技術=VoiceXML + PHP 処理の流れ

グリーティング

番組アクセス番号入力

マイクテスト開始

マイクテスト終了と音量チェック 録音時間の報告、レベルオーバー検出

本番録音開始

本番録音終了

Page 44: Nishimoto110111twcu p2

44

音声素材管理 事前に内容をチェックし準備する

到着した素材にメモをつける

使用しない素材を非表示にする

在宅でも自宅でも準備可能 (Webブラウザ)

Page 45: Nishimoto110111twcu p2

45

試験運用 2006年2月埼玉県入間市

コミュニティFM局「FM茶笛(チャッピー)」

「なべやかんの居留守放送局」

2月3日から24日まで毎週金曜日 16時~17時の生放送

放送範囲:入間市を中心としたエリア 周波数 77.7MHz

インターネットにて再配信(放送後1週間)

投稿(4週合計) 電話投稿: 約60件 ボイスレコーダー投稿: 約20件

Page 46: Nishimoto110111twcu p2

46

まとめ 担当ディレクターの評価

素材管理=事前に自宅で番組の準備

送出操作=葉書やファクスのような感覚 色分けが有効

急な変更にも対応できる(組み替えの自由度)

キューシートによる連続再生 次のコーナーの準備の時間が確保できる

生放送に適している リスナーと時間・空間を共有できる

ラジオの歴史はリスナー参加方法の歴史

葉書 → FAX → メール → オラビー?

2010年 Twitter + Ustream 時代の到来