世界を動かす技術を、日本語で。

ニューラルオーディオコーデック:音声をLLMに取り込む方法

概要

  • 音声LLM は現在のテキストLLMに比べて大きく遅れている現状
  • 音声のモデリング はテキストよりも難易度が高い理由
  • ニューラル音声コーデック を使ったアプローチの重要性
  • VQ-VAE (ベクトル量子化オートエンコーダ)の仕組みとメリット
  • 今後の課題 と音声生成モデルの発展可能性

音声LLMの現状と課題

  • 音声LLM は、現在のテキストLLM(例:GPT-4oなど)に比べて知能や自然さで劣る現状
  • 多くの音声LLMは、 音声→テキスト変換→テキスト生成→テキスト→音声変換 というラッパー的手法
  • これにより、 声の感情や抑揚、皮肉、共感 などの理解・表現が困難
  • GeminiやChatGPTのAdvanced Voice Modeなど、ネイティブ音声対応のLLMもあるが、 実用面や知能面で限界
  • 例:「高い声で“私の声は高い?”と聞いても、正しく判別できない」問題

テキストと音声モデリングの違い

  • テキストは バイトペアエンコーディング(BPE) などで容易にトークン化が可能
  • GPT-4oのトークナイザーなど、長年同じ仕組みを利用
  • 音声は1秒間に数万サンプル とデータ量が多く、長期的な一貫性を保つモデル構築が難しい
  • WaveNetのように サンプル単位で予測 する方法は、計算コストが高く、生成も非現実的に遅い

ニューラル音声コーデックの役割

  • 音声を離散トークンに変換 し、LLMで予測しやすい形に圧縮
  • コーデックを用いることで、 音声→トークン→LLM→トークン→音声 という流れが可能
  • Kyutaiチームの Mimi など、実際のモデルで採用例
  • SesameのCSMなど、他モデルでも応用

サンプル単位生成の実験

  • Andrej KarpathyのnanoGPTを改造し、 Libri-Lightデータセット で実験
  • μ-lawアルゴリズムで 256バケットに量子化 し、トークンとして扱う
  • 小規模Transformer(151Mパラメータ)で学習
  • 結果: 意味不明な音声、声質の不安定さ、単語の認識不能
  • 10秒音声の生成に 30分以上 かかるなど、実用性に課題

オートエンコーダとVQ-VAEの導入

  • オートエンコーダ で音声を低次元の潜在空間に圧縮・再構成
  • 潜在空間を クラスタリング(例:k-means) し、離散化
  • 量子化操作は非微分可能だが、 ストレートスルー推定器 で勾配を近似
  • コミットメント損失 を導入し、潜在表現がクラスタ中心に近づくように訓練
  • これにより、モデル自体が量子化に適応

VQ-VAEのメリットと今後

  • VQ-VAE は、音声や画像の離散表現を効率的に学習可能
  • 量子化による情報損失を 多段階量子化(Residual Vector Quantization) などで補完可能
  • 音声LLMの進化には、 コーデックの改良と大規模データ・計算資源 の投入が不可欠
  • 今後の課題: リアルタイム性、長期一貫性、感情やニュアンスの理解

まとめ

  • 音声LLM の進化には、 ニューラル音声コーデックVQ-VAE の活用が重要
  • テキストと異なり、 音声データの大規模圧縮と離散化 が不可欠
  • 現状の限界 を突破するには、さらなる研究と技術革新が必要

Hackerたちの意見

いい投稿をシェアしてくれてありがとう!チームと共有するよ。最近、AIスイートで音声を使い始めたばかりだから、ここに書いてある内容はとても役に立ちそうだね。

多くのLLMには音声インターフェースがあるけど、通常はあなたの話を文字に起こして、テキストで答えを生成し、その後テキスト読み上げを使って返答を声に出しているんだ。それは多くの場合には問題ないけど、実際の音声理解ではなくてラッパーみたいなものだね。でも、トークン化についても同じことが言えるよ。LLMはまず文字のグループをトークンに変換して、それを使ってトークンを生成し、最後にトークンを文字に戻すんだ。これも本当の理解じゃないよ!もしLLMがそんなに賢いなら、トークン化のステップを飛ばせるはずだよ。

本当の理解なんてないよ。理解の基準がないから、理解が何かを機械的に知っているわけじゃないし。今のところ、最も良いのは人々がその場で作り上げた基準を「雰囲気で知っている」ってことかな。

ずっと疑問に思ってるのは、音声をトークン化する努力がなぜされなかったのかってこと。書き起こした言葉じゃなくてね。トレーニングに使える音声は大量にあるのに。

音声トレーニングのトランスフォーマーの瞬間はまだ来てないと思うけど、理論的には音声優先のモデルはもっと能力が高くなるはずだね。

音声トークンはテキストに比べて少なくとも4倍のトークンを消費するから、まず効率の問題があるね。それに、ゼロからLLMをトレーニングするのに十分な音声データはあるのかな?

データはあるけど、書き言葉の量には全然及ばないし、言語、方言、イントネーション、表情、手のジェスチャーなどの追加機能を考慮する必要がないほど標準化されているわけじゃない。音声からテキストへの変換は、そういった他の特徴を多く捨てて、言語間でマッピングするのにもっと効率的なトークンのセットに文脈を与えるために使われているんだ。

音声トークンでのトレーニングはコストがかかるけど、きっとそこにたどり着くよ。YouTubeの講義のトランスクリプトでモデルをトレーニングするのと、その音声でトレーニングするのでは違いが出るはずだね。

記事はまさにそれについて話してるよ。重要な質問は、連続的な信号(音声/音声)をどのように離散的なトークンのセットに変換するかってこと。音声の一つのウィンドウは通常10msから100msの間だよね。そのウィンドウの意味的かつ音響的な内容を表す「トークン」に全ての情報を圧縮するのは難しい。だから、残差ベクトル量子化が役立つ技術なんだ。単一のタイムスライスを量子化するために、複数の辞書を使って、各々が前の残差レベルに条件付けされるんだ。異なる周波数で信号を量子化することもできるよ。投稿の最後の方には、彼らのMimi音声コーデックで訓練されたLLMのサンプルがあるよ。

これがこの概念について見た中で、一番視覚的に心地よい説明だと思う。おめでとう!僕も似たようなVQ-VAEの作業を試みたことがあるけど、レンダリングされたテキストをトークン化しようとしたんだ。10ポイントのレンダリングフォントで動くビジュアルLLMを作れるか興味があったし、PDFソースも使ってみた。基本的なアイデアは、テキストの画像を生成するより進んだ拡散画像モデルができることをやることだった。特定の画像テキスト拡散モデルを作って、補完を行うこと。さらに、ドキュメントタイプや言語を埋め込めたら、現在の辞書トークナイザーよりも抽象化されたテキストの潜在表現ができるかもと思った。たくさん学べたし、この投稿で全部美しく表現されてると思ったよ。

これは面白いね。音声に直接取り組むのは、テキストよりもはるかに複雑だよね。でも、LLMが音声でネイティブに動作するための一部が、音声を効率的にエンコードするコーデックを見つけることだっていうのはすごくワクワクする。いつか、フォーリエ変換やそれに類似したものに基づかず、声帯の形、舌の位置、喉や胸、口の形を説明する物理的パラメータのセットに基づいた人気の音声コーデックを作ることになるんじゃないかって思う。そんなモデルが統計的に導き出されて、ほぼ「ハードコーディング」されるようになるかも。人間の解剖学はその範囲を超えてあまり変わらないからね。これ、フォルマント音声エンコーディングって呼ばれてると思うけど、LLMがその分野を大きく進展させることになったら面白いな。歴史的には音声合成の方が音声圧縮よりも関係が深いと思うし。

このアプローチで人工音声を作ろうとする試みの長い歴史があるよ。口の部分を再現して、空気を振動させるんだ。どれもかなり馬鹿げていて、書くことが単に音声の派生物じゃないって理解していないような作品ばかりだよ。

音声コーディング/合成では、これは「ソースフィルター」モデルと呼ばれていて(音声生成を声帯の音源と音道のフィルターに分解し、それらをパラメータ化する)、実はTukeyとCooleyによるFFTの再発見よりも古いんだ。

なんで普通の音声コーデックじゃダメなの?JPEGやMP3(つまりDCT/MDCT)が、こういうモデルのために空間と時間の信号をトークン化する合理的な方法じゃないのはどうして?各MP3フレームは完全に自己完結していて、数十ミリ秒の元の音声を完全に再構築できるんだ。他のフレームを必要としないのが、これが最も重要な要素だと思う。128kbps CBRで、各MP3フレームは約418バイトで、約26ミリ秒の時間をカバーしてる。これは生のPCM波形に対して10-11倍の圧縮だよ。MP3は人間が気にしない情報を排除するように設計されてるし、400バイトのトークンをトランスフォーマーモデルで使うのが可能かは分からないけど、試してみたい気持ちがすごくある。

TFAのアプローチは32次元の空間にエンコードするんだ。これは、どの心理音響圧縮アルゴリズムよりもかなり多くの次元だと思う。また、私たちの聴覚システムがあまり処理できない情報を捨てるのは、音声(あるいは一般的に音声)合成が目標ならあまり役に立たないよね。

生の400バイトのMP3フレームから、特定のLLM用の埋め込みをトレーニングするアダプターを試すことができるよ(4096以上の浮動小数点数、正確な精度は異なるけど)。でも、その情報がニューラルネットワークにとって消化しやすいものでないといけない。そうじゃないと、そのアダプターを動かすのはすごく難しいよ。基本的に、ニューラルネットワークは冗長なデータが好きで、圧縮されたデータは嫌うからね。トークン化されたテキストは良いけど、GZIP圧縮されたバイトストリームはダメ。まぁ、実際のところは誰にもわからないけど。これはあくまで経験則だから、数学的な法則じゃないし。だから、MP3ベースのアダプターがうまくいく可能性もあるよ。もっと変なものがうまくいくのを見たことあるし。

JPEGはいいアイデアだね:RGBピクセルから直接畳み込みニューラルネットワーク(CNN)をトレーニングするシンプルでエレガントなアプローチは、圧倒的な実証的成功を収めてきた。でも、異なる入力表現を使うことでネットワークのパフォーマンスをさらに引き出せるのかな?この論文では、シンプルなアイデアを提案して探求してるよ:JPEGコーデックの中で計算されるブロック単位の離散コサイン変換(DCT)係数を直接CNNにトレーニングすること。直感的に言うと、JPEG画像をCNNで処理する際に、ブロック単位の周波数表現を展開したピクセル表現にデコードして、CPUからGPUに移動させて、最初の層で周波数表現に戻るような変換を学習するCNNで処理するのは無駄に思える。両方のステップを飛ばして、周波数領域をネットワークに直接入力してもいいんじゃない?この論文では、\libjpegを修正してDCT係数を直接生成し、異なるサイズとストライドの入力に対応するようにResNet-50ネットワークを修正し、ImageNetでのパフォーマンスを評価してる。結果、より速くて正確なネットワークや、同じ精度でResNet-50より1.77倍速いネットワークが見つかったよ。https://proceedings.neurips.cc/paper_files/paper/2018/file/7... MP3もいいアイデアだと思う。

言語モデルは通常、2バイト(16ビット)のトークンを使うと思うけど、それは埋め込み次元が2^16=65536に対応してるんだ。400バイトごとのトークンだと、2^(400*8)になって、これは非常に大きな数になるよ。実用的には大きすぎると思うけど。

著者です。理由はいくつかありますが、一番大きな理由は単純に圧縮率です。オリジナルのニューラルオーディオコーデックであるSoundStream(最初の著者はニールで、今は九大にいます)は、3kbpsでもそこそこ良い音がしますが、MP3は通常128kbpsくらいですよね。面白いことに、これはもともとGoogle Meetのために音声圧縮用に開発されたもので、LLM用ではなかったんです。今日のニューラルコーデックはさらに良い圧縮が可能です。もっと現代的なMP3の代替品はOpusで、12kbpsでもそこそこ動くけど、ニューラルオーディオコーデックにはまだ及ばないですね。ただ、これらの従来のコーデックはCPUの負荷が少ないので、その点では優れています。

音の知覚は周波数成分を検出することに基づいていて、これは内耳のフィルターバンクを通じて検出します(異なる長さの毛が異なる共鳴周波数を持っています)。音声の知覚は周波数に基づいていて、「フォルマント」と呼ばれる周波数帯域に依存しています。これは、音声が生成される際の発音によって作られる声道の共鳴によって減衰される部分です。具体的には、音声情報のほとんどはフォルマントの変化に含まれていて、これが発音の変化に対応しています。音声には、破裂音(「ぷっ」、「ぶっ」)に対応する音声エネルギーの発生や、「sss」のような摩擦音によって生成される高周波数など、他にも発音に関するアーティファクトがあります。MP3フレームを音声トークンとして埋め込む場合の問題は、MP3圧縮が周波数表現に基づいているとはいえ、量子化やハフマン符号化、MP3フレーム構造がその上に乗っかるので、フレーム全体がブラックボックスになってしまうことです。おそらくトランスフォーマーはMP3フレームを使ってテキストの転写を予測できるかもしれませんが(LLMがBase64表現からテキストを予測するのと似たような感じで)、入力が生成プロセスに対応する周波数成分やフォルマントを隠していると、確実に難しくなります。周波数やフォルマント情報に直接アクセスできないのも、一般化を難しくします。これはフォルマント構造や変化に基づいているからです。同じ単語を発音する際、特定のフォルマント周波数は個人によって異なりますが、主に声道の長さによるものです。でも人間はこれを一般化するのに問題がなく、子供と大人の音声を理解するために特別な訓練は必要ありません。

彼らに「私の声は低い声ですか、高い声ですか?」って高音で聞いてみて。彼らは答えられないよ。これがLLMの性能が悪いのか、LLMがそうしないように(過剰に)調整されているのか、どれくらいの割合なのか気になる。私の知る限り、Chat GPTのボイスモードには音楽生成やアクセントマッチング(インド人の声なら、インド人のように聞こえないはず)を防ぐために多くの安全策が施されていたみたい。これらの行動がモデルから慎重に排除されているのは、そんなに不可能じゃないと思う。

ただの安全策だけじゃないと思う。彼らは本当に音程を全く理解していないみたい。ChatGPTの高度な音声モードに、私がハミングしていたメロディを認識させようとしたら、何度もベートーヴェンの5番だって主張されたんだ。基本的に私のハミングを「ダンダンダン、ダーン」ってトークン化したんだと思う。

Qwen3のオムニトランスクリプターがこれをやってくれるよ。声や感情をすごくうまく表現できるんだ。

彼らは、あなたがどの人種だと思ったかによって反応が変わったの?正直、そんなことするなんて驚きだよ。彼らはテキストの会話を学習してると思ってたから、そういうのはないと思ってたんだけど。

ここでの著者です。これは安全性の問題というより、能力の問題だと思う。音声を学ぶのはテキストを学ぶより難しいから、音声モデルはあまり一般化できないんだ。それを解決するために、音声モデルはテキストと音声の情報を組み合わせることに依存してる(テキストと音声のトークンを同時に扱う単一モデルを持つこと)し、音声トークンは基本的に統合された音声認識/音声合成になってる。これはMoshiでの同僚の経験を反映していて、他のモデルでも同様のことがあるみたいだね。結論のセクションを見てみて。理由の一部は合成データにもあるかも:テキストから音声合成で生成されたデータでファインチューニングすると、声のトーンには情報がないから、モデルはそれを無視するように学習しちゃうんだ。

ここで興味深いのは、モデルが時間の経過について何らかの理解を持っているらしいことだね。チャットモデルに関しては、1秒後に返事をしても1ヶ月後に返事をしても同じ反応をするのが変なところだと思う。テキストモデルでも「ストリーム」が役立つかもしれないね。例えば、LLMが何かを説明して質問した後に長い間沈黙が続くと、「助けが必要?」って割り込むことができるかも。純粋なチャットGPTにはその能力がないけど。

RWKVやS4のような線形空間で定数時間のモデルがここでうまく機能するのかなと考えています。音声に関しては、長距離のコンテキストは必要ないと思うし、全てに対するマッピングは過剰な気がします。もしかしたらトランスフォーマーが並行して動いて、もっと低い周波数で、線形モデルが「サマリー」トークンを1秒ごとに提供する形になるかもしれません。その情報は主に「テキスト」ですが、感情や他の手がかりも含まれる感じです。それからこの出力を線形モデルにフィードバックして、何を言っていて、どんな感情で言っているのかを知ることができるようにします。基本的にトランスフォーマーは低周波の長距離コンテキストを考える(感じる)役割を果たし、線形モデルがそれを音声学に翻訳します。彼らは並行して訓練されるので、トランスフォーマートークンは訓練時に意味を持つようになり、事前に定義する必要はありません。だから、純粋に音声から音声への変換で、テキストへの直接的な翻訳はないです。これがLLMのためのテキスト圧縮の良い方法になるかもしれません。低価値の単語はトークン内で小さな表現になるかもしれませんし、論理やコードに関してはテキストベースのLLMには到底及ばないでしょうが、それは人間とも似たようなところがあります。詳細にアルゴリズムを説明するのは普通の会話では結構難しいですからね。