This repository has been archived by the owner on Jul 17, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
API update #69
Labels
Comments
geomodular
added a commit
that referenced
this issue
Jul 9, 2021
geomodular
added a commit
that referenced
this issue
Jul 12, 2021
geomodular
added a commit
that referenced
this issue
Jul 14, 2021
geomodular
added a commit
that referenced
this issue
Jul 15, 2021
geomodular
added a commit
that referenced
this issue
Jul 15, 2021
I have a working concept on a branch: What's added:
from h2o_wave_ml import H2O3Model
m = H2O3Model()
m.build()
m = DAIModel()
client = m.get_dai_client()
client.datasets.create() # Do whatever. m = DAIModel()
m.build()
m.save_autodoc() I hesitate to merge this, for now, as I'm not convinced this is the step in the right direction. |
I played a bit with this. I think its great! I also like this because its very to pick up already existing codes (say that use a sklearn model) and just replace the model instantiation line with a Wave Model. It's also as easy and seamless to use across environments (cloud vs local) as before, so I see no issues for enabling this. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This issue reviews the current Wave ML API and proposes the next direction.
Motivation
ML libraries/APIs tends to have a different approach of creating and working with objects comparing to Wave ML. Take
H2O-3
for example (to be clear it's not related just toH2O-3
):It instantiates an Estimator directly, i.e., it's not using a factory function. The idea is to follow a similar pattern so ML folks can stand on common ground.
Current status
A direct model instantiation is not available in Wave ML. To get a model,
build_model()
function needs to be called, which returns a commonModel
:This function is great for several reasons:
However, from the way
build_model()
is actual used, users tend to specifyDAI
/H2O-3
inbuild_model()
anyway throughmodel_type
argument. This leaves the function rather baseless.Also, the function might not be easy to pick up anymore due to a large amount of arguments (we have the code examples to mitigate this).
The last thing, IMO, It packs too many operations behind the scenes. It might be better to split it up.
Solution
We can keep the
build_model()
function and refactor code to support direct instantiation of models as well:This would also give us room to incorporate feature such as direct client access (in the roadmap):
Or to actually split training process and support a prediction on standalone DAI:
This way, we might be able to integrate
h2o_wave_ml.utils
into API more fluently. Since we are not working with a commonModel
anymore, we can pick and enable features for a particular model:Notes
Thanks @vopani for the early discussion.
Comments are welcomed.
cc @lo5 @mmalohlava @mtanco @tkmaker @AakashKumarNain
The text was updated successfully, but these errors were encountered: