Feature Contribution Calculation should become Transformer

[artidoro]

We should make the FeatureContributionCalculationTransform a transfomrer, and add a related estimator that produces it so that it can become part of a pipeline. Below I show how it could look like with the new API:

// Define a pipeline for feature extraction with a trainer at the end
var pipeline_1 = mlContext.BinaryClassification.Trainers.trainerEstimator(arguments);
// Train model and cast it to IPredictor
var predictor = pipeline.Fit(data).Model;

Two ways of applying FeatureContributionCalculation:

// 1 First Way: Define another pipeline with FeatureContributionCalculation and possibly more 
// estimators appended to it
var pipeline_2 = mlContext.Model.Explainability.FeatureContributionCalculatingEstimator(arguments, predictor);
var outputData = pipeline_2.Fit(data).Transform(data);

// 2 Second Way: Use the transformer directly, as it is not a trainable transformer
var transformer = new FeatureContributionCalculatingTransformer(mlContext, arguments, predictor);
var outputData = transformer.Transform(data);

In either cases the output data will contain a score column along with a FeatureContribution column.

cc: @rogancarr, @TomFinley, @Zruty0, @Ivanidzo4ka

[TomFinley]

Thanks @artidoro !! This seems good, and I think we need at least this model parameter based constructor to start with, but I had a few off-the-cuff reaction I wonder if we can perhaps do something else as well to potentially form a contiguous pipeline.

Just a note, what you call mlContext.Model.Explainability.FeatureContributionCalculatingEstimator, I will just have as shorthand be mctx.M.E.FCCE. So you have one signature that's more or less mctx.M.E.FCCE(Arguments, IPredictor). I wonder if we could have another overload like this as well (not insisting on this exact signature, except of course for the type):

mctx.M.E.FCCE<TModel, TScorer>(IEstimator<PredictionTransformerBase<TModel, TScorer>> estimator, Arguments estimator = null)

Then we could do something like mctx.M.E.FCCC(mctx.BC.Trainer.CreateFastTree(...), ...), which does more or less what you've accomplished in your training and first way, except in one statement instead of several.

Not suggesting it as a replacement, since I think we definitely need what you've already devised for separate reasons, but in this second way we could just have one straight continuous pipeline instead of having to break it up, train, store the model somewhere else, create a new pipeline, etc.

Also, just a naming note, we have tended to not put "estimator" in the names of things on the ML context or its subobjects, as far as I see. Perhaps a more idiomatic name (to the extent that we've converged on idioms) might be something like:

mlContext.Model.Explainability.CalculateFeatureContributions

Also a more minor note, I kind of feel like the parameters should be re-ordered, since I'd hope (not sure if this is reasonable) that someone having to specify advanced arguments would be somewhat rare.

[artidoro]

Thank you @TomFinley, I like your suggestions!
I think it should be relatively easy to add once the rest is complete. And I agree with reordering the arguments.