Forespørselsbevisst kontekstkompresjon for bedre utdrag

Eth hvert svar starter med bevis. I et søkesystem kommer dette beviset vanligvis fra dokumenter: titler, sammendrag, utdrag og tekstbiter som sendes som kontekst til en svarmodell eller agent.

Denne råkonteksten er støyende. For eksempel kan en nettside inneholde informasjon som trengs for brukerens forespørsel, men den kan også inneholde støylementer. Disse støylementene kan vises både i hovedteksten og i tilhørende elementer, som nav-tekstelementer, irrelevante annonser, metadata med mer. Å sende disse støylementene videre til en nedstrømsagent skaper tre problemer.

For det første går det ut over nøyaktigheten. Selv de kraftigste modellene har begrenset kapasitet. Lange strømmer med irrelevant informasjon kaster bort modellkapasitet, noe som resulterer i «kontekstråte» som svekker modellens evne til å svare på den faktiske brukerforespørselen. Som et resultat er det mer sannsynlig at det endelige svaret utelater nøkkelfakta, overvekter informasjon av lav kvalitet eller produserer påstander som er vanskeligere å begrunne i kilden.

For det andre reduserer det latensen. Lengre kontekst betyr flere tokens for den nedstrøms modellen å behandle, spesielt når et søk trenger bevis fra mange kildesider. Selv om en del av denne latenskostnaden bæres i forhåndsutfyllingsfasen, betales en mye vesentligere kostnad i resonnering, der modeller krever flere resonneringstokens for å håndtere irrelevant kontekst.

For det tredje øker det kostnadene. Hvert unødvendige token som sendes til modellen, gjør det dyrere å betjene brukerens forespørsel, ettersom både bruken av inndatatokens og resonneringstokens øker med mer støyende kontekst. Distraksjoner reduserer ikke bare kvaliteten; de ender opp med å tvinge deg til å betale mer for den dårligere kvaliteten.

Forstørr

For samtidig å fremme nøyaktighet, hastighet og kostnadseffektivitet på tvers av Perplexitys applikasjoner og API-plattform, investerer vi tungt i å forbedre kontekstpresisjonen. En måte vi gjør dette på, er ved å foredle våre algoritmer for utdragsgenerering. Vi behandler generering av utdrag som et kontekstkomprimeringsproblem. Modeller som leter etter spesifikke opplysninger, har ingen nytte av generaliserte sammendrag eller utdrag av et dokument. De trenger snarere det minste, mest kirurgisk uttrukne stykket med kildeinformasjon for å svare på brukerens forespørsel. Alt annet kan og må fjernes.

Et godt utdrag bør derfor gjøre tre ting:

Fremme nøyaktighet ved å presentere de nøyaktige bevisene som trengs for å begrunne modellens svar.

Redusere latens og kostnader ved å fjerne irrelevant kontekst før LLM-krysset.

Sikre sporbarhet ved å bevare sitatfideliteten og holde kildeteksten intakt.

Denne måneden implementerte vi en ny, banebrytende utdragsgenerator i våre applikasjoner og vår API-plattform. Kjernen i denne modulen er en forespørselsbevisst kontekstkomprimeringsmodell som avgjør, for hver forespørsel og kandidatresultat, hvilken delmengde av avsnitt som skal bevares. Denne artikkelen beskriver vår tilnærming til å bygge og trene modellen for å oppnå best mulig ytelse i klassen på denne kritiske oppgaven.

Utdrag som forespørselsbevisst kompresjon

Den første oppgaven er å definere selve oppgaven. Hva vil vi at denne modellen skal gjøre, og hvordan bør vi definere inndata- og utdataschemaet?

Utdragsmetoder faller inn i to brede kategorier. Den første er utvalgsbasert: finn et relevant vindu, en bolk, setning eller passasje, og send den videre nedstrøms. Den andre er genereringsbasert: be en modell om å skrive et forespørselsfokusert sammendrag fra siden.

Vårt fokus på nøyaktighet, latens og kostnad gjør designvalget klart. Vi kan utelukke generering, siden det å opprette et nytt sammendrag for hver side svekker ytelsen på alle de tre fokusområdene. Sammendrag egner seg dårlig for det bevislaget vi bryr oss om. Det kan parafrasere kilden, noe som gjør sitattilpasning vanskeligere. Det kan også introdusere ordlyd som ikke fantes på siden, noe som er risikabelt når utdraget brukes som bevis i stedet for som det endelige svaret. Latensen og kostnadene som er involvert, gjør generering enda mindre tiltalende.

Snarere definerer vi oppgaven vår som en form for forespørselsbevisst ekstraktiv kompresjon: å skille de nyttige delene av den hentede konteksten fra de distraherende delene. Spesielt må modellen vår akseptere en forespørsel og et kandidatresultat, og avgjøre hvilke avsnitt som skal bevares – de som støtter forespørselen best – og hvilke som skal forkastes – resten. Modellutdataene bevarer kildeteksten i stedet for å omskrive den. Dette gjør resultatet enklere å sitere, enklere å verifisere og billigere å sende videre nedstrøms.

Tenk deg for eksempel denne forespørselen og det hentede resultatet:

Forstørr

En sannsynlig modellutgang vil være å velge den uthevede setningen: "I Comet kan assistenten ...".

Vår tilnærming følger den samme brede ideen som tidligere arbeid med kontekstkompresjon som FliCo, Provence og LooComp, tilpasset for utdragsgenerering i et produksjonssøkesystem. Viktig nok fungerer modellen som et presisjonstrinn etter vårt råinnhentingstrinn. Som diskutert i vår forrige Perplexity Research-artikkel, Vi introduserer Perplexity Search API, arkitekter vi innhentingssystemene våre til å fungere opprinnelig på underdokuments- eller utdragsnivå, noe som allerede tillater oss å balansere presisjon og gjenfinning ganske godt. Å introdusere en forespørselsbevisst kontekstkomprimeringsmodell skyver Pareto-grensen for presisjon og gjenfinning enda lenger utover.

Bygging og trening av en kontekstkomprimeringsmodell

Vi utvikler modellen vår med tre hovedhensyn i tankene: felles forståelse av forespørsel og kontekst, finkornet utvalg på setningsnivå, og effektivitet for å passe inn i et ekstremt stramt latensbudsjett.

Modellarkitektur

Vi bruker en pplx-diffusjonsmodell som grunnstamme. Dette er den samme modellfamilien som ligger bak pplx-embed-v1, og både vårt tidligere akademiske arbeid, Diffusion-Pretrained Dense and Contextual Embeddings, og våre produksjonsreferanseverdier bekrefter at den er en sterk toveiskoder for forespørsel-kontekst-par. En av nøkkelegenskapene fra denne modellfamilien er toveiskontekst: hver tokenrepresentasjon kan forholde seg til hele forespørselen og hele kandidatkonteksten før modellen avgjør hva som skal beholdes.

På toppen av denne grunnstammen trener vi et lettvekts komprimeringshode som forutsier hvilke deler av konteksten som skal beholdes. Fordi ingen generering er involvert, utføres disse spådommene parallelt på tvers av hele konteksten. På serveringstidspunktet aggregerer utdragsmotoren disse prediksjonene på setningsnivå, bruker en terskel og trimmer resultatet til det forespurte tokenbudsjettet.

Overvåkingsrørledning

Trening av denne kompressoren krever overvåking på riktig detaljnivå. En relevansetikett på dokumentnivå er åpenbart uegnet for vår ekstraktive komprimeringsoppgave. For å generere tilstrekkelig finkornede data for overvåket læring, bygget vi en avsnittsetiketteringsrørledning som markerer forespørselsrelevante bevisavsnitt, sammen med støyavsnitt som bør fjernes.

Rørledningen vår bruker et LLM-som-dommer-oppsett. Gitt en brukerforespørsel og en kandidatnettside med tilhørende lenke, tittel og sammendrag, utfører dommeren først en forespørselsforståelse, der den analyserer forespørselen og produserer en liste over mulige brukerhensikter. Med forankring i disse hensiktene behandler dommeren deretter kandidatkonteksten og returnerer avsnitt kopiert ordrett fra teksten, med en kategori for hvert avsnitt for en enklere inspeksjon av etikettene.

Vi matchet deretter de returnerte avsnittene opp mot kildeteksten igjen. Ikke overraskende var de fleste dommerutdataene allerede nøyaktige kopier: enkel strengmatching gjenvant 98 % av avsnittene. Å legge til en enkel regex-basert matchingstrinn brakte avsnittsgjenopprettingen opp på 100 %. Dette ga oss pålitelige, finkornede avsnitt som kunne konverteres til token-nivå beholde/forkaste-overvåking.

Vi evaluerte denne overvåkingsrørledningen ved hjelp av et lite kuratert datasett med manuelt merkede avsnitt, der vi sammenlignede mindre dommermodeller, forskjellige ledetekster og forskjellige trinnkonfigurasjoner. Det best presterende oppsettet var en totrinnsrørledning: først forespørselsforståelse, etterfulgt av kategorisert avsnittsmerking. Vi validerte også settet med uttrukne avsnitt gjennom nedstrøms verifiserbare evalueringer som BrowseComp og SimpleQA, der bruk av kun de beholdte bevisavsnittene bevarte sterke skårer samtidig som inndatatokenene ble betydelig redusert.

Ved hjelp av denne rørledningen merket vi 750k forespørsel-dokument-par og brukte de resulterende avsnittene til å trene komprimeringshodet med binær kryssentropi. Denne prosessen lar vår forespørselsbevisste komprimeringsmodell holde kildeteksten intakt samtidig som den fjerner kontekst som sannsynligvis ikke vil hjelpe den nedstrøms modellen med å betjene brukerens forespørsel.

Sikring av sanntidslatens

Kontekstkompresjon plasseres før den nedstrøms modellen, noe som gjør det til en blokkerende operasjon. Dessuten er hver kompresjon forespørselsavhengig. Derfor må onlinestien skåre forespørsel-kontekst-par for hvert kandidatdokument innenfor et strengt latensomslag. En treig komprimeringsmodell motvirker sin hensikt, ettersom latensfordelene fra høyere presisjon slettes av selve komprimeringslatensen. Samtidig vil en mindre intelligent komprimeringsmodell ta dårligere beslutninger om hva som skal kuttes og beholdes.

Det praktiske spørsmålet er hvor mye modellkapasitet vi trygt kan fjerne før komprimeringskvaliteten begynner å avta. Vi sammenligner den fulle 28-lags pplx-diffusjonsgrunnstammen med 11-lags og 17-lags varianter produsert ved lagbeskjæring og rettet mot søkestien. For hver av dem feier vi over komprimeringsterskelen og måler to størrelser: gjennomsnittlig antall konteksttokens sendt nedstrøms per forespørsel, og brøkdelen av nyttige bevis bevart etter kompresjon.

Figur 2 viser kvalitet-effektivitet-grensen. En modell er bedre når den beveger seg mot øverste venstre hjørne: færre nedstrøms tokens med mer nyttig bevis bevart. 28-lagsmodellen gir kvalitetsreferansen. 11-lagsmodellen demonstrerer risikoen ved å komprimere modellen for aggressivt. Den beskjærte 17-lagsmodellen representerer et mellommål: den følger 28-lagsmodellen tett i det mettede regimet, men et lite gap åpner seg i den bratte delen av kurven der all produksjonstrafikk opererer.

For å lukke det gapet bruker vi token-nivå kunnskapsdistillasjon. Vår tilnærming er rutinemessig: vi utvider standardtapet med et mykt kryssentropitid på læreremodellens spådommer, vektet av en distillasjonskoeffisient. Dette er tilstrekkelig til å bringe studentmodellen til paritet, slik at vi fullt ut kan bytte til den destillerte 17-lagsmodellen i produksjon. Denne nye produksjonsmodellen gir en reduksjon på 35–40 % i slutningslatens og 40–45 % reduksjon i samlet GPU-beregning uten kvalitetstap i forhold til 28-lags læreren. Produksjonslatensen klokker inn på under 20 ms (p99): liten nok til å legges til serveringsstien samtidig som de totale tokens som sendes til svarmodellen, reduseres kraftig.

Forstørr

Kvalitet og tokeneffektivitet

Vi bruker Perplexitys Agent API som en testbenk for å analysere effektiviteten av kontekstkompresjon. Vi evaluerer tre Agent API-forhåndsinnstillinger:

En «lav» kontekstforhåndsinnstilling som begrenser tokenbudsjettet for hvert resultatsett til 1000 tokens.

En «middels» kontekstforhåndsinnstilling som begrenser tokenbudsjettet for hvert resultatsett til 4000 tokens.

En «høy» kontekstforhåndsinnstilling som begrenser tokenbudsjettet for hvert resultatsett til 10000 tokens.

Både standard-, ingen-kompresjon- og kompresjonsinnstillingene er konfigurert til å overholde disse tokenbudsjettene.

Agentbasert flertrinssøk (BrowseComp)

Vi undersøker først kompresjonens innvirkning på agentbaserte flertrinnssøksarbeidsflyter på BrowseComp-referansen. Vi utfører denne evalueringen ved hjelp av vår åpen kildekode-seleksjon search_evals. Poenggivingen er identisk på tvers av alle kjøringer, ved hjelp av OpenAIs kanoniske BrowseComp LLM-dommerledetekst.

De to dimensjonene av interesse er referansenøyaktighet og tokenbruk. Viktig nok måler vi tokenbruken på forespørselsnivå i stedet for på det individuelle trinnsnivået for å måle den faktiske tokenbelastningen som pådras gjennom hele forespørselens livssyklus. Figur 3 viser «skår-token»-grensen, nøyaktighetsskår vs. tokenbruk.

Forstørr

Kompresjon leverer en ny Pareto-grense hele veien igjennom. For hver innstilling reduserer innføring av kompresjon tokenbruken på forespørselsnivå med alt fra 10 % til 70 %, med nøyaktighetsgevinster som klokker inn mellom 4 og 4,81 prosentpoeng. Å introdusere kompresjon gjør at selv vår «lave» forhåndsinnstilling utkonkurrerer «høy»-forhåndsinnstillingen uten kompresjon, samtidig som tokenbruken reduseres med mer enn tre ganger.

Vi observerer at med kompresjon gir «høy» større nøyaktighet enn «middels» som vi kanskje kan forvente. Interessant nok gjør det imidlertid dette ved lavere tokenbruk. Dette avslører en subtil, men viktig effekt av kompresjon: med kompresjon kan selv økende per-trinn kontekststørrelse gjøre det mulig for modellen å ta færre trinn for å komme fram til det riktige resultatet. Å utforske denne ikke-monotonisiteten er en lovende retning for fremtidig arbeid.

SimpleQA: enstrinns faktasjekk

BrowseComp legger vekt på flertrinnsforskning, men mange produksjonsarbeidsflyter involverer enstrinns faktasøk. For å avgjøre om kompresjon også hjelper i enstrinnsregimet, undersøker vi også ytelsen på SimpleQA, en referanse som består av 4326 spørsmål som skal besvares i et enkelt søketrinn, i stedet for i en agentløkke.

Som før plotter vi nøyaktighet mot gjennomsnittlige totale tokens per oppgave ved hjelp av den kanoniske dommerledeteksten. Figur 4 viser skår-token-grensen i denne enstrinnsinnstillingen. Selv om effektestørrelsene er mer komprimerte i enstrinnsinnstillingen, observerer vi igjen at kompresjon samtidig forbedrer nøyaktighet og effektivitet på tvers av alle forhåndsinnstillinger, og dermed introduserer en ny Pareto-grense. Med kompresjon aktivert oppnår den midlere forhåndsinnstillingen 95 % nøyaktighet med et gjennomsnitt på bare 200 tokens per dokument. Gitt en gjennomsnittlig dokumentlengde på over 10 000 tokens, representerer dette ytelse på grensenivå ved et kompresjonsforhold på mer enn 50.

Forstørr

Hva ender opp i utdragene?

Nedstrømsgevinstene i avsnitt 4.1 og 4.2 er ende-til-ende. For å forstå hvordan kompresjon endrer individuelle utdrag, kjører vi en egen evaluering som bruker en LLM-dommer til å klassifisere hvert token i hvert hentede utdrag i en av seks kategorier:

Vitale: bevis som er essensielle for å svare på brukerens forespørsel.

Uvedkommende: informasjon som kan være nyttig for andre formål, men som ikke er relevant for den aktuelle forespørselen.

Annonser: irrelevant reklame som distraherer fra å svare på brukerens forespørsel.

Metadata: metadata om dokumentets innhold.

UI og navigasjon: elementer for frontend-visning og navigasjon.

Duplikat: repetisjon av tidligere innlemmet informasjon.

Evalueringen vår kjører på 1 000 blandet-domene-forespørsler fra valideringssettet vårt, og sammenligner produksjonsstakken med en ellers identisk baseline der kompresjon er deaktivert. Som vist i figur 5 øker kompresjon andelen vitale tokens per utdrag med i gjennomsnitt 63 % sammenlignet med baseline uten kompresjon. Vi observerer en tilsvarende nedgang på 29 % i irrelevante tokens, med spesielt bratte fall i UI/navigasjon (-58 %), metadata (-46 %) og annonser (-43 %). Disse resultatene bekrefter mekanismen for kvalitets- og effektivitetsforbedringene som diskuteres ovenfor: kompresjon forbedrer ytelsen på tvers av begge dimensjoner ved å øke signal-til-støy-forholdet for hvert enkelt utdrag kraftig.

Forstørr

Figur 6 illustrerer denne endringen for en individuell forespørsel. For forespørselen «6 dag gammel nyfødt melkeinntak per mating» viser vi både de ukomprimerte baseline- og de komprimerte utdragene. Kompresjon eliminerer kategoriene for ikke-vitalt innhold og beholder kun den nyfødtrelaterte mateinformasjonen. Viktig nok eliminerer kompresjon vellykket innhold som kan være generelt relevant for siden, men uvedkommende for denne spesifikke nyfødtfokuserte forespørselen.

Forstørr

Konklusjon

AI-systemer er avhengige av informasjon med høyt signalnivå for å betjene brukerforespørsler intelligent og effektivt. Denne informasjonen må presenteres så kirurgisk som mulig for å maksimere relevansen for hver forespørsel. Våre nye forespørselsbevisste komprimeringsmodeller gjør nøyaktig dette ved å maksimere relevant bevis per utdrag og aggressivt luke ut irrelevante distraksjoner.

Ved å distribuere disse nye modellene i søkestakken vår er vi i stand til å levere raskere og bedre svar til de som er avhengige av produktene og API-ene våre. Tilnærmingen vår skaper en enkel kontrollflate, slik at systemene våre og API-kundene kan finjustere komprimeringsgraden for å balansere mellom gjenfinning, latens og kostnad.

Kontekstkuratering er et felt i utvikling, og det er mye mer som gjenstår å gjøre for å optimalisere verdien av hvert token som brukes i dagens grenseregulerende intelligenssystemer. Vi jobber aktivt for å gjøre våre kontekstkurateringsteknikker enda bedre gjennom både modellforbedringer og systemarkitektur for å utnytte disse modellene på en enda mer omfattende måte.

Referanser

N. Chirkova, T. Formal, V. Nikoulina, og S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Akseptert til ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, og 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, og D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

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

Sitat

@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://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}