OpenResearch nanochat瓶颈诊断报告：研究智能体自我诊断案例解析-平芜编程栈

OpenResearch nanochat瓶颈诊断报告：研究智能体自我诊断案例解析

【免费下载链接】OpenResearchTurn your coding agents into research agents项目地址: https://gitcode.com/GitHub_Trending/op/OpenResearch

OpenResearch是一个把编码智能体（Claude Code、Codex、Cursor 等）变成研究智能体的本地优先工作区：它能让 AI 自主查文献、提假设、跑实验并产出可复核的研究产物。本文以它内置的nanochat 训练演示为真实案例，完整拆解一份由研究智能体写出的瓶颈诊断报告——从证据收集、文献对照到给出下一个单变量实验，帮你快速理解"研究智能体是怎么做科研的"。

🧪 案例背景：一次完整的 nanochat 训练跑完了，但模型"不太聪明"

演示脚本会在 Apple Silicon / CPU 上从零训练一个极简 GPT（6 层、约 7350 万参数），做预训练 + SFT 微调，最后用chat_cli提问验证。完整执行记录保存在 demo/nanochat/run-output.txt。

结果却很有意思：当被问"法国的首都是哪里？"时，模型先答对了Paris，紧接着陷入数字死循环：

Paris is a city known for its historical and cultural significance. The capital of France is Paris, a 1715,345,345,345,345,345,345...

这段"答对又复读"的现场输出被原样存档在 demo/nanochat/evidence/final-inference.txt。问题来了：到底是哪里出了瓶颈？换数据？换 SFT 配方？还是干脆加参数？

研究智能体没有拍脑袋，而是先收集证据。

🔍 诊断第一步：让证据说话，而不是凭感觉

OpenResearch 有一条核心技能——实验证据（见 agent-skills/orx-evidence/SKILL.md）：运行的日志和指标就是证据通道，"如果结果没写在日志里，之后就无法复核"。

围绕这次训练，演示保留了一个紧凑的证据包（demo/nanochat/evidence/README.md）：

证据文件	内容
training-metrics.csv	逐步的 loss、验证集 BPB、吞吐量，共 6500+ 行
evaluation-metrics.json	基础模型 BPB 与 CORE 评测任务成绩
checkpoints/base/meta_005000.json	最终 base 检查点的完整超参数元数据
run-manifest.json	全部产物清单（含字节数与 SHA-256 哈希）

两条关键证据直接改变了诊断方向：

损失还在下降，训练就停了：base 验证集 BPB 从 step 4000 的 1.1878 → 4500 的 1.1743 → 5000 的 1.1658，没有出现过平台期——说明模型还没把现有数据和算力"吃透"。
数据量严重不足：预训练只用了 8192 万 token，对应每参数仅3.53 个 token，远低于 nanochat 代码里默认的目标比例 12。

nanochat 本身就是一个围绕"缩放定律"设计的最小训练框架——参数量和 token 量应大致等比例增长。下面这张 IsoFLOP 曲线正是该思想的经典图示（来自 nanochat 仓库 demo/nanochat/base/dev/scaling_laws_jan26.png）：

同时，base 模型的 CORE 知识评测接近随机水平（Wikidata 0.0、OpenBookQA 0.25、Winogrande 0.56），而 SFT 后验证 BPB 虽从 1.0174 降到 0.7389，却换来的是"答对 Paris 后开始复读"——典型的拟合了 SFT 分布但没获得广博知识。

📚 诊断第二步：对照文献，排除"换 SFT 数据"的干扰项

报告没有止步于本项目数据，而是引用了四篇经典工作来交叉验证（完整引用见 demo/nanochat/reports/nanochat-bottleneck-diagnosis.md）：

Chinchilla（Hoffmann et al., 2022）：最优配比约 20 token/参数，本项目 3.53 连参考线都不到；
LIMA（Zhou et al., 2023）：知识与推理主要来自预训练，SFT 只教"如何表达"，且验证困惑度会在生成质量见顶后继续下降——正好解释"BPB 好看但生成复读"；
TinyStories（Eldan & Li, 2023）：极小模型在简化领域内也能生成连贯文本，说明"小"不是复读的唯一原因；
TAAH（Gunasekar et al., 2023）：数据质量能让小模型更高效，是后续可优化的轴，但不是当前的第一瓶颈。

综合结论一句话：首要瓶颈是预训练不足，模型规模构成次要天花板；SFT 数据质量和配方不是主因，但过短训练 + 贪心解码放大了复读现象。

🧪 诊断第三步：给出下一个"单变量"实验

一份好的瓶颈诊断，落点永远是可执行的下一步。报告推荐了一个只动一个变量的消融实验：

架构（d6）、分词器、预训练数据、优化器、batch、SFT 配方全部保持不变；
从头训练至代码默认目标--target-param-data-ratio=12：约2.78 亿 token / 16992 步（对比当前的 8192 万 / 5000 步）；
在 5000、约 11000、16992 步处存检查点，逐一报告验证 BPB、CORE 任务和固定提示生成；
对最终 base 检查点套用同一份 1500 步 SFT 配方，报告 ChatCORE 与 MMLU/GSM8K 成绩。

这个设计的好处是判据清晰：若基准分数大幅提升，就继续下一轮 SFT 早停/数据精选；若 loss 降了但评测不动，下一个瓶颈就是模型容量或预训练领域覆盖——届时应比较同算力下更大深度，而不是回头调 SFT。

想复现完整工作区，可以在新实验中运行 demo/nanochat/base/runs/runcpu.sh。