Abfragebewusste Kontextkompression für bessere Snippets

Jede Antwort beginnt mit Nachweisen. In einem Suchsystem stammen diese Nachweise üblicherweise aus Dokumenten: Titeln, Zusammenfassungen, Textabschnitten und Snippets, die als Kontext an ein Antwortmodell oder einen Agenten weitergegeben werden.

Dieser Rohkontext ist rauschbehaftet. Beispielsweise kann eine Webseite für die Anfrage des Nutzers notwendige Informationen enthalten, aber auch Ablenkungen. Diese Ablenkungen können sowohl im Haupttext als auch in Nebenelementen wie Navigations-Texten, irrelevanten Anzeigen, Metadaten und mehr auftreten. Die Weitergabe dieser Ablenkungen an einen nachgelagerten Agenten führt zu drei Problemen.

Erstens beeinträchtigt es die Genauigkeit. Selbst die leistungsfähigsten Modelle haben eine begrenzte Kapazität. Lange Ströme irrelevanter Informationen verschwenden Modellkapazität und führen zu einer „Kontext-Degradierung“, die die Fähigkeit des Modells zur Beantwortung der eigentlichen Nutzeranfrage mindert. Infolgedessen ist die endgültige Antwort eher dazu geneigt, wichtige Fakten zu übersehen, minderwertige Informationen überzubewerten oder Behauptungen aufzustellen, die schwerer durch die Quelle zu belegen sind.

Zweitens führt es zu einer Verschlechterung der Latenz. Ein längerer Kontext bedeutet mehr Token, die vom nachgelagerten Modell verarbeitet werden müssen, insbesondere wenn eine Abfrage Nachweise aus vielen potenziellen Seiten benötigt. Obwohl ein Teil dieser Latenzkosten in der Prefill-Phase anfällt, sind die Kosten in der Schlussfolgerung deutlich höher, da Modelle mehr Schlussfolgerungs-Token benötigen, um mit irrelevantem Kontext umzugehen.

Drittens erhöht es die Kosten. Jedes unnötige Token, das an das Modell weitergegeben wird, macht die Beantwortung der Nutzeranfrage teurer, da sowohl die Eingabe-Token als auch die Schlussfolgerungs-Token bei rauschbehafteterem Kontext zunehmen. Ablenkungen mindern nicht nur die Qualität, sondern führen letztlich dazu, dass Sie für diese geringere Qualität mehr bezahlen müssen.

Vergrößern

Um gleichzeitig Genauigkeit, Geschwindigkeit und Kosteneffizienz über die Anwendungen von Perplexity und die API-Plattform hinweg zu steigern, investieren wir intensiv in die Verbesserung der Kontextpräzision. Ein Weg hierfür ist die Verfeinerung unserer Algorithmen zur Snippet-Generierung. Wir betrachten die Snippet-Generierung als ein Problem der Kontextkompression. Modelle, die nach spezifischen Informationen suchen, profitieren nicht von generalisierten Zusammenfassungen oder Auszügen eines Dokuments. Vielmehr benötigen sie den kleinsten, chirurgisch exakt extrahierten Teil der Quellinformation, um auf die Anfrage des Nutzers zu antworten. Alles andere kann und muss entfernt werden.

Ein gutes Snippet sollte daher drei Dinge leisten:

Die Genauigkeit fördern, indem die präzisen Nachweise präsentiert werden, die zur Fundierung der Antwort des Modells erforderlich sind.

Latenz und Kosten reduzieren, indem irrelevanter Kontext vor dem LLM-Aufruf entfernt wird.

Die Rückverfolgbarkeit sicherstellen, indem die Wiedergabetreue der Zitate gewahrt bleibt und der Wortlaut der Quelle intakt bleibt.

Diesen Monat haben wir einen neuen, hochmodernen Snippet-Generator in unseren Anwendungen und der API-Plattform eingesetzt. Der Kern dieses Moduls ist ein abfragebewusstes Kontextkompressionsmodell, das für jede Abfrage und jedes potenzielle Ergebnis entscheidet, welche Teilmenge der Textabschnitte beibehalten werden sollte. Dieser Artikel beschreibt unseren Ansatz zur Entwicklung und zum Training des Modells, um in dieser kritischen Aufgabe eine erstklassige Leistung zu erzielen.

Snippets als abfragebewusste Kompression

Die erste Aufgabe besteht darin, das Problem selbst zu definieren. Was soll dieses Modell tun und wie sollten wir das Eingabe- und Ausgabeschema definieren?

Snippet-Methoden lassen sich in zwei große Familien einteilen. Die erste ist auswahlbasiert: Finden eines relevanten Fensters, Textabschnitts, Satzes oder Passagen, und Weitergabe an nachgelagerte Systeme. Die zweite ist generierungsbasiert: Ein Modell wird gebeten, eine abfragefokussierte Zusammenfassung der Seite zu schreiben.

Unser Fokus auf Genauigkeit, Latenz und Kosten macht die Designentscheidung klar. Wir können die Generierung ausschließen, da die Erstellung einer neuen Zusammenfassung für jede Seite die Leistung in allen drei Schwerpunkten beeinträchtigt. Zusammenfassung ist für die von uns angestrebte Nachweisebene ungeeignet. Sie kann die Quelle paraphrasieren, was die Ausrichtung der Zitate erschwert. Sie kann zudem Wortlaute einführen, die auf der Seite nicht vorhanden waren, was riskant ist, wenn das Snippet als Nachweis und nicht als endgültige Antwort verwendet wird. Die damit verbundene Latenz und die Kosten machen die Generierung noch inakzeptabler.

Stattdessen definieren wir unsere Aufgabe als eine Form der abfragebewussten extraktiven Kompression: Trennung der hilfreichen Teile des abgerufenen Kontexts von den ablenkenden Teilen. Unser Modell muss spezifisch eine Abfrage und ein potenzielles Ergebnis akzeptieren und entscheiden, welche Abschnitte bewahrt werden sollen, nämlich jene, die die Abfrage am besten stützen, und welche verworfen werden sollen, nämlich der Rest. Die Modellausgabe bewahrt den Quelltext, anstatt ihn umzuschreiben. Dies macht das Ergebnis leichter zitierbar, überprüfbar und kostengünstiger in der nachgelagerten Verarbeitung.

Betrachten Sie beispielsweise diese Abfrage und das abgerufene Ergebnis:

Vergrößern

Eine plausible Modellausgabe bestünde darin, den fettgedruckten Satz auszuwählen: „In Comet kann der Assistent ...“.

Unser Ansatz folgt derselben breiten Idee wie frühere Arbeiten zur Kontextkompression wie FliCo, Provence und LooComp, angepasst für die Snippet-Generierung in einem produktiven Suchsystem. Wichtig ist, dass das Modell als Präzisionsstufe nach unserer Rohabrufstufe arbeitet. Wie in unserem vorherigen Perplexity Research-Artikel, Einführung der Perplexity Search API, diskutiert, architekturieren wir unsere Abrufsysteme so, dass sie nativ auf der Ebene unterhalb des Dokuments, also auf Snippet-Ebene, arbeiten, was es uns bereits ermöglicht, Präzision und Recall gut auszubalancieren. Die Einführung eines abfragebewussten Kontextkompressionsmodells verschiebt die Pareto-Grenze zwischen Präzision und Recall noch weiter nach außen.

Entwicklung und Training eines Kontextkompressionsmodells

Wir entwickeln unser Modell unter Berücksichtigung von drei Hauptaspekten: gemeinsames Verständnis von Abfrage und Kontext, fein abgestimmte Auswahl auf Satzebene und Effizienz, um innerhalb eines extrem knappen Latenzbudgets zu bleiben.

Modellarchitektur

Wir verwenden ein pplx-Diffusion-Modell als Rückgrat. Dies ist dieselbe Modellfamilie, die hinter pplx-embed-v1 steht, und sowohl unsere früheren akademischen Arbeiten, Diffusion-Pretrained Dense and Contextual Embeddings, als auch unsere Produktions-Benchmarks bestätigen, dass es sich um einen starken bidirektionalen Encoder für Abfrage-Kontext-Paare handelt. Eine der Schlüsseleigenschaften dieser Modellfamilie ist der bidirektionale Kontext: Jede Token-Repräsentation kann die vollständige Abfrage und den vollständigen Kontext des Kandidaten berücksichtigen, bevor das Modell entscheidet, was beibehalten werden soll.

Auf dieser Grundlage trainieren wir einen leichtgewichtigen Kompressionskopf, der vorhersagt, welche Teile des Kontexts beibehalten werden sollten. Da keine Generierung involviert ist, erfolgen diese Vorhersagen parallel über den gesamten Kontext hinweg. Zum Zeitpunkt der Bereitstellung aggregiert die Snippet-Engine diese Vorhersagen auf Satzebene, wendet einen Schwellenwert an und kürzt das Ergebnis auf das angeforderte Token-Budget.

Supervisions-Pipeline

Das Training dieses Kompressors erfordert eine Supervision mit dem richtigen Granularitätsgrad. Ein Relevanz-Label auf Dokumentenebene ist für unsere extraktive Kompressionsaufgabe völlig ungeeignet. Um ausreichend granulare Daten für das überwachte Lernen zu generieren, haben wir eine Span-Labeling-Pipeline aufgebaut, die abfragerelevante Nachweisabschnitte sowie zu entfernende Distraktor-Abschnitte markiert.

Unsere Pipeline verwendet ein LLM-as-a-judge-Setup. Angesichts einer Nutzerabfrage und einer potenziellen Webseite mit Link, Titel und Zusammenfassung führt der Richter zuerst ein Abfrageverständnis durch, analysiert die Abfrage und erstellt eine Liste möglicher Nutzerabsichten. Basierend auf diesen Absichten verarbeitet der Richter dann den Kontext des Kandidaten und gibt Abschnitte zurück, die wörtlich aus dem Text kopiert wurden, mit einer Kategorie für jeden Abschnitt, um die Labels leichter überprüfbar zu machen.

Wir haben dann die zurückgegebenen Abschnitte mit dem Quelltext abgeglichen. Wenig überraschend waren die meisten Ausgaben des Richters bereits exakte Kopien: naiver String-Abgleich stellte 98 % der Abschnitte wieder her. Das Hinzufügen eines einfachen regex-basierten Abgleichsschritts brachte die Wiederherstellung der Abschnitte auf 100 %. Dies lieferte uns zuverlässige, granulare Abschnitte, die in eine Token-basierte Beibehalten/Verwerfen-Supervision umgewandelt werden konnten.

Wir haben diese Supervisions-Pipeline unter Verwendung eines kleinen, kuratierten Datensatzes mit manuell gelabelten Abschnitten evaluiert und dabei kleinere Richter-Modelle, verschiedene Prompts und unterschiedliche Schrittkonfigurationen verglichen. Das leistungsfähigste Setup war eine zweistufige Pipeline: zuerst Abfrageverständnis, gefolgt von kategorisiertem Span-Labeling. Wir haben die Menge der extrahierten Abschnitte zudem durch nachgelagerte verifizierbare Evaluationen wie BrowseComp und SimpleQA validiert, wobei die Verwendung ausschließlich der beibehaltenen Nachweisabschnitte starke Ergebnisse bewahrte und gleichzeitig die Eingabe-Token signifikant reduzierte.

Unter Verwendung dieser Pipeline haben wir 750.000 Abfrage-Dokument-Paare gelabelt und verwenden die resultierenden Abschnitte, um den Kompressionskopf mit binärer Kreuzentropie zu trainieren. Dieser Prozess ermöglicht es unserem abfragebewussten Kompressionsmodell, den Quelltext intakt zu lassen und gleichzeitig Kontext zu entfernen, der dem nachgelagerten Modell wahrscheinlich nicht bei der Beantwortung der Nutzeranfrage hilft.

Sicherstellung der Echtzeit-Latenz

Kontextkompression befindet sich vor dem nachgelagerten Modell und ist somit ein blockierender Vorgang. Darüber hinaus ist jede Kompression abfrageabhängig. Daher muss der Online-Pfad Abfrage-Kontext-Paare für jedes potenzielle Dokument innerhalb eines strikten Latenzrahmens bewerten. Ein langsames Kompressionsmodell ist kontraproduktiv, da die Latenzvorteile durch höhere Präzision durch die Kompressionslatenz selbst zunichtegemacht werden. Gleichzeitig wird ein weniger intelligentes Kompressionsmodell schlechtere Entscheidungen darüber treffen, was zu kürzen und was beizubehalten ist.

Die praktische Frage ist, wie viel Modellkapazität wir sicher entfernen können, bevor die Kompressionsqualität zu sinken beginnt. Wir vergleichen das vollständige 28-Schichten-pplx-Diffusion-Rückgrat mit 11- und 17-Schichten-Varianten, die durch Schichtenbeschneidung (Layer Pruning) erzeugt und auf den Suchpfad ausgerichtet wurden. Für jede Variante durchlaufen wir den Kompressionsschwellenwert und messen zwei Größen: die durchschnittliche Anzahl der pro Abfrage nachgelagert gesendeten Kontext-Token und den Anteil der nach der Kompression beibehaltenen nützlichen Nachweise.

Abbildung 2 zeigt die Qualitäts-Effizienz-Grenze. Ein Modell ist besser, wenn es sich in Richtung der oberen linken Ecke bewegt: weniger nachgelagerte Token bei gleichzeitigem Erhalt von mehr nützlichen Nachweisen. Das 28-Schichten-Modell dient als Qualitätsreferenz. Das 11-Schichten-Modell zeigt die Risiken einer zu aggressiven Kompression des Modells auf. Das beschnittene 17-Schichten-Modell stellt einen Mittelweg dar: Es folgt dem 28-Schichten-Modell im gesättigten Bereich eng, aber im steilen Teil der Kurve, in dem der Großteil des Produktionsverkehrs abläuft, öffnet sich eine kleine Lücke.

Um diese Lücke zu schließen, setzen wir Token-Level Knowledge Distillation ein. Unser Ansatz ist routinemäßig: Wir erweitern den Standardverlust um einen Soft-Cross-Entropy-Term der Vorhersagen des Lehrermodells, gewichtet mit einem Destillationskoeffizienten. Dies reicht aus, um das Schülermodell auf Parität zu bringen und uns den vollständigen Wechsel zum destillierten 17-Schichten-Modell in der Produktion zu ermöglichen. Dieses neue Produktionsmodell liefert eine Senkung der Inferenzlatenz um 35–40 % und eine Senkung des aggregierten GPU-Rechenaufwands um 40–45 % ohne Qualitätsverlust im Vergleich zum 28-Schichten-Lehrer. Die Produktionslatenz liegt unter 20 ms (p99): klein genug, um sie zum Bereitstellungspfad hinzuzufügen, während die Gesamtzahl der an das Antwortmodell übergebenen Token erheblich reduziert wird.

Vergrößern

Qualität und Token-Effizienz

Wir verwenden Perplexitys Agent API als Testumgebung, um die Wirksamkeit der Kontextkomprimierung zu analysieren. Wir bewerten drei Agent-API-Presets:

Eine „niedrige“ Kontext-Voreinstellung, die das Token-Budget für jeden Ergebnissatz auf 1000 Token begrenzt.

Eine „mittlere“ Kontext-Voreinstellung, die das Token-Budget für jeden Ergebnissatz auf 4000 Token begrenzt.

Eine „hohe“ Kontext-Voreinstellung, die das Token-Budget für jeden Ergebnissatz auf 10000 Token begrenzt.

Sowohl die Standard- als auch die Kompressionseinstellungen sind so konfiguriert, dass diese Token-Budgets eingehalten werden.

Agentische mehrstufige Suche (BrowseComp)

Wir untersuchen zunächst die Auswirkungen der Kompression auf agentische mehrstufige Such-Workflows auf dem BrowseComp-Benchmark. Wir führen diese Evaluation mit unserem Open-Source-Harness search_evals durch. Die Bewertung ist über alle Durchläufe identisch und verwendet den kanonischen BrowseComp LLM-Richter-Prompt von OpenAI.

Die beiden interessierenden Dimensionen sind die Benchmark-Genauigkeit und die Token-Nutzung. Wichtig ist, dass wir die Token-Nutzung auf Abfrageebene messen und nicht auf der Ebene einzelner Schritte, um die tatsächliche Token-Last zu messen, die über den gesamten Lebenszyklus der Anfrage anfällt. Abbildung 3 zeigt die „Score-Token“-Grenze, Genauigkeitswert vs. Token-Nutzung.

Vergrößern

Die Kompression liefert durchweg eine neue Pareto-Grenze. Für jede Einstellung reduziert die Einführung der Kompression die Token-Nutzung auf Abfrageebene um 10 % bis 70 %, bei Genauigkeitsgewinnen zwischen 4 und 4,81 Prozentpunkten. Die Einführung der Kompression ermöglicht es selbst unserer „niedrigen“ Voreinstellung, die „hohe“ Voreinstellung ohne Kompression zu übertreffen, bei gleichzeitig mehr als dreifacher Reduktion der Token-Nutzung.

Wir beobachten, dass mit Kompression „hoch“ eine höhere Genauigkeit liefert als „mittel“, wie wir es erwarten könnten. Interessanterweise geschieht dies jedoch bei geringerer Token-Nutzung. Dies offenbart einen subtilen, aber wichtigen Effekt der Kompression: Mit Kompression kann selbst die Erhöhung der Kontextgröße pro Schritt dem Modell ermöglichen, weniger Schritte zu unternehmen, um zum richtigen Ergebnis zu gelangen. Die Erforschung dieser Nicht-Monotonie ist eine vielversprechende Richtung für zukünftige Arbeiten.

SimpleQA: Einstufige Faktizität

BrowseComp betont mehrstufige Recherche, doch viele Produktions-Workflows beinhalten einstufige faktische Abfragen. Um festzustellen, ob Kompression auch im einstufigen Bereich hilft, untersuchen wir auch die Leistung auf SimpleQA, einem Benchmark, der 4.326 Fragen umfasst, die in einem einzigen Suchschritt beantwortet werden müssen, statt in einer Agentenschleife.

Wie zuvor tragen wir die Genauigkeit gegen die durchschnittlichen Gesamttoken pro Aufgabe unter Verwendung des kanonischen Richter-Prompts auf. Abbildung 4 zeigt die Score-Token-Grenze in diesem einstufigen Setting. Obwohl die Effektgrößen im einstufigen Setting komprimierter sind, beobachten wir erneut, dass die Kompression gleichzeitig die Genauigkeit und Effizienz bei allen Voreinstellungen verbessert und somit eine neue Pareto-Grenze einführt. Mit aktivierter Kompression erreicht die mittlere Voreinstellung 95 % Genauigkeit mit durchschnittlich nur 200 Token pro Dokument. Angesichts der durchschnittlichen Dokumentlänge von über 10.000 Token stellt dies eine Leistung auf Grenz-Ebene bei einem Kompressionsverhältnis von mehr als 50 dar.

Vergrößern

Was landet in den Snippets?

Die nachgelagerten Gewinne in Abschnitt 4.1 und 4.2 sind End-to-End. Um zu verstehen, wie die Kompression einzelne Snippets verändert, führen wir eine separate Evaluation durch, die einen LLM-Richter verwendet, um jedes Token jedes abgerufenen Snippets in eine von sechs Kategorien einzustufen:

Vital: Nachweise, die für die Beantwortung der Nutzerabfrage unerlässlich sind.

Themenfremd: Informationen, die für andere Zwecke nützlich sein könnten, sich jedoch nicht auf die vorliegende Abfrage beziehen.

Anzeigen: Irrelevante Werbung, die von der Beantwortung der Nutzerabfrage ablenkt.

Metadaten: Metadaten über den Inhalt des Dokuments.

Benutzeroberfläche & Navigation: Elemente für die Frontend-Anzeige und Navigation.

Duplikat: Wiederholung bereits zuvor integrierter Informationen.

Unsere Evaluation läuft auf 1.000 Abfragen mit gemischten Domänen aus unserem Validierungsset und vergleicht den Produktions-Stack mit einer ansonsten identischen Baseline, bei der die Kompression deaktiviert ist. Wie in Abbildung 5 gezeigt, erhöht die Kompression den Anteil vitaler Token pro Snippet um durchschnittlich 63 % gegenüber der Baseline ohne Kompression. Wir beobachten einen entsprechenden Rückgang um 29 % bei irrelevanten Token, mit besonders steilen Rückgängen bei UI/Navigation (-58 %), Metadaten (-46 %) und Anzeigen (-43 %). Diese Ergebnisse bestätigen den Mechanismus für die oben diskutierten Qualitäts-Effizienz-Verbesserungen: Kompression verbessert die Leistung in beiden Dimensionen durch eine drastische Erhöhung des Signal-Rausch-Verhältnisses jedes einzelnen Snippets.

Vergrößern

Abbildung 6 veranschaulicht diese Änderung für eine individuelle Abfrage. Für die Abfrage „6 Tage altes Neugeborenes Milchaufnahme pro Fütterung“ zeigen wir sowohl die unkomprimierten Baseline-Snippets als auch die komprimierten Snippets. Die Kompression eliminiert die nicht-vitalen Inhaltskategorien und behält nur die Informationen bei, die sich auf das Füttern von Neugeborenen beziehen. Wichtig ist, dass die Kompression erfolgreich Inhalte eliminiert, die zwar allgemein für die Seite thematisch relevant sein mögen, aber für diese spezifische auf Neugeborene fokussierte Abfrage themenfremd sind.

Vergrößern

Fazit

KI-Systeme verlassen sich auf Informationen mit hohem Signalwert, um Nutzeranfragen intelligent und effizient zu bedienen. Diese Informationen müssen so chirurgisch genau wie möglich präsentiert werden, um die Relevanz für jede Anfrage zu maximieren. Unsere neuen abfragebewussten Kompressionsmodelle tun genau dies, indem sie die themenrelevanten Nachweise pro Snippet maximieren und irrelevante Ablenkungen aggressiv aussortieren.

Durch den Einsatz dieser neuen Modelle innerhalb unseres Such-Stacks sind wir in der Lage, schnellere und bessere Antworten für diejenigen bereitzustellen, die sich auf unsere Produkte und APIs verlassen. Unser Ansatz schafft eine einfache Steuerungsoberfläche, die es unseren Systemen und API-Kunden ermöglicht, den Grad der Kompression anzupassen, um eine Balance zwischen Recall, Latenz und Kosten zu finden.

Kontext-Kuration ist ein sich entwickelndes Feld, und es gibt noch viel zu tun, um den Wert jedes Tokens, das in den heutigen hochmodernen Intelligenzsystemen verwendet wird, zu optimieren. Wir arbeiten aktiv daran, unsere Techniken zur Kontext-Kuration durch Modellverbesserungen und Systemarchitektur noch weiter zu verbessern, um diese Modelle noch umfassender nutzen zu können.

Referenzen

N. Chirkova, T. Formal, V. Nikoulina, und S. Clinchant. Provence: Effizientes und robustes Kontext-Beschneiden für Retrieval-Augmented Generation, 2025. Akzeptiert für ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, und D. Kim. LooComp: Leverage Leave-One-Out Strategy to Encoder-only Transformer for Efficient Query-Aware Context Compression, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, und D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, und G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

Zitieren

@online{perplexity2026QueryAwareContextCompressionForBetterSnippets,
  author = {{Perplexity} and Bo Wang and Hao Zhang and Ismail Gadzhiev and Kirill Priemko and Markus Krimmel and Nandor Licker and Vitalii Polshkov and Sarah Eslami and Louis Milliken and Maksim Gaiduk and Nikita Kireev and Jerry Ma},
  title = {{Query-aware context compression for better snippets}},
  date = {2026-05-14},
  url = {https://perplexity.coolkeypoint.com/hub/blog/query-aware-context-compression-for-better-snippets}
}