Karpathyのオートリサーチを約3300万トークンの公共交通データセットに適用(14%改善、再現メモ)

Reddit r/MachineLearning / 2026/5/1

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsModels & Research

要点

  • 米国の公共交通分野の研究者が、Andrej Karpathyの「autoresearch」ループが、FineWebの想定よりも大幅に小さく・特化されたデータでも機能するかを検証するために適用しました。
  • 80Mパラメータのモデルを、交通分析・運行計画・規制に関するQ&Aを含む約3300万トークンの公共交通コーパスで、学習をスクラッチから実行する形で進め、GPT-2 XLの微調整プロジェクトを流用する代わりに新規に取り組みました。
  • 目的は2点で、5分の実験ループと単一スカラーの合否指標が限られたデータでもペルプレキシティ改善に寄与するか、さらにエージェントが研究者自身では提案しなかった発見をするのかを確認することです。
  • 結果はチャットボットの実用化ではなく手法の検証として位置づけられており、再現メモとともに、失敗ポイントや次に学ぶべき点についてコミュニティの意見を求めています。
33Mトークンの公開交通データセットに、カープのオートリサーチを適用(14%改善、再現ノート)[P]

Hello r/MachineLearning!私は米国の交通業界で働いていて、数か月前にAI & MLの学習に全振りしました。アンドレイ・カープのオートリサーチ・フレームワークについて聞いて、すごく面白いと思いました。

そこで、以前のGPT-2 XLの微調整プロジェクトで使っていたものと同じ交通データセットを使い、スクラッチから小さな80Mモデルを学習することにしました。オートリサーチはスクラッチ前学習(微調整ではない)向けに設計されているので、GPT-2 XLのものを後付けで流用するのではなく、新しいプロジェクトを始めました。

ぜひ、皆さんの意見を聞かせてください…

  1. どこでミスった?
  2. ここで面白いのは何?
  3. 何を学習に注力すべき?次に何をする?(投稿の最後に私の考えがあります)

なぜこれをやったのか?

私の理解では、カープのオートリサーチ・フレームワークはLLM駆動の研究ループです。エージェントが単一の学習スクリプトを編集し、固定データセットに対して5分間の学習実験を走らせ、1つのスカラー指標に基づいてコミットするか元に戻します。これはFineWeb(実質的に無限のウェブ規模のテキスト)で設計・検証されました。しかし私のモデルは業界特化で、データ量ははるかに小さなものです。

カープのwikiを読みながら、コアとなる仕組み(自律的な実験ループ、5分という学習上限、単一スカラーの合否ラチェット)が、限られたデータでも有意なパープレキシティの低下を生むのかを検討しました。そこでオートリサーチをフォークし、小さな交通データのコーパス(交通分析、train plans、規制に関するQ&Aペアを含めて約33Mトークン)に向けて動かし、次の2つの主要な問いに答えることにしました:

質問1:オートリサーチは、設計目標より6桁も小さいコーパスでも機能するのか?

質問2:オートリサーチのエージェントは、私が提案しなかった何を見つけるのか?

念のため言うと、出力はデプロイ可能なチャットボットとして意図したものではなく、方法論の検証としてのものです。このフレームワークのパターン(自律的な徹夜実験、単一スカラーのラチェット、gitをトラッカーとして使う)が、データが小さく専門化される場合にも成り立つのかを知りたかったのです。

プロジェクトの制約

  • ハードウェア:単一のRTX 5080(16 GB、sm120 … Blackwellのコンシューマー向けアーキテクチャ)をWSL2 Ubuntu 22.04上で使用。クラウドGPUなし。
  • 1実験あたりの予算:学習5分(壁時計の契約として、オートリサーチが強制するもの)
  • 新たな依存関係なし:pyproject.tomlで配布されているものだけ。
  • スクラッチのみ:事前学習済みベースなし。エージェントは各5分の実験ごとに、ランダム初期化からトランスフォーマを学習しました。(これは、同じコーパスで先に行ったGPT-2 XLのLoRA微調整とは別物です。このモデルは本プロジェクトの範囲に含まれていません。2つのアプローチの比較は、投稿の最後にある可能性のある次のステップの1つです。)

設計上の選択とその理由

早い段階でいくつかの課題に直面しました。オートリサーチのフレームワークには3つの前提があり、私の実験では成り立たないように見えました。すなわち、FlashAttention-3カーネルがGPU上で利用可能であること、エージェントの「1実験につき1つだけ変更する」ルールを、既存のアーキテクチャ制御で守れること、そしてホールドアウトデータが適応的な過学習に耐えるほど十分に大きいこと、です。どれも私の環境では満たせませんでした。以下、それぞれについて対処します.

  • SDPAのみの注意機構: 私のRTX 5080 GPUは、オートリサーチのデフォルトが期待するFlashAttention-3カーネルをサポートしていないため、PyTorchの組み込みのattention(cuDNNバックエンド付きのscaled_dot_product_attention)に切り替えました。これは、FlashAttention-3がBlackwell向けGPUのサポートを出すまで恒久的です。
  • 2つのアトミックなスケーリングつまみ: カープの train.py は、相互依存する複数の定数によってモデルのアーキテクチャを制御します。モデルサイズを変えるには同時に複数行を編集する必要があり、エージェントの「1実験につき1つだけ変更する」ルールを壊してしまいます。そこで私は、2つの1行のつまみに置き換えました:TARGET_PARAMS_M(総パラメータ数)とASPECT_RATIO(深さ対幅の形状)で、管理を担う補助関数(derive_arch())を追加しました。最初はエージェントがきめ細かな制御を失うのが不満でしたが、結果として、すべての実験がきれいに“同じ土俵での”比較になることを強制できました。
  • Hidden-gate Ladderプロトコル: エージェントはホールドアウトの検証スコアを直接は見ません。代わりに、合否のシグナルと4段階のマージン(clear / narrow / miss / first_run)だけを受け取ります。正確なスコアはエージェントが読むことを許されない非公開ファイルに保存されるため、見えない数値に向けて調整できません。

さらにいくつかの方針転換:交通コーパスを4つに分割しました(train, dev, val_public, test_private)。トピックごとにグルーピングし、どのドキュメントもどの2つのパート間にもまたがらないようにしてあります。これにより、学習データ、エージェントの作業データ、コミットゲートのデータ、そしてマイルストーン確認用に差し控えるデータの間でリークが起きるのを防ぎます。トークナイザは65個の高頻度の交通略語(FTA、MBTA、NTD、IIJAなど)を、それぞれサブワード断片に分割せず1つのトークンとして符号化するように手作りしました。そして、エージェントのループが始まる前に、同じベースラインを異なるランダムシードで5回学習し、各スコアがランダムな運にどれだけ左右されるかを測定しました。これにより、後で本当の改善とランダム変動を見分けるためのノイズフロアが得られました。

https://preview.redd.it/5b0ndl0lfdyg1.png?width=1600&format=png&auto=webp&s=db3ae95071d544910337d169696ecaa622a89907

主要な発見

最も大きな単一の変更は、最初は私にとって直感に反するものでした。エージェントはバッチサイズを2回半減しました。学習ステップあたり524Kトークンから131Kへと落とし、その結果、同じ5分間の予算に3.6倍の学習更新を詰め込みました(118回の学習更新 ---> 427回の学習更新)。更新回数だけが増え、各更新はよりノイジーなシグナルを伴うのに、それでもMuonオプティマイザがノイズを破綻させずに扱いました。私は「より大きいバッチの方が学習はより確実に進む」という従来のレビュー観点なら、この変更はコードレビューで却下していたはずです。しかしエージェントはその偏見を共有しておらず、アーキテクチャの失敗を8回繰り返した後の実験13でこれを見つけました。

モデルサイズのカーブ(下記)がサイズ問題を決着させました。80Mパラメータが素直なピークでした。30Mと50Mは容量が足りませんでした。一方で100Mと150Mは、5分で十分なオプティマイザのステップ数を稼げず、競争できませんでした(150Mは時間切れになるまで84ステップしか走りませんでした)。

https://preview.redd.it/wdstkdzmfdyg1.png?width=1600&format=png&auto=webp&s=13e504c48ff7dee4501af84c700b4f0e37c8807f

方法論の層は2つの偽陽性を特定しました。2つの実験は、エージェントの作業メトリクス(dev_bpb)を改善しましたが、ホールドアウトの表面(val_public_bpb)には適用されませんでした。Hidden-gateがなければ、どちらも同じように誤りを起こしていたはずですが、代わりに両方ともリバートされました。

https://preview.redd.it/y8kr4wrpfdyg1.png?width=1600&format=png&auto=webp&s=4d8c04cc63c2578f9703029db4f07d38e9f91048

そして、厳密な検証(rigor pass)が私をかなり打ちのめした。別の乱数シード(INIT_SEED=43)で終盤の「勝者」を再現すると、言語モデリングの結果は揺るぎないものだった(4回の実行でΔは±0.005以内、2つのアーキテクチャ×2つのシード)。しかし、2つの見かけ上の精度向上は崩れた。用語精度はシード間で9ポイント振れ、規制引用精度は15%ポイント振れた。

精度ベンチマーク(用語、Q&A、規制引用)に対して適切な統計検定を行ったところ、8通りの直接対決比較のうち統計的に有意だったのは1つだけだった。結論は避けようがなかった。言語モデリングの改善は本物だ(別途検証済みで、ノイズの約20倍、さらに新しいシードで再現もできた)。一方で、ドメイン精度の「勝ち」は、我々の100〜250件のベンチマーク規模ではノイズに過ぎなかった。

https://preview.redd.it/9bybtswrfdyg1.png?width=1600&format=png&auto=webp&s=8061104f818c9868f76cdf32336926c6867227b3

重要な学び

このプロジェクトから私が次の「少量データ向けオートリサーチ(autoresearch)」の追試でも持ち越したい、5つの教訓:

  • オートリサーチの枠組みは少量で専門性の高いデータでも機能する。ただし、自分でセーフティネットを追加する必要がある。Transit Language Modelのスコアは約14%改善した。しかし2つの実験は勝ちのように見えたが、見せられていないデータへは実際には一般化しなかった。適切なガードレールがないと、偽陽性はそのまま出荷され得る。
  • 最大の勝ちは 何にではなくどれくらいの頻度でモデルが更新されるかを変えたことにあった。バッチサイズを2回半分にしたことで、同じ5分の予算に3.6倍の学習更新を詰め込めた(118回の学習更新 → 427回の学習更新)そして13.8%の改善につながった。私は「バッチが大きいほど、より確実に学習できる」という考え方をしていたので、コードレビューではこの変更を却下していただろう。オートリサーチエージェントはそのバイアスを共有しておらず、Muonオプティマイザは、壊れることなくノイジーな更新を扱えるほど頑丈だった。
  • エージェントに走らせる前に 異なる乱数シードでベースラインを数回学習させる。5つのベースライン、約30分——そして、各指標が運だけでどれくらい振れるかが分かる。それをしないと、信号とノイズを区別できない。
  • 実行を完了する前に、すべての「勝ち」を別の乱数シードで再実行する。 約6分の再実行を2回行ったところ、終盤の精度「勝ち」のうち2つは再現されなかった。それらは本物の改善ではなく、ラッキーなシードの選択だった。ノイズを炙り出し始めるには、2つのシードで十分そうだった。
  • エージェントに保持データ(held-out)のスコアを直接見せない——合否(pass/fail)信号だけにする。 エージェントは、見えていないものは攻略できない。これにより、プロジェクト中に2つの「勝ちになりそうな」ケースを見抜けたが、それらは新しいデータでは一般化しなかったはずだ。

次のステップ

正直なところ、次にどこへ進むべきかはよく分からない。この後に試す価値がありそうな方向性はいくつかあって、MLコミュニティの皆さんから、どれが一番面白そうか意見をもらえたら嬉しい。私が検討している3つは:

1. 新しい乱数シードでプロジェクトを再現する。Phase 5 + Phase 7のパイプライン全体を2〜3個の新しいシードで再実行し、同じ「勝ち」(または近い結果)が出るかどうかを見る……そして同じ偽陽性が再発するかどうかも確認したい。「その方法論は再現可能なのか、それとも別の形で運が良かっただけなのか?」を知りたい。

2. オートリサーチを「教科書どおり」に汎用コーパスで実行する。Karpathyの主要リポジトリを、AutoTransitの変更なしでクローンし、フレームワークが想定しているのと同じFineWebの一部でテストする。ここでの結果を私の小さくて専門性の高いデータセットでの結果と比較することで、オートリサーチについて一般化できる知見と、小データに固有の知見の切り分けができる。

3. こちらからスクラッチで行ったことと、ドメイン適応型事前学習(DAPT)を比較する。同様のサイズの事前学習済みモデルを既製品で用意する——Pythia-160M(すでにWebテキストで学習済み)——そしてそれを私のトランジット・データセットで継続学習する。データ、評価方法、アプローチは同じにする。主要な問いは、ランダム重みから始めることが、明白な近道(shortcut)に勝てるかどうかだ。私が把握している限り、多くの研究ではそれはできないはずだという。スクラッチの結果が成立するなら、その点が面白い。成立しなかった場合でも、役に立つ何かは学べるだろう。

ここまで読んだ、もしくはスクロールしてここまで来たなら、ありがとうございます!!(笑)ぜひあなたの考えを共有してください……どこで失敗したのか?何が面白いのか?次に何をするべきか考えるとしたら、どんな点を考慮すべきでしょうか?

submitted by /u/MarsPassenger
[link] [comments]