これで問題なく発表できる。
あとは風邪をひかないよう注意するくらいかな? :)
#TokyoNLP
今回はかなり理想的なコーパスで評価しているので、それを全面に押し出して許しをこおう。 (ぇ
#TokyoNLP
Winアプリ＝＞機械メーカでロボット作成（音声認識エンジン開発）＝＞KDDIで音声認識の応用研究されている という方
音声認識の概要)
音声データ（LPCM＝＞スペクトル）＝＞音声認識エンジン（TLP、MFC）＜＝音響モデル（HMM）、言語モデル（文書のゆう度）
■音素＝＞モーラ＝＞単語 の流れ
・単語/モーラ/音素
例)赤い/あ、か、い/a,k,a,i
http://recognition.web.fc2.com/
・フレミング、ハミング窓、高域強調フィルタ、FFT
・絶対値化、聴覚フィルタ（Mel Freq、Filter）、対数化、DCT
○電話回線を通すと音変わるので、電話音声用の専用フィルタを作成する
＝＞研究としては自然音声を基本に考える
開始＝＞きつね・うどん
カレー・うどん
XXX ・そば
という形で認識言語の繋がりを推測する。
言語モデルはNgramを使う
・コーパス(単語例)＝＞count N-Gram(頻度1以上の物を対象)=>Ngram
データベースにない語彙は認識がしづらくなる
単語N-gram高精度化と０頻度問題)
かたいことば(王道) と 柔らかい話し言葉(小手先パターン)＜友人同士
で扱いが違う
王道：コーパスを集める
小手先：パラレルコーパスでコーパスから生成
国会の議事録：余計な言葉は落とすイメージ
1)話題適応：LDA,PLSA
2)表現適応：CRL
3)未知N-gram：単語クラスタリングによる Class N-gram化
音声合成で歌を歌わせる 等の技術で小手先パターンは使われているかも との事
関西語は難しい！＝＞標準語 に直して認識させる手も
認識しにくい物)
・巨大なコーパスでも全て認識網羅できない
・認識内容：内容範囲が広いと難しい
＝＞スムージング(0頻度の単語に確率を付与)をして、強引に認識閾値を上げる
精度に対する指標)
1)音声データ＝＞コーパス（Word Correct,Word Accuracy）・・音声データとコーパスが1対1に対応してある
2)テキストデータのコーパスを用いる方法(Parplexity)
・Perpiexity=>音声認識分野で言語モデル単体の性の評価に用いられる指標
評価実験)
・MeCab ＝＞生成データを後からいじる
・NAIST Japanise Dictonary
・SRLM
http://www-speech.sri.com/projects/srilm/
学習コーパス Wikipedia 凄く多い
・ヒープスの法則（V＝KS）・・等比級数的に増加せず
＜曲線のグラフはMeCab生成データによる曲線色が強い
（音声認識だと些末データはしょっている?）
・スムージング手法による差ははそれほど大きくない
・コーパス規模に比例する＜料理なら料理と分野を限定した上で
■MSは網羅N-GRAMを作っていたが、範囲が広すぎて認識率が悪かった
音声認識の探索)
・辞書無しに、音素情報だけでやると場合分け(網羅率)が爆発する
・無くても認識に必要がない物（音声）は捨ててる。＜全て拾うわけではない？
・評価コーパスと学習コーパス
＝＞両方が良くなっていくとPerplexityが低くなる
・音声エンジン: Julius http://julius.sourceforge.jp/
・言語モデル: SRILM/32000語
でのデモ(rubyで動いてる?)
COOKPADを例にして見てる・・
音声認識エンジン「Julius」 http://sourceforge.jp/projects/julius/
リアルタイムに結構認識できるんだなー＜検索中に2-gram検索中(文字化表示)
■1文毎認識するのでその間は多少間を開ける必要があり
・音声エンジン: Julius http://julius.sourceforge.jp/
・言語モデル: SRILM/32000語
でのデモ(rubyで動いてる?)
COOKPADを例にして見てる・・
http://www.toshiba.co.jp/tech/review/2004/09/59_09pdf/a10.pdf
http://sourceforge.jp/projects/julius/
リアルタイムにやってるすごい
#TokyoNLP
・話題がずれた学習コーパスで認識させるとやはりボロボロ。
・「Julius」自体は不特定話者の音声認識に対応しているよ＜ぼそぼそ しゃべり方は認識しないかも
今は、食べログ の文章でデモ中
末尾に「室蘭」とかの文字で終わると、N-gramで変換できていてもさらに変換がかかって化けてしまう＜御認識扱い になってしまった＞＜。難しい
・「だ～か～ら～」とかは認識しずらい。
・早口も難しい
・認識しやすい話し方というのはやはりある
＝＞ここが今後の音声認識の課題 ！
http://atnd.org/events/11990
#TokyoNLP
http://www.cs.cornell.edu/home/kleinber/bhs.pdf
#TokyoNLP
http://www.cs.cornell.edu/home/kleinber/bhs.pdf
#TokyoNLP
http://www.cs.cornell.edu/home/kleinber/bhs.pdf
シンプルな方法)
1)1日ごとに区切る＝＞次の日にならないと集計できない＞＜
＝＞Twitter数の数を考える
2)イベントの範囲に注目
＜＝2連続でイベントが起きたらそれはバースト（Burst）? //ノイズ問題
1)イベント検出・・異常値の検出（地震計の揺れ検出） 正規分布を使ってそれっぽく計算
2)時系列ストリームからのイベント検出・・(TL、Blog、ニュース記事、センサ値)からイベント検出
＝＞時間とともに遣ってくるデータ
バースト状態・・通常の何倍もの頻度で起きる
BurstDetection＝流行チェック・・ノイズの問題が解決していない
ステート遷移：
Statable=>Burst / Burst=>Statable の遷移に制限を設ける（時間間隔で）
正規化項×状態遷移確率×積×各時点での状態：ｑ(状態シーケンス)ｔ(時間間隔のシーケンス)
で有る確率
#TokyoNLP
http://www.cs.cornell.edu/home/kleinber/bhs.pdf
ページランクの話)
Yahoo Search、MS Search から論文が出ている。
＜Googleは情報露出が少ない?
■自然言語/ランク学習
・高次元/低次元
・スパース/デンス
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
ランク学習の評価指標)
・NDCG・・上位何件とるか＜普通は10件ぐらい
・いいサイトは高くしたい
・良くないサイトは低くしたい
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
http://atnd.org/events/11990
■Bigpartite Learning
・学習データが短時間で簡単に作れる
＝＞自然言語でも学習コーパスを作るのが大変
■PairWise
・データはペア
■ListWise
・データはリスト型
＜＝学習データ作るのが難しい
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230”
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
学習の簡単さ
Bipartite＜PairWise＜ListWise
・Bipartite・・sampleがある程度ある＝＞サンプルの組み合わせで実装できる
■Bigpartite Learning
・学習データが短時間で簡単に作れる
＝＞自然言語でも学習コーパスを作るのが大変
■PairWise
・データはペア
■ListWise
・データはリスト型
＜＝学習データ作るのが難しい
Pairwise：文章の並び替え・スコアで
Confidence Weighted )
・更新式は γi 正しい：マイナス値＝＞max:0=>無更新
・学習が速い＝＞ループ1回
・ノイズに弱い＝＞AROW,NAROWという対策アルゴリズム提案
Learnig to Rank)
・feature実装が大変
Confidence Weighted )
・パラメータの変更率がすごい＜ノイズデータによる
・伝統的な手法も要考慮
#TokyoNLP
http://d.hatena.ne.jp/download_takeshi/20091206/1260130230
統計的機械翻訳入門 by @nokuno さん 始まってます
#TokyoNLP
http://atnd.org/events/11990
Noisy-Channel Model）
・言語モデル（文の滑らかさ）と翻訳モデル（対訳コーパスから学習：意味の近さ）に分解
翻訳モデル)
・単語ベース
・フレーズベース
・文章ベース
単語アライメント)
・単語の対応づけ(英独対比)
das=the
has=house
・並び替え
・単語数の増加（1:1とは限らない）
かなり昔に。
http://www.nlp.mibel.cs.tsukuba.ac.jp/pdf/SMT2008.pdf
#TokyoNLP
EMアルゴリズム)
・不完全データにより分散された状態を収束させる
・初期化・・全てのアライメントは等確率
・modル学習 la は the と共起する
○共起・・ある単語がある文章中に出た時その文章中に別の限られた単語が頻繁に出現すること
http://code.google.com/p/giza-pp/
#TokyoNLP
http://alaginrc.nict.go.jp/WikiCorpus/
#TokyoNLP
日英対訳コーパスの例)
・NICTの日英対訳コーパスで実験
・GIZA++をつかってアライメント
・セグメーテンションのミスが多い
・フランス語に翻訳する場合は 日本語＝＞英語＝＞フランス
英語が対訳コーパスが一番多い（英語を中間言語に）
#TokyoNLP
http://atnd.org/events/11990
・IRM・・あるかないかでモデルを判定
・FIRM・・回数をモデルに組み込む
＝＞続けて何回出たかをIRMのモデルに共起の回数を条件として追加するイメージ
・SAM・・単語と単語のペア＝＞FIRMでは復元できる と論文には書いている
「クネイザー・ネイ」かなとは思ってますが、私も含め、みな、「ク」をあまりはっきり言わない印象があります。
#TokyoNLP
MFCは「Mel-Frequency Cepstrum」で、係数の「Coefficient」をつければMFCCになりますね。 :)
#TokyoNLP
http://quruli.ivory.ne.jp/diary/?date=20100605#p07
RT @mansuku: SnowLeopardになってからmake通らないのよね(ｰｰ;)
#TokyoNLP
参加された皆様、有り難うございました。
#TokyoNLP
RT @takesako:
参考文献：音声認識を紹介するページ MFCC http://recognition.web.fc2.com/
http://quruli.ivory.ne.jp/diary/?date=20100605#p07
RT @mansuku:
#TokyoNLP
音響の尤度があるので、それほど問題にはならないのですが、確率を割り当てが方が良いケースもあると思います。
具体的には、音響的に近く言語的に遠い単語列の組を、より適切に探索させるためです (あまり良い例が思いつかない…)。
#TokyoNLP
個人的にはMFC, PLP, LPCの分かり易い説明をしていただけると嬉しいです。
ちなみに今日の #TokyoNLP でも「PLPって何?」みたいな質問がありましたよ〜。 :)
Juliusのようなmulti-passの音声認識エンジンは、通常、探索時のメモリ占有量の削減、後段passの探索アルゴリズムの独自性を狙う形で実装されていると思います。
(と、口頭でお伝えしたつもりでしたが、念のため)
#TokyoNLP
Juliusのようなmulti-passの音声認識エンジンは、通常、探索時のメモリ占有量の削減、後段passの探索アルゴリズムの独自性を狙う形で実装されていると思います。
(と、口頭でお伝えしたつもりでしたが、念のため)
#TokyoNLP
