Gemma-4-12b-it Audio Transcriptを試す

Llama.cpp付属のWeb-UIで実現可能

Gemma-4-12b-itでは、それまで外付けエンコーダーを必要としていたものがモデルの中に組み込まれ、特に意識することなくオーディオ書き取りが行えます。私がオーディオ書き取りの機能をモデルを通じて行っていたのはまだWhisper以外になく、API型では多少GPT-4o派生のモデルを使っていたりもしましたが、ローカルモデルでちゃんとASRについて触れるのはこれが2度目って感じになります。

当初、どうやってAPIを書く必要があるんだろう？って悩んでたんですが、どうやらWeb-UIで手軽に行えるようです。

実行手順

まず、オーディオファイルをアップロードします。フォーム上の「＋」をクリックし、「Audio Files」を指定します。

以下のようにファイルが追加されたら、プロンプトで書き起こしをするよう指示します。
（ファイルの内容をテキストに書き起こしてください等）

そして実行すると、以下の画面のように解析できしだいStreaming形式で順次結果が出力されます。

トークン量はいかほど？

ちょうど今回使ったWavファイルですが、収録時間はおよそ5分程度です。この時のログを見て見ると以下の通りとなっていました。ちなみに使用しているGPUはRTX 3060です。

501.23.316.901 I slot update_slots: id  3 | task 0 | cached n_tokens = 5, memory_seq_rm [5, end)
501.23.317.129 I srv  process_chun: processing audio...
501.23.317.271 I encoding audio slice...
501.23.389.382 I reserve_compute_meta:      CUDA0 compute buffer size =   150.25 MiB
501.23.389.388 I reserve_compute_meta:        CPU compute buffer size =    18.78 MiB
501.23.389.391 I reserve_compute_meta: graph splits = 1, nodes = 4
501.23.389.396 I warmup: flash attention is enabled
501.23.572.325 I audio slice encoded in 255 ms
501.23.572.440 I decoding audio batch 1/4, n_tokens_batch = 2048
501.25.053.486 I audio decoded (batch 1/4) in 1481 ms
501.25.053.490 I decoding audio batch 2/4, n_tokens_batch = 2048
501.26.856.588 I audio decoded (batch 2/4) in 1803 ms
501.26.856.593 I decoding audio batch 3/4, n_tokens_batch = 2048
501.28.799.199 I audio decoded (batch 3/4) in 1943 ms
501.28.799.204 I decoding audio batch 4/4, n_tokens_batch = 1549
501.30.636.102 I audio decoded (batch 4/4) in 1837 ms
501.30.636.158 I srv  process_chun: audio processed in 7319 ms
501.30.714.028 I slot print_timing: id  3 | task 0 | prompt processing, n_tokens =   7712, progress = 1.00, t =   7.58 s / 1018.07 tokens per second
501.30.714.031 I slot update_slots: id  3 | task 0 | cached n_tokens = 7712, memory_seq_rm [7712, end)
501.30.714.211 I slot init_sampler: id  3 | task 0 | init sampler, took 0.02 ms, tokens: text = 23, total = 7716
501.30.838.129 I slot create_check: id  3 | task 0 | created context checkpoint 2 of 32 (pos_min = 3104, pos_max = 7711, n_tokens = 7712, size = 170.013 MiB)
501.33.698.420 I slot print_timing: id  3 | task 0 | n_decoded =    100, tg =  35.55 t/s
501.36.719.140 I slot print_timing: id  3 | task 0 | n_decoded =    208, tg =  35.65 t/s
501.39.762.827 I slot print_timing: id  3 | task 0 | n_decoded =    317, tg =  35.71 t/s
501.42.789.376 I slot print_timing: id  3 | task 0 | n_decoded =    413, tg =  34.69 t/s
501.45.840.838 I slot print_timing: id  3 | task 0 | n_decoded =    512, tg =  34.23 t/s
501.48.886.228 I slot print_timing: id  3 | task 0 | n_decoded =    618, tg =  34.33 t/s
501.51.945.806 I slot print_timing: id  3 | task 0 | n_decoded =    730, tg =  34.66 t/s
501.54.958.421 I slot print_timing: id  3 | task 0 | n_decoded =    834, tg =  34.64 t/s
501.57.984.631 I slot print_timing: id  3 | task 0 | n_decoded =    938, tg =  34.61 t/s
501.59.335.310 I slot print_timing: id  3 | task 0 | prompt eval time =    7746.02 ms /  7716 tokens (    1.00 ms per token,   996.12 tokens per second)
501.59.335.316 I slot print_timing: id  3 | task 0 |        eval time =   28450.19 ms /   991 tokens (   28.71 ms per token,    34.83 tokens per second)
501.59.335.317 I slot print_timing: id  3 | task 0 |       total time =   36196.21 ms /  8707 tokens
501.59.335.322 I slot print_timing: id  3 | task 0 |    graphs reused =        488
501.59.335.323 I slot print_timing: id  3 | task 0 | draft acceptance = 0.25355 (  500 accepted /  1972 generated)
501.59.335.344 I statistics        draft-mtp: #calls(b,g,a) =    1    493    493, #gen drafts =    493, #acc drafts =   305, #gen tokens =   1972, #acc tokens =   500, dur(b,g,a) = 0.004, 4393.784, 0.664 ms
501.59.335.382 I slot      release: id  3 | task 0 | stop processing: n_tokens = 8709, truncated = 0

501.23.316.901 I slot update_slots: id  3 | task 0 | cached n_tokens = 5, memory_seq_rm [5, end)
501.23.317.129 I srv  process_chun: processing audio...
501.23.317.271 I encoding audio slice...
501.23.389.382 I reserve_compute_meta:      CUDA0 compute buffer size =   150.25 MiB
501.23.389.388 I reserve_compute_meta:        CPU compute buffer size =    18.78 MiB
501.23.389.391 I reserve_compute_meta: graph splits = 1, nodes = 4
501.23.389.396 I warmup: flash attention is enabled
501.23.572.325 I audio slice encoded in 255 ms
501.23.572.440 I decoding audio batch 1/4, n_tokens_batch = 2048
501.25.053.486 I audio decoded (batch 1/4) in 1481 ms
501.25.053.490 I decoding audio batch 2/4, n_tokens_batch = 2048
501.26.856.588 I audio decoded (batch 2/4) in 1803 ms
501.26.856.593 I decoding audio batch 3/4, n_tokens_batch = 2048
501.28.799.199 I audio decoded (batch 3/4) in 1943 ms
501.28.799.204 I decoding audio batch 4/4, n_tokens_batch = 1549
501.30.636.102 I audio decoded (batch 4/4) in 1837 ms
501.30.636.158 I srv  process_chun: audio processed in 7319 ms
501.30.714.028 I slot print_timing: id  3 | task 0 | prompt processing, n_tokens =   7712, progress = 1.00, t =   7.58 s / 1018.07 tokens per second
501.30.714.031 I slot update_slots: id  3 | task 0 | cached n_tokens = 7712, memory_seq_rm [7712, end)
501.30.714.211 I slot init_sampler: id  3 | task 0 | init sampler, took 0.02 ms, tokens: text = 23, total = 7716
501.30.838.129 I slot create_check: id  3 | task 0 | created context checkpoint 2 of 32 (pos_min = 3104, pos_max = 7711, n_tokens = 7712, size = 170.013 MiB)
501.33.698.420 I slot print_timing: id  3 | task 0 | n_decoded =    100, tg =  35.55 t/s
501.36.719.140 I slot print_timing: id  3 | task 0 | n_decoded =    208, tg =  35.65 t/s
501.39.762.827 I slot print_timing: id  3 | task 0 | n_decoded =    317, tg =  35.71 t/s
501.42.789.376 I slot print_timing: id  3 | task 0 | n_decoded =    413, tg =  34.69 t/s
501.45.840.838 I slot print_timing: id  3 | task 0 | n_decoded =    512, tg =  34.23 t/s
501.48.886.228 I slot print_timing: id  3 | task 0 | n_decoded =    618, tg =  34.33 t/s
501.51.945.806 I slot print_timing: id  3 | task 0 | n_decoded =    730, tg =  34.66 t/s
501.54.958.421 I slot print_timing: id  3 | task 0 | n_decoded =    834, tg =  34.64 t/s
501.57.984.631 I slot print_timing: id  3 | task 0 | n_decoded =    938, tg =  34.61 t/s
501.59.335.310 I slot print_timing: id  3 | task 0 | prompt eval time =    7746.02 ms /  7716 tokens (    1.00 ms per token,   996.12 tokens per second)
501.59.335.316 I slot print_timing: id  3 | task 0 |        eval time =   28450.19 ms /   991 tokens (   28.71 ms per token,    34.83 tokens per second)
501.59.335.317 I slot print_timing: id  3 | task 0 |       total time =   36196.21 ms /  8707 tokens
501.59.335.322 I slot print_timing: id  3 | task 0 |    graphs reused =        488
501.59.335.323 I slot print_timing: id  3 | task 0 | draft acceptance = 0.25355 (  500 accepted /  1972 generated)
501.59.335.344 I statistics        draft-mtp: #calls(b,g,a) =    1    493    493, #gen drafts =    493, #acc drafts =   305, #gen tokens =   1972, #acc tokens =   500, dur(b,g,a) = 0.004, 4393.784, 0.664 ms
501.59.335.382 I slot      release: id  3 | task 0 | stop processing: n_tokens = 8709, truncated = 0

この結果から、5分ほどの会話データでおよそ7,700トークン程度のコンテキストが収集できたものと予想されます。1時間程度のデータとなると、これのおよそ12倍程度になると考えられますので、そのデータ量は92,400トークンとなり、1時間程度のデータであれば、コンテキスト上限設定が例えば128kであっても収容可能と考えられます。

オーディオエンコードは、基本的に音声データを単位時間刻みでスペクトログラム化して画像イメージの様に取り込むことを基本としているかと思いますので、時間が延びればトークン量も単調増加をするんじゃないかなとみています。

モデルとしての最大コンテキスト長は256kですので、もしかしたら2時間程度の会議データでも十分収容できるのかもしれません。ただ、これはあくまでwavファイルをそのまま放り込んだ結果なため、実際にどうだったのかは別途異なる拡張子のデータをアップロードしてみてどうだったかを実験する必要があるのではないかなと思います。

Readに伴う処理速度も1,000tok/s弱ぐらいの速度でしたので、それほど時間をかけずに処理が完結できるのではないかな？と予想しています。

精度はいかほど？

元の音声データですが、Gemini TTSを使用して、あらかじめ作成した台本を読ませた音声データをベースにしています。というわけで、以下に音声データと書き起こしたデータを並べてみます。一部、音声としても文字を誤読している箇所があり、ベースとして使うには改良の余地が多分にあるのですが、それを考慮してもまだまだ完全ではないなと感じるところが見受けられました。

精度を改善するには基本的に以下2つのアプローチが必要になってきます。

ファインチューニング

別途データセットとして、「音声データ」と「正しい書き起こしデータ」を結合させたデータセットを作成し、ファインチューニングによって、モデル内部の書き起こし辞書を拡張する方法です。Whisperではそうした対応を主にとっており、デコーダー中心にパラメータ情報を追加していくようなことをよく行っていましたが、今回のケースではモデルのパラメータ量が12Bあるということで、ファインチューニングを行うにはそれなりの設備が必要になってくるものと考えられます。（WhisperはLargeモデルでも1.5B程度で、学習個所を細かく制御すれば12GB程度のGPUでもファインチューニングが可能です）

誤り辞書の整備

こちらは、推論処理を単発で行うのではなく、以下のようなフローで複数段階推論させ、正しい結果を出力させるようなことを行う方法で、現実的な対応策としてはこちらが望ましくなるのではないかと思われます。

• オーディオから、一次書き起こしを行う（本記事で紹介）
• 書き起こしたテキストを、誤り辞書を取り込んだうえで文章の校正を行う

この2段階の推論はGemma-4-12b-itであればそのモデルだけで処理が完結できると思います。手間がかかるとすれば誤り文字列の修正辞書の作成になるのかなと思います。こちらは、実際に音声を聞いたうえでデータを作成する必要もあり、それなりの人海戦術が必要になってきますが、それは前述したファインチューニングにおけるデータセット作成でも同じことが言えます。

正直な感想

ほんと便利な時代になったと思います。Whisperでファインチューニングをコツコツやっていたころが懐かしく感じるほどです。その完成度の高さに、ぶっちゃけファインチューニングもういらないんじゃね？って感じるほどです。
とは言え、ファインチューニングも実は一見難しそうで、ある程度運用を軌道に乗せれば楽に回せるようになって吐きます。

とはいえ、コンテキストに乗せると混乱しがちなデータをモデルにあらかじめ焼き込むことでちょうどよい強度で追加した辞書が紐付けできるようになったりすることもあり、それこそ使い方はケースバイケースなのかなとも思っています。

どっちが正解とか言わず、色々見ていただき、より良い方法を各々が選択していくとよいのかなと言うのが個人的な考え方でして、それによって日本のAI技術力が何かしら底上げに寄与出来たら幸いだなと考えるところです。

参考：実際に出力された書き起こしデータ・台本との突合結果

本項以降は、参考までにどういう書き起こしデータが生まれ、Geminiに評価させた結果、どのような評価が下されたかについて、その内容を転載したものになります。あくまで簡易実験した結果として、参考程度に見ていただければと思います。

全体の評価結果

この内容をGeminiに評価してもらった内容は以下の通りです。

1. 固有名詞（地名・企業名・サービス名）の誤認識

ローカルな地名や企業名、サービス名は、一般的な音声認識エンジンが苦手とする分野であり、今回も顕著にエラーが発生しています。

• 地名の誤り
  • 「春日市（かすがし）」 ⇒ 「糟屋市」：福岡県に「糟屋市」は実在せず、近隣の「糟屋郡」などの地名に引っ張られた、あるいは音の類似による誤認識とみられます。
  • 「太宰府市（だざいふし）」 ⇒ 「田在氏」：「ふ」の音が脱落し、実在しない人名のような表記に誤変換されています。
  • 「鳥栖市（とすし）」 ⇒ 「戸栗市」：音の響きから誤認識されています。
  • 「大刀洗町（たちあらいまち）」 ⇒ 「田原町」：難読地名のため、別の地名（あるいは一般的な読み）に置換されています。
  • 「桂川町（けいせんまち）」 ⇒ 「勝浦町」：こちらも「けいせん」という難読な読みが、一般的な「かつうら」に誤認識されています。
• 企業名・サービス名の誤り
  • 「QTnet」 ⇒ 「QTネット」、「CRCCメディア」 ⇒ 「CRCメディア」：アルファベット表記の揺れや、文字の脱落が見られます。
  • 「嘉麻市（かまし）ケーブルネットワーク」 ⇒ 「嘉松ケーブルネットワーク」：地名由来の企業名の誤認識です。
  • 「くーみんテレビ」 ⇒ 「区民テレビ」：同音の一般名詞（区民）への誤変換です。
  • 「はっぴとす（ビジョン）」 ⇒ 「ハッピー戸栗（ビジョン）」：直前の「鳥栖市 $\rightarrow$ 戸栗市」の誤認識に引きずられる形で、サービス名も「戸栗」に引っ張られています。
  • 「ケービレッジ」 ⇒ 「ケーブルレッチ」：「ケーブルテレビ」という文脈から、認識エンジンが推測して誤変換した可能性があります。
  • 「株式会社メック」 ⇒ 「株式会社ミック」：母音（e と i）の誤認識です。

2. 一般名詞・専門用語・表現の誤認識

音の類似性による同音異義語への誤変換や、専門用語の聞き間違いが起きています。

• 「地上波や衛星放送」 ⇒ 「事情やEASY放送」：今回の書き起こしの中で最も大きな誤認識の一つです。「ちじょうは（地上波）」が「じじょう（事情）」、「えいせい（衛星）」が英語の「EASY」に誤認識されています。
• 「天神に本社を置く」 ⇒ 「天神日本橋を置く」：「に本社を（にほんしゃを）」が「日本橋（にほんばし / にほんばしゃ？）」のように誤認識された可能性があります。
• 「公営だった」 ⇒ 「光栄だった」：同音異義語の誤変換です。
• 「老舗局（しにせきょく）」 ⇒ 「市議測」：「しにせきょく」が「しぎそく」のように聞き取られたか、あるいは未知語として別の漢字が当てはめられています。
• 「CATV」 ⇒ 「CETV」：アルファベット（A と E）の誤認識です。
• 「医療検査用の」 ⇒ 「医療機器採用の」：音の響きは似ていますが、意味が変わってしまっています。
• 「共同アンテナ組合」 ⇒ 「共同運営の組合」
• 「普段何気なく」 ⇒ 「普段意識なく」：「なにげなく」が「いしきなく」に誤認識されており、文意が不自然になっています。
• 「工夫が詰まっている」 ⇒ 「工夫で集まっている」

3. 微細な言葉の揺れ・脱落

音声認識時、あるいは話者の発話の揺れ（言い淀みや省略など）によると思われる差異です。

• 「事業者5社を」 ⇒ 「事業者を」（「5社を」の脱落）
• 「お馴染み」 ⇒ 「馴染み」
• 「手広く」 ⇒ 「手幅広く」
• 「持っていた縁で」 ⇒ 「持っていたんで」
• 「機械」 ⇒ 「機器」

4. 段落構成・話者の混同

書き起こし結果では話者ラベル（Narrator / Guide）が除去されているため、一部の段落で本来別々の話者のセリフであるものが、ひとつの段落として結合してしまっています。

• 例：中盤の「～提供しているんです。県境を越えて地域をがっちり支えている～」の部分や、後半の「～インターネットサービスも提供しています。地域の難視聴を～」の部分など。

主な修正対照表（抜粋）

改善に向けたアドバイス

今回の書き起こしは、一般的な対話の聞き取りとしてはスムーズな部分も多いですが、専門的な紹介ナレーションであるため、固有名詞や専門用語の正確性が課題となっています。

自動音声認識（ASR）システムをご利用の場合、以下の対策を行うことで精度向上が期待できます。

1. カスタム辞書の登録（固有名詞の事前学習） 「QTnet」「CRCCメディア」「くーみんテレビ」「はっぴとす」「ケービレッジ」「桂川町（けいせんまち）」「大刀洗町（たちあらいまち）」などの地域独自の固有名詞をシステムに事前登録することで、大半の誤認識を防ぐことができます。
2. 音響モデル・言語モデルの調整 「地上波や衛星放送」が「事情やEASY放送」になったケースなど、放送・通信業界に特化したコーパス（テキストデータ）を言語モデルに追加、あるいは関連文書を認識プロファイルに読み込ませることで、業界用語の認識率を高められます。