Hi everybody, I'm trying to figure out what is th...
# hamilton-help
m
Hi everybody, I'm trying to figure out what is the best Hamilton pattern for evaluating multiple different models, such as model_A and model_B, using the same shared evaluate function. Is it better to run the pipeline multiple times with different configurations for each model, or to define one large pipeline that computes all model evaluations in parallel? For example:
Copy code
# We have two different model functions:
def model_A() -> TrainedModelA: ...
def model_B() -> TrainedModelB: ...

# We have ONE shared evaluation function:
def evaluate(model: AnyTrainedModel) -> float: ...

# How do we use Hamilton to get the results of `evaluate(model_A)` and `evaluate(model_B)`?
When talking about configuration, I mean
config.when
and then providing the values in for loop to
Builder
. For the second cast, to avoid code duplication, using something like
@parametrize
. I've found model training docs but unfortunately neither of them is describing the pattern I have in mind. Just to be clear, the goal is to: a) train multiple models "at once" b) find out the best of them - usually by looking and comparing the evaluation results in something like MLFlow Thanks!
s
yeah, no one best way.
from a modular perspective this might help if you haven't seen it. Also you can run Hamilton within Hamilton, in case that's helpful to more easily wrap certain bits of logic. i.e. you use @parameterize to come up with the parameterizations, and then feed that as input into a function that wraps a hamilton driver creation and execution... Option 1: parallelize a for loop over hamilton drivers -- one for each model. Option 2: use the parallel & collect approach to parallelize over things. They both have their caveats. I would also consider whether you need to join everything back to compare holistically? or? Some resources: • notebook on reuse &

video walkthrough of itā–¾

šŸ™Œ 1
m
Wow, thanks for prompt answer! Haven't noticed
subdag
abstraction / the whole modular perspective looks very insightful! That looks like a nice building blocks as the size/complexity of the project rises. For the record, I've settled for
@config.when
with manual gluing of drivers for now as the setup is fairly simple but
subdag
looks like a way to go in the future. Thanks a lot 😊
Lastly, the reason I decided on
@config.when
>
@parametrize
is that with the later, I would need to annotate also downstream definition which seemed clunky. I like the fact that with
@config.when
+ gluing of driver, the pipeline definition (code) stays the same and what varies is just runtime configuration (variation of "Build Once, Deploy Anywhere" principle)
šŸ™Œ 2