Multimodale Embeddings jenseits eines einzelnen Vektors

Seit der Veröffentlichung von pplx-embed-v1 im Februar arbeiten wir an einer neuen Generation von Embedding-Modellen. In der vergangenen Woche haben wir unser neues Kontext-Embedding-Modell pplx-embed-v2-context vorgestellt. Heute erweitern wir die Familie um pplx-embed-v2-late, eine Sammlung von Late-Interaction-Modellen. Neben stärkeren Retrieval-Fähigkeiten kombinieren die Modelle erstmals drei zentrale Eigenschaften:

• Multivektor-Repräsentationen. Anstatt jede Eingabe auf einen einzelnen Vektor zu komprimieren, behalten diese Modelle Vektoren auf Token-Ebene für feiner granulierte Abfragen-Dokument-Vergleiche bei. Dadurch können verschiedene Teile einer Abfrage mit verschiedenen Teilen eines Dokuments übereinstimmen, wodurch Details erhalten bleiben, die besonders wertvoll für multimodales Retrieval sind.
• Unterstützung für Text- und Bildmodalitäten. Zusätzlich zu den Text-zu-Text-Retrieval-Fähigkeiten unserer bisherigen Modelle unterstützen diese neuen Modelle Text-zu-Bild-Retrieval und können damit gerenderte PDF-Seiten direkt durchsuchen, ohne OCR oder geparsten Text zu benötigen.
• Ein gemeinsamer Einbettungsraum. Wir veröffentlichen zwei Modellgrößen, 0,6B und 9B, um unterschiedliche Anforderungen an Qualität, Latenz und Rechenleistung zu unterstützen. Jede kann unabhängig verwendet werden, aber der gemeinsame Einbettungsraum ermöglicht es auch dem kleineren Modell, einen mit dem größeren Modell erstellten Index abzufragen, wodurch hochwertigere Dokumenten-Embeddings mit günstiger, schneller Inferenz zur Anfragezeit kombiniert werden.

Diese neuen Modelle erzielen Spitzenergebnisse in einer Reihe von Benchmarks für Bild- und Text-Retrieval sowie bei agentischen Frage-Antwort-Aufgaben. Bemerkenswert ist, dass unser 0,6B-Modell auf ViDoRe (V3), einem führenden Benchmark für visuelles Dokument-Retrieval, mit Modellen gleichzieht, die fünfmal so viele aktive Parameter haben. Beide Modelle sind öffentlich auf Hugging Face verfügbar. Unser technischer Bericht enthält weitere Details zur Methodik und zu den Evaluationsergebnissen.

Von Einzelvektoren zu Late Interaction

Retrieval-Systeme müssen ein Gleichgewicht zwischen Effizienz und der Tiefe der Interaktion zwischen Abfragen und Dokumenten finden. Dichte Embedding-Modelle kodieren jede Abfrage und jedes Dokument unabhängig voneinander, sodass sie mit einem günstigen inneren Produkt verglichen werden können. Dadurch wird eine Approximate-Nearest-Neighbor-(ANN-)Suche über Milliarden von Dokumenten praktikabel. Am anderen Ende des Spektrums verarbeiten Cross-Encoder Abfrage und Dokument gemeinsam, was reichhaltigere Interaktionen ermöglicht, aber einen separaten Forward Pass für jeden Kandidaten erfordert. Diese Berechnung für jedes Suchergebnis über einen großen Dokumentenkorpus hinweg anzuwenden ist unerschwinglich teuer, weshalb Cross-Encoder typischerweise dem Re-Ranking einer kleinen Menge abgerufener Kandidaten vorbehalten sind.

Grenzen dichter Embeddings

Ein ganzes Dokument mit einem einzigen Vektor fester Größe darzustellen, erzeugt einen Informationsengpass. Wenn Dokumente länger werden und mehr Themen abdecken, muss das Modell mehr Inhalt in denselben Vektor komprimieren, wodurch es schwieriger wird, alles für eine Abfrage Relevante zu bewahren. Chunking kann diesen Druck mindern, zerlegt das Dokument jedoch und kann Informationen voneinander trennen, die nur zusammen Sinn ergeben – ein Problem, dem wir auch mit unserem Kontext-Embedding-Modell begegnen. Dieser Engpass verschärft sich in multimodalen Szenarien, in denen die Informationsdichte von Bildern noch stärkere Kompression erfordert.

Auch das dichte Retrieval mit Einzelvektoren reduziert jeden Vergleich auf ein inneres Produkt zwischen zwei Vektoren und begrenzt damit die Ausdrucksstärke der Scoring-Funktion. Bei einer festen Einbettungsdimension und einem ausreichend großen Korpus sind einige Muster von Scores über Abfragen-Dokument-Paare hinweg unabhängig vom Training unmöglich zu erzeugen. Der LIMIT-Benchmark macht diese theoretische Sorge zu einem konkreten Stresstest für Einzelvektor-Retrieval.

Late-Interaction-Retrieval

Late-Interaction-Modelle besetzen den Raum zwischen den günstigeren dichten Embedding-Modellen und den ausdrucksstärkeren Cross-Encodern. Wie dichte Modelle kodieren sie Dokumente unabhängig von der Abfrage, sodass Dokumentrepräsentationen offline berechnet werden können. Allerdings reduzieren sie jede Eingabe nicht auf einen einzelnen Vektor, sondern behalten mehrere Vektoren bei und verwenden beim Vergleich einer Abfrage mit einem Dokument eine reichhaltigere Scoring-Funktion.

Unsere pplx-embed-v2-late-Modelle verwenden eine Architektur im ColBERT-Stil und geben für jedes Token der Eingabe 128-dimensionale Embeddings aus. Wir bewerten Abfrage-Dokument-Paare mit MaxSim; für jedes Abfrage-Token wählt das Modell das am höchsten bewertete Dokument-Token aus und summiert die tokenweisen Maximalähnlichkeiten, um den Endscore zu erzeugen. So können verschiedene Teile einer Abfrage mit verschiedenen Teilen eines Dokuments übereinstimmen, wobei stärkere Token-Matches stärker zum Score beitragen.

Vergrößern

Diese zusätzliche Ausdrucksstärke geht mit höheren Speicher- und Kandidatenbewertungskosten einher. Dichtes Retrieval speichert einen Vektor pro Dokument und bewertet einen Kandidaten mit einem einzigen inneren Produkt; Late Interaction speichert Vektoren für Dokument-Tokens und berechnet viele Token-zu-Token-Ähnlichkeiten. Die Kosten wachsen mit der Dokumentlänge, sodass Late Interaction einen anderen Kompromiss bei Indexierung und Auslieferung erfordert als ANN-Retrieval mit einem Vektor. Im Gegenzug bietet es reichhaltigeres Retrieval in der ersten Stufe für qualitätssensitive Korpora und kann außerdem als spätere Stufe in einer größeren Retrieval-Pipeline im Web-Maßstab dienen.

Ein Modell, mehrere Modalitäten

Diese verbesserte Tiefe der Interaktion hat sich bei verschiedenen Aufgaben als sehr nützlich erwiesen, darunter Retrieval mit langem Kontext, agentisches Retrieval und Retrieval außerhalb der Domäne. Dieser Unterschied wird im multimodalen Retrieval besonders deutlich, wie der große Vorsprung der ColPali-Modelle auf der Rangliste von ViDoRe(V3) zeigt.

Reale Korpora bestehen nicht nur aus sauberem Text. Sie liegen als PDFs, Präsentationsfolien, Screenshots, gescannte Seiten, Diagramme und Tabellen vor. Die konventionelle Pipeline parst diese Dokumente, wendet OCR oder Bildbeschriftung an und durchsucht den resultierenden Text, was teuer und verlustbehaftet ist: Sie kann OCR-Fehler einführen und Layout, Tabellenstruktur, Abbildungen und räumliche Beziehungen verwerfen. Die visuelle Dokumentensuche überspringt diesen Schritt und projiziert die gerenderte Seite direkt in den Repräsentationsraum, in dem textuelle Abfragen sie durchsuchen können.

Unsere neue Modellfamilie baut auf der starken Leistung von Multivektor-Modellen für multimodale Suche auf und verschiebt die Pareto-Front für kleine Modelle auf dem am weitesten verbreiteten Benchmark für Dokumentsuche, ViDoRe(V3). Obwohl wir erwarten, dass Dokument-Renderings die häufigste Form visueller Eingaben sein werden, unterstützen unsere Modelle auch semantische Bildsuche über natürliche Bilder, etwa Landschaftsfotografien.

Training einer Familie interoperabler Modelle

Suche ist grundsätzlich asymmetrisch: Indexierung und Abfragekodierung haben unterschiedliche betriebliche Anforderungen. Indexierung läuft offline und kann parallelisiert werden, sodass ihre Rechenkosten über viele zukünftige Suchen amortisiert werden. Abfragekodierung läuft online für jede Anfrage und ist daher latenzsensitiv und gelegentlich durch Serving- oder Edge-Device-Limits eingeschränkt. Unsere Modellfamilie nutzt diese Asymmetrie aus und bietet Größen, die auf beide Seiten der Retrieval-Pipeline zugeschnitten sind.

Wir trainieren zunächst einen 18B-Lehrer kontrastiv und destillieren ihn dann separat in 9B- und 0,6B-Schüler. Anstatt jeden Schüler nur darauf zu trainieren, die Ranking-Verteilung des Lehrers zu reproduzieren, verwenden wir eine representation distillation im Stil von LEAF: Für jedes Eingabe-Token gleichen wir das Ausgabe-Embedding des Schülers mit dem des Lehrers ab. Während Distillation im Repräsentationsraum zuvor für dichte Einzelvektor-Modelle verwendet wurde, erweitern wir sie auf Late Interaction, wo das Abgleichsziel ein Vektor für jedes beibehaltene Token ist.

Dadurch teilen beide veröffentlichten Checkpoints denselben multivektoriellen Einbettungsraum. Das ermöglicht Cross-Model-Retrieval und schafft zusätzliche Bereitstellungsoptionen.

• Maximale Qualität: Dokumente und Abfragen mit dem 9B-Modell kodieren.
• Maximale Effizienz: Dokumente und Abfragen mit dem 0,6B-Modell kodieren für 100 % lokale Inferenz
• Retrieval mit niedriger Latenz: den Korpusindex mit dem 9B-Modell aufbauen und dann Live-Abfragen mit dem 0,6B-Modell kodieren, um die Rechenzeit beim Indexieren zu nutzen und gleichzeitig die Abfrage schnell zu halten.
• Lokales-Cloud-Retrieval: private lokale Dokumente oder Live-Abfragen mit dem 0,6B-Modell auf dem Gerät kodieren und diese Repräsentationen mit Ergebnissen aus einem 9B-Index in der Cloud vergleichen oder zusammenführen.

Für latenzsensible Umgebungen haben wir das 0,6B-Modell als leichten Abfrage-Encoder konzipiert, der auch auf Edge-Geräten ausgeführt werden kann. Ausgehend von Qwen3.5-0.8B kürzen wir seinen 24-lagigen Text-Tower auf 12 Lagen und reduzieren diesen Tower von 498 Mio. auf 240 Mio. Nicht-Embedding-Parameter. Das resultierende Modell hat insgesamt 594 Mio. Parameter, doch seine Nenngröße überschätzt die Serving-Kosten: 100 Mio. werden für die Bildkodierung verwendet, und 254 Mio. liegen in der Token-Embedding-Tabelle, was sich kaum auf die Laufzeit auswirkt. Nur etwa 240 Mio. Parameter sind für die Textkodierung und 340 Mio. für die Bildkodierung aktiv, wodurch das Modell die Serving-Kosten eines deutlich kleineren Modells hat und dennoch mit dem 9B-Index kompatibel bleibt.

Wir haben denselben Prozess angewendet, um unseren 18B-Lehrer aus einem 27B-Backbone aufzubauen, was das Destillieren aus dem Lehrer erheblich günstiger machte, ohne das von ihm gelieferte Signal zu schwächen.

Mehrsprachige, multimodale, nicht kontaminierte Trainingsdaten

Wir trainieren beide Modelle mit einem Datensatz aus 186 Millionen Abfrage-Dokument-Paaren, die aus 594 Datensätzen in 46 Sprachen stammen. Von diesen Paaren sind 88,3 % Text-zu-Text-, 8,3 % Text-zu-Bild- und 3,4 % Text-zu-visuelles-Dokument-Paare. Anstatt proportional zur Datensatzgröße zu sampeln, weisen wir jedem Datensatz ein Sampling-Gewicht zu, was zu einer ausgewogeneren Trainingsmischung von 56,5 %, 30,9 % und 12,6 % führt.

Beim Erstellen unserer Trainingsdaten schließen wir alle Datensätze aus, die mit Benchmarks verknüpft sind, auf denen wir evaluieren, um unsere Ergebnisse getreu darzustellen, ohne die Benchmark-Werte künstlich zu erhöhen. Diese Entscheidung bringt den Kompromiss mit sich, dass einige der von uns ausgeschlossenen Datensätze hochwertige Daten enthalten, die die Leistung unseres Modells bei Aufgaben verbessern könnten, die nicht zu dem Benchmark gehören, aus dem sie stammen. Letztlich haben wir uns entschieden, diese Kosten zu akzeptieren: Vertrauenswürdige Zahlen sind für uns während der Entwicklung nützlicher und für Nutzer beim Modellvergleich.

Evaluation

Wir evaluieren beide Modelle über Text-, visuelle Dokumenten-, gemischte Bild- und agentische Retrieval-Aufgaben hinweg. Beide Modelle übertreffen die evaluierten Baselines auf Q2D-Web und BrowseComp+ und erzielen starke Ergebnisse beim visuellen Dokumenten-Retrieval und bei MADQA.

Textretrieval

Wir evaluieren Text-zu-Text-Retrieval anhand von drei Benchmarks:

• Domänenspezifische Benchmarks: Eine Sammlung von 72 MTEB-ähnlichen Aufgaben, 55 über fünf Domänen hinweg (Finanzen, Recht, Gesundheit, Konversation, Technik) sowie 17 sonstige mehrsprachige Aufgaben. Die Sammlung umfasst Aufgaben wie FinQA, AILACasedocs und XLSum. Keiner dieser Datensätze ist in unseren Trainingsdaten enthalten, wie oben beschrieben.
• Q2D-Web: unser Web-Scale-Retrieval-Benchmark mit etwa 70.000 von einem Agenten umformulierten Suchanfragen, die aus produktivem Suchverkehr stammen, über einem Korpus von 190 Mio. Web-Dokumenten. Dieser Benchmark misst Retrieval-Performance in einer Umgebung, die dem realen Web-Retrieval deutlich näher kommt als andere verfügbare Retrieval-Benchmarks, aufgrund seiner produktionsähnlichen Anfragen und des großskaligen Korpus.
• ViDoRe(V3) Markdown: ViDoRe(V3) ist typischerweise eine Text-zu-visuelles-Dokument-Retrieval-Aufgabe, kann aber auch als Textaufgabe bewertet werden, indem eine Version des Korpus verwendet wird, die in Markdown geparst wurde, wodurch wir informationsreiche Dokumentensuche sowohl in Bild- als auch in Textmodalitäten evaluieren können.

Wir messen die Leistung mit nDCG@10, außer bei Q2D-Web, wo wir Recall@1000 berichten, da der Benchmark auf ein Web-Retrieval-Szenario der ersten Stufe ausgerichtet ist. Im gesamten Verlauf unserer Evaluationen vergleichen wir uns mit branchenführenden Embedding-Modellen über verschiedene Größeklassen hinweg. Für Textretrieval stehen nemotron-embed-8b, gemini-embedding-2, voyage-large-4 und qwen3-embed-8b für die stärksten und am weitesten verbreiteten dichten Wettbewerber, während voyage-4-nano und qwen3-embed-0.6b als dichte Baselines mit unter einer Milliarde Parametern dienen. Zusätzlich vergleichen wir mit den kürzlich veröffentlichten Late-Interaction-Modellen topk-embed-v1 von TopK auf den Benchmarks, für die TopK Ergebnisse veröffentlicht hat. Die ViDoRe(V3)-Werte stammen aus deren Model Cards bei 128 Dimensionen und entsprechen damit der Breite unserer Token-Embeddings; der Q2D-Web-Wert stammt von unserer Rangliste.

Bei den domänenspezifischen Benchmarks erreichen unsere 9B- und 0,6B-Modelle im Durchschnitt 81,3 % bzw. 78,0 %. Unser 9B-Modell erzielt den höchsten Wert aller von uns evaluierten Modelle und übertrifft das nächstbeste Modell um 1,6 Prozentpunkte. Unser 0,6B-Modell ist mit den anderen Modellen mit den höchsten Werten konkurrenzfähig und liegt nur 0,3 Prozentpunkte hinter gemini-embedding-2. Wichtig ist: Da wir auf keinen der Daten für diese Benchmark-Aufgaben trainiert haben, zeigen die domänenspezifischen Benchmarks, dass unsere Embedding-Modelle auf neue Domänen generalisieren können.

Vergrößern

Die relative Stärke unseres 0,6B-Modells ist bei der ViDoRe(V3)-Markdown-Aufgabe sogar noch größer; sein Wert von 61,2 % übertrifft alle anderen Modelle außer unserem 9B-Modell, das 64,7 % erreichte. Das nächstbeste externe Modell erreichte 60,6 %, und das nächstbeste Modell mit unter 1B, topk-embed-v1-0.8b, lag 4,3 Prozentpunkte hinter unserem 0,6B-Modell.

Vergrößern

Bei Q2D-Web stammt die Relevanz aus drei Bewertungssätzen: Dokumenten, die der Agent zitiert hat (Citation), Dokumenten, die von unserem produktiven Retrieval-System gerankt wurden (Web), und der Vereinigung beider, erweitert um LLM-Bewertungen nicht gelabelter Dokumente (Combined). Beide pplx-embed-v2-late-Modelle führen alle Baselines in allen drei Bewertungssätzen an. Wir konzentrieren uns auf die kombinierten Bewertungen, da die Citation- und Web-Sätze aus dem abgeleitet sind, was unsere eigenen Systeme bereits angezeigt haben, und daher Modelle begünstigen, die wie diese ranken; die in Combined hinzugefügten LLM-Bewertungen decken Dokumente ab, die keines der beiden Systeme abgerufen hat. In diesem Satz schlagen sowohl unser 9B- als auch unser 0,6B-Modell alle Wettbewerber und erreichen Werte von 74,8 % bzw. 73,6 % gegenüber dem bisherigen Bestwert von 69,3 %.

Vergrößern

Visuelles Retrieval

Unser primärer Benchmark für visuelle Suche ist der öffentliche Standard-Teil von ViDoRe (V3), wobei das Korpus aus gerenderten Seitenbildern statt aus der Markdown-Konvertierung besteht. Wir vergleichen mit zwei führenden dichten Vision-Language-Modellen, qwen3-vl-embed-8b und gemini-embedding-2, sowie mit den Late-Interaction-Modellen topk-embed-v1. Darüber hinaus dienen Tencents EVIE-Modelle und NVIDIAs Nemotron ColEmbed V2-Modelle als "vision-only"-Multivektor-Baselines, die speziell für Bildsuchaufgaben trainiert wurden.

Beide unserer Modelle erreichen eine State-of-the-Art-Performance für Vision-Language-Modelle. Unser 9B-Modell erreicht im Durchschnitt 65,2 % und liegt damit nur hinter EVIE. Unser 0,6B-Modell erreicht einen Wert von 62,3 % und liegt damit vor topk-embed-v1-2b und unter den externen Baselines nur hinter den deutlich größeren EVIE und nemotron-colembed-v2-8b.

Vergrößern

Unser 0,6B-Modell ist insbesondere im Hinblick auf die Modellgröße sehr konkurrenzfähig. Es liegt vor allen vergleichbaren Modellen und ist nur 1,2 Prozentpunkte hinter nemotron-colembed-v2-8b, während es für Bildeingaben nur 340 Mio. Parameter aktiviert. Unsere Modelle erzeugen pro Token Embeddings mit 128 Dimensionen, im Vergleich zu 2.048 bei EVIE-4.5B und 4.096 bei EVIE-8B und nemotron-colembed-v2-8b. Dieser Unterschied bei den Speicheranforderungen kann die Szenarien, in denen sich diese Modelle praktisch einsetzen lassen, drastisch beeinflussen.

Vergrößern

Wir evaluieren außerdem visuelles Retrieval auf MIRACL-Vision, einem Benchmark, dessen Korpus aus Screenshots von Wikipedia-Artikeln besteht, sowie auf PPLX-Q2I, einem internen Benchmark, der sowohl visuelle Dokumente als auch natürliche Bilder abdeckt. PPLX-Q2I wird aus Perplexitys produktiven Bildsuchprotokollen erstellt und ist darauf ausgelegt, die Vielfalt von Anwendungsfällen der Bildsuche abzubilden. Wir verwenden eine Stichprobe von 10.000 Anfragen, stratifiziert nach Sprache und Domäne, gegenüber einem Korpus von 100.000 Bildern; die relevanten Dokumente jeder Anfrage sind die Bilder, die dafür ausgeliefert wurden. Wir haben EVIE-8B oder Nemotron ColEmbed auf PPLX-Q2I nicht evaluiert, da das Indexieren eines Korpus dieser Größe bei ihren standardmäßigen Ausgabe-Dimensionalitäten (2.560 für Nemotron ColEmbed 4B und 4.096 für Nemotron ColEmbed 8B und EVIE-8B) unpraktikabel war.

Ähnlich wie bei seiner Leistung auf ViDoRe(V3) ist unser 0,6B-Modell mit deutlich größeren Modellen konkurrenzfähig und liegt auf MIRACL-Vision nur 1 Prozentpunkt hinter qwen3-vl-embed-8b. Unser 9B-Modell übertrifft alle anderen Modelle außer gemini-embedding-2.

Auf PPLX-Q2I übertreffen beide unserer Modelle qwen3-vl-embedding-8b um mehr als 9 Prozentpunkte, und unser 9B-Modell liegt nur 2 Prozentpunkte hinter gemini-embedding-2. Unsere Ergebnisse bleiben auf Korpora konkurrenzfähig, die sowohl natürliche Bilder als auch visuelle Dokumente enthalten, sodass die Multivektor-Repräsentationen, die sich auf ViDoRe(V3) auszahlen, nicht zulasten der allgemeinen Bildsuche gehen.

Vergrößern

Cross-Model-Retrieval

Die Ergebnisse in den vorherigen Abschnitten bewerten jedes Modell gegen ein Korpus, das es selbst eingebettet hat. Der gemeinsame Einbettungsraum bedeutet, dass dies keine Voraussetzung ist: Ein vom 9B-Modell indiziertes Korpus kann mit vom 0,6B-Modell eingebetteten Abfragen durchsucht werden. Dies ist die Konfiguration, die wir für die meisten produktiven Bereitstellungen erwarten, da das Indexieren einmalig anfällt und über die Lebensdauer des Korpus amortisiert wird, während die Einbettung von Abfragen im latenzkritischen Pfad jeder Anfrage läuft.

Eine Bereitstellung, die das 9B-Modell zur Anfragezeit nicht ausführen kann, würde andernfalls auch mit dem 0,6B-Modell indexieren, sodass diese symmetrische 0,6B-Konfiguration der relevante Vergleichspunkt ist. Wir evaluieren gegen die oben verwendeten 72 domänenspezifischen Benchmarks und beim Bildretrieval von ViDoRe v3. Abfragen werden mit pplx-embed-v2-late-0.6b eingebettet, und wir variieren nur, womit der Korpus eingebettet wurde.

Das Indexieren mit dem 9B-Modell ist eine klare Verbesserung. Bei den domänenspezifischen Benchmarks erzielt die asymmetrische Konfiguration im Durchschnitt einen Gewinn von 1,6 Prozentpunkten. Beim Bildretrieval von ViDoRe v3 erreicht sie 63,5 %, gegenüber 62,3 % mit dem 0,6B-Modell auf beiden Seiten, also einen Gewinn von 1,2 Prozentpunkten. Die Kosten für die Abfragekodierung bleiben zwischen der symmetrischen 0,6B- und der asymmetrischen Konfiguration unverändert, da in beiden Fällen dasselbe 0,6B-Modell die Abfrage kodiert; die zusätzlichen Kosten für die Dokumentenkodierung fallen zur Indexierungszeit an.

Die Verwendung des 9B-Modells auf beiden Seiten bleibt noch besser und erreicht im Durchschnitt 81,3 % bei den domänenspezifischen Benchmarks. Die asymmetrische Konfiguration holt damit bei Text ungefähr die Hälfte des Qualitätsunterschieds zwischen den beiden Modellen auf, ohne zusätzliche Kosten für die Abfragekodierung. Welche Konfiguration zu wählen ist, hängt davon ab, ob das 9B-Modell zur Anfragezeit erschwinglich ist; wo dies nicht der Fall ist, erfasst die asymmetrische Einrichtung einen erheblichen Teil seines Nutzens.

Vergrößern

Agentisches Retrieval

Agentisches Retrieval ist ein weiterer Bereich, in dem Multivektor-Embeddings besonders stark sind. In BrowseComp+ nutzt ein LLM (GPT-OSS-120B in unserem Fall) das Embedding-Modell, um einen Korpus nach Informationen zu einer komplexen Benutzeranfrage zu durchsuchen, und ein zweites LLM beurteilt, ob die resultierende Antwort der Ground Truth entspricht. Unser 9B-Modell erreicht 64,0 % Genauigkeit, übertrifft das nächstbeste ColBERT-Modell um 4,9 Prozentpunkte und das nächstbeste dichte Modell um 8,7 Prozentpunkte, während es weniger Suchen ausführt als jedes andere Modell außer unserem 0,6B. Auch das 0,6B-Modell liegt vor jedem Modell außerhalb unserer Familie.

Vergrößern

MADQA testet agentische Frage-Antwort-Systeme über 800 heterogene reale PDFs mit mehr als 18.000 Seiten hinweg, mit 500 von Menschen verfassten Fragen, die sich nicht aus Allgemeinwissen beantworten lassen. Ein Agent (in unserem Fall Gemini 3.5 Flash) durchsucht die Sammlung mit dem getesteten Retriever und wird hinsichtlich Antwortgenauigkeit und Seiten-F1 gegen die annotierten Evidenzseiten bewertet. Unser 9B-Modell setzt mit 92,4 % Genauigkeit einen neuen State of the Art unter den Retrievern, 3,5 Prozentpunkte vor demselben Agenten mit dem Retriever von Mixedbread; unser 0,6B-Modell erreicht 90,1 %. Außerdem stellen wir fest, dass unser Retriever konkurrenzfähige Ergebnisse gegenüber Mixedbread Agentic Search erzielt, das in seinem Suchsystem einen Such-Sub-Agenten verwendet, der mehrere Suchen pro Aufruf des Haupt-Agenten plant und ausführt (93,4 %, innerhalb unseres Konfidenzintervalls).

Vergrößern

Erste Schritte

Sowohl unsere 0,6B- als auch unsere 9B-Modelle sind auf Hugging Face verfügbar und funktionieren out of the box mit sentence-transformers >= 6.0.0 und transformers >= 5.4.0. Weitere technische Details und vollständige Evaluationsergebnisse werden später in diesem Jahr in einem technischen Bericht veröffentlicht.

Wir trainieren derzeit die nächste Generation unserer Dense-Embedding-Modelle und werden auf der Perplexity API Platform schrittweise Unterstützung für Late-Interaction-, Dense- und kontextuelle Embeddings einführen.

Zitieren

@online{perplexity2026MultimodalEmbeddingsBeyondASingleVector,
  author = {{Perplexity} and Markus Krimmel and Louis Milliken and Antoine Chaffin and Sarah Eslami and Ekaterina Glazkova and Maximilian Schall and Bo Wang and Denis Bykov and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Multimodal embeddings beyond a single vector}},
  date = {2026-10-07},
  url = {https://www.perplexity.ai/hub/blog/multimodal-embeddings-beyond-a-single-vector}
}