Replies: 2 comments
-
I’ve wondered about adding the estimation logic to the settings object before and I think it’s a good idea in principle To explain why it's not there already, it's because are a few challenges, some of which could probably be overcome, but make things tricky. Overall it's because model training is to some extent imperative rather than declarative
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Converting to a discussion because still unsure whether this is desirable |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Is your proposal related to a problem?
Currently the settings object does not make a model fully reproducible (i.e. re-trainable). The settings json can save out the blocking rules, comparisons, m/u values etc that make up a model, but not the model training steps that have made them.
Describe the solution you'd like
Add sections to the settings object to define lambda, m and u training rules (similar to blocking rules). These can be specified (and run) at the instantiation step, or if the user iteratively runs model training - these should be added to the settings object under the hood.
Describe alternatives you've considered
Additional context
Beta Was this translation helpful? Give feedback.
All reactions