Compresie a contextului conștientă de interogare pentru fragmente mai bune

Fiecare răspuns pornește de la dovezi. Într-un sistem de căutare, aceste dovezi provin de obicei din documente: titluri, rezumate, fragmente și citate care sunt transmise drept context unui model de răspuns sau agent.

Acest context neprelucrat conține mult zgomot. De exemplu, o pagină web poate conține informații necesare pentru solicitarea utilizatorului, dar poate include și elemente perturbatoare. Aceste elemente pot apărea atât în corpul principal, cât și în elemente auxiliare, cum ar fi textul din elementele de navigare, reclame irelevante, metadate și altele. Transmiterea acestor elemente perturbatoare către un agent din aval generează trei probleme.

În primul rând, afectează acuratețea. Chiar și cele mai puternice modele au o capacitate finită. Șirurile lungi de informații irelevante risipesc capacitatea modelului, ducând la o „degradare a contextului” care diminuează capacitatea unui model de a soluționa solicitarea efectivă a utilizatorului. Prin urmare, răspunsul final are șanse mai mari să omită fapte cheie, să acorde o importanță disproporționată informațiilor de slabă calitate sau să genereze afirmații care sunt mai greu de susținut cu dovezi din sursă.

În al doilea rând, crește latența. Un context mai lung înseamnă mai multe tokenuri pe care modelul din aval trebuie să le proceseze, în special atunci când o interogare necesită dovezi din multe pagini candidate. Deși o parte din acest cost de latență se manifestă în etapa de preumplere („prefill”), un cost mult mai semnificativ este plătit în faza de raționament, modelele necesitând mai multe tokenuri de raționament pentru a face față contextului irelevant.

În al treilea rând, crește costurile. Fiecare token inutil transmis modelului face ca deservirea solicitării utilizatorului să fie mai costisitoare, deoarece utilizarea atât a tokenurilor de intrare, cât și a celor de raționament crește pe măsură ce contextul devine mai plin de zgomot. Elementele perturbatoare nu doar reduc calitatea; ele ajung să vă oblige să plătiți mai mult pentru acea calitate inferioară.

Extinde

Pentru a îmbunătăți simultan acuratețea, viteza și eficiența costurilor în cadrul aplicațiilor Perplexity și al Platformei API, investim masiv în îmbunătățirea preciziei contextului. O modalitate prin care facem acest lucru este prin rafinarea algoritmilor noștri de generare a fragmentelor. Tratăm generarea fragmentelor ca pe o problemă de compresie a contextului. Modelele care caută informații specifice nu beneficiază de pe urma unor rezumate generalizate sau a unor extrase dintr-un document. Mai degrabă, ele au nevoie de cea mai mică bucată de informație din sursă, extrasă chirurgical, pentru a răspunde la solicitarea utilizatorului. Orice altceva poate și trebuie să fie eliminat.

Prin urmare, un fragment bun ar trebui să îndeplinească trei lucruri:

Să promoveze acuratețea prin prezentarea dovezilor precise necesare pentru a fundamenta răspunsul modelului.

Să reducă latența și costurile prin eliminarea contextului irelevant înainte de apelul către LLM.

Să asigure trasabilitatea prin păstrarea fidelității citatelor și a formulării originale din sursă.

Luna aceasta, am implementat un generator de fragmente nou, de ultimă generație, în cadrul aplicațiilor noastre și al Platformei API. Miezul acestui modul este un model de compresie a contextului conștient de interogare (query-aware), care decide, pentru fiecare interogare și rezultat candidat, subansamblul de segmente (spans) care ar trebui păstrat. Acest articol descrie abordarea noastră privind construirea și antrenarea modelului pentru a obține o performanță de top în această sarcină critică.

Fragmentele ca compresie conștientă de interogare

Prima prioritate este definirea sarcinii în sine. Ce ne dorim să facă acest model și cum ar trebui să definim schema de intrare și de ieșire?

Metodele pentru fragmente se încadrează în două mari categorii. Prima se bazează pe selecție: găsește o fereastră, un segment, o propoziție sau un pasaj relevant și îl transmite mai departe în aval. A doua se bazează pe generare: îi cere unui model să scrie un rezumat axat pe interogare pornind de la pagină.

Focalizarea noastră pe acuratețe, latență și cost face ca opțiunea de design să fie clară. Putem exclude generarea, deoarece crearea unui rezumat nou pentru fiecare pagină afectează performanța în toate cele trei direcții. Sumarizarea nu se potrivește bine cu stratul de dovezi care ne interesează. Aceasta poate parafraza sursa, îngreunând alinierea citatelor. De asemenea, poate introduce formulări care nu au fost prezente în pagină, ceea ce este riscant atunci când fragmentul este folosit ca dovadă și nu ca răspuns final. Latența și costul implicate fac ca generarea să fie și mai puțin atrăgătoare.

În schimb, definim sarcina noastră ca fiind o compresie extractivă conștientă de interogare: separarea părților utile ale contextului regăsit de cele care constituie distracții. Mai exact, modelul nostru trebuie să accepte o interogare și un rezultat candidat și să decidă ce segmente să păstreze – pe cele care susțin cel mai bine interogarea – și pe care să le elimine – pe restul. Ieșirea modelului păstrează textul sursă în loc să îl rescrie. Acest lucru face ca rezultatul să fie mai ușor de citat, mai ușor de verificat și mai ieftin de transmis în aval.

De exemplu, luați în considerare această interogare și rezultatul regăsit:

Extinde

O ieșire plauzibilă a modelului ar fi selectarea propoziției îngroșate: „În Comet, asistentul poate ...”.

Abordarea noastră urmează aceeași idee generală ca și lucrările anterioare privind compresia contextului, cum ar fi FliCo, Provence și LooComp, adaptată pentru generarea de fragmente într-un sistem de căutare de producție. Important este că modelul funcționează ca o etapă de precizie după etapa noastră de regăsire brută. Așa cum am discutat în articolul nostru anterior de la Perplexity Research, Prezentarea API-ului de căutare Perplexity, am arhitecturat sistemele noastre de regăsire pentru a opera în mod nativ la nivel de sub-document sau fragment, ceea ce ne permite deja să echilibrăm destul de bine precizia și acoperirea (recall). Introducerea unui model de compresie a contextului conștient de interogare împinge frontiera Pareto precizie-acoperire și mai mult în exterior.

Construirea și antrenarea unui model de compresie a contextului

Dezvoltăm modelul nostru având în vedere trei considerații principale: înțelegerea comună a interogării și a contextului, selecție fină la nivel de propoziție și eficiență pentru a se încadra într-un buget de latență extrem de strict.

Arhitectura modelului

Folosim un model pplx-diffusion ca bază (backbone). Aceasta este aceeași familie de modele aflată în spatele pplx-embed-v1, iar atât munca noastră academică anterioară, Diffusion-Pretrained Dense and Contextual Embeddings, cât și benchmarkurile noastre de producție confirmă că este un codificator bidirecțional puternic pentru perechi interogare-context. Una dintre proprietățile cheie ale acestei familii de modele este contextul bidirecțional: fiecare reprezentare de token poate lua în considerare întreaga interogare și întregul context candidat înainte ca modelul să decidă ce ar trebui păstrat.

Deasupra acestei baze, antrenăm un cap de compresie ușor care prezice ce părți ale contextului ar trebui păstrate. Deoarece nu este implicată nicio generare, aceste predicții sunt realizate în paralel pe întregul context. În momentul deservirii, motorul de fragmente agregă aceste predicții la nivel de propoziție, aplică un prag și trunchiază rezultatul pentru a se încadra în bugetul de tokenuri solicitat.

Conducta de supervizare

Antrenarea acestui compresor necesită supervizare la nivelul corect de granulație. O etichetă de relevanță la nivelul documentului este în mod evident nepotrivită pentru sarcina noastră de compresie extractivă. Pentru a genera date suficient de granulare pentru învățarea supervizată, am construit o conductă de etichetare a segmentelor care marchează segmentele de dovezi relevante pentru interogare, împreună cu segmentele perturbatoare care ar trebui eliminate.

Conducta noastră folosește o configurare LLM-ca-judecător (LLM-as-a-judge). Având o interogare a utilizatorului și o pagină web candidată cu linkul, titlul și rezumatul său, judecătorul efectuează mai întâi înțelegerea interogării, analizând-o și generând o listă de posibile intenții ale utilizatorului. Bazându-se pe aceste intenții, judecătorul procesează apoi contextul candidat și returnează segmente copiate verbatim din text, cu o categorie pentru fiecare segment, pentru a face etichetele mai ușor de inspectat.

Am potrivit apoi segmentele returnate înapoi cu textul sursă. Nu este surprinzător faptul că majoritatea ieșirilor judecătorului erau deja copii exacte: potrivirea simplă de șiruri a recuperat 98% din segmente. Adăugarea unei etape simple de potrivire bazată pe expresii regulate (regex) a adus recuperarea segmentelor la 100%. Acest lucru ne-a oferit segmente fiabile și granulare care au putut fi convertite într-o supervizare de tip păstrare/eliminare (keep/drop) la nivel de token.

Am evaluat această conductă de supervizare folosind un mic set de date curatoriat cu segmente etichetate manual, comparând modele de judecători mai mici, diferite prompturi și diferite configurații de pași. Cea mai performantă configurare a fost o conductă în două etape: mai întâi înțelegerea interogării, urmată de etichetarea segmentelor pe categorii. De asemenea, am validat setul de segmente extrase prin evaluări verificabile în aval, cum ar fi BrowseComp și SimpleQA, unde utilizarea exclusivă a segmentelor de dovezi păstrate a menținut scoruri puternice, reducând în același timp semnificativ tokenurile de intrare.

Folosind această conductă, am etichetat 750 de mii de perechi interogare-document și am folosit segmentele rezultate pentru a antrena capul de compresie cu entropie încrucișată binară. Acest proces permite modelului nostru de compresie conștient de interogare să păstreze textul sursă intact, eliminând în același timp contextul care are puține șanse să ajute modelul din aval să servească solicitarea utilizatorului.

Asigurarea latenței în timp real

Compresia contextului se situează înaintea modelului din aval, făcând-o o operațiune blocantă. În plus, fiecare compresie depinde de interogare. Prin urmare, calea online trebuie să evalueze (score) perechile interogare-context pentru fiecare document candidat într-o limită strictă de latență. Un model de compresie lent se autodistruge, deoarece beneficiile de latență aduse de o precizie mai mare sunt anulate de însăși latența compresiei. În același timp, un model de compresie mai puțin inteligent va lua decizii mai slabe cu privire la ce anume trebuie tăiat și reținut.

Întrebarea practică este cât la sută din capacitatea modelului putem elimina în siguranță înainte ca performanța compresiei să înceapă să se degradeze. Comparăm baza de 28 de straturi pplx-diffusion cu variante de 11 straturi și de 17 straturi obținute prin eliminarea de straturi (layer pruning) și orientate către calea de căutare. Pentru fiecare dintre acestea, analizăm pragul de compresie și măsurăm două cantități: numărul mediu de tokenuri de context trimise în aval per interogare și fracțiunea de dovezi utile păstrate după compresie.

Figura 2 arată frontiera calitate-eficiență. Un model este mai bun atunci când se deplasează spre stânga sus: mai puține tokenuri în aval cu mai multe dovezi utile păstrate. Modelul cu 28 de straturi oferă referința de calitate. Modelul cu 11 straturi demonstrează riscurile comprimării prea agresive a modelului. Modelul redus cu 17 straturi reprezintă o cale de mijloc: urmărește îndeaproape modelul cu 28 de straturi în regimul saturat, dar apare o mică diferență în porțiunea abruptă a curbei unde operează cea mai mare parte a traficului de producție.

Pentru a acoperi această diferență, folosim distilarea cunoștințelor la nivel de token (token-level knowledge distillation). Abordarea noastră este standard: augmentăm funcția de pierdere (loss) obișnuită cu un termen de entropie încrucișată slabă (soft cross-entropy) bazat pe predicțiile modelului profesor, ponderat printr-un coeficient de distilare. Acest lucru este suficient pentru a aduce modelul student la paritate, permițându-ne să trecem complet la modelul distilat de 17 straturi în producție. Acest nou model de producție aduce o scădere de 35-40% a latenței de inferență și o scădere de 40-45% a calculului GPU agregat, fără nicio scădere a calității în comparație cu profesorul de 28 de straturi. Latența în producție se situează sub 20 ms (p99): suficient de mică pentru a fi adăugată pe calea de servire, reducând în același timp considerabil totalul tokenurilor transmise modelului de răspuns.

Extinde

Calitatea și eficiența tokenurilor

Agent API de la Perplexity este utilizat drept mediu de testare pentru a analiza eficacitatea compresiei de context. Evaluăm trei presetări ale Agent API:

O presetare de context „redusă” (low), care limitează bugetul de tokenuri pentru fiecare set de rezultate la 1.000 de tokenuri.

O presetare de context „medie” (medium), care limitează bugetul de tokenuri pentru fiecare set de rezultate la 4.000 de tokenuri.

O presetare de context „ridicată” (high), care limitează bugetul de tokenuri pentru fiecare set de rezultate la 10.000 de tokenuri.

Atât setările standard, fără compresie, cât și cele cu compresie sunt configurate să respecte aceste bugete de tokenuri.

Căutare autonomă în mai mulți pași (BrowseComp)

Examinăm mai întâi impactul compresiei asupra fluxurilor de lucru de căutare autonomă în mai mulți pași pe benchmarkul BrowseComp. Efectuăm această evaluare utilizând instrumentul nostru open-source search_evals. Notarea este identică pentru toate rulările, utilizând promptul canonic al judecătorului LLM BrowseComp de la OpenAI.

Cele două dimensiuni de interes sunt acuratețea benchmarkului și utilizarea tokenurilor. Important este că măsurăm utilizarea tokenurilor la nivel de interogare, și nu la nivelul fiecărui pas în parte, pentru a evalua sarcina efectivă de tokenuri generată de-a lungul ciclului de viață al cererii. Figura 3 prezintă frontiera „scor-token”, reprezentând scorul de acuratețe în raport cu utilizarea tokenurilor.

Extinde

Compresia oferă o nouă frontieră Pareto pe toată linia. Pentru fiecare setare, introducerea compresiei reduce utilizarea tokenurilor la nivel de interogare cu procente cuprinse între 10% și 70%, obținându-se totodată creșteri ale acurateții cu între 4 și 4,81 puncte procentuale. Introducerea compresiei permite chiar și presetării noastre „reduse” să depășească performanța presetării „ridicate” fără compresie, reducând în același timp utilizarea tokenurilor de peste trei ori.

Observăm că, în condițiile utilizării compresiei, setarea „ridicată” generează o acuratețe mai mare decât cea „medie”, așa cum era de așteptat. Interesant este însă că acest lucru se realizează cu un consum mai redus de tokenuri. Acest fenomen relevă un efect subtil, dar important al compresiei: atunci când se folosește compresia, chiar și mărirea dimensiunii contextului per pas poate permite modelului să efectueze mai puțini pași pentru a ajunge la rezultatul corect. Investigarea acestei non-monotonii reprezintă o direcție promițătoare pentru cercetările viitoare.

SimpleQA: factualitate într-un singur pas

BrowseComp pune accentul pe cercetarea în mai mulți pași, însă multe fluxuri de lucru de producție implică o căutare factuală într-un singur pas. Pentru a stabili dacă compresia ajută și în regimul cu un singur pas, analizăm și performanța pe SimpleQA, un benchmark care cuprinde 4.326 de întrebări la care trebuie să se răspundă într-un singur pas de căutare, și nu printr-o buclă de tip agent.

Ca și până acum, reprezentăm grafic acuratețea în raport cu media totală a tokenurilor per sarcină, utilizând promptul canonic al judecătorului. Figura 4 arată frontiera scor-token în acest scenariu cu un singur pas. Deși dimensiunile efectelor sunt mai comprimate în acest scenariu, observăm din nou că compresia îmbunătățește simultan acuratețea și eficiența pentru toate presetările, introducând astfel o nouă frontieră Pareto. Cu compresia activată, presetarea medie atinge o acuratețe de 95% cu o medie de numai 200 de tokenuri per document. Având în vedere că lungimea medie a documentului depășește 10.000 de tokenuri, acest lucru reprezintă o performanță de nivel de frontieră la o rată de compresie de peste 50.

Extinde

Ce ajunge în fragmente?

Câștigurile obținute în aval în secțiunile 4.1 și 4.2 sunt end-to-end. Pentru a înțelege cum modifică compresia fragmentele individuale, efectuăm o evaluare separată care utilizează un judecător LLM pentru a clasifica fiecare token din fiecare fragment regăsit în una dintre cele șase categorii:

Vitale (Vital): dovezi esențiale pentru a răspunde la întrebarea utilizatorului.

Fără legătură cu subiectul (Off-topic): informații care pot fi utile în alte scopuri, dar care nu au legătură cu interogarea în cauză.

Reclame (Ads): publicitate irelevantă care distrage atenția de la răspunsul la întrebarea utilizatorului.

Metadate (Metadata): metadate despre conținutul documentului.

Interfață de utilizator și navigare (UI & navigation): elemente pentru afișarea în interfața grafică și navigare.

Duplicate (Duplicate): repetarea unor informații încorporate anterior.

Evaluarea noastră rulează pe 1.000 de interogări din domenii mixte din setul nostru de validare, comparând stiva de producție cu o linie de bază (baseline) altfel identică, dar cu compresia dezactivată. După cum se arată în Figura 5, compresia crește proporția de tokenuri vitale per fragment cu o medie de 63% față de linia de bază fără compresie. Observăm o scădere corespunzătoare de 29% a tokenurilor irelevante, cu scăderi deosebit de pronunțate în secțiunea de interfață/navigare (-58%), metadate (-46%) și reclame (-43%). Aceste rezultate confirmă mecanismul din spatele îmbunătățirilor calității și eficienței discutate mai sus: compresia îmbunătățește performanța în ambele dimensiuni prin creșterea accentuată a raportului semnal-zgomot pentru fiecare fragment individual.

Extinde

Figura 6 ilustrează această modificare pentru o interogare individuală. Pentru interogarea „6 day old newborn milk intake per feeding” (aportul de lapte al unui nou-născut de 6 zile la o masă), prezentăm atât fragmentele necomprimate (linia de bază), cât și pe cele comprimate. Compresia elimină categoriile de conținut ne-vital și păstrează doar informațiile despre hrănirea nou-născutului. Important este că compresia elimină cu succes conținutul care poate fi în general relevant pentru pagină, dar irelevant pentru această interogare specifică axată pe nou-născuți.

Extinde

Concluzie

Sistemele AI se bazează pe informații cu un semnal puternic pentru a răspunde inteligent și eficient la solicitările utilizatorilor. Aceste informații trebuie prezentate cât mai chirurgical posibil pentru a maximiza relevanța pentru fiecare interogare. Noile noastre modele de compresie conștiente de interogare fac exact acest lucru, maximizând dovezile relevante pentru subiect per fragment și eliminând agresiv elementele perturbatoare irelevante.

Prin implementarea acestor noi modele în stiva noastră de căutare, reușim să oferim răspunsuri mai rapide și mai bune celor care se bazează pe produsele și API-urile noastre. Abordarea noastră creează o suprafață de control simplă, permițând sistemelor noastre și clienților API să ajusteze gradul de compresie pentru a echilibra recuperarea (recall), latența și costul.

Curatarea contextului este un domeniu în plină dezvoltare și mai sunt multe de făcut pentru a optimiza valoarea fiecărui token utilizat în sistemele de inteligență artificială de frontieră de astăzi. Lucrăm activ pentru a îmbunătăți și mai mult tehnicile noastre de curatare a contextului, atât prin optimizări ale modelelor, cât și prin arhitectura sistemului, pentru a face o utilizare și mai extinsă a acestor modele.

Referințe

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

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

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

Citare

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