少し時間を取ってやってきたので、なんでこの作業をやっていたかを折にふれ
反芻してました。下記のようなことです。
(1) libanthy のなかでは一番 src-splitter/depgraph.c の
anthy_scan_node の処理 (match_branch, match_nodes)の処理が重い。
NFA を動かして、付属語の可能性を全部列挙しているところ。
ここは現状の実装において第一の改善点であろう。
(2) depgraph は実装の面だけでなく、仕様としてなにがやりたいのか、結果
としてなにができているのか、技術的に今ひとつの感がする。
(3) 「付属語」を独自の翻訳で depword と呼んでいるところ、現実装からす
れば有限状態オートマトンのところを graph と呼んでいるところでイケ
てない感じが漂う。
(4) alt-depgraph の変更(結構大規模)を採り入れるには、現状では無理かも。
特に、(1) の実装の面から、遅い libanthy がさらに遅くなるので整理
してからじゃないとイカン。
(2010年07月31日 15:27), NIIBE Yutaka wrote:
> まぁ、これって(現状でも)やりすぎで、あまりデキが良くないかもしれません。
depgraph は付属語を認識するだけでなく、付属語の属性(H, C, S)を扱います。
この属性のデキはかなり微妙です。同じ文字列でも属性の違いがある複数の可
能性をすべて列挙するようになっています。
> calctrans/proccorpus の出力で付属語の長いのを見てみると
calctrans/proccorpus の出力ですが、ブランチ feature/ancill-words-dfa で
ブランチ master と結果が異なります。これは、master の NFA が
anthy_commit_word_list を呼んで列挙する結果(depth first search)と
feature/ancill-words-dfa の DFA が accepting state について
anthy_commit_word_list が呼ぶところで(sort してある)結果を列挙するとこ
ろで、内容が同じだけども順番が異なるため、と考えられます。
calctrans/proccorpus の作りは、同一の付属語があっても、加点/減点は、た
またま先頭にきているそのうちの一つだけ、というものなのかもしれません。
結果に影響が出ないような謎の内部状態をたくさん持っていている実装は、つ
まみがたくさんあるおもちゃのような感じで、いろいろといじるには満足する
向きもあるかもしれませんが、大人はそういうのはいらないなぁ、と思いまし
た。
付属語の処理で頑張って属性を計算していても、それはあんまり利用されてい
ません。また、頑張っている属性の計算もルールが正確に記述されていないみ
たいで少なくとも属性については今ひとつ正確さにかける感じがします。利用
されていないので正確さも追求されてなかったのでしょうか。
揺れる仕様の属性の扱いは(やるとしても別のところでやるとして)削り、
付属語認識オートマトンだけをコンパクトに実装するのが良い、と感じます。
また、calctrans/proccorpus の出力を見比べて思ったのは、feature_set もイ
マイチ感漂うところです。
現状の feature_set の処理と、コーパスによる feature_set の頻度の計算
は、別の実装が望まれる所でしょうか。
別の実装とするのであれば、
* 結果に影響を及ぼす内部状態が何であるか明確な仕様があるべき
* メカニズムは well defined に。
* 入力は通常の仮名漢字まじり文とする(文節区切り、読みは入力に無くてよい)。
* たくさん文章を与えて、学習させるというモデル。
というのが良いだろうなぁ、と考えています。
--
_______________________________________________
Anthy-dev mailing list
[email protected]
http://lists.sourceforge.jp/mailman/listinfo/anthy-dev
