企业官网建设流程全解析

OpenResearch demo evidence目录全解：快速读懂checkpoints、评测指标与run-manifest

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

OpenResearch 是一个把编程智能体（Coding Agent）变成科研智能体的开源工具，它内置的demo/nanochat/evidence/目录就是一份紧凑的实验证据包：完整记录了一次在 Apple Silicon 上从零训练 nanochat 模型的全过程，包括 checkpoints 元数据、评测指标（BPB、CORE 任务）和 run-manifest 清单。本文带你从零读懂这些文件——无需下载几十 GB 的训练工作区，几 MB 的小文件就能验证一次完整的 LLM 训练实验。

为什么需要 evidence 目录？

一次真实的 LLM 训练会产生海量产物：模型权重、优化器状态、下载的数据集、评测语料……加起来通常是数 GB 到十几 GB。这些文件放在 Git 仓库里既不现实，也难以分发。

OpenResearch 的做法很聪明：把「可检查的小输出」单独打包成证据包，把「大而笨重」的产物留在本地运行目录。正如 evidence 包的 README 所说，这个包保留了检查实验所需的最小输出集合，同时不打包多 GB 的训练工作区。

简单说：evidence 目录 = 这次实验的"证据链"，每一环都能核对、可复现。

evidence 目录结构一览

整个证据包只有 8 个有效文件，结构非常清晰：

注意 checkpoints 下的文件名meta_005000.json、meta_001499.json中的数字就是训练步数（step）：base 阶段训了 5000 步，SFT 阶段训了 1499 步。

checkpoints：两个检查点告诉你"模型训到哪了"

检查点元数据是判断模型状态的核心。以 base 检查点为例，meta_005000.json 记录了四个关键块：

• val_bpb：验证集 BPB（Bits Per Byte）为 1.1658，数值越低模型越好；
• model_config：模型结构——6 层 Transformer、512 序列长度、32768 词表；
• user_config：训练超参——总 batch size 16384、5000 步、各组件学习率等；
• loop_state：训练环状态——累计训练时长 7893 秒，约2.2 小时。

SFT 阶段的 meta_001499.json 则显示val_bpb降到了0.7389，比 base 阶段下降了约 37%——这正是"对话微调让模型更懂指令"的量化体现。

这两个检查点真正的权重文件（model_005000.pt约 294 MB、optim_005000_rank0.pt约 546 MB）并未打包进仓库，但 run-manifest 里记录了它们的字节数和 SHA-256 哈希，保证"本地有文件"和"证据里有文件"可以严格区分。

评测指标：从训练曲线到最终问答

1️⃣ training-metrics.csv：逐 step 的训练指标

training-metrics.csv 共 6502 行，表头为：

phase, step, loss, validation_bpb, tokens_per_second, total_minutes

以 base 阶段开头几行为例：初始 loss 约 10.40、验证 BPB 约 3.20，随着训练推进不断下降；tokens_per_second（每秒处理 token 数）稳定在 1 万上下，total_minutes记录累计耗时。想看完整训练曲线，直接按这个文件画图即可。

2️⃣ evaluation-metrics.json：三个层次的评测结果

evaluation-metrics.json 按层次组织：

3️⃣ final-inference.txt：最直观的"验收测试"

final-inference.txt 记录了用最终 SFT 检查点（step 1499）的推理问答：

Prompt:What is the capital of France?Response:Paris（后续出现重复，是小型模型的典型现象）

虽然这个小模型（仅 6 层）回答出现了重复循环，但它确实答对了"Paris"——这就是整个 demo 要证明的端到端能力：分词器训练 → base 预训练 → SFT → 推理问答，全链路跑通。

run-manifest.json：可审计的"实验清单"

run-manifest.json 是整个证据包的灵魂，分三块：

① 运行信息（第 3-8 行）

记录复现命令、设备和状态：

command: bash runs/runcpu.sh && python -m scripts.chat_cli -p "..." device: mps（Apple Silicon 加速） status: completed

② 文件清单（第 9-66 行）

每个产物文件都带有path、kind（类型）、bytes（大小）、sha256（哈希）和bundledAt（打包位置）。例如 base 检查点元数据：

• 原始路径：base_checkpoints/d6/meta_005000.json
• 类型：checkpoint_metadata
• SHA-256：d06eaa26...（可逐字节核验）
• 打包位置：evidence/checkpoints/base/meta_005000.json

模型权重文件的bundledAt为null，明确表示"存在于运行工作区，但未打包进仓库"。

③ 有意省略的目录（第 67-83 行）

这种"省略也要登记"的设计，让后续分析可以精确区分**"证据包里的文件"和"本地运行区才有的文件"**，是科研可复现性（reproducibility）的典范做法。

如何生成与复现 evidence？

• 重新生成指标文件：training-metrics.csv和evaluation-metrics.json由 scripts/generate-demo-evidence.mjs 从录制日志重新生成，保证指标与原始日志一致；
• 复现完整工作区：在新实验中运行bash runs/runcpu.sh，即可重建包含模型权重、数据集在内的完整运行目录（参见 runs/runcpu.sh）。

⚠️ 安全提醒：tokenizer.pkl使用 Python pickle 格式，README 特别强调只应通过 nanochat 官方可信代码加载，切勿随意反序列化。

快速上手：按这个顺序读

1. 先看 README，理解证据包的设计意图；
2. 打开 run-manifest.json，掌握"哪些文件在、哪些文件不在"；
3. 对比 base 与 sft 两个检查点的val_bpb，理解训练效果；
4. 用 training-metrics.csv 画 loss 曲线，结合 evaluation-metrics.json 看评测结果；
5. 最后读 final-inference.txt，感受模型实际输出。

小结：OpenResearch 的 evidence 目录用 7 个小文件构建了一条完整的实验证据链——checkpoints 说明"模型是什么状态"，评测指标回答"效果如何"，run-manifest 保证"一切可核验"。这正是科研智能体工作流中"用证据说话"理念的落地范本。

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