●一般講演　　10:00-11:45
（1） リスク最小化学習に基づく識別的言語モデル
　　　小林彰夫，奥貴裕，藤田悠哉，佐藤庄衛，中川聖一
NHKで以前からやっている識別的言語モデル．認識誤りをリスクとしたベイズリスク最小化学習を行う．デコーダの第1パスで得られた単語ラティスに対して，ラベルなしデータに対する半教師あり学習．従来法である条件付き尤度最大化とエントロピー正則化との比較．また，教師あり学習と教師なし学習を同時に行う場合に，それぞれの目的関数を総合的に最適化する方法（多目的最適化）を利用する．この方法では，教師あり学習での目的関数を制約として，教師なし学習の目的関数の最適化を行う．認識対象はクローズアップ現代．従来法（条件付き尤度最大化，エントロピー正則化）と比べて1ポイントほど改善．ラベルなしデータを増やすことによって半教師あり学習の効果が出る．細かい分析から，ナレーションなどVTR部分の性能改善が大きい．特に挿入誤りが削減されていることがわかった．短い単語は挿入誤りである可能性が高いため，リスクが大きいという学習がされたのではないかという分析．組成としては単語n-gramと音素n-gramを併用しているが，音素n-gramはラベルありデータや単語組成との併用をしないと性能に寄与しない．

（2） 非負値行列因子分解に基づき動的適応したn-gram言語モデルによるパープレキシティ削減効果の分析
　　　藤田悠哉，奥貴裕，小林彰夫，佐藤庄衛
リスピーク方式で対応できる番組を増やしたい．音響モデルは特定話者モデルが使えるため，言語モデルの適応方式を検討．対象は情報番組．現状は手作業で番組ごとに言語モデルを作っているが，項目ごとに複数の話題が現れるので，自動で適応することが望ましい．事前情報として番組構成表が使えるが，量は少ない．そのため，NMFを使ってN-gram確率を直接求める方法を検討．適応テキストとしては過去の認識結果を利用．認識対象は「今日の料理」とか「食彩浪漫」など．評価はパープレキシティで，適応にunigramを使った場合とbigramを使った場合について調べた．基底数が少ないときにはunigramよりもbigramのほうがよいが，基底数が多くなると悪化．また，未知語が多い対象には向かない．基底が多い場合になぜ性能が下がるのかを調べるため，適応対象に認識対象を含めた実験を行ったところ，この場合は基底が多いほど性能が上がるので，規定の学習自体は問題がなくて，過適応が起きているのではないかと分析．

（3） 音声データの隠れ属性を利用した異種音響モデル群の構築
　　　福田隆，立花隆輝，西村雅史，Upendra Chaudhari，Bhuvana Ramabhadran，Puming Chan
ROVERとかCNCのような方法で統合することを前提に，大量の学習データから複数の音響モデルをどのように学習するか．学習データを分割して，それぞれの学習データに異なる性質をもった発話が集まるようにする．そのうえで各学習データのクラスタからモデルを認識することによって，異なる性質の音響モデルを学習する．学習データのクラスタリングには，ボトムアップクラスタリング（従来法）ではなく，その発話が持つ属性（話者，SNR，話速，話題など）に基づくトップダウンクラスタリングを用いる．それぞれの発話を発話ベクトルとして表現するが，その中身はHMMの各状態の出す確率の平均値（状態はクラスタリングしている）．分割スコアは，クラスタ内の全発話ベクトル間のコサイン類似度の平均と，全クラスタの平均ベクトル間のコサイン類似度の平均との差．最初の分割で最もスコアが良いのはSNRによる分割．分割したデータに対して，識別学習によって個別音響モデルを学習する．5000時間のデータを分割学習することで，n-best ROVERでWERが0.9%改善．ベストなモデルを事後的に選ぶことができれば，3.2ポイント改善する．

●デベロッパーズフォーラム（1）　　13:00-14:35
（4） しゃべってコンシェルと言語処理
　　　吉村健
最初に「しゃべってコンシェル」の紹介．「雑談」をする人は何か月たっても雑談を続けるという話が面白い．昨日リリースしたバージョン2から知識Q&A機能が付いた．
しゃべってコンシェルの２つの要素：「資源言語UI」と「データベース」
        タスク達成率∝音声認識率(UI)×意図解釈の正確性(UI)×機能・コンテンツの幅(DB)
構成要素：音声認識エンジン，意図解釈エンジン，各種専門検索エンジン，知識検索エンジン
・専門検索エンジンはDメニューにあるものを活用
・アプリ起動などはAndroidのインテント起動機能を利用
【意図解釈エンジンについて】
・ユーザ発話からタスクを判定し，またタスクに送るべき内容を切り出す
        タスク識別：発話例から機械学習
・意図解釈におけるキーポイント
        学習文例の質
                量も必要だが，質も重要（質が悪いと頭打ち）
                学習器自体にはあまりこだわらなくてもよい
        カテゴリ辞書の整備
                コンテンツプロバイダから情報取集など，自動クラスタリングも取組中
                自動クラスタリングは性能は良いが挙動が，不審なことがあって問題
【知識検索エンジン】
・質問文に対する回答をズバリ推定して維持する
        DB型QA（既存DBベース）
        検索型QA（Web検索ベース）
                「リアルタイム検索エンジン」を追加(Twitter検索）
・DB型QAのしくみ：Entity-Propertyタイプの質問解析
        EntityはCRFを使って抽出，Propertyは機械学習による多クラス分類
・解釈した意図がユーザにわかるようにフィードバックする
・検索型QAのしくみ：キーワード付近の内容を抽出
        質問タイプ判定→ENEタイプ判定→Web検索→回答候補抽出→応答評価候補

【サービス状況とユーザの声】
・400万ダウンロード（ちなみにLINEは700万）
・1億8000万クエリ
・しゃべってコンシェルを含むツイート：CM期間中は増える
        高評価・低評価ツイートの紹介
        珍答「彼女の作り方」「今，何時？」「今日のご飯は何がいいですか？」
        らくらくスマホ用しゃべってコンシェルのUIを研究している
        声を変えられるとよい→「しゃべってキャラ」
        ゲームなどのアプリへの展開
【今後の取り組み】
・実用性とエンタメ性の２つの軸
        実用性：機能拡大，iコンシェル連携
        エンタメ性：しゃべってキャラ（吉田くんとけいおんの話題がツイッターでは多かった）
・しゃべってコンシェルエンジンの今後の展開
        マルチデバイス，マルチスクリーン
        外部サービスへの提供
                ドコモ　ドライブネット（カーナビ）
                しゃべってロボ
【おまけ】
・うつして翻訳（カメラ撮影→文字認識→翻訳）
        言語モデルを活用した文字認識（WFSTベース）

（5） 議会の会議録作成のための音声認識－衆議院のシステムの概要－
　　　河原達也
2005年に速記者の新規採用・要請を停止し，2010年に音声認識による議事録作成を導入，2011年に運用開始（世界初）．すべての本会議・委員会の審議を対象とする．発言者（質問者・答弁者）の発言をマイクから収録し，それを認識した結果をもとに原稿を作成（校閲は行う）．
・アメリカの裁判所では速記者がリスピークによってディクテーションソフトを利用
・日本の裁判所では記録作成支援と検索に音声認識を利用（NEC）
・諸外国の議会・参議院では録音したものをテープ起こし
・イタリア議会ではリスピークによるディクテーション
・日本の地方議会では一部音声認識を導入（北海道，東京都など）
日本語固有の問題
・かな漢字変換の問題（曖昧性）→リアルタイムのタイプ入力がほぼ不可能
・表記の揺れ
・話し言葉と書き言葉の差異が大きい→復唱入力が困難
システムの基本的要件
・認識精度：80%以下では使い物にならない（90%以上が望ましい）
        現在の文字単位の認識精度85%，大半の区間で80%を確保
・速いターンアラウンド
        当該作業単位（5分）は10分後には編集開始→RTFが1以下
・厳格な表記・文字使いの保証
        会議録以外のコーパスは利用不可
類似タスクとの比較
        TC-STAR：欧州議会，ほとんど朗読（フィラー2%）
        日本の国会：大半が委員会，自発発話（フィラー4.7%)
        CSJ：自発発話，独話，ヘッドセットマイク，偏った話題（フィラー5.5～6.5%）
基本的アプローチ：言語モデル変換　大規模コーパスの効率的・持続的な推定
        話し言葉と会議録では13%の会議録で相違→うち93%は単純な挿入・置換など，文脈依存
        確率的な文体の変換によって話し言葉のコーパスを推定する
統計的言語モデル変換の枠組みと，それに基づく音声認識の紹介．
システムの実装と性能評価．
        2010年：文字正解率で約89.3%（本会議では95%）．文字正解精度は85.7%
        2011年：文字正解率89.8%
        2012年：文字正解率がほぼすべての会議で88%以上，平均90%
ユーザビリティ
        音声認識誤り：文字単位で10%程度
        話し言葉整形：フィラーは自動削除，その他の修正が8%程度
        シンプルなワープロ風のエディタのほうがよい（余計な機能はないほうがいい）
モデル更新
        言語モデル変更年1回，単語登録はいつでも
        音響モデル毎年（内閣交代ごとに）

●デベロッパーズフォーラム（2）　　14:50-16:35
（6） 話速変換技術・音声変換技術の放送および関連ビジネスへの応用
　　　都木徹，今井篤，清山信正，世木寛之，田高礼子，田澤直幸，岩鼻幸男
NHK放送の対象は幅広いので，視聴者によっては聞き取りにくかったり声質が気に入らなかったりする場合がある．そこで，視聴者に合わせたコンテンツ生成のために，話速変換と音声変換の応用を紹介．
・話速変換の基本原理（PSOLA）．話速を遅くした場合でも全体の音声が遅れないための適応的変換．適応的変換では，語尾に向けてだんだん話速を速くするとともに，単語間ポーズで話速の変化を吸収する．NHKオンラインのラジオニュースに使われている．
・合成音声によるラジオ放送の時間調整（株式市況）．番組終了時間にぴったり終わる．
・iPhone語学プレーヤーアプリ（2011～）．
・視覚障碍者の情報取得の支援技術．「ななめ聞き」の出現．
音声変換技術
・中国語の声調の放送番組への応用（声調参号）

（7） 音声合成の多様性向上の取り組み
　　　籠嶋岳彦，橘健太郎，布目光生，森田眞弘
音声合成普及の課題：了解性，自然性から多様性へ
多様性のニーズ：有名人・タレントの声，自分の声での合成，サービスに合った声作り（高級車の車格に合った声），たくさんの声の使い分け
ここでの多様性：顧客の用途で必要とされる話者・スタイルの音声合成を短期間低コストで提供できる能力
多様性向上の課題：コストの問題，顧客はどんな話者・スタイルを必要とするか，どう使い分けるか
・低コスト・短時間：一般ユーザ向けカスタム音声合成サービス
・スタイルのニーズ：対話調，緊急調
・使い分け：感情の自動推定
コストの問題：収録，データ修正→小規模コーパスで高い話者性の合成を実現（素片接続ベース）
        複数素片選択融合方式：小規模なコーパスでも均質な音声を合成できる
                複数の波形素片（ピッチの2倍の窓で切り出し）→帯域分割→位相を揃える→平均
一般ユーザ向けサイト：「声の素」作成700名以上
        読み上げは音韻バランス87文（10分程度）
        全自動が前提．読み・アクセントの表示，お手本音声の提示，収録音声のセルフチェック
話し手と聞き手の関係によるスタイルの違い
        読み上げ調だとよいが，対話には向かない（対話調と読み上げ調の使い分け）
        緊急メッセージの場合には「緊急調」で合成
感情によるスタイルの使い分け
        電子書籍の読み上げなどでは，自動推定が必要
                テキストからの感情自動推定：ナイーブベイズ　3000文で適合率90%再現率64%
                若草物語の自動朗読デモ

（8） キャラクターとの会話体験を提供する音声応答の試験サービス
　　　花沢健，辻川剛範
音声UIのエンターテインメント領域への適用．サンリオピューロランドの中でキャラクターと会話ができる試験サービスを実施した．目標は，音声認識・対話の高度化ではなく，会話体験の確実な提供．
システムが備えるべき要件として，「雑音に頑健なVADと認識」「全年齢の音声認識」「高速な音声認識」「キャラクターの声質による音声合成」など．
・耐雑音処理：2入力の音声検出（2マイクの差分によるVAD），サブバンド検出
・音声認識：文法ベース，各年齢層を含む音声コーパスによる学習，MDLを使ったモデルサイズ削減
　　　　　　ガベージ単語を用いた語彙外発声の棄却
・応答音声の選択：キャラクターに合わせたシナリオ，声優の発話の録音再生
シナモロール10周年イベントでフォトスポットの人形が対話する
・キャラクタの価値を高めたい
構成
・2台のマイク（音声用，雑音用），PC（単体動作）
稼働実績
・141日，13万6千件（多い日で2000件程度）
・1000件程度のサンプリング調査により，精度は約7割，返答はリアルタイム
・正しく認識できないケース：大声，小声，語彙外発声（誤検出はほとんどなし）
・子供は注意書きを読まない（読めない）