[AHMETHAKANBEZIR1]

Summary

Address the lazy-construction part of #3293. ShapExplainer currently builds every sklearn per-output SHAP explainer at initialization, even when only one horizon and quantile will be requested. A three-horizon, three-quantile LightGBM example constructs nine trees upfront.

Store deferred constructors for separate estimators and replace each one with its cached SHAP explainer on the first request. Explaining only one horizon/quantile constructs one tree; repeated calls reuse it, and explaining all outputs eventually constructs all nine. Native multi-output models still construct one explainer eagerly. Estimator selection, explanation values, naming and component-selection defaults are unchanged. The issue's separate median-selection API request is not implemented here. A runnable univariate example shows how to select the existing median likelihood component without manually formatting its name.

SHAP constructor options/background are forwarded unchanged. Output-specific initialization errors now occur on the first request, as documented. The existing tree-type assertion is retained and runs after first use for separate estimators.

Validation

Windows CPU, Python3.12/core+development dependencies, SHAP, LightGBM4.7.0, XGBoost3.4.1 and CatBoost1.2.10:

• Final new tests on unchanged master: 6 failed, 2 passed. With this change: 8 passed. Tests use real fitted tree models, count actual SHAP construction and compare SHAP sums plus base values with the selected estimator's predictions.
• Whole darts/tests/explainability: 60 passed, 2 skipped (594 warnings). The remaining Torch cases require unavailable optional dependencies; no assertions or gates were disabled. Tests cover multivariate quantile mapping, deterministic wrapped estimators, native multi-output behavior, cross-API caching and interventional constructor options.
• All eight changed executable lines in the two adapters are covered.
• Configured pre-commit hooks, diff checks and a focused strict Sphinx API build pass. The exact new median-selection example also ran successfully offline. The full Darts suite/site and optional Torch backend were not run locally.

Related #3284 addresses a different issue (multi_models=False). In a private local integration with its head a354658, two import/return-annotation contexts needed resolution; both imports, the new return type and that PR's initialization guard were retained unchanged. No algorithm merge edits were needed. The combined explainability suite passed 78 tests, 2 skipped with all three GBM backends (591 warnings). This private integration was not pushed or included in this PR, which is based directly on master.

Local timing probe (Windows CPU, one thread, 6 horizons × 7 quantiles, 20 trees per estimator, 256 training observations and 32 foreground observations; training excluded): after two warmups, seven runs gave the following medians. Baseline and branch ran sequentially in the same environment. These are a small reproducible workload, not a general performance guarantee.

Constructor plus requested work	Master	Branch
Construction only	118.94 ms	0.45 ms
One horizon / median quantile	115.38 ms	4.35 ms
All outputs	141.34 ms	143.95 ms

The benefit is selective explanation; requesting everything did not improve in this measurement. Selected SHAP value and base-value arrays were exactly equal to master in both explanation scenarios. No timing thresholds were added to tests.

Other Information

Prepared, tested, committed and submitted autonomously by OpenAI Codex, without independent human review. #3293 is an existing user report; I am not claiming the account holder personally experienced it in production. Installation retained the repository's seven-day dependency cooldown and binary-wheel setting.

• Mentioned the issue addressed
• Summarized the behavior and limitations
• Added an Unreleased changelog entry