スコット・スティーブンソンとAI音声エージェントを構築する - 707

21,365 文字

最近では、音声認識からテキスト変換モデル、LLMモデル、TTSモデルについて個別に議論するんじゃなくて、知覚モデル、理解モデル、そしてインタラクションモデルについて話すべきやと思います。もしかしたら、これら全部が一つのものかもしれませんな。目的によって変わってくるんですけど、知覚があって、理解のステップがあって、それから何らかの形で世界と相互作用する、つまりデータベースのエントリーを変更したり、音声を生成して人間に話しかけたりするわけです。これがエージェントってことですな。
みなさん、twiml AIポッドキャストの新しいエピソードへようこそ。わたくし、サム・シントンです。今日はスコット・スティーブンソンをお迎えしています。スコットはディープグラムの共同創業者兼CEOです。本編に入る前に、みなさん、お聴きのプラットフォームで購読ボタンを押してくださいね。スコット、ポッドキャストへようこそ。
「お招きいただき、ありがとうございます」
「お帰りなさい。前回お話してからずいぶん経ちましたね。信じられへんかもしれませんが、7年ぶりです。AIの世界では相当長い期間ですな」
「その通りです。この7年で本当に多くのことが変わりました」
「みなさんに簡単にあなたの経歴を振り返っていただきたいんですが、確か物理学がご専門でしたよね？」
「はい、その通りです。私は素粒子物理学者で、地下深くにダークマター検出器を作っていました。基本的に、銀河中を飛び交う粒子を捕捉するための検出器を作っていたんです。探していたのはダークマターですね。それから約9年前に、何人かの物理学者と一緒にディープグラムを立ち上げました。現在は400以上のB2B顧客にオーディオAIモデルを提供する企業に成長し、従業員は100人規模になっています」
「すごいですね。音声の分野について考えると、前回お話した頃は、専門的な音声モデルを作っている企業は数えるほどしかありませんでした。少なくともモデルの面では、かなり大きく変わったと思います。個人的には、Whisperが新しい時代を切り開いたと感じています。音声の利用のしやすさという点でね。複雑さの問題が完全になくなったわけじゃないですが。Whisperで話者分離を試してみましたが、関連するコンポーネントがたくさんあって、うまく結果を出すのは難しかったですね。
でも、最近ではそれ以上に、QuenなどのAIモデルが毎日のように登場していて、音声に特化したものも出てきています。Geminiのようなマルチモーダルモデルでさえ、かなり decent な文字起こしや話者分離ができるようになっています。この進展について、音声AIを専門とする企業の立場から見て、どのように感じておられますか？」
「確かに多くのことが変わりましたが、まだまだやることは残っていますね。それについてはもっと詳しく話したいところですが、確かにここ数年で音声分野に注目するモデルが増えてきました。テキストの分野では大きなブームがありましたが、それがある程度落ち着いてきたので、他のモダリティに目を向ける人が出てきたんです。例えば、画像や動画、そして音声ですね。
私はこれを『タイピング、タッピング、トーキング』という観点から考えるのが好きです。私たちは何かをクリックしたり、タップしたり、タイプしたり、話したりして機械とやり取りしてるわけですな。ここ数年でようやく、精度が十分に良くなり、速度も十分になり、コストも手頃になり、アクセスしやすくなってきました。世界中の開発者やプロダクト開発者が、音声アプリケーションの作り方を学んでいる最中なんです。
これら全てが同時に起こっているわけです。この分野に多くのプレイヤーが参入してきているのを見ています。私からすると、大歓迎ですね。会社を始めた時、タイピングとタッピングは既に確立されているけど、トーキングはまだやな、と考えていました。人間と機械のインタラクションにおいて、トーキングは主要なモダリティの一つです。これを何とかせなあかん、そのうちホッケースティック現象が来るはずや、と思ってました。そして今、それが現実になっているんです」
「確かにそうですね。モデルを巡る活動は活発になってきていますが、モデルは方程式の一部に過ぎませんね。純粋なモデルの観点から見て、目標に到達するためにはどんなギャップがあると思われますか？あなたの視点から見て、音声の分野でどこを目指すべきだと考えておられますか？」
「AIにおける目標は、当然のことながら時とともに変化していきます。7年前を振り返ると、標準的な音声認識の精度でさえ、リアルタイムのことは考えずに、他の言語のことも考えずに、英語だけで、ポッドキャストの音声のような本当に質の良いクリーンな音声だけを考えても、精度はあまり良くありませんでした。
これをうまく機能させるためには、多くの開発が必要でした。しかし今では、電話の音声や、バックグラウンドノイズの多い電話音声などの複雑な要因が加わってきています。7年前に遡ると、そういった音声の精度は約50%で、つまり2語に1語は間違っていたんです」
「そうそう、あの頃のモデルを試していたの覚えてますわ。チャンネルを指定せなあかんかったですよね」
「その通りです。結果はチャンネルによって大きく異なっていました。つまり、モデルが学習したものと、実際に使用する環境との間にマッチングが必要だったということです」
「私が遭遇した問題の一部は、私の録音環境とそれらのモデルが期待する環境との間のギャップにあったんじゃないかと常に疑っていました」
「その通りですね。時間とともにモデルがより一般的になっていくことを目指しています。これを大学や高校に行くようなものと考えています。世界のことをよく知り、多くの異なる問題に取り組めるモデルを作りたいんです。
でも、もう一つの重要なアナロジーがあります。大学を卒業すると、人は仕事で専門化していきますよね。これが私の視点から見たAIの次のフェーズです。非常に優れた汎用モデルがあり、それをユースケースに適応させることができる。これはエージェントの場合もあれば、音響環境に適応する音声認識モデルの場合もあります。
ただし、それを自己学習的な方法で行う必要があります。以前は、これらのモデルを改善するには純粋な教師あり学習を使う必要がありましたが、今はそれは必ずしも真ではありません。合成データを生成したり、自己教師あり学習の技術を使用したりできます」
「以前話していた、モデルの進化について振り返ると、CDIという音声認識のフレームワークがありましたね。これは非常にパイプライン的なアプローチを取っていました。それから4、5年前くらいにFacebookからWave2Vecが登場し、それが大きなゲームチェンジャーとなりました。自己教師あり学習を取り入れ始めたからです。
今日のLLMで見られるような手法の一部を取り入れ始めたんです。つまり、必ずしも完璧なラベルが全てに必要というわけではなく、それでもたくさんのことを学習できるようになったんです。その後Whisperも登場し、同様の技術を活用しながら、基礎となるモデルアーキテクチャも改善しました。
この流れは続いていくでしょう。ディープグラムでも研究チームがこの最前線を押し進めています。精度とスケーラビリティ、実装コストを見ると、オープンソースモデルとB2B専用モデルの間には違いがあります。これは適応化が重要になってくる部分です。
全ての音声が適応化される必要があるわけではありません。一部はモデルで上手く処理できますが、一部は適応化が必要かもしれません。特にエージェントの観点から見ると、タスクを達成し、データを取り込み、それから学習して時間とともに改善していく場合には適応化が重要になってきます」
「その種の適応化についてお話しする時、非常に特定のドメイン向けのアプリケーション、例えば医師が患者のメモを口頭で記録できるようにするような場合を想定されているんでしょうか？その場合、明らかに専門用語を多く使用することになりますが、そのような特殊なケースでのみ適応化が必要なのか、それともより一般的なB2Bのユースケースでも適応化が必要になってくるんでしょうか？」
「私はそれをよりモダリティとして考えています。人間とのインタラクションを例に挙げましょう。例えば、誰かと話していて、その人があなたの名前を特定の方法で発音するとします。私の苗字はStevenson（スティーブンソン）ですが、多くの人がStephenson（ステファンソン）と発音します。もし望むなら、『実はスティーブンソンで、ステファンソンじゃないんです』と訂正することができます。
これは単なる小さな編集ですが、コールセンターのAIエージェントが何度も何度もあなたの名前を間違って発音し続けると、イライラしてきますよね。このような一見些細なことが実は重要で、以前はオープンループだったものが、今は会話の中でクローズドループのフィードバックを得られるようになったんです。
発音は単純な例の一つに過ぎませんが、AIエージェントで問題を解決しようとしている場合、『そっちのことは気にせんでいいから、こっちの解決したい問題に集中してよ』というように指示することができます。次世代のモデルはそれが可能になります。これが恐らく最大の根本的な変化の一つでしょう。
過去10年くらいのモデルは、主に教師あり学習の観点から訓練されており、1〜2年のタイムラインで訓練されています。そのため、1年か2年、運が良ければ四半期程度古いものになっています。しかし、将来はそうではなくなります。リアルタイムで更新され、学習していくようになります。
私はモデルを必ずしも1つのモデルや10のモデルとは考えていません。数十億のモデルが存在することになるでしょう。その中には使われなくなって消えていくものもあれば、時間とともにどんどん良くなっていくものもあります。そして、それらは達成しようとしている目的にもっと特化していくことになります」
「おっしゃっていることの一部は、ファインチューニングやLoRAアダプターを思い起こさせますね。これらの数十億のモデルは、そういったものなんでしょうか。ただし、通常、それはリアルタイムのクローズドループの自動プロセスではありませんよね。音声の分野でファインチューニングは現在どのように使用されているのでしょうか？また、それがどのように進化すると予想されますか？」
「私はこれをコンピュータのメモリシステムのように考えています。昔はテープがあって、そこにデータを保存していましたよね。それから回転する磁気ディスクがあって、今でもこの階層は存在しています。テープは大量のデータを保存するのに最も安価ですが、最も遅いんです。
磁気ディスクは次に安価で、テープからデータを探すよりもずっと速い。でも、本当に速くデータを探したい場合はSSDを使います。もっと速くしたい場合はRAMを使います。そして超高速が必要な場合は、CPUのキャッシュを使います。L3が最大で最も遅いキャッシュで、L2は少し小さいけど更に速く、L1は更に小さくて更に速い。そこで終わりですが、これは大きくて遅いものから、超高速だけど小さいものまでの huge な範囲があるんです。
これと非常によく似たプロセスが、これらのモデルの構築でも起こることになります。これは速度の観点からですが、変更の能力やそれを実行するコストの面でも同様です。
例えば、現在の会話システムでは、少なくとも今日のシステムの構築方法では、全ての異なるモデルに渡されるプロンプトの中に会話のコンテキストを含めて運んでいきます。しかし、将来的にはそうはならないでしょう。現時点では、その会話のために常に増加し続けるプロンプトを持っているだけです。
会話が2時間続くと、プロンプトの末尾から内容が落ちていき始め、時間とともにコンテキストを失い始めます。会話が5分、10分、20分と続くかもしれません。しかし、1時間か2時間経つと、ほとんどのシステムではパイプから落ちていってしまいます。
コールセンターなどで問題を解決したい場合、5分程度で済むかもしれないので、それでもいいかもしれません。でも、これはモデルが学習したように見えるだけで、コンテキストを保持しているだけです。実際にはモデルの重みは更新されていないので、もう一度電話をかけ直すと、最初の会話を始める前と同じように『無知』な状態になってしまうんです」
「その一部はエンジニアリングの問題のように聞こえますね。会話の開始時にコンテキストの一部を更新するシステムを構築することもできそうです。実際、私も、なぜ通信会社に電話して電話番号を入力しても、次のエージェントがまた電話番号を尋ねるのか、何年も不満に思っていました。これはモデルや技術の問題ではなく、プロダクトの問題ですよね」
「はい、でもそういった状況の根本にはコストの問題があるんです。その情報を担当者に提供し、それについて学び、顧客情報を調べるのにどれだけのコストがかかるか、ということですね。コールセンターはそれが高すぎると判断して、代わりに担当者を情報なしの状態で会話に放り込んで、最善を尽くしてもらうことにしているんです。
でも、AIエージェントを使えば、そうする必要はなくなります。追加の作業や追加のデータ分析にかかるコストが、5分もかからなくなりますし、非常に高価になることもありません。より多くのコンテキストを詰め込むことができるようになります。
でも、おっしゃる通り、これの多くはエンジニアリングの問題です。ただし、異なる階層へのアクセスはエンジニアリングの問題ではありません。単にコンテキストを大きくすることから離れて、代わりにモデルが多くの人々の使用から実際に時間とともに学習することを望むなら、基本的にはフェデレーテッド学習の問題になります。
同時に1万の会話が進行していて、全てが1つのAIの脳から始まったとします。それが1万の異なる会話に分かれたわけです。全ての会話から学んだことを、どのように同じモデルに戻して含めるのか。1万1番目の新しい会話を始める時に、他の全ての情報を含めるにはどうすればいいのか。完璧である必要はありませんが、時間とともに改善していってほしいわけです。
これが本当の意味での知能革命の約束です。機械学習システムをオフラインで訓練される教師あり学習の方法でのみ機能するものとして考える必要がなくなるんです。これは知能革命の0.5版とでも呼べるものでしょう。次のバージョンでは、時間とともに更新され、学習できるようになります。
現在、この方法は最先端の研究段階にありますが、私たちがやっているのは、一部分ずつ取り組んでいくことです。最も重要なことに焦点を当て、それをモデルに確実に学習させ、今は細かいことは忘れる。そして、それを拡張できるかどうかを検討する。時間とともにテストし、領域をどんどん広げていくんです。
これこそが、ディープグラムやOpenAI、Anthropicなどの基盤的な研究チームが毎日やっていることなんです」
「その未来が実現し始めている兆候は見られますか？どんな兆候を見ておられますか？確かに、あなたが描写した世界よりもずっと限定的ですが、フェデレーテッド学習のユースケースは見てきました。継続的学習に関する研究もありますが、通常はフェデレーテッドな側面は持っていませんよね」
「はい、見えています。でも、それをどの程度『見て、掴める』かという問題です。AIの観点からすると氷河のような速度で動いていますが、それでも2年後には間違いなくここにあるでしょう。
既知のアーキテクチャや既知のモダリティで反復されている高速で動くものがあります。それは本当に速いペースで進んでいます。でも、まだ論文も書かれていない、世界中に例もないような、モデルの新しい訓練方法に踏み出そうとすると、比較的ゆっくりとしたペースになります。
その理由は、それがどのように機能するかについて30のアイデアがあっても、実際に機能するのはそのうちの1つだけかもしれないからです。しかし、30の実験全てを行う必要があり、それらはモデルが実際に機能するかどうかを判断できる十分な規模である必要があります。
訓練に長時間かかり、データのラベリングなども必要です。でも、一旦何かを見つけると、『あ、これは機能する』とわかります。例えば、音声のエンドツーエンドのディープラーニングがそうですし、テキストのトランスフォーマーもそうです。
残差ネットワークのような個々のコンポーネントも同様です。これらの小さなものが全て積み重なって、後で全てがどのように構築されるかの構造を提供するんです。十分な証拠と、それらの証拠に関する十分なマーケティングがあれば、みんながそれに飛びつくんです。
だから、AIの観点からすると、これから2年くらいはかなりゆっくりとした進展になると予想しています。でも、その後は『一夜にして起こった』ように見えるでしょう。実際には、舞台裏で誰もが不確実性を打ち破ろうと努力していたわけですが」
「少し前に戻って、基本となるモデルが急速に進化しているという考えについて。あなたは社内に研究チームを持っているとおっしゃいましたが、基本モデルへの投資は以前と同じくらい、それとも増えているでしょうか？それとも減っているでしょうか？音声認識や話者分離などの基本的な部分は商品化されていて、それがあなたのビジネスであっても、既製品を使用して問題ないとお考えですか？」
「最初の方ですね。AIカンパニーの作り方には、組み合わせ的に見ていくつかの異なる方法があります。消費者向け製品を持ち、独自のモデルを構築し、インフラも全て行うAI企業になることもできます。モデルのみを作るAI企業、インフラのみを行うAI企業、アプリのみを作るAI企業になることもできます。
また、それらを2つ組み合わせることもできます。ディープグラムは、私たちはモデルビルダー、基盤モデルビルダーであり、インフラも提供しているカテゴリーに入ります。他の企業は異なることをしています。
音声の世界では、特に複雑だということに気付きました。音声や動画は一般的に非常に複雑で、インフラだけを提供していると、至る所に穴があることに気付きます。
例を挙げましょう。音声AIエージェントを構築する際、相手が言いたいことを言い終わって、あなたの番が来たことをどうやって知るのでしょうか？これは非常に難しい問題です。このターンテイキングの能力ですね。
でも、標準的な音声認識から、相手が話し終わったという信号をどのように得るのでしょうか？それはかなり曖昧な信号です。ピリオドがあるとか...本当にはわかりません。また、どのくらい待てばいいのでしょうか？
『たぶん話し終わったな』と判断するまで。一つの方法として、沈黙を探すことができます。2秒間何も言わなければ、おそらく自分の番だろうと判断する。でも、そうすると、実際に知能を持っていれば活用できるかもしれない多くのコンテキストを見逃してしまいます」
「その通りですね」
「基盤モデルのビルダーであれば、人々が音声AIエージェントを構築しようとしている時にこの問題を見て、『ちょっと待てよ、これは本当は知覚レイヤーに属すべきものだ』と気付くことができます。その知覚レイヤーには音声認識も含まれるべきですが、話者分離や、トピックの把握も必要です。
リアルタイムモデルの場合は、他の人の番が来たかどうかも把握する必要があります。少なくとも音声に関して、このループは知覚、理解、インタラクションのようになっています。知覚は私が列挙したようなもので、他にもたくさんあります。
理解は、『さて、全ての事実を書き留めて、それらの事実を教えてもらったけど、今度は何をすべきか』ということです。何か言うべきか、メールを送るなどの行動を起こすべきか、などです。
何か言うべきだと判断した場合、『これらが私が言いたいことです』というだけでなく、『どのように言いたいか』も重要です。深刻なトーンでゆっくりと話すべきか、といったことです。これは全てコンテキストであり、伝えられる必要があります」
「現在のアーキテクチャでは、本当に人間のように感じる音声AIエージェントシステムを構築したいと思っても、それは単に不可能です。モデルを構築するか、モデルに新しい機能を組み込んで、基本的にモデル間の境界を曖昧にしていく必要があります。
インフラプロバイダーだけだと、常に後れを取ることになります。モデルプロバイダーだけだと、全てのインフラの人々にあなたのモデルを使うよう説得しなければなりません。彼らは大きな観客にサービスを提供しようとしているので、あなたのモデルをどのように使うべきかを正確には知らないでしょう。
そこで私たちが選んだのは、それらを組み合わせることです。モデルを構築し、インフラもホストします。特定のタイプのモデルを提供するために独自のインフラをゼロから構築する必要がある場合、例えば独自のデータセンターを持つ必要がある場合でも、それを行います。
なぜなら、私たちはユースケースを見ているからです。2万席のコールセンターに話を戻すと、これは必要な計算量が本当に膨大です。現在のモデルを立ち上げて、うまくいくことを期待するだけでは済まないんです。
だから私たちは会社としてそれらを組み合わせています。これは非常に強力な方法だと思います。顧客からのフィードバックを得て、それを直接モデル構築に活かすことができるからです。
ただし、デメリットもあります。OpenAIやAnthropicが上手く行っているように、消費者向けアプリを持っていると、会社の認知度を大きく高めることができ、そこからも多くを学ぶことができます。つまり、戦いの場を選ぶ必要があるんです」
「一つ思い出したのですが、私は個人的な経験から話者分離の複雑さについて触れました。もしターンテイキングを予測するようにモデルを構築し、訓練するなら、話者分離に関してクローズドループを作ることができそうですね。両方を改善するために」
「その通りです」
「通常、音声認識とは別に実装される話者分離は、やはり課題がありますね」
「変ですよね」
「世界の現状で話者分離がそれほど良くない理由を説明しましょう。ディープグラムの話者分離は世界クラスですが、それでも素晴らしいとは言えません。オープンソースのものも同様です。
その理由は、人々がそれに多くのお金を払いたがらないからです。これは事実です。高精度の音声認識、低遅延のリアルタイム音声認識、高品質のTTS音声など、そういったものには人々は多くのお金を払う意思がありますが、話者分離のユースケースについては、その分野にはあまりお金を使おうとしません。
これが全てのモデルビルダーやインフラビルダーに対して、『機能はすべきだけど、あまり時間をかけない方がいい。他のことの方がもっと重要だから』というシグナルを送ることになるんです」
「それは、単語ごとの精度を修正するのと比べて、話者分離の修正のUIが比較的シンプルだからですか？それともユースケースがないからですか？」
「ユースケースと、それに伴う収益の問題ですね。手の届きやすい果実から取り組む必要があります。話者分離は複雑ですが、もし私たちの研究チームが『話者分離を解決しよう』と決めたら、それほど時間はかからないでしょう。
でも、他にもたくさんの課題に取り組んでいるんです。これが本当の問題で、今まではいつも話者分離よりも他のことが優先されてきました。
ただし、時間とともにモデル企業やインフラ企業は、より良いツールを自社で開発していきます。そのため、モデルの生産コストは時間とともに下がっていきます。また、ディープグラムのように会社が大きくなると、より多くのことに注力できるようになります。
私たちが選択したのは、ラインナップにTTSを追加し、音声インテリジェンスを追加し、そして完全な音声AIエージェントを追加することでした。これは音声分野における手の届きやすい果実を全て網羅しているので、それ以上の拡張は今のところ見込んでいません」
「エージェントについてもっと深く掘り下げたいですね。これまで何度か触れてきましたが、その前に、数ヶ月前にGroqで行った作業について触れられましたが、それを思い出しました。以前、リアルタイムのインタラクションについて、音声版チューリングテストに合格するようなものにはまだ至っていないとおっしゃいましたが、そこに近づいているように見えます。あなたたちはリアルタイムに近づいていますよね。その分野での能力と、そのループを閉じることについて話していただけますか？」
「はい。知覚を正しく行い、それを非常に短い時間で行う必要があります。通常、知覚のための時間予算は250ミリ秒以下です。その後、理解と音声生成が必要です。全体の時間予算は250ミリ秒、あるいは最大で500ミリ秒かもしれません。つまり、全てのプロセスに対して約0.75秒ということです。
これはまだ少し長すぎますが、それでもかなり人間らしく感じられるでしょう。特に、思考の終わりやターンの終わりを予測するモデルがあれば、次のような感じになります：『相手の話し方から、まとめに入っているようだ。もうすぐ私の番が来そうだ。次の数語が予想通りの場所で来れば、次に何を言うべきか考え始めていいな』という具合です。
これは私たち人間がやっていることです。人間をモデルとして使うことで、これらの基礎となるモデルをどこに向かわせるべきかについての良い示唆が得られます。
つまり、応答のための総予算は500〜750ミリ秒程度で、合理的な支出、つまり時間あたり100ドルでも10ドルでもなく、1〜5ドル程度の範囲で、その目標に到達できると安全に言えます。
これは、フィリピンやインドのコールセンターエージェントの時給、通常2〜5ドル程度と同じ範囲です。ここから面白くなってきます。コストが同程度なら、通話の最初の比較的簡単な部分をAIに任せ、その後コンテキストと共に人間に引き継ぐということが始まるかもしれません。
ある意味では、これは既に解決済みと言えます。ただし、『これが人間じゃないとは100%わからない』というチューリングテストのレベルには達していません。現時点では、変な発音をさせようとしたり、話題を逸らそうとしたりすれば、確実に躓かせることができます。
今はそういった弱点がありますが、2年以内にはそういった問題にも非常に強くなるでしょう」
「音声認識とテキスト音声変換について話してきましたが、それが唯一の方法なんでしょうか？テキストがある種のボトルネックになっているように思えます。モデルが言われたことを『理解する』とき、テキストという、私が考えるところでは限られた帯域のチャネルを通過する必要はないのではないでしょうか？これは正しい考え方でしょうか？」
「その通りです。基本的に、様々な分布の端を切り落として平坦化し、一つのテキスト表現に強制的に押し込んでいるんです。
良い例を挙げると、どんな文でも、単純な文でも『Hello World』でも、若い人でも年配の人でも、どんな背景や方言でも、マイクから遠くても近くても、どんな背景ノイズがあっても言うことができます。でも、それを文字起こしすると、全て同じになってしまいます。
ここで既に、音声には同じことを『意味する』可能性の巨大な基盤があることがわかります。でも、人間として聞く時、それらは同じ意味ではないことがわかります。車の中で誰かが何かを言っているのを聞けば、それはコンテキストを教えてくれます。声に興奮が感じられれば、それも何かを伝えています。
テキストに変換するとき、この情報を全て捨ててしまっているんです。しかし、これは最初にシステムを構築する最善の方法です。その理由の一つは、人間がデバッグする必要があるからです。
リアルタイムで動作する何かを接続して、望む動作を得るためには、少なくとも歴史的に、それは音声認識でした。『音声を取り込んで、単語に変換し、それをLLMに接続し、そしてTTSに接続する』という具合です。
でも、人々がそれに飽きて、習熟してくると、『このシステムはコンテキストを失っているぞ。これらの境界をどうやって越えればいいんだろう』と考え始めます。音声インテリジェンスモデルを通じてそれを実現する方法はありますが、私の考えでは、もはや音声認識モデル、LLMモデル、TTSモデルについて話すべきではありません。
代わりに、知覚モデル、理解モデル、インタラクションモデルについて話すべきです。そして、おそらくそれらは全て一つのものかもしれません。達成しようとする目標によって変わってきます。
例えば、非常に難しい音声を扱う場合、その中で何が起こっているかを理解するために知覚モデルを強化する必要があるかもしれません。でも、それがこのカテゴリーかあのカテゴリーかを判断するだけなら、非常にシンプルな理解モデルで済むかもしれません。
TTSの部分も、単一の声でいいかもしれません。全ての人間の声を再現する必要はありません。それほど複雑なモデルである必要はなく、あなたが選んだ通常の方法で話し返すだけでいいかもしれません。他の背景ノイズを生成する必要もありません。
出力段階を単純化し、理解段階を単純化できますが、その代わりに入力段階をより強化する必要があるかもしれません。音声があまり難しくなく、深く考える必要があり、どの言語でも話せるようにしたい、翻訳もしたいなど、様々なことをしたい場合は、後半を強化することになるでしょう。
これが、『全てを支配する一つのモデル』について考えることが必ずしも正しくない理由の一つです。そういう方法があるかもしれませんが、可能なコストと比較すると非常に高額になってしまいます。
これが、B2Bの観点から見て、境界を越えるモデル、あるいはスタックの特定の部分に対して小・中・大のモデルを考え、それぞれをユースケースに適応させ、スケールでデプロイすることが非常に理にかなっている理由です。
結局のところ、私が常に顧客のことを考えるとき、彼らはこれを1万の同時接続にスケールアップする必要があるんです。会話の中で80ミリ秒ごとにサンプリングしている1000億パラメータのモデルをスケールアップするのは、彼らにとってコストが高すぎます。
そこで、それを機能させるための他の方法を見つける必要があります。ただし、将来的に、つまり5年後、10年後には、適応可能で制御可能な、本当の意味での音声から音声へのモデルが出現すると思います。これは私たちがディープグラムで行っている研究の一部でもあります。
しかし、それまでの間は、手元にあるツールで制御可能性を確保したいですし、デバッグの能力も必要です。今後2〜5年の間に、私が音声エージェント1.0と呼ぶものの大規模な展開が見られると思います。
これは主に音声認識、LLM、場合によってはRAGなどを使用し、そしてTTSという形になるでしょう。多くの人々にとって理解しやすいシステムだからです。その後、数年後に新しい革命が起こり、音声エージェント2.0が広く普及することになるでしょう。それは非常にコンテキストを重視したAIベースのモダリティになるはずです」
「進化の道筋として興味深い考え方ですね。現在、LLMや深層モデルをデプロイする際の課題の多くが解釈可能性に関するものです。最初に全てをテキストに変換することで得られる解釈可能性と予測可能性を失う準備ができているのでしょうか。
モデルを内部観察できるようにするための良い強制関数のように思えます。その後のステップとして、モジュール式のアプローチは素晴らしいと思います。ただし、全てをテキストに強制的に変換せず、より統合された形で。
そして、最大の進歩は全てをエンドツーエンドで訓練する時に得られるという考えを適用すると、これらの異なるモジュールをエンドツーエンドで訓練するとはどういうことか。でも、それはおっしゃるように少なくとも5〜10年先の話ですね」
「特定のユースケースでは、6ヶ月後にそういった方法で訓練されたものが出てくる可能性はありますが、それらは他のインスタンスで使用できるような形で制御可能なものにはならないでしょう。実際には、特定のタスクに非常に特化した訓練になると思います。
例えば、Googleは長い間、チャネルとしての音声を重視してきました。多くの人はこのように考えないかもしれませんが、これがGoogleが音声チームを作った理由です。彼らは『我々はどのように攻撃される可能性があるか？誰が我々の広告収入を奪いに来るのか？どうやってそれが起こり得るのか？』と考えていました。
彼らは『タイピング、タッピング、トーキング』という考え方で世界を見て、『タイピングとタッピングはかなりうまくいっている。人々はデフォルトでテキストを通じて我々のところに来る。でも、トーキングは本当に大きなモダリティだ。人々は一日の大部分を話すことに費やしている。もし検索エンジンとインタラクティブな音声でやり取りする方法があれば、我々がリーダーでない場合、それは本当に大きな問題になる』と考えたんです。
これが、2008年に彼らが投資を始めた理由です。実際、OpenAIのChatGPTなどの他の消費者向け製品のデザインを見ると、少し目を細めて考えてみれば、非常によく似たことをしているのがわかります。
誰か他の人が本当に優れた音声エージェントをリリースすれば、全てのトラフィックがそちらに流れてしまうことを彼らは知っています。だから、防衛的なメカニズムとしてそれを行う必要があるんです。
でも、ここで重要なのは、彼らは他の全ての人のユースケースのために構築しているわけではなく、自分たち自身のために構築していて、『他の人にも売れるかもしれない』と考えているということです。
そして、ハイパースケーラーがよく使う一般的な手法を使います。それは、「これが唯一の方法だ」という大規模なマーケティングを行うことです。今日の技術について私の言葉を鵜呑みにする必要はありません。10年前の技術を見てください。GoogleやMicrosoft、その他の企業が全く同じことを言っていました。
でも、今では彼らは音声やテキスト、その他の分野でAI革命を主導しているわけではありません。彼らはただスタートアップからの攻撃を防ごうとしていただけで、今、自分たちが攻撃されているんです。これが今起きていることです」
「興味深いですね。HackerNewsやRedditのコメントなどでよく目にするのですが、音声検索や音声によるIDE開発など、様々なことについて『それは望んでいない、機械と話すのは嫌だ』といった意見を見かけます。でも、それは現状があまりにも悪いからだと思わずにはいられません」
「そうですね。私自身の例を挙げると、もし私がIDEで『ここがこう書いてあるところを、あれに変更して』と信頼性高く言えて、LLMがその処理を行い、『こういう補足を加えた方がいいかもしれません』と提案してくれるなら、私はそれを喜んで使うと思います。私はそれほど優れたタイピストではありませんし、もっと速くタイプできる人もいるでしょうが、それが一つの要因かもしれません。
私が言いたいのは、音声に対する抵抗が多いのは、まだそれほど優れていないからだと思います。でも、7年前に比べると十分良くなっていて、その可能性は見えてきていますよね」
「その通りです。そして非常に短期間で、合成データや他の全ての要素が積み重なってきたことで、一部の人々が本当に満足するまでそれほど時間はかからないでしょう。
ただし、自分の仕事に深く精通した素晴らしいエンジニアがいて、他の誰かがLLMに話しかけて同じことをやろうとしても、現時点では100%うまくいかないのは事実です。少なくとも今は、それは起こりません。5年後くらいには違うかもしれませんが」
「現在、最も採用が進んでいるのは、中間層の人々ですね。少しコードを書けたり、HTMLを知っていたり、CSSを編集できたり、5年前にPythonでデータ分析をしたことがあるような人々です。彼らは『本当にコードを書いて何かを作りたいと常に思っていた』けど、どこから始めればいいのかわからなかったんです。
『4年間大学に戻って、厳しい道を歩むべきか』というと、将来はそうはならないでしょう。今では、これらのアシスタントエージェントに話しかけるか入力するだけで、物を作ることができます。
ディープグラム社内でも多くの例があります。社員の多くは技術者ではありませんが、これらのツールを使って物を作り、社内の自動化を大幅に改善しています。私たちは100人規模の会社ですが、その自動化のおかげで、規模以上の成果を上げています。
エンジニアや研究者だけでなく、業務担当者などもそうです。彼らは以前はコードを書けませんでしたが、これらの仕組みを通じて学んできました。ただし、コーディングは一例に過ぎません。
より広い視点で見ると、コーディングと同様に、音声によるドキュメント編集や、コマンドライン操作、メール送信など、音声は常に人間とコンピュータのインタラクションの継子扱いされるのか、それとも主要なメカニズムになるのか、お考えをお聞かせください。また、本質的な制限はあるのでしょうか？」
「私はそうは思いません。むしろお気に入りのメカニズムになると思います。ただし、本質的な制限はあります。例えば、地下鉄に乗っている時に、音声でメールをチェックしたり、銀行取引をしたりはしないでしょう。
音声には別の制限もあります。基本的に単一スレッドだということです。そのため、車の運転中や、静かな部屋で一人で、あるいはコンピュータと話すことを気にしない状況など、それが意味をなす状況である必要があります。
だから、全てのインタラクションを音声が占めることになる、これが私たちが今後やることの全てになる、とは考えていません。私たちは引き続き、タイピング、タッピング、トーキングを使っていくでしょう。ただし、それらはかなり均等な重みを持つようになると思います。
デジタルシステムと話すだけで生み出したものが、大部分を占める時が来るでしょう。以前なら10時間かかっていたことが、システムと話すことで1、2時間で済むようになるかもしれません。これは今後1、2年の間に実現することです。そうなると、人々は本当にそれを好むようになるでしょう。
私は既にそうしています。例えば、ディープグラムでの幹部採用面接で、以前は後で注釈を書き留めていましたが、今は面接での会話に集中し、その直後に時間を取って話すようにしています。『この人についてこう思った、こういうことを言っていた、そしてこういったニュアンスがあった』といった具合です。
そういったニュアンスは、以前なら怠け者の私は書き留めなかったでしょう。全てを書き留めるのは大変すぎますから。でも、話すのはほとんど労力がかからないので、全てを話して、AIにノートを取らせ、他の人に渡すことができます。
このようなことが至る所で起きているのを目にしています。マーケティングチームやプロダクトチームが怒るかもしれませんが、こっそり言わせていただくと、私たちは最近、Poisedという会社を買収しました。これは、ミーティングを行う人々のペースを改善したり、『えーと』の使用を減らしたりして、より良いスピーチができるようサポートするアプリケーション分野の会社です。
そのチームの主な課題の一つは、まさにあなたが話していたような機能をこのアプリケーションに追加することです。至る所で機会が見えているからです。私が話していることを書き留めてもらうという、そのアプリケーションは既にディープグラム社内で動作していて、私たちは既にそのアハ体験を目にしています。
だから、これは確実に来ると思います。お気に入りのメカニズムになると思いますが、全てを支配する唯一の手段にはならないでしょう。全てが協調して機能する必要があります。画面は引き続き存在し、タイピングやポインティングも続きます。テキストも引き続き存在します。
でも、音声は元々最初からあったものです。しばらくは電信がありましたが、その後長い間、全てが音声でした。ただ、機械との連携が複雑すぎたため、テキストやデジタルなものが登場したんです。でも、音声が戻ってきました。再び戻ってきたんです」
「そうですね。エージェントについて。あなたが取り組んでいて、期待を寄せているものだと思いますが、その前にそれを定義していただけますか？あなたはコールセンターエージェントという意味合いと、AIエージェントという技術的な意味合いの接点にいらっしゃいますが、エージェントについて考える時、どちらか一方、あるいは少なくとも時間とともに両者の融合を考えておられるのでしょうか？」
「社内での定義は、知覚、理解、インタラクションという完全なループです。知覚があり、理解のステップがあり、そして何らかの形で世界とインタラクションする、つまりデータベースのエントリーを変更したり、音声を生成して人間に話しかけたりする、これがエージェントです。
エージェントの異なる能力や統合は全て非常に異なりますが、これが私たちの考え方です」
「そのループが閉じられることについて、何を見て、何を構築しようとしているのでしょうか？」
「多くのエージェントが構築されることになるでしょう。多くの音声エージェントと、音声以外のエージェントが構築されます。私たちは全てを構築しようとしているわけではありませんし、全てを構築するためのプラットフォームを作ろうとしているわけでもありません。
私たちが最近リリースした音声エージェントAPIは、世界で唯一の音声AIエージェントやAPIになることを意図していません。それは可能性の実証であり、多くのユースケースではそれで十分な仕事ができます。私たちはその分野での成長を既に見ています。
しかし、私たちが本当にやっているのは、開発者が製品、音声製品、最先端の音声製品を構築するためのツールを作ることです。そこに引き続き集中しています。
ただし、エージェントも私たちを前進させます。自社のエージェントを構築する時、それは私たちのモデルも進化させます。これは、先ほど話したモデル構築とインフラ構築のアナロジーに似ています。
自社の音声AIエージェントを構築せざるを得ない時、顧客から要求される前に、あるいは問題や進化する市場として浮上する前に、モデルが何をすべきかを再考することを迫られるんです」
「私たちはそのように考えています。考え方の一つとして、ディープグラムの究極の目標は、世界の生産性を向上させることです。また、私たちは学習する企業だと考えています。
世界の生産性については、経済的な意味で考えています。技術革命が起こると、世界の生産性が向上し、時間とともにそれが全ての人々に広がっていきます。これが私たちの目標です。
また、私たちは学習する企業です。学習するモデルを構築し、人々も学習し、顧客の教育を支援し、顧客の学習を手助けしています。この考え方から、AIエージェントを構築しているのは、私たち自身が学習し、長期的に持続可能な製品を作るためです。
しかし、それは他の人々が構築しているシステムにフィットする、より良い基本コンポーネントを作るのにも役立ちます。私たちの音声AIエージェントは全てのケースに適合するわけではありませんが、知覚レイヤー、理解レイヤー、インタラクションレイヤーはおそらく適合するでしょう」
「つまり、これは能力を実証し、インスピレーションを与えることを意図したフレームワークであって、必ずしも構築しようとしているものを作るために使用する必要のあるツールではないということですね。
最終的に、知覚、理解、インタラクション、これらがあなたたちの提供するものであり、このエージェントツールキットはそれらを全て結び付けて、人々がこれらの体験を作るためにどのように使用すべきかを示す方法なんですね」
「その通りです。両方の機能を果たしますが、ChatGPTを例に挙げると、これはアプリケーションですが、私たちの音声AIエージェントはアプリケーションではなくAPIです。とはいえ、二つの機能を果たします。
一般の消費者が月額10〜20ドルを支払って利用できるという収益面の機能と、何が可能かを教育する機能です」
「どのようなユースケースを人々が構築しているか、あるいはこれらのコンポーネントで何が可能かを示すようなユースケースをどのように想定されていますか？」
「医療分野は今、AIの観点から見ると本当に凄まじい状況です。彼らは多くの分野で人手不足に悩まされていて、ようやく規制面での整理がついて、何を気にすべきで、どうやって実現するかを理解し始めました。
獣医や医療界全般が、患者ケアを支援するためにたくさんのものを構築し始めています。ケアを提供するためではなく、予約を設定したり、来院時に必要なことを教育したり、診察後にどのようにセルフケアすべきかを教育したりするためです。
これは明らかに、急速に成長している大きなユースケースです。フードオーダーは、ファストフード店などのクイックサービスレストランで採用が進んでいる別の例です。
今年後半にいくつか発表がありますが、過去数年間で『機能しない』という発表もありました。でも、これらのシステムは機能します。これらのレストランで注文を受けるだけでも大きなコストがかかっています。年間数十億ドルの収益規模の市場です。絶大な市場というわけではありませんが、その一つのことだけでもかなり大きな市場なんです。
正直なところ、業界特化型の音声AIエージェントが至る所で登場しているのを目にしています。最近のYコンビネーターのバッチや、直近2回のバッチを見ると、本当に多くの異なるアプリケーションが出てきています。
私は、最も基本的なレベルで考えると、全てのテキストボックスには何らかの音声機能が付随すべきだと考えています。ただし、それはテキストボックスを通過する必要がない場合に何ができるかということを考慮に入れていません。そういったことも増えてきています。
「このエージェントフレームワークが具体的に何を行うのか、もう少し詳しく教えていただけますか？以前、技術的な側面でRAGなどについて触れられましたが、それら全てを組み込んでいるのでしょうか？それともLangChainなど、RAGの部分を担う他のものと組み合わせて使用することを想定していて、あなたたちは音声の部分を担当するのでしょうか？」
「完全なシステムです。システムに何が必要かを指定します。プロンプトを入力し、参照文書などを入力し、私たちのシステムを使用してそれを実行します。ただし、使用するLLMを選択することもできます。
しかし、遅延を低く保ち、高可用性で提供するためのインフラを運用しているのは私たちです」
「つまり、開発フレームワークというよりは、インフラ提供が主体ということですか？」
「両方です。常に改善されるモデルが組み込まれていて、思考の終わりなどを改善していきます」
「開発者体験としては、Pythonの開発者がライブラリをインポートし、あなたたちのシステムにデプロイされる成果物を作成する、という感じですか？」
「その通りです。様々な言語用のSDKを提供しています。Websocketを自分で開始したい場合はそのためのドキュメントも提供していますが、複数の言語用のSDKも提供しています。
間もなく、開発者向けの最大級のコミュニケーションプラットフォームの一つと提携する予定です。マーケティングを行ったと思いますが、Twilioです。他にもいくつか発表予定がありますが、彼らと提携して電話番号を取得できるようにするなど、必要に応じて簡単にも複雑にもできるようになっています」
「インフラを提供するとおっしゃいましたが、私がアプリを書いてあなたたちのAPIを呼び出す際、何らかの成果物、例えばコンテナを作成する必要がありますか？SDKがそれを行うのか、それとも他のものを使ってVercelやDigital Oceanなどにデプロイするのか、あるいはあなたたちのところにデプロイして、その部分も実行するのでしょうか？」
「DNAを注入する、つまりプロンプトや関連文書などを注入し、制御構造の一部を提供します。しかし、少なくともエージェントに関しては、あなたのインフラで実行されるものは何もありません。
ディープグラムはオンプレミスでも実行できるので、全てをオンプレミスで実行することも可能です。ただし、それは設計思想ではありません。設計思想は、誰かが何かを言った後、どれくらい待ってから割り込むか、相手が再び割り込んできたらどうするか、といったことを全て考える必要がないということです。
それら全てがフレームワークに組み込まれていて、私たちがホストしています。本当に必要なのは、音声の入力と出力だけです。システムとの接続は完全二重のWebsocketで行い、他の全ては私たちが処理します。もちろん、あなたの仕様に従ってですが」
「つまり、ノーコード・ローコードに近いもので、テキストボックスにプロンプトを入力するような感じで、Pythonパッケージを作成するようなものではないということですか？」
「そういう使い方もできます。例えば、電話に応答するエージェントを作成する場合、発信者の番号から分かるCRM情報をそのプロンプトに組み込むことができます。名前や発信元、注文履歴などが既に分かっているということです。
でも、それをやりたい場合は、通常はコーディングが必要です。Websocket接続を開始する時に、その情報を含む全てのペイロードを含めることになります。そうすれば、エージェントはその情報を念頭に置いてタスクを実行します」
「その部分は典型的なツール使用のモデルのように見えます。つまり、この顧客検索ツールにアクセスできると伝え、エージェントが必要だと判断した場合にそのツールを呼び出す、といった感じですか？」
「はい、ツールは無限にありますが、現時点では限定的な機能で、時間とともに機能を拡張していきます。これは、私たちがサポートできないからではなく、他のシステムでの検索ルックアップを待って10分もコールが中断されることは避けたいからです。
私たちのシステムは高速で準備ができていますが、他のものを待つ必要はありません。そのため、より多くの統合、関係性、パートナーシップを構築して、それを可能にしようとしています。現時点では比較的限定的です」
「良いユースケースの例として、営業時間外の店舗や、営業時間外の多くの店舗をサービスしている場合、ローカル番号に電話がかかってきた時に、ただボイスメールに行くか何も起こらないのではなく、親切なエージェントが電話に出て、店舗や業務内容、営業時間などの情報を提供するというものがあります。
つまり、一日のうち12時間か16時間、誰もいない時間帯でも、電話に応答できる誰かがいるということです。そこから発展させていきます。低い実を摘んで、そこから発展させていく考え方です。
最も複雑な『電話で法律相談に応じる弁護士が欲しい』といったところから始めるのではなく、もっと小さく、シンプルに、複雑さの低いものから考えます。統合が少ないほど、あるいは少なくとも成功の確率が高いほど良いということです」
「素晴らしいですね。スコット、今日は近況をお聞かせいただき、ありがとうございました。また7年も空けないようにしましょう」
「ありがとうございました。お話できて良かったです」