# 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.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/opensearch-neural-sparse-vocabulary-contract/
Language: en

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](https://github.com/naver/splade) 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](https://docs.opensearch.org/latest/vector-search/ai-search/neural-sparse-search/) describes model and index integration, while the [neural-search repository](https://github.com/opensearch-project/neural-search) 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.

Related reading: [Embeddings and rerankers: other tasks for an idle GPU](/journal/embeddings-rerankers-gpu/); [Batch text embeddings on your own GPU](/journal/text-embeddings-batch/).