experiment-pipeline

实验流程

一个结构化的 4 阶段框架，用于执行研究实验，涵盖从初始实现到消融研究的全过程，并设有尝试次数预算和门槛条件，以避免浪费精力。该框架遵循 EvoScientist 论文中的 Experiment Tree Search 设计：工程师 Agent 迭代生成可执行代码、运行实验，并在每个阶段记录结构化的执行结果。

何时使用此技能

• 用户已有计划中的实验，需要组织执行工作流
• 用户希望系统地将新方法与基线进行验证
• 用户询问实验阶段、尝试次数预算或何时进入下一阶段
• 用户需要在测试自己方法之前复现基线结果
• 用户提到“实验流程”“先跑基线”“消融研究”“阶段预算”或“实验执行”

流程理念

实验失败有两个原因：顺序错误，或没有停止标准。 大多数研究人员会直接测试自己的新方法，却不先验证基线设置，然后纳闷结果为何不合理。还有些人没有设置预算，花数周调整超参数，希望下一次运行就能成功。

这个 4 阶段流程能同时解决这两个问题。它会严格规定顺序（每个阶段都会验证下一阶段所依赖的假设），并分配尝试次数预算（促使大家系统思考，而不是蛮力迭代）。

开始之前：加载既有知识

如果你是从 research-ideation 进入，研究提案（步骤 7）会提供实验计划，包括数据集、基线、指标和消融设计，可直接对应下文的第 1 至第 4 阶段。

进入流程前，先加载此前周期的 Experimentation Memory（M_E）：

1. 参考 evo-memory 技能 → 在 /memory/experiment-memory.md 中读取 M_E
2. 通过比较每条记录的 Context 和 Category 与当前问题，选出与当前实验领域最相关的前 1 条记录（k_E=1）
3. 所选策略将指导超参数范围（第 2 阶段）、调试方法（第 1 至第 3 阶段）以及所有阶段的训练配置
4. 如果 M_E 尚不存在（首次周期），跳过此步骤并继续——流程完成后，ESE 会将你的结果用作 M_E 的种子数据

4 阶段流程概览

每个阶段都遵循 生成 → 执行 → 记录 → 诊断 → 修订 循环：

阶段	目标	预算（N_E^s）	门槛条件
1. 初始实现	运行基线代码并复现已知结果	≤20 次尝试	指标与报告值相差不超过 2%（或处于报告的方差范围内）
2. 超参数调优	针对你的设置优化配置	≤12 次尝试	配置稳定，3 次运行的方差 < 5%
3. 提出的方法	实现并验证新方法	≤12 次尝试	在主要指标上优于调优后的基线，且 3 次运行结果一致
4. 消融研究	证明各组件的贡献	≤18 次尝试	所有主张均有受控实验作为证据

每个阶段都会将产物保存到 /experiments/stageN_name/。

阶段循环

在每个阶段中，每次尝试都重复以下循环：

1. 生成：为此次尝试提出假设或计划。你具体要尝试什么？预期会发生什么？
2. 执行：运行实验。记录准确的配置、代码变更和运行时间。
3. 记录：立即使用阶段日志模板记录结果，包括指标和观察结果。
4. 诊断：将结果与预期进行比较。如果一致，评估是否满足门槛条件；如果不一致，加载 experiment-craft，按照 5 步诊断流程进行排查。
5. 修订：根据诊断结果，进入下一阶段（满足门槛）或规划下一次尝试（未满足门槛）。

阶段 1：初始实现

目标：找到或生成可执行的基线代码，并验证其能够复现已发表的结果。此阶段对应论文的“初始实现”——工程师 Agent 搜索可用代码、运行代码并记录结构化的执行结果。

为什么重要：如果无法让基线运行并复现已知结果，那么后续所有比较都毫无意义。初始实现可以验证数据流水线、评估代码、训练基础设施以及对前人工作的理解。

预算：≤20 次尝试（N_E^1=20）。基线可能很棘手——论文中缺少细节、版本不匹配、未报告预处理步骤等。20 次尝试足以留出调试空间，同时避免无休止地折腾。

门槛：主要指标与报告值的差距在 2% 以内（若提供了报告的方差，则以该方差为准）。

流程：

1. 找到原始基线代码（官方仓库、重新实现的版本，或根据论文描述编写）
2. 在你的环境中运行代码——解决依赖问题并修复兼容性问题
3. 精确匹配论文中的训练配置（数据集划分、预处理、超参数）
4. 运行并比较指标。如果差距 >2%，诊断差异原因
5. 常见陷阱：随机种子不同、数据划分不同、未报告的数据增强、框架版本不同

何时加载 experiment-craft：如果前 1-5 次尝试都失败严重（差距 >10%），请切换到 5 步诊断流程，在继续消耗尝试次数之前找出原因。

输出：/experiments/stage1_baseline/，包含结果、配置和经过验证的基线代码。

详细的初始实现检查清单请参阅 references/stage-protocols.md。

阶段 2：超参数调优

目标：为你自己的特定设置找到最优的超参数配置。

为什么重要：已发表的超参数是针对作者的设置调优的。你的硬件、数据版本、框架版本或细微的实现差异，可能意味着他们的配置并不适合你。现在进行调优，可以避免因基线欠佳而干扰新方法的结果。

预算：≤12 次尝试。超参数调优的收益会逐渐递减。如果经过 12 次有计划的尝试仍未找到稳定配置，问题很可能不在超参数层面。

门槛：找到稳定配置——使用不同随机种子进行 3 次独立运行，方差 <5%。

流程：

1. 确定最敏感的超参数（通常包括：学习率、批量大小、损失权重）
2. 针对最敏感的参数开始粗略搜索
3. 根据结果缩小范围，然后转向下一个参数
4. 使用 3 次独立运行验证最终配置

调优优先级：学习率 → 批量大小 → 损失权重 → 正则化 → 特定于架构的参数。此顺序反映了通常的敏感程度。

何时加载 experiment-craft：如果多次运行的结果极不稳定（方差 >20%），很可能存在训练不稳定问题。请使用诊断流程。

输出：/experiments/stage2_tuning/，包含调优日志、最终配置和稳定性验证结果。

预算的制定依据和调整规则请参阅 references/attempt-budget-guide.md。

阶段 3：提议的方法

目标：实现并验证你的新方法，证明其效果优于经过调优的基线。

重要性：这是核心贡献。但由于你已经验证了基线（阶段 1）并优化了配置（阶段 2），因此观察到的任何改进都确实归因于你的方法，而不是更优的调优方案或有问题的基线。

预算：≤12 次尝试。如果底层思路合理，你的方法应能在合理次数的迭代内奏效。尝试次数过多说明存在根本性问题，而非调优问题。

门槛：主要指标优于经过调优的基线。至少 3 次运行的结果应保持一致。

流程：

1. 逐步实现核心方法——不要一次性添加所有内容
2. 测试各组件与基线流程的集成情况
3. 完成完整训练，并与阶段 2 的结果进行比较
4. 如果表现不佳，找出导致差距的组件

集成策略：将方法的各个组件逐一添加到可正常工作的基线中。每个新增组件的表现都应控制在基线的 20% 以内——如果某个组件单独导致性能下降超过 20%，应先定位问题并进行调试，再继续推进。切勿一次性集成完整方法。

何时加载 experiment-craft：当你的方法在正确实现后仍逊于基线时。5 步诊断流程有助于区分实现错误和根本性问题。

关键决策——失败分类：如果耗尽尝试预算后，方法仍逊于基线，则移交给 evo-memory 进行 IVE（Idea Validation Evolution，想法验证进化）——这是 evo-memory 的职责，而非此技能的职责。以下两种情况会触发 IVE：

1. 没有可执行代码：在任何阶段都无法在预算内找到可正常工作的代码。
2. 表现差于基线：实验已完成，但方法表现不佳。

evo-memory 技能会将失败分类为：

• 实现失败：存在错误或遗漏技巧 → 可在未来周期重试。
• 方向存在根本性问题：核心思路行不通 → 更新构思记忆，避免再次尝试。

输出：/experiments/stage3_method/，包含方法代码、结果以及与基线的比较。

阶段 4：消融研究

目标：证明你的方法中的每个组件都对最终结果有实质性贡献。

重要性：对于你方法中的每个部分，审稿人都会问：“组件 X 真的有必要吗？”没有消融实验，你就无法回答。更重要的是，消融实验能帮助你了解方法为何有效——有时你以为重要的组件并不重要，反之亦然。

预算：≤18 次尝试。消融需要进行多项受控实验——每个待消融的组件各做一项实验，此外还要测试交互效应。18 次尝试足以研究包含 4～5 个组件的方法。

门槛：每项声称的贡献都有受控实验作为依据，且实验能显示其影响。

流程：

1. 列出你声称能够提升性能的方法组件
2. 设计消融实验：每次移除一个组件，并测量其影响
3. 对于存在交互作用的组件，测试其交互效应
4. 确认移除任何单个组件都不会提升结果（否则该声称不成立）

三种消融设计：

• 逐一留出：逐个移除每个组件，展示各组件的边际贡献。
• 逐步添加：从基线开始，逐个添加组件，展示增量收益。
• 替换：将你的组件替换为其他方案，展示你的组件优于其他方案，而不只是优于什么都不做。

何时加载 experiment-craft：如果消融结果与你的假设相矛盾（移除组件反而提升了结果），请使用诊断流程来了解原因。

输出：/experiments/stage4_ablation/，包含消融结果表和各组件分析。

详细的消融设计模式请参阅 references/stage-protocols.md。

使用 experiment-craft 进行诊断

当某个阶段的尝试失败时，请参考 experiment-craft 技能进行结构化诊断：

1. 遵循 experiment-craft 诊断协议
2. 运行 5 步诊断流程（观察、提出假设、测试、得出结论、制定建议）
3. 诊断不会占用阶段预算——这是免费的分析步骤
4. 诊断输出（建议方案）将成为你下一次尝试的计划
5. 返回流水线，并在轨迹日志中记录诊断结果

触发时机：任何阶段的尝试失败后。以下情况尤为重要：

• 阶段 1：失败尝试达到 5 次以上（与报告指标的差距 >10%）
• 阶段 2：多次运行之间的方差 >20%
• 阶段 3：方法持续表现不如基线
• 阶段 4：消融结果与你的假设相矛盾

代码轨迹日志记录

所有阶段中的每次尝试都应采用结构化格式记录，不仅要记录你做了什么，还要记录原因和收获。这些日志会输入到 evo-memory 的实验策略演进（ESE）机制中。

每次尝试都要记录：

• 尝试编号和阶段
• 假设：你的预期及理由
• 代码更改：修改内容摘要（无需完整差异，但要记录关键更改）
• 结果：指标和观察结果
• 分析：假设是否得到证实或被推翻，以及你学到了什么

完整日志格式以及日志如何输入 evo-memory，请参阅 references/code-trajectory-logging.md。

反直觉的流水线规则

执行实验时优先遵循以下规则：

1. 初始实现不是在浪费时间：它可以验证整个基础设施，包括数据流水线、评估代码和训练设置。跳过这一步，意味着后续每项结果都建立在未经验证的基础上。许多“方法不起作用”的问题，实际上是基线设置出了问题。

2. 预算限制能防止陷入无休止的尝试：固定的尝试预算会迫使你系统地思考。知道自己只有 12 次尝试时，你会设计每次尝试，让它尽可能提供更多信息。没有限制的话，第 47 次尝试很少比第 12 次更有信息量——只是更加绝望。

3. 阶段顺序不可更改：每个阶段都会验证下一阶段所依赖的假设。跳过阶段 1，意味着阶段 3 的结果可能因基线存在问题而出错。跳过阶段 2，意味着阶段 3 的改进可能只是超参数更好，而不是方法更好。没有捷径可走。

4. 消融不是可有可无的收尾工作：它是证明方法奏效的原因符合预期的主要证据。一个优于基线却没有消融实验的方法，是一个你并不理解的方法。评审人明白这一点。

5. 失败的尝试是数据，不是浪费：每次失败的尝试都会缩小搜索空间，并揭示问题的某些特征。仔细记录失败——这些记录会提供给 evo-memory，避免未来的研究者重蹈覆辙。

6. 提前终止是一项特性：在预算用尽前停止是明智之举，而不是偷懒。如果经过系统尝试后发现目标关卡显然无法达成，就应将问题升级至 evo-memory IVE，而不是把剩余预算耗在越来越随机的变化上。

移交给论文写作

四个阶段全部完成后，将以下成果交给 paper-writing：

成果	来源阶段	用途
初始实现结果	阶段 1	对比表、设置验证
最优超参数配置	阶段 2	可复现性部分
方法与基线的对比	阶段 3	主要结果表
消融研究结果	阶段 4	消融表、贡献主张
代码轨迹日志（所有阶段）	所有阶段	方法部分的详细信息、补充材料
实现细节和技巧	阶段 1-3	方法部分、可复现性（记录在轨迹日志的 Analysis 字段和 [Reusable] 标签中）

还应将结果提供给 evo-memory，用于演进更新：

• 如果任一阶段耗尽预算后仍没有可执行代码，或阶段 3 的方法表现不如调优后的基线 → 触发 IVE（想法验证演进）
• 如果所有阶段均成功 → 触发 ESE（实验策略演进）

技能集成

开始前（加载记忆）

参考 evo-memory 技能，读取实验记忆： → 读取 /memory/experiment-memory.md 中的 M_E

失败时（任一阶段内）

参考 experiment-craft 技能，执行 5 步诊断： → 运行诊断 → 返回流水线

触发 IVE 时（预算耗尽或方法表现不佳）

参考 evo-memory 技能，对失败进行分类： → 执行 IVE 协议

流水线成功时（4 个阶段全部完成）

参考 evo-memory 技能，提取策略： → 使用轨迹日志执行 ESE 协议

移交给论文写作

参考 paper-writing 技能： → 移交所有阶段成果

参考导航

主题	参考文件	使用时机
各阶段的检查清单和模式	stage-protocols.md	查看各阶段的详细指南
尝试次数预算的依据和调整	attempt-budget-guide.md	预算感觉过紧或过宽松时
代码轨迹日志格式	code-trajectory-logging.md	为 evo-memory 记录尝试过程
阶段日志模板	stage-log-template.md	记录单个阶段的进展
流水线跟踪模板	pipeline-tracker-template.md	跟踪完整的 4 阶段流水线