Feature importance reflects which features are considered to be significant by the ML algorithm during model training.
Feature importance is a relative metric. It is often expressed on the percentage scale. The main application area is ranking features, and providing guidance for further feature engineering and selection work. For example, the cost and complexity of models can be reduced by gradually eliminating low(est)-importance features from the training dataset.
Feature importance is sometimes confused with feature impact.
Feature impact reflects which features and to which extent contribute towards the prediction when the fitted model is executed.
Feature impact is calculated by substituting feature values into the model equation, and aggregating the partial scores of model terms feature-wise. This calculation is applicable to all data records, irrespective of their origin (ie. training, validation and testing datasets).
Some model types have built-in feature importance estimation capabilities.
For example, decision tree and decision tree ensemble models declare a
feature_importances_ property that yields Gini Impurities upon invocation.
Similarly, it is not formalized as a linear model property, but all seasoned data scientists know that the beta coefficients of a linear model act as surrogate feature importances (assuming standardized data).
Scikit-Learn version 0.24 and newer provide the
sklearn.inspection.permutation_importance utility function for calculating permutation-based importances for all model types.
The estimation is feasible in two locations.
First, estimating the importance of raw features (data before the first data pre-processing step). Indicates which columns of a structured data source such as a CSV document or a relational database are critical for success.
Second, estimating the importance of fully-developed features (data after the last data pre-processing step). Indicates how to improve feature engineering and selection work. For example, optimizing feature encodings, exploring and generating feature interactions, deriving custom features.
The JPMML-SkLearn library can only work with this state of a Python object that is serializable in Pickle data format. A Python property does not have a persistent state. The workaround is to transfer its value into a new regular Python attribute.
By convention, the JPMML-SkLearn library checks if the Python pipeline or model object has a
pmml_feature_importances_ attribute (the
pmml_ prefix prepended to the standard
feature_importances_ attribute name).
If it does, then it is expected to hold a Numpy array of shape
Exposing the built-in feature importances of a decision tree:
In case of ensemble models there are feature importances available at different aggregation levels.
Exposing the built-in feature importances of a decision tree ensemble, first at the root model level, and then at the member model level:
Attaching custom feature importances to a PMML pipeline:
MiningField element specifies an
importance attribute for recording field importance values.
The PMML term "field" is incompatible with the Scikit-Learn term "feature". The former corresponds to raw feature (data before the first pre-processing step), whereas the latter corresponds to fully-developed feature (data after the last pre-processing step). They are functionally equivalent only when the pipeline does not contain any data pre-processing steps.
Thanks to the relative nature of Scikit-Learn feature importances it is possible to reduce them to PMML field importances via simple summation. If a feature is derived from two or more columns, then its importance value is split between them in equal proportions.
The JPMML family of conversion tools and libraries preserves native feature importance information by attaching an
X-FeatureImportances extension element to the
This extension element contains a table of feature names mapped to their importance values.
In the table header, there is a quick summary (the number and the sum of non-zero importance values, extreme non-zero importance values, etc.) to facilitate data parsing and interpreration.
For example, the PMML representation of feature importances for the "DecisionTreeAudit" case is the following:
The quick statistics shows that 13 out of 49 features have zero importance, which means that they are redundant from the current model perspective. Of the remaining 36 features, the most important one is the "Marital=Married" binary indicator feature that alone does over 20% of work. Interestingly enough, all the other "Marital" category levels contribute very little. This suggest that the "Marital" column should be encoded using some binarizing transformer instead ("Marital equals Married" vs. "Marital does not equal Married").
On aggregate, the importance of the "Marital" column is only surpassed by the "Income" column.
Its importance is obtained by summing the "Income" direct feature importance and half of the "Hourly_Income" derived feature importance (
0.14371484745257854 + 1/2 * 0.15704030730211904 = 0.22223500110363806).
The overall ranking of columns is "Income" > "Marital" > "Hours" > "Occupation" > "Age" > "Education" > "Employment" > "Gender". Numeric columns tend to precede string columns. This may be caused by the fact that Scikit-Learn decision tree algorithms do underperform when categorical features have been one-hot-encoded.
PMML documents are text based and very well structured, which allows for efficient information retrieval using command-line tools.
Using the Xidel tool to extract "Occupation" field importances for the "RandomForestAudit" case:
The console print-out shows 32 values.
The first value corresponds to the root model (
/PMML/MiningModel), and the following 31 values to member decision tree models (
All field importance values are roughly of the same magnitude.
grep tool to extract "Occupation" field importances for the "GradientBoostingAudit" case:
The console print-out shows only 24 values this time.
The first value
0.1445742412830531 corresponds to the root model. The following 23 values range from
0.4084976807753639, and correspond to member decision tree models; the "missing" eight field importances should be interpreted as