Hatena::ブログ(Diary)

自己的活动日记

2010-10-24

Google 日本語入力 Tech Talk

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

参加してきました。

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

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

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

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



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

Google 日本語入力 TechTalk 2010 まとめ - Togetterまとめ

Google 日本語入力 TechTalk 2010 ノート - yoriyukiの日記

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


変換アルゴリズム

 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


  • 質疑応答

顔文字の辞書はどう作っている

 人手で。1000文字くらいまでは人手でいけるはず

文字コードは?困ったことは?

 基本UTF-8コンパイラ環境によって問題が起こる可能性があるのでソース中はエスケープで記述

 ヴとか全角チルダ問題とか

速度測定はどうやっている?

 プロファイラーで

ヘルプフォーラムでの要望の取捨選択はどのように行われている?

 重要性

 実装容易性

 開発者の思い入れ

 を基準に判断

mozc内のテストコードはユニットテストのみか?

 ユニットテストがほとんど。

 ストレステストも一部入っている

  ダミーのキーイベントを大量送信するものなど。

mozcの開発環境は?

 OS依存の開発はそのOS

 それ以外は好きなもの

 CIツールが各プラットフォームで動いているのでバグにはすぐ気づくはず

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/shentiyuelaiyuepangle/20101024/1287920576