Googleの講演会に行ってきました
Tech Talk in 関西: Google 日本語入力を支える情報処理技術 （学生向け）のお知らせ (1 月 30 日)
ちょうど前回のパターン認識の講義で統計的言語モデルを扱っていたので、これは聞きに行くしかない！と何も考えずに行ってきました。
以下、走り書きメモを若干補完したものです。
私が興味をもった質問に対する回答も該当場所に埋め込みました。
誤りがあれば指摘してくださると有り難いです。
概要紹介
内部設計
IMは複雑（Officeソフト並？）
- たくさんのコンポーネントからなる
これまでの一般的な実装 - As DLL
発想の転換 - クラッシュ/セキュリティホールの存在を考慮した設計
- 機能分離
- IM DLLのサイズをできる限り小さく
- クラッシュのリスクが低下
- 処理毎に別プロセスに分業する
- Converter（変換エンジン）やRenderer（候補ウィンドウ表示）
- プロセス間通信（IPC）
- ひとつのプロセスがクラッシュした時のリスク低減
- IM DLLのサイズをできる限り小さく
ありがちな実装方法
- アプリとIM DLL間でほとんどのやりとり、かなを漢字に変換する時のみ変換エンジンプロセスに送る
- リスクは低減できていない。結局多くの処理をDLLで行っている
Google日本語入力の実装方法
- IM DLLはほとんどの処理を変換エンジンプロセスに丸投げ
（a→あ、i→あい、(space)→合い、(space)→愛・合い・etc）- Statelessになる
- Portability - 移植が容易
- Win版/Mac版で変換エンジンのほとんどを共有
- 64bit版は1日でできた。テストは10日（小さいDLLのみ64bit化、残りは32bit）
- クラッシュリスク減
変換エンジンがクラッシュしたら？
- （仮説）ユーザ入力がリセットされる？
- 4秒毎にkillするscriptを走らせて実験
- 特に問題なく(?)入力ができている
- Why?
- 特に問題なく(?)入力ができている
Playback機能
- 変換エンジンがクラッシュするとDLLが変換確定前のやりとりを全部再送
- クラッシュ時のログを吐けばデバッグ
- 500キーほど記憶される（それ以上打つ前にユーザは変換確定させるだろうという推測）
- いつkillされても安全
- 自動アップデートが簡単にできる
- ユーザはおそらく気づかない
- IM ONになる時（念のため安全な状態）に勝手にアップデートされる
セキュリティ問題の解決策 - Sandbox
- 変換エンジンを別プロセスにし、Sandbox化
- 外部プログラムを起動不可
- 必要な特定ディレクトリ（AppData/LocalLow）以外への書き込み不可
自動テスト
- クラッシュしないほうがいいのは言うまでもない
- 自動ストレステスト
- 入力をランダム生成、リソースギリギリのPCへ送信を長時間継続する
- クラッシュ→Playback機能からログが吐かれる→デバッグ
まとめ
- 発想の転換
- Google Productsの共通哲学
- Google File System
- Google Chrome ←特に強い影響
- Google Productsの共通哲学
豊富な語彙・変換の秘密
ウェブ辞書生成
- Web Indexから持ってくる
- 特徴的・高頻度で出現する単語・フレーズの抽出
- 読みはどうする？
- 単漢字辞書
- 当て字に弱い（もず→百舌鳥）
- ウェブ技術の応用
- もしかして機能
- 読みがわかっている
- 読み間違いは少なからずある
- 単漢字辞書
辞書
- Key Value Storeにする？→たぶんムリ
- 圧縮率が高くないので肥大化
- 一般にexact matchしかできない
- 日本語入力特有の検索要求
- Common Prefix Search
- 連文節変換
- Predictive Search
- サジェスト
- Common Prefix Search
データ構造
開発経緯
- 20%ルール
- 20%使いなさい
- もしかして機能のログ分析
- 大部分がIMによる誤変換
- 経験者多数
- （関西（京大?）にゆかりのある人ばかり）
リリースまで
- 社内でDogfood（まず自分たちで使う）
- 既存IMとの互換性要望
- 「○○のキーバインド・機能がないと使えない！」
- 移行コストを最小限にする必要
- サジェストと語彙で勝負することに
- コードベースが肥大化
- 機能を選別してカット
- 実装の2〜3倍かけてテスト
- さらにテスト不足でカットした機能が2,3個
- 既存IMとの互換性要望
