私のブログ『kiyoka日記』を見ながら過去を追跡した結果です。
実はあんまり高度な話題はいまでも理解仕切れていません。
読んでいる内にSumibiはそんなに高度な数学を使わなくてもできる筈というのが分かってきた
SumibiWebAPI として定義されている
日本語変換エンジンは反応速度においてシビアな要求がある。MySQLはまずまずの性能
場合によってはschemeでやるより宣言的な簡潔な記述が可能
トランザクション処理が標準装備されているのでSumibiエンジンを運用(read)しながら、辞書構築(write)を行なえる
逆に言うと、作者はscim等のデスクトップのインターフェースは必要としていない
誰か作ってください ^_^;
最初はKansai.pmでの、世間話から発展
過去一年のSumibi.orgに来る日本語変換回数のグラフ
過去一ヶ月のSumibi.orgへのVisit回数(地図上にプロットしたもの)
*あたかも*高い変換精度の実現
おこなu /行/
ningen ni wakachigaki shitemorau
コンピューターによる文節認識間違いは論理的に無くなる
人間に補助してもらうことにより、あたかも変換精度が高そうに見える事を狙っている。
共起頻度をカウントしていくだけのもの
次の文章があったら、下記要領でデータベースをインクリメントしていく
夏 は 暑い
『夏』の頻度をインクリメント
『夏』=『は』と『は』=『暑い』の二つの共起頻度をインクリメント
『夏』=『暑い』の共起頻度をインクリメント
単純な共起頻度の計算をベースとしたもの
入力
natu ha atui
処理:それぞれの文節毎に候補を全て検索
夏、捺、奈津、菜津、奈都、なつ、ナツ、natu、為つ、生つ、成つ、.....
処理:候補同士の全ての組合せの出現評価値を求める
結果として総合的に出現頻度が高い順に変換候補が出る → 第一候補だけを表示すると
夏 は 暑い
okonau → [行う]と[行なう]のどちらになるかは、統計情報の出現頻度で決まる。
二つのデザインポリシーで作られている
→ メンテナンスコストが上がり過ぎると、ソフトウェアの更新が遅くなりプロジェクトの勢いが無くなる。
環境が整い、統計的アプローチの敷居が下がった
『自然言語処理ことはじめ』『確率的言語モデル』などなど..

統計処理には持ってこいのコーパス
エンジンの作り手が楽をできる
文法知識をデータで持たなくて良い。文法処理のアルゴリズムのメンテをしなくてよい。
辞書データのメンテナンスをしなくても良い
たった一つの冴えた見切りかた
人間観察の結果出てきた割り切り
もういちど最初から文章を打ちこみ直しして、文節区切り間違いの前まででいったん変換している
文節区切り間違いを恐れるせいか、連文節でどんどん文章を入力する人は殆どいない
→ じゃあ最初から人間に分かち書きしてもらっても良いのでは?
難しい数学の質問以外なんでもどうぞ ^_^;