ELI5: Per-Model Explanation Adapters for scikit-learn, XGBoost, LightGBM and Keras
A library for debugging/inspecting machine learning classifiers and explaining their predictions
At a glance
- What is it?
- ELI5 is an MIT-licensed Python package that explains classifier predictions across several frameworks and implements LIME and permutation importance for black-box models. Its value is breadth of adapters; its cost is that each adapter has its own level of completeness, and the README does not tell you which.
- Who is it for?
- Adopt ELI5 if you already run scikit-learn, XGBoost, LightGBM or Keras models and want one explanation API instead of writing a per-framework renderer. Do not adopt it expecting uniform coverage: the README promises weights and predictions for scikit-learn and lightning, but only feature importances for CatBoost, and only Grad-CAM visualizations for Keras image classifiers.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 160 days ago.
- What is it written in?
- Mainly Jupyter Notebook, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap ELI5 fills: one explanation API over many estimator libraries
A team that trains a linear model in scikit-learn, a gradient-boosted model in XGBoost and an image classifier in Keras ends up with three unrelated ways to ask why a prediction came out the way it did. Each library exposes its own coefficient arrays, its own feature importance attributes, its own plotting helpers. Writing a consistent explanation layer on top of that is unglamorous work that gets redone in every project. ELI5 is an attempt to standardize that layer. The README describes it as a Python package that helps debug machine learning classifiers and explain their predictions, and the supported list spans scikit-learn, Keras, xgboost, LightGBM, CatBoost, lightning and sklearn-crfsuite. The intended user is an engineer or data scientist who already has a trained estimator and wants to inspect it, not someone building a model from scratch. That framing matters: ELI5 does not train anything, and it does not evaluate model quality. It reads a fitted estimator and produces an explanation.
Explanation and formatting are separate layers, which is the design decision that matters
The README states that explanation and formatting are separated. In practice this means the same explanation can be emitted as console text, as HTML embeddable in an IPython notebook or a web dashboard, as a pandas.DataFrame for further processing, or as JSON for a client to render itself. For anyone wiring explanations into an existing UI, the JSON and DataFrame paths are the interesting ones, because they let the rendering decision live outside the library. The mechanism differs by model family. For scikit-learn linear classifiers and regressors, ELI5 explains weights and predictions directly, which is the cheap case: the model already stores coefficients, so the explanation is arithmetic over them. For decision trees and tree-based ensembles it prints trees as text or SVG and shows feature importances. For xgboost, LightGBM and CatBoost it reports feature importances and, for the first two, predictions. For Keras it produces Grad-CAM visualizations, which are image-space heatmaps rather than per-feature weights. These are genuinely different mechanisms wearing one interface, and the interface is what you are buying.
Where the adapters are not equivalent
Read the supported list as a table of capability, not as a list of equals. scikit-learn gets the broadest treatment: weights, predictions, decision tree printing, feature importances, and text highlighting that understands scikit-learn text processing utilities. Pipeline and FeatureUnion are supported, and the README notes ELI5 can debug pipelines containing HashingVectorizer by undoing hashing, which is a specific and non-obvious feature: hashing destroys the mapping from feature index back to token, and reversing it is what makes a hashed text pipeline explainable at all. xgboost and LightGBM get feature importances plus prediction explanations. CatBoost gets feature importances only. lightning gets weights and predictions. sklearn-crfsuite gets weight inspection for CRF models. Keras gets Grad-CAM for image classifiers. If your model is a CatBoost regressor and you need per-prediction explanations rather than global importances, the README does not offer that, and you should plan around it rather than assume parity.
Black-box paths: TextExplainer, LIME and permutation importance
Beyond per-framework adapters, ELI5 implements algorithms for inspecting models it has no native support for. TextExplainer explains predictions of any text classifier using the LIME algorithm, attributed in the README to Ribeiro et al., 2016. Permutation importance computes feature importances for black-box estimators. Both are model-agnostic, which means they work by perturbing inputs and observing output changes rather than by reading model internals. That has a direct consequence: they are approximations, they cost repeated predictions per explanation, and their stability depends on the sampling. The README is explicit that utilities for using LIME with non-text data and arbitrary black-box classifiers exist but are currently experimental. Take that word seriously. The text path is presented as the mature one; the general black-box path is flagged as not settled.
Getting it running
Installation is a standard PyPI install: pip install eli5. The package is MIT licensed and the README points to http://eli5.readthedocs.io for documentation. Framework-specific extras are not described in the README text supplied here, so check the docs for the install variant that matches your stack before assuming a single install covers Keras or CatBoost. The calling surface follows one naming pattern: explain_prediction for per-prediction explanations and show_weights for model weights. The README's own image captions reference explain_prediction for text data and for image data, which confirms the same entry point name is used across text and image cases. Output format is selected at call time, since the README lists text, HTML, pandas.DataFrame and JSON as the available renderings of the same explanation. For a scikit-learn pipeline that includes a HashingVectorizer, the hashing-undo path is what makes the highlighted tokens meaningful rather than opaque feature indices.
The wrong tool for stable, auditable, per-decision documentation
ELI5 produces explanations, not guarantees. The black-box paths are sampling-based, so two runs on the same input need not produce identical output, and nothing in the README claims determinism. If you need a frozen, reproducible artifact attached to each decision, for example a document that a reviewer can re-read a year later and get the same numbers, LIME-based text explanations are a poor fit for that requirement. The same applies to permutation importance: it is a global summary computed by shuffling, and it says nothing about an individual prediction. A second limitation is scope. There is no support listed for PyTorch, TensorFlow beyond the Keras interface, or general NLP transformer pipelines. If your model is a fine-tuned transformer, neither the adapter list nor the black-box section in this README addresses it directly. And the non-text LIME utilities are marked experimental, so building a product feature on them means building on a surface the maintainers have not declared stable.
Alternatives and the actual difference in approach
SHAP is the obvious comparison, and the difference is architectural rather than cosmetic. SHAP computes Shapley-value-based attributions from cooperative game theory, giving a single additive attribution per feature with consistency properties. ELI5's per-framework adapters mostly read what the model already stores (coefficients, tree structure, importance attributes), which is fast and exact for those model types but only available where the library exposes it. For black-box cases ELI5 uses LIME, which fits a local surrogate around one prediction; SHAP's model-agnostic estimators sample too, but the underlying attribution definition is different and the output is designed to be additive across features. A second alternative is the built-in tooling of each library: XGBoost's own plot_importance, scikit-learn's tree export functions. Those avoid a dependency but reintroduce the problem ELI5 exists to solve, namely one rendering per framework. If your stack is a single framework and you only need that framework's native plot, the dependency is not earning its place.
Maintenance cost and the MIT licence
The licence is MIT, which is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the whole of what the README states, and it is not legal advice; if you are bundling ELI5 into a distributed product, confirm notice-retention obligations with your own counsel. Maintenance cost is harder to pin down from the material available. The repository is not archived and the last push is dated 2026-04-08, so the project is active, but no releases were retrieved for this review, which means version cadence could not be assessed. The practical upgrade risk sits in the per-framework adapters: each one tracks a third-party library, so an XGBoost or Keras API change can break explanation output without any change in ELI5 itself. Pin your framework versions alongside ELI5 and re-run your explanation path when you bump either one. The core scikit-learn path, which reads coefficients and tree structures, is the least exposed to that churn.
Editorial conclusion
Adopt ELI5 if you already run scikit-learn, XGBoost, LightGBM or Keras models and want one explanation API instead of writing a per-framework renderer. Do not adopt it expecting uniform coverage: the README promises weights and predictions for scikit-learn and lightning, but only feature importances for CatBoost, and only Grad-CAM visualizations for Keras image classifiers. Before committing, verify two things on your own model: that your estimator class appears in the supported list above, and that the output format you need (text, HTML, pandas.DataFrame or JSON) is produced by the specific adapter you are calling. The README calls the non-text LIME utilities experimental, so treat those as a separate decision from the text path.
Community notes