[AI Ideas Notebook 01] SlideOn: a smaller search model with two useful cost controls

AI Ideas Notebook explores the ideas and practical possibilities behind newly emerging AI models and tools.

You remember that a document explains how to cancel an order. The search box remembers only the word cancellation. Unfortunately, the document calls the same process withdrawal. A collection can contain the right answer and still be difficult to use.

LightOn introduced SlideOn and mSlideOn on October 19, 2026, as two models for retrieving relevant documents. SlideOn focuses on English; mSlideOn extends the approach to multilingual text, long documents and code. Their particular appeal is a pair of adjustable budgets: how many features a query uses, and how many features each stored document keeps. LightOn announcement

This introduction explains where the models fit, what those controls change, and how to try a small comparison before building a search service. You do not need a new chat application to understand the idea. Start with a question, a few documents, and a definition of a useful result.

Public model-card screen captured October 20, 2026. Source: LightOn on Hugging Face. This is the published model page, not a local inference result; the interface also shows that a downloadable model need not have a hosted inference provider.

Search needs a good shortlist before an answer

A retriever ranks documents against a query. It does not have to write an answer, summarize the files, or decide whether a company should change its policy. Its immediate job is narrower: put the most relevant source material near the top.

Consider an internal handbook with three pages about returns, shipping and staff holidays. A question about sending back a damaged order should bring the returns page forward. If the first result instead discusses the holiday calendar, a fluent answer generator downstream has already started with the wrong evidence.

This distinction makes retrieval useful even without generative AI. A support specialist can open the ranked document directly. A researcher can collect passages for comparison. A coding tool can use retrieval to find a likely implementation before a person inspects it.

There is also a useful separation of responsibility. Retrieval helps locate evidence; the original document remains the place to verify wording, dates and exceptions. A good result should make it easier to reach that source, rather than replacing the source with a confidence score.

Sparse search keeps a selective address book

Think of a search index as an address book. A conventional keyword index records which documents contain a term. A learned sparse model creates another kind of address book: it assigns weights to a relatively small set of learned features, then uses shared active features to score queries against documents.

The word sparse describes that selectivity. A representation may have many possible positions while using only a fraction of them for a particular text. An inverted index can associate each active feature with the documents that use it, helping a search engine focus on relevant posting lists.

SlideOn's model card specifies 32,768 possible learned features and independent query and document pruning controls. Those feature positions are learned latents, not a transparent dictionary of English words. You should not interpret feature 100 as a guaranteed synonym for “returns.” SlideOn model card

That last detail matters when explaining results. Sparse representations can be economical to search without making every internal decision human-readable. The practical explanation for a user should still be a relevant passage from the source document, with enough context to check why it matches.

Original explanatory diagram. The example feature marks illustrate the process; they are not activations measured from SlideOn.

Choose the model for the collection you actually have

The two names describe related starting points, not interchangeable language settings. LightOn lists SlideOn at 174 million parameters and mSlideOn at 339 million parameters in its release. The larger number alone does not establish which one will serve your collection better. October 19 release

A multilingual label is a reason to investigate, not a shortcut around evaluation. A bilingual catalog may contain translated copies, regional policies that differ, and terminology that has no single literal equivalent. These are different retrieval problems even when the documents share a language tag.

For example, imagine searching a French refund policy with an English question. That is a cross-language task. Searching a French document with a French query is a same-language task. Record them separately: an aggregate score can hide a weak experience for one group of readers.

The same principle applies to code. Finding a source file about “session recovery” requires something different from matching an exact function name. Keep exact identifier queries in the comparison as well as descriptive questions, because a useful search system often needs both.

Your first experiment can fit in a notebook

Begin with public or synthetic text and a clean Python environment. The published example uses Sentence Transformers' SparseEncoder; it is a model-loading interface rather than a complete search server. The following is an adaptation of the official recipe, checked October 20, 2026. Documented usage

1. Open the model card and review the repository's custom inference code and dependencies. The loader below uses trust_remote_code=True, which permits that repository's Python implementation to execute; use a reviewed revision for a repeatable experiment.
2. Create an isolated environment and install the documented library range.
3. Encode one query and a few short documents. Use the model's query and document methods rather than adding prefixes by hand.
4. Inspect the scores beside the actual document text. This first check is about ranking, not a universal score threshold.

python -m venv .venv
# Activate .venv using the command for your shell.
python -m pip install "sentence-transformers>=6.1,<6.2" "transformers>=5.3,<6"

from sentence_transformers import SparseEncoder

model = SparseEncoder("lightonai/SlideOn", trust_remote_code=True)
documents = [
    "Customers may return a damaged order within the stated return period.",
    "Standard delivery takes three working days after dispatch.",
    "Staff should record annual leave in the shared calendar.",
]
queries = ["What should I do if my delivery arrives broken?"]

q = model.encode_query(queries, top_k=64)
d = model.encode_document(documents, top_k=512)
scores = model.similarity(q, d)
print(scores)

The documents above are invented teaching examples. There is no claimed output or measured accuracy attached to this code. You should expect to inspect whether the returns document ranks first, then try paraphrases and deliberately difficult alternatives.

Do not stop after the easiest query works. Ask about cancelling an order before dispatch, a damaged parcel after delivery, and a refund after the stated deadline. If the collection does not answer a question, the test should reveal that absence instead of rewarding an attractive but irrelevant result.

Two budgets answer two different cost questions

Query pruning limits the features used when asking a question. Document pruning limits the features stored for each indexed item. In a large service, the first budget concerns work repeated for each search; the second also affects the index that remains between searches.

A useful trial changes one budget at a time. Keep the document representations fixed while adjusting query pruning, then repeat with alternative document budgets. If both change at once, a different result gives you little help deciding which change caused it.

There is no universal “small enough” setting. A short FAQ, a multilingual archive and a software repository have different distributions of language, length and repetition. A configuration that works for broad questions may lose the rare detail that distinguishes two nearly identical procedures.

Original experiment plan. These are comparison conditions, not benchmark results or recommended production settings.

Keep quality, time and storage in separate columns. If search gets faster while the relevant article falls out of the first page, the time improvement is not free. If a larger index gives no meaningful benefit on the questions people ask, its extra storage may not earn its place.

A benchmark number is not a response-time measurement

The model card reports 56.68 nDCG@10 on BEIR-15 for SlideOn's unpruned setting. That is an attributed ranking-quality result across the benchmark's datasets, not the probability that a particular answer is correct. It also is not a count of milliseconds. Published evaluation

LightOn's efficiency discussion distinguishes a retrieval FLOPS proxy from measured latency, and document nonzero counts from index size in bytes. That distinction is worth keeping in any comparison table. A mathematical proxy helps explain a mechanism; an operational measurement tells you what your system actually does.

For a small evaluation, a stopwatch alone is also incomplete. Initial model loading, document encoding, index construction and repeated queries are different phases. Report cold startup separately from a warm search, and make clear whether a timing includes the work of encoding the query.

The same care applies to quality scores. A retriever can find the right document while placing the wrong passage near the top of a long file. Record whether your judging unit is a file, a section or a passage, and use the same unit for every candidate.

Three practical collections make the tradeoffs visible

An operations handbook is a good first example because the desired result is often clear. Write questions about returns, dispatch delays and account access, then identify the authoritative page for each. Include questions whose wording differs from the page heading so you test more than title matching.

A multilingual project archive adds another challenge: the same subject can appear in meeting notes, a translated announcement and an older plan. Use metadata to distinguish current policy from historical discussion. Semantic similarity does not decide which version an organization should follow.

A developer documentation collection adds exact strings and near-duplicates. A question about a timeout may need both a conceptual guide and a configuration key. Preserve lexical search as a baseline, and inspect whether a hybrid approach earns its complexity on your actual questions.

These are suggested evaluation scenarios, not deployed case studies. Their purpose is to make the acceptance criteria concrete. In each case, the important artifact is a list of questions, accepted sources and observed rankings that another person can review.

Make the first comparison small enough to finish

Use perhaps 30 representative questions rather than an unbounded pile of queries. Divide them into ordinary lookups, paraphrases, ambiguous cases and questions the collection cannot answer. This is a proposed starter design, not a statistically representative benchmark.

Have a subject expert judge the expected results before tuning. Otherwise, every surprising ranking invites a new explanation of what the question “really meant.” Keep a separate set of untouched questions for a final check so the settings do not merely memorize the examples used during development.

Record the model revision, preprocessing rules, chunk size, pruning settings and machine details. Changing any one of these can change the comparison. A short run that another person can repeat is more useful than a large score whose inputs have disappeared.

Finally, inspect the result screen at the size people will use. A correct top hit still fails the user when the title is truncated beyond recognition or the excerpt hides the deciding sentence. Retrieval quality and interface quality meet at the moment a person chooses what to open.

Better search gives people a shorter route to the source

Our view is that SlideOn's useful idea is the separation of quality and resource budgets into controls you can test. That is a more practical starting point than assuming every search problem needs a larger answer model. It invites a modest experiment: preserve the questions, vary the representation, and inspect what people can actually find.

Start with the document your team repeatedly fails to locate. If the new retriever reliably brings it forward under different wording, you have a concrete improvement to build on. The destination is still a readable source; the model's job is to shorten the route.

Sources and media

Checked October 20, 2026. The setup example adapts the public model card; no installation, local inference or independent benchmark is claimed. Screenshot: LightOn's public model page on Hugging Face, captured by the author. The two diagrams are original. Asset sources and license notices accompany the media record.

• LightOn release, October 19, 2026
• SlideOn model card and usage
• mSlideOn model card and language details
• Training and evaluation repository

Keep the questions beside the evidence

Save the query set, source links and review notes together so a later comparison answers the same questions. Telli.sh can help organize that research record. Create a Telli.sh account