[Feature Discussion] ゼロクエリの予測変換

[ensan-hcl]

iOS標準のキーボードを含む多くのソフトウェアキーボードは、予測変換において「ゼロクエリ」のものに対応している。ゼロクエリの予測変換とは、ユーザが明示的に何も入力していない状態からの予測変換である。これをazooKeyでも導入したい。

ゼロクエリの予測変換はazooKeyにおいては開発初期に一度導入を試みたものの、良い精度が出ず複合語化を進める方向に舵を切ったのだった。（今でも部分的にコードが残っている）

2種類のゼロクエリ予測変換

ゼロクエリ予測変換と呼べるものは大きく2種類ある。

1. 入力中のゼロクエリ予測変換
   これは「はし」の予測には通常「はしっ」が現れるところを、「走っ/て」とか「走っ/た」のように、追加で1語ないしそれより多く予測して変換する方式である。azooKeyで当初試みたのはこちらのパターンだが、「走っ/て/てる」のような不適切な候補が多数生成されたため、本導入を見送った
2. 入力後のゼロクエリ予測変換
   「走った」で確定した後に「とき」とか「ら」とかが候補として表示される機能である。iOSの場合、この機能は確定直後以外にも、カーソルを動かすことで勝手に表示される。こちらの機能は特に「句読点」「絵文字」などを追加する機能としても要望が多い。

技術的な違い

1と2は一見大差ないように見えるが、技術的に異なる。

1のケースではゼロクエリ予測変換を挿入する前の文脈の情報を得ることができる。つまり「走っ」が動詞の連用形促音便であることは利用可能な情報である。
一方、2のケースでは一般に前の文脈の情報が得られない。このため、一度形態素解析のようなステップを挟まなければ先行文脈の詳細な情報を得ることができない。

ユーザの期待の違い

1と2に対するユーザの期待についても注意する必要がある。

1のケースに対するユーザの期待は大きい。つまり、1を実装した結果、変換候補にゴミが出る場合、ユーザはより強い不満を抱く。
一方、2のケースに対してユーザは強い期待を持っておらず、「いいのがなければ自分で打つ」程度の意識である。したがって2の場合は精度をある程度妥協しても問題ないと考えられる。

[ensan-hcl]

実装上の課題

実装上の課題は大きく分けて2つある。

1. UI

現在、変換を終えるとタブバーボタンが表示される仕様になっている。しかし、これでは予測変換を表示するスペースが存在しない。

現在のところ、タブバーボタンを左寄せして予測変換候補を表示する方式を検討している。これは絵文字タブにおいても前例のある方式であり、妥当だろうと考えている。

2. 変換の実装

type-1についてはある程度実装が考えられるものの、type-2のゼロクエリ予測変換をどのように実装するかは大きな問題である。一般的にこのような変換はn-gramのような言語モデルを構成すれば比較的簡単に構築できるものの、そのためにわざわざ大きな辞書を作って同梱するのはコストが大きく、パフォーマンスも十分であるかわからない。

その代わりに、ある程度妥協を入れることでこの実装をシンプルにできる。

1. 確定直後のみ動くようにする（一般的なケースは諦める）
2. かつ、type-1のゼロクエリ予測変換と同一の仕組みを用いる
3. 事前に列挙された限られたパターン＋学習＋ユーザ辞書、のように、予測変換を利用する範囲を限定する

こういう実装にすることで比較的低コストでtype-2のゼロクエリ予測変換を実現できないかと考えている。

[ensan-hcl]

事前に列挙された限られたパターン

この部分の実装だが、以下のようにする。

1. 左側の品詞idに対して右側に来うる単語の上位100個程度を列挙した辞書を作成する。これは辞書ベースで自動的に作っても良いし、手動で調整しても良い。
2. 左側のcidに基づいてこの上位100個の単語をチェックし、midを含めてゼロクエリの予測変換を実施する

また、以下も加える

1. 左側の単語をprefixとする単語を検索する。例えば「愛」だったら「愛知」「愛情」などが出てくる。
2. 「知」「情」などを候補に追加する

学習、ユーザ辞書は多くないので、上限を500などに決めた上で全探索する。