Google DeepMindのEmbeddingGemma 2を土台にして、音声認識モデルへ作り替えたプロジェクトが登場した。売り文句はかなり強く、1時間の音声を約13秒で文字起こしでき、しかもBase MacBook Air上で、端末の中だけで動くという。クラウドに投げずに済むローカル音声認識は以前からあるが、ここまで速いとなると話は少し変わってくる。単に「便利な実験」ではなく、Embedding modelの使い方そのものをずらしている点が面白い。
元記事が示しているのは、音声を理解するためのモデルを一から作った話ではない。EmbeddingGemma 2はもともと、テキスト、画像、音声、動画を同じ埋め込み空間に並べるmultimodal embedding modelだという。埋め込み空間というのは、異なる種類のデータを「近さ」で扱える場所だと思えばよい。たとえば、声に出した単語の音声は、その単語の書き言葉の近くに来る。そこを逆手に取って、音声をその空間の中で読ませる発想に変えたわけだ。
仕組みは意外と単純だ。EmbeddingGemma 2のaudio encoderはそのまま使い、短い音声の断片ごとに、小さなreaderがそれをtext spaceへ押し込む。そこで約229,000個の英単語のうち、最も近いものを選び、その連なりをトランスクリプトにする。さらに、句読点と大文字を補う小さな追加モデルも載せている。つまり、基盤モデル本体をspeech-to-text用に再学習したというより、すでにある埋め込み表現を「単語当て」に使う構成だ。学習したのはreaderだけで、公開ライセンスの英語音声を使い、8×H100で2時間未満だったという。元のベースモデル自体は、speech-to-text用には訓練されていない。
速度の主張もかなり具体的だ。Embedding Gemma TranscribeはNeural Engine上で動き、base M3 MacBook Air、8GBで1時間分を12.6秒で処理したとしている。表ではこれを288× real timeと書いている。比較として、同じMacBook Air上で試したIBM Granite Speech 5.0 TurboCTCは約150×、25.7秒だった。さらに、FluidAudioが公開している別のベンチマークとして、NVIDIA Parakeet TDT 0.6B v3や、その fine-tune であるPhonon-2の数値も並べているが、元記事はこれは厳密な横並び比較ではないと注記している。ベンチマークに使ったMacや音声条件が違うからだ。
精度については、word error rateが現在およそ5%だとしている。これは先行するspeech modelの2〜3%にはまだ届かない。ただし、著者はreaderをもっと上手く学習させれば差は埋まるはずだとして、次の改良でそこを詰める考えのようだ。使い方はシンプルで、音声ファイルを放り込むか、Right Optionを押しながら話し、離すと任意のアプリに дикtationできる。音声はMacのNeural Engine上で処理され、機械の外には出ない。配布はmacOS 14+、Apple Silicon向けで、初回起動時に715MBのApple Siliconモデルをダウンロードする。なおこれはGoogle DeepMind製のEmbeddingGemma 2を使った独立プロジェクトで、Googleの公式提供でも後援でもないと明記されている。
この発表でまず目を引くのは、精度の勝負を真正面からやっていないことだと思う。word error rate 2〜3%の最先端に対して、今回は約5%だと認めている。それでも前に出してくるのは、端末内で1時間を13秒で処理する速度だ。ここには、音声認識の評価軸が一枚岩ではないという事情がある。会議の逐語録を完璧に残したい人と、録音をざっと文字にしたい人、リアルタイムのメモを取りたい人では、欲しいものが違う。後者にとっては、数%の誤差より待ち時間の短さのほうが効く場面がある。
しかも「オンデバイス」である点は、単なるおまけではない。クラウド型の音声認識は便利だが、録音データを外に送ることへの抵抗は根強い。会議、インタビュー、医療、法務、開発者のメモなど、音声の中身がセンシティブであるほど、その抵抗は強くなる。ここで音声が機械の外に出ないのは、機能の説明を超えて導入理由になる。私は、Embeddingsの再利用でここまで踏み込めるなら、今後は「高精度だが重いモデル」と「少し粗くても軽くて速いモデル」が、使い道ごとに住み分ける流れが進むのではないかと思う。
面白いのは、このモデルが何かを生成しているというより、「近い単語を選ぶ」ことで文字起こししている点だ。いまのAIの話題は、どうしても大規模な生成モデルに寄りがちだが、ここでは埋め込み空間という、もっと素朴で几帳面な仕組みが主役になっている。音声を理解するために巨大な言語モデルを回すのではなく、すでに近さが学習された空間を辞書のように使う。かなり発想が逆方向だ。
このやり方の利点は、モデルの役割分担がはっきりすることだと思う。音声の意味を全部深く推論するのではなく、まず「この音に最も近い英単語は何か」を大量に素早くやる。そのあとで句読点や大文字を整える。人間の作業にたとえるなら、速記と整文を分けている感じに近い。もちろん、そのぶん曖昧な発話や固有名詞、文脈依存の訂正には弱くなりやすいはずだ。元記事が英語に限定しているのも納得感がある。229,000語という候補集合は大きいが、言語が変われば単語の分布も音の切れ方も変わるから、同じ設計をそのまま移植するのは簡単ではないだろう。
元記事では、学習したのはreaderだけで、しかも2時間未満の訓練で済んだとある。ここはかなり重要だと思う。モデルをゼロから作らず、既存のembedding modelに薄い層を足して別タスクへ転用する。これは、近年よく言われる「基盤モデルをどう使い回すか」という話を、かなり実用寄りに押し進めている。重いモデルを配るのではなく、既存の表現に最小限の部品をつなぎ替えるだけで、別の製品になるからだ。
この方向が広がると、モデル開発の競争点も少し変わるかもしれない。これまでは「どれだけ大きいモデルを作れるか」「どれだけ事前学習を積めるか」が強かった。でもEmbeddingGemma Transcribeのような例は、既存の表現をどう読むか、どう切り出すか、どう軽い後処理で使える形にするかが勝負になることを示している。私はそこに、派手さはないが実務ではかなり強い流れを感じる。巨大モデルの時代が終わるという話ではない。ただ、実際に使われる場面では、モデルを賢くするより、既にある賢さを別の仕事へ安く移すほうが価値を持つことは増えるはずだ。
速度が速いと、つい「これで十分では」と思ってしまう。ただ、文字起こしでは5%のword error rateは小さくない。話者名、専門用語、数字、固有名詞が混ざる会話では、平均値以上に目立つ失敗が出る。しかも、この種のツールはそのままメモになるだけでなく、検索や要約の前段にも使われる。そこに誤変換が入ると、後段の処理がずれる。だから、速いことと使えることは同義ではない。
とはいえ、元記事の面白さは、その弱点を隠していないことにもあると思う。最先端精度ではまだ劣る、ただし reader を改善すれば縮むかもしれない、という書き方は誠実だ。私は、こういう位置づけの製品は、万能な置き換えではなく、用途の幅を増やすものとして見るのが正しいと思う。会議の即時メモ、録音の下書き、プライバシー重視の環境、そして実験好きの開発者。そういう場面では、5%の誤差より、ローカルで速く動くことの価値のほうが勝つことがある。EmbeddingGemma Transcribeは、その境界をかなり分かりやすく押し広げた例だ。
