データの規模がすべてではない

By ilian Herzi2025-07-212 min readCategories: Blog Post

これは人間が書いた文書の自動翻訳版です。

英語のオリジナルを読む
インテリジェントなデータ選択と品質指標比較を伴う大規模な未フィルタリングデータセットを示すデータ可視化

TL;DR

AI企業のドグマは、より多くのデータがより良いパフォーマンスにつながるというものですが、実際にはデータスケールがすべてではありません。

  • 高品質なデータは、より大規模な低品質データセットと比較して、より良いパフォーマンスをもたらします。
  • 高品質なデータを生成するには、ノイズをフィルタリングし、ラベル付けされていないデータを理解し、何をラベル付けすべきかを理解する必要があります。
  • アノテーションプラットフォームによる大規模なデータラベリングも問題があります。なぜなら、彼らのインセンティブはしばしば一致しておらず、彼らのプラットフォームは時間がかかり、エラーが発生しやすく、コストがかかるボトルネックとなるからです。
  • AIシステムを改善する最良の方法は、自己教師あり表現学習、基盤モデリング、フィルタリングを使用して、インタラクティブな方法でデータセットをインテリジェントに表現することにより、モデルに供給されるデータを理解することです。
  • これらの実践は、AIシステムにおける低パフォーマンスのリスクと、有害な出力を生成するリスクを防ぎます。

少ないほど豊か

データ規模がすべてではありません。モデルの事前学習中にデータセットのサイズを盲目的に増やすことは、AI優先企業に深刻なエラーを犯すリスクをもたらします。未知の分布を持つ大規模データセットでモデルを訓練すると、予期しない動作につながります。ロボティクスでは誤った危険な軌道、医療企業では不正確なリスク評価、LLMでは有害な発言生成につながる可能性があります9。X上で、Grokはこの過ちを犯し、図0aに示された現在削除された投稿で有害な発言を生成しました。xAIのCEOでさえ、「インターネット全体で訓練するのではなく、訓練データについてもっと選択的になる必要がある」と認めています。しかし、これらのモデルを適切に訓練し評価するために、どのようにデータを適切に選択すればよいのでしょうか?どのようなツールがあるのでしょうか?

解決策は、データをインタラクティブで意味的に十分に多様な形式でインテリジェントに表現することです。このアプローチは次のことに役立ちます:1. 事前学習と事後学習の両方のための訓練データセットと評価データセットの作成、2. データの穴の特定、3. それらのギャップを埋める方法(購入または収集)に関する推奨事項の作成。


Figure 0a: Examples of an LLM generating harmful speech likely due to existence of similar text in the training data the xAI team used to train Grok.
Figure 0a: Examples of an LLM generating harmful speech likely due to existence of similar text in the training data the xAI team used to train Grok.

Figure 0b: Reaction from the xAI CEO after Grok generated harmful speech. The interesting piece is the teams focus on being selective of the training data. Original post from the Grok CEO
Figure 0b: Reaction from the xAI CEO after Grok generated harmful speech. The interesting piece is the teams focus on being selective of the training data. Original post from the Grok CEO https://x.com/elonmusk/status/1944132781745090819

データフライホイールとアノテーション企業

業界では、AI企業のCEO、AI研究者、エンジニアのほとんどが、データフライホイールに統合される現代のアノテーション企業に不満を抱いています。

AI企業の現在の一般的な解決策は、事前学習用の大規模なラベルなしデータセットを蓄積し(またはオープンソースの事前学習済みモデルを使用し)、次に意図されたタスクに特化した別の大規模データセットにラベルを付け、最後に訓練セットと評価セットを手作業でキュレーションすることです。ラベリングは通常、データエンジンに統合されるアノテーション企業(ScaleAI、SuperAnnotate、Labelboxなど)に外注されます。しかし、大規模データセット内のすべてにラベルを付けることはうまく機能しません。なぜなら、データラベリングを数百万または数十億の例にスケーリングすることは、エラーが発生しやすく、持続不可能なほどコストと時間がかかり、AI企業を不満にさせるからです。さらに重要なことに、ラベリングループは終わりのないプロセスです。データフライホイールは進化するモデルとより多くの収集データに継続的に適応し、ラベリング要件が流動的で時間とともに変化するため、アノテーション企業は変化の速度に追いつくことができません。モデルの更新は数週間で行われる一方、ラベリングには数ヶ月かかる可能性があります。

データエンジンにおける現代のラベリングループは次のとおりです:

  1. データを収集する。
  2. ラベリング仕様を設計または更新する。
  3. データと仕様をラベリング企業(Scale、SuperAnnotateなど)に送信する。ラベリングの料金を支払う。
  4. ラベリング企業と反復し、モデルを訓練する。
  5. 結果を観察し、ステップ2〜5を無期限に繰り返す。

たとえば、自動運転企業は一時停止標識にラベルを付けたいと考えるかもしれませんが、100万個の一時停止標識にラベルを付けて結果を見た後、一時停止標識の「視認性」にラベルを付けたいことに気づき、次に一時停止標識の周りにある可能性のある木にもラベルを付けて「隠蔽」ラベルを追加したいことに気づきます。今やすべてのデータ(データ収集は継続的であるため、その間に増加しています)に再ラベル付けが必要です!企業がモデルを改善している間、このサイクルは決して終わりません!

MetaがScale.AIのCEOを雇用するために49%の株式に143億ドルを費やしたこと11は、ラベリング企業とのこれらの困難のために、同社がこれまでに行った最もリスクの高い動きの1つかもしれません。

では、膨大なデータセットで盲目的に訓練することが問題であり、すべてにラベルを付けることが困難である場合、他に何をすべきでしょうか?この問題に過去4年間取り組んできた結果、私たちが見つけた最良の解決策は、データ内に何があるか、そのデータがモデルにどのように影響するかを選択し理解しやすくなるように、データを十分に表現することです。例を素早く検索し、モデルをテストするための評価セットを素早く構築できる方法で、データとチャットできるようにすべきです。

それが私たちがInterpret AIで構築しているものです。私たちは、AIシステムを構築する企業がデータセットとやり取りし理解できるようにする、データ内省プラットフォーム、データキュレーションプラットフォーム、インテリジェントデータマーケットプレイスを構築しています。私たちは、自然言語、音声、画像、動画を使用してデータとチャットし、類似のインスタンスを検索できる世界を思い描いています。これにより、企業はモデルを動かすデータ(またはデータのギャップ)を信頼し、知ることができます。

まず役立つ可能性が高いものをスケールする

従来のデータフライホイール

Figure 1a: The traditional data engine powering AI solutions in companies.
Figure 1a: The traditional data engine powering AI solutions in companies.
  1. 企業には、データセットにデータを継続的に収集するインフラストラクチャがあります(1b)。次に、チームはラベル付けされればモデルを改善するであろうヒューリスティックなデータサブセットを作成します(1a)。
  2. データはラベリング(アノテーション)企業に送信されます。ラベリング企業はラベル(アノテーション)を生成し、チームによってレビューされます。これには収束するまでに数ヶ月のやり取りがかかる場合があります。
  3. 次に、事前学習済みAIモデルが事前学習されます。
  4. 事前学習済みモデルは、ラベリング企業からのラベルを使用してファインチューニングされます。
  5. 最終モデルは、企業の評価システムを使用して評価され、メトリクスが生成されます。
  6. 次に、企業はこのフィードバックを使用して、他のデータサブセットを選択したり、ラベリング要件を更新したり、モデルの変更を行ったりします。この時点で、データセットサブセットはすでに古くなっていることに注意してください。

注:メトリクスは、不適切なアノテーションによって歪められる可能性があり、チームからの継続的な反復が必要であり、コストと時間の両方で非効率的です(6)。


Figure 1b: A breakdown of the time requirements for different processes in a traditional company’s approach to solutions. Notice that the major bottleneck is getting labels from a labeling company.
Figure 1b: A breakdown of the time requirements for different processes in a traditional company’s approach to solutions. Notice that the major bottleneck is getting labels from a labeling company.

図1b:従来の企業のAIシステムの時間的制約とセットアップ、各部分を独立して反復するためのおおよそのタイムライン。ラベリング企業がループに入ると、AIモデルを適切に改善するラベルを生成するのに数ヶ月の反復がかかることに注意してください。これらの各部分が従来の企業とどのように相互作用するかについては、図1aを参照してください。


Interpret AIのデータフライホイール:深いデータインサイトで知ることから始める

Figure 2a: Interpret’s AI data flywheel & how we provide immediate data insights.
Figure 2a: Interpret’s AI data flywheel & how we provide immediate data insights.

図2a:Interpret AIのデータフライホイール。

  1. 事前学習と訓練のための即座のデータサブセット推奨と強化されたデータ提案(それぞれ1aと1b)。
  2. チームは現在、ラベリング企業に送信する前に、Interpretによって提案された大幅に小さいデータサブセットをレビューします。これらのデータサブセットは流動的で、データの変化に応じて継続的に更新されます(オプションで、企業がベースラインモデルを統合する場合、Interpret AIはデータがモデルパフォーマンスにどのように影響するかについてより多くのインサイトを提供できます)。
  3. ラベリング企業とのやり取りは、数ヶ月から数週間に短縮され、アノテーション仕様とデータセット選択が明確であるため、大幅に安価になります。
  • フィードバックはモデルに焦点を当てています(6)。
  • 最後に、Interpret AIはデータスペースを分析して、モデルの改善を加速するために収集または購入するデータに関するインサイトを提供します。
Figure 2b: A breakdown of the time requirements for different processes in using Interpret’s platform. On the left hand side feedback iteration speed in green is accelerated. Notice there is no more bottleneck.
Figure 2b: A breakdown of the time requirements for different processes in using Interpret’s platform. On the left hand side feedback iteration speed in green is accelerated. Notice there is no more bottleneck.

図2b:この図は、Interpret AIが顧客と直接統合して、モデル訓練、データトリアージと理解、評価を加速する方法を示しています。Interpret AIは次のソリューションを提供します

  • 既存のデータ分布の理解。
  • データギャップと相関するモデルギャップの特定。
  • データギャップを埋めるためのデータの購入とキュレーション。

ユースケース

私たちは、ロボティクス、医療、エージェンティックLLM業界の複数の企業と協力しています:


医療

HealthCoは、患者の心血管疾患のリスクを予測しようとしています。

訓練用

  • Interpret AIは、解釈基盤モデルを使用して心血管データを分析し、EHR、画像、利用可能な場合はECGデータ12を処理します。
  • Interpret AIは、HealthCoの異常または「穴」に気づき、これらの人々の人口統計を説明します(つまり、女性、中年、子供なし、歴史的にトリメタジジンを処方されている)。
  • これらの検出された記録は、専門家によってさらに分析されます。選択されたデータは、更新、無視、歴史的にトリメタジジンを処方された人々のより多くのデータの購入を支援するために使用、またはこの特定のグループにアノテーションを付けるためにラベリング企業に送信できます。
  • 選択されたデータは、AI心血管疾患モデルの訓練に使用されます。HealthCoが心血管モデルをInterpretプラットフォームに統合すると、モデルがリアルタイムでパフォーマンスが低い場所をさらに分析し、即座の内省が可能になります。
  • このプロセスにより、モデル訓練のタイムラインが数ヶ月から数週間に短縮され、AIシステムが急速に改善され、コストが節約されます!

安全性のため

HealthCoに心臓発作を起こした人々の例があり、同様にリスクがある可能性のある他の人々のEHRを分析したいとします

  • Interpret AIを使用して、HealthCoはこの人の例を選択し、関連する人々のプールを検索し、信頼度で並べ替えることができます。
  • これらの人々はリスクありとしてフラグを立てることができ、数百万の記録からリスクのある数百人を迅速に特定できます!

ロボティクス

DriveCoは、子供たちが外で遊ぶためのおもちゃとして自律レースカーを構築しています。

訓練用

  • Interpret AIは、収集されたレースカービデオデータの実行を分析します。Interpret AIはデータレポートを提供します。
  • Interpret AIは、ビデオからのリプレイの大部分が地理的に多様ではなく、裏庭の屋外を走行するレースカーの例がほとんどないことに気づきます。
  • Interpret AIは、DriveCoチームに屋外ビデオのより多くの例を収集することを推奨します。また、この不均衡を軽減するために、Interpret AI基盤モデルを使用して学習された方法でデータセットのバランスを取ろうとします。
    • Interpret AIがなければ、DriveCoは必要のないオブジェクトにラベルを付けるために1000時間以上のレースカーデータを送信していたかもしれません!今では10時間だけラベル付けする必要があります!

安全性のため

これらの自律レースカーが乳児の安全性について精査されているとします。

  • DriveCoは、「赤ちゃん」を含むビデオをデータベースで検索して、このデータがあるかどうかを確認できます。
  • DriveCoがデータを持っていない場合、これはチームにそれを収集するよう通知します(おそらく偽の赤ちゃんを使用することを願っています)、またはこれによりDriveCoは消費者と投資家に製品が実際に赤ちゃんの周りで安全であることを示すことができます!

私たちがここに至った経緯

ラベルと事前学習に関する簡単な歴史

2015年、Transformer以前、ほとんどのモデルは非常に特定の問題のサブセットを解決するために訓練されていました:分類、セグメンテーション、物体検出(つまり基礎的な問題)など[1]。ベンチマークは、10kから1Mのオーダーの「やや大きい」ラベル付きデータセットでした。1

現代の事前学習は2017年頃に登場し、ゲームを変えました。表現学習から借用して、事前学習は基本的なパラダイムシフトとして登場し、突然ラベルなしデータセットがモデルパフォーマンスの大きな向上を解き放ちました。事前学習に使用されるラベルなしデータセットは、ラベル付きの兄弟と比較して大規模でした[5]。これは他の技術と進歩2と組み合わさって、CLIP[13]、DALL-E[14]、DINOv2[15]、BERT[16]などの現代の基盤モデルにつながりました。

次に、OpenAIは、Transformer、事前学習、強化学習の進歩の基盤の上に構築され、GPT(生成事前学習済みTransformer)[6]をリリースしたときにゲームを変えました。Sora[7]、DeepSeek[8]、Anthropic[9]はすべて、パフォーマンスの高いモデルのバックボーンとして大規模データセットでの事前学習を使用しています。しかし、その中に隠されているのは、ほとんどの人が話していない鋭い観察です。

事前学習は良い最初のステップですが、これらのモデルのほとんどは、事前学習済みベースの上にさらなる訓練が必要です。これがRLであろうと教師あり微調整であろうと、最もパフォーマンスの高いモデルは、元の問題に何らかの形で整合3されています。しかし、微調整でさえある程度までスケールするため、事前学習の改善は将来のモデルパフォーマンスに不可欠です4。

文献で事前学習を適切に統合し、データフライホイールを構築する方法の最も説得力のある例の1つは、MetaがSegment Anything Model(SAM)とSAM v2[10]で構築したラベル付きデータフライホイールです。しかし、この例でさえ、データラベリングはスケールすることが非常に困難です。

Segment Anything:イノベーションとメッセージ

要約:SAMが示すのは、品質保証とデータ内に何があるかを理解することは困難ですが、対処すべき重要な問題であるということです。より多くのデータを追加することは必ずしも答えではありません。

SAMは、訓練のさまざまな段階で部分的に訓練されたSAMを人間のラベルフィードバックとともに使用して、大規模なラベル付きデータセットをキュレーションするデータフライホイールを構築しました。彼らのアプローチは、ラベリングをパイプラインに統合する適切な方法を示していますが、適切なデータラベリングフライホイールでさえコストがかかりスケールが困難であることも強調しています。ある時点で、データセットは十分に大きくなり、人間がすべてにアノテーションを付けることができなくなり、したがって他の内省方法(つまり、Interpretが構築しているもの)が必要になります。

大まかに言えば、SAMのアプローチは次のとおりでした[10]

  1. MAE事前学習済み階層型ViTから始める。
  2. 公開されているセグメンテーションデータセットでSAMを訓練する。
  3. 部分的に訓練されたSAMを使用して、データサブセットでセグメンテーションマスクを生成する。
  4. 人間にセグメンテーション予測を洗練させる。次に、マスクを使用してオブジェクト検出器を訓練し、より多くのオブジェクトを見つけ、人間にそれにラベルを付けさせる。
  5. ステップ3〜4を繰り返し、データセットのサイズを徐々に増やす。
  6. 10億枚の画像で実行してSA-1Bを取得することで終了する。QAチームを使用して、潜在的に悪い例にフラグを立てる。10億枚すべての画像に人間のラベルを提供することは非常に困難であることに注意してください。

SAM 2のアイデアも同じで、これはビデオセグメンテーションモデルであり、50.9Kビデオにわたって3550万マスクを持つSA-Vデータセットを生成し、どのビデオセグメンテーションデータセットよりも53倍多くのマスクを持っています[10]。

最高のセグメンテーションモデルは、ラベルフィードバックがすべて迅速で効率的なデータフライホイールで適切に結合されたタスクに直接関連するデータで訓練されたことに注意してください。事前学習してから、オープンソースのセグメンテーションデータセットのコレクションで訓練することは、最初と2番目のステップにすぎませんでした。

また、人間のラベリングが最終的に天井に達したことにも注意してください。データフライホイールが10億枚の画像のラベリングを開始したとき、Metaは依然として悪い例にフラグを立てるためにQAフィルターを実行する必要がありました。論文に基づくと、11億マスクすべてにアノテーションを付けるには51,000日のアノテーション時間がかかったでしょう!5

これはMetaの話ですが、ほとんどの企業にとってそれを雇うことは法外に高価で実行不可能でしょう!6この規模でのラベリングは単に困難です!

要約を繰り返すと、SAMが示すのは、品質保証とデータ内に何があるかを理解することは困難ですが、対処すべき重要な問題であるということです。これは、今日の業界で見られる根本的なギャップです。事前学習または微調整に使用されるより多くのデータは必ずしも答えではありません。適切なアプローチは、モデルがどこで苦しんでいるかを特定し、なぜそこで苦しんでいるかを理解し、問題に関連するデータ(またはデータギャップ)を強調することです。これが私たちがInterpret AIで行っていることです。

アノテーション企業の目標は必ずしもあなたの目標と一致していません...

私たちはMAANGでの業界経験があり、私たちのチームはScale、SuperAnnotateなどのアノテーション企業と協力した経験があります。ほとんどのラベリング(アノテーション)企業にとって、ビジネスモデルは次のとおりです:

  • 企業に、ラベルの複雑さに応じて、おそらくいくつかのやり取りを伴って、独自のラベリング(アノテーション)仕様を生成させる。
  • ほとんどのアノテーション企業には、アノテーターの異なる階層があり、最大のプールはすべてにラベルを付ける非専門家であり、最小のプールはその分野の専門家(つまり医師)です。次に、アノテーション企業は人間のラベラーのプールを編成し、通常は最も安価なものから始めて、低品質の最初のパスを行います。
  • 次に、アノテーターは、企業の複雑なアノテーション仕様に従って、できる限りラベルを付け、アノテーションごとに課金します。
  • アノテーションにフィードバックと更新を提供し、場合によってはアノテーション仕様を更新します。

このプロセスには4つの主な問題があります:

  1. アノテーションは一貫性がなく、通常は適切なラベラーに割り当てられません、
  2. ラベリングは時間がかかり高価です、
  3. アノテーションを修正するためのフィードバックループは誤りがあります、そして
  4. アノテーション仕様は、モデルパフォーマンスの変化に応じて時間とともに変化します。

1.に対処すると、ラベラーは割り当てられたラベリングタスクに適しているとは限らず、しばしば同僚とは異なるラベル付けを行います。たとえば、医療企業の場合、タスクが「患者を最もよく診断する臨床応答を選択する」である場合、これらのラベラーはタスクに適した医師でさえないかもしれません!さらに、自動運転企業の場合、タスクが「一時停止標識の境界ボックスを描く」である場合、これにはポールが含まれますか?一時停止標識の裏側の場合はどうですか?異なるアノテーターは、互いに相談することなく異なるラベル付けを行います。

2.に対処すると、アノテーションごとに課金することは理論的には素晴らしいように聞こえます。従来の教義では、より多くのラベルが役立つとされていますが、企業がモデルパフォーマンスを向上させるのに十分な数のラベルのコストを負担できる場合に限ります。この数は通常不明です。これらのアノテーションには通常エラーがあり、AI企業はアノテーションをレビューする内部システムを構築する必要があり、時間(数ヶ月のオーダー)とより多くのお金がかかります。

3.に対処すると、フィードバックループも一貫していません。通常、アノテーション検証の責任はAI企業に押し付けられ、独自の内部監視システムをセットアップする必要があります(すでに時間がかかりコストがかかります)。AI企業がアノテーションの問題に気づいたとき、修正は問題のあるラベルを作成した同じアノテーターからのものであるとは限らず、アノテーション企業は修正する代わりに問題のある例全体を再ラベル付けすることがあり、これにはより多くのコストがかかります。たとえば、自動運転企業は信号機と人のインスタンスマスクにラベルを付けたいと考えるかもしれません。このダミーの例では、最初のアノテーターがミスを犯し、カメラに向いていない信号機にラベルを付けるのを忘れます。AI企業はそれにフラグを立て、再レビューのために送信しますが、アノテーション企業がこれを修正する方法は、画像を新しいアノテーターに送信し、すべてをゼロから再ラベル付けすることです!2番目のアノテーターは元の問題を修正しますが、警察官を「人」としてラベル付けせず、新しい問題が発生します!図3aと図3bを参照してください。このループは、オブジェクトを正しくラベル付けする確率が非常に低く、50ラベルで約61%です7。


Figure 3a: First pass by the first annotator who missed the traffic lights that are not facing the camera. (Image from Waymo Open Dataset [17])
Figure 3a: First pass by the first annotator who missed the traffic lights that are not facing the camera. (Image from Waymo Open Dataset [17])
Figure 3b: Second pass from the second annotator who got all the traffic lights but didn’t realize that the “people” class included police officers! (Image from Waymo Open Dataset [17])
Figure 3b: Second pass from the second annotator who got all the traffic lights but didn’t realize that the “people” class included police officers! (Image from Waymo Open Dataset [17])

本質的に、このフィードバックシステムでは、アノテーション企業が作成するラベルが正しいラベルに収束することは保証されていません!

AI企業のインセンティブは、ラベリング企業のインセンティブとうまく一致していません。AI企業はAIモデルと製品を改善したいと考えていますが、アノテーション企業はできるだけ多くの企業データにラベルを付けて課金したいと考えています。あなたはモデルをパフォーマンスの高いものにしたいと考えており、アノテーション企業もそうすべきです。

4.に対処すると、業界(および研究)では、問題を解決しようとするとき、多くの可能な解決策があります。おそらく、インターネット全体で事前学習するとLLMが改善されるか、ラベル付きテキスト画像ペアで訓練することでLLMを基盤化するとLLM推論に役立つか、思考の連鎖を追加すると役立つかもしれません。言い換えれば、AIシステムを設計するとき、最良のアプローチが何であるかが不明な場合があるため、並行して多くの異なることを試す必要があります。ラベリングは1つの解決策であり、問題をよりよく理解するにつれて、ラベル定義は変更される可能性があります。

たとえば、自動運転で一時停止標識にラベルを付ける場合を考えてみましょう。最初に一時停止標識にラベルを付けるとします。一時停止標識が部分的に隠されているかどうかがわかると、パフォーマンスが向上することに気づくので、標識が部分的にまたは見えない場合に「隠蔽」と呼ばれるメタデータタグを追加するようにアノテーション仕様を更新します。次に、アノテーション企業に戻り、これですべての一時停止標識を再ラベル付けするよう依頼します!この「ループ内のアノテーションプラットフォーム」は、ラベル付きデータセットを更新するすべてのモデル実験が非常に高価であることを意味します!

では、なぜラベリングプロバイダーがまったく使用されるのか疑問に思うかもしれません。2つの理由があります。第一に、データに関する高品質

Conclusion

The optimal data flywheel represents data in a form that’s inherently insightful and interactable: we should be able to detect anomalies and also chat with our data to garner interesting patterns and insights. This flywheel should enhance annotation platforms by focusing on what should be labeled instead of labeling everything 8. And finally, this data flywheel should align with model performance, tying directly to whatever problem your AI company is solving.

The traditional dogma is that more data “just works” and sometimes deep learning feels like alchemy. Perhaps more data will work for you in the short run but when things “just don’t work” the proper way is to assess failure both in the data & the model and work from there.

Footnotes

  1. Back when AlexNet was still a thing circa 2015ish most models for computer vision were trained on a subset of very particular problem types: classification, segmentation, object detection (ie foundation problems) and others like image captioning, scene recognition, pose estimation (see appendix for more details)[1]. Note this was pre “Attention is all you need” when bigrams were a-la-mode. The focus then was model development while benchmarks remained fixed. These benchmarks were “largish” labeled datasets (order of 10k to 1M) that were used to evaluate model performance. Some of the popular CV benchmarks you’re probably familiar with are MNIST, ImageNet, MS COCO, KITTI, Caltech-101 [2]. If you look the largest labeled datasets around this time they were around 1M labels, and that was considered large at the time.
  2. Modern pretraining entered the chat around 2017 and changed the game. Borrowing from representation learning, pretraining came as a fundamental paradigm shift from learning features for only a specific labeled dataset to learning general features on unlabeled data that correlated well with other problems like classification, segmentation, object detection. These datasets compared to their labeled brethern were massive [5]. At the same time, advancements in model training (CUDA optimization which is why NVIDIA hit a 4T market cap), deep learning libraries (tensorflow, pytroch), and new / improved model architectures like Transformers from “Attention Is All You Need” opened up a brand new world. Researchers also noticed that increasing the size of models typically correlated with improved performance on unseen data (from the same data distribution). All of this combined interfaced with modern pretraining algorithms like pretext tasks, contrastive learning, masked label modeling, masked autoencoding (MAE) multimodal modeling [4] unlocking the era of training big models on even massive unlabeled datasets. Ergo, models like CLIP [13], DALL-E [14], DINOv2 [15], BERT [16].
  3. ”Alignment” is an overused term I mean alignment in both the “we want our LLM to be helpful not harmful” sense and the “data distribution alignment” sense.
  4. When training / fine-tuning a model, scaling model size correlates with improvement in performance roughly following a power law. In industry, we’re already hitting the peak for model size scaling laws and fine-tuning is giving less and less of an advantage. The next frontier is improving pretraining method to better utilize existing unlabeled datasets.
  5. In the SAM paper, annotations could take 30 seconds (but suppose it took 4 seconds based on the improvements from SAM v2 [10]); reviewing 1.1B masks would’ve required 1,100,000,000 * 4 seconds = ~51,000 days of annotation time!
  6. This is also assuming that the data distribution is stationary (unchanging). If we wanted to increase the labels to a different data distribution (say deep sea diving videos where the semantics & dynamics of objects is different) then finetuning SAM would still require the same data flywheel training process which is also more time and more money.
  7. Suppose that each object has a probability of being mislabeled p=0.01 (ie an annotator labels incorrectly or misses a label once every 100 labels). Assuming 50 objects in a video the probability of succeeding assuming independence is (1 - p)^50 = 61% chance of success! And that’s conservative.
  8. Fundamentally, when AI companies have better clarity on what to label their incentives align with annotation companies.
  9. More and more it is clear very few samples (e.g. thousands) of very high quality data is way better than million of low quality data - this is particularly true in post-traning of LLMs in industry but it is starting to be the focus also of pre-training.
  10. A data flywheel is the loop used to collect data, improve the model, which makes a better product, which then modifies what data to collect and the cycle repeats (for example this image from dataloop.ai https://dataloop.ai/book/the-data-flywheel-effect/). A data engine is the infra for collecting/labeling/evaluating data (for example Scale’s product https://scale.com/data-engine).

Special Thanks

  • Cameron Tukerman-Lee (also credit for the title)
  • Gabriele Sorrento
  • Francesco Pongetti
  • Lotfi Herzi

Appendix