スケジュール管理（研究的な意味ではなく）

自分がいつ授業があるか、いつの就職説明会に興味があるか、いつレポート締め切りに追われているか、いつ試験があるか、いつ東京を離れているか、etcetc...、などの情報は逐次カレンダーに追加しています

http://www.google.com/calendar/embed?src=fpmuacke.2c%40gmail.com&ctz=Asia/Tokyo

万が一、私のカレンダーの閲覧権限を持っていないという方がいらっしゃいましたら、ご連絡ください

StreamGraph 研究の方向性とか

グラフ関連の研究ということで、2つのビジョンがある。

1. 既存のバッチ型グラフ処理システム(ex. PEGASUS(GIM-V))のGPU高速化
2. Framework for incremental graph processing
   

前者について

• PageRank, RWRなどのGPU実装に関する研究は既にある
• GIM-Vはそんなに汎用的な計算モデルでもない
• ⇒GIM-VをGPU実装しても、既存研究に対してあまり差別化できない？
  

のであまり研究テーマとして魅力を感じない。

後者の方を見ると

• incrementalなPageRank計算アルゴリズムが存在
• ⇒各マイニングアプリケーションに特有のインクリメンタルな計算モデルはある
• 汎用的なインクリメンタルなグラフ処理の計算モデルを提唱したい
  

インクリメンタルグラフ処理システムの研究を行うために

• インクリメンタルGIM-V (or other) を実装
• その上でPageRankアルゴリズムを実装
• バッチ処理とのgapを調べる
  

===
まとめ：やりたいこと

• インクリメンタルなグラフ処理の計算モデルの提唱

まずはじめに

• incrementalなPageRank計算アルゴリズムについて理解
• incremental GIM-V (or other) on System S (or Hadoop, or StreamScale) の実装
  

メモ

並列分散環境下におけるデータストリームグラフ処理に対して、ネットワークインテンシブなアプリケーションのための、ネットワークコストを削減するデータ（タスク）配置手法を考える

……その前に、
・バッチグラフ処理での配置手法に関する研究を調べる
・バッチ処理一般（MapReduceなど）における配置手法に関する研究を調べる

===================================
そもそも研究がどういう方向性に行くのかまだ決まっていない……アイディアがどこからともなくふってくるわけでもないので、いろいろ調べてみるしかないのかも

個別ミーティング 2010.11.29 Mon.

StreamGraph
・PEGASUSの動作モデルの理解（実行を通じて）⇒pptにまとめる
・Spade上でMapReduce的な反復処理の実装（案）
⇒これだけだとあまりストリーム的な要素がない
・ストリーム的な要素のアイデアを考える

ストリーム的な要素で簡単なものとしては、反復計算の途中に割り込んで
トポロジーの変化をする(頂点、辺の追加、削除）などが考えられる

メモ : StreamGraph 思考メモ

大規模グラフ処理におけるデータ分散手法
・各タスクが必要とするデータは、どのノードが保持しているか
・（ローカルデータだけで処理できるのか）
・バッチ処理、データストリーム処理を問わず
・既存手法
・・Pregel →
・・・各タスクの分散 : Hash(id) mod N
・・・メッセージパッシング、ローカルデータのみ
・・PEGASUS →
・・・Mapタスク、Reduceタスクの分散はHadoop依存
・・・データはOutput関数で渡し、Map、Reduce関数の引数で受け取る
・・・各タスクが必要とするデータはローカルデータのみ（HDFSは使わない）

GIM-V の SystemS 上実装
・研究の方針としては、数多くあるグラフアルゴリズムに対する汎用性はそんなに考えなくてよい？
・（GIM-V のように特定のアルゴリズムだけ解ければよい？）
・GIM-V のナイーブ実装、高速実装をまず理解する必要がある
・SystemS の UDOP のフィードバックループで実装できる？
・オリジナルの GIM-V は（多分）ユーザ操作による辺、頂点の追加、削除を考慮していない？（そういう機能を持たない）

GIM-V BASE implementation (IV. A)
・行列のうち値を指定していない（空）箇所はcombine2の計算がされない
・→疎行列でもそれなりに効率が良い（多分）

==============================

GIM-V拡張で辺の追加、削除を実装するのは、行列Mの値を更新すればいいだけなので多分簡単。問題は頂点の追加、削除で、行列M、ベクトルVの大きさが変化することになるので困難。

==============================
(2010.11.30 Tue.)
GIM-Vの反復の終了
PageRankを例にする。(src\pegasus\pagerank\PagerankNaive.java)
反復処理を行っているのが383～404行。
終了条件は、
1. ベクトルの値の変化がなくなったとき
2. 規定回数反復を行ったとき

1については、PageRankの値がスレッショルド(converge_threshold==0.000001)以上の変化が生じなくなった時を指す。（186～190行）
2については、デフォルトの規定回数は32回(niteration==32)となっている。

==============================
(2010.12.01 Wed.)
バッチ処理におけるデータ量爆発と、データストリーム処理におけるそれとの違いが判らない……

==============================
(2010.12.03 Fri.)
ストリーム処理向けグラフ処理のアプリケーション
http://suzumura-lab.blogspot.com/2010/11/streamgraph.html

膨大（かつstatic）なWebグラフに対するPageRankの計算を計算しているところで最も有名なのはGoogleだと思うが、そのGoogleでもPageRankの更新を行うのは2～4ヶ月に一度程度。こういった用途であればバッチ処理的に行うのが適切だろう。

ストリーム的なPageRankの計算となると、ミニブログやブログ、SNSなど話題の生起が頻繁（数日レベルのものから数時間レベルのものまで）なものが対象だろうか。
対象（頂点）は、ユーザレベルか、投稿レベルか。
辺は？

TODO list 20101117 Wed. (StreamGraph)

• PEGASUS, Pregel の動作原理を理解
• それぞれの計算モデルの応用性を把握（何に向いているか、いないか）
• ストリーム処理に向いているか否か考察
  
• System SなどDSMS上で実装するにはどうすればいいか考察
  

===
GIM-V(PEGASUS)計算モデルの高速実装は論文をちゃんと読んでちゃんと実装しないといけないので、時間がかかるかも
ナイーブ実装ならばそんなに難しくない？
===
PEGASUSの分散手法を理解する前に、MapReduce(Hadoop)の分散手法（Mapタスク、Reduceタスク、データ）を理解する必要がありそう？

メモ : Efficient PageRank on GPU Clusters

http://www.ipsj.or.jp/09sig/kaikoku/2010/ARC184HPC128.html
===
（22）Efficient PageRank on GPU Clusters
　　　○Cevahir Ali（東工大），Aykanat Cevdet，Turk Ata（Bilkent大），
　　　Cambazoglu B. Barla（Yahoo! Research），Nukada Akira，Matsuoka Satoshi（東工大）
===
GPGPUを使ったグラフ処理の研究自体は当然既にある

PEGASUSの各アルゴリズム

Degree, PageRank, RWR など各種アルゴリズムがデフォルトで実装されている
デモの実行方法やスクリプトの場所などはマニュアルpdfを参照

例 : Degree
実行スクリプト : run_dd.sh
デモスクリプト : do_dd_catstar.sh
Javaプログラム : src/pegasus/degdist/DegDist.java

マニュアルpdfにはアルゴリズムの実装の詳細などは載っていないので、詳しく知りたければ元論文を読むなりすること

---

グラフの記述方法
頂点は番号(o-origin)で識別される
（Pregelのように文字列形式の識別子を持つわけではない）
辺は、ソース頂点番号、デスト頂点番号の対で表す

具体例を見ればわかると思う(catepillar_star.edge)

---

PEGASUSは、Hadoopを利用したグラフアルゴリズム処理システム。
MapReduce計算モデル上でグラフアルゴリズムを処理する。
アルゴリズムの「いくつかは」、GIM-Vというモデルに基づいて実行される。
（すべてのアルゴリズムがGIM-Vを用いているわけではない）

……GIM-Vを利用しているのはアルゴリズム実装であって、PEGASUSのフレームワークレベルが利用しているわけではない

[UNIX一般]ライブラリ検索パスの設定

システムに直接インストールしていないライブラリを参照したい場合
（/usr/lib /usr/local/lib 以外にライブラリを置いている場合）

環境変数 LD_LIBRARY_PATH LIBRARY_PATH などで設定すればよい

[TODO: インクルードパスについても調べる]

PEGASUS on Ubuntu on VM

動作テストまで。とりあえず動いた(2010.11.11(Thu.))

Parallel BGLをあきらめる？

うまくビルドできないので、
・Apache HAMA
・PEGASUS
などを動かすことを考えてみる？

Parallel BGL on Ubuntu on VM その2

うまくいかなかったメモ

Parallel BGL on Ubuntu on VM

Ubuntuのディストリに含まれるboostを使おうとしてうまくいかなかったメモ

全体ミーティング

Query-Aware Partitioning for Monitoring Massive Network Data Streams の紹介

今期取る授業

月
5,6 W833 村田 ★機械学習
7,8 W531 古井 ★音声情報処理特論

金
1,2 W831 渡辺 オペレーティングシステム特論
3,4 W831 米田 フォールトトレラントシステム論
7,8 S321 原崎ほか (他専攻)通信システム論

[全体ミーティング]2010.10.13 (Wed.)

（個人的な話）
やはり練習していない発表では説明がしどろもどろになってしまう。
練習する機会がある発表はともかく、そうでない場合でもうまく発表できるようになりたい。

（StreamSR）
もっと詳しく説明すべき点はノートにまとめておいた。

（論文紹介）
もっとちゃんと読もう。次回発表続き。
Query-Aware Partitioning for Monitoring Massive Network Data Streams
Chain: Operator Scheduling for Memory Minimization in Data Stream Systems

[個別ミーティング]2010.09.27(Mon)

1. IC2010カメラレディ原稿の修正、提出
2. 全体ミーティング(2010.10.06(Wed))について
2.1. StreamSRについて紹介
2.2. 論文について簡単に（サマリーで）紹介。1論文あたり1スライド
2.3. 自分の興味について、その後の研究テーマを踏まえて

StreamSR : IC2010論文修正メモとか

冷静に考えると一括処理は逐次処理より優れているわけではない。

よく考えてみれば大事なのは「スレッド数」に対するスループットではなく「コア数」に対するスループットですし、逐次処理で1スレッド辺りのCPU使用率が下がるのならば、それに応じて1ノード（or1コア）に対するスレッド数を増やせばいいだけなので、「逐次処理はCPU使用効率が悪い」は明らかに誤りでした。

実際のところ、一括処理を選んだ理由はそのほうが実装が楽だったからにすぎない。
（libjuliusとSPADEの兼ね合いとか、ひとつの音声を複数タプルにわけて管理する面倒さとか）

可能ならば逐次処理で実装するべき。その方法としては、
1. libjuliusを使う
1.1. 認識処理をSPADE外部で実行し、source/sinkあるいはsource/UDOPなどで認識処理エンジンとやり取り
1.2. libjulius自体を大きく改造し、UDOP内でうまく連携できるようにする（困難）
2. libjuliusを使わず自前で認識エンジンを実装（困難）
など。

1.1. が割と楽な方法。
認識エンジンの管理をUDOPにさせるなどすればよい。
認識エンジンの出力はsourceなどで受け取る。

---

とりあえず、一括処理を採用した理由を論文中にどう書くべきか、うーむ。

Springer LNCS camera-ready format

DASFAA2011で使用。
下記のURIからダウンロード可能。

www.springer.com/computer/lncs?SGWID=0-164-6-793341-0
LNCS Proceedings and Other Multiauthor Volumes - Using LaTeX2e

今後の研究を始める前に

今回の研究(StreamSR)は，自分の中ではもともと単なる演習であって，これ自体を研究として発表することになるとはまったく考えていなかった．そのため，十分に関連研究を調べたりしていないため，既存研究との位置づけおよび研究の価値について今一把握しにくいことになってしまった．

今後は，研究室で始めるあらゆることについて，それが研究につながる可能性が『少しでも』あれば，行動を始める前にとにかく関連研究を調べ，わからなければまずどのような研究があるか伺うところから始めたい．そしてこれから始めることが既存の研究に対してどのような位置づけになっているのか把握すること．

何もわからないまま実際に手を動かしてみるところから始めるのはとにかく避けたい．

（さもないと論文で「研究の背景」や「関連研究」を書くときに苦労することになるので）

所感

研究読本 Ver 1.7 植松友彦@東京工業大学(URI先PDF)
www.it.ss.titech.ac.jp/uyematsu/howtoresearch

---

自分に足りないもの
・物事を数理的に理解する能力（理論、数学力）
・文献を読み知見を得る能力
・・・その他たくさん

理論周りの勉強や、多くの文献を読むことをないがしろにしてきているので、
このあたりをしっかりとできるようにしていきたい。

逐次音声処理と一括音声処理

（名称は仮のものです）

【前提】
音声処理の所要時間のRTF（実時間係数）とは、処理時間を音声時間で割った値である。
以下におけるレイテンシの議論では、入力データレートがシステムの同時処理限界人数よりも小さい状態を仮定している。

【逐次音声処理】
逐次音声処理は、クライアント側が発声を開始してから逐次エンコーディング、サーバへの送信、音声処理を行っていく方法である。発声が完了しなくても音声処理を開始することが出来るため、発声終了から音声処理を開始するよりも応答時間が短くなる。

音声長を x、音声処理時間のRTF を k, ネットワークなどの固定レイテンシを L とおくと、発声終了からのレイテンシは k が 1.0 よりも大きい場合
　　　　≒ (k - 1.0)x + L
と定式化できる。

逆に、k の値が 1.0 より小さいか同程度である場合でも、発声が完了しないと実行できない処理もあるため、レイテンシは
　　　　≒ pkx + L
となる。p は音声処理のうち発声が完了してから開始される処理の所要時間の、全処理時間に対する比率 (0 ≦ p <1.0) ならば同時処理限界人数は
　　　　≒ n / k
となるが、一方 k ≦ 1.0 の場合、
　　　　≒ n
となり、サーバの台数以上に同時処理限界人数を増やすことは出来ない。

【一括音声処理】
一括音声処理では、クライアント側で発声が完了してから、一括でサーバに送信し、音声処理を始める方法である。この手法でのレイテンシは
　　　　≒ kx + L
となり、逐次音声処理よりもレイテンシが明らかに大きくなってしまう。これはリアルタイム音声処理では致命的である。

（RTF 1.3 ならば、10秒の音声に対して逐次だと 3+L 秒で済むところが、一括だと 13+L 秒もかかってしまう）

一方スループットは、k の大小に関わらず
　　　≒ n / k
となり、これは RTF が 1.0 よりも小さい場合に同時処理人数が大きく向上することとなる。

つまり、一括音声処理の逐次音声処理に対するアドバンテージとは、音声処理の RTF を 1.0 よりも小さく出来るときに、スループットを向上させることが出来る、という点にあるといえる。

SystemS : TCP周りのメモ

stcp: 経由の user-defined source operator では、通常のソケット通信（サーバ）と異なり、クライアントからの接続が終了したか、を確認することが出来ない。
C や Python などのソケット通信では recv() 関数の戻り値などからそれを判断できる。

SystemS だと、クライアントからの入力途中に突然接続が切れた場合、データが中断されたことを udf-source 内で把握できない。
このため、後続する別のクライアントからのデータを、以前のクライアントからのデータの続きとして扱ってしまうことになる。
（udf-source の実装にもよるが）

このことも少し関連してきて、SystemS 内部での逐次音声認識処理の記述が困難になっていた。

StreamSR : 要求入力レート、スループット

入力コア数1、認識コア数4、ビーム幅1500（その他省略）の設定のもとで、Streams内部で求めたスループット限界の値は（音声時間vs実処理時間） 2.21 である。

この条件下で、要求入力データレート（Streamsの外でInputTimeを付与）を 0.5 , 1.0 , 2.0 , 3.0 , 6.0 と変化させたときの、テストセット（音声ファイル30個）に対するレイテンシ、および音声時間を図示する。

図より、入力データレート 0.5 , 1.0 （2.21 より低い）ではレイテンシはほぼ音声時間に比例する値で、これは認識処理自体のレイテンシのみが現れる結果となっている。

一方、入力データレート 3.0 , 6.0 などスループット限界より大きい値のときは、認識コアの処理待ちにより、レイテンシが大きく増大している。

この入力データレートの値は、Streams内部からでも参照可能なので、この値を元に最適ビーム幅を決定することが可能である。

（余談）
図の結果だと入力データレートが低いときでも、例えば10秒の音声に対して15秒ものレイテンシがかかっている。これはリアルタイム音声認識としてはちょっとレイテンシが大きすぎると思う。
レイテンシの下限値については、認識コア数を増やしても（スケールアウトしても）変わらないので、もっと基本的な部分でスケールアップするべき（ビーム幅を下げるとか）。

StreamSR : 負荷の指標

■現在の負荷の指標
AGG_RANGE = 6
最新 AGG_RANGE サンプルから計算される、アイドル時間も含めた、瞬間平均流速
sum(nsamples)/(max(otime)-min(itime)) * 定数

■その値の時間的変化
（入力コア : 1、認識コア : 4）
グラフは、tcpを経由してディレイを与えずに順次データを送信し続けた場合の
瞬間平均流速の変化をプロットしたものである。

見てのとおり、最大スループットが現れるのは入力系列の最初のほうのサンプルである。
バッファリングが生じていないため、itime計測から認識を経てotime計測までの時間が短くなるからである。
このような最大スループットの値からビーム幅変更のスレッショルドを求めるのは難しい気がする。
あるいは、ビーム幅の候補を手動で与えるのと同様に、スレッショルドも手動で与えてもらうような実装なら簡単かも。

最大スループットにある定数 k (0 < k < 1) を乗じた値を
ビーム幅変更のスレッショルドにする、というのも学習機構の簡単な実装の一つ。

StreamSR : 微妙な問題、など

■なぜかstcpが動かない
netstat -l してもポートが表示されない
(追記 : 20100723 Fri)
なんかよくわからないけど直ってた。
start_streams を実行するノードの問題だろうか？
とりあえず se00 から実行すれば問題なさそう

■現実装の思想と実際
（思想）
低負荷時（要求入力速度＜認識限界スループット）であれば
レイテンシは認識速度のみに依存
低認識精度でも高認識精度でも、認識処理以外にレイテンシが引っ張られることはない

高負荷時（要求入力速度＞認識限界スループット）であれば
高認識精度だとバッファリングが生じるため
低認識精度時に比べレイテンシが激しく増大する

なので高負荷時には認識精度を低く、低負荷時には認識精度を高くしたい

負荷を測る指標として、認識器のアイドル時間も含めた瞬間平均流速を用いる。
この値が指定した範囲に含まれるとき、その範囲に該当するビーム幅を設定する、という実装

（問題）
この「負荷の指標」は正しく負荷を表しているか？
また、「負荷の指標」の値は現在のビーム幅にも依存してしまうという問題もある

（以下、要言語化）
やればわかる。学習機構自体は再考の必要あり？
あるいはごく簡単な学習機構のみを作り、手動で学習済みパラメータの入力も可能にする
学習機構のより適切な実装については論文中で「今後の課題」として書く。

論文の背景：オフライン音声認識、オンライン音声認識などの研究は今までなされてきたが、今日ではデータストリーム処理の重要性なども関連してきて、大規模な同時音声認識をDSMS上で行うことも重要な課題となっている。

StreamSR : スケールアウト性

JNASモデルを用いてJNASテストセット（約20分音声)を評価
ビーム幅は500,4000,8000の三通り
ビーム幅以外の設定値については割愛
ソースノード数1、認識ノード数4

赤線が認識時間(RTF)である。ビーム幅に応じて増加している。
緑線が誤認識率(WER)である。ビーム幅を落とすと誤認識率は増えるが、逆にビーム幅を一定程度以上高くしても誤認識率はあまり下がらなくなる。

StreamSR : 論文構成メモ

タイトル : データストリーム処理系を用いたスケーラブルな音声認識

・ Abstract
1. 導入
　- DSMS
　　- 非構造化データ (音声)
　　- 背景 : コールセンターの顧客満足度向上など
　　- VoIP (インターネットコンファレンスなので)
　　- Streams + Julius を用いて実装した
　- スケーラビリティ
　　- 認識ノードをスケールアウトすることによりスループットが向上
　　- 負荷向上時にビーム幅を落として認識精度を犠牲にレイテンシ、スループットが向上
2. 前提知識
　- Streams
　- Julius
　　- 主にビームサーチについて
3. システムの実装
4. 実験
　- 実験条件
　　- 認識ノードのマシン構成
　　- 認識器、音響モデル、言語モデル、テストセット
　- スケールアウトの実験
　　- 認識精度
　　- スループットの変化
　- 負荷増大時ビーム幅変動機構の実験
　　- ビーム幅可変時、固定時（いくつかのビーム幅）で比較
　　- 認識精度、レイテンシ
　- 考察
5. 結論
・ 参考文献

StreamSR : バグメモ

InputParser周りにバグがあるのでリビジョン4以前のStreamSRは使わないように

StreamSR : ビーム幅学習（案）

--- 学習 ---
いくつかのビーム幅の値について、そのビーム幅でのスループットの最大値を計測する。
ビーム幅 : {b[0], b[1], ..., b[n-1]} , 最大スループット : {mth[0], mth[1], ..., mth[n-1]}

--- ビーム幅設定 ---
b[0] < b[1] < ... < b[n-1]
mth[0] > mth[1] > ... > mth[n-1]
n >= 3
を仮定する。

現在のスループットを th として、以下のようにビーム幅を設定

for ( i = n - 1; i >= 2; --i ) {
  if ( mth[i] >= th ) {
    setBeam(b[i - 1]);
    return;
  }
}
setBeam(b[0]);

上記のアルゴリズムからは、ビーム幅の値が b[n - 1] に設定されることはない。

StreamSR : ビーム幅vsスループット

比較的うまく動いたときの結果。これよりも変な結果になることもあり。
この学習を基にビーム幅決定機構を作る。

StreamSR : 評価の基準（応答時間）

1. 話者が発話を開始する
2. 話者が発話を終了し、クライアントプログラムが発話データをまとめる
3. クライアントプログラムがTCP経由でサーバにクエリを送る
↓
4. サーバがTCP経由でクエリを受け取る
5. クエリを処理する（音声認識処理）
6. サーバからTCP経由でクライアントに認識結果を送る
↓
7. クライアントが認識結果を受け取る

2.の終了から7.の終了までの応答時間を小さくすることを目標とする
---
模擬実験では、実際には発話はすでに完了しているため、
スケジュール表を元に、一定のタイミングで発話が完了したものとして
その時刻から応答時間を計測する。
「実際にTCP送信を始めた時刻」ではなく「スケジュール表に基づく発話終了時刻」
からの計測であるという点がポイントとなる。

StreamSR : 入力データレートとスループット

「CPUインテンシブならば入力データレート ∝ スループットになる」というのは思い込みだった。
同じ実験で測定した入力データレートとスループットを図示する。
下図を見る限り、入力データレートではなくスループットで学習すればうまくいくかも？

学習の方法、ビーム幅の決定方法は未定

StreamSR : ビーム幅と入力データレート

トリビアルなテストデータを用いて、ビーム幅に対する入力データレートを測定した。
ソースノード数 : 4、認識ノード数 : 16

一回目（認識ノードのCPU使用率は100%）


二回目（CPU使用率不明）


---
補足

ビーム幅を x と置くと、音声処理時間（実時間係数 : RTF）は Ax+B で定式化される（はず）
データ入力でバッファリングが起こる、などの関係上、入力データレート ≒ スループット となる。

なので、入力データレート ∝ 1/(Ax+B) になる（はず）

---
確認事項

/tmp/ /dev/shm/ などにファイルを置いて試してみる。
今回のテストでは低いビーム幅から高いビーム幅の順にスクリプトを回したが、
逆に高いのから順にすると結果が変わるか確認。

StreamSR : 入力ボトルネック

以前からの変更点
・システムの入力を file: から stcp: に変更
・学習ユニットと認識ユニットを統合

問題点
・stcp: に変更したからなのか、入力データレートが非常に低い
・認識ノードのCPU使用率が100%までいかない

解決案
・無理矢理すべての入力をひとつの file: からの入力にまとめる
・stcp: を使う場合、TCP入力スクリプトを改良、音声形式をMFCCに変更、など

StreamSR : 現状メモ(2)

（言語化されていない記事）

学習ユニット
Decoderでスループットが低い場合、当然それに従って、バッファリングが生じて入力データレートも低くなってしまう。（ボトルネック）

それでも、学習ユニット内のデコーダの数を一つに限定してしまえば、ビーム幅vsスループットの学習はできる。

問題は、「認識ユニットの入力データレート増大時にビーム幅を下げる」機能の実装である。
当然だが、認識器のスループット≦入力データレートにしかならない上に、
ボトルネックの影響があるので「ボトルネックがなかった場合の」入力データレートを知ることはできない。
（この値がわかるのであれば、それに応じてビーム幅の変更が可能である。）

---

ビーム幅vsスループット、あるいはビーム幅vs（ボトルネック付き）入力データレートの学習はできるので、現在の観測された入力データレートが学習値に近づいた場合にビーム幅を下げる、というような実装ならば可能。

User-defined sources are able to produce multiple streams.

IBMInfoSphereStreams-LangRef.pdf の28ページ (35/100) より

StreamSR : 現状の問題

ユーザ定義ソースからpunctuation0()が送られていない？

(追記 : 20100702)
先生に教えてもらった -o オプションが spadec --help から見つからなかった。
-U オプションかな？と思って試してみたけど、うまくいかなかった。

(追記2 : 20100707)
うまくいった。単純に punctuation を送るところまで処理がいっていなかっただけらしい
修正

StreamSR : 学習とは

ここでいう学習とは、写像 f:X→Y (X : ビーム幅 , Y : スループット)
を推定することである。

認識処理はビーム幅に対する線形時間＋固定時間で行うことができる（と思われる）: Ax+B
すなわち、ビーム幅に対するスループットは 1/(Ax+B) で表され、目的はこのAとBの値を推定することになる。

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)
などのように実装できればこういう問題は起こらないのだが……

DONE & TODO

DONE:
・入力（認識音声、ビーム幅セット）をTCP経由で行えるように変更
・TCP送信スクリプトも実装
→ 入力データレートを可変にできるようになった
・UDOP_SpeechDecoderにビーム幅変更機構を実装

TODO 学習関連:
・入力（学習音声）の実装
・学習時の入力のデータ区間の設定
→ Punctuate用の特別なユーザIDを設定するなど
→ これにより、学習入力データレートを計測
・を計測する機能の実装
・「ビーム幅とスループットのペアを記録」「スループットを入力、ビーム幅を出力」するUDOPの実装

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の明確な研究を行うべきだと思うし、
それができないなら無理に論文を通すべきとも思えない。

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)

音声認識とビーム幅について (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

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

その他の課題：
負荷が高くなったときに認識パラメータを低くする機能の実装

Juliusパラメータとレイテンシ，スループット

-b, -b2, -sb, -m, -n
のパラメータを適当に動かして計測
結果より，-b 以外のパラメータはデフォルト値の付近では
あまりレイテンシやスループットに影響をもたらさない（？）

大きな値を設定するようにすると変化が生じるかもしれない
（議事録の作成などでは，デフォルト値よりもかなり大きな値を使う）

---

実験結果や資料などをweb上にアップロードしたいが
このブログ上ではできないし，研究室のgoogleサイトも容量の問題がある
どこか適当な場所はないだろうか

自分のdropboxアカウント上に上げる，という手もあるけど……

StreamJulius : TODO : jconfと応答速度，スループットの評価

-b, -b2, -sb, -s, -m などのパラメータをデフォルトの値より低くした場合の
応答速度，スループットの変化を調べる．

すべてのパラメータを動かのは実験のパターンが増えすぎるので，
実験の際は一つを除いたパラメータをデフォルトの値に固定する．

ソース数は4，コア数は16で行う．

StreamJulius : スケールアウト実験結果

前回と同じコンフィグ，テストデータを使い，ソース数4で実行
コア数のみを変動させる．

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

各コア数の設定に対して一回しか実験を行っていないので，
統計的な信頼区間は不明

StreamJulius : 動作確認実行

M=5, N=16

音声ファイルとして4.11秒のファイルをひとつ用意 (test1.wav)
これを150個並べただけの入力ファイルを5個用意．

結果，レイテンシの最小値は1.31秒，最大値は14.86秒となった．
（後のほうの入力のほうがレイテンシが大きくなるのは当たり前である．
レイテンシを評価基準にする場合，このあたりをどう説明するか）
また，スループットの値は総発話時間／総処理時間で求めたところ
43.43となった．

---

ちゃんとしたテストセット（ファイルごとに発話時間が異なる）を使って実験を行いたい

解決 : StreamJulius : PE数がおかしい

なんのことはない，spadecのオプションに
-p FMAN
を付け忘れていただけだった．

StreamJulius : PE数がおかしい

（解決済み）

ソースプロセス数M，デコーダプロセス数Nとなるように
かいたspadeのプログラム（UDOPは空）をコンパイル
してみたところ，コンパイル時に出力されるPE数が
想定している値と異なってしまう．

sa07をソースと時間計算，sa08をシンク，
st05から08をデコーダに割り当てているのだが，
想定しているPE数が

sa07: M+1
sa08: 2
st05 + st06 + st07 + st08: N
合計: M+N+3

なのに対して，実際にコンパイルしてみると

sa07: 3M+1
sa08: 2
st05 + st06 + st07 + st08: 2N
合計: 3M+2N+3

となってしまう．

ソースコード:
/nfs/home/nishii/work/streams/test/julius_st2/julius_st2.dps

libsentの定数LOG_DEBUGがStreamsの何処かと名前衝突

libsent/include/sent/stddefs.h - L.171
の LOG_DEBUG が，
おそらく Streams 上のマクロと名前がかぶっているらしく，
このままでは，UDOPヘッダ上で
#include
とするとUDOPをコンパイルできなくなる．

なので，この LOG_DEBUG を適当な名前(DUMMY_LOG_DEBUG)に
置き換えたヘッダファイルをインクルードするようにしてUDOPをコンパイルする．

なお，このダミーのヘッダファイルは，libjulius/libsent のコンパイルには
使わないこと．

参照 : /nfs/home/nishii/work/julius-4.1.4-fpic/libsent/include.fix4streams

StreamJulius ソースデータ

Streams側をサーバ(stcp)としてTCPで通信
（テスト用にはfileから）

データ構造
UserName: char[] (end with '\0')
DateTime: char[] (end with '\0')
NumSamples: uint32_t
Samples: sint16_t[NumSamples]

バイトオーダは、ネットワークの作法に従ってビッグエンディアンにするべき？

現状1

done:
Juliusのコールバック関数を実装できる状態にした

todo:
StreamJulius向けのコールバック関数の実装
StreamJuliusのUDOPの実装
ユーザ定義ソースの実装
？認識結果を使った何らかのアプリケーション（フィルタリング？）

とりあえずユーザ定義ソースから手をつける

test

てすと