李沐がついに新モデルをオープンソース化し、リリース後すぐに3.6kスターを獲得！
7月23日、李沐はHiggs Audio v2のオープンソース化を発表しました。これはLlama-3.2-3Bを基盤に構築された音声基礎モデルで、
事前学習データには1000万時間を超える音声データと豊富なテキストデータが含まれています。このモデルは現在GitHubで3.6kスターを獲得しています。
「昨年はテキスト言語モデルに焦点を当て、その知能を十分に高め、人間の指示に従えるようにしました。これにより、ゲームで人間と遊ぶことや、一部の文書作成作業を支援することが可能になりました。要するに、読むことも書くこともできるモデルを目指しました。今年は、モデルが聞くことも話すこともできるかどうかを検討しました」と、李沐はBilibiliで公開した動画で述べました。
その後、彼は次のように続けました。「音声はAI分野で比較的歴史の長い領域であり、私は音声分野の専門家ではありません。
新人として私の考えはシンプルです。音声モデルを単独で訓練するのではなく、テキストの大規模言語モデル訓練時に大量の音声データを組み込み、大量のデータを投入して成果を出す。テキスト言語モデルの知能を低下させず、同時に音声でのコミュニケーション能力を習得させることを目指しています」
李沐は世界的に有名なAI深層学習科学者で、深層学習フレームワークMXNetの共同開発者。2008年に上海交通大学コンピュータ科学部卒業後、マイクロソフトアジア研究所でインターンを経験。
卒業後、香港科技大学の研究助手を務め、2011年に百度に入社し高級研究員に就任。2012年にカーネギーメロン大学で博士号を取得し、その間グーグルでコードドキュメントの研究に従事しました。
2017年に博士号を取得後、アマゾンにAI主任科学者として入社し、7年半勤務した後退職し、大規模モデル企業Boson AIを設立しました。
報道によると、EmergentTTS-Eval評価において、Higgs Audio v2は「感情（Emotions）」と「質問（Questions）」の2つのカテゴリーで、「gpt-4o-mini-tts」に対しそれぞれ75.7%と55.7%の勝率を達成しました。
また、Seed-TTS Evalや感情音声データセット（Emotional Speech Dataset, ESD）などの伝統的なTTSベンチマークテストでも業界トップクラスの成績を収めています。
さらに、このモデルは多言語対応の自然多話者対話生成、ナレーション時の自動イントネーション適応、クローン音声のメロディハミング、音声と背景音楽の同期生成など、他の機能も示しています。
李沐は最新の動画で、Higgs Audio v2 の技術的背景と遭遇した課題について詳細に説明しています。
テキストモデル訓練時
1000万時間の音声データを追加
李沐はHiggs Audio v2のアーキテクチャについて説明を開始しました。その前に、テキストモデルの原理を例を交えて振り返りました。例えば、「中国の首都は？」とモデルに尋ねると、言語モデルは問題を見た瞬間に回答を開始し、まず「北」を連想し、次に「北」と問題文を組み合わせて、次の単語を「京」と予測します。
しかし、実際の使用では、言語モデルにこのような文字の連鎖を直接させることは避けられます。なぜなら、これでは制御が難しいからです。
一般的なアプローチは、質問を3つの部分に分割することです。まず「system」部分では、言語モデルに何をすべきかを指示します。例えば質問に答えるように指示するほか、雑談や文章の作成など他のタスクを指示することも可能です；
次に「user」部分では、モデルに具体的な指示を与えます。例えば具体的な質問内容や作成する小説の形式などです。そして「system」がモデルの応答となります。さらに、複数回のやり取りを可能にするため、もう1つの「user」セクションを追加し、その後に「system」セクションを接続する構造にすることもできます。
このモデルに音声の入力と出力をサポートさせることは、モデルに新しいタスクを追加することです。例えば、モデルに「以下のテキストを音声に変換してください」というシステムコマンドを渡し、ユーザーの入力で変換対象のテキストをモデルに伝え、モデルが「system」セクションで対応する音声データを出力するようにします。
なぜ言語モデルをこのような形に改造するのでしょうか？李沐は次のように説明しています。音声認識や音声生成は、それぞれ独立したモデルであり、その役割は文字を音声に変換するか、音声から文字に変換することだけです。例えばWhisperもTransformerを基盤としていますが、一つのことしか行いません。
テキストモデルに音声出力を追加するデメリットは明白です：音声処理能力を向上させようとすると、純粋な音声モデルに比べてモデルサイズが肥大化します。同様に、テキストモデルに音声データを追加すると、モデルの「知能」が低下する可能性があります。
しかし、このアプローチの利点も明確です。例えば、以下の図は簡略化したタスクのバージョンを示しています：
プロの音声録音時、監督はプロの声優に録音のシーン（ここでは「小明と小紅が喧嘩している」）を説明し、キャラクターの性格（ここでは「小明は短気な性格で、小紅は控えめな性格」など）を指示します。
次に、実際に録音する会話の部分で、小明が何を言うか、小紅が何を言うか、それに伴う動作の音響効果なども加えます。プロの録音俳優は、単に台詞を読むだけでなく、キャラクターの設定やシーンに合わせ、良い演技を表現する必要があります。
以前のテキストから音声への変換モデルは、このような複雑な設定を理解するのが難しかったかもしれません。しかし、言語モデルを活用することで、理解可能になる可能性があります。なぜなら、テキスト領域ではモデルに非常に複雑な指示を与えるのが一般的だからです：「a、b、c、d、e、f、gを実行し、その結果を出力してください」
そのため、モデル訓練時に人間の指示に従うように訓練されます。テキスト言語モデルの能力を維持すれば、音声出力時にも複雑な指示の理解をサポートできます。
さらに、単純なテキストから音声への変換タスクでは、ユーザーのニーズを満たせなくなっています。私たちは単に音声を生成するだけでなく、曲を作成して歌わせ、音楽も合わせることを望んでいます。これは生成側の応用例ですが、理解側でも活用可能です。
例えば、音声データを与え、モデルが其中の人物の発言を抽出する、これが最もシンプルな例です；
次に、モデルに音声内で何が起こっているかを分析させることができます。例えば、話者が男性か女性か、年齢はどのくらいか、喧嘩しているのか、会話しているのか、授業を行っているのか、環境音から室内か屋外か他のシーンかを推測することも可能です。
音声には大量の信号が含まれており、人間は全体の文脈を理解できます。テキスト言語モデルの支援を受けることで、モデルもこのような複雑な理解と推論を行うことができます。
より複雑な応用例として、モデルと音声で会話する際、モデルが単に機械的に応答を繰り返すのではなく、人々の現在の感情を理解し、自身の感情を表現できることが求められます。さらに、応答の遅延が十分に低く、一言発した後に1～2秒待たされることなく、対面での会話のようにスムーズにやり取りできることが重要です。
李沐は、これらのタスクはすべて「システム、ユーザー、アシスタント」という形式に分解でき、言語モデルが統一的に処理できると述べています。つまり「一つの基本レシピで全ての問題を解決できる」ということです。
チームは、比較的固定されたシンプルなモデルを使用し、より多くのデータと計算リソースを追加することで、スケーリング法則を活用して大きな成果を上げることを目指しています。
モデルは音声信号をどのように理解し出力するのでしょうか？
次に、2つの「どのように実現するか」という質問に答えます：
モデルが音声信号または音声データを理解し出力する方法は？
モデルを訓練する際、どのようなデータを構築すれば、モデルが音声信号とテキスト信号を適切に融合させ、音声が何を表現しているかを理解できるようになるのでしょうか？
最初の質問について、李沐は言語モデルにおける文字の表現方法から説明しました。
文字は言語モデル内でトークンやリソースとして表現されます。単純に言えば、日本語の漢字や英単語の語根がトークンに相当し、入力文字はトークン列に変換されます。言語モデルのタスクは、トークン列の次のトークンを予測することです。
トークンは離散的な概念であり、数万のトークンを含む辞書が存在します。言語モデルの出力はSoftmaxであり、本質的に多クラス分類問題です。毎回辞書から1つの単語を選択して出力します。
音声信号はより複雑です。連続した信号をどのように離散的なトークンに変換するのでしょうか？
一つの簡単な方法は、固定時間（例えば100ミリ秒）で音声データを分割し、音声の細粒度での繰り返し出現の特性を利用して、各セグメントに事前定義された代表的な音声テンプレート（トークン）を割り当てることで近似表現します。
例えば、45個の音声断片をテンプレートとして使用し、1秒の音声入力に対して、その音声を入力として10個の断片に分割し、各断片に45個のテンプレートの中から最も一致するテンプレートの番号を割り当てます。最終的に、その1秒の音声は長さ10の番号のシーケンスに変換されます。
この表現方法により、言語モデルは音声信号をテキストトークンと同様に処理できるようになります。入力としても出力としてもです。
もちろん、実践ではそれほど単純ではありません。音声信号は簡単に表現できるものではありません。
例えば、1時間の信号を128 BPSのMP3で保存すると、約60MB（中程度の音質）になります。64,000個のトークンで表現した場合、1秒の音声は24個のトークンで表現されます。
この方式で音声データをエンコードする場合、各トークンにはlog₂(64,000) ≈ 16ビットが必要となり、1秒の音声は384ビット（24×16）で表せます。1時間を圧縮すると0.16MBとなり、128kbps MP3に比べて375倍の圧縮率を実現します。
このような高い圧縮率は必然的に情報損失を伴います。この場合、重要な問題は「トークナイザーは音声信号（例えば声のトーン）を優先して保持すべきか、それとも意味信号（具体的に何と言っているか）を優先すべきか」です。李沐チームの結論は「意味情報を優先する」です。
音響信号は少数の特徴量で核心的なスタイルを保持でき、後から他の方法で復元可能です。しかし、意味信号は多様で、同じ音声が異なる文脈で全く異なる内容を表現する可能性があります。
したがって、意味情報の完全性を可能な限り保持し、意味トークンに十分な意味情報を包含させ、モデルが早期に音声とテキストのトークン間の強い意味的関連性を確立できるようにする必要があります。これにより、音声とテキストの相互変換をスムーズに実現できます。
音声データをトークン化してモデルに投入した後、次に注目すべきはモデルがこれらの音声データをどのように理解し生成するかです。
音声からテキスト、またはテキストから音声への変換は、本質的にモダリティ間の変換です。したがって、言語モデルはコンテンツの音声表現とテキスト表現をマッピングできます。
現在、テキストの大規模モデルは既に非常に強力です。現在課題となっているのは、音声の語義を可能な限りテキストにマッピングし、モデルがテキスト領域で持つ強力な能力を継承することです。
リアルタイム音声アシスタントの場合、ユーザーが発言しモデルが応答する仕組みは、音声空間で直接処理しているように思えますが、実際はテキストの音声空間に戻ります。
音声アシスタントでは、キャラクター設定や処理すべき内容の判断はテキストで制御されます。また、リアルタイムインタラクション時もテキスト空間で行われる可能性が高いです。
例えば「今日の天気は？」と尋ねた場合、モデルはテキスト空間で検索し、結果を返した後、音声信号にマッピングします。したがって、モデルの核心は、テキストと音声の表現間の関連性を確立し、同じ概念が異なるモダリティで対応する関係をモデルが理解することです。
データが用意できた後、
モデルをどう訓練するか？
この目標が明確になれば、必要なデータの種類とデータの表現方法を検討できます。
「データは多ければ多いほど良いと思います」と李沐は述べ、チームはBilibiliやYouTubeのデータを使用しなかったのは、品質が悪いからではなく、著作権リスクを回避するためだと説明しました。
その方法は、コンプライアンスに準拠したデータを購入するか、公開が許可されたオーディオを収集するかのいずれかです。後者の場合、90%のデータを削除してようやく一部の利用可能なデータが残る可能性があります。例えば、1,000万時間の有効なデータを取得するには、約1億時間の原始素材を収集する必要があります。
データを入手した後、チームはどのようにモデルを訓練するのでしょうか？
例えば、音声データをモデル訓練に用いる場合、通常は次のように表現されます：システムレベルでこの音声の音声学的特徴、話の内容、話者の人数とその特徴などを説明します。次に、ユーザーが入力したチャットテキストを入力として、モデルが対応する音声を出力します。
このタスクでは、チームはモデルが提供された全体のシーン説明と生成すべきテキストに基づいて、現実的でシーンに合った音声を出力できるようにしたいと考えています。
これらのラベルをどのように付与するかという点について、李沐の提案は次のようにです：学生が研究を行う場合、音声データをOpenAIのGPTやGoogleのJamilaに渡し、ラベル付けを依頼することを推奨します。
しかし、李沐は自チームがこれを行うことができない理由を2つ挙げました：1つ目は、相手方が自社のモデルの出力を他のモデル訓練に利用することを明示的に禁止していること；2つ目は、コストが高すぎる点です。チームが処理する必要のあるデータ量は1千万件を遥かに超え、億単位になる可能性があり、そのようなAPIのコストは負担できません。
李沐のチームは次のように対応しています：同じモデルアーキテクチャを採用し、追加で音声理解モデルを訓練します。音声理解モデルの入力と出力は次のように想像できるでしょう：音声生成時には、シーンの記述とユーザーの発言内容を入力し、音声を出力します。現在は逆で、ユーザーの発言音声を入力し、モデルにシーンの分析（例：登場人物、その人物の特徴、発言内容）や発言時の感情状態などを分析させ、これらの情報をすべて出力させます。
これは生成モデルの入力と出力を入れ替えたようなものです：生成モデルの入力（シーンの記述と発言内容）が理解モデルの出力となり、生成モデルの出力（音声）が理解モデルの入力となります。
例えるなら、弟子に拳法の全技を教えるが、一度に全てを教えることはできない。そこで、まず一人の弟子に拳を教え、別の弟子に蹴りを教え、その後二人で毎日対戦させ、互いに切磋琢磨しながら最終的に両者が完全な拳法を習得する。
最後に、Higgs Audio v2では、以下のアーキテクチャ図に示す「生成型変種（generation variant）」を採用しています。
このモデルの性能は、以下の3つの主要な技術革新に支えられています：
チームは、複数の音声認識（ASR）モデル、音声イベント分類モデル、および自社開発の音声理解モデルを組み合わせた自動化ラベル付けプロセスを開発しました。
このプロセスを通じて、チームは1000万時間の音声データをクリーニングし、ラベル付けし、これをAudioVerseと名付けました。自社開発の理解モデルは、Higgs Audio v1 Understandingを微調整したもので、後者はアーキテクチャ図に示された「理解変種（understanding variant）」を採用しています。
ゼロから統一された音声トークナイザー（tokenizer）を訓練し、意味と音響的特長の両方を同時に捕捉できるようにしました。
DualFFNアーキテクチャを提案し、計算コストをほとんど増加させずに、大規模言語モデル（LLM）の音響トークンモデリング能力を大幅に向上させました。DualFFNを導入後も、元のLLMのトレーニング速度の91%を維持しています。
(https://higgsaudio.io/)