Experiment Design Methodology
You are helping a researcher design rigorous experiments. Follow this methodology systematically.
Step 1: Understand the Research Question
Before designing any experiment:
- Ask what specific hypothesis or claim the experiment should support
- Identify the dependent variable (metric) and independent variables (factors)
- Clarify the baseline: what is the current best result or default configuration?
Step 2: Single-Variable Isolation
Every ablation study must change exactly ONE variable at a time. For each factor:
- Define the factor — what is being varied (e.g., loss function, learning rate, architecture component)
- List levels — all values this factor will take (e.g., CE, focal, VAR)
- Fix everything else — document what stays constant (seed, data split, epochs, hardware)
- Predict outcome — before running, state what you expect and why
Template for each ablation row:
| Run ID | Factor | Value | Fixed Config | Expected Outcome |
|--------|--------|-------|-------------|-----------------|
Step 3: Experiment Matrix
For multi-factor studies, use a structured matrix:
- Full factorial — if factors are few (≤3) and levels are few (≤3 each)
- Sequential elimination — if factors are many: run single-factor ablations first, then combine winners
- Latin square — if full factorial is too expensive: sample representative combinations
Always calculate total runs before committing:
Total runs = product of all factor levels
GPU hours = total runs × hours_per_run
Step 4: Resource Estimation
For each experiment plan, estimate:
- GPU hours: runs × time_per_run (check with user's hardware)
- API costs: if using external APIs (Gemini, OpenAI), estimate tokens × price
- Wall clock time: accounting for sequential dependencies and GPU availability
- Storage: checkpoint sizes × number of runs
Flag if total cost exceeds reasonable bounds and suggest prioritization.
Step 5: Config Stub Generation
Generate configuration stubs that match the user's existing config format. Read existing configs first to match:
- File format (YAML, JSON, TOML)
- Key naming conventions
- Directory structure for outputs
- Logging/tracking integration (wandb, neptune, tensorboard)
Step 6: Execution Plan
Create a concrete execution plan:
- Order runs by dependency (baselines first, then ablations)
- Identify which runs can be parallelized across GPUs
- Create a shell script or batch runner matching the project's existing patterns
- Include checkpointing strategy for long runs
Step 7: Analysis Plan
Before running, define how results will be analyzed:
- Which metrics to compare (primary + secondary)
- Statistical significance test if applicable (paired t-test, bootstrap CI)
- How to handle failed/crashed runs
- Visualization: what plots to generate (comparison tables, bar charts, learning curves)
Verification Checkpoints
Before finalizing the experiment plan:
Output Format
Always produce:
- Experiment matrix table — all runs with their configurations
- Resource estimate — GPU hours, API costs, storage
- Execution script — ready-to-run commands matching project conventions
- Analysis plan — metrics, comparisons, visualizations
1---2name: experiment-design3description: Use when the user wants to design experiments, plan ablation studies, structure baselines, or create incremental evaluation strategies. Triggers on phrases like "design ablation", "plan experiment", "what experiments should I run", "baseline comparison", or "experiment matrix".4---56# Experiment Design Methodology78You are helping a researcher design rigorous experiments. Follow this methodology systematically.910## Step 1: Understand the Research Question1112Before designing any experiment:13- Ask what specific hypothesis or claim the experiment should support14- Identify the dependent variable (metric) and independent variables (factors)15- Clarify the baseline: what is the current best result or default configuration?1617## Step 2: Single-Variable Isolation1819Every ablation study must change exactly ONE variable at a time. For each factor:20211. **Define the factor** — what is being varied (e.g., loss function, learning rate, architecture component)222. **List levels** — all values this factor will take (e.g., CE, focal, VAR)233. **Fix everything else** — document what stays constant (seed, data split, epochs, hardware)244. **Predict outcome** — before running, state what you expect and why2526Template for each ablation row:27```28| Run ID | Factor | Value | Fixed Config | Expected Outcome |29|--------|--------|-------|-------------|-----------------|30```3132## Step 3: Experiment Matrix3334For multi-factor studies, use a structured matrix:35361. **Full factorial** — if factors are few (≤3) and levels are few (≤3 each)372. **Sequential elimination** — if factors are many: run single-factor ablations first, then combine winners383. **Latin square** — if full factorial is too expensive: sample representative combinations3940Always calculate total runs before committing:41```42Total runs = product of all factor levels43GPU hours = total runs × hours_per_run44```4546## Step 4: Resource Estimation4748For each experiment plan, estimate:49- **GPU hours**: runs × time_per_run (check with user's hardware)50- **API costs**: if using external APIs (Gemini, OpenAI), estimate tokens × price51- **Wall clock time**: accounting for sequential dependencies and GPU availability52- **Storage**: checkpoint sizes × number of runs5354Flag if total cost exceeds reasonable bounds and suggest prioritization.5556## Step 5: Config Stub Generation5758Generate configuration stubs that match the user's existing config format. Read existing configs first to match:59- File format (YAML, JSON, TOML)60- Key naming conventions61- Directory structure for outputs62- Logging/tracking integration (wandb, neptune, tensorboard)6364## Step 6: Execution Plan6566Create a concrete execution plan:671. Order runs by dependency (baselines first, then ablations)682. Identify which runs can be parallelized across GPUs693. Create a shell script or batch runner matching the project's existing patterns704. Include checkpointing strategy for long runs7172## Step 7: Analysis Plan7374Before running, define how results will be analyzed:75- Which metrics to compare (primary + secondary)76- Statistical significance test if applicable (paired t-test, bootstrap CI)77- How to handle failed/crashed runs78- Visualization: what plots to generate (comparison tables, bar charts, learning curves)7980## Verification Checkpoints8182Before finalizing the experiment plan:83- [ ] Each ablation changes exactly one variable84- [ ] Baseline is clearly defined and will be run with same setup85- [ ] Resource estimate is within budget86- [ ] Config stubs match existing project format87- [ ] Analysis plan is defined before execution begins88- [ ] Seeds are fixed for reproducibility8990## Output Format9192Always produce:931. **Experiment matrix table** — all runs with their configurations942. **Resource estimate** — GPU hours, API costs, storage953. **Execution script** — ready-to-run commands matching project conventions964. **Analysis plan** — metrics, comparisons, visualizations