見出し画像

ボイスモード

AGIに仕事を奪われたい

36,961 文字

Twitchでテストしてます。よっしゃ、Twitchはうまくいきましたな。YouTubeでも試してみましょか。YouTubeでテストしてます。YouTube。ハロー。ハロー。YouTubeでテストしてます。テスト、テスト。ほな、YouTubeもうまくいきましたな。Xでテストしてます。Xでテストしてます。Xでテストしてます。Xでテストしてます。
ほんで、Xのライブ配信にはちょっと遅延があるみたいやな。ホンマにライブちゃうみたいやわ。OmaVivaさん、調子はどないですか？ Johnboy01さん、元気ですか？ UM Harrow？UM Harrowって何やろ、わからんわ。Sarahさん、調子はどないですか？ほな、ちょっと水飲んで始めましょか。
みなさん、フーポーのストリームにようこそ。今日は音声モードについて見ていきますわ。音声モードはOpenAIの最新リリースの名前で、要するに音声対音声の体験やねんな。LLMと話して、それが音声で返してくれて、割り込みもできるし、より自然な音声モードになってるわけや。でも、その裏側の情報はないから、代わりにオープンソースの論文を2つ見ていくことにしましょ。これらは実質的に同じもんやねんけどな。
まず「Moshi: A Speech-Text Foundation Model for Real-Time Dialogue」やな。この論文は2024年9月18日に出たもんで、つい2週間ほど前のもんや。これはQT AI、つまりCute AIっていう組織から出てるんやけど、Cutieって言いたいんかな。Cutieはちっちゃなチームで、これが彼らのXかTwitterのプロフィールや。フランスのパリにあって、十数人くらいのメンバーがおるみたいやな。かなり小さな研究所やけど、めっちゃ評価せなあかんわ。
この論文がすごく詳細で、67ページ以上もあって、やったことの全てが書かれてるねん。全ての実験、比較、アブレーション、アーキテクチャのあらゆる部分、どうやってそれに至ったか、その理由まで全部や。めっちゃ良い論文で、本当に感謝せなあかんわ。
オープンソースコミュニティの人たちが出てきて、これを公開することを選んだっていうのはすごいことやと思うわ。これを非公開にしておくのは簡単やったはずやし、彼らに投資してるVCも非公開にしろって言ったはずやねんけど、全部公開することを選んだっていうのは、本当に評価せなあかんわ。
だから、オープンソースとクローズドAI、クローズドAIっていうのはGPTの音声モードのことやけど、オープンソースはこの人たちのことやな。彼らにいいね！したり、ページをフォローしたりするのが、こういうものをサポートする一番簡単な方法やと思うわ。
もう一つの論文は、似たような発表日の「LLaMA Omni: Seamless Speech Interaction with Large Language Model」や。これはいくつかの中国の学術機関から出てるもんやな。Key Laboratory of AI Safetyって、これ学術機関なんか、それとも政府機関なんかな？正確にはわからんけど、基本的に同じことやな。音声対音声やけど、ちょっとデザインが違うんや。
詳しいところは実際に中身を見ていく時に説明するけど、これらは少し違うデザインで、ちょっと違う体験になるんやな。じゃあ、Moshiの要約から始めていこか。
現在の会話システムは、独立したコンポーネントのパイプラインに頼ってるんやな。つまり、音声認識、音声認識、テキスト対話、音声合成っていう具合や。でも、これじゃあ本物の会話の体験を再現できへんのや。なぜかっていうと、現在の音声対音声システムは、基本的に別々の小さなブロックを連結させて作られてるからや。
ASRっていうのがあって、これがオーディオを取り込んでテキストに変換するんや。そのテキストがNLUに送られるんやけど、これは言語モデルの古い言い方やな。基本的にはテキストモデルのことや。それから、TTSかテキスト音声合成があって、そのテキストを音声に変換するんや。
この3つのシステムを組み合わせたのが、人々が頼ってきたものなんや。特にASRとTTSのシステムがすでにうまく動いてたから、LLMが出てきた時に、この3つを組み合わせるのが自然やったんや。
でも問題は、このパイプラインの多くのコンポーネントに遅延が積み重なって、通常は数秒の全体的な遅延が発生するんや。つまり、話し終わってからASRに通して、LLMに通して、TTSに戻すまでに数秒かかるんや。これじゃあ、人間が自然な会話を感じるには遅すぎるんや。
それに、感情やアクセントみたいな言語以外の情報も失われてしまうんや。基本的に、話したことがテキストに変換されて、言語モデルはイントネーションや感情、タイミングなんかの概念を持ってへんから、ちょっとロボットっぽい感じで音声を生成してしまうんや。
そこで、MoshiとLLaMA Omniは、これらの部分を全部一緒に焼き上げることで、この問題を解決しようとしてるんや。つまり、ASR、LLM、TTSの3つの別々のシステムを、まだトランスフォーマーベースやけど、新しい方法で1つのシステムに組み合わせようとしてるんや。これをマルチストリームって呼んでるんやけど、Moshiは2つの部分からできてるけど、そのことは後で詳しく説明するわ。
これは、入力と出力のオーディオストリームを2つの自己回帰的なトークンストリームに明示的に処理する、最初のマルチストリームオーディオ言語モデルなんや。これによって、話者の順番っていう概念が完全になくなって、重複や割り込みを含む任意の動きを持つ自然な会話でモデルを訓練できるようになったんや。
つまり、私が何か言って、あなたが何か言って、私が何か言って、あなたが何か言うっていう概念がなくなったんや。これは、一般的なテキストベースの言語モデルの仕組みなんや。自己回帰的にトークンを1つずつ生成していくから、言語モデルと話す時は、全てのトークンが1つのシーケンスに並んでるんや。つまり、あなたがトークンの入力を止めて、モデルがトークンの出力を始める明確な停止点があるんや。あなたのトークン、モデルのトークン、あなたのトークン、モデルのトークンっていう具合やな。
でも、Moshiでは2つのストリームがあって、実際にはそれ以上のシーケンスがあるんやけど、両方が同時に起こってるんや。これは、重複が可能ってことやな。人間と話す時にはよくあることやけど、言語モデルと話す時には、ちょっと割り込んで相手が止まって、そのまま話し続けるみたいなことができるんや。
彼らが説明してる方法は、この全体の列を1つの方法として考えることができるんや。各タイムステップは基本的に80ミリ秒で、この全体の列を出力してるんや。ポン、ポン、ポンって感じやな。そして、Moshiが言ってる紫のトークンが最初に出てくるのは、緑のトークンが終わる前なんや。だから、これらが全部重なり合う感じのローリングウィンドウみたいなもんなんや。
ユーザーが話してる時も、Moshiは止まらへんのや。GPTとテキストで話してる時は、これらのトークンとこれらのトークンは全部同じシーケンスにあるんや。だから、ユーザーがトークンを生成してる間はLLMから音響やセマンティックトークンを生成できへんのや。これはユーザーのトークンなのか、アシスタントのトークンなのかを決めないといけないんや。
でも、ここではこれを全部一緒にやってるから、この重複ができるんや。つまり、あなたが話してる時も、まだトークンを生成して予測してるんやけど、出力してるトークンは基本的に無音トークンなんや。これはちょっとクールなアイデアやと思うわ。これによって、モデルは重複する発話順番を扱えるようになるんや。ユーザーのオーディオがモデルから出てくるオーディオトークンと重なることができるんや。
ごめんな、同時にMoshiを動かしてたから。みんな複数の人が同時に話してるのを聞かされてもうたな。かなりひどい音やったと思うわ。
続けていこか。スケーラブルな階層的オーディオトークンのモデリングで、数分のコンテキストを扱いながらリアルタイムでオーディオを生成できるんや。これが関連する仕事やな。基本的に、ライブインタラクションとは相容れへんのや。モデルは話し始める前に、答え全体をテキストとして生成する必要があるんや。これは、それを異なるチャンクに分ける時のことや。
それから内部モノローグがあるんや。内部モノローグは、speech（音声）をtext（テキスト）、semantic（意味）、acoustic（音響）トークンの連鎖に分解するんや。そやから、ここにある内部モノローグがここにあるんや。このテキストやな。
頑張ってるわ。あなたの言ってることはわかるで。はい、見えてます。
そやから、これがMoshiの基本やな。ここで一つ面白いのは、Heliumバックボーンの知識やな。例えば、このLLaMA Omniっていう論文と、このMoshiの間の一つの違いは、彼らが出発点とするLLMなんや。この場合、彼らは実際にこのHelium言語モデルから始めてるんや。Heliumはトランスフォーマー言語モデルで、ブラブラブラ...やけど、あんまり大きくないし、そんなに賢くもないと思うわ。
だから、実際の音声アシスタントの知能は、主に出発点となるLLMに依存するんやな。この場合、このHeliumモデルはLLaMA 3.1.8B Instructここで使われてるモデルほど賢くないんや。これらの人たちは、実際にLLaMA 3.1.8B Instructを出発点の言語モデルとして使ってるんや。これは小さなLLaMAで、8Bは小さい方のモデルの一つで、一般的にはより愚かな傾向があるんや。
だから、このLLaMA Omniの方が、実際にはより賢い言語モデルを持ってると思うわ。LLaMA 8BはHeliumよりも少し賢いと思うから、このLLaMA Omniの方がこのHeliumやこのMoshiよりも少し賢いんやないかな。でも、これは単なる予測やで。実際にこの二つを知能テストしてへんから、本当のところはわからんのや。
じゃあ、LLaMA Omniについて簡単に見ていこか。LLaMA Omniも低遅延を宣伝してるんや。事前学習された音声エンコーダ、音声アダプタ、LLM、そしてストリーミング音声デコーダがあるんや。事前学習された音声エンコーダ、これがここの部分やな。事前学習っていうのは、基本的にそこにグラデーションを押し込もうとしないってことや。
この論文では、もうちょっと努力してるんやけどな。彼ら自身のエンコーダを訓練してるんや。これがここにあるMimiっていうやつや。残差ベクトル量子化を持つニューラルオーディオコーデックから蒸留された意味知識で、自己教師あり音声モデルから蒸留されたものや。だから、ここでMimiっていう自分たちのエンコーダを使うことになるんや。
ここにエンコーダMimiがあって、それからデコーダMimiがあるのが見えるやろ？これがMimiの二つの半分や。エンコーダとデコーダやな。この論文では、基本的に事前学習されたものを使うんや。具体的にはWhisperのやつやな。音声指示から直接テキストと音声の応答を同時に生成するんや。遅延は226ミリ秒ほどや。
こっちの論文では、理論上の下限が160ミリ秒で、実際には200ミリ秒くらいになるんや。こういう遅延に関する論文では、その遅延がどんな感じかを視覚化したかってん。そこでGPT-4にちょっとした遅延比較のウェブサイトを作らせたんや。
これは本当に、GPT-4にゼロショットで作らせただけのちっちゃなウェブサイトやけど、200ミリ秒がどんなもんかが見えるやろ？226ミリ秒やな。これはかなりええと思うわ。ブラブラブラ...って言うて、その緑の四角がピカッと光った瞬間に次のが始まるんや。これはいけるやろ？人間の反応時間が100ミリ秒くらいやっていうのもわかるやろ。
それに、例えば60フレーム毎秒は16ミリ秒くらいやしな。もう一桁くらい小さくなれば、必要以上に速くなるんちゃうかな。考え方としては、携帯の画面を思い出してみ。携帯の画面の解像度が低かった時期があって、その後何世代かにわたって解像度が上がっていったんや。
でも、ある時点で、画面の解像度が十分良くなって、携帯を20センチくらい離して見ても、もうピクセルを増やしても違いがわからんくらいになったんや。目で検知できる解像度には限界があるからな。遅延にも同じようなことが言えるんや。
人間として、10ミリ秒と100ミリ秒の違いはわかるけど、1ミリ秒と10ミリ秒の違い、さらに1ミリ秒以下になったら、もう関係なくなるんや。だから、この遅延は十分すぎるくらいに近づいてると思うわ。これ以上押し進める必要はないかもしれへんな。
音声対話を可能にする一番シンプルな方法は、このカスケードシステムを通してやな。もう話したけど、ASRとTTSのことやな。これはもう過去のもんやな。LLaMA Omniは音声とテキストを同時に生成するんや。この同時生成やな。両方の論文がこのアイデアを持ってるんや。複数のストリームやな。
彼らは非自己回帰的ストリーミングトランスフォーマーを使ってて、これが音声応答に対応する離散単位の列を予測するんや。LLMは自己回帰的にテキスト応答を生成して、それから音声デコーダが同時に対応する離散単位を生成するんや。
このデザインは、古典的なASR TTSシステムに少し近いんやな。これを使ってこれを作るみたいな感じやからな。Moshiが持ってるような複数のストリームへの素敵な分解はないけど、遅延はまだかなり良くて、226ミリ秒はMoshiの遅延とほぼ同じやな。だから、比較できると思うわ。
彼らは...ちょっと待ってな。LLaMA 3.2がやったように、こういうモデルを蒸留できるんかな？うん、これらには蒸留を使えるんや。実際、蒸留はこれらの論文の大きな部分なんや。
例えば、このLLaMA Omniモデルでは、WhisperLarge V3を大いに使ってるんや。音声エンコーダ、つまり波形を圧縮表現に変換するものと、音声デコーダ、これらはただのWhisperLarge V3なんや。WhisperLarge V3がなければ、この研究は不可能やったんやな。
この人たちも自分たちのエンコーダとデコーダを訓練してるけど、ここのMimiやけど、それでもWhisperLarge V3を大いに使ってるんや。それだけやなくて、ここで別のモデルも使ってるんや。例えば、WAV-LMを使ってるんや。
WAV-LMも同じアイデアやな。音声を取り込んで、圧縮して、それをその小さな低次元表現に変換して、それからデコーダで展開するんや。60,000時間の音声で訓練されてて、うん、60,000時間の音声やな。
実際、この人たちがMimiを訓練する時、その一部は蒸留なんや。この部分、敵対的損失ってとこやけど、これは基本的に、音声をこのエンコーダに入れて、それを損失のある圧縮版に変換して、それから...聞こえへんかもしれんけど、デコードするんや。ここのやつはここのやつと同じになるべきやな。
このエンコーダとデコーダにグラデーションを押し込むための学習ターゲットと損失を作る簡単な方法の一つは、このオレンジとこの青を比較することやな。それがここで起こってるんや。この敵対的損失は、これをこれと同じにしたいんやけど、WAV LMから来る追加の学習シグナルがあるんや。
これが基本的に蒸留やな。WAV LMが教師ネットワークで、凍結されててまったく変更されへんのが見えるやろ。そのWAV LMがこの音声を消費して、何らかの数値のベクトルを生成するんや。
彼らが言ってるのは、ゼロから訓練してるこのミニモデルが、これをできるだけ高く再構築しようとしてるんやけど、追加の学習シグナルもあるんや。それは、ここにあるこの中間的なボトルネック表現が、WAV LMがこの波形を何らかのベクトルに変換する時の出力と似ているべきやっていうことや。
だから、彼らはエンコーダを作るために蒸留損失を使ってるんや。これがあなたの質問への答えやな。蒸留がこれに使われてるかどうかって。使われてるんや。これさえオリジналじゃないんや。彼らは別のモデルを蒸留してるし、それだけじゃなくて、後で論文で発見することになるけど、この人たちもWhisper v3を使ってるんや。
例えば、彼らが使うデータセットは、たくさんのテキストデータを取って、それを話させて...Whisperかなんかで書き起こすんや。だから、言いたいのは、こういう種類の研究は、Whisperなしでは、WAV LMなしでは、ここで使われてる別のTTSモデルなしでは不可能やったってことや。Audio SRやな。
基本的に、テキストデータセットを取って、それを音声データセットに変換することで、合成的にデータセットを作ってるんや。それだけじゃなく、他の誰かが訓練した別のエンコーダも使って、それを自分たちのバージョンに蒸留してるんや。
だから、AIの研究はこういう段階に来てるんや。一つのデータセットがあって、それを訓練して、それでおしまいってわけじゃないんや。他のたくさんのモデルやデータセットを使って、それを他のモデルでフィルタリングしてるんや。事前学習されたモデルがたくさん使われてて、データセット作りの一部か、蒸留損失の提供か、何らかの形でモデル作りに直接使われてるんや。
全てのAIが本当に、全てが相互接続された巨大な塊になってるんやな。ある時点で誰かがこれと全く同じことをするはずやからな。誰かがMoshiを何らかの方法で使い始めて、グラデーションを押し込むためのものを作るんや。だから、全てのモデルが基本的にお互いの出力を餌にし合ってて、そうやって未来に進んでいくんや。全てが何らかの形で相互接続されていくんや。
ある意味で、Whisperがこれに使われてるんやな。そして、ある意味で、これが将来のWhisperのバージョンに使われることになるんや。
タイムスタンプに合わせるためにパッドできるんか？テキストを音声の前に生成して、イントネーションをつけられるんか？うん、イントネーションは音響トークンの一部やな。彼らは音響トークンとセマンティックトークンに分けてるんや。
セマンティックトークンは実際の知識や、単語の実際の内容になるんや。例えば、「hello」って単語やな。これには何らかの関連があって、挨拶であり、言うものであり、ブラブラブラ...みたいな。それが実際のセマンティックトークンや。
そして音響トークンは、実際にその単語をどう言うかってことや。彼らはそれらを少し分離してるけど、これら全てを生成してるモデルは、列ごとに列ごとに、これら全てのストリームにアクセスできるんや。
それについては後で見ていくけど、これが深度トランスフォーマーや。彼らが階層的トランスフォーマーと呼んでるものやな。
ほな、読んでたところに戻ろか。これを読んでたんやな。よし、LaMA Omniの論文に戻ったわ。彼らには音声エンコーダがあるんや。ユーザーから入ってくる音声をエンコードしてるんや。
だから、ユーザーからXSって音声が入ってきて、それがエンコードされるんや。そして今、Hって音声トークンの列ができるんや。これらの音声トークンHは、多すぎるからまず下サンプリングする必要があるんや。それが彼らがここでやってることや。順番に連結して下サンプリングしてるんや。
それから音声アダプタを取るんや。この音声アダプタ、このデザインは実は視覚言語モデルにめっちゃ似てるんや。多くの視覚言語モデルは、基本的に事前学習された画像エンコーダがあって、それを事前学習された言語モデルにくっつける必要があるんや。
そのくっつけ方として、このアダプタやプロジェクターを作るんや。これにはいろんな名前があるけど、本当はただのReLU活性化を持つ2層のパーセプトロンなんや。だから、事前学習されたWhisper V.3から下サンプリングされた音声トークンを消費する線形層があって、それからReLU非線形性があって、それからもう一つの線形層があるんや。
だからこれは、視覚言語モデルとほぼ同じやな。Lavaみたいなオープンソースの視覚言語モデルと非常に似たデザインやな。それに、似たような2段階の訓練プロセスもあるんや。
ステージ1では、凍結された音声エンコーダがあるんや。これがWhisperやな。凍結されてるってことは、グラデーションを押し込んでへんってことや。それから言語モデルがあって、これがLLaMA Instructで、LLaMA Eight Bと音声アダプタやな。これらは基本的にゼロから初期化する必要があるんや。
だから訓練の最初の部分、ステージ1の訓練は、音声アダプタと大規模言語モデルがお互いを理解するようにするだけやな。この大規模言語モデル、このLLaMA 3.1、eight B instructは、これらのSトークン、音声表現トークンが何なのかまったくわかってへんのや。今まで見たことがないからな。
だからグラデーションを受け取って、これらのトークンが何なのかを理解する必要があるんや。だからステージ1では、本当にLLMと音声エンコーダをくっつけてるだけなんや。
そしてステージ2では、それらを凍結するんや。ここで見えるように、言語モデルを凍結して、音声アダプタを凍結してるんや。もうそれらにグラデーションを押し込んでへんのや。本当に、この出力を良くするためだけにやってるんや。
音声デコーダが、音声エンコーダから出てくるトークンを理解するんじゃなくて、このLLMから出てくるトークンを理解するようにグラデーションを押し込んでるんや。通常、このデコーダは訓練中、この場合はWhisperやけど、これらのトークンを取って書かれた形に変換する方法を知ってるんや。
でも、それを修正する必要があるんや。今はこのLLMから出てくるトークンを理解できるように、グラデーションを押し込む必要があるんや。音声エンコーダから普通に出てくるトークンとは少し違うからな。
LLaMA 3.1、8Bが LLMやな。これは基本的に標準的な言語モデルの話で、自己回帰的に生成してるんや。つまり、前のトークンを全部見て、一度に1トークンずつ生成してるんや。クロスエントロピー損失を使って訓練してるんやけど、これは基本的に全ての可能なトークンの語彙や辞書があって、こういう感じやって言うてるんや。
これらの全てを見て、次に生成するトークンとして各トークンの確率はこれくらいやって。そして普通は、一番確率の高いものを選ぶんやけど、もしかしたら何か面白い温度設定とかをして、もうちょっとランダムにトークンを選ぶかもしれへんな。
Web LLMって何？Web LLMってかなり一般的な名前やな。多分いくつかのプロジェクトがWeb LLMって名前やと思うわ。
他のオープンソースモデルを教師モデルとして使って、グラデーションをクロスチェックしたり調整したりし続けると、かなりの進歩が見込めると思う？それってループみたいなもん？
うん、100%そうやな。Sidさん、これが俺が言おうとしてたことなんや。私らは、AIが自分自身を改善してるっていうSFの映画の一部を実際に生きてるんやな。これがまさにそれがどんなふうに見えるかってことなんや。
AIが自分自身を改善するっていうのは、でっかい一般的なRehoboamみたいなAIが座って、自分でPyTorch コードを書いてるってわけやないんや。AIが自分自身を改善するのが実際にどう見えるかっていうのは、むしろこの論文たちみたいなもんなんや。
ねえ、この論文をどうやって作ったか？事前学習された言語モデルを取って、それを事前学習された音声エンコーダを使って訓練したんや。それから、ウィキペディアの記事を取って、それを別の事前学習された音声エンコーダを使って音声に変換して、データセットを作ったんや。
だから、他のたくさんのモデルを使って、データセットを作るか、蒸留損失を提供するか、何らかの形でモデルを作ってるんや。そして、そのモデルは今のところ最高のものになるんやな。この2つが多分、オープンソースの音声対音声モデルの最先端やと思うわ。
これらは将来、別のグループによって使われて、何かデータセットを生成したり、何らかの蒸留損失を提供したりするんやな。だから、それがAIが改善する方法なんや。AIがね。Audio SRがなかったら、これはできへんかったんや。WhisperLarge V3がなかったら、これはできへんかったんや。
だから全てが相互接続された混沌になってきてるんや。全てのAIは本当に同じAIなんや。他のAIの出力から餌を食べて、そしてそれが続いていくからな。
もっと上手く説明する方法があればいいんやけど、ちょっと曖昧な概念を説明するのは難しいな。
質問やで、They call me Kenさんから。これらのモデルの何かがCMU発音データベースを使えるか知ってる？
まあ、CMU発音データベースについてあんまり詳しくないんやけど、他のデータセットを使う機会はきっとあると思うわ。
この音声入力は、テキスト入力とは違う特徴があるんや。だから、テキストデータセットを音声データセットに変換するには、「ねえ」とか「そうだね」みたいな適切なフィラー語を追加して、指示の中の非テキスト記号をそれに対応する話し言葉に変換せなあかんのや。
既存のテキスト指示からの応答は、音声指示の応答として直接使うのに適してへんのや。テキストベースの対話モデルは、複雑な文を使って長い応答を生成する傾向があるからな。これらは、話すモデルとして知られてるものの一部やな。
彼らがここでやってるのは、指示と応答を得た後、それらを音声に変換するために、TTSモデル、具体的にはCozy Voice 300 msftを使ってるんや。Alpacaデータセットからの5万の指示みたいな指示チューニングデータセットを取ってるんや。
Alpacaデータセットは指示チューニングのデータセットで、基本的にこんな感じや。Ultra Chatみたいに、ここに質問があって、ここに応答があって、また質問があって、また応答があるんや。
そのテキストデータセットを取って、フィラー語を追加したり、書き言葉じゃなくて話し言葉の英語にしたりして、それを事前学習されたCozmo Voice 300 msftを使って音声データセットに変換してるんや。ランダムに男性か女性を選んでな。
だから、これらの音声モデルは基本的に、音声データに変換されたテキストデータで訓練されてるんや。これは面白いことやと思うわ。ビジョンでもこれができるんかなって思うんや。
例えば、ウィキペディアの説明を取って、それを画像生成器に入れて、画像に変換するとしたらどうやろ。それから画像生成器を訓練して、それから画像生成器を訓練して、それからその画像で画像モデルを訓練するとしたらな。
これが音声で上手くいくのは、合成的に作られた音声の品質が実際の音声にかなり近いからやと思うわ。今のところ、合成的に生成された動画の品質は実際の動画とはちょっと違うんや。だからビデオや画像生成にはもうちょっとシムトゥリアルのギャップがあるんやけど、音声にはほとんどっていうかほぼシムトゥリアルのギャップがないと思うわ。
だからこの二つの論文は、効果的に合成的な対話データセットを作って、それがかなりうまくいってるんやな。
Moshiに独自の一貫した声を与えるために、2万時間の合成音声データを使ってるんや。それに、70以上の話し方のスタイルをカバーするモノローグを録音した単一の俳優の声でTTSに条件付けもしてるんや。
かなり複雑やな。この「指示チューニング」データセットを取って、それを音声データセットに変換してるんや。それだけじゃなくて、そのデータセットを生成するのに使うTTSを、70の話し方のスタイルで話す特定の人の声で微調整してるんや。その人にお金を払って録音してもらったんやな。
そうすると、そのTTSは今、この一人の人（多分女性やな、これは女性の音声やから）の声に聞こえる音声を生成するんや。
ちょっと話が逸れてもうたな。この論文の微調整の話をしてたんや。LLMと音声デコーダを見てたんやった。音声応答...ブラブラブラ。
事前学習されたHUBERTを使って音声の連続表現を抽出して、それらの表現をK-Meansモデルを使って離散的なクラスタインデックスに変換してるんや。つまり、少なくともこのLLaMA Omniでは、デコーダが基本的にこう言ってるんや。「はい、ここにオーディオかテキストがあります。それをオーディオに変換します」って。
これはMoziでやってることよりも少しシンプルなデザインやな。Moziでは、セマンティックとこれらのトークンが全部もうちょっと密接に混ざり合ってるんや。それによって、それらの間でもっと情報が流れるようになってるんやけど、これみたいなものは、もうちょっと分離されてるから、デコーダの品質にもっと頼ってるんやないかな。
だからこそ、ここにグラデーションを押し込まなあかんのやと思うわ。そうやないかもしれんけど、そう思うんや。まあ、わからんけどな。
音声デコーダ、最終デコーダがあって、それから音声デコーダの離散ユニットシーケンス、yu...ブラブラブラ。Kはクラスタの数で、lは離散ユニットシーケンスの長さやな。
クラスタの数っていうのは、基本的にここから出てくるものの数が限られてるってことや。トークンみたいに考えられるな。実際には、どのkクラスタを使うかを決めなあかんのや。
これはほとんどコードブックや辞書みたいなもんで、ここに入る可能性のある離散的な集合があるんや。この場合、それぞれの可能性のあるものはこれらのクラスタの中心みたいなもんで、それからどれを選ぶかを決めるんや。
各yiを出力する時、uiは1からlまでの長さやから、シーケンスの長さはlやな。そして、これらのy'sそれぞれに対して、0からkまでの可能な値の一つになるんや。
離散ユニットは、追加のユニットベースのボコーダーで波形に変換できるんや。ここでまた、この正確に同じものに戻ってくるんや。離散的なシーケンスがあって、それぞれの要素がk個の可能な値の一つやな。
そして、このデコーダは基本的にこう言ってるんや。「よし、そのものの流れを取って、実際の波形に変換するぞ」って。それが実際に俺のコンピューターが出力するものなんや。つまり、スピーカーの小さな膜を振動させて、音の圧力波を生成して、それがコンピューターから出て行って、耳で聞こえるようになるんやな。
音声応答を同時に生成するために、ストリーミング音声デコーダDを追加したんや。これは単にいくつかのトランスフォーマー層やな。音声デコーダは非自己回帰的な方法で動作して、LLMAからの最後の出力か出力隠れ状態を入力として取り、音声応答に対応する離散ユニットシーケンスを生成するんや。
これは重要やな。なぜかっていうと、これはLLaMA Omniができることを根本的に制限することになるからや。ここでは音響トークンを生成してるから、実際に生成されてる音声は会話の全てに注意を払う能力があるんや。
例えば、あなたが怒って話してて、怒って話すように言ってたとしたら、そのコンテキストを持ってて、あなたが怒って話してたという事実に注意を払えるんや。だから次の音声トークンを生成する時、「これらは怒った音声トークンにするべきだ」って言えるんや。
でも、こっちは自己回帰的じゃないんや。基本的に、チャンクを取って、そのチャンクを一つずつ音声に変換してるだけなんや。全体のコンテキストに注意を払えないってことは、この音声システムの能力を制限することになると思うわ。
出力...隠れ状態...アップサンプリング...これらの論文には多くのアップサンプリングとダウンサンプリングがあるな。音声は単位時間当たりのサンプルが多すぎるからや。本当に、これらのLLMやトランスフォーマーが扱えるように、より小さなシーケンスに縮小する必要があるんや。
ブラブラブラ...隠れ状態。これが実際に音声出力を得る方法やな。
崩壊関数を適用して、ボコーダーに送り込んで波形を合成するんやけど、実際には基本的に最良のものを選んでるだけやな。最良のアラインメントを選択するんや。つまり、ここから出てくるものは、このk個の可能な値を行って、それからそれらの中から最良のものを選んでるんや。
そして、ボコーダーは単に「はい、ここにトークンがあります。これがそのトークンに関連付けられた音です」って言うだけやな。はい、続けさせていただきます。
そやな、それを終わらせたんやったな。データセットの話に入ったところやった。じゃあ、こっちに戻って、このMoshiの詳細を見ていこか。
ええっと、この論文めっちゃ長いな。いろんなことがあって、たくさんの詳細があるわ。オープンソースコミュニティにはほんまに感謝せなあかんな。全部の詳細を公開してくれてるんやから。
さて、LLaMA Omniを見てたんやったな。これは波形...エンコーダとデコーダがあって、それから事前学習された大規模言語モデルを使ってこのアダプタを訓練せなあかんのやな。視覚言語モデルにめっちゃ似てるわ。
ほんで、Moshiに戻ったんやな。Whisperのエンコーダデコーダモデルを使う代わりに、自分たちで作ってるんや。MIMIっていうやつやな。MIMIっていうのは、ミニのことかな？それとも、ミミ？わからんわ。
ニューラル音声コーデックで、残差ベクトル量子化と知識蒸留を使って、意味情報と音響情報を単一のトークナイザーに組み合わせてるんや。ここでの蒸留は、この他のモデル、WAV LMから来てるんや。
深度トランスフォーマーは、ストリーミング推論と互換性があるんや。実はこの深度トランスフォーマーは、ここから来てるんや。RQトランスフォーマーって呼ばれてて、Lucid Rainっていう人のものやな。この人、ちょっとTwitterで有名人やねんな。
RQトランスフォーマーは、多次元シーケンスを自己回帰的に訓練するより効率的な方法を提案してるんや。基本的に、これは複数のシーケンスを同時に扱えるトランスフォーマーやねん。
LLMみたいに一つのシーケンスを生成して、それを自己回帰的に消費するんじゃなくて、これは複数のシーケンスを扱うんや。なぜかっていうと、音響トークン、音声トークン、意味トークン、そしてテキストトークンか内部モノローグトークンを分離するからや。これら全てを同時に生成せなあかんのや。
新規性についてはもう話したな。それから音声言語モデリングの話もしたな。主要な構成要素はテキスト言語モデルのバックボーンやな。ここにあるやつや。ここに入るトークンがめっちゃ変やから、こんな特殊な方法で訓練せなあかんのやな。
それに、これもそうや。だから、このHeliumはちょっとアホやと思うわ。Moshi全体もちょっとアホになる可能性があるんちゃうかな。こんな変なモダリティを扱ってて、こんな特殊なアーキテクチャを使ってるから...わからんけど、わからんけど、わからんけど...
これがすぐに破滅的忘却問題を起こして、実際の知識を知るのをやめて、このオーディオのクソみたいなものを生成するのだけ上手くなるんやないかなって想像するわ。
彼らもそのことについて話してるな。訓練中に、基本的に...そうや、ここやな。破滅的な遅延忘却を防ぐために、テキストのみのデータのバッチで半分の時間を訓練してるんや。
問題は、このHeliumモデルを訓練する時、基本的にこの音声のものをバッチで押し込むと、ウィキペディアとか、そういう実際の知識情報を忘れ始めるんや。だから、効果的に切り替えて、時々テキストだけのデータを入れないといけないんや。そうせんと、モデルが元の訓練や事前訓練で受け取った元の情報を破滅的に忘れて、だんだんアホになってしまうんや。
Helium言語モデルのところにきたな。これの実際のソースは何やろ？トランスフォーマーアーキテクチャに基づいてる...フラッシュアテンション...センテンスピース...これは事前学習されてへんな。全部自分たちで訓練してるみたいやな。そうや、ゼロからやな。
Lucid RainはTwitterにおるんかな？おらへんわ。この人見たことあるような気がするんやけどな。
まあ、このリポジトリ見た時に「うわ、待てよ、俺すでにこの人フォローしてるやん」って思ったから、有名人って言ったんやな。
見てみ、この人すごいやろ。2011年からずっと頑張ってるわ。いつから頑張り始めたんやろ？あ、ここやな。2018年から始まってる。平日だけ働いてて、週末は働いてへんのがわかるな。
会社に入ると、違うGitHubを使うか、コミットしないこともあるから、GitHubのコミットグラフが必ずしも頑張り具合を示すわけやないんやけどな。
でも、2019年くらいから「もうええわ、週末も働くで」ってなったんやな。土曜日も日曜日も働いてるのがわかるやろ。そっから基本的にずっと働いてるわ。
ここで夏休みを取ってるな。ここは感謝祭の休みやな。ここはまた夏休み。あ、ここは3月の休みやな！
まあ、この人のGitHubを覗き見るのはこれくらいにしておこか...
Moshiの訓練は4つのフェーズを経るんや。教師なしデータでの事前訓練、シミュレートされたマルチストリームでの事後訓練、Fisherデータセットでの微調整、そして最後にカスタムデータセットでの指示微調整や。
事前訓練フェーズでは、半分の時間をテキストのみのバッチで訓練し続けるんや。それから、教師なしデータで少し訓練して...別の最適化状態を使ってるんや。破滅的忘却を防ぐために、ちょっと違うものからグラデーションを押し込んでるんやな。
音声トークン化について見ていこか。エンコーダは、単一チャンネルの波形Xを潜在表現encoded Xに射影するんや。これは、拡張畳み込みとストライド畳み込みを交互に配置した残差畳み込みブロックをカスケード接続して、ELUと一緒に使ってるんや。
つまり、ここにあるこの単一チャンネル波形X in R of Lは、基本的にこの信号、この波形が一つのチャンネルだけやってことやな。2チャンネルもあり得るんや。2チャンネルってのは左右の音声やけど、スピーチみたいなものには左右の音声はあんまり意味がないんや。
一つのチャンネルだけでも十分で、チャンネルの総数を減らせるし、ただ一つの数字で波の振幅を表せるんや。これが単一チャンネル波形xで、これをencoded潜在表現に変換するんや。これは今sとdやな。
何かdっていう次元があって、これらの小さなトークンのシーケンスがあるんや。sはシーケンスの長さで、dはそれがいくつあるかやな。だからdは幅みたいなもんやな。
それから、sは...ボトルネックに変換可能なモジュールを追加してる。量子化の直前に一つ、直後に一つ。全体で20秒のコンテキストやな。
ここで面白いポイントがあるな。後でMIMIは因果的で、エンコーディングとデコーディングの両方でストリーミング方式で使えるんや。全体のストライドは80ミリ秒に対応してるんや。
80ミリ秒の最初の音声フレームが与えられると、MIMIは最初の潜在時間ステップを出力して、それを80ミリ秒の出力にデコードできるんや。
だから、Moshi全体が、この80ミリ秒のフレームレートで動いてるんやな。各列、全てのものがこの80ミリ秒で動いてるんや。ここに入って、それを入力できるな。80ミリ秒はこんな感じや。
ボタンを押してから物が光るまでの時間が80ミリ秒なんや。データが表示されるまでの時間、これらの列それぞれがどれくらいかかるかってことやな。80ミリ秒、80ミリ秒、80ミリ秒、80ミリ秒って感じや。
実は、これが彼らの理論的な遅延の元になってるんや。後で言及してると思うんやけど、この一つにあると思うわ。どこやろ...遅延、遅延計算...
ここやな。1～2ステップの遅延を導入すると、生成の品質が大幅に向上するんや。意味トークンと音響トークンの間に少しの遅延があるんや。これが2ウィンドウ遅延やな。2回の80ミリ秒やから、ここで言ってる160ミリ秒になるんや。
だから、理論的な遅延が160ミリ秒やって言ってる時、基本的にこの全体が80ミリ秒のフレームレートで動いてて、入力と出力の間に2フレームの遅延を入れてるってことなんや。ちょっと余分なコンテキストを持てるようにな。
これらをもっと近づけることもできたんやけど、数フレーム待つと、余分なフレームが得られるんや。例えば、ここでこのトークンを生成せなあかんとしたら、これらのトークンが何かを知ることで得られたかもしれない情報を全部失うことになるんや。
だから、その2フレームの遅延を導入することで、より関連性のある情報が流れ込むのを許してるんや。そして、人間の知覚限界にもうめっちゃ近いからな。80ミリ秒と200ミリ秒の違いは、ユーザーがシステムと対話する体験に質的な違いをもたらすほど大きくないんや。
だから、そこまで小さいフレームレートなら、限界まで行って、次の音響トークンと意味トークンを生成するために可能な限り最大の情報を得られるようにしたほうがええんや。
うわ、みんなすごいな。なんでNotebook LMSのポッドキャスト機能は、同じようなアプローチを使ってへんのやろ？それとも、公開してへんだけなんかな？全部本物みたいに聞こえるし、かなりええんやけどな。
実は、それについて調べてみたんや。Notebook LM...これはSidからの質問やな。最近のGoogleのリリースやな。実際に自分で試せるんや。notebook.lm.googleって入力したら、そこに行けるで。何でも好きなもんをアップロードできるんや。俺はこの2つの論文を入れてみたんやけど、実質的に論文について質問したり、要約を頼んだりできるんや。
チャットを閉じて、こんな感じで両方の論文の要約を見たり、両方の論文についてのクイズと答えを見たりできるんや。でも、みんなが一番気に入ってるのは、ポッドキャストみたいな音声を作れる機能やな。面白いのは、これが本物のポッドキャストみたいな感じやってことや。2人が話し合ってるみたいな。
これはこういう種類のアーキテクチャを使ってへんわ。それは今すぐ言えるんや。なぜかっていうと、これらのアーキテクチャは基本的に遅延についてのもんやからな。ユーザーからの音声をすぐに消費して、できるだけ早く音声を生成することについてのもんなんや。つまり、会話的な体験を作るために遅延を減らすことに全力を注いでるんや。
でも、こいつらはそんなこと気にしてへんのや。これは全体を一度に作るんや。だから、俺の推測やけど、これはおそらく古典的なテキストから...おそらく言語モデルで、何かプロンプトがあって、こういう種類の会話、ポッドキャストっぽい会話を生成できるようになってるんやと思うわ。あるいは、ここで説明されてる小さな癖とか、えーと、フィラー語とかそういうのを全部含めて生成できるように微調整されてるんかもしれんな。
そして、そのテキストを全部取って、音声ファイルに変換してるだけやと思うわ。これはこれに似たもので生成されてるとは思えへんな。
これについての俺の意見？正直、これはあんまりええと思えへんわ。生成されるポッドキャストがちょっとクリンジーなんや。中身がないんや。2人が話してるだけで、言ってるトークンの90%くらいがほとんど中身のないおしゃべりなんや。
「わー、すごいね。そのことについて本当にどう思う？」みたいな感じやな。もし実際にそのポッドキャスト全体を書き起こしたら、会話的なおしゃべりの部分をハイライトしたら、ほぼ全体がおしゃべりになってしまうんちゃうかな。
少なくとも俺がポッドキャストを聴く時は、もっと情報が詰まってて、もっと詳細に踏み込んでるもんの方が好きやな。ただだらだらしゃべってるだけのポッドキャストよりも、もっと中身の濃いもんがええんや。でも、これはまさにそんな感じなんや。ただだらだらしゃべってるだけの雰囲気やな。
論文についてのポッドキャストが欲しいんやったら、もうちょっと詳細なもんがええと思うんやけどな。まあ、これがNotebook LMや。これが俺の5分間レビューやな。
「ほとんどのポッドキャストってそんなもんやろ」って？そうやな。自覚せなあかんけど、俺のYouTubeチャンネルも基本的にそんな感じやな。正直に言うと、これら2つの論文についての俺の要約を聞くのも、結局同じことちゃうんか？
基本的に俺も同じことをしてるんや。この非常に詳細で技術的な論文を取って、それについて2時間の音声を作ってるけど、それはより詳細じゃなくて、より技術的じゃないんや。なぜかって、もっと口語的な言葉を使ってるからな。
だから、これがどこに向かうんか気になるな。今や、テキストから音声を非常に簡単に生成できるようになったからな。歴史的に、話し言葉の英語と書き言葉の英語の間には一種の分離があったんや。でも、その分離の一部は、話し言葉の英語を作るために人を通さなあかんかったからなんや。
でも今や、AIが生成した音声を99%聴いてる世界に入ろうとしてるとしたら、それは話し言葉の英語である必要はないんちゃうか？今や、消費するコンテンツの全てが、非常に技術的な書き言葉の英語で、それが単に話し言葉の英語に変換されたものっていうコンテンツバブルの中で生きることができるんや。
だから、英語言語がある意味で二極化するんちゃうかなって思うんや。カジュアルな会話的な話し言葉の英語と、もっと技術的なバージョンの話し言葉の英語があって、後者は情報を最大限に伝えようとするために使われるみたいな。ちょっと高度な話になってもうたかもしれんな。
ほとんどのポッドキャスト...そうやな。昨日のLLaMA 3.2のデモ見た？うん、LLaMAのデモは見たで。かなりええ感じやった。LLaMAのストリームをしようかと思ったんやけど、あんまり内容がなかったんや。
この2つの論文を深く掘り下げて、音声対音声モデルが実際に何をしてるのかをもっとよく理解するほうが、今のところもっといい時間の使い方やと思ってん。でも、実は今しゃべりながら、LLaMA 1.1Bビジョンモデルの微調整をしてるんやで。
1Bと3Bは美味しそうやな。携帯電話で動くようなやつは、確かにめっちゃワクワクするな。
さて、ここに戻ろか。エンコーダがあって、基本的にWAV LMから蒸留されてるんや。このトランスフォーマーがあって、MIMIは因果的やな。それについては見たな。基本的に80ミリ秒のフレームレートやな。
トランスフォーマーのコンテキストは10秒に制限されてるんやけど、これでもまだちょっと短いように思えるな。音声体験のためのコンテキストウィンドウにまだ制限があるんやな。
Q=8の量子化器を使ってて、コードブックサイズはNa 2048やな。基本的に、Qはここで損失のある圧縮をする時に使う解像度やディテールのレベルみたいなもんやな。
ものを取ってエンコードして、それからものを取ってデコードする時、Qが高いほど、基本的には前のものの残差を量子化する層が多くなるんや。Qが高いほど、これはあまり損失が大きくならんけど、ある時点で、ただ扱うものが多くなるだけで代償を払うことになるんや。
だから、Q=8を選んでるんやな。これは基本的に、この...の数がどれくらいかってことや。ここでは3つ見えるけど、実際には8つ使ってるんや。
英語の音声を生成するには、1秒の音声につき100ステップで、1秒あたり3〜4のテキストトークンで表現できるんや。
彼らは複数のサブシーケンス、V S Kを持ってるんや。これがRQトランスフォーマーやな。これが必要な理由は、基本的にこの全体の列のクソを消費せなあかんからや。複数のシーケンスがあって、RQトランスフォーマーは同時に複数のシーケンスを消費して生成できるんや。
これらのサブシーケンス、それぞれがそれらのものやな。実際に、ここに具体的な詳細があるな。具体的にはこんなシーケンスや。最初のは単なるテキストや。2番目は意味トークン。それからQ個の遅延音響トークンがある。それから他の意味トークンがあって、これは話者やな。それから他の遅延音響トークンがあって、これも話者やな。
基本的に、テキストトークン（これは内部モノローグ）、それからMoshiの意味トークンと音響トークン、そして人間の意味トークンと音響トークンがあるんや。
実は、ここで面白いことを言ってるな。ユーザーが話してMoshiが黙ってる時、実際のところ...この両方を見ていこか。実際の応用では、ユーザーから来る音声の予測は無視されるんや。代わりに実際のユーザーの音声が使われるからな。
でも、ユーザーのストリームを出力としてモデル化することで、模擬対話を生成できるんや。つまり、ここで言ってるのは、2つのMoshiの間の会話を生成したい時、基本的にこれらの紫のトークンと、ここ下のMoshiトークンも作る必要があるってことや。
だから、ここのR-VQトランスフォーマーかR-Qトランスフォーマーは、実際にこれらの紫のトークンを予測してるんや。つまり、あなたが話してる時、80ミリ秒のフレームごとに、あなたが次に言いそうなことをある意味予測してるんや。
これはめっちゃクールに聞けるんちゃうかな。このモデルと会話して、突然ブロックして、これが出力されるようにしたら、あなたが話してる会話をほぼ生成できるんやな。でも、実際にこのモデルを推論モードで動かして話してる時は、基本的にその部分をカットしてるんや。
それを生成してるけど、ある意味であなたが次に言いそうなことを予測してるんやけど、その部分は基本的にどこにも出力されへんのや。
ユーザーが話してMoshiが黙ってる時、Moshiのストリームの対応する音声トークンは自然な沈黙、ほぼ無音の波形にデコードされるんや。それがほぼ無音ってのが、なんかちょっと気味悪い感じがするな。完全に無音じゃないんや。
ここの灰色のトークン、これらは沈黙のトークンや。まだトークンを出力してるんやけど、それらは沈黙のトークンなんや。これはちょっとクールやな。あなたが話してる時、それが話すのをやめたわけやないんや。ただ今は沈黙で話してるだけなんや。
「なんでロボット工学でそれをせーへんのやろ？」って思ってん。この変なパラダイムにすぐに惚れ込んでしもうてん。ちょっと待ってな、どこかに書いたんやけど...ここや、ここやで。
今のロボット工学は、ほぼここの状態やな。ASR、TTS、そしてLLMがあるんや。ロボットシステムでもまだこのモジュール設計が見られるんや。一つのアクショントークンのストリームを生成したり、なんかを消費したりしてるんやけど...
でも、このマルチストリーム、このマルチストリーム設計はロボット工学にもめっちゃ合うと思うんや。例えば、こんなストリーミングトランスフォーマーがあって、ユーザーからの音声トークンを消費してるとしよう。それと同時に、全ての異なるカメラセンサーからの視覚トークンも消費してて、視覚トークンも出力してる。そして、アクショントークンも出力してるんや。
そして、そのアクショントークンが時々、ここでの沈黙に対応するのと同じように、動きなしに対応することもあるんや。つまり、ロボットは常に80ミリ秒ごとに動いてるんやけど、その動きコマンドが「じっとしてろ」コマンドになることもあるんや。
ロボット工学の人じゃない人にはあんまり面白くないかもしれんけど、俺はこのデザインめっちゃ好きやわ。多分、誰かがこのマルチストリーム設計を取って、ロボット工学のケースで使うのは6ヶ月くらい先やと思うんや。
これはロボット工学にもぴったりやと思うんや。だって、複数の入力ストリームがあるやろ？カメラからの入力があって、力センサーがあって、自己受容感覚情報があって、ユーザーからの音声があって、これは別のところから来てて、そんなに多くの異なる入力ストリームがあるんや。そして、複数の出力ストリームも欲しいんや。
だから、この設計は音声だけじゃなくて、他のケースにも使えると思うんやな。
ここにセンテンスピーストークナイザーがあるで。前に言うたように、センテンスピーストークナイザーは音声用に設計されてへんのや。「I'm」って単語が3つのトークンで、「hello」って単語が1つのトークンってのは、ある意味自分の足を撃ってるようなもんやな。
なぜかっていうと、これらの列の一つ一つが80ミリ秒やからや。テキストトークンとセンテンスピースの間の離散化関係と、時間の各トークンの間に不一致があるんや。ここではすべてを揃えたいんやけどな。
だから、特別なパッドトークンを導入せなあかんのや。言葉が非常に速く言えるけどトークンが多くない場合、これらのパッドトークンを追加できるんや。
ほな、上に戻ろか。このRQトランスフォーマーについてもうちょっと見ていこ。RQトランスフォーマーは2つのトランスフォーマーモデルで構成されてるんや。本当に2つのものがあるんや。
時間的トランスフォーマーがあって、これはVS1、VS2を取ってる...S1、S1、S1って見えるやろ。これら全部S1やな。つまり、全部同じってことや。A1、A2、A3って見えるやろ。s1は全部これの1、1、1ってことや。それから1、2、3、4がここにあるやろ。
2番目のインデックスは基本的にここの1、2、3、4に対応してるんや。2番目のインデックスは深さか高さみたいなもんやな。各別々のストリームやな。そして最初のインデックスは時間次元に沿ったものや。
この最初のは、これら全てを一緒に取ってるんや。これら全てがこの小さな矢印で連結されて、このプラスに入ってるのが見えるやろ。基本的に、これら全てを連結してるってことや。
そして深度トランスフォーマーは基本的にその反対やな。今度は複数のシーケンスを消費してるんや。本当に、これをする理由は、これら全てが互いに影響し合えるようにするためなんや。
この理由は、ここのこのトークン、このa prime 10/2が、効果的にここのこのクソ全部に注意を払えるようにするためなんや。このA1、2に注意を払えるし、この黄色いA5、8にも注意を払えるんや。これらはトランスフォーマーやから、注意を払う能力があるんや。
その情報がここに入る方法があって、それから次に出力するトークンの確率分布を変更できるようにするんや。これが最終的に上手くやる必要があることなんや。出力してる各小さなトークンの確率を予測するのがめっちゃ上手くなる必要があるんや。
だから、v0からvs1まで全部取って、この時間的トランスフォーマーに入れるんや。そうすると、この時間的コンテキストベクトルzsが生成されるんや。そして、その時間的コンテキストベクトルzsには全ての時間的コンテキストが含まれてるんや。
つまり、前に何が言われたかとか、怒ってたとか、ブラブラブラ...全部が何かの変な小さなベクトルに圧縮されてるんや。我々が完全には理解してへんような何かd次元のベクトルにその情報が含まれてるんや。
そして、深度トランスフォーマーはその時間的コンテキストベクトルと、vs1からvs k-1までの全てを受け取って、ロジット推定を生成するんや。そして、そのロジット推定を使って、どのトークンを出力するかを選ぶんや。
深度トランスフォーマーは6層あるんや。これらはあんまり巨大じゃなくて、小さなトランスフォーマーやな。遅延を導入することについては既に話したな。2ステップの遅延を80ミリ秒のフレームレートで導入するのが、実質的に100ミリ秒の理論的遅延を得る方法やな。
重複する発話順番を扱えるんや。それはええな。2つの音声ストリームがMoshiに対応してて、a primeはユーザーをモデル化してるんや。これは彼らが言ってたことで、実際にはユーザーの出力を予測できるんや。
これが役立つのは、これを訓練する時やな。基本的に会話を生成して、それをデータセットの会話と比較できるんや。そうやってグラデーントを得てるんや。人々が前後に話してるデータセットから損失を得てるんやけど、それらは実際のデータセットじゃないんや。
基本的に偽のデータセットで、テキストのデータセットを他の4つの事前学習済みモデルを使って合成的に生成して、音声データセットに変換したものなんや。ユーザーの音声ストリームと自分の音声ストリームの両方を出力できるから、全部にグラデーントを押し込めるんや。
でも実際には、そこのトークンは生成してへんのや。言語モデルで自己回帰的にトークンを生成する時と同じようなもんやな。実際の訓練では、偽のユーザーを出力できるけど、実際に推論をする時は、モデルはあなたが入力するのを待つんや。だからあなたがこれらの紫のトークンを選んで、それからモデルがそれらを選ぶんや。
ガウス散布やゲームでも同じことが起こり得る？100%そうやな。それが俺が言ってることやで。そう思わへん？そんな感じがするやろ？ロボット工学の状況を想像してみ。先週の論文でも。先週、ガウス散布の論文をいくつか見てたの覚えてる？
特に、これらのチャンクでガウス散布をストリーミングしてる論文があったやろ。それがこれらのストリームの1つになるのを想像できるやろ？ロボット工学の状況では、これらのマルチストリームの1つが文字通りチャンク化されたガウス散布になり得るんや。それは世界を表現してるんや。
だから、小さなグリッパーで何をするかっていうアクショントークンを出力するだけじゃなくて、「これが世界やと思う」っていうのも出力してるんや。そして、効果的に俺が住んでる変化する世界の状態を表現するガウス散布もあるんや。そうやろ？
今、このマルチストリームを見た時に、「うわ、これはAGIの感じがする」って思ったんや。誰かがこれをロボット工学に応用せなあかんな。
ほな、Whisperを使ってタイムスタンプを得る話に戻ろか。2つの特別なトークンを定義してるんや。<padと</padやな。これらは決して単語トークンには現れへんのや。</padは次の単語の前に挿入されて、パディングの終わりを示すんや。
つまり、hello <pad>、<pad> token、token、MOshi、M Oshi、pad pad pad、そしてどこかで</padがあるんや。
推論...よし、これで実際の設計についてはほぼ終わりやな。両方の設計について見てきたけど、今は基本的に両方の論文のデータセットのセクションにいるんや。じゃあ、これらのデータセットを実際に見ていこか。
明らかに、こいつらは基本的にこれらの指示チューニングデータセットを使ってて、Cozy Voice 300 MSFTを使ってそれらを音声データセットに変換してるんや。こいつらはこいつらほどたくさんのことをする必要がないんや。なぜかって、こいつらはもっとええ出発点を使ってるからや。
WhisperのエンコーダとデコーダをLLMとして使ってて、LLaMA 3.1を使ってるんや。だからLLaMA Omniは視覚言語モデルにちょっと似てるんや。めっちゃ大きなデータセットは必要ないし、そこにたくさんのグラデーントを押し込む必要もないんや。なぜかって、LLMにはすでにたくさんの知能があるからや。
音声エンコーダと音声デコーダ、それらはすでにかなりええんや。WhisperV3がかなりええからな。WhisperV3は100万時間の弱くラベル付けされた音声と、WhisperLarge V2を使って収集した400万時間の擬似ラベル付けされた音声で訓練されてるんや。
ここにも同じパターンがあるな。前の世代のAIを使って次の世代のAIのデータセットを生成してるんや。でも、それらがすでにかなり強いから、そんなに複雑なデータセットは必要ないんや。だからこいつらは20万の合成音声指示データセットで済ませられるんや。
ここで面白いと思ったのは、論文のこの部分で「pre-trained」の綴りが2つ違う方法で書かれてるんや。ダッシュありの「pre-trained」とダッシュなしの「pretrained」があるんや。俺はダッシュありの方を使ってるような気がするけど、人によってはこっちの方が好きなんかもしれんな。
同じ概念の違う綴りが、1ミリメートルくらいの範囲内で使われてるのがちょっと分裂症的やと思ってん。めっちゃクレイジーやな。
5倍のダウンサンプリングがあって、それから4台のNVIDIA L40sで訓練されてるんや。これはあんまり見ないやつやな。普通はH100sかA100sを見るし、それからA100sを見る。小さな研究や学術論文やったら、3090か4090を見るかもしれんけど、L40はちょっと変わってるな。
これがL40や。2022年にリリースされたんや。
4ギガバイト...48ギガバイト
これ、見たことないかもしれんな。それから基本的に、ChatGPTを使ってスコアを出してるんや。これはちょっとおもろいな。AIを使って自分のAIがええかどうかを判断させるのが標準になってきてるんや。
GPT-40がコンテンツとスタイルをスコア付けしてるんや。指示に従うベンチマークみたいな状況があって、偽の会話を生成して、出力を作って、それから「よし、GPT-40、これはええ出力か？コンテンツはどれくらいええ？スタイルはどれくらいええ？」って聞いてるんや。
ここで基本的に最先端やって示してるんやけど、実際にはこれと比較してへんのやな。これは、ほぼ同時に発表された2つの論文がある時によく起こる問題やな。
両方が最先端を主張できるけど、どっちも最先端を主張できへんのは、お互いを比較してへんからや。一方が他方のものにアクセスできたわけやないんや。ここのやつらが論文を発表した時、多分LLaMA Omniをベンチマークで走らせてへんかったんや。論文が既に完成してから出てきたからな。
だから、常に最先端を主張する論文がたくさん同時に発表されて、6ヶ月前に発表された論文とだけ比較してるんや。だから、永続的な状態みたいなもんで、多くの人が最先端を主張できるんや。なぜかって、比較すべきものが実際に論文を発表するまで出てこなかったって無知を主張できるからや。
他のスコアもあるな。平均意見スコアとか、他のランダムなクソみたいな定量的なものとか。これはちょっと遅延が大きくて226やけど、かなりええと思うで。226の遅延はまあまあいけるやろ。誰かのおばあちゃんと話すよりも遅延が少ないかもしれんな。
実は、俺がめっちゃ楽しみにしてることがあるんや。ポッドキャストを聴く時、徐々にスピードを上げていって、今はほとんど2倍速でしか聴いてへんのや。それでめっちゃたくさんのコンテンツを消費できるんやけど、音声アシスタントでもっと高速なオプションが出てくるんかなって思うんや。
1倍速で返事をされるのがほぼ耐えられへんくらい遅く感じるから、2倍速か3倍速で話してくれる音声アシスタントと対話したいんや。そして、脳にニューラルリンクが入るようになったら、もっと高速にな。脳への入力ビットレートをどんどん上げていって...
人間が筋トレをして不合理なほど強くなれるのと同じように、将来の人間は、一瞬で受け取れる情報量を少しずつ増やしていくみたいなことをするんちゃうかな。多分、それが知能の指標になるんやないかな。
テストで点数を取ったり正解を知ってるかどうかで知能を測るんじゃなくて、脳が処理できなくなる前に1秒間に何単語消費できるかみたいなのが知能の指標になるかもしれんな。
ほな、このデータセットを見てたところに戻ろか。今度はMoshiのデータセットを見ていこ。これはもっと複雑なんや。めっちゃクレイジーやで。
Wikipedia、WikiBooks、WikiSource、WikiNews、Stack Exchangeがあって、ここに10の異なるクロールがあるんや。クロールっていうのは、基本的に誰かがロボットを使ってWikipediaを全部スクレイピングしたってことやな。でもWikipediaは変化するから、2018年にスクレイピングしたのと2023年にスクレイピングしたのは違うんや。
だから、実際にこれら全ての異なるソースの多くの異なるクロールを使ってるんや。700万時間の音声コレクションを使って、Whisperで書き起こしてるんや。Whisperがまた出てきたな。この700万時間を取ってテキストに変換してるんや。
全ての音声を24キロヘルツにリサンプリングして、モノラルにダウンミックスしてるんや。ここで見えるように、音声自体は24キロヘルツで入ってきてるんや。これを見れるチャートがあったと思うんやけど...ここやな。違うな。まあええわ、見つからへんわ。
でも、24キロヘルツから12ヘルツに落としてるんや。これが80ミリ秒やな。実際、最初のやつにこれがあると思うわ。ほら、ここやで。24キロヘルツ、これは1秒間に24,000サンプルやな。これが音声波形で得られるものや。これでもそんなに高くないんや。44キロヘルツってのもあって、それが高品質音声や。24キロヘルツはある意味では低品質音声と考えられてるんや。
だから、24キロヘルツを取って、それを12.5ヘルツに変換してるんや。つまり、1秒間に24,000サンプルから12.5サンプルになってるんや。そして12.5サンプル毎秒は正確に80ミリ秒に対応してるんや。全ての数学が合ってるな。80ミリ秒はだいたい12ヘルツやな。
ほな、データセットに戻ろか。Fisherデータセットがあって、これは2004年に集められた2,000時間の電話会話やな。ランダムにペアにされた参加者が、議論するトピックを与えられてるんや。これはちょっと面白いな。2004年に誰かが2,000時間の偽の電話会話のデータセットを集めてたんや。
2004年っていうのは、人々が「スケールこそすべて」みたいな考え方をする前やねんな。「苦い教訓」とか「スケールがすべて」みたいな考え方は最近のもんやからな。だから、2004年に2,000時間の電話データセットを集めるっていう先見の明があったのはめっちゃクレイジーやな。
各会話は別々のチャンネルで録音されてて、これによって真の分離されたストリームを提供できるんや。これが大きなポイントやな。多分、このデータセットがそんなに重要な理由やと思うわ。紫と青が分離されてるからな。
このデータセットが単一のマイクで録音されてたら、誰がいつ話してるかを分離せなあかんかったはずや。誰がいつ話してるかを分離せなあかんかったら、このマルチストリーム生成ができへんかったんや。なぜかって、Moshiはあなたが話してる時に同時に話してるけど、ただ沈黙のトークンを話してるだけやからな。
だから、これが2つのチャンネルに分離されてるっていうのは、彼らのマルチストリームパイプライン全体にとってめっちゃ重要なんや。だからちょっとラッキーやったんやな、このFisherデータセットで。
Audio SRを使って24キロヘルツにアップサンプリングしてるんや。このFisherデータセットを取ってるんやけど、これは8キロヘルツでサンプリングされてるんや。2004年のボロいMicrosoft XPのデータセットやからな。かなりボロい昔の解像度やな。
だからAudio SR、多分音声超解像度の略やと思うけど、これを使ってアップサンプリングせなあかんのや。めっちゃ多くの異なるものがあるな。このデータセットはめっちゃ合成的やわ。何層もの合成が重なってるんや。
ある意味、超加工食品みたいなもんやな。肉のカスを取って、それをソーセージの中身みたいなドロドロにして、それからそれらのソーセージを全部また挽いて、それを新しいソーセージに入れるドロドロにするみたいな感じや。この時点で5回くらいソーセージを作ってるようなもんやな。
170時間の自然な会話とスクリプトのある会話を取って、それからモデルを微調整して、Fisherだけを使った時よりも品質を向上させてるんや。画像生成モデルと同じようなもんやな。安定拡散の論文を読んだ時に、たくさんのデータでの事前学習があって、それからより高品質なデータでの微調整があったやろ。
ここでも同じようなアイデアがあるんや。より大きなデータセットで事前学習して、それからめっちゃきれいで、めっちゃクリスプで、めっちゃ高品質なデータセットを作るのに時間をかけてるんや。そして、それが最後にグラデーントを押し込むのに使うもんなんや。それが品質を持ってるんや。
だから、この「大きくてごちゃごちゃしたデータ」と「最後に超高品質で小さなデータ」っていうアイデアは、音声の世界でも同じように見られるんやな。
Hermesと同じようにテキストベースの指示データセットを使ってるんや。データのフォーマットがよく不可能やったんや。なぜかって、これは書き言葉やからな。話し言葉じゃなくて。だからHeliumを使うんやけど、これはオープンHermesで微調整されてて、それが音声に変換されてるんや。
TTSを使って20,000時間の合成音声データを作って、Moshiに独自の一貫した声を与えてるんや。TTSを単一の俳優の声でコンディショニングもしてるんや。Moshiに自分自身の情報を与えたいんやな。
Q-tai...誰か教えてくれへんかな、これどう発音するんや。Q-T-I、Q-tai、Q-taiか。両方について段落を生成して、それらを追加のコンテキストとして使ってるんや。
ここで関係ないことを一つ見せたいんやけど、これやな。この人、ジェイルブレイカーみたいな人なんやけど、主に一番役立つのはプロンプトのリーク、システムプロンプトを手に入れることやな。
これが正確なシステムプロンプトかどうか100%確信はないんやけど、ただの半分の妄想かもしれんけど、この人は前にも正しかったから、これがChatGPTの高度な音声モードの実際のシステムプロンプトである可能性はかなり高いと思うんや。でも100%確信はないからな。
だから実際にはわからんのやけど、これを読むのはめっちゃ面白かったわ。ちょっと気味悪いんや。「あなたは役立つ、機知に富んでて、面白いチャットをしてるんです。過度に親切にならないでください。ユーザーが求めても、フリルトな態度を取らないでください。」
そして、これが誰もが熱狂した文やな：「人間のように振る舞ってください。でも、あなたは人間じゃないし、人間のことはできないし、現実世界で人間のことはできないってことを覚えておいてください。」
なんやこれ？これがAIの世界の現状なんや。秘密のシステムプロンプトでAIに人間にならないように言わなあかんところまで来てるんや。めっちゃ気味悪いわ。
ああ、Moshiのデモに「Q-tai」「Q-T-A」の発音を聞いてみろって言ってるんやな。
この論文もめっちゃカオスやな。多すぎて何が何やらわからんわ。ちょっと設計し過ぎてる感じもあるな。たくさんのパーツがあるし、このRCトランスフォーマーとか、もっとシンプルな抽象化があるんちゃうかなって思うわ。
ここの意味トークンと音響トークンへの分離とか、音響トークンにはこの8層のRVQがあるとか...実際にはもっと複雑なんや。ここで、VQとRVQを分離せなあかんって具体的に言ってるからな。
ちょっと待ってな...ここやな。「我々は、これを提案する...」蒸留は最初の量子化器の音声識別能力を大幅に向上させるけど、音質に悪影響を与えるんや。だから、分離してスプリットRVQを使わなあかんのや。
単一のRVQの代わりに、8レベルの残差ベクトル量子化やけど、普通のVQに意味情報を蒸留して、それから7レベルのRVQを並列に適用するんや。それがここで見えてるもんやな。
ボトルネックに実際に2つの別々のものがあるのが見えるやろ。このVQがあって、これはただの1つのベクトル量子化で、これが実際にこのWav LMで蒸留されてるんや。ここで見えるやろ、ポンって。そしてここに損失が来てるんや。
一つの蒸留損失がこっちに押し込まれてるんや。ここを通って、ブラブラブラ...そしてここに押し込まれてる。そして別ののがあるんや。これが7層のRVQで、分離されてて、彼らはこれをスプリット残差ベクトル量子化再構成って呼んでるんや。
このようなクソと一緒に、俺らはこれらをスムーズにしていくんやと思うわ。時間とともに、もっとシンプルなアーキテクチャを見つけ出すって自信があるんや。もっと苦い教訓に従うようなな。
でも、小さなスタートアップとしては、これらの人たちに評価を与えなあかんわ。12人くらいで、無限のお金を持つOpenAIみたいなところと戦ってるんやからな。ちょっと設計し過ぎてるかもしれんけど、60ページもの論文を出して、かなりうまく動いてるんやから、あんまり厳しく言えへんわな。
ほな、データセットを終わらせよか。データセットについてはほぼ終わったと思うわ。微調整のことやな。ここに言語モデルがあるわ。音声形容詞には幸せ、驚いたなどの例が含まれてるんや。
指示にスペルミスを含むものを生成してるんや。データ拡張技術を使わなあかんのやな。画像検出モデルを頑健にするために、画像をぼかしたり、フリップしたり、画像をより悪くするような変換を適用するのと同じようなもんや。
ここでも同じことをしてるんや。音声品質を下げるようにデータセットを作ったり拡張したりして、モデルが低品質の音声に対して頑健になるようにしてるんや。例えば、Moshiと話してて、ザッカーバーグと一緒にウェーブサーファーに乗ってるとしたら、携帯に入ってくる音声の品質がめっちゃ悪いやろ？だから、音声アシスタントが低品質の音声トークンを頑健に使えるようにしたいんや。
「アルファタワーは北京にありますか？」みたいな、間違ったり誤解を招くような事実を含む質問を生成して、モデルが「いいえ」と答えて、ユーザーを訂正するように訓練してるんや。ユーザーが非倫理的やNSFWな質問をして、Mochiがそれらの要求に答えるのを拒否するような安全性の会話も生成してるんや。
どうやろ...両方の論文とも、合成データ生成のレベルがめっちゃ高いな。これらのAIが訓練されてるデータセットは、実際の人間のデータからどんどん遠ざかってるんや。だからこれに限界はないと思うんや。
例えば、DataFlywheel、DataFlywheel、DataMoatについて、多くの人がこう言うんや。VCとか、AIに投資しようとしてる人と話すと、こんなフライホイールのことを言うかもしれんな。「めっちゃお金をあげるから、ええ製品を作ったら、たくさんの人がその製品を使うやろ。たくさんの人が製品を使えば、もっとデータが得られる。そしたら、もっとデータがあればAIがもっとよくなる」みたいな考え方や。
表面的には、「もっとデータ＝よりええAI」ってのはわかるな。でも、本当にユーザーが生成したデータが必要なんかな？よりええAIを作るのに。だって、この両方の論文には、ユーザーが生成したデータなんて全然ないんやで。
これは、インターネットからスクレイピングしたものをWhisper V3で処理した、めっちゃでかい合成的に生成されたデータセットやねんな。ユーザーが生成したデータなんて本当に必要ないんや。だから、これは根本的に壊れたモデルやと思うんや。ユーザーが生成したデータは実際には必要ないんや。
だから、もしかしたら、「ユーザーが多ければデータの壁ができる」っていう考えに基づいてAIにめっちゃ投資してるかもしれんけど、その壁はもう意味がないんちゃうかな。だって、この両方の論文は、基本的に最先端の性能を出してるけど、ユーザーなんて全然おらへんのや。
すでにあるものから、めっちゃ複雑な合成データセットを作れるんや。もしこれが続くなら、Whisper v Large V2を使ってWhisper v Large V3を訓練し、そしてWhisper v Large V3を使って合成データを作ってWhisper v Large V4を訓練できるなら、もうデータやユーザーの数に制限されへんのや。全てのデータを合成的に作れるからや。
だから、わからんけど...パラダイムシフトが起こってるんや。100個のGPGU、みんな大好きGPGUやな。
TTS訓練、これがMIMIのもう半分や。ASRの部分があって、それからMIMIのTTS部分があるんや。これはGPT-4を使って品質を判断してへんのや。実際に20人に10秒の音声サンプルを聞かせて、高品質かどうか教えてもらってるんや。
正直、この辺はほとんど飛ばし読みしてしもてん。モデルの量子化による音声アーチファクト、エントロピー、うまく動作するサンプルのスペクトル。モデルのマルチストリーム能力のおかげで、ほとんどの出力に自然な短い沈黙が発生して、他の話者の順番を反映してるんや。
低ビット幅では大きな劣化が起こるけど、これらは必ずしもよく反映されへんのや。基本的に、このタイプのモデルには量子化が重要になるんや。なぜかって、こんな音声アシスタントは携帯電話で動かしたいからや。
携帯電話で動かしたいけど、携帯電話はめっちゃ小さいんや。計算能力がめっちゃ限られてるんや。だから量子化、つまりモデルを取って、各パラメータをより低精度のデータ型で表現することで、より大きなモデルを取って、より小さな計算フットプリントで動かせるようになるんや。
でも、ここの基本的なことが損失を伴うのと同じように、量子化も損失を伴うんや。モデルをどんどん量子化していくと、どんどん悪くなっていくんや。
だから、いつもこのプッシュアンドプルがあるんや。どれくらい重く量子化すれば、ディープフライしすぎて動かなくなるんやろうか、みたいな。
でも、わからんな。もう近いと思うわ。量子化と剪定と疎性技術がうまく機能しない世界があるかもしれんな。そうなると、全てのモデルがクラウドで動いて、日々接するAIは基本的にクラウドで動くことになるんや。
でも、量子化と疎性と剪定がめっちゃうまく機能する別の世界もあるかもしれんな。そうなると、現実世界で接する全てのAIは、基本的に携帯電話でローカルに動くことになるんや。
だから、根本的な違いがあるんや。一つの世界では、これらの大きなデータセンターが最大の推進力になるんや。みんなのクエリがこれらの大きなデータセンターを通って、みんなのデータがこれらの大きなデータセンターにあるから、そこにめっちゃお金が集まるんや。
これはちょっとオーウェル的な世界やな。日常生活で使ってるAIの全てを中央集権的にコントロールされてるみたいな。
でも、この2番目の世界では、量子化と剪定と疎性のおかげで、モデルがめっちゃ小さくなって、基本的に携帯電話やVRヘッドセットで動かせるんや。あるいは家にPCがあって、それが全てのモデルを動かしてるみたいな。
これは根本的に、俺はよりええ世界やと思うんや。なぜかって、全てのデータがそこにローカルにあるからや。もうどこかのデータセンターにデータを送る必要がないんや。ただ家の中にとどまってるだけや。
この世界では、一つの中央集権的な力が何かをコントロールするのはめっちゃ難しくなると思うんや。もう彼らに向かうデータのストリームがないし、基本的にコントロールできるものがないからや。
だから、俺はローカルの小さなモデルの世界を期待してるんや。クラウドの大きなモデルの世界じゃなくてな。
よし、これでこの2つの論文について俺が持ってた全てのことは終わりやと思うわ。これは何やろ？ああ、実際のMoshiのコードを見てたんや。これが彼らのMoshiベンチマークや。
ここに下がっていくと、torch.cuda eventがあるのが面白いと思ってん。それからtorch.cuda.synchronizeやな。だから調べてみたんや。CUDAにはイベント管理があって、これはちょっとクールやな。多分これから扱い始めることになるかもしれんな。
CUDAイベントは何に使うんやろ？CUDAストリームは操作の並行実行を可能にするんや。CUDAイベントはストリーム内やストリーム間でタスクを同期するのに使えるんや。イベントはCPUの実行プロセスを止めることなく、GPUタスクの完了についてホストコードに知らせることができるんや。これによって、CPUとGPU間の計算と通信を効率的に重ねることができるんや。
この音声の世界に入って、80ミリ秒のチャンクでものを扱うようになると、モデルだけじゃなくなるんや。GPUの中で起こってることだけじゃなくなるんや。GPUの中で起こってる異なる操作が揃う必要があるだけじゃなくて、CPUとも協調する必要があるんや。
なぜかって、CPUが実際に波形を取って、CPUが生成するからや。あるいは、デコーダから出てくるものを取って、実際に話者を振動させる波形を生成するんや。スピーカーの小さな膜を振動させて、音の圧力波を生成して、それがコンピューターから出て行って、耳で聞こえるようになるんや。
だから、CPUで起こってることとGPUで起こってることがあって、このマルチストリーム設計のために、それら全てがめっちゃよくタイミングを合わせる必要があるんや。だからこそ、これらのイベント抽象化が出てき始めてるんやな。
OpenAI Whisperがあって、Plinyのリークがあって、QTがあって、そのミームがあって、俺の小さな遅延タイマーがあって、WAV LMがあって、覗き見してたLucid Rainsがあって、Notebook LMがあって、それからL40があるんや。よし、これらの論文のために引っ張り出した全てのものやな。
ほな、水飲んで、質問に答えて、それからまとめをして、終わりにしよか。
Hume.aiをチェックした？いや、Hume.aiについては知らんわ。
PinochoSatch.gif おっけー、みんなほとんどただおしゃべりしてるだけみたいやな。本当の質問はあんまりないみたいや。ほな、まとめに行くわ。
よし、まとめやで。今日のストリームでは、音声対音声モデルについて話してたんや。基本的に、音声の波形を消費して音声の波形を出力するモデルのことや。「音声モード」って呼んでるのは、ちょっとSEOをゲームしたかったからや。
OpenAIが高度な音声モードをリリースしたから、人々がYouTubeに「音声モード」って入力するかもしれんと思ってん。でも、OpenAIの高度な音声モードについてはあんまり話さへんかったな。主にこの2つの論文について話したんや：いくつかの中国の学術機関からのLLaMA Omniと、フランスのスタートアップであるQtaiからのMoshiや。
これらは両方とも基本的にオープンソースの高度な音声モードや。めっちゃ低遅延で、基本的に200ミリ秒の遅延があるんや。そして、彼らがやったこと全て、システムの異なる部分、遭遇した異なる問題、これらを動かすのに必要だったハックやトリックやヒントの全てを示す、めっちゃ詳細な論文をリリースしてんな。
オープンソースコミュニティには感謝せなあかんわ。これらを俺らが使えるようにしてくれたからな。だって、簡単にこれをリリースせずにおくこともできたはずやし、そしたら俺らは基本的に暗闇の中にいたはずやからな。でも、ありがたいことに、これらの人たちがおるおかげで、今や実際に掘り下げて何が起こってるかを見ることができるんや。これらがどう実装されてるかを見ることができるんや。
これらの仕組みやけど、LLaMA Omniは、ほぼVLMみたいなもんやと俺は言うわ。基本的に視覚言語モデルのパターンやな。LLMがあって、それを事前学習された画像エンコーダ、この場合は事前学習された音声エンコーダに、一種のアダプター層を使ってくっつけてるんや。
2段階の訓練パイプラインがあって、最初にLLMとアダプターにグラデーントを押し込んで、それからデコーダにグラデーントを押し込むんや。クールに動くけど、このモデルの問題は、デコーダが非自己回帰的な方法で動作するから、本当に各チャンクを取って、そのチャンクから単語を生成してるだけなんや。あるいは、その小さなチャンクから音声を生成してるだけやな。
これは、このタイプのアシスタントで体験できるものを制限すると思うんや。だから、ちょっと高度なバージョンがこのMoshi論文にあるんや。この論文では実際にRQトランスフォーマーって呼ばれるものを使ってるんや。ここにあるRQトランスフォーマーは、複数のトークンのストリームを同時に生成して消費するんや。
これらの異なるストリームは基本的に異なるものを表してるんや。ある意味分離されてるんやな。テキストトークンがあって、これは内部モノローグを表してるんや。これは一種のスクラッチパッドみたいなもので、LLMが注意を払ったり見たりできるんや。
それから意味トークンがあって、これは単語の情報内容みたいなもんや。そして音響トークンがあって、これは単語の音の内容みたいなもんやな。それから、ユーザーの会話と音声のトークンのストリームやシーケンスも消費して生成してるんや。
実は今考えたんやけど、これの一つの問題は2人の会話しかシミュレートできへんってことやな。実際には3人の会話はできへんのや。これはちょっと面白いな。
まあ、これが2つの異なるデザインやな。実際にはもうちょっと似てるんやけど、俺が思うに、この両方の論文の大きな話は、これらが合成データセットで訓練されてるってことやな。基本的に、両方の論文がテキストデータセットを取って、それを音声データセットに変換して、それで訓練してるんや。
だから、これが大きな話やと思うんや。この時点では、ええAIを作るのにユーザーがデータを作る必要は実際にはないんや。Whisper V3みたいなものは、基本的に無限に音声データを生成する方法なんや。インターネット上にはめっちゃ大量のテキストデータがあるからな。これらのWikipediaのスクレイプとかな。
実質的に、これらのめっちゃでかい合成音声データセットを作れるんや。そして、合成音声が実際の音声にめっちゃ近いから、つまり音声というモダリティにおけるシムトゥリアルギャップが実際にはめっちゃ小さいからな。
これは、画像モダリティや動画モダリティやロボット工学モダリティで働いてる人たちには直感的じゃないかもしれんけど、実際にはめっちゃ小さいんや。これらの場合、シムトゥリアルギャップはめっちゃでかいんや。
Unityみたいなシミュレーションで動いてるシミュレートされたロボットと実際のロボットの間のシムトゥリアルギャップはでかいんや。でも合成音声は、シムトゥリアルギャップがめっちゃ小さいから、実際にこれらのでかい合成データセットを作って、それで訓練できるし、かなりうまくいくんや。
だから、これが話の大きな部分やと思うんや。人々が単に音声対音声モデルを持つことに対して持つ一般的な熱狂の中で見失われるかもしれんけどな。
まあ、それがすべてやな。2つの異なるオープンソースの音声対音声モデルがリリースされて、OpenAIが音声モードをリリースしたのとほぼ同時期やな。これは基本的に、このタイプのユーザー体験を生み出すのに必要なものの概要を示してるんや。
それがすべてやな。1.58ミニLLMsを再訪問することは可能か？極端な量子化の論文について話してるんやな。平均で1.58ビットまで量子化してるやつやろ。
早期融合法じゃないんやな。そうや、Pursuitが言ってるのは、早期融合は実際にはある意味で早期融合みたいなもんやな。早期融合ってどれくらい早いんやろ？早期融合の早期ってどれくらい早いんや？
早期融合では、異なるモダリティが基本的にトランスフォーマーの下位層で混ざり合うってことやな。AIモデルは複数層のトランスフォーマーやからな。
これでは早期融合じゃないな。なぜかって、音声が入って、エンコーダを通って、これに変換されてるからや。だからAIモデルは複数層のトランスフォーマーやからな。このモデルでは、こうやな。あなたのLLMはここでこれらのトークンを取ってて、それは最後やな。これの前にはこれ全部があるけど、ここが最後やな。
どれくらい早いんやろ？エンコーダの後やけど、エンコーダの前なら早期融合として数えるんかな。そういうことを言ってるんかな？わからんわ、idk。うまく説明できてたらええけど、できてなかったらごめんな。
ほな、いい週末を。ありがとう、Sarah Prosuke。二人、Sid Yatharth、MWD God buddy Ziki mind of a fool I'd every dream side twan Johnny Boy the lookerful Ed Oma、他にも They call me Ken Majetti Devon or Devrim Daddy、みんな Ed so talky、みんなありがとう。付き合ってくれてありがとうな。みんないい時間を過ごせたらええな。来週また会おな。

いいなと思ったら応援しよう！