LightAutoML: a preset-first AutoML framework with a customization escape hatch
Fast and customizable framework for automatic ML model creation (AutoML)
At a glance
- What is it?
- LightAutoML (LAMA) from sb-ai-lab ships a two-line TabularAutoML preset and a block-level framework underneath it. The preset is the easy part; the framework is what determines whether it fits your pipeline.
- Who is it for?
- Adopt LightAutoML if you have a tabular, time series or text dataset and want a working baseline from the TabularAutoML preset before you invest in feature engineering, or if you specifically need an interpretable model via the WhiteBox and AutoWoE presets. Do not adopt it if you need a managed service with a scheduler, a UI or drift monitoring; LAMA is a Python library and the README offers nothing in that direction.
- Can I use it commercially?
- Yes. Apache-2.0 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 1 day ago.
- What is it written in?
- Mainly Python, 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 problem LightAutoML solves, and the two audiences it splits into
Most teams that reach for an AutoML library are not trying to win a competition. They want a defensible baseline on a tabular dataset, produced in an afternoon, so that a later model has something to beat. LightAutoML's README addresses that case directly with a preset that takes a task name, a metric and a dataframe. The quick tour shows a binary classification setup with metric 'auc', a roles dictionary naming the target column and a drop list, and a single fit_predict call that returns out-of-fold predictions. Two objects come back: an OOF result on the training data and a separate predict call for the test set. That is the whole entry point.
The second audience is the reason the repository is larger than the preset suggests. The README describes LightAutoML as a framework with 'a lot of ready-to-use parts and extensive customization options', and points to a tutorial on building a pipeline from specified blocks: feature generation, feature selection, ML algorithms, hyperparameter optimization. These are two different products sharing one package. The preset is for people who want a number today. The block layer is for people who have opinions about how features should be generated and want to keep the orchestration that LAMA provides.
The supported data types are broader than tabular: the README states support for tabular, time series, image and text data. The tutorial list backs that up with notebooks for NLP interpretation, time series, relational data in a star scheme, uplift modeling, and neural networks on tabular data.
How the preset and the block layer relate
The mechanism visible in the README is composition. TabularAutoML is a preset, meaning a pre-assembled pipeline that you configure rather than build. The Task object carries the problem definition: a name such as 'binary' and a metric such as 'auc'. The roles dictionary tells the pipeline which column is the target and which columns to exclude. Everything else, feature processing, model selection, validation, is decided inside the preset.
The framework path inverts that. Tutorial 6 is described as showing how to create your own pipeline from specified blocks, and the blocks named are feature generation, feature selection, ML algorithms and hyperparameter optimization. So the same components the preset wires together are individually addressable. That is the real architectural claim: the preset is not a separate code path, it is a configuration of the block layer. Whether that holds exactly in the source is not something the README proves, but the tutorial naming suggests the blocks are exposed rather than hidden.
Two presets appear in the material beyond the default. TabularCVAutoML is shown in Tutorial 8 for a CV multi-class classification task, which implies a cross-validation variant rather than a single holdout. TabularNLPAutoML appears in Tutorial 4 alongside LimeTextExplainer, which suggests text columns are handled as a distinct feature type with its own interpretation tooling. A WhiteBox preset and an AutoWoE preset appear in Tutorial 2 and in a linked Kaggle kernel, aimed at interpretable models. The README does not describe the internals of any of these presets, so treat the naming as the extent of what is confirmed.
Installation and the config surface you actually touch
The README's installation section is referenced by anchor but its contents are not in the supplied material, so the exact pip invocation is not something I can quote. What is confirmed is the PyPI package name, lightautoml, from the badge links. The import paths are explicit: lightautoml.automl.presets.tabular_presets for TabularAutoML and lightautoml.tasks for Task. Those two imports are the minimum viable setup.
The config keys shown in the quick tour are small in number. Task takes name and metric. The roles dictionary takes 'target' and 'drop'. fit_predict takes the dataframe and the roles. predict takes a dataframe and returns an object whose .data attribute holds the predictions. There is no config file, no YAML, no environment variables in the material. Configuration is Python objects passed at construction time.
One operational note in the README deserves attention because it is easy to miss. The profiler increases work time and memory consumption, and the README states plainly that you should not turn it on in production and that it is off by default. It also notes that the demo deletes the report at the end, and that you should comment out that deletion line if you want to inspect the report afterward. If you are running the demo notebooks as a first pass, that deletion line is the difference between seeing the profiling output and wondering where it went.
Where the documentation thins out
The README is a launchpad, not a reference. It links to Read the Docs, and that is where the detail presumably lives, but from the repository front page alone a reader cannot answer several basic questions. Which metrics does Task accept? The quick tour shows 'auc' for binary classification and nothing else. What does the drop list do beyond excluding columns? What is the default validation scheme, and can it be changed without dropping to the block layer? How are categorical columns detected, and what happens if detection is wrong?
These are not nitpicks. They are the questions that determine whether a first run produces a trustworthy number. A user who passes a metric string that is not recognized will find out at runtime, not from the README.
The tutorial list is generous, with eleven numbered notebooks plus Kaggle kernels covering competitions, SQL data sources, uplift, ICE and PDP interpretation, and relational data. That is a lot of surface area, and the breadth itself is a signal about where the project's effort has gone. The counterweight is that the front page does not summarize what any tutorial concludes. You have to open the notebook to learn whether it addresses your situation. For a library that positions itself as fast to start, the gap between the two-line example and the first real question is wider than the example implies.
A genuine limitation: the preset decides, and you inherit its decisions
The preset model has a structural cost. When you call TabularAutoML with a task and a metric, you are accepting the pipeline's choices about feature generation, model family, validation and blending. The README's quick tour gives you no parameters to inspect those choices. If the resulting OOF score is poor, the preset does not tell you which stage is responsible.
The escape hatch is the block layer, and the README points to Tutorial 6 for it. But that is a different mode of work. You are no longer writing two lines; you are assembling feature generation, feature selection, algorithm and hyperparameter optimization blocks yourself. The transition from preset to framework is not incremental, it is a rewrite of your training script.
There is a second limitation in the material. The README lists image data as supported, but none of the linked tutorials or Kaggle kernels in the supplied text is about images. Every named example is tabular, text, time series, relational or uplift. So the image claim is unverified by the material I have. That does not mean it is false, but a reader deciding based on the example list would not find evidence for it.
A third point: LAMA is a library. There is no mention of a scheduler, a model registry, a serving layer or a UI. If your requirement is a managed AutoML service, this is the wrong category of tool, not a weaker version of the right one.
How it differs from a minimal scikit-learn pipeline
The honest alternative for a tabular baseline is scikit-learn: a ColumnTransformer for preprocessing, a gradient boosting classifier, and cross_val_score. That approach gives you total visibility. Every transformation is a line you wrote. Nothing is hidden, and nothing is automatic either. You choose the imputation strategy, the encoding, the model, the folds. For a dataset whose quirks you already understand, that is often faster than learning a preset's conventions.
The difference in approach is where the decisions live. In scikit-learn, you make them and the library executes. In LightAutoML's preset, the library makes them and you execute. The block layer moves the boundary back toward scikit-learn, but with LAMA's own abstractions for feature generation and selection rather than sklearn's transformers.
That makes the choice less about accuracy and more about whether the preset's default decisions are ones you would have made anyway. On a clean tabular problem with a standard metric, they probably are, and the preset saves you the assembly. On a problem with unusual categorical encoding needs, leakage risks across time, or a metric that is not a standard classification or regression score, the preset's defaults become something you have to fight, and a hand-built sklearn pipeline is the shorter path. The README does not claim LAMA outperforms hand-built pipelines, and no benchmark in the supplied material supports such a claim either way.
Licence, release cadence and what upgrades cost you
LightAutoML is Apache-2.0. That is a permissive licence with an explicit patent grant, which matters if you are embedding the library in a commercial product. It is not legal advice and you should have your own counsel review the terms, but the licence category is the permissive kind rather than a copyleft one.
The release history shows a slow, uneven cadence: v0.4.0 in December 2024, v0.4.1 in March 2025, v0.4.2 in December 2025. Roughly one release per several months, and the last push to the default branch is dated after the most recent release. For a library you depend on in production, that rhythm means you should expect to pin a version and plan upgrades deliberately rather than track the tip of master.
The upgrade cost is hard to estimate from the material because the release notes are not included. What can be said is that the public surface shown in the README is small: TabularAutoML, Task, fit_predict, predict, and the roles dictionary. A small surface is cheaper to keep stable, but the block layer used by anyone on the customization path is a larger surface, and that is where breakage between minor versions would be felt most. If you build on the block layer, read the changelog before moving versions. If you use only the preset, the exposure is narrower.
Editorial conclusion
Adopt LightAutoML if you have a tabular, time series or text dataset and want a working baseline from the TabularAutoML preset before you invest in feature engineering, or if you specifically need an interpretable model via the WhiteBox and AutoWoE presets. Do not adopt it if you need a managed service with a scheduler, a UI or drift monitoring; LAMA is a Python library and the README offers nothing in that direction. Before committing, verify three things: that your Python version is on the PyPI classifiers, that your metric is accepted by the Task object (the README shows 'auc' for binary classification and does not enumerate the rest), and whether the profiler is off in your run, since the README states it increases work time and memory consumption. The last check is the cheapest and the one most likely to be skipped.
Community notes