Token导航 LogoToken导航TokenDH.com
研究检索需要联网github未标认证来源可访问许可证需确认审计提醒

autoresearch-ml自动研究机器学习

Agent Skill

autoresearch-ml 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

392

周安装

16

GitHub Stars

7

下载量

125
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:autoresearch-ml(自动研究机器学习)
来源仓库:https://github.com/proyecto26/autoresearch-ai-plugin
仓库路径:skills/autoresearch-ml
安装命令:
npx skills add https://github.com/proyecto26/autoresearch-ai-plugin --skill autoresearch-ml
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/proyecto26/autoresearch-ai-plugin --skill autoresearch-ml

简介

autoresearch-ml 是一个单 GPU LLM 预训练自主实验循环工具,支持编辑 train.py、提交、运行短时训练并测量验证损失,适合模型调优场景。

  • 适用于具备快速评估能力(如 val_bpb)且希望持续迭代改进的训练任务。
  • 自动设置训练模板、运行实验、记录结果并通过 TSV/JSON 输出改进日志与可视化看板。
  • 使用前需准备 Python 环境和数据集,并注意本地文件读写与可能的 GPU 资源占用。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Autoresearch ML: Autonomous LLM Training Optimization

An autonomous experiment loop for single-GPU LLM pretraining. Edit train.py → commit → run 5-minute training → measure val_bpb → keep improvement or revert → repeat forever.

This skill is self-contained — it includes everything needed to set up and run the loop.

Setup Phase

1. Copy Template Assets

Copy the bundled training template to the project directory:

cp ${CLAUDE_SKILL_DIR}/assets/prepare.py .
cp ${CLAUDE_SKILL_DIR}/assets/train.py .
cp ${CLAUDE_SKILL_DIR}/assets/pyproject.toml .
cp ${CLAUDE_SKILL_DIR}/assets/program.md .

2. Install and Prepare

uv sync                    # Install dependencies
uv run prepare.py          # Download data shards, train tokenizer (~2 min)

3. Verify GPU

nvidia-smi
python -c "import torch; print(f'CUDA: {torch.cuda.is_available()}, Device: {torch.cuda.get_device_name()}, VRAM: {torch.cuda.get_device_properties(0).total_mem / 1e9:.1f} GB')"

4. Initialize the Experiment Session

  1. Create a branch: git checkout -b autoresearch/<tag>-<date>
  2. Ensure session files are gitignored (critical — git revert will fail if tracked): echo -e "autoresearch.jsonl\nrun.log" >>.gitignore git add.gitignore && git commit -m "autoresearch: add session files to gitignore"
  3. Read prepare.py and train.py thoroughly to understand the codebase
  4. Write autoresearch.md — a living session document recording goal, metrics, files in scope, constraints, and learnings
  5. Write autoresearch.sh — the benchmark script (see Benchmark Script section below)
  6. Commit session files
  7. Run baseline: bash autoresearch.sh
  8. Parse metrics from output (lines matching METRIC name=value)
  9. Record baseline in autoresearch.jsonl:

- First write a config header: {"type":"config","name":"Optimize val_bpb","metricName":"val_bpb","metricUnit":"bpb","bestDirection":"lower"} - Then record the baseline result

  1. Begin the experiment loop

The Experiment Loop

LOOP FOREVER. Never ask "should I continue?" — just keep going.

The user might be asleep, away from the computer, or expects you to work indefinitely. Each experiment takes ~5 minutes, so you can run ~12/hour, ~100 overnight. The loop runs until the user interrupts you, period. If you run out of ideas, think harder — re-read train.py for new angles, try combining previous near-misses, try more radical architectural changes.

Each iteration:

1. Read current git state and autoresearch.md
2. Choose an experimental change to train.py (informed by past results and ASI notes)
3. Edit train.py (the ONLY editable file)
4. git add train.py && git commit -m "experiment: <description>"
5. Run: bash autoresearch.sh > run.log 2>&1
6. Parse METRIC lines from output
7. If output is empty (crash): tail -n 50 run.log to read the stack trace
8. Decide: keep or discard
9. Log result to autoresearch.jsonl (include ASI annotations)
10. If discard/crash: git revert $(git rev-parse HEAD) --no-edit
11. Update autoresearch.md with learnings (every few experiments)
12. Repeat

Decision Rules

  • val_bpb improved (lower)keep (commit stays, branch advances)
  • val_bpb equal or worsediscard (run git revert $(git rev-parse HEAD) --no-edit)
  • Crash (OOM, CUDA error, NaN loss)discard (revert). If it's a simple fix (typo, import), fix and re-run. If the idea is fundamentally broken, log as crash and move on.
  • Simpler code for equal val_bpbkeep (removing complexity is a win)
  • Catastrophic VRAM increase → consider discard even if val_bpb improved slightly

Simplicity Criterion

All else being equal, simpler is better. A 0.001 val_bpb improvement that adds 20 lines of hacky code? Probably not worth it. A 0.001 improvement from deleting code? Definitely keep. Equal val_bpb with much simpler code? Keep.

Constraints

  • Fixed 5-minute time budget. All experiments are directly comparable — the wall clock is the equalizer.
  • Single file modification. Only train.py changes; prepare.py is immutable. This ensures fair comparison (same data, same evaluation).
  • VRAM is a soft constraint. Using more VRAM is acceptable but note the trade-off (larger model = fewer training steps in 5 minutes).
  • No new packages. You can only use what's already in pyproject.toml.
  • Timeout: If a run exceeds 10 minutes, kill it and treat as a crash.

Don't Thrash

If 3 consecutive experiments fail or get discarded, stop and think about why. Re-read train.py for new angles. Try a fundamentally different approach.

Handling User Messages

If the user sends a message while the loop is running: finish the current cycle, address the feedback, then resume immediately — do not wait for permission.

Logging to autoresearch.jsonl

Each experiment appends one JSON line:

{"run":2,"commit":"def5678","metric":0.993,"metrics":{"peak_memory_mb":44200,"mfu_percent":39.8},"status":"keep","description":"increase LR to 0.04","timestamp":1700000000,"segment":0,"confidence":null,"asi":{"hypothesis":"higher LR converges faster","arch_change":"MATRIX_LR 0.03→0.04"}}

Use the shared logging script:

bash ${CLAUDE_SKILL_DIR}/scripts/log-experiment.sh \
  --run 2 \
  --commit "$(git rev-parse --short HEAD)" \
  --metric 0.993 \
  --status keep \
  --description "increase LR to 0.04" \
  --metrics '{"peak_memory_mb":44200,"mfu_percent":39.8}' \
  --segment 0 \
  --asi '{"hypothesis":"higher LR converges faster"}'

Parse metrics from benchmark output:

bash autoresearch.sh 2>&1 | bash ${CLAUDE_SKILL_DIR}/scripts/parse-metrics.sh

Valid statuses: keep, discard, crash, checks_failed

ASI (Actionable Side Information)

ASI is structured annotation per experiment that survives reverts. When code changes are discarded, only the description and ASI remain — the only structured memory of what happened.

Record ASI for every experiment:

{
  "hypothesis": "Deeper model with fewer steps should compress better",
  "arch_change": "DEPTH 8→12, DEVICE_BATCH_SIZE 128→64",
  "result": "val_bpb improved 0.998→0.992, but 2x VRAM",
  "next_action_hint": "Try intermediate DEPTH=10 for better VRAM tradeoff"
}

Resuming After Context Reset

If autoresearch.jsonl and autoresearch.md exist in the working directory:

  1. Read autoresearch.md for full context (goal, metrics, files, constraints, learnings)
  2. Read autoresearch.jsonl to see all past experiments, current best, and ASI annotations
  3. Check git log to verify current branch state matches expected state
  4. If git state is dirty (unclean shutdown), revert uncommitted changes
  5. Resume the loop from where it left off — no re-setup needed
  6. Resume immediately — do not ask "should I continue?"

Confidence Scoring

After 3+ experiments, assess whether improvements are real or noise:

  • Compute the Median Absolute Deviation (MAD) of all metric values as a noise floor
  • Confidence = |best improvement| / MAD
  • ≥2.0× → likely real improvement
  • 1.0–2.0× → marginal, could be noise
  • <1.0× → within noise floor

ML training with fixed seeds is mostly deterministic, so the noise floor is typically very low.

Template Architecture

prepare.py (FIXED — never modify)

  • Data download: Fetches parquet shards from HuggingFace (climbmix-400b-shuffle)
  • Tokenizer training: BPE tokenizer (8192 vocab) using rustbpe/tiktoken
  • Dataloader: Best-fit document packing with 100% token utilization, BOS-aligned
  • Evaluation: evaluate_bpb() computes bits-per-byte (vocab-size-independent metric)

Key constants: MAX_SEQ_LEN = 2048, TIME_BUDGET = 300, EVAL_TOKENS = 40 * 524288, VOCAB_SIZE = 8192

train.py (MODIFIED BY AGENT — the only editable file)

  • Model: GPT with RoPE, sliding window attention, value embeddings, Flash Attention 3
  • Optimizer: Hybrid MuonAdamW (Muon for matrices, AdamW for everything else)
  • Training: Gradient accumulation, LR schedules (warmup/flat/warmdown), fixed time budget

Editable: ASPECT_RATIO, DEPTH, WINDOW_PATTERN, TOTAL_BATCH_SIZE, learning rates, LR schedule phases, and the full model architecture.

GPU Requirements

Supported GPU Tiers

TierGPUsVRAMNotes
ConsumerGTX 1080 Ti, RTX 2080 Ti11GBfp32 fallback, gradient checkpointing required
Consumer+RTX 3090, RTX 409024GBGreat for experiments
EnthusiastRTX 509032GBExcellent — larger models possible
DatacenterA100, H10040-80GBOriginal development target

Consumer GPU Adaptations

For GPUs with limited VRAM (< 16GB), apply these changes to train.py during the first experiment:

  1. Remove Flash Attention 3 import and dependency — the top-level from kernels import get_kernel block (lines 20-24) runs unconditionally at startup and will fail on non-Hopper GPUs. Replace the entire block and the fa3.flash_attn_func() call in CausalSelfAttention.forward() with torch.nn.functional.scaled_dot_product_attention. Also remove kernels from pyproject.toml and run uv sync again.
  2. Enable gradient checkpointing — use torch.utils.checkpoint.checkpoint() with use_reentrant=False to trade ~30% compute for ~50% VRAM savings
  3. Auto-scale model size — reduce DEPTH and DEVICE_BATCH_SIZE to fit VRAM budget (see table below)
  4. Cap evaluation steps — scale eval batch count by available VRAM (30-100 steps)
  5. fp32 fallback — use fp32 instead of bf16 for Pascal GPUs (compute capability < 7.5). Change the autocast dtype and disable bf16-specific optimizations.

VRAM Auto-Scaling Guide

VRAM BudgetDEPTHn_embdBatch SizeSeq Length~Params
4GB21284512~1M
8GB425681024~5M
12GB6384161024~14M
16GB8512322048~25M
24GB85121282048~50M
32GB127681282048~85M
80GB1610241282048~200M

Note: n_embd must be a multiple of HEAD_DIM (default 128). Config search: start with the largest depth that fits, reduce DEVICE_BATCH_SIZE then MAX_SEQ_LEN if OOM.

Experiment Strategies

  1. Architecture: Layer count, attention patterns, embedding dimensions, activation functions
  2. Optimizer: Learning rates (per-parameter), schedule phases, momentum, weight decay
  3. Attention: Window sizes, sliding window configs, full vs. local attention
  4. Batch size: Trade-off between gradient quality and steps-per-budget
  5. Initialization: Weight init schemes, residual scaling parameters
  6. Advanced: Value embeddings, softcapped logits, GQA

Metric: Bits Per Byte (BPB)

How well the model compresses text, normalized by byte count. Vocabulary-size-independent — all architectures are directly comparable. Lower is better. See references/gpu-training-guide.md for the formula and interpretation table.

Benchmark Script

Use this as autoresearch.sh:

#!/usr/bin/env bash
set -euo pipefail

uv run train.py > run.log 2>&1

val_bpb=$(grep "^val_bpb:" run.log | tail -1 | awk '{print $2}' || echo "0")
memory=$(grep "^peak_vram_mb:" run.log | tail -1 | awk '{print $2}' || echo "0")
mfu=$(grep "^mfu_percent:" run.log | tail -1 | awk '{print $2}' || echo "0")

echo "METRIC val_bpb=$val_bpb"
echo "METRIC peak_memory_mb=$memory"
echo "METRIC mfu_percent=$mfu"

Session Files

FilePurpose
autoresearch.mdLiving session document — goal, metrics, scope, learnings
autoresearch.shBenchmark script — outputs METRIC name=value lines
autoresearch.jsonlAppend-only experiment log with ASI (survives restarts)

Additional Resources

  • references/gpu-training-guide.md — Detailed GPU setup, CUDA configuration, OOM troubleshooting, BPB formula, and performance tuning
  • scripts/parse-metrics.sh — Extract METRIC lines from benchmark output
  • scripts/log-experiment.sh — Append experiment results to autoresearch.jsonl
  • assets/prepare.py — Data preparation (download, tokenizer, dataloader, evaluation)
  • assets/train.py — Model architecture and training loop
  • assets/program.md — Self-contained agent instructions for the ML loop
  • assets/pyproject.toml — Python dependencies (PyTorch, Flash Attention, etc.)

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.6%
按下载量换算43

Claude

31.25%
按下载量换算39

Cursor

22.51%
按下载量换算28

Gemini CLI

9.6%
按下载量换算12

安全审计

Gen Agent Trust Hub

可疑

Socket

可疑

Snyk

可疑

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。来源安全扫描存在 warning/failed 结果,不能写成本站确认安全。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills