Open CESARDELATORRE opened 5 years ago
This.
The gains you'd get here aren't as big as you first think. If you have any "transforms" in your pipeline, you still need to run them at "scoring" time. And also, the output objects of the "training" code (basically the ModelParameter classes plus the transforms) are also needed at "scoring" time.
In all actuality, the only code you could eliminate at scoring time is the few classes that do the actual training - which wouldn't be a lot of code.
Looking at the above issues, they would all still remain even if we split the "trainer" code into separate assemblies. Reflection.Emit is used by "scoring". MEF is used by the custom transforms. etc.
/cc @TomFinley
Segregate "scoring" ML.NET components/NuGet packages so the scoring components evolve autonomously from the rest of ML.NET.
This will be a breaking change, although easy to fix in the apps when having the breaking changes.
If we segregate the scoring area of ML,NET, that would help when providing support to:
So initially, only the "scoring" area of ML.NET could be supported in those environments. It would be less expensive than providing support to UWP, Unity and ARM to the whole ML.NET. And in most scenarios, for those environments, the customer just want to score a model, not to train a model in an UWP app, Unity app or ARM app (Xamarin mobile app or IoT).
Related issues: https://github.com/dotnet/machinelearning/issues/1886 https://github.com/dotnet/machinelearning/issues/1736 https://github.com/dotnet/machinelearning/issues/22 https://github.com/dotnet/machinelearning/issues/2252 https://xamlbrewer.wordpress.com/2019/01/25/machine-learning-with-ml-net-in-uwp-clustering/