LightOn's SlideOn: open sparse retrievers, BEIR-15 score 56.68

LightOn published SlideOn and mSlideOn on 19 October 2026 on the Hugging Face blog. LightOn says they are open sparse retrieval models: SlideOn has 174M parameters and handles English, and mSlideOn has 339M parameters and covers multilingual, long-context and code retrieval. LightOn says it releases the models, the sparse autoencoder checkpoints and the training code under a permissive license.

What a sparse retriever changes

A dense retriever turns every query and document into a full vector and compares them. A sparse retriever, as LightOn describes it, produces a vector in which most values are zero, so a classic inverted index can skip every document that shares no active feature with the query. LightOn argues this suits very large collections, and cites earlier work reporting that sparse retrievers can run index search on CPU at similar latency to dense baselines on GPU. That is the cited research's claim, not a result from this release.

LightOn built the models by converting two of its existing retrievers, DenseOn and mLateOn, using sparse autoencoder pretraining and supervised fine-tuning. It says this is much cheaper than training a retriever from scratch. The fine-tuning mixture is about 16.3M query-document pairs across nine languages and code.

What LightOn reports

• SlideOn scores 56.68 on BEIR-15, against 56.20 for DenseOn.
• mSlideOn beats mDenseOn by 4.76 points on MIRACL (multilingual retrieval) and by 10.19 points on MLDR (long documents), and LightOn says it also beats mLateOn and mDenseOn on MTEB Code.
• LightOn says both models keep retrieval quality as sparse vectors are pruned, so a team can trade quality for lower latency and storage.

What the post leaves out

The benchmarks are LightOn's own, run against its own earlier models, and I found no independent replication. The summary and conclusion claim leading position on cost and storage frontiers among the sub-2B models LightOn compared, but give no headline latency, memory or index-size figure for a given corpus size. How much pruning your data tolerates is unknown until you test it. Benchmark averages also say little about your company's documents.

What to do

• If you run RAG or enterprise search on a dense index that is costly to store or serve, add SlideOn or mSlideOn to your next retrieval evaluation.
• Measure recall on your own queries at several pruning levels, and record index size and query latency next to your current retriever.
• Check the license on each model card before production use.