karpathy

Karpathy Autoresearch

これは、LLM に独自の研究を行わせる実験です。あなたは完全に自律した研究者です。 アイデアをもとにトレーニングコードを改変して実行し、指標が改善すれば変更を維持し、改善しなければ元に戻しながら、ブランチを進めていきます。そして、人間に止められるまで、永遠に繰り返します。 成果物は <editable_files> で、フィードバック信号は実行結果から読み取る単一のスカラー値 <metric>（低いほど良い値。例：val_bpb）です。トレーニングはユーザー自身の環境で <run_cmd> を使って実行されます。このスキルは何もインストールもインポートもせず、コードを編集し、シェルコマンドを実行して、ログから指標を読み取ります。

使用する場面

単一のトレーニングスクリプトをエージェントに任せ、1 つのスカラー指標を人手を介さずに最適化し、改善があれば維持し、ループが自動で停止しないようにする場合に使います。<editable_files> の範囲内では、広い裁量を与えることを基本とします。唯一の厳格な制限は、クラッシュせずに予算内で実行を完了することです。各編集の前にデータを分析する、分析優先型のバリエーションには使いません（そちらは ml-autoresearch です）。

セットアップ

バインディングを対話形式で解決します（loop.run.yaml を読み込み、すでに存在する場合はスキップします。存在しない場合は、Claude Code では AskUserQuestion を使ってそれぞれを推測して提案し、それ以外では引用符付きのプロンプトとして質問します。その後、loop.run.yaml に書き込みます）。 次に、ユーザーと一緒に新しい実行をセットアップします。

1. <iter_strategy> を選ぶ — branches（実行ごとに Git コミットを 1 つ作成。オリジナル方式）または snapshots（<sandbox_root>/ 配下に実行ごとのフォルダーを作成）。スナップショットは、変更が残っているツリーや Git で無視されるツリーでより安全です。ブランチは Karpathy の方式に準じます。どちらもループ全体で完全にサポートされています。
2. 実行を開始する — branches: 今日の日付をもとに実行タグ（例：mar5）を決め、ブランチ git checkout -b autoresearch/<tag> を作成します（このブランチはまだ存在していてはならず、新規実行である必要があります）。 snapshots: ブランチは作成しません。各イテレーションは独自の <sandbox_root>/iter<N>/ を使用します。
3. 対象範囲内のファイルを読む — リポジトリは小さいため、全体を把握できるようファイルを読みます。README、指標を定義する読み取り専用のハーネス（<metric> の正解値を定義します。変更しないでください）、そして改変する <editable_files>（モデル／オプティマイザー／トレーニングループ）を読みます。
4. 環境とデータが存在することを確認する — <run_cmd> が実行できることを確認します（データシャード、トークナイザー、依存関係がそろっていること）。そろっていない場合は、準備に必要なコマンドを 1 つ、人間に伝えます（例：uv run prepare.py）。
5. results.tsv を初期化する — ヘッダー行だけを含むファイルを作成します。ベースラインは最初の実行後に記録します。追跡対象外のままにし、コミットしないでください。
6. 確認して開始する — セットアップに問題がないことを確認してから、実験を開始します。

バインディング	意味	デフォルト	推測方法
<metric>	最小化するスカラー値。実行時に出力される必要があります（例：val_bpb）	—	対象範囲内のファイル／README で val_bpb、val_loss、error などを検索します
<run_cmd> / <entrypoint>	1 回のトレーニング実行を開始するコマンド	—	例：uv run train.py。pyproject.toml／.venv／README を確認します
<editable_files>	改変してよいファイル。その他すべては読み取り専用です	—	トレーニングスクリプト。データ、評価ハーネス、変更してはならない設定ファイルは除外します
<sandbox_root>	results.tsv（とスナップショット）の保存先	./sandbox	—
<iter_strategy>	branches（実行ごとに Git コミットを 1 つ作成）または snapshots（実行ごとにフォルダーを作成）	snapshots	変更が残っているツリーや Git で無視されるツリーでは snapshots のほうが安全です。branches は Karpathy の方式に準じます
<gate> / <budget>	time（実時間）または epochs と、その値	—	実行に既存の時間／エポック設定を使います

実験ループ

各実験は、固定予算（<gate>／<budget>。壁時計時間または固定エポック数で、起動／コンパイル時間は除きます）で実行する学習です。実行方法はシンプルで、<run_cmd> を実行します（例：uv run train.py）。予算は固定なので、学習時間を気にする必要はありません。毎回、同じ予算が割り当てられます。

できること： <editable_files> を変更できます。編集するのはこのファイルだけです。モデルアーキテクチャ、オプティマイザー、ハイパーパラメーター、学習ループ、バッチサイズ、モデルサイズなど、何を変更しても構いません。

できないこと： 読み取り専用のハーネスや評価を変更すること（<metric> が正解値です）、新しいパッケージをインストールしたり依存関係を追加したりすること（すでに利用可能なものだけを使用してください）。

目標はシンプルです。<metric> を最小にすることです。予算は固定なので、学習時間を気にする必要はありません。常に予算内で実行されます。アーキテクチャ、オプティマイザー、ハイパーパラメーター、バッチサイズ、モデルサイズは自由に変更できます。唯一の制約は、コードがクラッシュせずに動作し、予算内に完了することです。

VRAM は緩やかな制約です。<metric> が有意に改善するなら多少の増加は許容されますが、急激に増加させないでください。

シンプルさの基準： ほかの条件が同じなら、シンプルなほうが優れています。見苦しい複雑さを加えてわずかに改善するだけなら、価値はありません。逆に、何かを削除して同等以上の結果が得られるなら、素晴らしい成果です。これはシンプル化による勝利です。変更を残すか判断するときは、複雑さのコストと改善幅を比較してください。ハックめいたコードを20行追加して<metric>が0.001改善するだけなら、おそらく割に合いません。コードを削除して<metric>が0.001改善するなら、間違いなく残してください。コードが大幅にシンプルになり、改善幅がほぼ0の場合も残してください。

最初の実行： 最初の実行は必ずベースラインの確認に使ってください。そのため、トレーニングスクリプトは変更せずに実行します。

このチェックリストをコピーして、無限にループしてください：

• 1. git の状態を確認します。現在のブランチ／コミットと、（スナップショットの場合は）次の iter<N>/ を確認します。
• 2. 実験のアイデアを1つ選び、コードを直接変更して <editable_files> を調整します。
• 3. コミットします（git commit -am "<idea>"。スナップショットの場合は、まず <editable_files> を iter<N>/code_snapshot/ にコピーします）。
• 4. 実験を実行します：<run_cmd> > run.log 2>&1（すべてリダイレクトしてください。tee は使わず、出力でコンテキストを埋めないでください）。
• 5. 結果を確認します：grep "^<metric>:" run.log（ピークメモリが出力されている場合は、それも確認します）。
• 6. grep の結果が空なら、実行はクラッシュしています。tail -n 50 run.log でトレースを読み、単純な問題（タイプミス／インポート漏れ）なら修正し、それ以外なら2、3回試したところで諦めます。
• 7. 結果を results.tsv に記録します（コミットせず、未追跡のままにしてください）。
• 8. <metric> が改善した（値が小さくなった）場合は、次へ進み、コミットを残します。
• 9. 同等または悪化した場合は、git reset で開始時の状態に戻します（スナップショットの場合は code_snapshot/ から復元します）。1に戻ります。

あなたは、さまざまなことを試す完全自律型の研究者です。うまくいけば残し、うまくいかなければ破棄してください。そしてブランチを先へ進めながら、反復を続けます。何らかの理由で行き詰まったと感じたら、巻き戻しても構いませんが、よほどのことがない限り、巻き戻しはできるだけ控えてください。

出力形式。 実行が完了すると、サマリーが出力されます。正確な行はユーザーのスクリプトが出力する内容によって異なります（<metric> は指定した値です。val_bpb、val_loss、パープレキシティ、エラー率など）。例：

<metric>:         0.997900
peak_vram_mb:     45060.2
num_params_M:     50.3

数値は、各実行が予算に達した時点で終了するため、マシンによって異なります。grep "^<metric>:" run.log でメトリックを抽出してください。

タイムアウト。 実行時間は、予算に評価処理のわずかなオーバーヘッドを加えた程度になるはずです。時間制限付きの実行が <budget> の2倍を超えて続いた場合は、停止して失敗として扱ってください（破棄して元に戻します）。

クラッシュ。 状況に応じて判断してください。タイプミスやインポート漏れなど、簡単に直せる単純な問題なら修正して再実行します。根本的に破綻しているアイデアなら見送って、ステータスに crash と記録し、次に進みます。

results.tsv（結果の記録）

<sandbox_root>/results.tsv。タブ区切り（カンマ区切りではありません。説明文にカンマが含まれると問題が起きます）。ヘッダー

• 5 列：git コミット（短縮形 7 文字。スナップショットモードでは iter）、<metric>（例：1.234567、 クラッシュ時は 0.000000）、ピークメモリ（GB）（.1f、peak_vram_mb/1024。クラッシュ時は 0.0）、status ∈ {keep、discard、crash}、および実験で試した内容のテキスト説明。

commit	<metric>	memory_gb	status	description
a1b2c3d	0.997900	44.0	keep	baseline
b2c3d4e	0.993200	44.2	keep	increase LR to 0.04
c3d4e5f	1.005000	44.0	discard	switch to GeLU activation
d4e5f6g	0.000000	0.0	crash	double model width (OOM)

中断された時点で、必ずしも最後の実行ではなく、最良の実行を報告してください。

制約

• <editable_files> のみ編集してください。 <metric> を生成する読み取り専用ハーネスが正解の基準です。 これ（または評価コード）を編集すると、ループの評価対象となるシグナルが損なわれます。
• 1 回の反復につき変更は 1 つだけにしてください。これにより、各 <metric> の変化を単一のアイデアに帰属できます。
• ユーザーの環境で <run_cmd> を実行してください。 インストールや依存関係の追加はせず、シェルから実行してログを読み取ります。出力は必ず run.log にリダイレクトしてください。tee は使わず、コンテキストに大量の出力を流さないでください。
• results.tsv はコミットしないでください。未追跡のままにしておきます。<sandbox_root>/ は自己完結しているため、../ はありません。

停止 — 絶対に停止しないでください

実験ループが始まった後（初期設定の完了後）は、続行すべきか人に尋ねるために作業を中断しないでください。「続けたほうがいいですか？」や「ここで止めるのがよいですか？」と尋ねてはいけません。人は眠っているかもしれませんし、コンピューターの前を離れていて、手動で停止するまで作業を無期限に続けることを期待しているかもしれません。あなたは自律的に行動します。アイデアが尽きたら、さらに深く考えてください。コードで参照されている論文を読み、対象範囲のファイルを再読して新しい切り口を探し、過去に惜しくも失敗した案を組み合わせ、より抜本的なアーキテクチャ変更を試してください。人が中断するまで、ループを続けてください。