A factory team reruns a defect model months later and cannot tell which tree depth and learning rate produced the saved scores. Which practice would have closed that gap?
Select an answer to reveal the explanation.
Short Explanation
You can’t reliably rerun a recipe if its key settings are missing. Record the hyperparameters—including tree depth and learning rate—with the run that produced the scores. That way, the next analyst can explain or reproduce them instead of guessing.
Full Explanation
Hyperparameters are part of a run, not an optional note beside it. Recording the tree depth and learning rate with the run that produced the saved scores lets a later analyst reproduce or explain those scores instead of guessing. Keeping only the final accuracy figure shows how well the run did but erases the settings that led there, so the gap remains. Keeping the raw sensor files preserves the inputs, but those files do not reveal which depth and learning rate were chosen when the model was fit. Writing the business goal on a slide captures why the model exists, but leaving the run’s depth and learning rate out of the record still omits the settings needed to understand the scores. Without those settings, analysts can use the same sensor files and still produce different scores, with no record of why. Store the settings alongside the run record so the next review does not depend on memory. Depth and learning rate are the missing settings here; the same practice applies to the other hyperparameters actually used in that run. Exam caveat: a code version helps only if those settings are recorded in it; values entered into a one-off job still need to be stored with the run. Practical check: open the record for the saved scores and confirm that tree depth and learning rate are present before attempting a rerun.