※本記事は、YC Paper Clubによる動画「Going In Deep On Data」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=IfoPg2QefF8 でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
本動画には、司会を務めるFrancois Chaubard氏に加え、3名の登壇者が出演しています。Vincent Sunn Chen氏はSnorkelの創業メンバーの一人で、エージェントのベンチマーキングに関する研究について発表しています。Volo Kuleshov氏はInception Labsの共同創業者で、プロダクション向けの拡散言語モデルについて発表しています。Shayne Longpre氏はMITで博士課程を修了し、多言語モデルのスケーリング則に関する研究「ATLAS」について発表しています。
また、Francois Chaubard氏(@fchaubard)、Vincent Sunn Chen氏、Volo Kuleshov氏、Shayne Longpre氏、およびY Combinator(@ycombinator)の関連アカウントもあわせてご参照ください。
1. イントロダクション:なぜデータが重要か(Francois / YC)
1.1 データ軽視から100億ドル産業への転換
Francois: 今回のYC Data Clubでは、データそのものにフォーカスを当てた回を用意しました。なぜデータがこれほど重要なのか、その原点は私自身の経験にあります。私は2016年に博士課程を中退してFocal Systemsを創業したのですが、当時業界では「データはコモディティだ」という空気が支配的でした。ImageNetのようなデータセットは既に誰でもダウンロードできるのだから、これ以上データを増やす必要があるのかという懐疑的な見方です。Scale AIのシリーズAに投資したVCがいましたが、それ以外のほとんどのベンチャーキャピタリストは、データビジネスの終端価値はゼロだと考えていました。唯一の例外がAccelのLevy氏だったと記憶しています。しかし、それから約10年が経った今、データ関連企業は累計で1000億ドル規模の時価総額を生み出しており、業界の見立ては完全に覆ったと言えます。
Francois: 私はFocalで9年間、深層学習チームを率いていましたが、その間ずっと同じ面接質問をしてきました。スタンフォードやMITから来た非常に優秀な博士たちに対して、「あなたのモデルはホットドッグかホットドッグでないかを判定するタスクでF1スコア85%まで来た。次に何をするか」と尋ねるのです。もし答えが「論文を読む」「ReLUをGELUに変えてみる」「層を増やしてみる」だったら、それは不正解です。正解は「データを見る」ことです。誤検出と誤検知をすべて洗い出し、パレート分析でバケットに分類し、最も大きな問題は何かを特定する。私たちの在庫管理タスク(在庫あり・在庫切れの判定)で言えば、最大の問題は冷蔵庫のガラスに霧がかかって見えない場合や、人が写り込んで商品が隠れてしまう場合でした。こうした問題は、モデルの層を増やしたところで解決しません。
Francois: データの重要性を象徴する逸話として、Andrej Karpathyの話をよくします。彼はImageNetにおける人間レベルの分類精度を、自ら画像を見て判定することで実際に計測した人物です。その結果分かったのは、人間はさほど優秀ではないということでした。私自身、エスキモー犬とシベリアンハスキーの区別すらつきません。ImageNetの3〜4割は犬の品種の分類なのですが、多くの人はその事実すら知らないのです。アーキテクチャが非常に表現力豊かになった今、モデルが何を学習するかを決めるのは、アーキテクチャそのものよりも、学習に使うデータであるという事実がここに表れています。Karpathy自身、博士課程時代はおそらく時間の5%程度しかデータについて考えず、95%はアーキテクチャに費やしていたと語っていました。それが本番環境に持っていく段階になると比率が逆転し、当時で25対75、そして現在ではおそらく3対97までデータ側に比重が寄っていると私は見ています。過去10年間、多くのベンチャーキャピタリストがこの領域を見過ごしてきたにもかかわらず、データ関連企業は1000億ドル超の市場価値を生み出しており、これはYCにとって最良の投資カテゴリの一つになっています。
1.2 データがアーキテクチャより重要になった理由
Francois: なぜここまでデータが重要になったのか。理由は、ImageNetのような綺麗な訓練セットでは訓練分布が非常に美しく整っている一方で、実際に本番環境にモデルをローンチすると、訓練データには存在しなかった分布のデータポイントが次々と現れ、モデルが機能しなくなるという経験を、この場にいる多くの方がしたことがあるはずだからです。経済全体を自動化していく、いわばGDPの評価軸で考えるならば、専門家によるデータと、検証可能な報酬のためのRL環境の両方が必要になります。さらに、コーディングのようにコードが動くかどうかは判定できても、そのコーディングスタイルが良いか悪いか、保守可能かどうかは主観的な判断に委ねられますし、医療の現場では二人の医師が同じ患者に対して異なる診断を下すこともあります。裁判官の判断も同様です。こうした場面で必要になるのが、好み(preference)に基づくデータであり、これは経済活動の大部分を支えているものです。
Francois: データセットやRL環境は、まさに「プロダクト」として捉えるべきだと私は考えています。ArcGIのGregと話したことがありますが、Prime Intellectが打ち破ったゲームひとつひとつに込められた職人技は驚くべきものでした。Focalのような単純な在庫あり・在庫切れの判定タスクでさえ、「商品プッシャー(品出し中で商品を陳列棚の前面に押し出している状態)」をどう扱うかに膨大な時間を費やしました。見た目は商品があるように見えても、技術的には在庫切れであるため、これを独立したクラスとしてオントロジーに含めるべきか、それとも在庫切れとして分類すべきかは、モデルを混乱させかねない非常に難しい判断でした。データは決して単なるzipファイルではないのです。
Francois: もうひとつ私がバッチ業務でよく直面する例として、Salesforceを自動化するケースがあります。仮に100億時間分ものトレースやスクリーンキャプチャを収集し、考えられる限りのデータを手に入れたとしましょう。しかしSalesforceがUIを変更すれば、そのデータはもう使えません。データをどれだけ持っていても、さらに新しいデータが必要になるのです。この事実からも、データの終端価値がゼロになるという予測がいかに的外れであったかが分かります。Brendan Foody(Mercorの創業者)がSequoiaで発表したスライドに、私は強く同意しています。今のボトルネックはアーキテクチャでもGPUでも電力でもなく、データそのものです。その根拠として、私自身がTwitterに投稿した分析があります。ChatGPTを含め、S&P500の7日後リターンを予測させると、市場に出回っているどのAIモデルもランダム(コイン投げ)に勝てないという結果が出ました。もしゴールドマン・サックスのトレーダーによる、ランダムより明らかに優れた判断のトレースデータがあれば、モデルはもっと上手くやれるはずだと私は考えていますが、そうしたデータは現状存在しません。会計士、医師、弁護士についても同じことが言え、人間の能力に到達し、それを上回るには各分野の専門家データが不可欠です。
Francois: では、この状況をどう捉えるべきか。私なりのメンタルモデルを提案します。もし私がAppleのような企業だとして、家まで食料品を届けたり、ブリトーを運んだり、車を呼んで迎えに来させたり、懐中電灯として使ったり、道案内をさせたりしたいのであれば、そのためには「アプリ」というものが必要になります。同様に、LLMを優秀な医師、会計士、弁護士、大工、トレーダー、あるいはセラピストにしたいのであれば(実際にセラピストとしてLLMを使う人は多いのですが)、専門データとRL環境が必要です。最新かつ質の高いキュレーションされたデータがなければ、LLMはそれらの役割を果たせません。「この領域でどれだけのデータ企業が成立し得るか」という問いに対する答えは、「あなたのスマートフォンにいくつアプリが入っているか」とほぼ同じだと私は本気で考えています。さらに踏み込んだ例え話をすると、AppleとAndroidそれぞれに専用のInstacartが存在する意味はあるでしょうか。おそらく一社に統合されるべきです。同様に、Appleが自らInstacartのような食料品配達事業に参入する意味もないでしょう。懐中電灯機能のように簡単に実装できるものはAppleやAndroidが自前で提供して構いませんが、Instacartのような複雑なネットワークを一から構築し、既存の企業と競合するのは、Appleが得意とする領域ではありません。同じ論理で、AI医師を本気で作り込もうとするなら、HIPAA対応をはじめとする専門性の高い領域に深く入り込む必要があり、AnthropicやOpenAI、Google、Appleがそれぞれ個別に優れたAI医師を作るのではなく、医師のネットワークを持ち、事前学習用データや、同一患者に対する複数の対応履歴(あるトラジェクトリと別のトラジェクトリのどちらを医師が好むか、といった比較データ)をキュレーションする専門企業一社に任せる方が理にかなっている、というのが現在の実際の潮流だと私は見ています。
2. Vincent Chen(Snorkel):専門知識のスケーリング
2.1 Data 1.0:手動ラベリングの限界とData Programmingによる解決
Vincent Chen: Francoisの素晴らしい導入に感謝します。データにようやく光が当たる時代が来たことを、私は本当に嬉しく思っています。私はSnorkelの創業メンバーの一人です。最初は社内でFrontier Lab事業を立ち上げ、現在はベンチマークと評価に関する研究をリードしています。今日は「専門家による教師付けをどうスケールするか」という研究テーマについて、この十数年でどう進化してきたかをお話しします。私たちはスタンフォードAI Labにルーツを持ち、10年以上にわたってデータの研究を続けてきました。私たちの中心的なテーゼは、医師、臨床医、ジャーナリストなど、何が良い結果かという基準(スペック)を頭の中に持っている専門家に、その知識をレバレッジする仕組みを与えることこそが、効果的なデータセットを構築する上での本質的なボトルネックだというものです。私たちはフロンティア研究所として、ほぼすべてのグローバルなフロンティアラボやFortune 10企業とデータの課題について提携していますが、そのすべての取り組みは、この「専門知識のスケーリング」というボトルネックに帰着します。専門家の頭の中にある判断力や知識を、どうやって取り出し、実際に使えるデータセットに落とし込むか、これが最初にお話ししたい問題設定です。
Vincent Chen: 専門家による教師付けというプロセスは、raw dataから学習や評価に使える形へと変換する工程であり、これはこの10年で大きく進化してきました。私たちが「Data 1.0」と呼んでいる段階は、質問応答に対するthumbs up/thumbsdown式の好み判定や、基本的なプロンプトと応答のペアといった、基礎的なラベリングでした。1つのラベルを作るのに人間の判断がおよそ30秒程度かかる、という規模感です。しかし現在では、タスクやルーブリック、検証器、そして非常に繊細な採点メカニズムを備えた「世界」そのものをDockerの環境として構築する必要があり、これはエージェントが実際に動作する空間を表現するものです。こうした環境の構築には、人間にとって数時間から場合によっては三桁時間規模の作業が必要になることもあります。専門家は世界に一定数しか存在せず、しかも1日に使える時間には限りがあるという制約の中で、いかに専門知識をスケールさせるかが鍵となります。
Vincent Chen: まずData 1.0、つまり手動ラベリングの話から始めます。これは私たちがSnorkelを始めた当時から今日に至るまで存在し続けている問題だと考えています。Francoisが挙げたImageNetの例のように、手動ラベリングにはいくつもの問題があります。第一に、これはスケールしないアプローチです。1つのデータポイントに1つの手動ラベルが必要というO(n)の関係にあり、データポイントが増えるたびに新たな認知的努力が必要になります。第二に、こうしたアプローチはノイズに対して頑健ではありません。ノイズを減らす唯一の方法は冗長性を導入すること、つまり複数人による再ラベリング(k人による重複ラベリング)を行うことですが、これは仕様やタスク定義が変わるたびにゼロからやり直す必要があることを意味します。そして決定的な問題として、プロブナンス(判断の根拠)が一切残らないということが挙げられます。なぜそのラベルを付けたのか、どういう理屈でその判断に至ったのかが記録されないのです。これが10年前に私たちが直面し、今なお専門領域において存在し続けている課題です。特にMD/PhDや、非常にニッチな専門分野を持つ循環器医のような専門家に、大規模なMRIデータセットや電子カルテ(EHR)データを作らせるのは、事実上不可能に近い作業です。
Vincent Chen: そこで私たちが取り組んだのが「Data Programming」と呼ぶ研究の系譜です。私たちのCEOであるAlexが大学院生だった当時から一緒に取り組んできたテーマで、中心的な発想は「専門知識をソフトウェアとしてエンコードする」というものです。これにはいくつかの利点があります。ソフトウェアのスケーラビリティを得られること、そしてスペックが変化した際にリファクタリングや調整が可能で、批判的に、監査や議論、共同作業の対象にできることです。具体的には、専門家がスパムかそうでないかを判定する際の理由を、ラベリング関数(labeling functions)という形の一連のヒューリスティックとして明示的に表現します。これによって、人の頭の中にある知識を、より再現可能でスケーラブルな形式に落とし込むことができます。ただし、この方法には課題もあります。これらの信号、つまり教師付けのソースは互いに重なり合っており、しかも不正確です。そこで私たちは「弱教師付き学習(weak supervision)」という理論を導入し、信号同士が重なり合い、かつ完全なグラウンドトゥルースとは言えないような設定において、どのように品質を理解するかに取り組みました。こうしてノイズを除去した信号を、ノイズを意識したエンドモデルで学習させることで、初期のラベリング関数がカバーしていた範囲を超えて汎化させることができます。
Vincent Chen: このラベルモデルの直感を、細かい技術的な話に立ち入らずにご説明します。目標は、それぞれの「投票者」の精度を完全に教師なしの形でモデル化することです。私が好んで使う例え話は、クラスに様々なスキルや質を持つ生徒が何人もいて、採点基準(答案の正解)が手元にない状況で、生徒たちの投票結果だけから真の正解を推定する、というものです。これがまさに取り組んでいるモデリング問題の本質です。手順としては、まず各投票者の精度を学習します。次に、これはベイズ的な計算になりますが、それぞれの投票者の実際の投票結果が与えられた条件下での、真の正解の確率を計算します。そして最後に、ノイズを意識したモデルを学習させることで、このラベルモデルのカバレッジを拡張し、より広い分布におけるノイズを最小化しつつ、効果的にスケールさせることができます。まとめると、私たちの初期の研究は、専門家の判断をラベルという形でソフトウェア化することによって専門知識をスケールさせる、というものでした。そこで鍵となったボトルネックは、グラウンドトゥルースが存在しないという条件下で、信号のソースをいかにデノイズするかという点であり、この技術の一部は今なお私たちの本番環境で使われ続けています。
2.2 Data 2.0:SeniorSWEBenchと報酬設計における専門知識のスケーリング
Vincent Chen: 続いて「Data 2.0」についてお話しします。データとフロンティアの進展を支える領域は拡大し続けており、複雑性と重要性の両方が増しています。ここではコーディングを例に取ります。横軸に複雑性、つまりプロンプトやスペックの入力の複雑さ、出力の複雑さ、環境の複雑さ(単純なQ&Aの設定なのか、それともデスクトップへのYOLOアクセスを与えるような根本的に新しい環境なのか)を置き、縦軸にシーケンス長、つまりエージェントが実際に作業を続ける長さを置いてみます。ソフトウェアやコーディングという領域では評価もデータも飽和していると思われがちですが、私はむしろ逆で、フロンティアが進むにつれてデータの課題はますます大きくなっていくと考えています。HumanEvalのような基本的な評価はすでに飽和していますが、それは事実である一方で、ターミナルベースのエージェントは依然として大きく成長を続けていますし、ProgramBenchでは最新のモデルがようやく1%を突破したばかりです。エージェントの複雑性と責任範囲が増すにつれて、モデルを学習・評価するために生み出すデータの重要性もまた増していきます。
Vincent Chen: これを踏まえて、私たちがこの1年ほどで取り組んできた最近の研究「SeniorSWEBench」についてお話しします。私たちは大変光栄なことに、元々のSWEBenchを開発したPrinceton大学のチームと協業する機会に恵まれました。ここでの核心的な問題意識は、私たちはすでにコーディングエージェントをシニアエンジニアのように、バイブコーディングの相手として、コードベース全体のアーキテクチャ判断やリファクタリングを任せるほど信頼して使い始めているにもかかわらず、評価の方法は依然としてジュニアエンジニアを評価するような水準に留まっている、という点でした。そこで私たちが構築したかったのは、実際のシニアエンジニアが手掛けるような業務を本当に代表するベンチマークとデータセットであり、それを構築するために必要な専門知識をスケールさせ、これらの要素を反映した高品質なベンチマークを作ることでした。
Vincent Chen: タスク設計そのものについて言うと、SeniorSWEBenchのタスク設計は、多くの専門家による教師付けの接点を必要とするものでした。従来のSWEBenchのようなコーディングベンチマークのサンプルを実際に見ると、多くが過度に仕様化され、TODOレベルの細かい指示になっています。私たちはむしろ、実際に現場でエージェントとやり取りする際により近い、高レベルで抽象的な指示形式を表現したいと考えました。例えば、Slackメッセージ一本や、ログのダンプをそのまま渡して「これをどうにかしてほしい」と伝えるような形、あるいはアイデアについてのユーザーストーリーをいくつか渡すような形です。つまり、指示そのものに専門性とリアリズムを注入することが、このベンチマーク構築における非常に重要な作業でした。加えて報酬フェーズの設計にも多くの時間を費やしました。ここでの狙いは、単にコードが正しいか、マージ可能かだけでなく、スタッフレベルやシニア、あるいはプリンシパルレベルのエンジニアが完全に監督なしで実際に取るであろう振る舞いを示しているか、つまり「品位(taste)」を示しているかどうかを測定することでした。
Vincent Chen: 報酬設計についてもう少し詳しくお話しします。ここは専門知識のスケーリングという観点で、私たちが創造性を発揮したいと考えた領域でもあります。私たちにはSnorkelのエンジニアや研究者、そして非常に優れたシニア・スタッフ・プリンシパルレベルのエンジニアからなる強力なネットワークがいますが、彼らの時間は無限ではありません。従来の検証器や報酬には、信頼性と柔軟性のトレードオフという軸があります。片方の極にあるのが、事前に書かれた検証器、つまりユニットテストのようなものです。これらはコードベースに対して確実に実行され、実際にコードを動かして確認するため信頼性は高いのですが、あらゆる解法に適応できるわけではありません。例えばユーザー情報を更新する際に、あるPOSTベースの実装と別の実装とで書き方が異なる場合、検証器が過度に制約的だと、本来は完全に妥当な振る舞いを誤って偽陰性としてペナルティを与えてしまう可能性があります。もう一方の極にあるのがLLM judgeです。これは多くの場合、異なる解法の形に柔軟に適応できる非常に効果的な手法で、コードをより柔軟に評価できます。エージェントやLLMにコードを見せて、キャリブレーションされた、あるいはされていない直感で採点させるわけですが、実際にコードパスを実行しているわけではないため信頼性が低く、もっともらしいが誤っている解法を過大に評価してしまう偽陽性を制御するのが難しいという課題があります。
Vincent Chen: そこで私たちが見出した折衷案が「Validation Agent」という考え方です。これは、シニアの研究者やエンジニア、そして私たちのコミュニティにいる専門家の知見を捉えてスケールさせるための仕組みで、二つの役割を担います。一つは、専門家がユーザーストーリーや「何が良い結果か」の仕様を言語化すること。もう一つは、その仕様を使って、実際に解法に関連するコードのサーフェスに対する決定論的なテストを書くことです。これはシンプルなアイデアですが、実現には多くのキャリブレーションと工数を要しました。具体的には、CodexやClaude Codeがある指示セットに対してパッチを生成し、専門家がそれに対して「Validation Spec」と呼ぶものを作成します。これは箇条書き数点程度の、ユーザーストーリーや機能・非機能要件をまとめたもので、特定の解法を過度に規定しすぎないようにしつつ、モデルに何をしてほしいか、何をしてほしくないかの空間を捉えられる程度の抽象度に留めます。次にValidation Agentがそのパッチとバリデーション仕様を受け取り、実際にコードに対して実行される決定論的なテストスクリプトを実装します。最後に、その実行結果とjudgeの両方を使ってスコアリングを行い、実行結果が意味を成しているか、あるいは共謀(collusion)や報酬ハッキングのような、そのトライアルにとって妥当でない振る舞いが起きていないかを確認します。この専門知識をスケーラブルな形でエンコードするというアイデアこそが、特定のコードベースにおける動的な実装にマッピングするValidation Agentの設計の核心でした。
Vincent Chen: 私たちはこのキャリブレーションのために多くの作業を行い、社内および私たちのネットワークにいる特定のテストエンジニアたちとすり合わせを行いました。忠実性(fidelity)、完全性(completeness)、共謀(collusion)といった観点を測定するLLM judgeを導入し、それぞれのテストがパラメータ化される形にしました。Validation Specの中では、完全な仕様や完全なテスト(本来なら数日から数ヶ月かかるもの)を書き切る代わりに、捉えたいユースケースやエッジケースの形をラフに書き出す程度で済むようにしています。このベンチマークは現在も稼働中です。結果についてお話しする前に一点触れておきたいのが、「Tasteful Pass」という新しい指標です。これは単なる正しさやマージ可能性だけでなく、そのコードが実際のコードベースの慣習に沿っているか、シニアエンジニアが実務で取るであろう振る舞いに対応しているか、パッチサイズの観点で無駄な肥大化(bloat)を最小限に抑えられているかといった、より繊細な定義を捉えるための指標です。これを正しさの概念と組み合わせて多数のモデルをランク付けした結果、これは何度も二重三重に確認したのですが、Fable、Opus、そしてSolt(Sonnet)が、先週時点で同率一位という結果になりました。これは非常にエキサイティングな結果で、パレートフロンティアが確実に押し上げられていることを意味しています。このベンチマークはライブのダッシュボードとして継続的に最新の状態に保っているので、興味があればぜひチェックしてみてください。
Vincent Chen: この研究の立役者に敬意を表したいと思います。共同創業者のHenryがリードを務め、元のSWEBenchを率いたPrinceton大学のKaranthikのグループ、そして私たちのチーフサイエンティストでウィスコンシン大学マディソン校にラボを持つFredと、彼の学生たちにも大変お世話になりました。最後にまとめとして、私たちがData 2.0に足を踏み入れるにあたっての要点をお話しします。複雑性はさらに増しており、それに伴ってデータ研究そのものがもっと必要になります。単に人間を大量に投入すれば解決するという問題ではなくなっているのです。ソフトウェアエンジニア、医師、弁護士など、スペックを本当に理解している専門家に、自らの教師付けや判断力を発揮するためのレバレッジを与えるための、思慮深い設計がこれまで以上に求められています。環境はより複雑かつ動的になり、出力はより検証困難で繊細かつ主観的になり、エージェントの自律性もさらに拡張していく。これらすべての軸が複合的に複雑性を増していくというのが、私たちが考えるこの分野の見立てです。ここから、非常に具体的な提案があります。私たちは、より多くのベンチマークが必要だと考えており、これはコミュニティが新しいデータ研究を推進する上で非常にレバレッジの効く方法だと思っています。Berkeleyの「Agents/Exam」、「Continual Learning Bench」、そして「Terminal Bench」といった取り組みに携わる方々と協業させていただき、多くを学ばせてもらいました。私たちはこうした活動をさらに後押しするため、「Open Benchmarks Grants」という仕組みを用意しています。これがコミュニティにとっての一つのリソースとなり、より多くのデータ研究を加速させ、皆さんのデータ開発を支援する研究パートナーとなれることを願っています。Data 2.0時代におけるベンチマークとデータの未来について、私たちは非常に強い期待を持っています。ありがとうございました。
3. Volodymyr(Inception Labs):拡散言語モデルとデータ生成
3.1 拡散言語モデルの仕組みと速度優位性、音声エージェントへの応用
Volodymyr: お招きいただきありがとうございます。今日は、私たちが共同創業者のStefanoやAditya、そして非常に優秀なエンジニアと研究者からなるチームとともにInceptionで取り組んでいる、実世界向けの大規模拡散言語モデルの研究についてお話しさせてください。私たちが取り組んでいるのは、拡散モデルによって駆動される新世代の言語モデルです。従来のようにトークンを左から右へ一つずつ逐次的に生成するのではなく、拡散モデルはまず出力の初期状態、いわばノイズを含んだ状態からスタートし、複数ステップの精緻化(refinement)を経て、全トークンを並列に生成していきます。私たちはこの技術に大きな可能性を感じており、これが言語モデルの未来になると考えています。特に現時点でこのモデルが持つ非常に重要な優位性は速度です。1ステップで複数のトークンを生成できるため、1秒あたりに生成できるトークン数が大幅に増え、1000トークン/秒を超える速度に到達できます。これは従来型の自己回帰モデルでは到底届かない領域です。
Volodymyr: この超高速な推論には、リアルタイムAIにおけるあらゆる応用が考えられますが、私たちが特に力を入れている領域の一つがリアルタイム音声です。カスタマーサポートをはじめ、教育などの分野で、音声を合成してリアルタイムに会話するエージェントが求められています。現在の最先端の音声パイプラインの多くは、依然としてカスケード型のアーキテクチャで構築されています。つまり、音声をテキストに変換する音声認識システムがあり、出力側にはテキストを音声に変換する音声合成システムがあり、その中間にLLMが存在するという構成です。このシステム全体のレイテンシは、このLLM部分に大きくボトルネックされています。LLMが速く動作すればするほど、リアルタイムの音声対話はよりシームレスに感じられるようになりますし、あるいはより大きなモデルをデプロイしたり、モデルにより長く推論させたりすることが可能になり、それが品質の大幅な向上につながります。
Volodymyr: こちらのスライドは、Mercury 2の音声ベンチマークにおける性能を、他のモデルと比較して示したものです。ご覧の通り、Mercury 2はレイテンシと品質の両面で新たなパレートフロンティアを描いています。横軸がレイテンシ、縦軸が品質です。拡散モデルによって、これまでにない新しいパラメータのフロンティアが達成可能になっています。ここでベースラインとして紹介したいモデルがいくつかあります。例えば、Cerebras上で動作する1200億パラメータのGPT-OSSモデルです。拡散モデルであるMercuryは、少なくともここではτ-benchで測定した限りにおいて、そして実データにおいても同様だと私は考えていますが、より高い品質を達成しつつ、より高速に動作させることができます。これは非常にエキサイティングな結果です。Cerebrasのようなチップは、自己回帰モデルを高速に動かすために特別に設計・製造された専用ハードウェアです。しかし拡散モデルであれば、よりインテリジェントなソフトウェアによって、GPU上でも同等の速度を達成できます。つまり、ハードウェアではなくソフトウェアによってモデルを高速化できるということであり、これは非常に大きな意味を持ちます。より入手しやすい、一般的に流通しているGPUの上に、こうしたモデルを数多くデプロイできるようになるからです。
Volodymyr: ただし、良い音声モデルを構築するためには、アルゴリズムと拡散という要素は一つの構成要素に過ぎません。もう一つ、非常に、非常に重要な要素がデータです。モデルの学習にも評価にも、データが必要になります。現在、最も広く使われ、代表的とされる評価ベンチマークはτ-benchですが、これにはいくつかの問題があります。まず、τ-benchは実世界のデータに見られる複雑性の幅を十分に捉えられていません。τ-benchの環境を見てみると、実際にビジネスが行っているリアルなカスタマーサポートの現場に比べて、仕様の数が桁違いに少なく、ツールの数も少なく、本来盛り込みたい種類の仕様が欠けています。さらにτ-benchのもう一つの問題は、ベンチマークが極度にベンチマーク特化(benchmaxed)されてしまっている点です。お気に入りのベンチマークサイトを見に行けば、ほとんどのモデルが90点台のスコアを叩き出しているのが分かるはずです。しかし、同じモデルを実世界の本番ログに対して走らせると、はるかに低いスコアしか出ず、モデルサイズによるばらつきもずっと大きくなります。つまり、性能の高いモデルを構築するためには、アルゴリズムに加えて、データこそが鍵となる要素なのです。
3.2 Tau Forge:リアルなRL環境とタスクを合成するシステム
Volodymyr: 私たちのモデル向けに良質なデータを得るためのアプローチは、「Tau Forge」と呼んでいるシステムに基づいています。これは、τ-benchに似た、幅広く現実的なRL環境を合成するシステムで、実データ、つまり実際のユーザーとのやり取りに基づいて構築されます。このデータは、データプロバイダーから得られるものもあれば、本番環境でこのモデルを使っている提携企業から得られる実世界のデータもあります。このスライドは、Tau Forgeの全体像を要約したものです。Tau Forgeはエージェント型のシステムで、多数の異なるエージェントを協調させるハーネスとして機能し、その出力としてτ-benchに似た合成RL環境を生成します。Tau Forgeへの入力は、生成したい環境の種類の記述です。例えば「銀行業務の環境を生成してほしい」といった指示に加えて、その対象領域における実世界のユーザー利用状況、あるいはそのモデルの実世界での利用状況を表すアーティファクトを与えることができます。最初のステップは、そのデータに基づいて初期環境を合成することです。
Volodymyr: 環境の合成には、例えばその領域でモデルにどのようなタスクをさせたいかを規定する「ポリシー」の生成が含まれます。銀行業務におけるカスタマーサポートをシミュレートするのであれば、その銀行がどのように運営されているか、営業時間は何時か、どのようなユーザーがいるか、どのような口座の種類があるかといったポリシーを生成し、小規模なデータベースを合成することもあります。さらに、このプロセスではモデルがこの環境とやり取りするためのツールも作成します。重要なのは、これがモデルの実際の利用状況に基づいて条件付けできるという点で、これによって、この環境が実際に本番でモデルがどのように使われるかを代表するものになることが保証されます。もし実データが手に入らない場合には、私たちが「ビジネス知識グラフ(business knowledge graph)」と呼んでいるものを用意しています。これはインターネット全体をクロールして構築したデータで、様々な代表的なビジネスの情報を記述しています。これにより、実データを持たない領域についても、インターネットからクロールした実世界の知識に基づいて環境を合成することができます。
Volodymyr: 環境ができたら、次に生成すべき最も重要なものはタスクです。これは、シミュレートされたユーザーがこの環境の中で何らかのゴールを達成しようとし、エージェントがそのゴールの達成を支援するというもので、そのゴールが何であるかを合成する必要があります。この手順では「シードのデータベース」というものから始めます。これは、口座を開設したい、口座を解約したい、電話番号を変更したい、何らかの情報を得たいといった抽象的なシナリオと、モデルとやり取りする可能性のある様々なタイプの人間を表す「ペルソナ」から構成されています。環境がすでにある状態で、このシナリオやシードのライブラリを、別のエージェントを呼び出すことによってその領域向けに特化させ、良質なデータベースができたところで、いよいよタスクの生成に入ります。これらは、あるユーザーがこれらのモデルとやり取りする際の実世界での対話を表すもので、私たちは別のエージェントを使ってそうしたユーザーをシミュレートします。
Volodymyr: 良いタスク群を得ることは、決して自明な作業ではありません。簡単すぎず、かつ難しすぎない、慎重なバランスを取る必要があります。もしモデルが常にそのタスクを解けてしまうのであれば、それは学習にとって有用ではありません。逆に、タスクが難しすぎる場合も、十分な学習信号が得られません。そこで私たちは、モデルがそのタスクをどれだけ解けるかに基づいて、タスクをフィルタリングし再構築する反復的な手順を採用しています。これを実現するために、私たちが「hardening traps」と呼ぶ手法を使っています。これは、タスクをより難しくするために手を加える手法のことです。例えば、ある情報を意図的に取り除いたり、依頼内容をより複雑にしたりすることができます。こうしたあらゆる手法を駆使してタスクを難化させたり、逆に難しすぎるタスクをフィルタリングして除外したりして、現実性と、モデルへの学習信号の提供という二つの要件の間で良いバランスが取れていると感じられる状態に持っていきます。ここでの出力は、あくまでRLタスクであり、これは常に実世界のデータと照らし合わせて継続的に検証されています。この環境は、まずハーネス自体を検証・更新できますし、この環境から生まれたモデルについても、ユーザーからの実世界のフィードバックを得ることができ、そのフィードバックを使ってハーネスや、この合成手順そのものをさらに洗練させていくことができます。
Volodymyr: この手法によって何が達成できるかの一例として、私たちの最新のプレビューモデルであるMercury 2.5を使った実験をご紹介します。このモデルは、特定の領域向けのデータで学習される前の段階では、約50%の精度でした。しかし、Tau Forgeから合成した初期のタスク群でこのモデルを学習させたところ、別の環境群における性能が23%以上向上し、あらゆる最先端のオープンソースおよびクローズドソースのモデルの性能に匹敵する水準に達しました。ここでの設定について補足すると、銀行業務や、例えば航空券の予約、医師の予約を取るといった、多様な業種にまたがる幅広い環境が用意されており、それをテストセットとトレーニングセットに分割します。一方のビジネス群でハイルクライム(性能向上のための試行錯誤)を行い、別のビジネス群でテストを行うことで、過学習を抑えることができます。そして、これらのタスク、特にテストセットは実世界のログから密接に導き出されているため、本番環境に展開した際の実世界の性能と相関するという確信を持つことができます。
Volodymyr: これは、私たちのモデルを本当に高品質なものにするために使える手法のほんの一部をご紹介したものです。単に高速であるだけでなく、音声のような非常に優先度の高い特定の領域における知性そのものを向上させることが目的です。もしこれらのモデルを試してみたい方がいれば、すでに提供されています。1000トークン/秒で動作し、こちらが料金体系です。今回のトークでは主に音声について話しましたが、検索やコードといった他の領域のお客様にもご利用いただいています。こうした領域はすべて、Mercury 2モデルがレイテンシに敏感なタスクに対して非常に強みを発揮できる分野です。もしフィードバックにご興味があれば、私たちのモデルを利用している企業やその他の企業についても、より詳しくお話しできます。トークの後にでも、ぜひお声がけください。最後に一点だけ付け加えると、私たちはスタートアップ向けのプログラムを用意しています。YCに参加している方であれば、50万ドル分のクレジットを提供する用意がありますので、ご興味があればぜひ声をかけてください。もっと詳しくお話しします。ありがとうございました。
4. Shane(MIT / Anthropic):多言語事前学習における言語間転移
4.1 問題設定と言語シナジー測定の実験手法
Shane: ご清聴ありがとうございます。私はMITで博士課程を終えたばかりのShaneです。この5年間の博士課程の中で、この研究が一番のお気に入りのプロジェクトだと思っています。Googleでインターンをしていた際に取り組んだ研究で、TPUを提供してくれたことに感謝しています。私たちが取り組んだのは、多言語事前学習と、その中における言語間の転移、つまり異なる言語という学習データのソース同士のシナジー、干渉、相互作用についてです。この10分間でこのプロジェクトをご案内していきますが、ここで紹介する実験や結果、手法はすべて、言語に限らず一般化できるものだとイメージしていただければと思います。必ずしも言語である必要はなく、異なるドメインや、異なる品質のデータソースであっても構いません。モデルの能力やリスク、限界について考える際、異なるデータの断片がどのように相互作用し、組み合わさっているのかを考えることがますます重要になっているため、この点は重要だと考えています。
Shane: 本題に入る前に、なぜこの研究が重要なのかを、英語を超えた視点から少しお話しします。この研究は今年のICLARで発表したもので、Google、University of Washington、Stanford、その他の素晴らしい方々との共同研究です。現在の文献にあるスケーリング則やミキシング則の論文を見てみると、99%は英語の学習データと英語の評価についてのものです。世界の他の地域やコミュニティについての研究は非常に少なく、これは実際かなり衝撃的なことです。そこで私たちは、目的関数が英語ではない単一言語、あるいは複数言語のクラスターだった場合にどうなるかを考え、その領域を探索することにしました。なぜ英語と事情が異なるのかというと、オンラインで非常に豊富に存在する最初の数言語を超えると、深刻な制約が生じるからです。私たちは、スケーリング則やミキシング則、ファインチューニングか事前学習かといった、開発者が下すべき判断のためのツールと手法の両方を提供しています。これは、自分たちの文化や社会、言語向けにモデルを開発する上で重要な意味を持ちます。例えば、トルコ語のモデルを事前学習する際にどのような制約があるのか、単純にそこにあるデータの利用可能量という観点から、英語ベースの言語モデルと比べてどれだけ遅れを取ることになるのか、そして事前学習においてどのようなシナジーや干渉が予想されるのか、といった問いに答えることができます。
Shane: それでは問題設定からお話しします。非常にシンプルに、ある言語を選んでみましょう。ここではタイ語を選びます。世界に8000万人ほどの話者がいる言語だからです。非常にユニークな言語ですが、スワヒリ語でもポーランド語でも構いません、要点は変わりません。Common Crawlをベースにした人気のある事前学習コーパスであるMadlad 400では、タイ語のトークン数は英語と比較してわずか0.6%しかありません。つまり英語データの1%にも満たない量しかないということです。何らかのフロンティアモデル、ChatGPTでも何でもいいのですが、それが自然言語間でどのような学習ミックスを持っているかは分かりませんが、おそらく他の多言語モデルと同様の分布に大まかに従っているはずです。サンプリング手法などは異なるにせよ、英語が最も多く、その次に比較的豊富で多様性のある言語が続き、そのリストの下の方までいくと、タイ語はミックス全体のごくわずかな断片、6%よりもはるかに少ない割合になっているはずです。したがって、タイ語における性能はかなり低くなることが予想されます。モデル全体としては非常に大規模なため、そこそこ良い性能を示すかもしれませんが、タイ語話者にとって満足のいくものにはならないでしょう。これは文献や評価でも示されている通りです。
Shane: それでは、タイ語だけを対象にモデルを学習させればいいのではないか、と考えるかもしれません。手持ちのタイ語データだけを使って、単一言語(モノリンガル)でモデルを学習させる、という発想です。しかし問題は、タイ語のデータがあまりに少ないため、同じデータを何度も何度も繰り返し学習することになってしまう点です。これがグラフ上の破線、つまりエポックとして表れます。その結果、タイ語データに対して過学習を起こしてしまい、モデルをずっと小さくする必要が出てきます。そしてそれでもなお、良い性能は得られません。理想的には、飛ばして解決策の話をすると、タイ語データを大量に使いつつ、深刻な収穫逓減に差し掛かった段階で、高品質でシナジーのあるデータ、たまたま英語やインドネシア語、マレー語、ラオ語、クロアチア語であったりするデータを組み合わせる、というミックスが望ましいということになります。これはカリキュラムではなく、すべてが混ぜ合わされた形で使われます。ただし、これはあらかじめ言語族が似ているかどうかという理論だけでは分からないことです。むしろ、あるデータが経験的にどれだけノイズが少なく、他のソースが実際に有用であり、似たトピックをカバーしているかという観点であり、これはウェブ上で非常に分散していて不確実なものです。したがって、これは経験的に測定しなければならないことであり、言語学者を連れてきて言語学的な理論を語ってもらうだけでは解決しません。
Shane: では、どうすればタイ語やスワヒリ語、トルコ語について優れたモデルを構築し、正しいミックスと正しいモデルサイズを見つけられるのでしょうか。まず取り組むべきは、言語間のシナジーを測定することであり、これがこの論文の貢献の多くを占める部分です。この測定方法にはいくつものアプローチが考えられますが、私たちが最終的に採用した方法は次のようなものです。学習曲線を思い浮かべてください。学習ステップを横軸に取ったとき、赤い線はタイ語データのみで学習した場合、つまり単一言語の場合を示しています。これはそれなりに良い性能を示しますが、非常に早い段階で頭打ちになります。これを、タイ語と英語を50対50で学習させたモデル、タイ語とテルグ語、タイ語とその他の言語で学習させたモデルと比較してみてください。これらの学習曲線ははるかに高い位置にある、つまりそれほど良くないということが分かります。したがって、これらの曲線の間の距離こそが、その言語がタイ語にとってどれだけ有用かを教えてくれるのです。こうして、例えばインドネシア語は英語より優れており、英語はテルグ語より優れている、といったことが言えるようになります。この距離は「線が長い」ということで示されます。この効率のギャップは定式化することができ、これから細部はすべて抽象化してご説明します。もし二つの線が非常に近ければ、その数値は大きく正の値になります。
4.2 クロスリンガル転移マトリックスの発見とスケーリング則への応用
Shane: もし二つの線が非常に離れていれば、それは負の転移、つまり干渉が生じていることを意味します。これらの言語がトークンやニューロンをめぐって競合し、互いを表現しようとしているということです。これを何度も繰り返し行い、ここでは詳しく触れませんが多くのトリックを使うことで、赤が高いシナジーを、青が高い干渉を示す、大きなクロスリンガル転移マトリックスが得られます。ここでは実際にはご覧いただけませんが、スペイン語の行を拡大してご覧いただけると想像してください。明るい赤のスポットは、経験的にポルトガル語、イタリア語、フランス語であることが分かります。そして最も干渉が大きい、有害な言語は日本語です。つまり、日本語で学習を行うと、それがスペイン語の性能を損なうということです。これはすべて経験的に得られたもので、この中にはいくつかの驚きや興味深い発見が含まれています。ある言語は他の言語よりも広く有用であるということも分かりましたが、全体として非常に複雑な様相を呈しています。このマトリックスのもう一つの興味深い点は、これが固定サイズの言語モデルにおける結果だということです。もし言語モデルのサイズを大きくすると、多くの青の部分が赤、あるいはより深い赤に転じます。これは、モデルが大きくなることで、複数の言語を同時に、あるいは一緒に理解し、その共通パターンを捉える余地が生まれるためにシナジーが増すからです。しかし逆に、モデルが非常に小さくなると、これらすべてが青に転じ、モデル内の限られた領域を奪い合う形で互いに干渉し合います。
Shane: さて、聴衆の皆さんに質問です。もしポルトガル語がスペイン語にとって有用だとしたら、スペイン語もポルトガル語にとって有用だという対称性が、私たちが測定した結果から成り立つと思う方はいますか。手を挙げてください。
聴衆: (一部の手が挙がる)
Shane: それが正しくないと思う方は手を挙げてください。
聴衆: (ほぼ半々に手が挙がる)
Shane: ちょうど五分五分くらいですね。画面上では少し見えにくくなっているかもしれませんが、もう夜も遅いですし。実は、これは対称的ではありません。ご覧の通りです。そして実際には、一種の奇妙な分岐的な構造が生じています。これは重要な点で、もしあなたが実務者として実験を行い、「テルグ語がスワヒリ語にとって非常に有用だ」と分かったとしても、その逆が成り立つと仮定することはできません。実際に測定しに行く必要があります。私たちはこれが崩れることを実証して示しています。
Shane: では次の質問で名誉挽回のチャンスです。二つの言語が同じ文字体系(スクリプト)を共有している場合と、同じ言語族に属している場合とでは、どちらがより有用だと思いますか。言語族に投票したい方は。
聴衆: (何人かの手が挙がる)
Shane: スクリプトに投票したい方は。
聴衆: (多くの手が挙がる)
Shane: それでは、スクリプト派チームの皆さん、おめでとうございます。両方とも影響はあるのですが、トークナイゼーションのアーティファクトと、それがどのように表現されるかという理由から、おそらくスクリプトの方がわずかに重要度が高いです。もし写真を撮っている方がいれば、心配しないでください、すべてオンラインで公開されますので、後ほどそちらをご案内します。
Shane: 残りの3分で、数式について駆け足でご説明します。私たちはこの素晴らしいマトリックスを手に入れました。つまり、言語間の関係を示す一連の数値があるわけです。しかし最後のステップは、これをどうやってスケーリング則に変換するか、つまり、ある目的の言語に対して損失を予測・推定したり、最適な言語のミックスを見つけたりする方法をどう理解するか、というのが私たちの本来の目標です。スケーリング則をフィットさせる必要があります。Chinchillaに馴染みのある方であれば、この式を覚えているかもしれません。モデルサイズと学習したデータ量から損失を予測し、これらの青いパラメータを使ってフィットさせます。しかし、多言語のデータソースがあり、フランス語における性能を知りたい場合、最も重要になるのは、どれだけのフランス語データがあったかということですが、それ以外にも大量の他のデータがあった場合、それをどう組み込むかという問題があります。1次元のデータ量だけでは不十分で、すべてをモデル化する必要があります。
Shane: そこで私たちが行っていることをお話しします。これをモデル化する方法は多数あり、私たちも多くの選択肢を検討しましたが、実際に非常にうまく機能したシンプルな解決策は、ChinchillaのDを、単一言語の転移言語(この場合はタイ語というモノリンガルのソース)、マトリックス上で近接する転移言語、そしてそれ以外すべてを含むバケットという複合要素に分解するというものです。細かい話をすると、特定のデータを複数エポック回す際の収穫逓減も考慮に入れています。多くの詳細がありますが、要約すると、こういった形になります。そして、この"tau"のようなものが、マトリックスから学習できる重み付けの要素になります。時間の都合上、駆け足で進めますが、表の中で太字の数値、つまり最先端(state-of-the-art)の結果が得られています。うまく機能しています、本当に。おそらく多くの人が700回もの事前学習実験を回すことができないから、あるいはこの領域が十分に研究されていない(underserved)からだと思いますが、いずれにせよ、これは複数のソースを混合し、それらがどのように相互作用してモデルの最終的な損失を予測するかを理解する上で非常に有用な仕組みだと考えています。また、手持ちのリソースに応じてモデルをどうスケールさせるべきかを理解する上でも役立ちます。
Shane: 最後にまとめます。私たちは、多言語対応の大規模な事前学習済みモデルが手元にある場合、それをファインチューニングすべきか、あるいは自分が関心のある言語向けにゼロから事前学習すべきかを判断するための実験を行いました。どちらを選ぶべきかは、手元にある計算資源の量に応じてお伝えできます。また、「多言語性の呪い(curse of multilinguality)」についても検討しました。もし4言語対応の言語モデルのサイズを大きくして、8言語に対応させたい場合、以前と同じ性能を維持するためには、どれだけ多くのデータが必要で、モデルはどれだけ大きくする必要があるのかという問いです。私たちはこれについて多くの計算を行いました。非常に興味深い結果で、実務者として正確に何をすべきかをお示ししており、実際に異なる目的言語に対しても非常によく当てはまることが分かっています。ですので、興味がある方はぜひこの研究を参照していただくことをお勧めします。ありがとうございました。ご清聴に感謝します。