Public Constructors for ModelParameters

[najeeb-kazmi]

During the course of fixing #1698 and deriving work items (e.g. #1699, #1701, #1702), we created public constructors for the various ModelParameter objects (formerly Predictor objects).

@sfilipi raised the question whether these should be public or be made internal as the only thing that can create ModelParameters (Predictors) is training a model. What use case are we supporting with this? When might a user want to create say a LinearRegressionModelParameters object with bias and weights instead of training a linear regression model?

[Ivanidzo4ka]

I think it make sense to some degree for me.
We have Feature contribution functionality which accept IPredictor and let you give feature importance. And without public constructors only way to create IPredictor is via training.
I personally would like ability to create IPredictor by hands which would give me ability to tweak it.

[sfilipi]

Curious, how would you create an IPredictor by hand? Where would you get the values for the model parameters?

[Ivanidzo4ka]

With @najeeb-kazmi changes, like this:
new LinearModelParameters(env, "some_name_have_no_idea_why", in my_beatuiful_weights, yes_im_biased);

[Ivanidzo4ka]

I can always explore predictor from training, and decide to manually boost certain weight or bias.

[Ivanidzo4ka]

I believe in general this positive changes.
One thing I think we can improve is that name parameter we ask from user.
It's confusing and doesn't make any sense from user perspective.
We still can provide it, we just need to create separate internal constructor and pass nameof(class) in it (or whatever we pass right now).

[rogancarr]

I think it would be super useful to be able to create some predictors by hand. I do this quite a bit to compare models across implementations and languages. This would make it way easier. This would be a more advanced usage, though.

An interesting use-case that I could see becoming popular would be to create importers of non-ML.NET models for ML.NET predictor classes. For example, if you had an in-house tree learner, you could write custom code to import your models as a TreeEnsembleModelParameters class for deployment. Similarly, we could allow NimbusML to pass compatible sklearn predictors to ML.NET for use with tools like Feature Contribution Calculator and Permutation Feature Importance.

[Zruty0]

I can always explore predictor from training, and decide to manually boost certain weight or bias.

What @Ivanidzo4ka says is the primary reason I like public constructors. Being able to tweak the model and then plug it back into the system is a useful functionality.

[Zruty0]

I suppose we can close it now

[abgoswam]

re-opening this discussion.

• if we do want to keep it public we should have some unit tests for it (currently there are no unit tests)

@TomFinley @glebuk @eerhardt

[rogancarr]

Some scenarios where it's important to have public constructors:

Adjusting model parameters: Often there are situations where you may want to modify some parameters based on prior knowledge, as @Ivanidzo4ka and @Zruty0 mention above.

Importing models: Many people need to train models in custom systems, but need to deploy them in .NET. Imagine if you train a large-scale model in Spark or Hive and need to deploy it in .NET. Or your data scientists are using Python or R. You could hand-code some model, or you could simply plug in your linear model parameters, gradient-boosted-trees, or k-means parameters, etc. into ML.NET and use our framework for scoring.