Kompresia kontextu citlivá na dopyt pre lepšie úryvky

Každá odpoveď sa začína dôkazmi. Vo vyhľadávacom systéme tieto dôkazy zvyčajne pochádzajú z dokumentov: názvov, zhrnutí, blokov a úryvkov, ktoré sa odovzdávajú ako kontext modelu odpovedí alebo agentovi.

Tento surový kontext je zašumený. Webová stránka môže napríklad obsahovať informácie potrebné pre požiadavku používateľa, ale môže obsahovať aj rušivé prvky. Tieto rušivé prvky sa môžu objaviť tak v hlavnom texte, ako aj v pomocných prvkoch, akými sú navigačné textové prvky, irelevantné reklamy, metadáta a ďalšie. Odovzdávanie týchto rušivých prvkov následnému agentovi vytvára tri problémy.

Po prvé, znižuje to presnosť. Aj tie najvýkonnejšie modely majú obmedzenú kapacitu. Dlhé prúdy irelevantných informácií plytvajú kapacitou modelu, čoho výsledkom je „kontextová hniloba“, ktorá zhoršuje schopnosť modelu riešiť skutočnú požiadavku používateľa. V dôsledku toho konečná odpoveď pravdepodobne vynechá kľúčové fakty, pripíše príliš veľkú váhu menej kvalitným informáciám alebo prinesie tvrdenia, ktoré sa ťažšie opierajú o zdroj.

Po druhé, zhoršuje to latenciu. Dlhší kontext znamená viac tokenov na spracovanie pre následný model, najmä keď dopyt potrebuje dôkazy z mnohých kandidátskych stránok. Hoci časť týchto nákladov na latenciu vzniká v štádiu predbežného vyplnenia (prefill), oveľa významnejšie náklady sa platia pri uvažovaní (reasoning), pričom modely vyžadujú viac tokenov uvažovania na prácu s irelevantným kontextom.

Po tretie, zvyšuje to náklady. Každý zbytočný token odovzdaný modelu predražuje obsluhu požiadavky používateľa, pretože so šumovejším kontextom rastie spotreba vstupných tokenov aj tokenov uvažovania. Rušivé prvky neznižujú len kvalitu – nakoniec vás nútia platiť viac za túto horšiu kvalitu.

Zväčšiť

Aby sme súčasne zvýšili presnosť, rýchlosť a nákladovú efektivitu v rámci aplikácií Perplexity a platformy API Platform, veľa investujeme do zlepšovania presnosti kontextu. Jedným zo spôsobov, ako to dosahujeme, je zdokonaľovanie našich algoritmov na generovanie úryvkov. Generovanie úryvkov chápeme ako problém kompresie kontextu. Modely hľadajúce konkrétne informácie nemajú úžitok zo všeobecných zhrnutí alebo výňatkov z dokumentu. Namiesto toho potrebujú čo najmenšiu, čo najchirurgickejšie extrahovanú časť zdrojových informácií, aby mohli reagovať na požiadavku používateľa. Všetko ostatné môže a musí byť odstránené.

Dobrý úryvok by preto mal robiť tri veci:

Zvyšovať presnosť poskytovaním presných dôkazov potrebných na podloženie odpovede modelu.

Znižovať latenciu a náklady odstránením irelevantného kontextu pred volaním LLM.

Zabezpečovať sledovateľnosť zachovaním vernosti citácií a ponechaním pôvodného znenia zdroja.

Tento mesiac sme v našich aplikáciách a platforme API Platform nasadili nový špičkový generátor úryvkov. Jadrom tohto modulu je model kompresie kontextu citlivý na dopyt, ktorý pre každý dopyt a kandidátsky výsledok rozhoduje o tom, ktorá podnož úsekov sa má zachovať. Tento článok popisuje náš prístup k vytvoreniu a trénovaniu modelu na dosiahnutie najlepšieho výkonu vo svojej triede pri tejto kritickej úlohe.

Úryvky ako kompresia citlivá na dopyt

Prvou úlohou je definovať samotnú úlohu. Čo chceme, aby tento model robil, a ako by sme mali definovať vstupnú a výstupnú schému?

Metódy úryvkov patria do dvoch širokých rodín. Prvou je výber (selection-based): nájsť relevantné okno, blok, vetu alebo pasáž a odovzdať ju ďalej. Druhou je generovanie (generation-based): požiadať model, aby zo stránky napísal zhrnutie zamerané na dopyt.

Náš dôraz na presnosť, latenciu a náklady robí toto rozhodnutie o dizajne jasným. Generovanie môžeme vylúčiť, pretože vytvorenie nového zhrnutia pre každú stránku zhoršuje výkon vo všetkých troch oblastiach. Tvorba zhrnutí sa nehodí pre vrstvu dôkazov, na ktorej nám záleží. Môže parafrázovať zdroj, čo sťažuje zosúladenie citácií. Môže tiež zaviesť znenie, ktoré na stránke nebolo prítomné, čo je riskantné, keď sa úryvok používa ako dôkaz namiesto konečnej odpovede. Zapojená latencia a náklady robia generovanie ešte neprijateľnejším.

Našu úlohu definujeme radšej ako extraktívnu kompresiu citlivú na dopyt: oddeľovanie užitočných častí získaného kontextu od rušivých častí. Náš model musí konkrétne prijať dopyt a kandidátsky výsledok a rozhodnúť, ktoré úseky zachovať – tie, ktoré najlepšie podporujú dopyt – a ktoré zahodiť, teda zvyšok. Výstup modelu zachováva zdrojový text namiesto jeho prepisovania. Vďaka tomu je výsledok jednoduchší na citovanie, jednoduchší na overenie a lacnejší na odovzdanie ďalej.

Zvážte napríklad tento dopyt a získaný výsledok:

Zväčšiť

Pozoruhodným výstupom modelu by bolo vybratie tučným písmom zvýraznenej vety: „V systéme Comet môže asistent...“.

Náš prístup sa riadi rovnakou všeobecnou myšlienkou ako predchádzajúca práca v oblasti kompresie kontextu, ako sú FliCo, Provence a LooComp, prispôsobenou na generovanie úryvkov v produkčnom vyhľadávacom systéme. Je dôležité poznamenať, že model funguje ako fáza presnosti po našej fáze surového získavania údajov. Ako sa diskutovalo v našom predchádzajúcom článku z výskumu Perplexity Predstavujeme Perplexity Search API, naše systémy vyhľadávania navrhujeme tak, aby fungovali natívne na úrovni poddokumentov alebo úryvkov, čo nám už teraz umožňuje celkom dobre vyvážiť presnosť a úplnosť (recall). Zavádzanie modelu kompresie kontextu citlivého na dopyt posúva Paretovu hranicu presnosti a úplnosti ešte ďalej smerom von.

Budovanie a trénovanie modelu kompresie kontextu

Náš model vyvíjame s ohľadom na tri hlavné hľadiská: spoločné pochopenie dopytu a kontextu, jemne granulárny výber na úrovni viet a efektivita, aby sa zmestil do extrémne tesného rozpočtu na latenciu.

Architektúra modelu

Ako základ (backbone) používame model pplx-diffusion. Ide o rovnakú rodinu modelov, aká stojí za pplx-embed-v1, pričom naša predchádzajúca akademická práca Diffusion-Pretrained Dense and Contextual Embeddings aj naše produkčné benchmarky potvrdzujú, že ide o silný obojsmerný enkóder pre páry dopyt-kontext. Jednou z kľúčových vlastností tejto rodiny modelov je obojsmerný kontext: každá reprezentácia tokenu môže brať do úvahy celý dopyt a celý kandidátsky kontext predtým, ako sa model rozhodne, čo sa má zachovať.

Na tento základ trénujeme ľahkú kompresnú hlavu (compression head), ktorá predikuje, ktoré časti kontextu by sa mali zachovať. Keďže tu neprebieha žiadne generovanie, tieto predikcie sa robia paralelne v celom kontexte. V čase obsluhy zhrňovač úryvkov (snippet engine) agreguje tieto predikcie na úrovni viet, aplikuje prah (threshold) a orezáva výsledok na požadovaný rozpočet tokenov.

Potrubie dohľadu (Supervision pipeline)

Trénovanie tohto kompresora si vyžaduje dohľad na správnej úrovni granularity. Značka relevance na úrovni dokumentov sa pre našu úlohu extraktívnej kompresie zjavne nehodí. Na generovanie dostatočne podrobných údajov pre supervidované učenie sme vytvorili potrubie označovania úsekov (span labeling pipeline), ktoré označuje úseky dôkazov relevantné pre dopyt spolu s rušivými úsekmi, ktoré by sa mali odstrániť.

Naše potrubie využíva nastavenie LLM-as-a-judge (LLM ako rozhodca). Vzhľadom na dopyt používateľa a kandidátsku webovú stránku s jej odkazom, názvom a zhrnutím rozhodca najprv vykoná pochopenie dopytu, pričom analýzou dopytu vytvorí zoznam možných zámerov používateľa. S ukotvením v týchto zámeroch rozhodca následne spracuje kandidátsky kontext a vráti úseky skopírované doslovne z textu spolu s kategóriou pre každý úsek, aby sa štítky dali ľahšie skontrolovať.

Vrátené úseky sme potom priradili späť k zdrojovému textu. Nie je prekvapením, že väčšina výstupov od rozhodcu bola už presnými kópiami: naivné porovnávanie reťazcov obnovilo 98 % úsekov. Pridanie jednoduchého porovnávania založeného na regulárnych výrazoch posunulo obnovu úsekov na 100 %. To nám poskytlo spoľahlivé, podrobné úseky, ktoré bolo možné konvertovať na dohľad nad zachovaním/zahodením (keep/drop) na úrovni tokenov.

Toto potrubie dohľadu sme vyhodnotili pomocou malej kurátorovanej množiny údajov s manuálne označenými úsekmi, pričom sme porovnávali menšie modely rozhodcov, rôzne výzvy (prompts) a rôzne konfigurácie krokov. Najvýkonnejším nastavením bolo dvojfázové potrubie: najprv pochopenie dopytu, po ktorom nasledovalo kategorizované označovanie úsekov. Súpravu extrahovaných úsekov sme overili aj prostredníctvom následných overiteľných vyhodnotení, ako sú BrowseComp a SimpleQA, kde použitie iba zachovaných úsekov dôkazov zachovalo silné skóre a zároveň výrazne znížilo počet vstupných tokenov.

Pomocou tohto potrubia sme označili 750 tisíc párov dopyt-dokument a výsledné úseky používame na trénovanie kompresnej hlavy pomocou binárnej krížovej entropie. Tento proces umožňuje nášmu modelu kompresie citlivému na dopyt ponechať zdrojový text nedotknutý a zároveň odstrániť kontext, ktorý pravdepodobne nepomôže následnému modelu obslúžiť požiadavku používateľa.

Zabezpečenie latencie v reálnom čase

Kompresia kontextu sa nachádza pred následným modelom, čo z nej robí blokujúcu operáciu. Navyše, každá kompresia závisí od dopytu. Online cesta preto musí ohodnotiť páry dopyt-kontext pre každý kandidátsky dokument v rámci prísneho obmedzenia latencie. Pomalý model kompresie je kontraproduktívny, pretože výhody latencie plynúce z vyššej presnosti sú zmazané samotnou latenciou kompresie. Menej inteligentný model kompresie zároveň urobí horšie rozhodnutia o tom, čo vystrihnúť a čo ponechať.

Praktickou otázkou je, koľko z kapacity modelu môžeme bezpečne odstrániť predtým, ako sa začne zhoršovať kvalita kompresie. Porovnávame plný 28-vrstvový základ pplx-diffusion s 11-vrstvovými a 17-vrstvovými variantmi vytvorenými orezávaním vrstiev (layer pruning) zameraným na vyhľadávaciu cestu. Pre každý z nich prechádzame prahom kompresie a meriame dve veličiny: priemerný počet kontextových tokenov odoslaných následne na jeden dopyt a podiel užitočných dôkazov zachovaných po kompresii.

Obrázok 2 zobrazuje hranicu kvality a efektivity. Model je lepší, keď sa posúva smerom nahor doľava: menej následných tokenov s viacerými zachovanými užitočnými dôkazmi. 28-vrstvový model poskytuje referenciu kvality. 11-vrstvový model demonštruje riziká príliš agresívnej kompresie modelu. Orezaný 17-vrstvový model predstavuje strednú cestu: tesne kopíruje 28-vrstvový model v saturovanom režime, ale malá medzera sa otvára v strmej časti krivky, kde funguje väčšina produkčnej prevádzky.

Na zacelenie tejto medzery používame distiláciu vedomostí na úrovni tokenov (token-level knowledge distillation). Náš prístup je bežný: rozširujeme štandardnú stratu o termín mäkkej krížovej entropie (soft cross-entropy term) na predikciách učiteľského modelu, vážený koeficientom distilácie. To stačí na to, aby sa model študenta dostal na úroveň učiteľa, čo nám umožňuje plne prejsť na distilovaný 17-vrstvový model v produkcii. Tento nový produkčný model prináša 35–40 % pokles latencie inferencie a 40–45 % pokles celkového výpočtu GPU bez poklesu kvality v porovnaní s 28-vrstvovým učiteľom. Produkčná latencia dosahuje menej ako 20 ms (p99): dostatočne málo na pridanie do obslužnej cesty a zároveň výrazné zníženie celkového počtu tokenov odovzdaných modelu odpovedí.

Zväčšiť

Kvalita a efektivita tokenov

Na analýzu efektívnosti kompresie kontextu používame Agent API od Perplexity ako testovacie prostredie. Vyhodnocujeme tri predvoľby Agent API:

„Nízka“ (low) kontextová predvoľba, ktorá obmedzuje rozpočet tokenov pre každú množinu výsledkov na 1 000 tokenov.

„Stredná“ (medium) kontextová predvoľba, ktorá obmedzuje rozpočet tokenov pre každú množinu výsledkov na 4 000 tokenov.

„Vysoká“ (high) kontextová predvoľba, ktorá obmedzuje rozpočet tokenov pre každú množinu výsledkov na 10 000 tokenov.

Štandardné nastavenie bez kompresie aj nastavenia s kompresiou sú konfigurované tak, aby rešpektovali tieto rozpočty tokenov.

Viacsmerové vyhľadávanie agentov (BrowseComp)

Najprv skúmame vplyv kompresie na pracovné postupy (workflows) viacsmerového vyhľadávania agentov v benchmarku BrowseComp. Toto vyhodnotenie vykonávame pomocou nášho open-source nástroja search_evals. Hodnotenie je vo všetkých behoch identické, pričom sa používa kanonická výzva rozhodcu BrowseComp LLM judge prompt od OpenAI.

Dve dimenzie záujmu sú presnosť benchmarku a využitie tokenov. Dôležité je, že využitie tokenov meriame na úrovni dopytu, a nie na úrovni jednotlivých krokov, aby sme zmerali skutočnú záťaž tokenov vznikajúcu počas životného cyklu požiadavky. Obrázok 3 ukazuje hranicu „skóre-token“, teda skóre presnosti vs. využitie tokenov.

Zväčšiť

Kompresia prináša novú Paretovu hranicu vo všetkých smeroch. Pre každé nastavenie zavedenie kompresie znižuje využitie tokenov na úrovni dopytu o 10 % až 70 %, pričom zisky v presnosti sa pohybujú medzi 4 a 4,81 percentuálnymi bodmi. Zavedenie kompresie umožňuje dokonca aj našej „nízkej“ predvoľbe prekonať „vysokú“ predvoľbu bez kompresie, a to všetko pri viac ako trojnásobnom znížení využitia tokenov.

Pozorujeme, že s kompresiou prináša „vysoká“ predvoľba väčšiu presnosť ako „stredná“, ako by sme mohli očakávať. Zaujímavé však je, že to dosahuje pri nižšom využití tokenov. To odhaľuje jemný, ale dôležitý účinok kompresie: s kompresiou môže dokonca aj zväčšenie veľkosti kontextu na jeden krok umožniť modelu vykonať menej krokov na dosiahnutie správneho výsledku. Preskúmanie tejto nelinearity (non-monotonicity) je sľubným smerom pre budúcu prácu.

SimpleQA: jednokroková faktografickosť

BrowseComp kladie dôraz na viacsmerový výskum, no mnohé produkčné pracovné postupy (workflows) zahŕňajú jednokrokove vyhľadávanie faktov. Aby sme zistili, či kompresia pomáha aj v jednokrokovom režime, skúmame aj výkon v benchmarku SimpleQA, ktorý obsahuje 4 326 otázok, na ktoré treba odpovedať v jedinom kroku vyhľadávania namiesto slučky agenta.

Tak ako predtým, vynášame presnosť oproti priemernému celkovému počtu tokenov na úlohu pomocou kanonickej výzvy rozhodcu. Obrázok 4 ukazuje hranicu skóre-token v tomto jednokrokovom nastavení. Hoci veľkosti efektov sú v jednokrokovom nastavení stlačenejšie, opäť pozorujeme, že kompresia súčasne zlepšuje presnosť a efektivitu vo všetkých predvoľbách, čím zavádza novú Paretovu hranicu. S povolenou kompresiou dosahuje stredná predvoľba 95 % presnosť s priemerom iba 200 tokenov na dokument. Vzhľadom na priemernú dĺžku dokumentu presahujúcu 10 000 tokenov to predstavuje výkon na špičkovej úrovni pri kompresnom pomere väčšom ako 50.

Zväčšiť

Čo nakoniec skončí v úryvkoch?

Následné prírastky v častiach 4.1 a 4.2 sú typu end-to-end. Aby sme pochopili, ako kompresia mení jednotlivé úryvky, spúšťame samostatné vyhodnotenie, ktoré využíva rozhodcu LLM na klasifikáciu každého tokenu každého získaného úryvku do jednej zo šiestich kategórií:

Kľúčové (Vital): dôkazy nevyhnutné na zodpovedanie požiadavky používateľa.

Mimo témy (Off-topic): informácie, ktoré môžu byť užitočné na iný účel, ale netýkajú sa aktuálneho dopytu.

Reklamy (Ads): irelevantná inzercia, ktorá odvádza pozornosť od zodpovedania požiadavky používateľa.

Metadáta (Metadata): metadáta o obsahu dokumentu.

UI & navigácia (UI & navigation): prvky pre zobrazenie vo frontendovej časti a navigáciu.

Duplikát (Duplicate): opakovanie predtým začlenených informácií.

Naše vyhodnotenie prebieha na 1 000 dopytoch zmiešaných domén z našej validačnej množiny, pričom porovnáva produkčný zásobník (stack) s inak identickým základným variantom (baseline) s vypnutou kompresiou. Ako ukazuje obrázok 5, kompresia zvyšuje podiel kľúčových tokenov na úryvok v priemere o 63 % v porovnaní so základným variantom bez kompresie. Pozorujeme zodpovedajúci pokles o 29 % u irelevantných tokenov, pričom obzvlášť strmé poklesy nastávajú pri UI/navigácii (-58 %), metadátach (-46 %) a reklamách (-43 %). Tieto výsledky potvrdzujú mechanizmus vyššie spomínaných vylepšení kvality a efektivity: kompresia zlepšuje výkon v oboch dimenziách prudkým zvýšením pomeru signálu k šumu každého jednotlivého úryvku.

Zväčšiť

Obrázok 6 ilustruje túto zmenu pre jednotlivý dopyt. Pre dopyt „príjem mlieka 6-dňového novorodenca na jedno kŕmenie“ ukazujeme nestlačené úryvky zo základného variantu aj stlačené úryvky. Kompresia eliminuje kategórie nekľúčového obsahu a zachováva iba informácie o kŕmení súvisiace s novorodencom. Dôležité je, že kompresia úspešne odstraňuje obsah, ktorý môže byť všeobecne relevantný pre danú stránku, ale je mimo témy pre tento konkrétny dopyt zameraný na novorodenca.

Zväčšiť

Záver

Systémy umelej inteligencie sa spoliehajú na informácie s vysokým signálom, aby inteligentne a efektívne obsluhovali požiadavky používateľov. Tieto informácie musia byť prezentované čo najchirurgickejšie, aby sa maximalizovala relevancia pre každú požiadavku. Naše nové modely kompresie citlivé na dopyt robia presne toto – maximalizujú dôkazy k téme na jeden úryvok a agresívne odstraňujú irelevantné rušivé prvky.

Nasadením týchto nových modelov v našom vyhľadávacom zásobníku dokážeme poskytovať rýchlejšie a lepšie odpovede tým, ktorí sa spoliehajú na naše produkty a rozhrania API. Náš prístup vytvára jednoduché riadiace rozhranie, ktoré našim systémom a zákazníkom API umožňuje ladiť stupeň kompresie na dosiahnutie rovnováhy medzi úplnosťou (recall), latenciou a nákladmi.

Kurátorstvo kontextu je rozvíjajúcou sa oblasťou a je toho ešte veľa, čo treba urobit na optimalizáciu hodnoty každého tokenu použitého v dnešných špičkových spravodajských systémoch. Aktívne pracujeme na tom, aby boli naše techniky kurátorstva kontextu ešte lepšie, a to prostredníctvom vylepšení modelov aj systémovej architektúry, čo umožní ešte rozsiahlejšie využívanie týchto modelov.

Referencie

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

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

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

Citácia

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