Summary
treelite.sklearn.export_model should export scikit-learn-compatible classifier metadata for child estimators in exported random forest classifiers.
Today, cuML needs a local workaround when converting a RandomForestClassifier to scikit-learn: after calling the CPU export path, it manually patches each exported child estimator so that:
- the forest-level
classes_ retains the original class labels
- each child estimator's
classes_ uses sklearn-style encoded class indices ([0, 1, ..., n_classes - 1])
- each child estimator's
n_classes_ matches the parent classifier
This behavior is currently implemented downstream in RAPIDS cuML, but it appears to be a responsibility that belongs in Treelite's sklearn export layer.
Rationale
scikit-learn stores classifier metadata differently at the forest level vs. the individual child trees. If treelite.sklearn.export_model exports the same classes_ metadata everywhere, downstream projects need ad hoc fixups to restore sklearn-compatible child estimator state.
Moving this logic upstream would:
- keep sklearn-export behavior consistent at the source
- remove downstream patching/hacks in RAPIDS cuML
- improve compatibility for any Treelite consumer exporting sklearn random forest classifiers
Affected area
treelite.sklearn.export_model
- sklearn random forest classifier export path
- exported child estimator metadata (
classes_, n_classes_)
Observed downstream workaround
RAPIDS cuML PR #8291 adds a post-processing step in python/cuml/cuml/ensemble/randomforestclassifier.py to patch exported child estimators after CPU export.
PR: NVIDIA/cuml#8291
Review comment: NVIDIA/cuml#8291 (comment)
Requested by: @csadorf
Expected behavior / acceptance criteria
- Exported sklearn random forest classifiers preserve the original labels at the forest level (
forest.classes_)
- Exported child estimators use sklearn-compatible encoded labels for
estimator.classes_
- Exported child estimators expose the correct
estimator.n_classes_
- Behavior matches a natively fitted scikit-learn
RandomForestClassifier, including cases with non-contiguous class labels
- Downstream projects such as cuML can remove local metadata patching once they adopt the updated Treelite behavior
Summary
treelite.sklearn.export_modelshould export scikit-learn-compatible classifier metadata for child estimators in exported random forest classifiers.Today, cuML needs a local workaround when converting a
RandomForestClassifierto scikit-learn: after calling the CPU export path, it manually patches each exported child estimator so that:classes_retains the original class labelsclasses_uses sklearn-style encoded class indices ([0, 1, ..., n_classes - 1])n_classes_matches the parent classifierThis behavior is currently implemented downstream in RAPIDS cuML, but it appears to be a responsibility that belongs in Treelite's sklearn export layer.
Rationale
scikit-learn stores classifier metadata differently at the forest level vs. the individual child trees. If
treelite.sklearn.export_modelexports the sameclasses_metadata everywhere, downstream projects need ad hoc fixups to restore sklearn-compatible child estimator state.Moving this logic upstream would:
Affected area
treelite.sklearn.export_modelclasses_,n_classes_)Observed downstream workaround
RAPIDS cuML PR #8291 adds a post-processing step in
python/cuml/cuml/ensemble/randomforestclassifier.pyto patch exported child estimators after CPU export.PR: NVIDIA/cuml#8291
Review comment: NVIDIA/cuml#8291 (comment)
Requested by: @csadorf
Expected behavior / acceptance criteria
forest.classes_)estimator.classes_estimator.n_classes_RandomForestClassifier, including cases with non-contiguous class labels