协作头脑风暴
brainstorming
在实现前澄清需求、探索设计选择,并形成清晰的开发方向。
select-and-verify-best-checkpoint【开发与工程】Proves that evaluation ran at the intended cadence, the tracked metric selected the true best checkpoint, and held-out inference loaded that checkpoint. Use with Hugging Face Trainer or compatible training-state artifacts before trusting test metrics.
独立 GitHub 快照 · 自动分类 · 以原作者文档为准
Treat checkpoint identity as an evidence requirement, not a configuration assumption.
Set evaluation and saving to compatible cadences. Specify the metric, whether greater is better, and best-model loading. Ensure the configured metric name matches the emitted evaluation key; account for frameworks that add an eval_ prefix.
After training, run:
python scripts/verify_checkpoint.py output/trainer_state.json \
--metric eval_loss \
--expected-eval-steps 50,100,150 \
--evaluation-manifest held-out-run.json \
--loaded-checkpoint-field loadedCheckpoint \
--output checkpoint-proof.json
The script fails unless:
best_metric and best_model_checkpoint are non-null;Use --greater-is-better for maximized metrics and repeat --required-file to require adapter or model files inside the best checkpoint.
Record the trainer state hash, checkpoint path and hash inventory, best metric and step, evaluation manifest, and evaluation command. If ties exist, report the framework's selected tied checkpoint rather than pretending the optimum is unique. Never claim held-out results came from the best checkpoint without an explicit load identity.