Reranker auf Deutsch im Test: Was sie für Wissensdatenbank und RAG bringen – und was sie kosten

Gemessen haben wir vom 9. Oktober 2026 bis zum 11. Oktober 2026, auf 305 deutschen Fragen aus dem öffentlichen Datensatz MIRACL. Messplan, Abweichungen und alle Ergebnisse liegen offen bei uns: Messplan, Abweichungen und Ergebnisse.

Das Wichtigste in Kürze

Eine Suche arbeitet meist in zwei Schritten. Zuerst holt sie schnell eine Liste möglicher Treffer, die erste Stufe. Ein Reranker ist ein zweiter, genauerer Blick auf die ersten 100 Treffer: Er liest jede Frage zusammen mit jeder Passage und sortiert die Liste neu. Nach einer Hybrid-Suche stand danach bei mindestens 50,8 % statt 33,8 % der Fragen eine passende Passage unter den ersten fünf. Beide Werte zählen nur Passagen, die MIRACL bewertet hat; wie groß der Abstand genau ist, hängt an Lücken in diesen Urteilen (Abschnitt „Grenzen der Messung“). Ob sich ein Reranker für Sie lohnt, hängt von Ihrer Lage ab:

• Nur Stichwortsuche: Prüfen Sie zuerst die Einstellungen für Deutsch, das kostet nichts. In unserer Messung stieg die Qualität (nDCG@10) von 0,012 mit den Standardeinstellungen von Typesense auf 0,074 mit deutschen Einstellungen, darunter drop_tokens_threshold=100, und mit einem Reranker über 100 Kandidaten auf 0,215.
• Chat mit eigenen Dokumenten (RAG): Nach Stichwort- oder Hybrid-Suche spart ein Reranker in unserer Rechnung meist mehr Kontext, als er kostet. Mit einem teuren Sprachmodell ein Vielfaches: nach der Stichwortsuche 20,53 € gegen 0,97 € je 1.000 Anfragen. Mit einem günstigen Modell wie DeepSeek Flash ist es knapper: nach der Stichwortsuche 1,54 €, mehr als der Reranker kostet; nach der Hybrid-Suche lohnt sich zur Nebenzeit nur die günstigere Variante rerank-3-lite (0,52 € gegen 0,38 €), zur Hauptzeit von DeepSeek auch rerank-3.
• Live-Suche im Hilfe-Center oder in der Wissensdatenbank: Mit 20 Kandidaten passt ein Reranker ins Zeitbudget von 500 ms, als API (95 % der Anfragen unter 366 ms, gemessen an einem Wochenende) oder auf einer GPU mit gte-multilingual-reranker-base oder bge-reranker-v2-m3 (41 ms bzw. 86 ms im Median). Qwen3-Reranker-0.6B und die übrigen Modelle auf Basis von Sprachmodellen sind dafür zu langsam.
• Kein GPU-Server: Nehmen Sie eine API. Auf einem Prozessor dauerte eine Anfrage in unserem Aufbau (PyTorch, ohne Quantisierung) 4,2 s bis 188,6 s. Die günstigere Voyage-Variante kostet 0,08 € bis 0,38 € je 1.000 Anfragen.
• Die Daten dürfen das Haus nicht verlassen: Ein eigener GPU-Server mit bge-reranker-v2-m3 (offene Lizenz, kommerziell nutzbar) leistet das. Seine Qualitätswerte lesen wir mit Vorsicht: MIRACL gehört laut MTEB-Registry zu seinen Trainingsdaten. Ehrlich gesagt ist das eine Frage des Datenschutzes, nicht der Kosten: Gegen die API rechnet sich der Server erst ab etwa 224.451 Anfragen im Monat.
• Gute Vektorsuche vorhanden: Sieben von neun Modellen waren noch deutlich besser, um +3,7 bis +9,2 Punkte (Höchstwert Qwen3-Reranker-4B, mit MIRACL trainiert wie das Embedding der Vektorsuche), und 20 Kandidaten reichen. gte-multilingual-reranker-base lag gleichauf, mxbai-rerank-large-v2 nach den MIRACL-Urteilen deutlich schlechter; es stellt aber mehr unbewertete Passagen nach vorn, der Befund ist unsicher.

Die Empfehlungen gelten für Fragen in ganzen Sätzen, wie sie in einer Wissensdatenbank, einem Hilfe-Center oder einem Chat gestellt werden. Kurze Suchbegriffe im Shop („teichfolie 1 mm“) können sich anders verhalten; das haben wir hier nicht gemessen. Die Produktsuche bekommt einen eigenen Artikel.

Was ein Reranker macht und wie man ihn einbaut

Die erste Stufe muss in Millisekunden durch Zehntausende oder Millionen Passagen. Eine Stichwortsuche vergleicht dafür Wörter, eine Vektorsuche vergleicht vorab berechnete Zahlenvektoren von Frage und Passage. Beides ist schnell, aber grob: Die Frage und die Passage werden nie zusammen gelesen.

Ein Reranker, meist ein sogenannter Cross-Encoder, macht genau das. Er bekommt Frage und Passage gemeinsam und gibt einen Wert dafür aus, wie gut die Passage die Frage beantwortet. Das ist deutlich genauer, aber teurer. Deshalb sortiert er nur die ersten k Treffer der ersten Stufe neu, typisch 20 bis 100.

Typesense, die Suchmaschine in unserem Test und in vielen Shops, hat kein eingebautes Reranking mit einem solchen Modell (Stand Version 30.2). Der Reranker ist ein eigener Dienst: ein Server mit GPU oder eine API. Für den Betrieb empfehlen wir drei Dinge; das sind Erfahrungswerte, keine Messergebnisse:

• Ein Zeitlimit mit Rückfall. Antwortet der Reranker nicht rechtzeitig, bleibt die Reihenfolge der ersten Stufe. Die Suche wird dann nicht schlechter als ohne Reranker, nur nicht besser.
• Eine bewusste Wahl von k. Mehr Kandidaten bringen nach einer schwachen ersten Stufe spürbar mehr Treffer, kosten aber Zeit und Geld (Abschnitt „Wie viele Kandidaten“).
• Ein Zwischenspeicher für häufige Fragen. Dieselbe Frage mit denselben Kandidaten ergibt denselben Wert.

Warum wir nachgemessen haben

Für deutsche Texte gab es bisher keinen unabhängigen Vergleich der gängigen Reranker mit Latenz und Kosten. Die wenigen deutschen Qualitätszahlen stammen aus drei Quellen, und je nach Quelle unterscheidet sich die Rangfolge. Qwen3-Reranker-0.6B etwa bringt im Jina-Paper keinen Gewinn gegenüber der ersten Stufe, im Querit-Paper liegt er hinter bge-reranker-v2-m3, im HAKARI-Benchmark vorn. Das muss kein Widerspruch sein: Korpus, erste Stufe und Teilmenge unterscheiden sich. Zwei der drei Quellen sind aber Herstellerpapiere, und keine misst Latenz oder Kosten. Genau das braucht, wer einen Reranker einbauen will.

Transparenz: Niemand hat diese Messung bezahlt oder gesponsert, alle Kosten haben wir selbst getragen. Typesense und Embeddings von Voyage setzen wir in einem Kundenprojekt ein. Der Messplan stand fest, bevor die erste Zahl gemessen war; er ist mit einem Zeitstempel belegt (PLAN.md, Zeitstempel). Jede spätere Abweichung steht mit Begründung in DEVIATIONS.md, ebenfalls mit Zeitstempel. Dort steht auch eine Korrektur nach der Messung: Die Trainingsdaten von bge-reranker-v2-m3 hatten wir zunächst falsch als unbekannt eingetragen.

Was ein Reranker bringt

Reranker im Vergleich

Grundlage ist eine Fassung von MIRACL-de mit 71.277 Passagen, die besonders viele schwer unterscheidbare Treffer enthält. Genau die muss ein Reranker auseinanderhalten. Alle Reranker sortieren dieselben 100 Kandidaten der ersten Stufe neu. Die Qualität messen wir als nDCG@10: ein Wert von 0 bis 1, der umso höher ist, je weiter oben die passenden Passagen unter den ersten zehn stehen. Ein Punkt ist 0,01 davon.

Alle neun Reranker machen die Hybrid-Suche deutlich besser. Die besten liegen aber dicht beieinander: Voyage rerank-3 und jina-reranker-v3.5 sind gegen das beste Modell gleichauf, bge-reranker-v2-m3 liegt 1,9 Punkte dahinter. Einen Sieger gibt es nach unserer vorab festgelegten Regel nicht. Vorn steht meist Qwen3-Reranker-4B. MIRACL gehört laut MTEB-Registry aber zu seinen Trainingsdaten, ebenso bei bge-reranker-v2-m3, Qwen3-Reranker-0.6B und Querit-4B (in den Tabellen mit † markiert). Ihre Werte lesen wir deshalb mit Vorsicht.

Für die Praxis heißt das: Lizenz, Latenz und Preis entscheiden mehr als die Qualität. jina-reranker-v3.5 ist gut, im Betrieb aber kostenpflichtig (Lizenz CC BY-NC 4.0). bge-reranker-v2-m3 ist offen und kommerziell nutzbar. Voyage rerank-3 gibt es nur als API.

Die erste Stufe entscheidet

Ein Reranker kann nur neu sortieren, was die erste Stufe gefunden hat. Wie viel er höchstens herausholen kann, zeigt die Obergrenze: der Wert einer perfekten Sortierung der ersten 100 Treffer.

Nach der Stichwortsuche liegt diese Obergrenze bei nur 0,264, weil 24 % der relevanten Passagen unter den ersten 100 waren. Die Reranker holen mit bis zu 0,219 das meiste davon heraus. Wer mehr will, muss die erste Stufe verbessern. Drei Befunde zu Typesense sind dabei wichtig:

• Die Standardeinstellungen taugen für deutsche Fragen nicht. Mit den Standardeinstellungen lag die Stichwortsuche bei 0,012: ohne deutsche Sprache, Wortstämme und Stoppwörter, dazu mit den Standardwerten für die Präfixsuche und für drop_tokens_threshold (1 statt 100). Bei 287 von 305 Fragen kamen weniger als 100 Treffer zurück, mit unseren Einstellungen nur bei 3. Mit deutschen Einstellungen waren es 6,2 Punkte mehr. Welche Einstellung wie viel beiträgt, haben wir nicht getrennt gemessen (DEVIATIONS.md).
• Typesense lässt bei langen Fragen Wörter weg, und zwar von hinten. Findet es weniger Treffer, als drop_tokens_threshold verlangt (Standard 1, bei uns 100), streicht es so lange Wörter vom Ende der Frage, bis es genug Treffer gibt. Deutsche Fragen beginnen aber mit „Wann“, „Wer“ oder „Warum“. Diese Fragewörter bleiben, die Inhaltswörter fallen weg. Lässt man die Wörter von vorn weg (drop_tokens_mode=left_to_right), steigt die Qualität um 4,8 Punkte. Diesen Versuch haben wir nach der ersten Messung ergänzt; er ist entsprechend gekennzeichnet. Zum Vergleich: Ein unabhängiges BM25 erreicht auf denselben Daten 0,232 (DEVIATIONS.md). Die Stichwortsuche von Typesense ist kein BM25 und liegt bei Fragen deutlich darunter.
• Bei der Hybrid-Suche von Typesense bestimmt die Stichwortliste die Reihenfolge. Typesense verrechnet nicht die Werte, sondern die Ränge beider Listen, und gibt der Stichwortliste mit α = 0,3 (dem Standard) 70 % des Gewichts. Die Stichwortliste hat zudem viele Gleichstände. Im Mittel stammten 94,2 der 100 Hybrid-Treffer aus den ersten 100 der Stichwortsuche und nur 16,4 aus denen der Vektorsuche (Auswertung in DEVIATIONS.md). Die Vektorsuche hebt also einzelne Treffer an, und das bringt etwas: Die Hybrid-Suche lag mit 0,175 über der Stichwortsuche mit 0,074. α lässt sich einstellen; andere Werte haben wir nicht gemessen. Seit Version 28 kann Typesense mit der Option rerank_hybrid_matches für jeden Treffer beide Werte berechnen; diese Option haben wir nicht gemessen. Die reine Vektorsuche lag in unserer Messung weit vorn, mit 97 % der relevanten Passagen unter den ersten 100. Diesen Abstand nehmen wir aber nicht für bare Münze: Das Embedding-Modell der Vektorsuche (Arctic) hat MIRACL in den Trainingsdaten. Belastbar ist der Mechanismus, nicht die Höhe des Abstands.

Diese Befunde gelten für Fragen in ganzen Sätzen. Bei kurzen Suchbegriffen dürfte das Weglassen von Wörtern weniger ins Gewicht fallen; gemessen haben wir das nicht.

Wie viele Kandidaten?

Neu sortiert haben wir die ersten 20, 50 und 100 Kandidaten.

Nach einer schwachen ersten Stufe lohnen sich 100 Kandidaten: Nach der Hybrid-Suche stieg Voyage rerank-3 von 0,322 bei 20 auf 0,379 bei 100 Kandidaten. Nach einer guten Vektorsuche reichen 20, mehr bringt dort kaum noch etwas: bge-reranker-v2-m3 kam auf 0,631 mit 20 und 0,638 mit 100 Kandidaten. Einen eigenen Signifikanztest für die Zahl der Kandidaten haben wir nicht gerechnet.

Stichwortsuche im vollen Korpus. Die Fassung mit 71.277 Passagen schont die Stichwortsuche, weil sie viele störende Passagen gar nicht enthält. Deshalb haben wir die Stichwortsuche zusätzlich im vollen Korpus mit 15.866.222 Passagen gemessen. Diese Zahlen stehen getrennt, sie sind mit denen oben nicht direkt vergleichbar.

Auch hier bringen alle gemessenen Reranker deutlich mehr, von 0,061 auf bis zu 0,161. Auf niedrigem Niveau, denn die erste Stufe begrenzt alles.

Wie schnell

Gemessen haben wir die Zeit für eine Anfrage, also Frage und k Passagen hinein und die Werte heraus, einzeln wie im Betrieb. Die Modelle liefen mit dem Standardcode von Hugging Face (PyTorch), ohne Inferenz-Server, ONNX oder Quantisierung. Optimierte Laufzeiten können schneller sein.

Für die Einordnung zwei Budgets, die wir vorab festgelegt haben: Eine Live-Suche sollte insgesamt in 500 ms antworten. Davon brauchte die Hybrid-Suche auf der Fassung mit 71.277 Passagen samt Fragevektor bereits bis zu 67 ms. Im vollen Korpus brauchte in unserem Aufbau schon die Stichwortsuche allein bis zu 765 ms, mehr als das ganze Budget. In einem Chat darf der Reranker bis zu 2 s brauchen. Gemessen wird jeweils das 95. Perzentil, also die Zeit, die 95 von 100 Anfragen einhalten.

Für eine Live-Suche mit 20 Kandidaten sind auf der GPU nur gte-multilingual-reranker-base, bge-reranker-v2-m3 und jina-reranker-v3.5 (im Betrieb kostenpflichtig) schnell genug. Schon Qwen3-Reranker-0.6B braucht bei 95 von 100 Anfragen bis zu 693 ms, die größeren Modelle noch länger. Auch bei der API von Voyage wächst die Zeit mit der Zahl der Kandidaten: Abends lag rerank-3 mit 100 Kandidaten bei 505 ms (95. Perzentil) und damit allein über dem Budget. Gemessen haben wir die API vom Desktop in Schweden aus, in drei Läufen am Samstagabend, Sonntagmorgen und Sonntagmittag, also nur an einem Wochenende.

Ohne GPU ist es in unserem Aufbau zu langsam. Als Richtwert haben wir vier Modelle auf einem AMD Ryzen 9 5950X 16-Core Processor mit 8 Threads gemessen, mit PyTorch in voller Genauigkeit (fp32) und ohne Quantisierung, an 10 Anfragen. Mit 20 Kandidaten dauerte eine Anfrage im Schnitt 4,2 s (gte-multilingual-reranker-base), 10,0 s (bge-reranker-v2-m3), 19,3 s (jina-reranker-v3.5) und 44,1 s (Qwen3-Reranker-0.6B). Mit 100 Kandidaten waren es 28,3 s, 61,4 s und 188,6 s. Qwen3-Reranker-0.6B lief bei 100 Kandidaten, mit allen 100 Paaren in einem Durchgang, nicht in 30 GB Arbeitsspeicher. Das ist weit über jedem Budget. Eine Quantisierung, etwa mit OpenVINO, macht Modelle auf dem Prozessor schneller; gemessen haben wir das nicht. Wer keine GPU hat, nimmt eine API.

Was es kostet

Die API rechnet nach Tokens ab, also nach der Textmenge: Die Frage zählt für jede Passage erneut mit, dazu kommen die Passagen selbst. Die ersten 200 Millionen Tokens je Modell sind frei (Preise von Voyage); in den Tabellen ist das nicht abgezogen.

Ein eigener GPU-Server kostet dagegen einen festen Monatspreis. Wir haben mit einem GPU-Server GEX45 von Hetzner gerechnet. Die Latenz haben wir auf einer RTX 5070 Ti gemessen, nicht auf diesem Server. Dessen GPU, eine RTX PRO 4000 Blackwell SFF, ist auf 70 W begrenzt und hat etwa die halbe Speicherbandbreite (Datenblatt); die RTX 5070 Ti ist für bis zu 300 W ausgelegt. Auf dem Server dürften die Zeiten deshalb länger und die Kapazitäten kleiner sein; die Angaben in der Tabelle sind eher zu günstig. Die Kapazität setzt außerdem gleichmäßige Last rund um die Uhr voraus, ohne Spitzen.

Unterhalb der folgenden Schwellen ist die API günstiger, und dort dürften die meisten Wissensdatenbanken liegen; das ist unsere Einschätzung, Anfragezahlen haben wir nicht erhoben. Mit 100 Kandidaten lohnt sich der eigene Server gegen Voyage rerank-3 erst ab 224.451 Anfragen im Monat, gegen die günstigere Variante ab 561.127. Mit 20 Kandidaten sind es 1.128.984. Dazu kommt die einmalige Einrichtung von 209 €.

Was der Reranker im Chat spart. In einem RAG-Chat bekommt das Sprachmodell die besten Passagen als Kontext. Ohne Reranker braucht es viel mehr Passagen, um dieselbe Trefferquote im Kontext zu erreichen. Jede Passage kostet Tokens.

Mit einem Modell der Preisklasse von Claude Sonnet spart der Reranker damit ein Vielfaches seiner eigenen Kosten. Mit einem günstigen Modell wie DeepSeek Flash ist die Rechnung knapper: Nach der Stichwortsuche lohnt sich auch rerank-3 (1,54 € gegen 0,97 €). Nach der Hybrid-Suche lohnt sich zur Nebenzeit nur rerank-3-lite (0,52 € gegen 0,38 €); rerank-3 kostet 0,95 €. Zur Hauptzeit von DeepSeek (Hinweis unter der Tabelle) verdoppelt sich die Ersparnis auf 1,04 €, dann lohnt sich auch rerank-3. Gerechnet über den Recall statt über Hit@5 fällt die Ersparnis nach der Hybrid-Suche ebenfalls höher aus (0,88 €). Nach einer guten Vektorsuche spart er höchstens etwa so viel, wie er kostet: selbst mit einem Modell der Sonnet-Klasse nur 0,89 €, mit DeepSeek Flash 0,07 €, bei 0,78 € Kosten je 1.000 Anfragen mit 100 Kandidaten. Wichtig: Die Rechnung zählt nur Passagen und Tokens. Ob das Sprachmodell mit dem kleineren Kontext besser antwortet, haben wir hier nicht gemessen.

Datenschutz

Voyage ist ein Anbieter aus den USA. Wer Fragen und Dokumente dorthin schickt, überträgt sie in ein Drittland. Eine Verarbeitung in Europa bietet MongoDB, der Eigentümer von Voyage, über seine Embedding- und Reranking-API in Atlas an: allgemein verfügbar seit dem 29. September 2026, mit 10 % Aufpreis (Ankündigung). Welche Modelle dazugehören, nennt die Ankündigung nicht; vor einem Einsatz sollte man das für rerank-3 bestätigen lassen. Voyage darf Kundendaten zum Training nutzen, außer man widerspricht (Opt-out). Das setzt eine hinterlegte Zahlungsart und die Admin-Rolle voraus; danach werden die Daten laut Voyage nicht gespeichert. Das Opt-out haben wir für unser Konto während der Messung gesetzt; bestätigt war es erst ab dem letzten der drei Latenzläufe, die Qualitätsläufe davor liefen ohne bestätigtes Opt-out. Die Messdaten sind ohnehin öffentlich.

Ein eigener Server behält die Daten im Haus. Das ist der eigentliche Grund für einen eigenen Reranker, nicht der Preis. Eine Rechtsberatung ersetzt dieser Abschnitt nicht.

Fallen beim Einbinden

Ein Reranker ist schnell eingebunden, aber auch schnell falsch. Wie viel das kostet, haben wir an Qwen3-Reranker-0.6B nachgestellt.

• Auffüllen auf der falschen Seite. Das Modell erwartet kürzere Eingaben links aufgefüllt. Rechts aufgefüllt ändert sich die Qualität um −22,9 Punkte, ohne jede Fehlermeldung.
• Am falschen Ende gekürzt. Wird die ganze Eingabe am Ende abgeschnitten statt nur die Passage, fehlt dem Modell das Ende der Vorlage, nach dem es mit „yes“ oder „no“ antwortet: −16,0 Punkte.
• Ohne die Anweisung aus der Modellkarte war das Modell in unserer Messung +1,04 Punkte messbar besser. Das ist ein Befund, keine Empfehlung gegen die Modellkarte; auf anderen Daten kann es anders aussehen.
• mxbai-rerank-large-v2 über sentence-transformers bekommt andere Tokens als über das Paket des Herstellers. Die Rangfolgen weichen ab (Spearman 0,965 bis 0,992 je Frage auf drei Testfragen, unter unserer Schwelle von 0,99 für gleiche Rangfolgen), die Werte um bis zu 1,31 Logits (DEVIATIONS.md). Wir haben das Eingabeformat des Herstellers verwendet.
• Stoppwörter in Typesense greifen über ihren Wortstamm nur, solange Typesense keine Wörter weglässt. Danach bleiben Formen wie „wurde“ in der Suche. Wer Stoppwörter pflegt, sollte das mit echten Fragen prüfen (Diagnose in DEVIATIONS.md).

Grenzen der Messung

• Nur Wikipedia, 305 Fragen. MIRACL-de besteht aus Fragen zu Wikipedia-Passagen. Fachtexte, Handbücher oder Produktdaten können anders ausfallen.
• Zwei Korpusfassungen. Die meisten Zahlen stammen aus der Fassung mit 71.277 Passagen. Sie schont die erste Stufe; die Stichwortsuche im vollen Korpus steht deshalb getrennt.
• Lücken in den Urteilen. MIRACL hat nur einen Teil der Passagen von Menschen bewerten lassen. Eine unbewertete Passage zählt als falsch, auch wenn sie die Frage beantwortet. Unter den ersten zehn Treffern der Hybrid-Suche waren nur 13 % bewertet, nach dem Reranker (Voyage rerank-3) 22 %. Wertet man nur die bewerteten Passagen aus, steigt nDCG@10 nach der Hybrid-Suche lediglich von 0,387 auf 0,436; diese Auswertung bevorzugt allerdings Listen mit vielen unbewerteten Passagen. Wie viel ein Reranker genau bringt, ist deshalb eine Größenordnung, kein genauer Wert; belastbar ist die Richtung. Eine Stichprobe von je 15 Passagen hat ein Sprachmodell, kein Mensch, blind bewertet: Es hielt 40 % bis 47 % der unbewerteten Passagen auf den ersten drei Plätzen nach der Hybrid-Suche für relevant, bei so wenigen Passagen ein sehr unsicherer Wert. Auf den Kontrollpaaren stimmte es in 13 von 15 Fällen mit den menschlichen Urteilen überein, und es wich nur in eine Richtung ab: 2 von 7 Passagen, die Menschen als nicht relevant bewertet hatten, hielt es für relevant. Ein Sprachmodell könnte Passagen bevorzugen, die auch Reranker auf Basis von Sprachmodellen vorne sehen. Alle Trefferquoten sind deshalb Untergrenzen („mindestens“).
• Trainingsdaten. Laut MTEB-Registry gehört MIRACL zu den Trainingsdaten von bge-reranker-v2-m3, Qwen3-Reranker, Querit-4B und dem Arctic-Embedding der Vektor- und Hybrid-Suche. Bei bge-reranker-v2-m3 hatten wir das zunächst übersehen und nach der Messung korrigiert (DEVIATIONS.md). Bei gte-multilingual-reranker-base, jina-reranker-v3.5 und Voyage ist es unbekannt; mxbai-rerank-large-v2 nennt kein MIRACL. Deutsch hat in MIRACL keinen Trainingsteil, nur Entwicklungs- und Testdaten; die hier genutzten Urteile des Entwicklungsteils sind aber seit 2022 öffentlich.
• Verwandte Modelle. Arctic baut auf derselben Modelllinie auf wie bge-reranker-v2-m3.
• Hardware und Ort. Die GPU-Zeiten stammen von einer RTX 5070 Ti, nicht vom Server der Kostenrechnung. Die API haben wir aus Schweden und nur an einem Wochenende gemessen. Die CPU-Werte sind ein Richtwert aus wenigen Anfragen.
• Kontext-Rechnung. Sie zählt Passagen und Tokens, nicht die Qualität der Antworten.
• jina-reranker-v3.5 liest alle Kandidaten in einer Eingabe und passte im vollen Korpus mit 100 Kandidaten nicht in 16 GB Grafikspeicher und fehlt dort in den Tabellen.
• Cohere fehlt. Die Vertragsbedingungen von Cohere untersagen den Zugriff „FOR ANY OTHER BENCHMARKING OR COMPETITIVE PURPOSES“ (Cohere SaaS Agreement, Stand 8. April 2025).
• Produktsuche. Kurze Suchbegriffe im Shop messen wir in einem eigenen Artikel mit einem eigenen Testset.

Fazit je Lage

Sie haben nur eine Stichwortsuche. Stellen Sie sie zuerst auf Deutsch ein: Sprache, Wortstämme und Stoppwörter, und setzen Sie drop_tokens_threshold mindestens auf die Zahl der Kandidaten, die der Reranker bekommen soll. Prüfen Sie auch, welche Wörter die Suche bei langen Fragen weglässt; in unserem Zusatzversuch half es, sie von vorn wegzulassen. Das ist die Voraussetzung: Mit den Standardeinstellungen käme selbst ein perfekter Reranker nicht über 0,016 hinaus. Danach hat ein Reranker mit 100 Kandidaten nDCG@10 in unserer Messung ungefähr verdreifacht (Fassung mit 71.277 Passagen, nach den Urteilen von MIRACL).

Sie planen einen Chat mit Ihren Dokumenten. In unserer Rechnung spart ein Reranker mehr Kontext, als er kostet, solange die erste Stufe keine sehr gute Vektorsuche ist. Mit einem teuren Sprachmodell bezahlt er sich über den kleineren Kontext selbst. Mit einem günstigen wie DeepSeek Flash ist es knapper: Nach der Hybrid-Suche lohnt sich zur Nebenzeit nur rerank-3-lite, zur Hauptzeit auch rerank-3. Ob die Antworten mit dem kleineren Kontext besser werden, haben wir nicht gemessen.

Sie brauchen eine schnelle Live-Suche. Mit 20 Kandidaten passen eine API oder auf einer GPU bge-reranker-v2-m3 bzw. gte-multilingual-reranker-base ins Budget; auf der GPU schaffte bge-reranker-v2-m3 auch 50 Kandidaten und gte-multilingual-reranker-base sogar 100. Die Reranker auf Basis von Sprachmodellen (Qwen3, Querit, mxbai) sind dafür zu langsam, auch das kleine Qwen3-Reranker-0.6B: Es kommt auf die Bauart an, nicht allein auf die Größe. Die GPU-Zeiten gelten für unsere Karte, nicht für einen Server (Abschnitt „Was es kostet“).

Sie haben keinen GPU-Server. Nehmen Sie eine API. Auf einem Prozessor dauerte eine Anfrage in unserem Aufbau (PyTorch, ohne Quantisierung) Sekunden bis Minuten.

Ihre Daten dürfen das Haus nicht verlassen. Ein eigener GPU-Server mit bge-reranker-v2-m3 ist kommerziell nutzbar und lag nur wenige Punkte hinter den besten Modellen; MIRACL gehört allerdings zu seinen Trainingsdaten, auf Ihren Daten kann der Abstand anders ausfallen. Unterhalb der Gewinnschwelle kostet er mehr als die API, aber die Daten bleiben bei Ihnen.

Sie haben schon eine gute Vektorsuche. Ein Reranker bringt noch einige Punkte; sieben von neun Modellen waren deutlich besser als die Vektorsuche allein. Prüfen Sie, ob diese Punkte die zusätzliche Zeit wert sind. Auch unsere Vektorsuche hatte MIRACL in den Trainingsdaten.