| Hello r/MachineLearning!私は米国の交通業界で働いていて、数か月前にAI & MLの学習に全振りしました。アンドレイ・カープのオートリサーチ・フレームワークについて聞いて、すごく面白いと思いました。 そこで、以前のGPT-2 XLの微調整プロジェクトで使っていたものと同じ交通データセットを使い、スクラッチから小さな80Mモデルを学習することにしました。オートリサーチはスクラッチ前学習(微調整ではない)向けに設計されているので、GPT-2 XLのものを後付けで流用するのではなく、新しいプロジェクトを始めました。 ぜひ、皆さんの意見を聞かせてください…
なぜこれをやったのか?私の理解では、カープのオートリサーチ・フレームワークはLLM駆動の研究ループです。エージェントが単一の学習スクリプトを編集し、固定データセットに対して5分間の学習実験を走らせ、1つのスカラー指標に基づいてコミットするか元に戻します。これはFineWeb(実質的に無限のウェブ規模のテキスト)で設計・検証されました。しかし私のモデルは業界特化で、データ量ははるかに小さなものです。 カープのwikiを読みながら、コアとなる仕組み(自律的な実験ループ、5分という学習上限、単一スカラーの合否ラチェット)が、限られたデータでも有意なパープレキシティの低下を生むのかを検討しました。そこでオートリサーチをフォークし、小さな交通データのコーパス(交通分析、train plans、規制に関するQ&Aペアを含めて約33Mトークン)に向けて動かし、次の2つの主要な問いに答えることにしました: 質問1:オートリサーチは、設計目標より6桁も小さいコーパスでも機能するのか? 質問2:オートリサーチのエージェントは、私が提案しなかった何を見つけるのか? 念のため言うと、出力はデプロイ可能なチャットボットとして意図したものではなく、方法論の検証としてのものです。このフレームワークのパターン(自律的な徹夜実験、単一スカラーのラチェット、gitをトラッカーとして使う)が、データが小さく専門化される場合にも成り立つのかを知りたかったのです。 プロジェクトの制約
設計上の選択とその理由早い段階でいくつかの課題に直面しました。オートリサーチのフレームワークには3つの前提があり、私の実験では成り立たないように見えました。すなわち、FlashAttention-3カーネルがGPU上で利用可能であること、エージェントの「1実験につき1つだけ変更する」ルールを、既存のアーキテクチャ制御で守れること、そしてホールドアウトデータが適応的な過学習に耐えるほど十分に大きいこと、です。どれも私の環境では満たせませんでした。以下、それぞれについて対処します.
さらにいくつかの方針転換:交通コーパスを4つに分割しました(train, dev, val_public, test_private)。トピックごとにグルーピングし、どのドキュメントもどの2つのパート間にもまたがらないようにしてあります。これにより、学習データ、エージェントの作業データ、コミットゲートのデータ、そしてマイルストーン確認用に差し控えるデータの間でリークが起きるのを防ぎます。トークナイザは65個の高頻度の交通略語(FTA、MBTA、NTD、IIJAなど)を、それぞれサブワード断片に分割せず1つのトークンとして符号化するように手作りしました。そして、エージェントのループが始まる前に、同じベースラインを異なるランダムシードで5回学習し、各スコアがランダムな運にどれだけ左右されるかを測定しました。これにより、後で本当の改善とランダム変動を見分けるためのノイズフロアが得られました。 主要な発見最も大きな単一の変更は、最初は私にとって直感に反するものでした。エージェントはバッチサイズを2回半減しました。学習ステップあたり524Kトークンから131Kへと落とし、その結果、同じ5分間の予算に3.6倍の学習更新を詰め込みました(118回の学習更新 ---> 427回の学習更新)。更新回数だけが増え、各更新はよりノイジーなシグナルを伴うのに、それでもMuonオプティマイザがノイズを破綻させずに扱いました。私は「より大きいバッチの方が学習はより確実に進む」という従来のレビュー観点なら、この変更はコードレビューで却下していたはずです。しかしエージェントはその偏見を共有しておらず、アーキテクチャの失敗を8回繰り返した後の実験13でこれを見つけました。 モデルサイズのカーブ(下記)がサイズ問題を決着させました。80Mパラメータが素直なピークでした。30Mと50Mは容量が足りませんでした。一方で100Mと150Mは、5分で十分なオプティマイザのステップ数を稼げず、競争できませんでした(150Mは時間切れになるまで84ステップしか走りませんでした)。 方法論の層は2つの偽陽性を特定しました。2つの実験は、エージェントの作業メトリクス(dev_bpb)を改善しましたが、ホールドアウトの表面(val_public_bpb)には適用されませんでした。Hidden-gateがなければ、どちらも同じように誤りを起こしていたはずですが、代わりに両方ともリバートされました。 そして、厳密な検証(rigor pass)が私をかなり打ちのめした。別の乱数シード(INIT_SEED=43)で終盤の「勝者」を再現すると、言語モデリングの結果は揺るぎないものだった(4回の実行でΔは±0.005以内、2つのアーキテクチャ×2つのシード)。しかし、2つの見かけ上の精度向上は崩れた。用語精度はシード間で9ポイント振れ、規制引用精度は15%ポイント振れた。 精度ベンチマーク(用語、Q&A、規制引用)に対して適切な統計検定を行ったところ、8通りの直接対決比較のうち統計的に有意だったのは1つだけだった。結論は避けようがなかった。言語モデリングの改善は本物だ(別途検証済みで、ノイズの約20倍、さらに新しいシードで再現もできた)。一方で、ドメイン精度の「勝ち」は、我々の100〜250件のベンチマーク規模ではノイズに過ぎなかった。 重要な学びこのプロジェクトから私が次の「少量データ向けオートリサーチ(autoresearch)」の追試でも持ち越したい、5つの教訓:
次のステップ正直なところ、次にどこへ進むべきかはよく分からない。この後に試す価値がありそうな方向性はいくつかあって、MLコミュニティの皆さんから、どれが一番面白そうか意見をもらえたら嬉しい。私が検討している3つは: 1. 新しい乱数シードでプロジェクトを再現する。Phase 5 + Phase 7のパイプライン全体を2〜3個の新しいシードで再実行し、同じ「勝ち」(または近い結果)が出るかどうかを見る……そして同じ偽陽性が再発するかどうかも確認したい。「その方法論は再現可能なのか、それとも別の形で運が良かっただけなのか?」を知りたい。 2. オートリサーチを「教科書どおり」に汎用コーパスで実行する。Karpathyの主要リポジトリを、AutoTransitの変更なしでクローンし、フレームワークが想定しているのと同じFineWebの一部でテストする。ここでの結果を私の小さくて専門性の高いデータセットでの結果と比較することで、オートリサーチについて一般化できる知見と、小データに固有の知見の切り分けができる。 3. こちらからスクラッチで行ったことと、ドメイン適応型事前学習(DAPT)を比較する。同様のサイズの事前学習済みモデルを既製品で用意する——Pythia-160M(すでにWebテキストで学習済み)——そしてそれを私のトランジット・データセットで継続学習する。データ、評価方法、アプローチは同じにする。主要な問いは、ランダム重みから始めることが、明白な近道(shortcut)に勝てるかどうかだ。私が把握している限り、多くの研究ではそれはできないはずだという。スクラッチの結果が成立するなら、その点が面白い。成立しなかった場合でも、役に立つ何かは学べるだろう。 ここまで読んだ、もしくはスクロールしてここまで来たなら、ありがとうございます!!(笑)ぜひあなたの考えを共有してください……どこで失敗したのか?何が面白いのか?次に何をするべきか考えるとしたら、どんな点を考慮すべきでしょうか? [link] [comments] |
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分の実験ループと単一スカラーの合否指標が限られたデータでもペルプレキシティ改善に寄与するか、さらにエージェントが研究者自身では提案しなかった発見をするのかを確認することです。
- 結果はチャットボットの実用化ではなく手法の検証として位置づけられており、再現メモとともに、失敗ポイントや次に学ぶべき点についてコミュニティの意見を求めています。



