Hi Alfredo,
Thanks for your comments, I really like all your suggestions. Here are my
answers let me know if it makes sense or have comments.
1) The fit API is targeting novice users covering about 80% of the use
cases listed in the document. For advanced users,
and complex models, we (Naveen, Ankit and Lai) felt its best use the
existing mechanisms due to the imperative nature and the more control it
can give, So we did not duplicate the save/load functionality in the Hybrid
block.
We’ll consider and extend the functionality to Estimator.
I have had trouble using pickle package which is commonly used for
serialization and deserialization, if you have any other suggestions from
your experience please let us know.
2) +1, we’ll add this to our backlog and add it in our next iteration.
3) Can you expand a little more on this, how it helps in a production
environment (which this API was not target for) ?.
I’ll check the TF Estimator to understand further.
Thanks, Naveen
On Thu, Feb 7, 2019 at 2:32 PM Alfredo Luque
wrote:
> This is great and something we should all be able to benefit from.
>
> There are just three pieces I’d like to advocate for that I feel are
> shortcomings of some competing APIs on other frameworks (eg; TF Estimators)
> and I would love to see in this proposal:
>
> 1) Make serialization/deserialization of these classifiers/regressors easy
> or at least ensure the internal members of the wrapper are easy to
> save/load. We’ve hacked around this by only allowing hybrid blocks which
> have easy save/load functionality, but having a simple
> “save_model”/“load_model” function as a 1st class citizen of these proposed
> APIs will lead to a vastly improved user experience down the road.
>
> 2) Allowing the fit/predict/predict_proba functions to take in both data
> loaders and simple numpy arrays and pandas dataframes is a simple change
> but a huge usability improvement. Power users and library authors will
> appreciate being able to use custom data loaders but a large portion of end
> users want to just pass an ndarray or data frame and get some results
> quickly.
>
> 3) Allow lazy construction of the model. This is something I feel TF
> Estimators do well: by allowing the user to pass a function that constructs
> the net (i.e a model_fn that returns the net) rather than the net itself it
> allows for more control at runtime and usage of these APIs in a production
> environment.
>
> Would love your thoughts on these three changes/additions.
>
> —Alfredo Luque
> Software Engineer
> Machine Learning Infrastructure
> Airbnb
> San Francisco, CA
>
> On February 7, 2019 at 1:51:17 PM, Ankit Khedia (khedia.an...@gmail.com)
> wrote:
>
> Hello dev@,
>
> Training a model in Gluon requires users to write the training loop, this
> is useful because of its imperative nature, however repeating the same code
> across multiple models can become tedious and repetitive with boilerplate
> code. The training loop can also be overwhelming to some users new to deep
> learning. Users have asked in [1] for a simple Fit API, similar to APIs
> available in SKLearn and Keras as a way to simplify model training and
> reduce boilerplate code and complexity.
>
> So, I along with other contributor Naveen and Lai came up with a fit API
> proposal in [2] that covers 80% of the use-cases for beginners, the fit API
> does not replace the gluon training loops. The API proposal is inspired by
> the Keras fit API. I have discussed and got feedback from a few MXNet
> contributors (Sheng, Mu, Aston, Zhi) close by and I am writing to ask for
> the community’s feedback on the API proposal.
>
>
>
> [1]
> https://discuss.mxnet.io/t/wrapping-gluon-into-scikit-learn-like-api/2112
> [2]
>
> https://cwiki.apache.org/confluence/display/MXNET/Gluon+Fit+API+-+Tech+Design
>
>
> Thanks,
> Ankit
>
>
> —
> Alfredo Luque
> Software Engineer
> Machine Learning Infrastructure
> Airbnb
> San Francisco, CA
>
