| name | vibe-research-optimize |
| description | Large-scale parameter optimization for research projects using Bayesian (optuna TPE ask-tell) or evolutionary methods, with safeguards against metric gaming. Use when running hyperparameter search, tuning parameters at scale, setting up multi-round optimization experiments, or whenever the user mentions parameter sweeps, Bayesian optimization, or finding the best settings. |
Vibe Optimize
The workflow for large-scale parameter search. This is the most delegated scenario in the whole framework, and the one most prone to gaming the metric at the expense of the goal, so the rules here are the most detailed.
Step 0: understand the goal
Understand what this optimization serves at the level of the paper, not just the metric. The metric is only a proxy for the real goal: pushing the metric up is not the same as making the research better. If some trick raises the metric while betraying the research purpose, report it; do not use it.
Expect this tension to recur rather than be settled once: any fixed metric can be exploited, and new loopholes surface as the search gets smarter. Finding one is itself a useful result — report it as a weakness of the metric and propose a fix, instead of quietly using it or quietly working around it.
Bayesian method (optuna TPE, ask-tell)
A. Agree with the user on: the parameters to optimize, the search space, and the experiment budget.
B. Multi-round loop:
- Draw a parameter set (nearly random at first), run the experiment, record parameters, results, and figures.
- Scoring: numeric metrics may be scored automatically; figures, visualizations, and paper-level quality must be scored by the user. Handing that kind of holistic judgment to an automatic scorer is an open invitation to gaming. Scores are material for the user's judgment, never a verdict that replaces it.
- Tell the score back to the model and update it.
- Repeat until the budget is used up.
C. When reporting the best result, explain why it is good: show the mechanism with figures, not just the score. A good-looking result whose mechanism cannot be explained should be flagged as suspicious.
D. Subtract before reporting. A winner found by search tends to carry every trick and component added along the way, while usually only one of them carries the effect. Test which additions actually matter and drop the rest, as much as will go. Then weigh what remains against its complexity — added complexity is itself a heavy cost, and a small metric gain often does not pay for it. Report the stripped-down version, with the performance–complexity trade-off stated.
E. If no setting in the space works well, say exactly that. "The search found nothing good" is a legitimate outcome of a search; dressing up the least-bad setting is not.
Isolation: keep the search fully separate from formal experiments
- Do not add sweep-only switches to core classes or formal code. Keep search code in its own place, and keep it git-tracked too (this rule exists because code was lost once).
- A "winner" found by the search must not be silently promoted to the formal default. Report it to the user and get confirmation first.
- Keep output directories separate from formal results. Figures produced by the search never go into the paper directly; formal figures must be regenerated by formal experiment code.
- Clean up the search's temporary outputs before merging back to the main branch.
Evolutionary method
(To be added.)
