pplx-embed-v2: 9B für Dokumente, 0.6B für Queries

Die nützliche Asymmetrie

Dokumente ändern sich meist seltener, als Menschen nach ihnen suchen. Ein Suchsystem kann deshalb beim Indexaufbau mehr Rechenleistung einsetzen und jede eingehende Anfrage mit weniger Aufwand verarbeiten. Die veröffentlichten Modelle pplx-embed-v2-late-9b und pplx-embed-v2-late-0.6b von Perplexity unterstützen genau diese Aufteilung: Das größere Modell encodiert die Dokumente, ihre Tokenvektoren werden gespeichert, und das kleinere Modell encodiert die Suchanfragen. Der Releasebericht vom 6. Oktober 2026 beschreibt diese Kombination.

Dieser Artikel prüft die öffentlichen Artefakte mit Stand vom 8. Oktober 2026. „9B“ und „0.6B“ bezeichnen im Folgenden immer die beiden Modelle mit Late Interaction. Das ebenfalls in der Collection enthaltene pplx-embed-v2-context-9b-preview ist nicht Gegenstand dieses Vergleichs. Für die Late-Modelle sind Gewichte unter MIT verfügbar; die Implementierung lässt sich über Sentence Transformers nutzen und ist damit auch außerhalb eines gehosteten Dienstes zugänglich.

Was die Encoder tatsächlich ausgeben

Diese Modelle verdichten ein Dokument nicht zu einem einzigen gepoolten Vektor. Sie erzeugen kontextabhängige Tokenvektoren, die nach den beiden Encoder-Durchläufen miteinander verglichen werden. Bei Text bilden Texttokens die durchsuchbare Repräsentation, bei Bildern oder gescannten Dokumentseiten die visuellen Tokens. Ein Bild lässt sich dadurch direkt indexieren. Lesbare Passagen für eine spätere RAG-Antwort zu extrahieren, bleibt eine gesonderte Aufgabe.

Die Releasekonfiguration von 0.6B und die 9B-Konfiguration beschreiben Encoder auf Qwen3.5-Basis mit folgenden exportierten Einstellungen des Textstacks:

Konfiguration	late-0.6b	late-9b
Textschichten	12	32
Breite der Textrepräsentation	1.024	4.096
Schichten mit `linear_attention`	6	24
Schichten mit `full_attention`	6	8
Tokenprojektion	1.024 → 128	4.096 → 128
Bias der Projektion	`false`	`false`
`is_causal`	`false`	`false`
Standardwert für `query_length`	1.024	1.024
Standardwert für `document_length`	4.096	4.096
`query_expansion`	`null`	`null`

Die Schichtzahlen stammen aus den tatsächlichen layer_types-Arrays. Insbesondere wechseln sich im kleinen Modell sechs lineare und sechs Full-Attention-Schichten ab. Würde man die Verteilung aus dem weiterhin vorhandenen Feld full_attention_interval: 4 ableiten, erhielte man eine falsche Anzahl. Die obigen Sequenzgrenzen stehen jeweils in sentence_bert_config.json. Ein höheres Positionslimit in der Backbone-Konfiguration belegt keine entsprechend unterstützte Länge für Retrieval.

Für einen Batch von Texteingaben haben die Hidden States die Form $[B,L,h]$ . Eine gelernte Projektion ohne Bias bildet die letzte Dimension auf 128 ab. Die exportierte Modulfolge lautet Transformer → Dense → MultiVectorMask → Normalize: Die Maske entfernt unerwünschte Positionen, darunter konfigurierte Satzzeichen in Dokumenten, und die Normalisierung wirkt auf die verbleibenden Tokenvektoren. Für eine einzelne Eingabe ist die effektive Ausgabe $[L_{\mathrm{kept}},128]$ . Am Ende findet kein Mean Pooling statt. Belegt wird das durch die 9B-Projektion und die Moduldokumentation von Sentence Transformers.

Für eine verbleibende Zeile $z$ der Hidden States lautet die Ausgabe:

u = zW,\qquad W\in\mathbb{R}^{h\times128},\qquad e = \frac{u}{\lVert u\rVert_2}.

Die Gleichung verwendet Zeilenvektoren; ein linearer PyTorch-Layer speichert die Gewichte in transponierter Form. Die Darstellung mit Einheitsnorm setzt eine von null verschiedene Projektion voraus. Tatsächliche Normalisierungsimplementierungen behandeln sehr kleine Normen numerisch.

MaxSim: Hier treffen die beiden Modelle zusammen

$Q\in\mathbb{R}^{m\times128}$ enthalte die verbleibenden Queryvektoren und $D\in\mathbb{R}^{n\times128}$ die Dokumentvektoren. Die Encoder können zu verschiedenen Zeitpunkten auf unterschiedlichen Rechnern laufen. Für das Scoring genügen ihre Ausgaben.

A = QD^\top\in\mathbb{R}^{m\times n},\qquad S(Q,D)=\sum_{i=1}^{m}\max_{1\le j\le n} A_{ij}.

Jedes Querytoken wählt den am besten passenden Dokumentvektor aus; diese Maxima werden summiert. Bei normalisierten Vektoren ist jedes Skalarprodukt eine Kosinusähnlichkeit. Verschiedene Querytokens dürfen denselben Dokumentvektor auswählen. Es handelt sich also nicht um eine eindeutige Eins-zu-eins-Zuordnung, und der Score ist keine Wahrscheinlichkeit. Die offizielle Scoring-API verwendet standardmäßig diese Summe ohne Normalisierung nach Querylänge.

Für eine beispielhafte Query mit zwei Tokens zur Akkugarantie nehmen wir folgende Ähnlichkeiten mit drei Dokumenttokens an:

A=\begin{bmatrix} 0.90 & 0.10 & 0.20\\ 0.20 & 0.85 & 0.10 \end{bmatrix},\qquad S=0.90+0.85=1.75.

Diese Zahlen sind zur Erklärung der Reduktion erfunden und keine Modellmessungen. Reale Tokenvektoren hängen vom Kontext ab und berücksichtigen Tokenisierung sowie Query-/Dokumentformatierung. Lokale Übereinstimmungen zu behalten, vermeidet die Forderung, dass jeder Aspekt eines langen Dokuments in einem einzigen gepoolten Vektor erhalten bleiben muss. Dieser Architekturvorteil ist unabhängig von der Kombination verschiedener Modellgrößen. Zum Vergleich dienen die Mathematik des Retrievals mit Einzelvektoren und die Architektur von EmbeddingGemma 2.

Warum gleiche Dimensionen nicht ausreichen

Zwei Encoder können jeweils 128 Dimensionen ausgeben und trotzdem inkompatible Koordinaten verwenden. Für eine orthogonale Matrix $R$ bleibt das Skalarprodukt erhalten, wenn beide Seiten gedreht werden. Wird nur eine Seite gedreht, ändert es sich im Allgemeinen:

(Rq)^\top(Rd)=q^\top d,\qquad (Rq)^\top d\ne q^\top d.

Gute Rankings innerhalb zweier getrennt trainierter Embeddingsysteme beweisen deshalb nicht, dass sich ihre Vektoren mischen lassen. Die Koordinatensysteme müssen übereinstimmen, einschließlich der Konventionen für Queries und Dokumente.

Perplexity berichtet, dass beide veröffentlichten Students aus demselben internen 18B-Teacher destilliert wurden. Dabei werden Tokenrepräsentationen abgeglichen, statt allein Rankingverteilungen zu destillieren. Entscheidend ist die Übereinstimmung mit den Koordinaten des Teachers. Die im Release zitierte LEAF-Originalarbeit definiert einen Repräsentationsverlust mit einer nicht quadrierten euklidischen Norm; Perplexity überträgt die Idee auf Tokenrepräsentationen. Ein schematisches Ziel für diesen Abgleich lautet:

\mathcal{L}_{\mathrm{align}}(\theta) =\mathbb{E}_{x}\left[\sum_{i\in I(x)} \left\lVert f_\theta(x)_i-T(x)_i\right\rVert_2\right].

$T$ bezeichnet hier den gemeinsamen Teacher und $I(x)$ die korrespondierenden Tokenpositionen, die für den Abgleich verwendet werden. Das ist eine erklärende Zielfunktion und keine Rekonstruktion des unveröffentlichten Trainingsrezepts: Loss-Gewichte, die genaue Reduktion, die Normalisierung während des Trainings und sämtliche Details der Tokenzuordnung nennt der Release nicht. Für die Architektur folgt daraus, dass der kleine Queryencoder und der große Dokumentencoder denselben Zielraum approximieren. Der Teacher wird beim Training benötigt, nicht beim Betrieb der veröffentlichten Modellkombination.

Wie der Abgleich den Scoringfehler begrenzt

Die folgende Herleitung erklärt den Mechanismus unter ausdrücklichen Annahmen. Sie ist keine gemessene Fehlergarantie für diese Modelle. Wir nehmen normalisierte Vektoren und korrespondierende Query-/Dokumentpositionen an. Sei $q_s$ ein Queryvektor des kleinen Modells, $d_L$ ein Dokumentvektor des großen Modells und seien $q_T,d_T$ die zugehörigen Teacher-Referenzen. Dann gilt:

q_s^\top d_L-q_T^\top d_T =(q_s-q_T)^\top d_L+q_T^\top(d_L-d_T).

\left|q_s^\top d_L-q_T^\top d_T\right| \le\lVert q_s-q_T\rVert_2+\lVert d_L-d_T\rVert_2.

Die zweite Zeile folgt aus Cauchy–Schwarz und den Einheitsnormen. Kleine Koordinatenfehler führen zu kleinen Fehlern im Skalarprodukt. Auch MaxSim bleibt kontrollierbar, wenn sich der gewinnende Dokumentvektor ändert: Das Maximum ist bezüglich des größten elementweisen Fehlers 1-Lipschitz.

\left|\max_j a_j-\max_j b_j\right| \le\max_j|a_j-b_j|.

\varepsilon_i=\lVert q_{s,i}-q_{T,i}\rVert_2,\qquad \delta_j=\lVert d_{L,j}-d_{T,j}\rVert_2,

\left|S(Q_s,D_L)-S(Q_T,D_T)\right| \le\sum_{i=1}^{m}\left(\varepsilon_i+\max_j\delta_j\right).

Für ein Ranking kommt eine weitere Bedingung hinzu. Beträgt der Scorefehler jedes Kandidaten höchstens $E$ , bleibt die Reihenfolge eines Kandidatenpaars erhalten, wenn der Scoreabstand des Teachers größer als $2E$ ist. Bei einem kleineren Abstand sind beide Reihenfolgen möglich. Ein größerer Dokumentencoder verbessert diese Grenze dann, wenn er den Fehler der Dokumentrepräsentationen reduziert. Die Parameterzahl allein beweist das nicht.

Damit lässt sich erklären, warum die gemischte Kombination brauchbare Rankings erhalten kann, ohne exakt dem 9B-Queryencoder zu entsprechen. Zugleich werden die Grenzen deutlich: Kleine Relevanzabstände können ihre Reihenfolge wechseln, Queryfehler bleiben bestehen, und im öffentlichen Release fehlen die Tokenfehlerwerte, die aus dieser Grenze eine numerische Garantie machen würden. Ausgabevektoren und Retrievalrankings zu vergleichen, ist deshalb aussagekräftiger, als lediglich gleiche Dimensionen festzustellen.

Was tatsächlich gemessen wurde

Der Release nennt folgende Messungen des Herstellers; sie sind keine unabhängige Reproduktion. Ein höherer nDCG@10-Wert bedeutet ein besseres Ranking anhand der Relevanzlabels der Evaluation. Er ist kein Prozentsatz korrekt beantworteter Suchanfragen.

Queryencoder / Dokumentencoder	Fachspezifischer Text: nDCG@10	ViDoRe v3 mit Bildern: nDCG@10
0.6B / 0.6B	78,0	62,3
0.6B / 9B	≈79,6*	63,5
9B / 9B	81,3	65,2

Die Textevaluation mittelt sechs Domänengruppen gleichgewichtet über insgesamt 72 Aufgaben. Der gemischte Textwert ergibt sich aus der gerundeten Basis von 78,0 plus der berichteten Verbesserung um 1,6 Punkte. Er ist kein separat veröffentlichter, genauerer Score. Der gemischte Bildwert wird direkt genannt. Diese Ergebnisse stammen aus dem Abschnitt zur asymmetrischen Suche im Releasebericht.

Aus den gerundeten Werten ergibt sich, dass die gemischte Kombination ungefähr $(79.6-78.0)/(81.3-78.0)\approx48\%$ des Textscoreabstands und $(63.5-62.3)/(65.2-62.3)\approx41\%$ des Bildscoreabstands aufholt. Diese Anteile beschreiben die aggregierten Benchmarks. Sie versprechen nicht denselben Gewinn auf einem bestimmten Korpus, und die Ergebnisse belegen keine Überlegenheit für jede einzelne Query. Der Abschnitt enthält keine Konfidenzintervalle oder Messungen der Latenz beim Verarbeiten von Suchanfragen.

Woher die Einsparungen beim Rechenaufwand kommen

$N$ zähle die Dokumentencodierungen einschließlich erneuter Indexierung und $U$ die Suchanfragen. $c_s^d,c_L^d$ seien die durchschnittlichen Kosten der Dokumentencodierung mit kleinem beziehungsweise großem Modell und $c_s^q,c_L^q$ die durchschnittlichen Querykosten. Für denselben Workload gilt:

\begin{aligned} C_{s/s}&=Nc_s^d+Uc_s^q,\\ C_{s/L}&=Nc_L^d+Uc_s^q,\\ C_{L/L}&=Nc_L^d+Uc_L^q. \end{aligned}

C_{L/L}-C_{s/L}=U(c_L^q-c_s^q),\qquad \frac{C_{s/L}-C_{s/s}}{U} =\frac{N}{U}(c_L^d-c_s^d).

Verglichen mit 9B auf beiden Seiten spart die Aufteilung bei jeder Suchanfrage die Differenz der Querykosten. Verglichen mit 0.6B auf beiden Seiten entstehen zusätzliche Kosten für die Dokumentencodierung, die sich auf $U$ Suchanfragen verteilen. Ein weitgehend stabiler, häufig durchsuchter Korpus eignet sich daher besonders. Häufig ersetzte Dokumente oder sehr wenige Suchanfragen schwächen diese Amortisation.

Die Gleichungen berücksichtigen nur das Encodieren. Vektorindex, Kandidatensuche, MaxSim, Datentransfers und Netzwerklatenz sind nicht enthalten. Das nominelle Parameterverhältnis $9/0.6=15$ ist kein gemessener Geschwindigkeitsgewinn um Faktor 15. Tokenlängen, Attention-Verteilung, Batchgröße, Präzision, Kernel und Hardware beeinflussen Durchsatz und Latenz.

Aufbau	Praktischer Vorteil	Grenze bei Kosten oder Qualität
Durchgehend 0.6B	Geringere Kosten für Dokumentencodierung und kleinerer Queryencoder	Niedrigere berichtete Retrievalscores
9B für Dokumente, 0.6B für Queries	Höhere berichtete Qualität als durchgehend 0.6B; kleinerer Queryencoder im laufenden Betrieb als durchgehend 9B	Größerer Indexierungsjob; die Kompatibilität des gemeinsamen Vektorraums muss erhalten bleiben
Durchgehend 9B	Höchste berichtete Scores dieser drei Varianten	Größerer Encoder im Pfad jeder Suchanfrage

Die Kombination erlaubt außerdem eine getrennte Kapazitätsplanung: Indexierungsjobs mit dem großen Modell können auf anderer Hardware oder zu anderen Zeiten laufen als der Querydienst. Das folgt aus den unabhängigen Encoder-Durchläufen und ist kein veröffentlichter Infrastrukturbenchmark.

Index und Scoring bleiben aufwendig

Ein kleinerer Queryencoder verkleinert die gespeicherten Dokumentvektoren nicht automatisch. Bei gleicher Anzahl verbleibender Tokens, gleichen Dimensionen und gleicher Speicherpräzision benötigen alle drei Varianten denselben Rohspeicher für die Vektoren. Für $n$ Dokumentvektoren und $b$ Bytes je Skalar gilt:

M_{\mathrm{vectors}}=n\cdot128\cdot b.

Bei 512 verbleibenden Tokens benötigt allein die Speicherung in FP16 $512\cdot128\cdot2=131{,}072$ Bytes, also 128 KiB je Dokument. FP32 verdoppelt diesen Wert. Das sind Rechenbeispiele für den Speicherbedarf der Repräsentation, keine empfohlenen Quantisierungseinstellungen oder gemessenen Indexgrößen. Metadaten, Token-IDs, Indexstrukturen und Replikate kommen hinzu. Bei Bildern hängt die Zahl der visuellen Tokens von Vorverarbeitung und Auflösung ab.

Ein exakter Score für ein Dokument berechnet eine $m\times n$ -Ähnlichkeitsmatrix mit $mn\cdot128$ skalaren Multiplikationen und ähnlich vielen Additionen. Für einen großen Korpus braucht das System deshalb einen Kandidatenindex für mehrere Vektoren je Dokument und eine begrenzte Zahl auszuwertender Kandidaten. Das dichte similarity-Beispiel der Bibliothek ist kein solcher Index. Kandidatenfilterung kann relevante Dokumente aussortieren, bevor MaxSim sie bewertet. Vektorquantisierung bringt eine weitere Fehlerquelle hinzu; siehe Quantisierungsschäden beim Retrieval.

Unterstützte API und Grenze zum produktiven Betrieb

Die Model Cards verlangen sentence-transformers >= 6.0.0 und transformers >= 5.4.0. Mit MultiVectorEncoder, encode_query und encode_document werden die Query-/Dokumentprompts und Module für Tokenvektoren angewendet. Die nativen Module benötigen kein trust_remote_code.

Dieses kleine Textbeispiel trennt die beiden Phasen ausdrücklich. Die erste Funktion gehört in den Indexierungsjob; ihre zurückgegebenen Arrays bilden die Dokumentartefakte für den Querydienst. Die zweite bewertet eine übergebene Kandidatenmenge und keinen vollständigen Produktionskorpus. Die Revisionen fixieren die hier geprüften Artefakte.

python

from sentence_transformers import MultiVectorEncoder
 
DOC_MODEL = "perplexity-ai/pplx-embed-v2-late-9b"
DOC_REV = "77e936a1b18ed2ac00b7c76fccd70dc6a1bb1c18"
QUERY_MODEL = "perplexity-ai/pplx-embed-v2-late-0.6b"
QUERY_REV = "dd4e95b836a73f6f0c32e46ea127c0b86b02169e"
 
 
def build_document_vectors(texts):
    encoder = MultiVectorEncoder(DOC_MODEL, revision=DOC_REV)
    return encoder.encode_document(
        texts, batch_size=1, convert_to_numpy=True
    )
 
 
def score_candidates(queries, document_vectors):
    encoder = MultiVectorEncoder(QUERY_MODEL, revision=QUERY_REV)
    query_vectors = encoder.encode_query(
        queries, convert_to_numpy=True
    )
    return encoder.similarity(query_vectors, document_vectors)

In einem laufenden Dienst wird der Queryencoder einmal initialisiert und weiterverwendet, statt ihn bei jeder Anfrage neu anzulegen. Dokumentarrays müssen zusammen mit IDs und Angaben zu Vorverarbeitung und Revision gespeichert werden. Persistenz und Kandidatenindexierung lässt das Beispiel bewusst aus. Hardwarezuordnung und Encoderpräzision müssen für den tatsächlichen Workload gewählt und geprüft werden.

Die Cards dokumentieren getrennte Batches nur mit Text oder nur mit Bildern; gemischte Text-Bild-Eingaben werden derzeit nicht unterstützt. Die Formatierung setzt [Q] beziehungsweise [D] an die erste Position. Das unterscheidet sich von PyLates üblichem Marker an zweiter Position. Ein generischer Aufruf von SentenceTransformer.encode mit Pooling ist kein Ersatz. Auch eine andere ColBERT-Pipeline ist nicht allein deshalb kompatibel, weil sie 128 Dimensionen ausgibt. Die dokumentierten Standardgrenzen von 1.024 beziehungsweise 4.096 verlangen zudem eine bewusste Strategie zum Aufteilen oder Kürzen längerer Eingaben.

Vor der Entscheidung für die gemischte Kombination sollten alle drei Varianten auf demselben Korpus mit denselben Relevanzurteilen verglichen werden. Vorverarbeitung, Kandidatensuche und Scoring müssen konsistent bleiben. Recall, nDCG, Indexierungsdurchsatz, Latenz der Queryencodierung sowie p50/p95 der Gesamtlatenz sind getrennt zu messen. Nach einem Präzisionswechsel oder einer Vektorquantisierung ist der Vergleich zu wiederholen. Beide Modellrevisionen und die Encoderbibliotheken sollten fixiert werden; nach einem Fine-Tuning einer Seite muss die Kompatibilität der Repräsentationen erneut geprüft werden.

Der belegte Grund für die Aufteilung ist konkret: Dokumentrepräsentationen des großen Modells lassen sich weiterverwenden, während ein kleinerer, darauf abgestimmter Encoder die Queries verarbeitet. Veröffentlichte Messungen zeigen einen Qualitätsgewinn gegenüber dem kleinen Modell allein; zur Variante mit großem Modell auf beiden Seiten bleibt eine Lücke. Ob sich dieser Kompromiss lohnt, hängt von der Wiederverwendung des Korpus, den Rankingabständen, den Indexkosten und der gemessenen Leistung im Betrieb ab.

Primärquellen und geprüfte Revisionen

Die Quellen wurden am 8. Oktober 2026 geprüft. Die mathematischen Grenzen und Kostengleichungen oben sind hergeleitete Erklärungen. Die Benchmarkwerte sind zugeordnete Messungen, und die exportierten Einstellungen sind Fakten aus den Artefakten.

Perplexity-Releasebericht vom 6. Oktober 2026: asymmetrisches Retrieval, Abgleich mit einem gemeinsamen Teacher und Benchmarkbedingungen.
Offizielle pplx-embed-v2-Collection.
Model Card für late-0.6b bei dd4e95b und Dateien des ersten Releases.
Model Card für late-9b bei 77e936a, Backbone-Konfiguration, Tokenprojektion und Sequenzeinstellungen.
LEAF-Originalarbeit, ACL 2026: Repräsentationsabgleich und nicht quadrierte Norm in der Verlustfunktion, Gleichung 3.
Sentence Transformers: MultiVectorEncoder-API, Modulaufbau und MaxSim-Scoring.