Neural sparse search in OpenSearch: token weights are not ordinary BM25

Learned sparse retrieval requires matching document and query vocabularies, not merely accepting arrays of token identifiers and weights. OpenSearch neural sparse search and ordinary BM25 both use sparse structures, but they do not become interchangeable scoring methods or representations because their storage appears superficially similar.

Distinguish lexical counts from learned weights

The original SPLADE implementation illustrates learned sparse representations. A model can assign weights to vocabulary dimensions beyond literal term occurrence. BM25 derives its own term-based scoring ingredients. Treat the representation’s training and tokenizer as part of the retrieval contract. A token identifier has meaning only within its vocabulary; the same integer from another tokenizer need not represent the same word or concept.

Read the OpenSearch integration boundary

The official neural sparse guide describes model and index integration, while the neural-search repository supplies implementation details. Preserve model revision, preprocessing, sparse-field mapping and query encoding policy. Different documented modes can allocate work differently between indexing and querying. Do not infer that an arbitrary sparse model can replace another without verifying its input, output and supported integration path.

Test literal and expanded matches

Use a troubleshooting collection with a literal error phrase, a paraphrased explanation and a near-identical phrase referring to another product. Query both the literal wording and a paraphrase. Inspect which sparse dimensions contribute and whether product applicability remains correct. This fixture distinguishes useful semantic expansion from broad topic similarity that promotes an incompatible procedure despite an apparently strong relevance score.

Contract component	Mismatch consequence
Tokenizer vocabulary	Identifier dimensions lose shared meaning
Model revision	Learned weights may change
Query encoding mode	Query and document contracts diverge
Product metadata	Relevant topic can select wrong applicability

Keep thresholds and filters distinct

A minimum score or weight-pruning decision affects which matches survive; an applicability filter governs whether a document is eligible. Do not use a weak score adjustment as a substitute for a required product constraint. Inspect the chosen version’s pruning and inference behavior before copying settings between integrations. Sparse output is not automatically a calibrated relevance probability, and a high value cannot independently establish answer sufficiency.

Migrate as a representation change

When changing the encoder or vocabulary, determine whether stored document representations must be rebuilt and evaluate a separate index. Compare candidate coverage, exact-term failures and paraphrase gains on held-out questions. Keep original text and encoding provenance for error analysis. This produces an auditable learned-sparse retrieval path without claiming universal superiority to BM25 or silently mixing incompatible weighted dimensions in a supposedly coherent index.