AutoResearch-LLM：让 Agent 接手 LLM 训练优化- 大数跨境

阿里云开发者

2026-07-03

阿里妹导读

本文分享 LLM 微调 AutoResearch 在电商场景（Query 改写、同款判定、重排打分）的落地实战。作者将 Qwen3 微调经验沉淀为 Agent 驱动的三阶段框架：场景诊断、方案设计、自动化实验，并将工程踩坑（如 PyTorch 2.6 兼容性、Qwen3 Thinking Mode 影响等）写入 SKILL.md 指导 Agent 执行。文章适合关注 AI Coding、Agent for ML 及 LLM 微调工程化的开发者。文中涉及的平台工具（如星云、TuningFactory）为内部命名，其核心思路可迁移至 PAI、SageMaker 等通用环境。

前言

此前在《多模态检索 TBStars_VL_Emb 指令遵循微调》一文中曾提出构建“请求→召回→反馈→训练→服务”的优化闭环。当时设想若训练环节也能自动化，闭环即可运转，但具体落地路径尚不清晰。

可构建完整的 "请求 → 召回 → 曝光/点击/成交 → 样本反馈 → 模型训练 → 线上服务 → 请求" 优化迭代闭环。

Karpathy 提出的 AutoResearch 概念（Agent 基于 SKILL 文件自主完成假设到验证的循环）启发了后续实践。主搜团队的 TAO-AutoResearch 和拍立淘团队的 Pailitao-AutoResearch 已证实"Agent 接管训练迭代”在工业界的可行性。

针对 1688 业务在星云平台训练 LLM 的需求，本项目进行了本地化适配：

底层框架采用 TuningFactory（LLaMA-Factory 内部 Fork），封装 ODPS 数据源及多队列适配；
对接星云训练平台，通过 API 拉取日志，无需人工介入；
将数据接入、镜像构建、分布式训练等工程痛点沉淀至 SKILL.md。

本文 AutoResearch-LLM 主要包含以下章节：

背景与定位
流水线设计
工程实现
踩坑实录
横向对比

阅读建议：

关注 Agent 调参流程：重点阅读§2 流水线设计；
关注工程避坑：重点阅读§4 踩坑实录（含 PyTorch 2.6、BLEU 异常等通用问题）；
希望复用框架：参考§3 工程实现，替换对应平台 API 即可适配 K8s/Slurm/PAI 等环境。

1. 背景

1.1 缘起

在之前的闭环图中，数据回流、特征生成等环节已有成熟基建，唯独“模型训练”仍依赖人工：调整超参、提交任务、监控日志、复盘结果，效率低下。

请求 → 召回 → 曝光/点击/成交 → 样本反馈 → 模型训练 → 线上服务 → 请求                                              ▲                                              │                                      这一环最难自动化

此前在 CV 分类领域（CIFAR-10）验证过 auto_research_cv_cls_demo，实现了 Agent 按 SKILL 跑实验的小闭环。但将其迁移至 1688 LLM 微调场景面临更多挑战：

维度	CV demo	LLM 实战
训练框架	手写 main.py	TuningFactory（LLaMA-Factory Fork）
数据	CIFAR-10 本地 tar	ODPS 表（百万行级）
模型	ResNet18~50	Qwen3-1.7B ~ 35B-A3B（含 MoE）
并行	单卡	DeepSpeed ZeRO-2/3 + Megatron Turbo
训练时长	30~60 分钟	1~24 小时
评估	acc 直接输出	generate + BLEU/ROUGE

1.2 参考的两份工作

本项目借鉴了公司内部两份 AutoResearch 落地实践：

TAO-AutoResearch：4 个子 Agent 协作，Git Worktree 隔离，支持多平台后端，工程化程度高；
Pailitao-AutoResearch：三阶段流水线（理解/方案/验证），Git 分支隔离，提供最小 Demo，适合入门。

auto_research_llm 的演进路径：Pailitao Demo（骨架）→ CV Demo（可行性验证）→ LLM 实战（1688 场景适配）。主要升级点包括：

升级点	前作 CV demo	auto_research_llm
任务领域	CV 分类	LLM 微调（Query 改写/同款判定/重排）
训练框架	单文件 PyTorch	TuningFactory + ROLL
数据源	本地 tar	ODPS + OSS JSON
训练方式	单一循环	SFT/DPO/蒸馏/RL 多种策略
并行	单卡	DeepSpeed/Megatron + EP
评估	acc	predict_with_generate (BLEU/ROUGE)

各方案定位对比：

入门 ─────────────────── 进阶 ─────────────────── 更完整Pailitao demo → 前作 CV demo → auto_research_llm → TAO-AutoResearch（最简骨架）    （CV 验证）      （1688 LLM 版）       （多 Agent+ 多平台）

1.3 目前做到什么程度

维度	能力
训练方式	已验证：SFT 全参/LoRA/MoE、DPO LoRA、离线蒸馏；配置就绪：在线 KD、RL(GRPO)
场景	1688 电商 Query 改写/同款判定/重排打分
基座	Qwen3 系列（1.7B/8B/32B/35B-MoE）
数据	ODPS（主）+ OSS JSON
存储	OSS/MOS/NAS
分布式	DeepSpeed ZeRO-2/3 / Megatron Turbo + EP
评估	Trainer 内置 predict_with_generate 自动输出 BLEU-4/ROUGE-L

1.4 仓库结构

auto_research_llm/├── SKILL.md              ← Agent 主入口（Pipeline/参数/Debug）├── submit.sh / kill.sh   ← 任务提交与终止├── configs/              ← 训练/推理配置（一文件一方式）│   ├── sft_lora.sh       ← 单卡 LoRA│   ├── sft_lora_multi.sh ← 多卡 LoRA + DeepSpeed│   ├── sft_full.sh       ← 全参 + DeepSpeed│   ├── sft_lora_moe.sh   ← MoE + Megatron Turbo│   ├── distill.sh        ← KD Loss 蒸馏│   ├── dpo_lora.sh       ← DPO│   ├── rl_roll.sh        ← GRPO（基于 ROLL）│   └── infer.sh          ← 单独推理├── scripts/              ← 同步、数据准备、格式转换脚本├── scenarios/            ← 场景定义（README/DDL/数据/指标）├── TuningFactory/        ← submodule（分支 openlm）├── experiment_logs/      ← 自动下载的训练日志└── experiment_results.csv← 实验记录入口

2. 流水线设计

沿用三阶段写法，明确各阶段产出物，便于 Agent 长上下文接力：

[用户输入] 研究目标 + 数据样例 + 预算   │   ▼[阶段 1] 场景理解与基线分析   ├─ 7 维诊断（基座/数据/Prompt/训练方式/Eval/Baseline 复盘）   ├─ 跑 baseline → 获取 eval_loss & 任务指标   └─ 产出 analysis_report.md（锁定 MODEL_NAME）   │   ▼[阶段 2] 实验方案设计   ├─ 匹配技术候选库（15+ 技术点）   ├─ 按六级参数清单展开   └─ 产出 improve_guide.md   │   ▼[阶段 3] 自动化实验验证   ├─ 单变量探索 → 正交组合 → 数据兜底   ├─ 每个实验：生成 config → push 分支 → submit → 监控 → 评估 → 入 csv   └─ 产出 experiment_results.csv + final_report.md

2.1 第一阶段：场景理解与基线分析

Agent 按七个维度进行诊断，前六维在 Baseline 前完成，第七维为复盘：

#	维度	何时检查	诊断问题	薄弱信号
1	基座模型	baseline 前	规模/能力是否匹配？	简单任务用大模型浪费；长文本用小模型截断
2	数据质量	baseline 前	错标比例？	错标>10% → 先清洗
3	数据规模	baseline 前	样本数是否充分？	生成<5K/分类<1K → 离线蒸馏扩数据
4	Prompt 模板	baseline 前	Instruction 是否清晰？	输出混乱 → 改 Instruction（通常 +5~10%）
5	训练方式	baseline 前	匹配 SFT/蒸馏/DPO/RL？	仅有 (q,a)→SFT；有偏好对→DPO
6	Eval 配置	baseline 前	指标 Parse 是否配好？	漏配 eval 或 predict_with_generate
7	Baseline 复盘	baseline 后	LR/过拟合/LoRA rank？	Loss 震荡→LR 大；Train↓Eval 不降→过拟合

注意：本阶段锁定基座模型（MODEL_NAME），后续实验不允许 Agent 擅自更换，避免越界探索。

2.2 第二阶段：实验方案设计

将技术点整理为清单并设定优先级。一级参数示例：

一级（直接影响效果）

参数	取值范围	备注
`learning_rate`	LoRA: 1e-4~5e-4; 全参：5e-6~5e-5	最敏感
`lora_rank / lora_alpha`	8/16/32/64/128 (alpha=2×rank)	表达力
`lora_target`	`q_proj,k_proj...` / `all-linear`	all-linear 参数量×3
`num_train_epochs`	SFT 2~5 / DPO 1~3	真实训练轮数
Prompt 模板	instruction 文本改写	通常 +5~10%
`cutoff_len`	1024 / 2048 / 4096 / 8192	序列长度，影响显存

技术候选库精简至 15+ 项，涵盖 SFT、蒸馏、RL 及数据优化等方向。

2.3 第三阶段：自动化实验验证

2.3.1 实验分支管理

每个实验对应 TuningFactory 的一个分支，命名规范为 experiment-{编号}-{场景}-{方式}-{变量}。脚本 sync_to_tuning_factory.sh 自动完成拉取分支、复制配置、提交推送，实现实验隔离。

2.3.2 任务提交与监控

通过 submit.sh 提交任务，利用星云 HTTP API 监控状态和日志，无需人工打开浏览器。Agent 可利用 /loop 能力自动轮询状态、提取指标并收尾。

# 状态查询curl -s "https://<meta-api>/nebula/meta?task_id=${TASK_ID}"# 日志下载curl -L -o experiment_logs/${EXP}.zip "https://<log-download-api>/logview/logs/download/${APP_ID}"

2.3.3 自动指标提取

训练结束后，Agent 正则提取日志中的 eval_loss、predict_bleu-4、predict_rouge-l 并写入 experiment_results.csv。

experiment_results.csv：实验级明细，记录核心变量与指标；
final_report.md：研究级总结，对比增益并给出建议。

3. 工程实现要点

3.1 数据接入

默认对接 ODPS 表，采用 Alpaca 三字段 Schema（instruction/input/output）。提交时需配置 ODPS 项目、AccessID/Key 及表路径。

--prompt=instruction --query=input --response=output--tables=${INPUT},${EVAL_INPUT} --odps_project=${ODPS_PROJECT}

3.2 训练配置脚本

configs/*.sh 承担三重角色：本地修改入口、Submodule 同步副本、远端执行脚本。只需修改顶部的模型、任务、数据源及超参变量，其余由模板自动拼接。

配置	适用
`sft_lora.sh`	单卡 LoRA
`sft_lora_multi.sh`	多卡 LoRA + DeepSpeed
`sft_full.sh`	全参 + DeepSpeed
`sft_lora_moe.sh`	MoE + Megatron Turbo
`distill.sh`	KD Loss 蒸馏
`dpo_lora.sh`	DPO
`rl_roll.sh`	GRPO（需单独 clone ROLL）

3.3 自动评估

利用 TuningFactory Trainer 自带的 --predict_with_generate=True，训练结束直接输出 BLEU/ROUGE 指标，省去单独推理步骤。需设置 --enable_thinking=False 以避免 Qwen3 Thinking Mode 干扰评估（详见 4.2）。

3.4 effective_batch 经验

公式：eff_batch = world_size × per_device_batch × gradient_accumulation。推荐值：SFT 7B(64~128), SFT 35B+(32~64), DPO(32~64)。调参顺序：先调大 batch_size 至显存极限，再用 accumulation 凑 eff_batch，最后按√eff_batch 微调 LR。

3.5 平台问题：星云 skill 兜底

采用分层 Skill 策略：平台级问题（OOM/NCCL/镜像等）交由官方 nebula-support Skill 处理；业务级问题（DeepSpeed ckpt/Thinking Mode/OSS Endpoint）保留在项目 SKILL.md 中。

4. 踩坑实录

4.1 PyTorch 2.6 + DeepSpeed ZeRO + load_best 冲突

现象：反序列化 DeepSpeed LossScaler 时报错 Unsupported global。

根因：PyTorch 2.6 默认 weights_only=True，DeepSpeed 对象不在白名单。触发点包括 Auto-resume 和 load_best_model_at_end。

修复：禁用 --load_best_model_at_end，使用 --overwrite_output_dir=True。全参训练加 --save_only_model=True。需 Best Ckpt 时手动解析 trainer_state.json。

4.2 predict BLEU 异常低（<5）

现象：eval_loss 正常但 BLEU 极低。

根因：Qwen3 默认开启 Thinking Mode，生成内容包含 <think>...</think> 标签，导致 BLEU 计算偏差。

修复：所有配置脚本默认添加 --enable_thinking=False。实测 BLEU 从 1.82 提升至 46.32。

4.3 oss_endpoint 格式因队列而异

现象：切换 GPU 队列时报域名白名单错误。

结论：同一 Region 下，不同队列（IDC 线路）的 OSS Endpoint 白名单规则不同。例如 MI308X 需用 cn-hangzhou.oss.aliyuncs.com，而 H20/H200 需用 oss-cn-hangzhou-internal.aliyuncs.com。切换队列时需同步修改 Endpoint。

5. 同期工作横向对比

按入门门槛由低到高排列：

项目	门槛	领域	框架	平台
karpathy/autoresearch	最低	单文件实验	任意	本地 GPU
Pailitao-AutoResearch	低	多模态/通用	自研	星云
前作 CV demo	低	CV 分类	PyTorch	星云
auto_research_llm（本文）	中	1688 LLM 微调	TuningFactory+ROLL	星云全队列
TAO-AutoResearch	高	搜索召回/排序	自研+AOP	多平台