Frågemedveten kontextkomprimering för bättre textsnuttar

Varje svar börjar med bevis. I ett sökssystem kommer dessa bevis oftast från dokument: titlar, sammanfattningar, utdrag och textsnuttar som skickas som kontext till en svarsmodell eller agent.

Denna råa kontext är brusig. En webbsida kan till exempel innehålla information som behövs för användarens förfrågan, men den kan också innehålla distraherande element. Dessa distraktioner kan förekomma både i huvudtexten och i tillhörande element, såsom navigeringselement, irrelevanta annonser, metadata med mera. Att skicka vidare dessa distraktioner till en nedströmsagent skapar tre problem.

För det första skadar det träffsäkerheten. Även de mest kraftfulla modellerna har en begränsad kapacitet. Långa strömmar av irrelevant information slösar bort modellens kapacitet, vilket leder till "kontextröta" som försämrar modellens förmåga att hantera användarens faktiska förfrågan. Som ett resultat är det mer sannolikt att det slutliga svaret missar viktiga fakta, övervärderar lågkvalitativ information eller producerar påståenden som är svårare att förankra i källan.

För det andra försämras svarstiden. Längre kontext innebär fler tokens för nedströmsmodellen att bearbeta, särskilt när en fråga behöver bevis från många kandidatsidor. Även om en del av denna svarstidsfördyring uppstår i förfyllnadsfasen, betalas en mycket mer betydande kostnad i resonemang, där modellerna kräver fler resonemangstokens för att hantera irrelevant kontext.

För det tredje ökar det kostnaden. Varje onödig token som skickas till modellen gör det dyrare att betjäna användarens förfrågan, eftersom användningen av både inmatningstokens och resonemangstokens ökar med mer brusig kontext. Distraktioner minskar inte bara kvaliteten; de tvingar dig till slut att betala mer för den sämre kvaliteten.

Förstora

För att samtidigt öka träffsäkerheten, hastigheten och kostnadseffektiviteten i Perplexitys applikationer och API-plattform satsar vi stort på att förbättra kontextens precision. Ett sätt vi gör detta på är genom att förfina våra algoritmer för generering av textsnuttar. Vi behandlar genereringen av textsnuttar som ett problem med kontextkomprimering. Modeller som letar efter specifik information har ingen nytta av generaliserade sammanfattningar eller utdrag ur ett dokument. Istället behöver de den minsta och mest kirurgiskt uttagna biten av källinformation för att svara på användarens förfrågan. Allt annat kan och måste tas bort.

En bra textsnutt bör därför göra tre saker:

Främja träffsäkerhet genom att presentera de exakta bevis som krävs för att förankra modellens svar.

Minska svarstid och kostnad genom att ta bort irrelevant kontext innan LLM-anropet.

Säkerställa spårbarhet genom att bevara citatets korrekthet och hålla källans ordalydelse intakt.

Den här månaden har vi distribuerat en ny, toppmodern generator för textsnuttar i våra applikationer och vår API-plattform. Kärnan i denna modul är en frågemedveten kontextkomprimeringsmodell som för varje fråga och kandidatresultat avgör vilken delmängd av textsegment som ska bevaras. Den här artikeln beskriver vår metod för att bygga och träna modellen för att uppnå branschledande prestanda för denna kritiska uppgift.

Textsnuttar som frågemedveten komprimering

Det första steget är att definiera själva uppgiften. Vad vill vi att den här modellen ska göra, och hur ska vi definiera in- och utdata schemat?

Metoder för textsnuttar faller i två breda kategorier. Den första är urvalsbaserad: hitta ett relevant fönster, ett textblock, en mening eller ett stycke, och skicka det vidare nedströms. Den andra är genereringsbaserad: be en modell att skriva en frågefokuserad sammanfattning utifrån sidan.

Vårt fokus på träffsäkerhet, svarstid och kostnad gör designvalet tydligt. Vi kan utesluta generering, eftersom skapandet av en ny sammanfattning för varje sida försämrar prestandan över alla tre fokusområden. Sammanfattning lämpar sig dåligt för det bevislager vi bryr oss om. Den kan parafrasera källan, vilket gör det svårare att anpassa citat. Den kan också introducera formuleringar som inte fanns med på sidan, vilket är riskabelt när textsnutten används som bevis snarare än som det slutliga svaret. Den tillhörande svarstiden och kostnaden gör generering ännu mindre tilltalande.

Istället definierar vi vår uppgift som en form av frågemedveten extraherande komprimering: att skilja de till synes hjälpsamma delarna av den hämtade kontexten från de distraherande delarna. Närmare bestämt måste vår modell ta emot en fråga och ett kandidatresultat, och avgöra vilka textsegment som ska bevaras – de som bäst stöder frågan – och vilka som ska tas bort, det vill säga resten. Modellens utdata bevarar källtexten istället för att skriva om den. Detta gör resultatet enklare att citera, enklare att verifiera och billigare att skicka vidare nedströms.

Betrakta till exempel den här frågan och det hämtade resultatet:

Förstora

Ett rimligt modellresultat skulle vara att välja den fetstilta meningen: "In Comet, the assistant can ...".

Vårt tillvägagångssätt följer samma breda idé som tidigare arbete inom kontextkomprimering, såsom FliCo, Provence och LooComp, anpassat för generering av textsnuttar i ett produktionssökssystem. Viktigt är att modellen fungerar som ett precisionssteg efter vårt råa hämtningssteg. Som vi diskuterade i vår tidigare Perplexity Research-artikel, Introducing the Perplexity Search API, har vi arkiverat våra sökssystem för att arbeta nativt på underdokumentsnivå eller textsnuttnivå, vilket redan gör det möjligt för oss att balansera precision och återkallande ganska väl. Att introducera en frågemedveten kontextkomprimeringsmodell förskjuter precision-återkallande-Paretogränsen ännu längre utåt.

Bygga och träna en kontextkomprimeringsmodell

Vi utvecklar vår modell med tre huvudsakliga överväganden i åtanke: gemensam förståelse av fråga och kontext, finkornigt urval på meningsnivå samt effektivitet för att rymmas inom en extremt stram budget för svarstid.

Modellarkitektur

Vi använder en pplx-diffusionsmodell som basmodell. Detta är samma modellfamilj som ligger bakom pplx-embed-v1, och både vårt tidigare akademiska arbete, Diffusion-Pretrained Dense and Contextual Embeddings, och våra produktionsriktmärken bekräftar att det är en stark dubbelriktad kodare för fråga-kontext-par. En av de nyckelegenskaper som denna modellfamilj har är dubbelriktad kontext: varje tokenrepresentation kan uppmärksamma hela frågan och hela kandidatkontexten innan modellen bestämmer vad som ska behållas.

Ovanpå denna basmodell tränar vi ett lättviktskomprimeringshuvud som förutsäger vilka delar av kontexten som ska behållas. Eftersom ingen generering är involverad görs dessa förutsägelser parallellt över hela kontexten. Vid serveringstillfället aggregerar textsnuttsmotorn dessa förutsägelser på meningsnivå, tillämpar ett tröskelvärde och trimmar resultatet till den efterfrågade tokenbudgeten.

Övervakningspipeline

Att träna denna komprimerare kräver övervakning på rätt detaljnivå. En relevansetikett på dokumentnivå är uppenbarligen olämplig för vår extraherande komprimeringsuppgift. För att generera tillräckligt finkorniga data för övervakad inlärning byggde vi en pipeline för textsegmentsmärkning som markerar frågerelevanta bevissegment tillsammans med distraktionssegment som bör tas bort.

Vår pipeline använder en LLM-som-domare-konfiguration. Givet en användarfråga och en kandidatwebbsida med dess länk, titel och sammanfattning utför domaren först en frågeförståelse, där den analyserar frågan och genererar en lista med möjliga användaravsikter. Med dessa avsikter som grund bearbetar domaren sedan kandidatkontexten och returnerar segment som kopierats ordagrant från texten, tillsammans med en kategori för varje segment för att göra etiketterna lättare att granska.

Vi matchade sedan de returnerade segmenten mot källtexten. Inte oväntat var de flesta av domarens utdata redan exakta kopior: en enkel strängmatchning återfann 98 % av segmenten. Genom att lägga till ett enkelt regex-baserat matchningssteg nådde vi 100 % återvinning av segment. Detta gav oss tillförlitliga, finkorniga segment som kunde omvandlas till token-nivå behåll/ta-bort-övervakning.

Vi utvärderade denna övervakningspipeline med hjälp av en liten kurerad datauppsättning med manuellt märkta segment, där vi jämförde mindre domarmodeller, olika prompter och olika stegkonfigurationer. Den bäst presterande konfigurationen var en pipeline i två steg: först frågeförståelse, följt av kategoriserad segmentmärkning. Vi validerade också uppsättningen av extraherade segment genom nedströms verifierbara utvärderingar som BrowseComp och SimpleQA, där användningen av enbart de behållna bevissegmenten bevarade starka poäng samtidigt som inmatningstokens minskades avsevärt.

Med hjälp av denna pipeline märkte vi 750 000 fråga-dokument-par och använder de resulterande segmenten för att träna komprimeringshuvudet med binär korsentropi. Denna process gör det möjligt för vår frågemedvetna komprimeringsmodell att hålla källtexten intakt samtidigt som den tar bort kontext som sannolikt inte kommer att hjälpa nedströmsmodellen att betjäna användarens förfrågan.

Säkerställande av latens i realtid

Kontextkomprimering placeras före nedströmsmodellen, vilket gör den till en blockerande operation. Dessutom är varje komprimering frågeberoende. Därför måste onlinesökvägen poängsätta fråga-kontext-par för varje kandidatdokument inom en exakt latensram. En långsam komprimeringsmodell motarbetar sig själv, eftersom latensfördelarna med högre precision raderas ut av själva komprimeringslatensen. Samtidigt kommer en mindre intelligent komprimeringsmodell att fatta sämre beslut om vad som ska klippas bort och vad som ska behållas.

Den praktiska frågan är hur mycket modellkapacitet vi säkert kan ta bort innan komprimeringskvaliteten börjar försämras. Vi jämför den fullständiga 28-lagers pplx-diffusionsbasmodellen med 11-lagers- och 17-lagersvarianter som producerats genom lagerbeskärning och anpassats för sökvägen. För var och en varierar vi komprimeringströskelvärdet och mäter två kvantiteter: det genomsnittliga antalet kontext-tokens som skickas nedströms per fråga, och andelen användbara bevis som bevaras efter komprimering.

Figur 2 visar kvalitet-effektivitets-gränsen. En modell är bättre när den rör sig uppåt och åt vänster: färre nedströms-tokens med mer användbart bevismaterial bevarat. 28-lagersmodellen utgör kvalitetsreferensen. 11-lagersmodellen visar på riskerna med att komprimera modellen för aggressivt. Den beskurna 17-lagersmodellen representerar en medelväg: den följer 17-lagersmodellen (sic) nära i det mättade registret, men ett litet glapp öppnar sig i den branta delen av kurvan där den mesta produktionstrafiken körs.

För att överbrygga det glappet använder vi kunskapsdestillation på token-nivå. Vårt tillvägagångssätt är rutinmässigt: vi utökar standardförlusten med en mjuk korsentropiterm baserat på lärarmodellens förutsägelser, viktad med en destillationskoefficient. Detta räcker för att få studentmodellen i paritet, vilket gör att vi helt kan gå över till den destillerade 17-lagersmodellen i produktion. Denna nya produktionsmodell ger en minskning av inferenslatensen med 35–40 % och en minskning av den totala GPU-beräkningen med 40–45 % utan någon kvalitetsförsämring jämfört med 28-lagerslärarmodellen. Produktionslatensen ligger på under 20 ms (p99): tillräckligt liten för att läggas till i serveringssökvägen samtidigt som den totala mängden tokens som skickas till svarsmodellen minskar kraftigt.

Förstora

Kvalitet och tokeneffektivitet

Vi använder Perplexitys Agent API som en testbädd för att analysera effektiviteten av kontextkomprimering. Vi utvärderar tre förinställningar för Agent API:

En "låg" kontextförinställning som begränsar tokenbudgeten för varje resultat uppsättning till 1000 tokens.

En "medel" kontextförinställning som begränsar tokenbudgeten för varje resultat uppsättning till 4000 tokens.

En "hög" kontextförinställning som begränsar tokenbudgeten för varje resultat uppsättning till 10000 tokens.

Både standardinställningen, utan komprimering, och komprimeringsinställningarna är konfigurerade för att respektera dessa tokenbudgetar.

Agentbaserad sökning i flera steg (BrowseComp)

Vi undersöker först komprimeringens inverkan på agentbaserade sökarbetsflöden i flera steg på BrowseComp-riktmärket. Vi utför denna utvärdering med hjälp av vårt verktyg med öppen källkod search_evals. Betygssättningen är identisk över alla körningar, med användning av OpenAI:s kanoniska BrowseComp LLM judge prompt.

De två dimensionerna av intresse är riktmärkets träffsäkerhet och tokenanvändning. Viktigt är att vi mäter tokenanvändningen på frågenivå snarare än på individuell stegnivå för att kunna mäta den faktiska tokenbelastningen under hela begärans livscykel. Figur 3 visar "poäng-token"-gränsen, träffsäkerhetspoäng kontra tokenanvändning.

Förstora

Komprimering levererar en ny Paretogräns över hela linjen. För varje inställning minskar införandet av komprimering tokenanvändningen på frågenivå med allt från 10 % till 70 %, med träffsäkerhetsvinster på mellan 4 och 4,81 procentenheter. Att introducera komprimering gör att även vår "låg"-förinställning presterar bättre än "hög"-förinställningen utan komprimering, samtidigt som tokenanvändningen minskar med mer än trefaldigt.

Vi observerar att med komprimering ger "hög" högre träffsäkerhet än "medel", vilket vi kan förvänta oss. Intressant nog sker detta dock vid en lägre tokenanvändning. Detta avslöjar en subtil men viktig effekt av komprimering: med komprimering kan till och med en ökad kontextstorlek per steg göra det möjligt för modellen att ta färre steg för att komma fram till det korrekta resultatet. Att utforska denna icke-monotoni är en lovande riktning för framtida arbete.

SimpleQA: enstegsfaktabaserbarhet

BrowseComp fokuserar på forskning i flera steg, men många produktionsarbetsflöden innefattar enstegs-faktainhämtning. För att fastställa om komprimering även hjälper i enstegsscenariot undersöker vi prestandan på SimpleQA, ett riktmärke som omfattar 4 326 frågor som ska besvaras i ett enda söksteg snarare än i en agentloop.

Precis som tidigare plottar vi träffsäkerhet mot genomsnittligt totalt antal tokens per uppgift med hjälp av den kanoniska domarprompten. Figur 4 visar poäng-token-gränsen i detta enstegsscenario. Även om effektstorlekarna är mer komprimerade i enstegsscenariot observerar vi återigen att komprimering samtidigt förbättrar träffsäkerhet och effektivitet för alla förinställningar, vilket därmed introducerar en ny Paretogräns. Med aktiverad komprimering uppnår medelförinställningen 95 % träffsäkerhet med ett genomsnitt på endast 200 tokens per dokument. Med tanke på den genomsnittliga dokumentlängden på över 10 000 tokens representerar detta prestanda på gränsnivå vid ett komprimeringsförhållande på mer än 50.

Förstora

Vad hamnar i textsnuttarna?

Nedströmsvinsterna i avsnitt 4.1 och 4.2 är end-to-end. För att förstå hur komprimering förändrar enskilda textsnuttar kör vi en separat utvärdering som använder en LLM-domare för att klassificera varje token i varje hämtad textsnutt i en av sex kategorier:

Viktigt: bevis som är väsentliga för att besvara användarens fråga.

Utanför ämnet: information som kan vara till nytta för något annat syfte men som inte är relevant för den aktuella frågan.

Annonser: irrelevant reklam som distraherar från att besvara användarens fråga.

Metadata: metadata om dokumentets innehåll.

UI och navigation: element för gränssnittsvisning och navigation.

Duplikat: upprepning av tidigare inkorporerad information.

Vår utvärdering körs på 1 000 frågor med blandade domäner från vår valideringsuppsättning och jämför produktionsstacken med en i övrigt identisk baslinje där komprimering har inaktiverats. Som visas i figur 5 ökar komprimering andelen viktiga tokens per textsnutt med i genomsnitt 63 % jämfört med baslinjen utan komprimering. Vi observerar en motsvarande minskning på 29 % av irrelevanta tokens, med särskilt branta minskningar inom UI/navigation (-58 %), metadata (-46 %) och annonser (-43 %). Dessa resultat bekräftar mekanismen bakom de kvalitet- och effektivitetsförbättringar som diskuterades ovan: komprimering förbättrar prestandan över båda dimensionerna genom att kraftigt öka signal-brusförhållandet för varje enskild textsnutt.

Förstora

Figur 6 illustrerar denna förändring för en enskild fråga. För frågan "6 dagars nyfödd mjölkintag per matning" visar vi både den okomprimerade baslinjen och de komprimerade textsnuttarna. Komprimering eliminerar de icke-viktiga innehållskategorierna och behåller endast den nyföddrelaterade matningsinformationen. Viktigt är att komprimering framgångsrikt eliminerar innehåll som kan vara allmänt relevant för sidan, men utanför ämnet för denna specifika nyföddfokuserade fråga.

Förstora

Slutsats

AI-system är beroende av information med hög signalstyrka för att intelligent och effektivt betjäna användarförfrågningar. Denna information måste presenteras så kirurgiskt som möjligt för att maximera relevansen för varje förfrågan. Våra nya frågemedvetna komprimeringsmodeller gör precis detta genom att maximera ämnesrelaterade bevis per textsnutt och aggressivt gallra bort irrelevanta distraktioner.

Genom att distribuera dessa nya modeller i vår sökstack kan vi tillhandahålla snabbare och bättre svar till dem som förlitar sig på våra produkter och API:er. Vårt tillvägagångssätt skapar ett enkelt kontrollgränssnitt som gör det möjligt för våra system och API-kunder att finjustera komprimeringsgraden för att balansera mellan återkallande, latens och kostnad.

Kontextkurering är ett område under utveckling, och det finns mycket mer att göra för att optimera värdet av varje token som används i dagens gränsöverskridande intelligenssystem. Vi arbetar aktivt för att göra våra tekniker för kontextkurering ännu bättre genom både modellförbättringar och systemarkitektur för att kunna utnyttja dessa modeller på ett ännu mer extensivt sätt.

Referenser

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

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

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

Citering

@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}
}