速度と精度

Suzume がブラウザでどれだけ速く動くか、そしてどれだけ正確に分割するか。以下の各数値には、それが何をカバーし何をカバーしないかを併記しています。自分のワークロードに当てはまるかどうかを判断してください。

すべての数値はリポジトリ内のスクリプトから出ており、実行コマンドも併記しています。判断材料になるのは自分の環境と自分のテキストで出た数値です。

ブラウザでの速度

公開 JavaScript API 経由で、結果のデコードまで含めて計測しています。トークナイザ内部の時間ではなく、呼び出し側が実際に待つ時間です。

	中央値
WASM モジュールの初期化	2.93 ms
初期化後の初回解析	0.48 ms
定常状態の解析（1テキストあたり）	0.34 ms
定常状態のスループット	11,878 トークン/秒

make wasm
node scripts/measure_wasm_metrics.mjs --instances=3 --iterations=500 --samples=5 --warmup=1

計測環境は Apple M5 Max 上の Node です。低速なスマートフォンで同じ数値は出ませんが、形は変わりません。初期化に数ミリ秒かかるのは一度きりで、その後の各呼び出しは1ミリ秒未満です。

この表を信じる必要はありません。プレイグラウンドはあなたの端末で自分自身を計測し、結果の下に実測値を表示します。CLI はネイティブビルドについて同じ3つの数値を出します。

suzume-cli test benchmark --iterations=500 --samples=5 --warmup=1

両方を走らせれば、他人の数値を勘で割り引くのではなく、自分が実際に対象とするハードウェアで WebAssembly が何を要求するのかがわかります。

これが「毎キーストロークで解析」の根拠です。1回あたり約0.3ミリ秒なら、入力インターフェースが待たされる要因にはなりません。毎秒60フレームでも、1回の呼び出しが占めるのは1フレームの約2%です。比較すべき相手は他のトークナイザではなくネットワーク往復で、そちらは数十ミリ秒から始まり、しかも自分で制御できない条件に左右されます。

なお、実行の前にモジュール自体が届く必要があります。gzip 227KiB、初回のみ、以降はキャッシュされます。

分割精度

リポジトリにコミットされている期待分割に対するスコアです。Suzume は MeCab との一致率では評価しません。両者は交換可能な出力を目指していないためです（MeCab との違い）。

	スコア
境界 F1	0.9997
境界 精度 / 再現率	0.9994 / 1.0000
トークン F1	0.9995
文全体が完全一致した割合	0.9991

4,516ケース、15,920トークンでの計測です。

make build
python3 scripts/measure_segmentation_accuracy.py --per-category

これは in-sample のスコアです

これらのケースは Suzume 自身のテストスイートであり、トークナイザはそれを通るまで修正されます。したがって 0.9997 が示すのは、カバーされている挙動が安定していることです。まだ見たことのないテキストをどう処理するかの推定ではありません。

他のトークナイザとの比較には使えません。自分のコーパスでの期待精度としても読まないでください。それを知るには、ライブデモか CLI で自分のテキストを通してください。

境界 F1 を先に出しているのは、検索インデックス用途で効いてくるのがこちらだからです。クエリが一致するかどうかを決めるのはトークンの開始位置と終了位置であって、付与されたラベルではありません。

最も弱いのは実文のカテゴリ（usecase_realworld が 0.9845、usecase_mixed が 0.9957）で、これは予想どおりの形です。実際の文章は、孤立した文法ケースには現れない形で文体や固有名詞が混ざります。

ここで測っていないもの

• 他ツールとの精度比較。 共通コーパス上で Suzume の F1 を他のトークナイザと並べた表はありません。公平に行うには両者が目指す注釈基準が必要で、Suzume は意図的に MeCab の基準を目指していません。MeCab との違いを参照してください。
• held-out での精度。 上記のとおり、精度スコアは in-sample です。
• 敵対的入力下でのメモリ。 アロケーション回数の計測にはインストルメント済みビルドが必要で、配布物はこれを報告しません。