ここでいう学習とは、写像 f:X→Y (X : ビーム幅 , Y : スループット)
を推定することである。
認識処理はビーム幅に対する線形時間＋固定時間で行うことができる（と思われる）: Ax+B
すなわち、ビーム幅に対するスループットは 1/(Ax+B) で表され、目的はこのAとBの値を推定することになる。
2010年6月30日水曜日
StreamSR : TCPポートメモ
sa07:6270..6279 : 認識音声入力の 0 ～ 9 番
sa07:62710..62799 : 認識音声入力の 10 ～ 99 番
sa07:6280 : ビーム幅セット入力
sa07:6281 : 学習音声入力（予定）
認識音声入力のポート番号について
spade上で "stcp://sa07.sc.cs.titech.ac.jp:627@i/"
というURIで入力源を指定しているため、 @i の桁数が変わるとポート番号が飛ぶようになっている。
pythonのように "stcp://sa07.sc.cs.titech.ac.jp:%d/" % (50300 + @i)
などのように実装できればこういう問題は起こらないのだが……
sa07:62710..62799 : 認識音声入力の 10 ～ 99 番
sa07:6280 : ビーム幅セット入力
sa07:6281 : 学習音声入力（予定）
認識音声入力のポート番号について
spade上で "stcp://sa07.sc.cs.titech.ac.jp:627@i/"
というURIで入力源を指定しているため、 @i の桁数が変わるとポート番号が飛ぶようになっている。
pythonのように "stcp://sa07.sc.cs.titech.ac.jp:%d/" % (50300 + @i)
などのように実装できればこういう問題は起こらないのだが……
DONE & TODO
DONE:
・入力（認識音声、ビーム幅セット）をTCP経由で行えるように変更
・TCP送信スクリプトも実装
→ 入力データレートを可変にできるようになった
・UDOP_SpeechDecoderにビーム幅変更機構を実装
TODO 学習関連:
・入力（学習音声）の実装
・学習時の入力のデータ区間の設定
→ Punctuate用の特別なユーザIDを設定するなど
→ これにより、学習入力データレートを計測
・を計測する機能の実装
・「ビーム幅とスループットのペアを記録」「スループットを入力、ビーム幅を出力」するUDOPの実装
・入力（認識音声、ビーム幅セット）をTCP経由で行えるように変更
・TCP送信スクリプトも実装
→ 入力データレートを可変にできるようになった
・UDOP_SpeechDecoderにビーム幅変更機構を実装
TODO 学習関連:
・入力（学習音声）の実装
・学習時の入力のデータ区間の設定
→ Punctuate用の特別なユーザIDを設定するなど
→ これにより、学習入力データレートを計測
・を計測する機能の実装
・「ビーム幅とスループットのペアを記録」「スループットを入力、ビーム幅を出力」するUDOPの実装
2010年6月25日金曜日
Julius : システム立ち上げ後にビーム幅を変更
(2010-06-30 free_nodes を fsbeam_free に修正、動作検証)
ビーム幅が動くことを確認
int specified = tuple.get_beam();
for ( FSBeam *r = m_recog->process_list; r; r = r->next ) {
fsbeam_free(&(r->pass1));
r->config->pass1.specified_trellis_beam_width = specified;
r->trellis_beam_width = set_beam_width(r->wchmm, specified);
}
ビーム幅が動くことを確認
Stream SR の拡張性に関する疑問
現在の方針で、ビーム幅の実行時動的変化機構の実装を進めても、これが研究のcontributionに繋がるとは考えにくい。
この機構でできることは
・学習データを用いた最適なビーム幅の設定
・認識負荷増大時、ビーム幅を落とす
などである。
このうち前者は普通、認識実行中に並列して行うということはなく、
システム立ち上げ後、認識実行前にあらかじめ行っておく、という使い方が想定されるが、
これはシステム立ち上げ前に「静的に」利用者がビーム幅を設定するのと大差がない。
利用者側で学習データと簡単なスクリプトを用意して
認識精度（Acc,Cor,Sub,Ins,Del）、実行時間(RTF)を調べて、適切な値を設定してもらえばよいだけの話である。
査読付き論文に通すからには、もう少しcontributionの明確な研究を行うべきだと思うし、
それができないなら無理に論文を通すべきとも思えない。
この機構でできることは
・学習データを用いた最適なビーム幅の設定
・認識負荷増大時、ビーム幅を落とす
などである。
このうち前者は普通、認識実行中に並列して行うということはなく、
システム立ち上げ後、認識実行前にあらかじめ行っておく、という使い方が想定されるが、
これはシステム立ち上げ前に「静的に」利用者がビーム幅を設定するのと大差がない。
利用者側で学習データと簡単なスクリプトを用意して
認識精度（Acc,Cor,Sub,Ins,Del）、実行時間(RTF)を調べて、適切な値を設定してもらえばよいだけの話である。
査読付き論文に通すからには、もう少しcontributionの明確な研究を行うべきだと思うし、
それができないなら無理に論文を通すべきとも思えない。
Julius : ビーム幅動的変更できない？
or 動的変更をするためには、Julius のソースコード自体を変更しないといけない
根拠 :
Juliusにおける初期化（or最初の認識を実行？）後、
ビーム幅(Recog.trellis_beam_width)の値を変更しても
ノードの再確保(malloc_nodes)が実行されない
get_back_trellis_initを呼び出しなおしても、nodes_mallocedがTRUEとなっているため
malloc_nodesが呼び出されない。
（その他、確認できていないところで関連するパラメータの再設定が行われない可能性も。未確認）
参照 :
beam.c:1834: malloc_nodes(d, wchmm->n, r->trellis_beam_width * 2 + wchmm->startnum);
<- pass1.c:234: if (get_back_trellis_init(mfcc->param, p) == FALSE) {
in pass1.c:112:decode_proceed(Recog *recog)
根拠 :
Juliusにおける初期化（or最初の認識を実行？）後、
ビーム幅(Recog.trellis_beam_width)の値を変更しても
ノードの再確保(malloc_nodes)が実行されない
get_back_trellis_initを呼び出しなおしても、nodes_mallocedがTRUEとなっているため
malloc_nodesが呼び出されない。
（その他、確認できていないところで関連するパラメータの再設定が行われない可能性も。未確認）
参照 :
beam.c:1834: malloc_nodes(d, wchmm->n, r->trellis_beam_width * 2 + wchmm->startnum);
<- pass1.c:234: if (get_back_trellis_init(mfcc->param, p) == FALSE) {
in pass1.c:112:decode_proceed(Recog *recog)
2010年6月11日金曜日
音声認識とビーム幅について (ver 0.0.0)
音声認識における統計的手法として，音声の音響的な特徴と言語的な特徴をそれぞれモデルとして学習したもの（音響モデル，言語モデル）を用いる手法が主流であり，音声認識エンジン Julius もこれを用いている．
音響モデル，言語モデルの詳細な説明は省く．
音声認識エンジンでは，モデルに基づいて出力となる認識仮説（文章）の候補の尤度を計算し，最も尤度の高い認識仮説を最終的に出力する．
出力の候補となる認識仮説において，あらゆるパターンを想定するならば，その仮説の数は膨大となってしまう．このため，音声認識エンジンは音声の先頭から逐次的に仮説の生成，尤度の計算を行っていき，途中の尤度の低い仮説は認識の正解となる可能性が低いため，出力候補から除外していく．
ここで，計算過程において認識仮説の候補として保持する個数を「ビーム幅」と呼ぶ．
音声認識エンジンでは，この尤度の計算（＝パス）を二回行う（第一パス，第二パス）．第一パスでは，計算量の少ない（精度が若干低い）手法で尤度の計算を行い，出力候補となる認識仮説の数を絞る．第二パスでは，第一パスで絞られた認識仮説に対して，厳密に尤度の計算を行い，ここで最も尤度の高い認識仮説が実際の出力となる．
---
Stream Speech Recognition（StreamSR）では，この第一パスにおけるビーム幅（第一ビーム幅）を実際の認識を行う前に，あるいは認識を実行している途中で，教師付き音声を学習データとして与えることで，最適な第一ビーム幅の計算を行い，適用する．
---
参考文献
河原達也, 李 晃伸, 連続音声認識ソフトウエア Julius
> http://www.ar.media.kyoto-u.ac.jp/lab/bib/review/KAW-JSAI05.pdf
T. Kawahara, A. Lee, T. Kobayashi, K. Takeda, N. Minematsu, S. Sagayama,
K. Itou, A. Ito, M. Yamamoto, A. Yamada, T. Utsuro and K. Shikano.
"Free software toolkit for Japanese large vocabulary continuous speech recognition."
In Proc. Int'l Conf. on Spoken Language Processing (ICSLP) , Vol. 4, pp. 476--479, 2000.
> http://julius.sourceforge.jp/paper/icslp00-6.pdf
> http://julius.sourceforge.jp/index.php?q=documents.html
村上仁一 , 確率的言語モデルによる自由発話認識に関する研究 (博士論文)
> http://unicorn.ike.tottori-u.ac.jp/murakami/doctor/main.html
音響モデル，言語モデルの詳細な説明は省く．
音声認識エンジンでは，モデルに基づいて出力となる認識仮説（文章）の候補の尤度を計算し，最も尤度の高い認識仮説を最終的に出力する．
出力の候補となる認識仮説において，あらゆるパターンを想定するならば，その仮説の数は膨大となってしまう．このため，音声認識エンジンは音声の先頭から逐次的に仮説の生成，尤度の計算を行っていき，途中の尤度の低い仮説は認識の正解となる可能性が低いため，出力候補から除外していく．
ここで，計算過程において認識仮説の候補として保持する個数を「ビーム幅」と呼ぶ．
音声認識エンジンでは，この尤度の計算（＝パス）を二回行う（第一パス，第二パス）．第一パスでは，計算量の少ない（精度が若干低い）手法で尤度の計算を行い，出力候補となる認識仮説の数を絞る．第二パスでは，第一パスで絞られた認識仮説に対して，厳密に尤度の計算を行い，ここで最も尤度の高い認識仮説が実際の出力となる．
---
Stream Speech Recognition（StreamSR）では，この第一パスにおけるビーム幅（第一ビーム幅）を実際の認識を行う前に，あるいは認識を実行している途中で，教師付き音声を学習データとして与えることで，最適な第一ビーム幅の計算を行い，適用する．
---
参考文献
河原達也, 李 晃伸, 連続音声認識ソフトウエア Julius
> http://www.ar.media.kyoto-u.ac.jp/lab/bib/review/KAW-JSAI05.pdf
T. Kawahara, A. Lee, T. Kobayashi, K. Takeda, N. Minematsu, S. Sagayama,
K. Itou, A. Ito, M. Yamamoto, A. Yamada, T. Utsuro and K. Shikano.
"Free software toolkit for Japanese large vocabulary continuous speech recognition."
In Proc. Int'l Conf. on Spoken Language Processing (ICSLP) , Vol. 4, pp. 476--479, 2000.
> http://julius.sourceforge.jp/paper/icslp00-6.pdf
> http://julius.sourceforge.jp/index.php?q=documents.html
村上仁一 , 確率的言語モデルによる自由発話認識に関する研究 (博士論文)
> http://unicorn.ike.tottori-u.ac.jp/murakami/doctor/main.html
2010年6月9日水曜日
Julius : TODO : 動的な認識パラメータチューニング
システム全体の入力 :
1. 認識対象となる音声
2. チューニング用音声 + それに含まれるべきキーワードリスト（＝学習データ）
1をルートとするストリームグラフと2をルートとするものは「直接的には」連結ではない（非連結グラフ）．
ただし，2のグラフと1のグラフはTCP通信を行う．
2において，パラメータの「指針」を計算し，TCPにSink．
1において，そのTCPからSourceとして受け取り，UDOP_SpeechDecoder の音声とは別の入力として設定パラメータを与える．
UDOP_SpeechDecoder はその値をJuliusに設定する．
------------------------------
問題点：
指針の計算をどう行うか．
学習データごとに，キーワードが正しく認識される認識パラメータの下限を求めた後，それらの値の最大値を指針として与える，など．
最大値とは．
2に与えられた学習データのすべてに対する認識パラメータの最大値とするのか．
（この場合，適当な学習データ数ごとに，入力された学習データの最初から現在までの認識パラメータの最大値を指針として出力し続ける）
本当に最大値でいいのか．
そもそもすべての学習データがちゃんとキーワードを認識できるような音声であるとは限らない．
あらゆる質の音声を認識できるようにしたいのであれば，このような動的チューニングは必要なく最初から大きな値を与えておけばいいのである．
最大値以外のチューニング方法を考えるべき．
------------------------------
参考 :
http://julius.sourceforge.jp/juliusbook/ja/desc_search.html#id2540911
その他の課題：
負荷が高くなったときに認識パラメータを低くする機能の実装
1. 認識対象となる音声
2. チューニング用音声 + それに含まれるべきキーワードリスト（＝学習データ）
1をルートとするストリームグラフと2をルートとするものは「直接的には」連結ではない（非連結グラフ）．
ただし，2のグラフと1のグラフはTCP通信を行う．
2において，パラメータの「指針」を計算し，TCPにSink．
1において，そのTCPからSourceとして受け取り，UDOP_SpeechDecoder の音声とは別の入力として設定パラメータを与える．
UDOP_SpeechDecoder はその値をJuliusに設定する．
------------------------------
問題点：
指針の計算をどう行うか．
学習データごとに，キーワードが正しく認識される認識パラメータの下限を求めた後，それらの値の最大値を指針として与える，など．
最大値とは．
2に与えられた学習データのすべてに対する認識パラメータの最大値とするのか．
（この場合，適当な学習データ数ごとに，入力された学習データの最初から現在までの認識パラメータの最大値を指針として出力し続ける）
本当に最大値でいいのか．
そもそもすべての学習データがちゃんとキーワードを認識できるような音声であるとは限らない．
あらゆる質の音声を認識できるようにしたいのであれば，このような動的チューニングは必要なく最初から大きな値を与えておけばいいのである．
最大値以外のチューニング方法を考えるべき．
------------------------------
参考 :
http://julius.sourceforge.jp/juliusbook/ja/desc_search.html#id2540911
その他の課題：
負荷が高くなったときに認識パラメータを低くする機能の実装
Juliusパラメータとレイテンシ，スループット
-b, -b2, -sb, -m, -n
のパラメータを適当に動かして計測
結果より，-b 以外のパラメータはデフォルト値の付近では
あまりレイテンシやスループットに影響をもたらさない（？）
大きな値を設定するようにすると変化が生じるかもしれない
（議事録の作成などでは，デフォルト値よりもかなり大きな値を使う）
---
実験結果や資料などをweb上にアップロードしたいが
このブログ上ではできないし，研究室のgoogleサイトも容量の問題がある
どこか適当な場所はないだろうか
自分のdropboxアカウント上に上げる，という手もあるけど……
のパラメータを適当に動かして計測
結果より，-b 以外のパラメータはデフォルト値の付近では
あまりレイテンシやスループットに影響をもたらさない（？）
大きな値を設定するようにすると変化が生じるかもしれない
（議事録の作成などでは，デフォルト値よりもかなり大きな値を使う）
---
実験結果や資料などをweb上にアップロードしたいが
このブログ上ではできないし，研究室のgoogleサイトも容量の問題がある
どこか適当な場所はないだろうか
自分のdropboxアカウント上に上げる，という手もあるけど……
2010年6月2日水曜日
StreamJulius : TODO : jconfと応答速度，スループットの評価
-b, -b2, -sb, -s, -m などのパラメータをデフォルトの値より低くした場合の
応答速度，スループットの変化を調べる．
すべてのパラメータを動かのは実験のパターンが増えすぎるので，
実験の際は一つを除いたパラメータをデフォルトの値に固定する．
ソース数は4，コア数は16で行う．
応答速度，スループットの変化を調べる．
すべてのパラメータを動かのは実験のパターンが増えすぎるので，
実験の際は一つを除いたパラメータをデフォルトの値に固定する．
ソース数は4，コア数は16で行う．
StreamJulius : スケールアウト実験結果
前回と同じコンフィグ，テストデータを使い，ソース数4で実行
コア数のみを変動させる．
1,2,4コアの場合はst05のみ
8コアの場合はst05～06
12コアの場合はst05～07
16コアの場合はst05～08
を認識用ノードとして使用した．
結果
各コア数の設定に対して一回しか実験を行っていないので，
統計的な信頼区間は不明
コア数のみを変動させる．
1,2,4コアの場合はst05のみ
8コアの場合はst05～06
12コアの場合はst05～07
16コアの場合はst05～08
を認識用ノードとして使用した．
結果
コア|スループット
|話者数| mbps
1| 3.68| 0.94
2| 6.49| 1.66
4| 11.61| 2.97
8| 22.93| 5.87
12| 33.46| 8.57
16| 43.57|11.16
各コア数の設定に対して一回しか実験を行っていないので，
統計的な信頼区間は不明
登録:
投稿 (Atom)