[Feature request] Official feature-attribution support for KumoTabular, inspired by TabICL's interpretability API

オープン
  • 何か問題がありますか？
#1,276 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
30/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python
領域
machine-learning

調査の方向性

Start by reading the existing sdm.explain GradientExplainer API and its documentation to understand the current outputs and limitations. Then compare its behavior with the linked TabICL SHAP implementation and the exploratory setups described here. Done would mean maintainers identify a recommended attribution workflow or define a supported API and document its baseline, masking, ensemble, and reconstruction semantics.

索引モデルが issue の本文から書いたものです。

説明

Motivation

Thank you for releasing KumoTabular!

I am evaluating it against CatBoost and TabICL on a binary classification
task. Beyond predictive performance, I would like to understand individual
predictions: which features increase or decrease the predicted probability
for a selected class?

An officially supported and documented feature-attribution workflow would
help users evaluate and adopt the model.

Reference: TabICL's interpretability tools

The standalone TabICL package provides helpers such as
tabicl.shap.get_shap_values and get_shap_explainer, returning standard
SHAP explanations that can be used for local and aggregate visualizations.

Its current implementation uses an all-NaN background as a missing-value
reference, handled through the model's preprocessing:

https://github.com/soda-inria/tabicl/blob/main/src/tabicl/shap/_shap.py

A similarly accessible workflow for KumoTabular would be very useful,
without necessarily using the same attribution method or masking strategy.

Existing functionality and questions

I noticed that sdm.explain already exposes GradientExplainer.
Could you clarify whether it is the recommended explanation method for
KumoTabular, what its outputs represent, and its limitations?

For additive feature attributions, would you recommend:

  • SHAP with representative background rows;
  • SHAP with an all-missing reference;
  • or another model-specific approach?

I understand that Kumo encodes missingness explicitly, so masking with NaN
should not be assumed equivalent to removing a feature.

I experimented locally with permutation SHAP using both real background
rows and an all-missing reference, while keeping the fitted context and
ensemble fixed. These experiments are exploratory; I would prefer guidance
and validation from the model authors.

Requested functionality

Ideally, an official API or example would provide:

  • Local contributions for a selected class probability.
  • Explicit baseline and masking semantics.
  • Support for numerical/categorical features and missing values.
  • Contributions mapped back to the original input features.
  • Compatibility with fitted/cached contexts and clear ensemble semantics.
  • Configurable computational budgets and reproducibility.
  • Standard outputs usable with SHAP plots or Shapash local plots.

For additive methods, an example checking that baseline plus contributions
reconstructs the explained output would also be helpful.

An initial tutorial documenting the recommended approach and its
limitations would already be valuable.

Is this on the roadmap, or is there an existing workflow I have missed?

主要言語
Python
スター
429
フォーク
46
平均マージ
1日 3時間
マージ済み PR（30日）
231

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA/structured-data-models のほかの issue

NVIDIA/structured-data-models の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。