Komprese kontextu zohledňující dotaz pro lepší úryvky

Každá odpověď začíná důkazy. Ve vyhledávacím systému tyto důkazy obvykle pocházejí z dokumentů: nadpisů, shrnutí, úseků a úryvků, které jsou předávány jako kontext modelu odpovědí nebo agentovi.

Tento surový kontext je zašuměný. Webová stránka může například obsahovat informace potřebné pro požadavek uživatele, ale může obsahovat i rušivé prvky. Tyto rušivé prvky se mohou objevovat jak v hlavní části, tak v doplňkových prvcích, jako jsou textové prvky navigace, irelevantní reklamy, metadata a další. Předávání těchto rušivých prvků následnému agentovi přináší tři problémy.

Za prvé, škodí to přesnosti. I ty nejvýkonnější modely mají omezenou kapacitu. Dlouhé proudy irelevantních informací plýtvají kapacitou modelu, což vede k „degradaci kontextu“ (context rot), která narušuje schopnost modelu reagovat na skutečný požadavek uživatele. V důsledku toho konečná odpověď s větší pravděpodobností vynechá klíčová fakta, přecení nízkokvalitní informace nebo vytvoří tvrzení, která lze v zdroji jen těžko podložit.

Za druhé, zhoršuje to latenci. Delší kontext znamená více tokenů, které musí následný model zpracovat, zejména když dotaz vyžaduje důkazy z mnoha kandidátských stránek. Ačkoli část těchto nákladů na latenci nese fáze předvyplnění (prefill), mnohem významnější náklady jsou placeny v oblasti uvažování, kdy modely vyžadují více tokenů uvažování k vypořádání se s irelevantním kontextem.

Za třetí, zvyšuje to náklady. Každý zbytečný token předaný modelu prodražuje vyřízení požadavku uživatele, protože se se zašuměnějším kontextem zvyšuje využití vstupních tokenů i tokenů uvažování. Rušivé prvky nesnižují pouze kvalitu; nakonec vás nutí platit více za tuto horší kvalitu.

Zvětšit

Abychom současně zvýšili přesnost, rychlost a nákladovou efektivitu napříč aplikacemi Perplexity a API Platform, masivně investujeme do zlepšování přesnosti kontextu. Jedním ze způsobů, jak toho dosahujeme, je zdokonalování našich algoritmů pro generování úryvků. Generování úryvků chápeme jako problém komprese kontextu. Modely hledající specifické informace nemají prospěch z generalizovaných shrnutí nebo výňatků z dokumentu. Místo toho potřebují co nejmenší, chirurgicky přesně extrahovanou část zdrojové informace, aby mohly reagovat na požadavek uživatele. Vše ostatní lze a musí být odstraněno.

Dobrý úryvek by proto měl plnit tři úkoly:

Podpořit přesnost tím, že prezentuje přesné důkazy potřebné k podložení odpovědi modelu.

Snížit latenci a náklady odstraněním irelevantního kontextu před voláním LLM.

Zajistit dohledatelnost zachováním věrnosti citací a zachováním původního znění zdrojového textu.

Tento měsíc jsme v našich aplikacích a na API Platform nasadili nový, špičkový generátor úryvků. Jádrem tohoto modulu je model komprese kontextu zohledňující dotaz, který pro každý dotaz a kandidátský výsledek rozhoduje o tom, které podřetězce (spans) by měly být zachovány. Tento článek popisuje náš přístup k sestavení a trénování modelu tak, aby dosahoval špičkového výkonu v tomto kritickém úkolu.

Úryvky jako komprese zohledňující dotaz

Prvním úkolem je definovat samotný úkol. Co od tohoto modelu chceme a jak bychom měli definovat vstupní a výstupní schéma?

Metody úryvků spadají do dvou širokých rodin. První je založena na výběru: najít relevantní okno, úsek, větu nebo pasáž a předat ji dále. Druhá je založena na generování: požádat model, aby ze stránky napsal shrnutí zaměřené na dotaz.

Náš důraz na přesnost, latenci a náklady činí architektonické rozhodnutí jasným. Generování můžeme vyloučit, protože vytváření nového shrnutí pro každou stránku zhoršuje výkon ve všech třech sledovaných oblastech. Shrnutí se nehodí pro vrstvu důkazů, na které nám záleží. Může parafrázovat zdroj, což ztěžuje zarovnání citací. Může také zavést znění, které na stránce nebylo přítomno, což je riskantní, když je úryvek používán jako důkaz spíše než jako konečná odpověď. Latence a náklady s tím spojené činí generování ještě méně lákavým.

Spíše náš úkol definujeme jako kontextově uvědomělou extraktivní kompresi: oddělení užitečných částí načteného kontextu od rušivých částí. Konkrétně musí náš model přijmout dotaz a kandidátní výsledek a rozhodnout, které úseky zachovat, tedy ty, které nejlépe podporují dotaz, a které zahodit, tedy zbytek. Výstup modelu zachovává zdrojový text místo jeho přepisování. Díky tomu je výsledek snazší citovat, snazší ověřit a levnější předat dále v rámci následného zpracování.

Zvažte například tento dotaz a získaný výsledek:

Zvětšit

Plausibilním výstupem modelu by byl výběr tučně zvýrazněné věty: „In Comet, the assistant can ...“.

Náš přístup vychází ze stejné obecné myšlenky jako předchozí práce zabývající se kompresí kontextu, jako jsou FliCo, Provence a LooComp, které byly přizpůsobeny pro generování úryvků v produkčním vyhledávacím systému. Důležité je, že model funguje jako fáze zpřesnění po naší fázi surového vyhledávání. Jak jsme diskutovali v našem předchozím článku Perplexity Research Introducing the Perplexity Search API, naše vyhledávací systémy navrhujeme tak, aby fungovaly nativně na úrovni dílčích dokumentů neboli úryvků, což nám již nyní umožňuje docela dobře vyvážit přesnost a úplnost (recall). Zavedení modelu komprese kontextu zohledňujícího dotaz posouvá Paretovu hranici přesnosti a úplnosti ještě dále směrem ven.

Sestavení a trénování modelu komprese kontextu

Náš model vyvíjíme s ohledem na tři hlavní hlediska: společné pochopení dotazu a kontextu, jemnozrnný výběr na úrovni vět a efektivita tak, aby se vešel do extrémně těsného rozpočtu na latenci.

Architektura modelu

Jako páteřní síť používáme model pplx-diffusion. Jedná se o stejnou rodinu modelů, která stojí za pplx-embed-v1, a jak naše předchozí akademická práce Diffusion-Pretrained Dense and Contextual Embeddings, tak naše produkční benchmarky potvrzují, že jde o silný obousměrný enkoder pro dvojice dotaz-kontext. Jednou z klíčových vlastností této rodiny modelů je obousměrný kontext: reprezentace každého tokenu může brát v úvahu úplný dotaz a úplný kandidátský kontext předtím, než se model rozhodne, co by mělo být zachováno.

Na vrcholu této páteřní sítě trénujeme lehkou kompresní hlavu, která předpovídá, které části kontextu by měly být zachovány. Protože zde neprobíhá žádné generování, jsou tyto předpovědi prováděny paralelně v celém kontextu. V době vyřizování požadavků (serving time) agreguje motor pro úryvky tyto předpovědi na úrovni vět, aplikuje prahovou hodnotu a ořízne výsledek na požadovaný rozpočet tokenů.

Dozorová pipelína

Trénování tohoto kompresoru vyžaduje dohled na správné úrovni granularity. Značka relevance na úrovni dokumentu se pro náš úkol extraktivní komprese zjevně nehodí. Pro generování dostatečně granulárních dat pro supervised learning jsme vytvořili pipelínu pro značkování úseků, která označuje úseky důkazů relevantní k dotazu spolu s rušivými úseky, které by měly být odstraněny.

Naše pipelína využívá nastavení typu LLM-as-a-judge (LLM jako rozhodčí). Vzhledem k uživatelskému dotazu a kandidátské webové stránce s jejím odkazem, nadpisem a shrnutím rozhodčí nejprve provede analýzu dotazu, analyzuje dotaz a vytvoří seznam možných uživatelských záměrů. S ukotvením v těchto záměrech pak rozhodčí zpracuje kandidátský kontext a vrátí úseky zkopírované doslova z textu spolu s kategorií pro každý úsek, aby bylo snazší zkontrolovat štítky.

Vrácené úseky jsme pak spárovali zpět se zdrojovým textem. Není překvapivé, že většina výstupů rozhodčího byla již přesnými kopiemi: naivní porovnávání řetězců obnovilo 98 % úseků. Přidání jednoduchého porovnávání založeného na regulárních výrazech zvýšilo úspěšnost obnovy úseků na 100 %. To nám poskytlo spolehlivé, granulární úseky, které bylo možné převést na dohled pro ponechání/vyřazení na úrovni tokenů.

Tuto dozorovou pipelínu jsme vyhodnotili pomocí malé kurátorské datové sady s ručně označenými úseky, přičemž jsme porovnávali menší modely rozhodčích, různé prompty a různé konfigurace kroků. Nejlépe fungující nastavení byla dvoufázová pipelína: nejprve porozumění dotazu, následované kategorizovaným značkováním úseků. Soubor extrahovaných úseků jsme také ověřili prostřednictvím následných ověřitelných vyhodnocení, jako jsou BrowseComp a SimpleQA, kde použití pouze ponechaných úseků důkazů zachovalo silné skóre a zároveň výrazně snížilo počet vstupních tokenů.

Pomocí této pipelíny jsme označili 750 tisíc párů dotaz-dokument a výsledné úseky používáme k trénování kompresní hlavy pomocí binární křížové entropie. Tento proces umožňuje našemu modelu komprese zohledňujícímu dotaz udržet zdrojový text nedotčený a zároveň odstranit kontext, u kterého je nepravděpodobné, že by pomohl následnému modelu vyřídit požadavek uživatele.

Zajištění latence v reálném čase

Komprese kontextu se nachází před následným modelem, což z ní činí blokující operaci. Navíc je každá komprese závislá na dotazu. Proto musí online cesta ohodnotit dvojice dotaz-kontext pro každý kandidátský dokument v rámci náročného limitu latence. Pomalý kompresní model je kontraproduktivní, protože přínosy latence plynoucí z vyšší přesnosti jsou smazány samotnou latencí komprese. Méně inteligentní kompresní model bude zároveň dělat horší rozhodnutí o tom, co vystřihnout a co ponechat.

Praktickou otázkou je, kolik kapacity modelu můžeme bezpečně odebrat, než se začne kvalita komprese zhoršovat. Porovnáváme plnou 28vrstvou páteřní síť pplx-diffusion s 11vrstvými a 17vrstvými variantami vytvořenými prořezáváním vrstev a zaměřenými na vyhledávací cestu. Pro každou z nich procházíme kompresní práh a měříme dvě veličiny: průměrný počet kontextových tokenů odeslaných následně na jeden dotaz a zlomek užitečných důkazů zachovaných po kompresi.

Obrázek 2 ukazuje hranici kvality a efektivity. Model je lepší, když se posouvá směrem k levému hornímu rohu: méně následných tokenů s více zachovanými užitečnými důkazy. 28vrstvý model poskytuje referenční hodnotu kvality. 11vrstvý model demonstruje rizika příliš agresivní komprese modelu. Prořezaný 17vrstvý model představuje zlatou střední cestu: v saturovaném režimu se těsně drží 28vrstvého modelu, ale v prudké části křivky, kde funguje většina produkčního provozu, se otevírá malá mezera.

K zacelení této mezery využíváme distillaci znalostí na úrovni tokenů. Náš přístup je rutinní: standardní ztrátu rozšiřujeme o měkký člen křížové entropie na předpovědích učitelského modelu, vážený koeficientem distillace. To stačí k tomu, aby se studentský model dostal na úroveň učitele, což nám umožňuje plně přejít na distillovaný 17vrstvý model v produkci. Tento nový produkční model přináší 35–40% snížení latence inference a 40–45% snížení celkového výpočetního výkonu GPU bez poklesu kvality oproti 28vrstvému učiteli. Produkční latence se pohybuje pod 20 ms (p99): dostatečně málo na to, aby se dala přidat do obslužné cesty a přitom výrazně snížila celkový počet tokenů předaných modelu odpovědí.

Zvětšit

Kvalita a efektivita tokenů

Jako testovací prostředí pro analýzu efektivity komprese kontextu používáme Agent API od Perplexity. Vyhodnocujeme tři předvolby Agent API:

Kontextová předvolba „low“ (nízká), která omezuje rozpočet tokenů pro každou sadu výsledků na 1000 tokenů.

Kontextová předvolba „medium“ (střední), která omezuje rozpočet tokenů pro každou sadu výsledků na 4000 tokenů.

Kontextová předvolba „high“ (vysoká), která omezuje rozpočet tokenů pro každou sadu výsledků na 10000 tokenů.

Standardní nastavení bez komprese i nastavení s kompresí jsou nakonfigurovány tak, aby tyto rozpočty tokenů respektovaly.

Agentní vícestupňové vyhledávání (BrowseComp)

Nejprve prozkoumáme dopad komprese na agenty řízené vícestupňové vyhledávací pracovní postupy v benchmarku BrowseComp. Toto vyhodnocení provádíme pomocí našeho open-source nástroje search_evals. Hodnocení je napříč všemi běhy identické a využívá kanonický prompt rozhodčího LLM pro BrowseComp od OpenAI.

Dvěma sledovanými dimenzemi jsou přesnost benchmarku a využití tokenů. Důležité je, že využití tokenů měříme na úrovni dotazu, nikoli na úrovni jednotlivých kroků, abychom změřili skutečnou zátěž tokenů vznikající během životního cyklu požadavku. Obrázek 3 ukazuje hranici „skóre-token“, tedy skóre přesnosti oproti využití tokenů.

Zvětšit

Komprese přináší novou Paretovu hranici na všech frontách. Pro každé nastavení snižuje zavedení komprese využití tokenů na úrovni dotazu o 10 % až 70 %, přičemž nárůst přesnosti se pohybuje mezi 4 a 4,81 procentními body. Zavedení komprese umožňuje dokonce i naší „nízké“ předvolbě překonat „vysokou“ předvolbu bez komprese, a to vše při více než trojnásobném snížení spotřeby tokenů.

Zjišťujeme, že s kompresí přináší „vysoká“ předvolba větší přesnost než „střední“, jak bychom mohli očekávat. Zajímavé však je, že tak činí při nižší spotřebě tokenů. To odhaluje nenápadný, ale důležitý efekt komprese: s kompresí může dokonce i zvětšení velikosti kontextu v jednotlivých krocích umožnit modelu podniknout méně kroků k dosažení správného výsledku. Prozkoumání této nelinearity je slibným směrem pro budoucí práci.

SimpleQA: jednostupňová faktualita

BrowseComp klade důraz na vícestupňový průzkum, přesto mnoho produkčních pracovních postupů zahrnuje jednostupňové vyhledávání faktů. Abychom zjistili, zda komprese pomáhá i v jednostupňovém režimu, zkoumáme také výkon v SimpleQA, což je benchmark obsahující 4 326 otázek, na které se odpovídá v jediném kroku vyhledávání namísto agentní smyčky.

Stejně jako dříve vynášíme přesnost oproti průměrnému celkovému počtu tokenů na úlohu za použití kanonického promptu rozhodčího. Obrázek 4 ukazuje hranici skóre-token v tomto jednostupňovém nastavení. Ačkoli jsou velikosti efektů v jednostupňovém nastavení komprimovanější, opět pozorujeme, že komprese současně zlepšuje přesnost i efektivitu napříč všemi předvolbami, čímž zavádí novou Paretovu hranici. S povolenou kompresí dosahuje střední předvolba 95% přesnosti s průměrem pouhých 200 tokenů na dokument. Vzhledem k průměrné délce dokumentu přesahující 10 000 tokenů to představuje výkon na špičkové úrovni s kompresním poměrem více než 50.

Zvětšit

Co nakonec končí v úryvcích?

Následné přínosy v sekcích 4.1 a 4.2 jsou end-to-end. Abychom pochopili, jak komprese mění jednotlivé úryvky, spouštíme samostatné vyhodnocení, které využívá rozhodčího LLM ke klasifikaci každého tokenu každého získaného úryvku do jedné ze šesti kategorií:

Vital (Životně důležité): důkazy nezbytné pro zodpovězení dotazu uživatele.

Off-topic (Mimo téma): informace, které mohou být užitečné pro nějaký jiný účel, ale netýkají se aktuálního dotazu.

Ads (Reklamy): irelevantní reklama, která odvádí pozornost od zodpovězení dotazu uživatele.

Metadata: metadata o obsahu dokumentu.

UI & navigation (UI a navigace): prvky pro zobrazení ve frontendové části a navigaci.

Duplicate (Duplikát): opakování dříve začleněných informací.

Naše vyhodnocení běží na 1 000 dotazech smíšené domény z naší validační sady a porovnává produkční stack s jinak identickým základním stavem (baseline) s vypnutou kompresí. Jak ukazuje obrázek 5, komprese zvyšuje podíl vitálních tokenů na úryvek v průměru o 63 % oproti výchozímu stavu bez komprese. Pozorujeme odpovídající pokles irelevantních tokenů o 29 %, s obzvláště prudkým poklesem v oblasti UI/navigace (-58 %), metadat (-46 %) a reklam (-43 %). Tyto výsledky potvrzují mechanismus výše diskutovaných vylepšení kvality a efektivity: kompresí se zlepšuje výkon v obou dimenzích díky prudkému zvýšení poměru signálu a šumu u každého jednotlivého úryvku.

Zvětšit

Obrázek 6 ilustruje tuto změnu pro konkrétní dotaz. Pro dotaz „6 day old newborn milk intake per feeding“ ukazujeme jak nekomprimované, tak výchozí (baseline) a komprimované úryvky. Komprese eliminuje nevitalní kategorie obsahu a zachovává pouze informace o krmení související s novorozenci. Důležité je, že komprese úspěšně eliminuje obsah, který může být obecně relevantní pro stránku, ale je mimo téma pro tento konkrétní dotaz zaměřený na novorozence.

Zvětšit

Závěr

Systémy AI spoléhají na vysoce signální informace, aby mohly inteligentně a efektivně vyřizovat požadavky uživatelů. Tyto informace musí být prezentovány co nejvíce chirurgicky, aby byla maximalizována relevance pro každý požadavek. Naše nové modely komprese zohledňující dotaz dělají přesně toto: maximalizují množství důkazů k tématu na jeden úryvek a agresivně ořezávají irelevantní rušivé prvky.

Nasazením těchto nových modelů v rámci našeho vyhledávacího stacku jsme schopni poskytovat rychlejší a lepší odpovědi těm, kteří spoléhají na naše produkty a API. Náš přístup vytváří jednoduché ovládací rozhraní, které našim systémům a zákazníkům API umožňuje vyladit stupeň komprese tak, aby se vyrovnala rovnováha mezi úplností (recall), latencí a cenou.

Kurátorování kontextu je vyvíjející se obor a je toho ještě mnoho co dělat pro optimalizaci hodnoty každého tokenu použitého v dnešních špičkových zpravodajských systémech. Aktivně pracujeme na tom, abychom naše techniky kurátorování kontextu ještě vylepšili prostřednictvím vylepšení modelů i systémové architektury, abychom tyto modely mohli využívat ještě rozsáhleji.

Odkazy

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. Přijato na 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.

Citace

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