ensan-hcl / azookeykanakanjiconverter Goto Github PK

Context: https://twitter.com/Kyomesuke/status/1688892565175865344?s=20

zenz-v1は文字レベルBPEトークナイザを利用しており、語彙に含まれない文字が現れた場合はUTF-8のバイトレベルの分割を行う。
したがって、Next Token Probabilityが最大であるようなトークンをとった時、これがバイトレベルのトークンの可能性がある。

しかし、現在はConstraintがSwiftの文字列で示されているため、UTF-8としてinvalidな状態のテキストはConstraintとして扱えない。
文字列を中間表現とするのをやめ、UTF-8コードポイントで直接これを扱うようにしたい。

なお、ほとんどのケースでバイトレベルのトークンは現れないため、基本的にはエッジケースのみで生じる

リンタの設定はazooKeyと共通化する

Linuxでビルド・テストができることを保証したいので、CIを用意する。

例えば「1234567890」と入力して変換すると「十二億三千四百五十六万七千九百三十六」と表示され、正確な値と異なる値が表示される。

この部分でString -> Float -> Intと変換してしまっているのが原因と考えられる。

1. 「へんかん」に対して「編感」を確定する
2. これを長期記憶に保存する
3. 何度「変換」で確定しても、「編感」が優先されるようになる。

この現象は1文字ずつ確定した際に起こる。iOS版のazooKeyでは起こらず、デスクトップ版でのみ再現している。

Swift 5.10のCIを追加する。

Swift 5.9はCIが通る限りサポートし、通らなくなったら停止する。

現在、メールアドレス変換として次のような機能が用意されている。

• /[A-Za-z0-9_\.]+@/と入力すると、@gmail.comや@icloud.comなどを予測変換として表示する

これに対して、以下の要望が来ていた。

@gまで入力している場合に絞り込んでほしい

この機能を実装したい。現在の実装はEmailAddress.swiftに存在しており、これを拡張することで実現可能だと考えられる。

https://github.com/ensan-hcl/AzooKeyKanaKanjiConverter/blob/develop/Sources/KanaKanjiConverterModule/Converter/EmailAddress.swift

https://github.com/ensan-hcl/azooKey に入れていた自動テストをこっちに移植する

「12345678901234567890」などと入力すると変換がクラッシュする。

やりますか？

背景

Zenzaiは現在llama.cppを推論ランタイムとして動いている。llama.cppはプラットフォーム間の移植が容易である利点がある一方で、Apple PlatformsにおいてはNPU（Neural Engine）を利用できないため、効率においてCoreMLに劣る可能性がある。
そこで、CoreMLを用いたZenzaiの実装を実現し、llama.cppを上回る推論パフォーマンスを得たい。

現在の状況

@Skyline-23 さんによるzenzモデルのCoreML版が存在する。
https://github.com/Skyline-23/zenz-CoreML

これを用いて推論を行う実装が以下であり、現在logitの取得までは達成できている。しかし推論時間はllama.cppの1.4倍程度遅く、またNPUが適切に使えていないと見られる挙動を示す。

https://github.com/ensan-hcl/swift-zenz-coreml

やりたいこと

以上を踏まえ、以下を行ってllama.cppを超える性能を得たい。これが実現できれば、原理的にはApple PlatformにおいてCoreMLを利用した高速化が得られることになる。

• zenz-v2(無改造のGPT-2)をCoreMLで動かし、入力に対するlogitを得る
• Quantization, Palletizationをかけてモデルを圧縮する
• KV-Cachingを有効にする
• llama.cppよりも高速な推論性能を得る

• ある程度はZenz側の出力も加味して学習の適用可否を調整する
• 学習境界が単語境界に一致しない場合に学習が反映できない問題を修正する

• AzooKeyKanaKanjiConverterがAndroidでビルドできるかどうか確認する
• 可能であればCIを追加する
• 不可能であればドキュメントを追加する

https://github.com/apple/swift/blob/main/docs/Android.md

#50 でCLIツールとしてancoを導入した。一方、今まで辞書生成用に利用していた https://github.com/ensan-hcl/azooKey_dictionary_builder は辞書生成用の別ツールとなっている。anco dictionary buildのようなサブコマンドを追加し、これらを統合したい。

また、辞書データのencode/decodeをまとめて記述したい。

現在、ほぼ全ての処理が@MainActorで実行されており、メインスレッドをブロックしてしまう。かな漢字変換はしばしば重い操作であり、多くの実用的なアプリケーションにおいて望ましくない。

そこで@MainActorの制約を外して非同期でアクセスするよう変更を行いたい。