> Gelernte spärliche Suche: wie SPLADE Begriffe erweitert, Modelle und Lizenzen, Indexgröße und Latenz, Engine-Unterstützung und wann es BM25 schlägt.
>
> Web page: https://balazscsorba.com/de/blog/splade-learned-sparse-retrieval · Language: Deutsch · Also available in: [English](https://balazscsorba.com/blog/splade-learned-sparse-retrieval.md) · [Magyar](https://balazscsorba.com/hu/blog/splade-learned-sparse-retrieval.md)
> Author: Balázs Csorba · Published: 2026-09-28 · Updated: 2026-10-01 · Keywords: learned sparse retrieval, SPLADE, SPLADE++ vs BM25, neural sparse search, Elasticsearch sparse_vector, ELSER, rank_features, OpenSearch neural sparse, learned sparse retrieval index size, sentence-transformers sparse encoder

[Blog](https://balazscsorba.com/de/blog)/Retrieval & Suche

# SPLADE und gelernte spärliche Suche in der Praxis: BM25, Indexgröße, Latenz

Gelernte spärliche Suche: wie SPLADE Begriffe erweitert, Modelle und Lizenzen, Indexgröße und Latenz, Engine-Unterstützung und wann es BM25 schlägt.

[Balázs Csorba](https://balazscsorba.com/de/about)·28\. September 2026·aktualisiert 1\. Oktober 2026·8 Min. Lesezeit

-   SPLADE
-   Sparse retrieval
-   BM25
-   Hybrid search
-   Elasticsearch

![Ein Wortstreifen fächert sich in viele dünne Balken auf, wenige hohe speisen einen Karteikasten.](https://balazscsorba.com/images/blog/splade-learned-sparse-retrieval/cover.webp?v=f3bfc3c3c9)

## Das Wichtigste in Kürze

-   Gelernte spärliche Suche behält den invertierten Index von BM25, lernt aber Termgewichte und ergänzt Erweiterungsbegriffe, sodass Dokumente auch Anfragen mit anderen Wörtern treffen.
-   Auf der BEIR-Teilmenge mit 13 Datensätzen erreichte SPLADE++ etwa 50,5 bis 50,7 mittleres nDCG@10 gegenüber 43,7 für BM25, und SPLADE++ plus BM25 kam auf 52,1, Fusion bringt also weiterhin etwas.
-   Naver stellt seine eigenen SPLADE-Checkpoints unter CC BY-NC-SA 4.0, was kommerzielle Nutzung ausschließt; Apache-2.0-Neuveröffentlichungen und ELSER sind die üblichen Auswege.
-   Die Kosten sind real, aber beherrschbar: OpenSearch maß den Index-Scan der Doc-only-Variante bei etwa dem 1,8-Fachen von BM25, und statisches Pruning bringt doppelte Geschwindigkeit bei höchstens 2 Prozent Qualitätsverlust.
-   Elasticsearch und OpenSearch betreiben gelernte spärliche Vektoren auf dem invertierten Index und fusionieren sie mit BM25 oder dichten Treffern; messen Sie mit Ihren Anfragen, bevor Sie einen zweiten Retriever ergänzen.

Auf dieser Seite

1.  [Was gelernte spärliche Suche ist](https://balazscsorba.com/#what-learned-sparse-retrieval-is)
2.  [Wie SPLADE Text erweitert](https://balazscsorba.com/#how-splade-expands)
3.  [Die Modellfamilie und ihre Lizenzfalle](https://balazscsorba.com/#the-model-family-and-licenses)
4.  [Die Effizienz in der Praxis: Indexgröße und Latenz](https://balazscsorba.com/#the-efficiency-reality)
5.  [Unterstützung in Elasticsearch und OpenSearch](https://balazscsorba.com/#engine-support)
6.  [Wann es BM25 schlägt und wann nicht](https://balazscsorba.com/#when-learned-sparse-beats-bm25)
7.  [Training und Domänenanpassung](https://balazscsorba.com/#training-and-domain-adaptation)
8.  [Eine praktische Checkliste](https://balazscsorba.com/#a-practical-checklist)
9.  [Quellen](https://balazscsorba.com/#sources)

Diesen Artikel anhören

0:000:00

**Gelernte spärliche Suche** behält die Mechanik von BM25, einen invertierten Index aus Vokabelbegriffen, ersetzt aber handabgestimmte Termstatistiken durch Gewichte, die ein Sprachmodell lernt, und ergänzt Erweiterungsbegriffe, die im Text nie vorkommen. SPLADE ist die bekannteste Familie. Ein Dokument über einen „Edelstahl-Kugelhahn“ kann so eine Anfrage nach einem „korrosionsbeständigen Absperrventil“ treffen, während Index, Suchmaschine und exakter Begriffsabgleich dieselben bleiben, die Sie schon betreiben.

Dieser Artikel behandelt, wie SPLADE Text erweitert, die Modellfamilie und ihre Lizenzfalle, was Index und Anfragen kosten, wie Elasticsearch und OpenSearch es betreiben und wann es BM25 oder eine dichte Hybridsuche schlägt. Wo spärliche Suche in einer vollständigen RAG-Pipeline sitzt, steht in [RAG-Pipelines: Chunking, hybride Suche und Reranking](https://balazscsorba.com/de/blog/rag-pipeline-chunking-hybrid-search-reranking); die Zahlen gelten Stand Oktober 2026.

## Was gelernte spärliche Suche ist

Es ist Suche in BM25-Form mit gelernten Gewichten und gelernter Vokabelerweiterung. Jedes Dokument und jede Anfrage wird zu einem Vektor über dem Vokabular des Modells, überwiegend Nullen, mit positiven Gewichten auf den wichtigen Begriffen, einschließlich verwandter Begriffe, die das Modell ergänzt. Weil der Vektor spärlich und nach Begriffen geschlüsselt ist, passt er in einen invertierten Index und behält die Nachvollziehbarkeit der Schlüsselwortsuche: Sie sehen, welche Begriffe getroffen haben.

Die Gewinne zeigen sich vor allem außerhalb der Trainingsdomäne. Im SPLADE++-Paper erreichte auf 13 BEIR-Datensätzen BM25 im Schnitt 43,7 nDCG@10, Contriever 47,5, ColBERTv2 49,7 und SPLADE++ 50,5 bis 50,7; die Summe der Werte von SPLADE++ und BM25 kam auf 52,1, die beiden ergänzen sich also weiterhin ([SPLADE++](https://arxiv.org/abs/2205.04733)). In der Domäne, auf MS MARCO, meldet dasselbe Paper BM25 mit 18,4 MRR@10 gegenüber 38,0 für SPLADE++.

Dichte Retriever lösen ein ähnliches Problem auf andere Weise: Sie bilden Text auf einige hundert oder tausend kontinuierliche Dimensionen ab und vergleichen per Vektorähnlichkeit. Sie sind stark bei Bedeutung und schwach bei seltenen exakten Begriffen, und ihre Treffer sind schwer zu erklären. Gelernte spärliche Suche liegt dazwischen: Sie behält exakten Begriffsabgleich und ein einsehbares Vokabular und leiht sich das Sprachmodell nur, um zu entscheiden, welche Begriffe zählen und welche verwandten Begriffe dazukommen.

## Wie SPLADE Text erweitert

SPLADE nutzt den Kopf für maskierte Sprachmodellierung von BERT, der für jedes Eingabetoken bereits vorhersagt, wie wahrscheinlich jeder Vokabelbegriff an dieser Stelle ist. Es leitet diese Werte durch eine ReLU und eine logarithmische Sättigung, bildet das Maximum über die Eingabetokens und erhält ein Gewicht pro Vokabelbegriff, 30.522 beim BERT-Vokabular ([SPLADE-v3](https://huggingface.co/naver/splade-v3)). Ein Sparsity-Regularisierer drückt im Training die meisten Gewichte auf null, sodass jeder Text nur seine wichtigen Begriffe und eine begrenzte Zahl von Erweiterungen behält.

![Wie SPLADE Text in einen spärlichen Vektor verwandelt Fünf Schritte von links nach rechts: der Eingabetext; ein BERT-Kopf für maskierte Sprachmodellierung bewertet jeden Vokabelbegriff für jedes Eingabetoken; ReLU und logarithmische Sättigung halten die Gewichte positiv und gedämpft; Max-Pooling über die Tokens ergibt ein Gewicht pro Vokabelbegriff, wobei ein Sparsity-Regularisierer die meisten auf null hält; und der entstehende spärliche Vektor mit 30.522 Dimensionen wird in einem normalen invertierten Index gespeichert.](https://balazscsorba.com/images/blog/splade-learned-sparse-retrieval/diagram-8.webp?v=5b99f4eeca)

Die Erweiterungsbegriffe kommen aus dem Sprachmodell, aber Index und Suchmaschine sind dieselben, die BM25 nutzt.

Bei der Erweiterung geht auch etwas schief. Ein auf Webfragen trainiertes Modell kann Begriffe ergänzen, die im allgemeinen Englisch plausibel, in Ihrer Domäne aber irreführend sind, etwa wenn es einen Produktlinien-Namen einem nicht verwandten Alltagswort zuordnet. Die wichtigsten Erweiterungsbegriffe für eine Stichprobe eigener Dokumente auszugeben, wie im Ausschnitt unten, dauert Minuten und zeigt schnell, ob das Modell Ihr Vokabular versteht oder angepasst werden muss.

Die Stärke des Regularisierers ist der wichtigste Regler: Stärkere Regularisierung bedeutet weniger Begriffe ungleich null, einen kleineren Index und schnellere Anfragen, zu einem gewissen Qualitätspreis. Navers eigenes Repository beschreibt SPLADE genau deshalb als „eher eine Klasse von Modellen als ein Modell an sich“ ([naver/splade](https://github.com/naver/splade)). Anfrage und Dokument lassen sich auch unterschiedlich kodieren, was die effizienten und Doc-only-Varianten unten ausnutzen.

```
# Encode with a learned sparse model and inspect the expansion terms (sentence-transformers SparseEncoder)
from sentence_transformers import SparseEncoder

model = SparseEncoder("Qdrant/Splade_PP_en_v1")        # Apache-2.0 re-host; check the license you deploy
doc = model.encode_document(["Stainless steel ball valve DN50, PN40, threaded ends"])
query = model.encode_query(["corrosion resistant shut-off valve 2 inch"])

for token, weight in model.decode(doc[0], top_k=12):    # expansion terms that were never in the text
    print(f"{token:>14}  {weight:.2f}")
print(model.similarity(query, doc))                     # dot product over the shared vocabulary
```

## Die Modellfamilie und ihre Lizenzfalle

Auf SPLADE v2 folgte SPLADE++, das Destillation von einem Cross-Encoder, geminte Hard Negatives und eine CoCondenser-Initialisierung ergänzte, und im März 2024 SPLADE-v3, das 40,2 MRR@10 auf MS MARCO und 51,7 mittleres nDCG@10 auf BEIR-13 bei maximal 512 Eingabetokens meldet ([SPLADE-v3](https://huggingface.co/naver/splade-v3)). 2026 veröffentlichte Naver außerdem SPLADE-Code-06B, ein Qwen3-basiertes 0.6B-Modell für Code, das seine Modellkarte als bestes MTEB-Modell unter 1B Parametern darstellt; behandeln Sie das als Herstellerangabe ([SPLADE-Code](https://huggingface.co/naver/splade-code-06B)).

**Navers Checkpoints sind nicht-kommerziell**

Das Repository naver/splade und Navers offizielle Checkpoints, auch SPLADE-v3, stehen unter CC BY-NC-SA 4.0. Damit scheiden sie für die meisten kommerziellen Produkte aus. Es gibt Apache-2.0-Neuveröffentlichungen der Community wie Qdrant/Splade\_PP\_en\_v1 ([Qdrant](https://huggingface.co/Qdrant/Splade_PP_en_v1)), und ELSER von Elastic sowie die spärlichen Modelle von OpenSearch sind Herstelleralternativen. Prüfen Sie die Lizenz genau des Checkpoints, bevor er in Produktion geht.

Modell

Größe

Lizenz

Wo es läuft

Hinweise

SPLADE-v3

BERT-base

CC BY-NC-SA 4.0

jede Engine mit spärlichen Vektoren

40,2 MRR@10, 51,7 BEIR-13

SPLADE++ (selfdistil)

BERT-base

CC BY-NC-SA 4.0

jede Engine mit spärlichen Vektoren

50,7 BEIR-13

Qdrant/Splade\_PP\_en\_v1

BERT-base, ONNX

Apache-2.0

Qdrant, FastEmbed, andere

kommerziell nutzbare Neuveröffentlichung

efficient-SPLADE

getrennte Anfrage- und Dok.-Encoder

CC BY-NC-SA 4.0

jede Engine mit spärlichen Vektoren

bis 4 ms an BM25-Latenz

ELSER v2

BERT-base, etwa 100M

Elastic, mit Abo

Elasticsearch

nur Englisch, 512 Tokens

Spärliche OpenSearch-Modelle

verschiedene

siehe Modellkarte

OpenSearch

Doc-only- und Bi-Encoder-Modus

## Die Effizienz in der Praxis: Indexgröße und Latenz

Erweiterung verlängert die Posting-Listen, ein gelernter spärlicher Index ist also größer und langsamer zu durchsuchen als ein BM25-Index über denselben Text; wie viel, hängt von der Regularisierungsstärke des Modells ab, und eine einzelne primäre Zahl für das Verhältnis habe ich nicht gefunden. Die gemessenen Kosten sind aber konkret. Der Benchmark von OpenSearch auf MS MARCO ergab für BM25 5,4 ms feste Latenz plus 2,80 ms pro Million Dokumente und für Doc-only Neural Sparse 8,7 ms plus 5,15 ms pro Million, etwa das 1,8-Fache des BM25-Scans ([OpenSearch](https://opensearch.org/blog/A-deep-dive-into-faster-semantic-sparse-retrieval-in-os-2-12/)).

![Index-Scan-Kosten pro Million Dokumente Drei horizontale Balken, gemessen in OpenSearch 2.12 auf MS MARCO. BM25 durchsucht den invertierten Index mit 2,80 ms pro Million Dokumente bei 5,4 ms fester Latenz. Doc-only Neural Sparse durchsucht mit 5,15 ms pro Million Dokumente bei 8,7 ms fest, etwa das 1,8-Fache von BM25. Bi-Encoder Neural Sparse, das pro Anfrage ein Modell ausführt, durchsucht mit 20,58 ms pro Million Dokumente bei 265,4 ms fest.](https://balazscsorba.com/images/blog/splade-learned-sparse-retrieval/diagram-18.webp?v=1aaa9a973f)

Doc-only gelernte spärliche Suche kostet pro Million Dokumente etwa das Doppelte von BM25; teuer ist das Modell pro Anfrage.

Teuer ist der Modus, der bei jeder Anfrage ein Modell ausführt. Im selben Benchmark brachte der Bi-Encoder-Modus 265,4 ms feste Latenz und 20,58 ms pro Million Dokumente; der zweiphasige Prozessor von OpenSearch, der zuerst mit hoch gewichteten Tokens bewertet und dann verfeinert, senkte die mittlere Latenz im Doc-only-Modus von 53,56 auf 38,61 ms und im Bi-Encoder-Modus von 300,79 auf 121,64 ms. Navers Effizienzarbeit erreichte mit getrennten, leichteren Anfrage-Encodern eine Latenz bis 4 ms an BM25 bei weniger als 10 Prozent Verlust an MRR@10 ([naver/splade](https://github.com/naver/splade)).

Pruning ist der günstigste Hebel. Statisches Pruning gelernter spärlicher Indizes brachte doppelte Geschwindigkeit bei höchstens 2 Prozent Qualitätsverlust oder vierfache bei höchstens 8 Prozent, und Reranker blieben auf Kandidaten aus geprunten Indizes robust ([statisches Pruning](https://arxiv.org/abs/2304.12702)). Der Ingest-Prozessor von OpenSearch unterstützt mehrere Pruning-Arten, und `max_ratio` mit 0,1 senkt den Speicher um etwa 40 Prozent bei weniger als 1 Prozent Relevanzverlust ([OpenSearch](https://docs.opensearch.org/latest/ingest-pipelines/processors/sparse-encoding/)).

## Unterstützung in Elasticsearch und OpenSearch

Beide Engines speichern gelernte spärliche Vektoren als gewichtete Begriffe im invertierten Index. In Elasticsearch ist `sparse_vector` der richtige Feldtyp; Token-Pruning ist seit 9.1 standardmäßig aktiv, spärliche Vektoren sind seit 9.2 standardmäßig aus `_source` ausgeschlossen, und Gewichte werden mit 9 signifikanten Bits gespeichert, etwa 0,4 Prozent relativer Fehler ([Elastic](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/sparse-vector)). Elastics eigenes Modell ELSER v2 beherrscht nur Englisch, kodiert die ersten 512 Tokens eines Felds und gewann 10 von 12 BEIR-Datensätzen gegen BM25 mit durchschnittlich 18 Prozent mehr nDCG@10 ([ELSER](https://www.elastic.co/docs/explore-analyze/machine-learning/nlp/ml-nlp-elser)).

Die anfrageseitige Optimierung von ELSER lohnt sich als Prinzip: Anfragetokens entfernen, die viel häufiger sind als erwartet, Tokens über 0,4 des Maximalgewichts behalten und die Top 50 mit dem vollen Tokensatz neu bewerten. Elastic meldet im Schnitt 3,4-fache Beschleunigung bei vernachlässigbarer Änderung des nDCG@10 ([Elastic Search Labs](https://www.elastic.co/search-labs/blog/introducing-elser-v2-part-2)). Für die Fusion kombiniert der RRF-Retriever von Elasticsearch einen BM25-Standard-Retriever mit einem ELSER-Retriever bei einem Standard-`rank_constant` von 60 ([RRF](https://www.elastic.co/docs/reference/elasticsearch/rest-apis/reciprocal-rank-fusion)). OpenSearch bietet Doc-only- und Bi-Encoder-Modus für Neural Sparse, einen zweiphasigen Prozessor und seit 3.3 approximative Suche auf `sparse_vector`\-Feldern.

Auch eigene Vektorspeicher unterstützen spärliche Vektoren, was zählt, wenn Sie bereits einen betreiben; die [Qdrant-Besprechung](https://balazscsorba.com/de/blog/qdrant) behandelt diese Seite. Die allgemeine Mechanik von Vektoren in einem Suchcluster steht in [Vektorsuche in Elasticsearch und OpenSearch](https://balazscsorba.com/de/blog/elasticsearch-opensearch-vector-search).

In der Praxis folgt die Wahl der Engine dem Cluster, den Sie bereits betreiben. Nutzen Sie Elasticsearch mit Elastic-Abo und englischen Inhalten, ist ELSER der geringste Aufwand. Nutzen Sie OpenSearch, sind dessen eigene spärliche Modelle und der Doc-only-Modus der natürliche Start. Wollen Sie einen offenen SPLADE-Checkpoint in einer der beiden Engines, kodieren Sie Dokumente selbst in einem Ingest-Job und schreiben die Tokengewichte in ein spärliches Feld, das beide Engines akzeptieren.

## Wann es BM25 schlägt und wann nicht

Gelernte spärliche Suche hilft am meisten, wenn Anfragen und Dokumente unterschiedliche Wörter für dasselbe verwenden: Nutzerfragen gegenüber technischer Dokumentation, Produktsuchen in natürlicher Sprache gegenüber knappen Katalogtexten, Synonyme und Umschreibungen im Englischen. Sie liefert außerdem einen zweiten Retriever, dessen Treffer sich Begriff für Begriff erklären lassen, was dichte Vektoren nicht bieten. In B2B-Katalogen aus der Arbeit mit Spryker und Pimcore, voller Artikelnummern und normalisierter Attribute, ist genau diese Kombination aus Erweiterung und exakten Begriffen die Hauptmotivation.

Sie hilft weniger, wenn Anfragen überwiegend exakte Bezeichner sind, die BM25 bereits trifft, wenn der Inhalt nicht englisch ist und das Modell nur Englisch kann, wie ELSER, oder wenn der Korpus so groß ist, dass eine zweite, längere Posting-Liste der teure Teil ist. Auf Benchmarks ist sie auch nicht durchgehend besser; die SPLADE++-Ergebnisse zeigen BM25 auf einigen BEIR-Datensätzen weiterhin vorn. Produktsuche mit Teilenummern im Besonderen behandelt [semantische Produktsuche im B2B](https://balazscsorba.com/de/blog/semantic-product-search-b2b).

## Training und Domänenanpassung

Ein spärliches Modell anzupassen ist mit einer GPU machbar. Das Repository naver/splade liefert Konfigurationen pro Trainingsszenario, darunter eine Einzel-GPU-Konfiguration auf einer 16-GB-Karte, die 37,2 MRR@10 erreicht ([naver/splade](https://github.com/naver/splade)). Sentence Transformers hat inzwischen einen vollwertigen SparseEncoder mit SPLADE-spezifischen Losses wie SpladeLoss, CachedSpladeLoss und FlopsLoss und unterstützt asymmetrische Kodierung von Anfrage und Dokument ([Sentence Transformers](https://sbert.net/docs/sparse_encoder/usage/usage.html)).

Für andere Sprachen als Englisch ist Anpassung oft der einzige Weg, weil die meisten veröffentlichten spärlichen Checkpoints, ELSER eingeschlossen, nur Englisch können. Ein mehrsprachiges Basismodell mit BERT-artigem Vokabular lässt sich mit denselben Losses zu einem spärlichen Encoder trainieren, aber das Vokabular selbst begrenzt, was erweitert werden kann; deutsche Komposita etwa werden in Wortteile zerlegt, und die Erweiterung arbeitet auf diesen Teilen statt auf ganzen Wörtern.

Die Datenseite ist dieselbe wie beim dichten Feintuning: Anfrage-Dokument-Paare aus Logs oder generierten Anfragen, geminte Hard Negatives und ein eingefrorenes Evaluierungsset; [Embedding-Modelle feintunen](https://balazscsorba.com/de/blog/embedding-fine-tuning-domain) behandelt diese Schleife. Der Sparsity-Regularisierer ist der zusätzliche Regler, und es lohnt sich, ihn durchzuprobieren, weil er Qualität direkt gegen Indexgröße und Latenz tauscht.

## Eine praktische Checkliste

1.  Zuerst BM25 und Ihre aktuelle Hybridsuche auf einem gelabelten Anfrageset messen.
2.  Lizenz genau des Checkpoints prüfen; Navers sind nicht-kommerziell.
3.  Sprachabdeckung des Modells mit Ihren Inhalten abgleichen.
4.  Im Doc-only-Modus beginnen und Tokens prunen, bevor Sie Latenz messen.
5.  Per RRF mit BM25 oder dichten Treffern fusionieren und mit Fusion ohne es vergleichen.
6.  Indexgröße und p95-Latenz bei Ihrer echten Dokumentenzahl messen.
7.  Nur behalten, wenn der Recall bei Ihrem k genug steigt, um den zweiten Index zu bezahlen.

Wenn Sie entscheiden, ob ein gelernter spärlicher Retriever neben BM25 und dichter Suche seinen Platz verdient, sehen Sie sich meine [KI-Engineering-Arbeit](https://balazscsorba.com/de/expertise/ai-engineer) an.

## Quellen

1.  [naver/splade on GitHub](https://github.com/naver/splade)
2.  [SPLADE++ (arXiv 2205.04733)](https://arxiv.org/abs/2205.04733)
3.  [naver/splade-v3 model card](https://huggingface.co/naver/splade-v3)
4.  [Static pruning for learned sparse indexes (arXiv 2304.12702)](https://arxiv.org/abs/2304.12702)
5.  [OpenSearch blog: faster semantic sparse retrieval in 2.12](https://opensearch.org/blog/A-deep-dive-into-faster-semantic-sparse-retrieval-in-os-2-12/)
6.  [OpenSearch docs: sparse encoding processor](https://docs.opensearch.org/latest/ingest-pipelines/processors/sparse-encoding/)
7.  [Elastic docs: sparse\_vector field type](https://www.elastic.co/docs/reference/elasticsearch/mapping-reference/sparse-vector)
8.  [Elastic docs: ELSER](https://www.elastic.co/docs/explore-analyze/machine-learning/nlp/ml-nlp-elser)
9.  [Elastic Search Labs: ELSER v2, part 2](https://www.elastic.co/search-labs/blog/introducing-elser-v2-part-2)
10.  [Sentence Transformers: sparse encoder usage](https://sbert.net/docs/sparse_encoder/usage/usage.html)

## Häufige Fragen

Was ist gelernte spärliche Suche?

Ein Suchverfahren, das Text als spärlichen Vektor von Vokabelbegriffen mit gelernten Gewichten darstellt, einschließlich Erweiterungsbegriffen, die im Text nicht vorkommen. Es läuft auf einem normalen invertierten Index wie BM25, trifft aber verwandte Formulierungen ähnlich wie ein dichtes Modell.

Ist SPLADE besser als BM25?

Auf Benchmarks außerhalb der Trainingsdomäne meist ja: SPLADE++ erreichte auf 13 BEIR-Datensätzen im Schnitt etwa 50,7 nDCG@10 gegenüber 43,7 für BM25. Es ist nicht überall besser, und die Kombination mit BM25 lag noch höher. Testen Sie mit Ihren eigenen Anfragen, besonders wenn exakte Bezeichner dominieren.

Darf man SPLADE kommerziell nutzen?

Navers offizielle SPLADE-Checkpoints und das Repository stehen unter CC BY-NC-SA 4.0, also nicht-kommerziell. Es gibt Apache-2.0-Neuveröffentlichungen der Community wie Qdrant/Splade\_PP\_en\_v1, und ELSER von Elasticsearch sowie die eigenen spärlichen Modelle von OpenSearch sind Alternativen. Prüfen Sie die Lizenz genau des Checkpoints, den Sie einsetzen.

Wie viel langsamer ist gelernte spärliche Suche als BM25?

Im Benchmark von OpenSearch durchsuchte die Doc-only-Variante den Index mit etwa 5,15 ms pro Million Dokumente gegenüber 2,80 ms bei BM25, also etwa das 1,8-Fache. Der Bi-Encoder-Modus, der pro Anfrage ein Modell ausführt, war deutlich langsamer. Token-Pruning und eine zweiphasige Anfrage verkleinern den Abstand.

Unterstützt Elasticsearch Suche im Stil von SPLADE?

Ja. Elasticsearch hat den Feldtyp sparse\_vector und ein eigenes gelerntes spärliches Modell, ELSER, das nur Englisch beherrscht und die ersten 512 Tokens eines Felds kodiert. Token-Pruning ist seit 9.1 standardmäßig aktiv, und RRF kann ELSER mit BM25 oder dichten Retrievern fusionieren.

Geschrieben von Balázs Csorba

Senior Fullstack & AI Engineer in der Steiermark – über 10 Jahre Vue, Nuxt, Node.js und PHP, heute baue ich Werkzeuge für KI-Agenten.

[KI-Entwicklung & MCP-Server →](https://balazscsorba.com/de/expertise/ai-engineer)[Über mich →](https://balazscsorba.com/de/about)

## Weitere Artikel

-   [Embedding-Modell wählen 2026: Leaderboards, Kosten und ein Vergleichstest mit eigenen Daten](https://balazscsorba.com/de/blog/embedding-model-selection-2026)
-   [Contextual Retrieval und Late Chunking: RAG-Chunks ihren Kontext zurückgeben](https://balazscsorba.com/de/blog/contextual-retrieval-late-chunking)
-   [Zugriffskontrolle für RAG: berechtigungsbewusstes Retrieval ohne Datenlecks](https://balazscsorba.com/de/blog/rag-access-control-permissions)
-   [RAG über Produktkataloge: aus PIM-Daten Antworten machen, die halten](https://balazscsorba.com/de/blog/rag-product-catalog-pim-data)

## Klingt nach dem, was du suchst?

Erzähl mir von deinem Projekt oder deiner Stelle – ich freue mich, von dir zu hören.

[Kontakt aufnehmen](mailto:contact@balazscsorba.com) [Auf LinkedIn vernetzen](https://www.linkedin.com/in/balazs-csorba)