LightOn gives semantic search a leaner index to work with

A document can answer a question without sharing its exact wording. That is why finding information is more demanding than spotting a keyword. For an AI assistant working over manuals, reports or code, the retrieval system determines which material reaches the model in the first place.

LightOn released SlideOn and mSlideOn on 19 October: two open retrieval models that turn learned representations into sparse features suitable for an inverted index. SlideOn has 174 million parameters and focuses on English; the 339-million-parameter mSlideOn covers multilingual, long-document and code retrieval.[1]

Learn a useful index entry

A book index maps an entry to the pages where it appears. A learned sparse index does something related with numerical features. A document activates a small subset of features; the index records which documents contain each one. A query activates features too, directing the search towards the corresponding document lists. Matching weights contribute to a relevance score.[1]

These features are learned rather than fixed to the tokenizer’s vocabulary. The same useful relationship can therefore be represented across different expressions. Most possible feature values remain zero, giving the system a way to skip documents with no matching activation. LightOn first trains a sparse autoencoder to reconstruct existing representations from few features, then fine-tunes the result for retrieval.[1]

The distinction matters for a search product. The model has to learn what is relevant; the index has to find it economically. A representation that works well for the first job can still be awkward for the second. This release changes the form in which learned information reaches the search engine.

Two budgets control the search

SlideOn exposes separate limits for query and document features. Keeping fewer query features means consulting fewer posting lists; keeping fewer document features means storing fewer weights. The model is trained to retain useful information when these budgets are tightened, so users can adjust them without retraining.[2]

The close ranking scores make the adjustable representation interesting. They do not supply a whole-service speed-up: a document search also has to encode the query, access its index and return results. Which stage dominates depends on the collection and the machine serving it.

The model card also reports 56.20 for the dense model from which SlideOn was developed. That comparison shows that converting to a sparse representation need not automatically sacrifice ranking quality, although the small score difference should not be read as a universal improvement on every collection.[2]

Multilingual results reveal a trade-off

mSlideOn’s closest comparisons are LightOn’s own mDenseOn and mLateOn, which share the training-data and teacher setup. On the full multilingual MIRACL benchmark, mSlideOn scores 62.78, against 58.02 for mDenseOn and 67.04 for mLateOn. On long-document MLDR, the scores are 61.68, 51.50 and 77.92 respectively.[3]

The sparse model therefore improves on the dense version in these comparisons while giving up some ranking quality against the model that preserves multiple vectors. Code retrieval is different: mSlideOn’s 74.78 exceeds both mDenseOn’s 71.53 and mLateOn’s 73.48. All are the developer’s reported nDCG@10 evaluations; results vary by task and language.[3]

For someone building search, the attractive option is a measurable choice between representation, retrieval quality and resource use. A multilingual help desk and a code archive need not choose the same operating point simply because both use AI.

LightOn has released training and evaluation code, including configuration files and saved run settings. That makes the method available for inspection and adaptation, alongside the finished models.[4]

A useful local comparison would begin with questions whose relevant documents are already known, then vary the feature budgets while following missed answers and response time. The result to seek is a smaller search workload that still brings the right document back.

Report an error or suggest a correction