❇️

ニューラルかな漢字変換エンジン「Zenzai」をazooKey on macOSに搭載します

Miwa

2024/05/16に公開

こんにちは。iOSの日本語入力アプリである「azooKey」を開発しているMiwaです。

azooKeyは最近macOS版の開発が進んでいます。このazooKey on macOSに、完全にローカルで動作するニューラルかな漢字変換エンジンである「Zenzai」を開発し、搭載します。この記事ではZenzaiの技術を解説します。

Zenzaiを搭載したazooKey on macOSは現在アルファ版としてリリースしています。macOSをご利用の方はぜひ入れて試してみてください！

Zenzaiの概要

日本語入力に欠かせないかな漢字変換ですが、その歴史は長く、50年にも及びます。この間様々なアルゴリズムが提案され利用されてきましたが、近年の技術開発はやや落ち着きつつあります。オープンソースのかな漢字変換ソフトウェアで今でも広く利用されているものは数えるほどしかありません。

クローズドソースのシステムでは、たとえばAppleはニューラル言語モデルを日本語入力に活用しているという噂がありますし、ATOKも「ディープラーニングを使っている」と明記しています。しかし、オープンソースのニューラルかな漢字変換システムはまだまだ未発展です。

そこで私が開発したのが90MパラメタのGPT-2に基づくニューラルかな漢字変換システム「Zenzai」です。「長い文脈を考慮できる」というTransformerアーキテクチャの利点を活かし、意味関係を高度に認識した変換を行うことが出来ます。日本語入力は高度にプライベートな情報を扱うことも多いため、全ての処理はローカル環境で行われます。

Zenzaiは、かな漢字変換タスクに特化するよう転移学習を施したニューラル言語モデルを用い、文書生成によってかな漢字変換タスクを処理します。一方で、ナイーブな実装では入力長に対して線形に生成処理時間が増加するため、長い文脈を考慮できても、1回の変換にストレスフルな時間がかかってしまいます。そこで、ある種の投機的デコーディングを利用することでこの問題を改善し、リアルタイムの変換を行うことを可能にしています。

このシステムは、私が従来開発してきた「AzooKeyKanaKanjiConverter」の内部に組み込まれる形で存在しています。AzooKeyKanaKanjiConverterでは従来の古典的手法によるかな漢字変換に加え、Zenzaiを用いた高精度な変換も利用できるようになりました。

かな漢字変換特化のニューラル言語モデル「zenz-v1」

zenz-v1の構築

ニューラル言語モデルの構築は言うまでもなく最も重要なパートです。今回は変換以外の能力をかなぐり捨てた、シンプルなニューラル言語モデルを構築することにしました。このモデルはzenz-v1と名付け、Hugging Faceで公開しています。

基盤モデルとして、CC-BY-SA 4.0で公開されている京大の文字レベル日本語GPT-2モデルを利用しました。

このモデルの選定理由は以下の通りです。

90Mパラメタと、かなり軽量である
トークナイザがバイトレベルBPEであり、未知語処理に優れる
かな漢字変換の特性上、文字単位で入力文字列を認識した方が柔軟な処理が可能であると期待できる

転移学習のための学習データとしてMeCabおよびipadic-NEologdを用いてそれぞれの読みを推定した500万文のテキストを用意しました。これを以下のようなテキストに加工します。

\uEE00ニュウリョク\uEE01入力

ここでは入力の始まりを出力の始まりを示すため、Unicode私用領域のU+EE00とU+EE01を用いました。Unicode私用領域の文字は事前学習時に現れていない可能性が高く、ニュートラルであることが期待できます。また、ユーザ入力とまず干渉しないため、処理上の利点もあります。

GPT-2はこのようなテキストの予測を学習します。ただし入力部分を予測できる必要はないため、学習時には\uEE01以降の文字列のみを損失の計算に含めています。

モデルは手元のMac miniを用いて3日間学習させました。これにより、かな漢字変換タスクに特化した言語モデルを得ることができました。

zenz-v1の性能評価

学習したモデルを用いてシステムを作る前に、zenz-v1が実際にどの程度「変換できるのか」ということを知っておきたいです。そこで2種類の評価データセットを用意し、構築したモデルを評価しました。

長い文脈を考慮して解く必要のある評価ケースなど、「従来の変換エンジンには難しい」と考えられるケースを多く含んだ独自データを150件作成し、これに対して許容解を列挙したものを構築しました。この評価データセットは現在のところ非公開ですが、たとえば次のような項目を含みます。

[
    {
        "query": "きめつのえいがをみました",
        "answer": ["鬼滅の映画を見ました", "鬼滅の映画を観ました"],
        "tag": ["時事2020"]
    },
    {
        "query": "はがいたいのでしかいにみてもらった",
        "answer": ["歯が痛いので歯科医に診てもらった", "歯が痛いので歯科医に見てもらった"],
        "tag": ["同音異義語"]
    },
    {
        "query": "くつろぐにふといでかんたといいます",
        "answer": ["寛ぐに太いで寛太と言います"],
        "tag": ["メタ表現"]
    }
]

出力が許容解に含まれるかどうかでスコア付けしたところ、以下の結果が得られました。この結果から、zenz-v1はベースラインとする従来型システム（AzooKeyKanaKanjiConverter）を大きく上回っていると判断しました。

AzooKeyKanaKanjiConverter (Baseline): 56/150

zenz-v1 trained with 1.2M sentences:    73/150
zenz-v1 trained with 2.6M sentences:    93/150
zenz-v1 trained with 5.0M sentences:   103/150

既存のシステムとして、Google日本語入力のAPIを利用した結果も合わせて示します。zenz-v1はGoogle日本語入力APIによる結果も大きく上回っています。

Google CGI API for Japanese Input: 69/150

また、以前私はGPT-4がかな漢字変換をうまく解けることを報告しました。そこで、OpenAIの最新モデルであるGPT-4oとの比較も行います。

以下のようにしてAPIを呼び出します。

def gpt4_api(query, key):
    client = OpenAI(api_key=key)
    response = client.chat.completions.create(
        model="gpt-4o",
        response_format={ "type": "json_object" },
        messages=[
            {"role": "system", "content": "あなたはかな漢字変換エンジンとして振る舞います。ユーザの入力に対してJSONで「\"output\": \"...\"」の形でかな漢字変換結果を返してください。"},
            {"role": "user", "content": query}
        ]
    )
    return response.choices[0].message

結果は以下の通りです。なんとGPT-4oはゼロショットで今回のベンチマークの最高性能を出してきました😇

GPT-4o: 110/150

……とはいえ、見方を変えれば、Mac miniで、わずか3日間の転移学習で作ったモデルがGPT-4oに迫る性能を出しているということです。考えようによってはかなり良い話なんじゃないでしょうか？（苦し紛れ）

やや余談ですが、今回用いた独自の評価データセットは、しばらく非公開で運用し調整した上で、公開したいと考えています。実はほとんど全てのオープンな日本語LLMはかな漢字変換が全く出来ません。文をどう発音するかということへの理解が如実に現れる、つまり日本語能力そのものが如実に現れるはずのかな漢字変換タスクを、ほとんどの大規模言語モデルが解けていないというのはとても悲しいことです。適切な評価指標を公開し、大規模言語モデル開発においてかな漢字変換タスクにも目が向けられるようになっていくよう促したいと考えています。

Zenzaiの構築

zenz-v1は既存の実装を大きく上回る性能を示していることがわかりました。そこで、zenz-v1に基づく、ニューラル日本語入力システム「Zenzai」を実装していきます。

ggufコンバート

学習したモデルをllama.cppを用いて動作させます。zenz-v1のgguf化は本家llama.cppではうまく動かなかったため、部分的に修正を加えたフォークを作りました。llama.cppはSwiftから直接呼び出せるため、とても便利です。

変換アルゴリズム

貪欲法で十分に良い結果が得られることがわかっているのですから、単純には\uEE00<クエリ>\uEE01の続きを生成してもらえばかな漢字変換結果を得られます。しかし、この方法にはいくつかの問題があります。

読みにそぐわない変換を行う可能性がある
かな漢字変換のデータセットで学習したニューラル言語モデルは、基本的に入力に忠実な変換を行います。しかし、稀に「おだのぶなり」と入力しているのに「織田信長」と変換してしまうような過剰な動作が発生します。こうした不安定な挙動は面白いですが、日本語入力システムでは望ましくありません。
入力長に対して線形に推論回数が増える
GPT-2を用いたテキスト生成は、原理的には「次の1トークンの予測」の繰り返しです。このため、正解テキストが20文字なら、ナイーブには20回の推論が必要です。GPT-2の推論は負荷が高いため、これほど多くの回数の推論が必要になってしまうと、変換速度が大きく落ちる可能性があります。

この両方の問題を解決するため、Zenzaiでは古典的なかな漢字変換システムをドラフトモデルとした投機的デコーディングを実施することにより、忠実かつ高速な日本語入力システムを実装します。

投機的デコーディング（Speculative Decoding）

そもそも投機的デコーディングとは、ニューラル言語モデルによる文章生成を精度を維持したまま高速化する手法です。

https://arxiv.org/abs/2302.01318

投機的デコーディングでは、「ドラフト（下書き）モデル」と呼ばれる高速で低精度なシステムを用いて、入力に対する複数トークンの予測を生成します。例えば入力が「おはよう」であるとき、ドラフトモデルはドラフトとして「おはようございました」を生成するようなイメージです。

このドラフトをニューラル言語モデルを用いて検証します。GPT-2の場合、最終層の出力は、全ての入力トークンに対する、その次のトークンの確率分布です。ということは、ドラフトが適切であったかどうかはこの確率分布を確認すればわかる、ということになります。そこでニューラル言語モデルは「おはようございま」までは妥当であるが、「し」は「す」に比べて圧倒的に低確率であることを出力します。
そこで、ニューラル言語モデルの言うとおり「し」ではなく「す」を採用し、「おはようございます」を得ます。

通常のニューラル言語モデルによる生成では、「おはよう」に対して「ご」を推論し、次に「おはようご」に対して「ざ」を推論し……と、合わせて5回の推論を行う必要があります。一方、投機的デコーディングでは、ニューラル言語モデルの推論は1回だけで、そこにドラフトモデルの処理が加わっただけです。ドラフトモデルの処理がニューラル言語モデルによる推論4回分よりも軽ければ、この方法で文章生成を高速化することができます。

これが投機的デコーディングの概要です。この方法を用いた場合、理論的には精度劣化なく高速化を実現できます。

Zenzaiにおける投機的デコーディング

ところで、実はかな漢字変換は非常に簡単なタスクです。実際、9割のテキストは古典的で単純で高速なシステムによって精度良く変換できます。問題は残りの1割です。それならば、9割は古典的で単純で高速なシステムに任せてしまい、難しいところだけニューラル言語モデルでやれたら良いのではないでしょうか？

ここにうまくフィットするのが投機的デコーディングの発想です。Zenzaiでは古典的なシステムをドラフトモデルとして利用します。

Zenzaiによるかな漢字変換の仕組みを説明した画像
動作の流れ。当然、実際にはこのようなチャット形式ではなく、単に出力された確率分布から制約を導出する。

既に評価にも登場しているAzooKeyKanaKanjiConverterですが、これは私がここ3年ほど開発している従来型のかな漢字変換エンジンです。2-gram言語モデルとViterbiアルゴリズムをベースにしたシンプルなアルゴリズムを使っていますが、多くのケースで問題なく動作します。iOSでの動作を前提に作っているため、高速でメモリ負荷が小さいです。

Zenzaiでは、入力された文章をまずAzooKeyKanaKanjiConverterが処理します。これにより、AzooKeyKanaKanjiConverterの評価に基づく最良の解がドラフトとして提案されます。そこでこれをzenz-v1を用いて検証します。全ての出力トークンが妥当であれば、検証OKで、このまま変換を合格とします。9割のケースでは、これが実際に正しい変換です。GPT-2の推論1回、従来型システムの推論1回だけで終わります。

しかし、AzooKeyKanaKanjiConverterの提出するドラフトがイマイチなこともあります。例えば「おんしゃをだいいちにしぼうしてます」という入力に対して、「恩赦を第一に死亡してます」をドラフトとして出したとしましょう。このとき、処理は次のような流れで進みます。

AzooKeyKanaKanjiConverterが「恩赦を第一に死亡してます」をドラフトとして提出します。
zenz-v1は「\uEE01の次のトークン」を予測し、その確率分布を出力します。この確率分布を確認すると、最も確率が高いのは「恩」ではなく「御」であることがわかります。そこでこのドラフトを却下し、「御」をprefixとせよ、という制約を返します。
AzooKeyKanaKanjiConverterはこの制約を満たす解を探索します。結果として「御社を第一に死亡してます」をドラフトとして提出します。
zenz-v1は再び確率分布を計算して出力していきます。こうして得られた「に」の次のトークンの確率分布を確認すると、最も確率が高いのは「死」ではなく「志」であることがわかります。そこでこのドラフトを再び却下し、「御社を第一に志」をprefixとせよ、という制約を返します。
AzooKeyKanaKanjiConverterはこの制約を満たす解を探索します。結果として「御社を第一に志望してます」をドラフトとして提出します。
zenz-v1はドラフトに対して確率分布を計算して出力していきます。今回は全てのトークンが最も確率が高いものになっているので、合格です。制約を満たしていることを報告し、処理が完了します。

このような流れにすることで、変換のほとんどはAzooKeyKanaKanjiConverterが実行し、残りの難しい部分だけをzenz-v1が実行する、という投機的デコーディングに基づいた高速化が実現できます。

この手法には多くの利点があります。まず、先ほど述べたとおり高速で、それでいて素の特化モデルであるzenz-v1の変換能力を壊しません。

さらに良いことに、この手法では全ての出力がAzooKeyKanaKanjiConverterによって生成されるため、従来型システムにとって解釈可能な候補が出力されることを保証することが出来ます。
単にzenz-v1を用いるだけでは「御社を第一に志望してます」が実際に読みに忠実であるかを判断することはできませんが、従来型システムにとって解釈可能であることによって、「志望」を「シボウ」と読めることが辞書レベルで保証されます。この結果、zenz-v1が読みに忠実でない変換を行おうとしていれば検知して排除することが出来ます。
また、文節区切りの情報が必要となってしまう部分変換なども変換結果が解釈可能であれば実現できますし、その気になればユーザ辞書や古典的な履歴ベースの学習との統合も可能です。

こうして、zenz-v1の精度面の利点を活かし、さらに高速かつ忠実なかな漢字変換を実現することができるのです。

システムの性能評価

この新しい日本語入力システムを、上記の独自テストデータで評価します。比較のため、異なるアルゴリズムも実装しました。これは次のようなシステムです。

AzooKeyKanaKanjiConverterを用いて上位10件の候補を作る
zenz-v1を用いて上位10件の候補を評価し、並び替える

並び替え法はシンプルな仕組みですが、ループが回るわけではないため、AzooKeyKanaKanjiConverterによる候補の絞り込みで精度が制約されます。また、候補の評価は常に10回行われるため、非常に簡単な変換において無意味な低速化が発生します。

便宜上、この方式を「並び替え法」と呼び、投機的デコーディングを用いるものを「Zenzai法」と呼ぶことにします。

独自データセットによる評価

2つのアルゴリズムで、独自データセットにおける速度と精度を計測したところ、次の結果を得ました。

従来システム（AzooKeyKanaKanjiConverter）
- 正解率: 56/150
- 速度: 0.0262 [s/query]
並び替え法（AzooKeyKanaKanjiConverter + zenz-v1）
- 正解率: 88/150
- 速度: 0.1206 [s/query]
Zenzai法
- 正解率: 100/150
- 速度: 0.0598 [s/query]

この結果から、Zenzai法は並び替え法に比べて高精度かつ高速な実装になっていることがわかります。従来システムと比較するとまだ2倍以上の時間がかかってしまいますが、およそ倍の正解数です。従来システムで倍の時間をかけても精度は倍になりませんが、Zenzai法はここをクリアできています。

原理上、精度は貪欲法による生成と一致するはずですが、4点分下回っています。この理由は実装に由来するもので、過剰な忠実性に由来するエラーがあります。前述のとおり、Zenzai法では仕組み上、生成される変換候補の読みと入力を一致させることが出来ます。しかしAzooKeyKanaKanjiConverterが「許していない読み」の存在によって、変換に失敗してしまうケースがあります。そうしたケースの1つが「もうちょっとそのAPIをふかぼってほしい！」という入力でした。AzooKeyKanaKanjiConverterは「深掘る」という語彙を持っておらず、尚且つ「掘る（ぼる）」という語彙ももっていません。この結果として、zenz-v1の要求する制約を満たす候補が作れなくなってしまいます。

部分的な課題はあるものの、全体としては精度を維持しながら効率を大きく高めており、好ましい結果だと考えています。

既存のデータセットによる評価

独自データセットは「既存の変換エンジンにとって難しい」と考えられるケースを選んでいるため、Zenzaiに有利な状態になっている可能性があります。そこでAnthyコーパスのデータを用いた追加の評価を行います。

Anthyコーパスはかな漢字変換エンジンのAnthyで利用されているコーパスで、多様な入力を含みます。（ただしやや技術者寄りの内容が多く含まれる印象です）
Publicドメインであるcorpus1.txtに含まれる1745件のデータで評価します。こちらも、用意された正答とシステムのベスト解と一致するかどうかを判定しました。

この評価データセットでもzenz-v1は最も良い性能を示していました。このことからも、Zenzaiの精度が示されていると言えると思います。

AzooKeyKanaKanjiConverter (Baseline): 1065/1745
Google CGI API for Japanese Input:    1104/1745
Zenzai trained with 5.0M:             1179/1745

もちろん、どちらの評価も性能の全てではありません。日本語入力は実際の利用時の振る舞いまで合わせて変換効率が決まるため、Best解の正確性では限られた部分しか捉えることが出来ないことには注意する必要があります。

azooKey on macOSとの統合

以上で変換システムの重要な部分はおおよそ完成したことになります。そこで、ここからはこの新システムをazooKey on macOSに統合していく作業です。azooKey on macOS自体はすでに作ってあったもので、この開発知見は別の記事でまとめています。

量子化

macOSで動かすとはいえ、日本語入力システムはシステムの主役ではないので、出来ればメモリ負荷が軽い方が望ましいです。そこで上記のベンチマークをもとに、量子化もかけておきます。試した範囲ではQ8_0までは精度劣化なく使うことができそうだったので、いったんこのモデルを動かすことにしました。

APIの整備

azooKey on macOSはかな漢字変換を行うためにAzooKeyKanaKanjiConverterを利用します。そこでAzooKeyKanaKanjiConverterのAPIを拡張して、Zenzaiを利用できるようにします。

次のように変換オプションでZenzaiMode.on(weight:)を渡してあげることによって変換ができるようになりました。重みファイルを与えることで勝手に読み込んで操作してくれます。

var options: ConvertRequestOptions = .withDefaultDictionary(
    // ...
    zenzaiMode: .on(
        weight: Bundle.main.bundleURL.appending(
            path: "Contents/Resources/ggml-model-Q8_0.gguf",
            directoryHint: .notDirectory
        )
    ),
    // ...
)

逐次入力における高速化

さて、実用的な日本語入力においては逐次入力のサポートを考慮することが重要です。特に、azooKey on macOSはライブ変換をサポートしています。ライブ変換では、ユーザが1文字入力するごとに変換候補を更新し、表示しなければなりません。

そこで、逐次入力においてより効率的な変換が行えるよう、システムを拡張します。「へ」「へん」「へんか」「へんかん」というような逐次的に変化するクエリに対処するアルゴリズムを構築できることが理想的です。

幸い、投機的デコーディングはここでもうまく動作します。ほとんどの場合、逐次的な入力は末尾から数文字分の変換に影響を与えるのみで、全体がガラッと変わってしまうことはあまりありません。そこで、前回の結果を適切に利用してドラフトを構築することで、逐次入力においても推論回数を大きく減らすことが出来ます。そこで、「前回の入力における第一候補」に基づいて最初の制約を構築し、それに基づいて処理を進めることで実行を高速化しました。

さらに、今回は「推論上限」を導入しました。これは変換リクエストあたりの推論の最大回数を指定するもので、azooKey on macOSでは1回にしています。変換リクエストあたり1回しか推論できないのでは、投機的デコーディングに基づいた精度向上のメリットを活かせないように見えますが、ここでも逐次入力が活きてきます。
その入力の瞬間は確かに最適な候補を提案できなくなってしまいますが、入力中のほとんどの場面において、ユーザがすぐさま次の文字を入力します。それなら、前回得られた制約をそのまま引き継いで、2回目の推論は次の入力時に行ってもだいたいのケースで間に合うはずです。

例えば「彼の動きは精彩を欠いた」という入力を考えます。Zenzaiで推論を十分な回数行えれば、この変換は問題なくできることがわかっています。具体的には、以下のような流れになります。

「彼の動きは制裁を書いた」がドラフトになる
「彼の動きは精」が制約になる
「彼の動きは精彩を書いた」がドラフトになる
「彼の動きは精彩を欠」が制約になる
「彼の動きは精彩を欠いた」がドラフトになる
追加の制約がないため、合格

ここでは推論が3回行われます。推論制約を1回とした場合、「彼の動きは精彩を書いた」で止まってしまいます。しかし、実際には逐次入力が走るので、次のような流れになります。

「彼の動きは精彩をか」までを入力した段階で「彼の動きは精彩をか」が制約になる
ユーザが「い」を入力する
前回の制約を引き継いだ「彼の動きは精彩をかい」がドラフトになる
「彼の動きは精彩を欠」が制約になる（推論1回）
「彼の動きは精彩を欠い」がドラフトになる
推論上限に達しているので、このままライブ変換候補として表示される
ユーザが「た」を入力する
前回の制約を引き継いだ「彼の動きは精彩を欠いた」がドラフトになる
追加の制約がないため、合格（推論1回）

このような動作のため、逐次入力においては、入力1回あたりの推論上限を1回と制約したとしても、多くの場合で妥当な変換を行えるのです。

これらの最適化によって、一操作あたり40ミリ秒程度で変換が行えるようになっています。逐次入力の利点を活かしながら体感でストレスなく変換が動作するようになりました。

主観評価

ここまでは定量的な評価を行っていましたが、日本語入力は「使い勝手」というような指標もだいぶ重要です。実際に動かしてみると定量評価だけでは出てこない問題点が見えてきます。

まず速度ですが、まだ「爆速」と感じるレベルの速度は得られていません。体感で言うと、「ちょっと重いかな？ってときのMacくらい」です。
M2 ProのMac miniを用いてこの状態なので、端末によってはストレスを感じるレベルで遅くなる可能性もありそうです。M3のMacBook Airでも同じような程度に動いたという報告をもらっているので、試せた方は具合を報告していただければ参考になります。個人的には、一入力あたり20〜30ミリ秒で処理できればもたつきを感じなくなるのではないか、という感想を持ちました。ライブ変換の遅延として許せる限界は40ミリ秒程度だと思います。

精度面については、残念ながらまだまだ完璧ではない感じがします。たった今入力した「精度」と「制度」の変換もうまく分けてくれなかったのは少し残念でした。
妙なところで失敗する印象もあります。例えば「ゴタントウシャ」で変換できず、「ゴタントウシャガ」とすると急に変換できるようになったりします。
語彙のカバレッジが悪く、低頻度の言葉や新語がほとんど学習されていないのでは、というような感じも覚えました。

もちろん、より広い先行文脈をコンテキストとして扱えるようにすることで精度が上がるでしょうし、手元のMac miniでわずか3日の学習でこのレベルの精度を実現できている、というのはポジティブなことだと考えています。この辺はモデル自体を改善していける部分なので、今後のアップデートを頑張りたいと思います。

逆に嬉しい副作用として、ライブ変換の安定感が少し増しました。従来のn-gram言語モデルベースの手法では入力末尾の文字列がかなりガチャガチャするような感じがありましたが、ニューラル言語モデルベースの手法ではあまり気にならない感じがします。
一方で、同音異義語の変換のようなケースで、末尾ではなく前方のテキストがガチャガチャと動くような挙動が見られました。これは推論の増加も意味するので、あまり望ましくありません。逐次的な変換においてガチャつきを抑えられるよう、何かしらの工夫を入れても良いかもしれません。

実際の動作はこんな感じです。リアルタイムで精度の高いライブ変換が実現できています。

未実装の機能

今のところ、履歴ベースの学習機能は動作しなくなっています。
出力が解釈可能であることから適当な方法で実現できると思っていますが、学習機能はユーザの手元に保存されるデータを含むため、安易に実装するとマイグレーションなどが必要になってしまい、面倒です。本格的な実装に進む前にコードの整理などが必要です。

azooKey on macOSではユーザ辞書や変換範囲の調整は元から未実装なので、これも一旦保留しています。

感想

Zenzaiが実装できたことで、オープンソースの日本語入力システムが「ニューラル日本語入力」という現代的なパラダイムの時代に入る土台をついに築くことができたと思います。研究・実験レベルのニューラルかな漢字変換の実装はこれまでもありましたが、適切な性能と適切な効率を持った実用システムとして公開できたのはとても嬉しいことです。今後の改善もどんどん進めていきたいと思っています。
azooKeyではいろんな方に「AIで日本語入力良くならないの？」というような声をいただいていたのですが、ようやく「AIで日本語入力良くなるよ」が実現できそうです。

Zenzaiは開発速度を優先して作ったので、まだまだ未熟なシステムです。改善の余地も広くあります。正直、「最高の日本語入力システムだ」と言える状態には程遠く、誤変換も発生しますし、あまり洗練されていない挙動も多いです。まだ手放しに喜べるクオリティには至っていません。

しかし、ニューラル言語モデルの良さはその柔軟さです。「長い文脈を考慮できる」という圧倒的な利点を活かせば、今後さらなる性能向上を見込めるはずです。従来システムと比べて成長の余地を多く残す、ポテンシャルの大きなシステムだと考えています。リアルタイム動作が実現しているので、あとはモデルを改善するだけです！

ニューラル日本語入力に興味を覚えた方は、ぜひプロジェクトの実装を手伝っていただければとてもありがたいです。azooKeyの開発に関する話題を共有するDiscordチャンネルもありますので、興味があればいらっしゃってください。

https://discord.com/invite/dY9gHuyZN5

ぜひ、GitHubのスターやSNSでのフォロー、GitHub Sponsorsなどでの支援をいただければ嬉しいです。

azooKey blogsPublication

iOS・iPadOS向け日本語キーボードアプリ「azooKey」のブログです。