Google 日本語入力 Tech Talk

Google Japan Blog: イベントのお知らせ「Google 日本語入力 TechTalk 2010」

参加してきました。

お申し込み多数の場合には、ソフトウェア開発関係の方を優先させていただいた上で、抽選とさせていただきますので、ご了承ください。

とのことだったので落選したらどうしよう・・・とか心配していましたが、無事参加できました。

当日は写真撮影不可ということだったので写真はありませんが、Google六本木オフィスのエントランス、食堂（ガラス越し）、バー、Liquid Galaxyなどを拝観いたしました。

あと、Google日本語入力のマンガの冊子もいただきました。

既に多くの人がレポートを書いているみたいなので

Google 日本語入力 TechTalk 2010 まとめ - Togetter
http://d.hatena.ne.jp/yoriyuki/20101024/p2

私は網羅性の無いメモだけ書きます。

• Google日本語入力/Mozcno設計概要(工藤拓さん)

変換アルゴリズム
　n文節最長一致
　　greedyに最長のものを探索
　最小コスト法
　　latice経路の探索コストが最小になるもの
　　viterbiアルゴリズム

コスト推定の方法
　v = argmax p(x|y) = argmax p(y) * p(x|y)
　p(y) ＝ 日本語らしさ。Web上の文章から統計的に算出

読みの推定
　検索で用いられている技術を総動員
　　もしかして機能
　　すでに読みが分かっている単語（当て字等）

辞書の圧縮
　mozc→ipadic のデータを38MB→9.5MBに圧縮
　　TRIE Tree(Louds) + ハフマン符号化

語彙の増大による副作用の低減
　例
　　アイマス　ー　会います
　　ドコイク　ー　どこ｜行く
　web情報が存在しても対立候補も考慮してランキングを行う。

評価の難しさ
　最初
　　機械的にさまざまなジャンルのデータを用いて評価
　　初期には有効
　今
　　当たり前の単語が当たり前に変換できることが一番大事
　　平均的、機械的精度はあまりあてにならない。
　　機械的評価／マストな評価

まとめ
　日本語入力は総合格闘技である

質疑応答
　使っているソケットは
　　Unix Domain Soocket
　　　peerのプロセスID、ユーザーIDが分かるので採用
　　named pipe
　　machIPC
　採用理由は「セキュリティ」

　ありえない過負荷のストレステストはやっているか？
　　ライブラリに対してはやっている
　　アプリケーションから直接に流すところまではできていない

　GUIレンダラーの乗っ取りはありえないのか？
　　仮に途中でクラッシュしても自動再起動して死なないのでユーザーにはあまり影響はない
　　Ubuntu版(ibus)はレンダラーは非公開。クラッシュすると落ちるかもしれない。
　　　ibusはプロセスが分離されているので大丈夫なはず（会場より）

　IMEのセキュリティが脆弱なことにどのようにたどり着いたか
　　一般的には知られていないがIPAなどで定期的に報告されている。
　　調べれば分かる情報

　どの程度辞書のチューニングを人手で行っているか
　　IPADicにのるレベルの基本語彙については人手で修正することもある
　　　ランキングについてはすべて機械的。Webの頻度を用いて算出する

• コードリーディング

アジェンダ
　ビルドシステム
　クライアント
　converter layer
　rewriter

ービルドシステム
何を使っているか
　GYP
　　chromeのために作られたビルドシステム
　もともとはsconsを使っていた
　GYPに移行したのは2010/5ころ

scons
　pythonで書かれたビルド環境
　何でもできるので管理に問題がでることも
　プラットフォームのサポートが万全ではない
　　ライブラリを作るのは簡単だがアプリを作るには色々な手間がある

GYP
　pythonで書かれたビルド環境
　シンプル。凝ったことはできない
　ビルドのレシピファイルを様々な環境のビルドファイルを生成する（makeなど）
　シンプルなだけにマルチプラットフォーム対応が行いやすい

質疑応答
　GYPの採用事例は？
　　あまり気にしていない・・
　　GYP自体は公開されているので誰でも使える。ただしドキュメントは少ない・・・

ークライアント
クライアントの役割
　キーを受け取る
　変換結果を表示する
　OSに依存したIMFとやりとりをする
　　Win:IMM32,TSF
　　Mac:IMKit
　　Linux:ibus,scim等
　プロセス間通信にProtocolBuffersを用いている
　　通信フォーマットはsession/command.proto
　　　CommandType
　　　ID
　　　KeyEvent

ーconverter
　変換候補（Candidates）はKey-Valueで表現している。

実装
　ImmutableConverter
　　変換処理
　Rewriter
　　後処理。雑多なことを行う
　　ヒューリスティックルールによる候補の書き換え、ランキングのっ変更、候補の追加など
　Predictor
　　予測変換。キー入力を元に予測を行う

最小コスト法
　品詞辞書の数字IDはリリースごとに変更される可能性がある
　コスト＝ -500 * log(freq) →小さいほど出現しやすい
　品詞ごとにコストを設定している。異品詞間のコストは比較不可能
　品詞IDと品詞コストだけで計算されている。
　ある単語を追加したい場合の手順
　　一定量の文章を集める
　　その中の既存単語と追加したい単語の頻度差を調べる

文節切りルール
　data/rules/segmenter.def
　文字列表現に対する正規表現がかかれている（文節を切るために使用）
　id.def + segenter.def を読み込んでif-thenルールを作成する
　→CPU使用率が高かったので全展開してビット配列化

ーRewriter
使用箇所
　入力履歴からの学習
　共起
　特殊な語彙
　特殊な変換

実装
　rewriter/配下
　RewriterInterfaceを継承
　　Finish()
　　Sync()
　　Clear()
　　Rewrite()

Rewrite
　スペースが押された時（すべての変換の際に呼ばれる）

ーStorage
辞書
　DictionaryInterface
　　LookupPredictive　予測変換、PredictiveSearch
　　LookupExact　完全一致
　　LookupPrefix　CommonPrefixSearch
　　LookupReverse　未実装

　ユーザー辞書
　　データの実体はProtocolBuffersのシリアライズデータ
　　Protobufのデータを操作すれば格調可能
　システム辞書
　　dictionary/*.txtのファイルをビルド時にバイナリに埋め込み

ExistenceFilter
　該当するハッシュ値に合致する値があるかどうかチェック
　Bloomfilterを使用
　suggestion_filterで使用
　「ただしイケメンに限る」はサジェストされない、等

LRUStorage
　ユーザー候補選択履歴を保持する
　rewriter/user_boundary_history_rewriter.cc

• 質疑応答

顔文字の辞書はどう作っている
　人手で。１０００文字くらいまでは人手でいけるはず

文字コードは？困ったことは？
　基本UTF-8。コンパイラ環境によって問題が起こる可能性があるのでソース中はエスケープで記述
　ヴとか全角チルダ問題とか

速度測定はどうやっている？
　プロファイラーで

ヘルプフォーラムでの要望の取捨選択はどのように行われている？
　重要性
　実装容易性
　開発者の思い入れ

　を基準に判断

mozc内のテストコードはユニットテストのみか？
　ユニットテストがほとんど。
　ストレステストも一部入っている
　　ダミーのキーイベントを大量送信するものなど。

mozcの開発環境は？
　OS依存の開発はそのOSで
　それ以外は好きなもの
　CIツールが各プラットフォームで動いているのでバグにはすぐ気づくはず