Lekérdezésalapú kontextustömörítés a jobb részletekért

Minden válasz bizonyítékkal kezdődik. Egy keresőrendszerben ez a bizonyítvány általában dokumentumokból származik: címekből, összefoglalók kontextusként egy válaszmodellhez vagy ágenshez továbbított szövegrészletekből és töredékekből.

Ez a nyers kontextus zajos. Egy weboldal például tartalmazhatja a felhasználó kéréséhez szükséges információkat, de tartalmazhat zavaró tényezőket is. Ezek a zavaró tényezők megjelenhetnek a fő szövegtörzsben és a kiegészítő elemekben is, mint például a navigációs szövegelemek, a lényegtelen hirdetések, a metaadatok és egyebek. Ezen zavaró tényezők továbbítása a downstream ágens felé három problémát teremt.

Először is, rontja a pontosságot. Még a legerősebb modellek kapacitása is véges. A lényegtelen információk hosszú folyamai elpazarolják a modell kapacitását, ami „kontextus-romlást” eredményez, ezáltal csorbítja a modell azon képességét, hogy kezelni tudja a valós felhasználói kérést. Ennek következtében a végső válasz nagyobb valószínűséggel hagyja figyelmen kívül a kulcsfontosságú tényeket, súlyozza túl alacsony minőségű információkat, vagy olyan állításokat hoz létre, amelyeket nehezebb megalapozni a forrásban.

Másodszor, növeli a válaszidőt. A hosszabb kontextus több tokent jelent a downstream modell számára a feldolgozáshoz, különösen akkor, amikor egy lekérdezés sok jelölt oldaltól igényel bizonyítékot. Bár a válaszidő költségének egy része az előtöltési szakaszban jelentkezik, ennél sokkal jelentősebb költség hárul a következtetésre, mivel a modelleknek több következtetési tokenre van szükségük a lényegtelen kontextus kezeléséhez.

Harmadszor, növeli a költségeket. A modellnek átadott minden egyes felesleges token költségesebbé teszi a felhasználói kérés kiszolgálását, mivel a zajosabb kontextus miatt mind a bemeneti tokenek, mind a következtetési tokenek használata növekszik. A zavaró tényezők nem csupán csökkentik a minőséget; végül arra kényszerítik Önt, hogy többet fizessen ezért a rosszabb minőségért.

Nagyítás

Annak érdekében, hogy egyszerre növeljük a pontosságot, a sebességet és a költséghatékonyságot a Perplexity alkalmazásaiban és az API Platform-on, komoly erőforrásokat fordítunk a kontextus pontosságának javítására. Ennek egyik módja a részletgeneráló algoritmusaink finomítása. A részletgenerálást kontextustömörítési problémaként kezeljük. A specifikus információkat kereső modellek nem profitálnak egy dokumentum általánosított összefoglalóiból vagy kivonataiból. Ehelyett a forrásinformáció legkisebb, legsebészibb módon kinyert darabjára van szükségük a felhasználó kérésére adott válaszhoz. Minden más abbahagyható és el is kell távolítani.

Egy jó részletnek ezért három dolgot kell tennie:

Növelje a pontosságot a modell válaszának megalapozásához szükséges pontos bizonyíték bemutatásával.

Csökkentse a válaszidőt és a költségeket a lényegtelen kontextus eltávolításával az LLM-hívás előtt.

Biztosítsa a visszakövethetőséget a hivatkozási hűség megőrzésével és a forrás szógépességének érintetlen hagyásával.

Ebben a hónapban új, korszerű részletgenerátort helyeztünk üzembe az alkalmazásainkon belül és az API Platform-on. Ennek a modulnak a magja egy lekérdezésalapú kontextustömörítő modell, amely minden egyes lekérdezés és jelölt eredmény esetében eldönti, hogy a szakaszok mely részhalmazát kell megőrizni. Ez a cikk bemutatja a modell felépítésére és betanítására vonatkozó megközelítésünket, hogy kategóriájában a legjobb teljesítményt érjük el ezen a kritikus feladaton.

Részletgenerálás mint lekérdezésalapú tömörítés

Az első teendő maga a feladat meghatározása. Mit akarunk, hogy ez a modell tegyen, és hogyan kell meghatároznunk a bemeneti és kimeneti sémát?

A részletgenerálási módszerek két nagy családra oszthatók. Az első a kiválasztásalapú: találjon meg egy releváns ablakot, egységet, mondatot vagy passzust, és küldje tovább. A második a generálásalapú: kérjen meg egy modellt, hogy írjon egy lekérdezésre fókuszáló összefoglalót az oldalról.

A pontosságra, a válaszidőre és a költségekre helyezett hangsúlyunk egyértelművé teszi a tervezési döntést. Kizárhatjuk a generálást, mivel az új összefoglaló létrehozása minden egyes oldalhoz mindhárom fókuszterületen rontja a teljesítményt. Az összefoglalás rosszul illeszkedik az általunk fontosnak tartott bizonyítékréteghez. Átfogalmazhatja a forrást, ami megnehezíti a hivatkozások igazítását. Olyan megfogalmazást is bevezethet, amely nem volt jelen az oldalon, ami kockázatos, ha a részletet bizonyítékként használják a végső válasz helyett. A járulékos válaszidő és költség még emészthetetlenebbé teszi a generálást.

Ehelyett a feladatunkat lekérdezésalapú kinyerő tömörítésként határozzuk meg: elválasztjuk a lekérdezett kontextus hasznos részeit a zavaró részektől. Pontosabban, a modellünknek el kell fogadnia egy lekérdezést és egy jelölt eredményt, és el kell döntenie, hogy mely szakaszokat kell megőrizni (azokat, amelyek a legjobban támogatják a lekérdezést), és melyeket kell elvetni (a többit). A modell kimenete megőrzi a forrásszöveget ahelyett, hogy átírná azt. Ezáltal az eredmény könnyebben hivatkozható, könnyebben ellenőrizhető és olcsóbban továbbítható a downstream rendszerbe.

Például vegyük ezt a lekérdezést és a lekérdezett eredményt:

Nagyítás

A modell lehetséges kimenete a félkövérrel szedett mondat kiválasztása lenne: „A Cometben az asszisztens tud ...”.

Megközelítésünk ugyanazt az általános ötletet követi, mint a korábbi kontextustömörítési munkák, mint például a FliCo, a Provence és a LooComp, amelyeket egy éles keresőrendszer részletgenerálásához igazítottunk. Fontos, hogy a modell a nyers lekérdezési szakaszunk utáni precíziós szakaszként működik. Amint azt a korábbi Perplexity kutatási cikkünkben, a Introducing the Perplexity Search API címűben tárgyaltuk, keresőrendszereinket úgy alakítottuk ki, hogy natív módon a dokumentum alatti, azaz részletszinten működjenek, ami önmagában is lehetővé teszi számunkra a pontosság és a visszahívás megfelelő egyensúlyát. Egy lekérdezésalapú kontextustömörítő modell bevezetésével a pontosság-visszahívás Pareto-határát még inkább kifelé toljuk.

Kontextustömörítő modell felépítése és betanítása

Modellünket három fő szempont szem előtt tartásával fejlesztjük: a lekérdezés és a kontextus együttes megértése, finomszemcsés, mondatszintű kiválasztás, valamint hatékonyság, hogy beleférjen a rendkívül szigorú válaszidő-keretbe.

Modellarchitektúra

Gerincfaként egy pplx-diffusion modellt használunk. Ez ugyanaz a modellcsalád, amely a pplx-embed-v1 mögött áll, és mind a korábbi akadémiai munkánk (Diffusion-Pretrained Dense and Contextual Embeddings), mind az éles benchmarkjaink megerősítik, hogy erős kétirányú kódoló a lekérdezés-kontextus párokhoz. E modellcsalád egyik kulcsfontosságú tulajdonsága a kétirányú kontextus: minden token-reprezentáció képes figyelni a teljes lekérdezésre és a teljes jelölt kontextusra, mielőtt a modell eldöntené, hogy mit kell megőrizni.

E gerincfej tetején egy könnyű súlyú tömörítőfejet tanítunk be, amely előrejelzi, hogy a kontextus mely részeit kell megőrizni. Mivel nincs generálás, ezek az előrejelzések párhuzamosan történnek a teljes kontextusban. A kiszolgálás idején a részletmotor mondatszinten összesíti ezeket az előrejelzéseket, küszöbértéket alkalmaz, és a kért tokenkerethez igazítja az eredményt.

Felügyeleti folyamat

Ennek a tömörítőnek a betanítása megfelelő szintű részletességet igényel. A dokumentumszintű relevácialapú címke nyilvánvalóan alkalmatlan a kinyerő tömörítési feladatunkhoz. A felügyelt tanuláshoz elegendően részletes adatok előállítása érdekében létrehoztunk egy szakaszcímkézési folyamatot, amely megjelöli a lekérdezés szempontjából releváns bizonyítási szakaszokat, valamint az eltávolítandó zavaró szakaszokat.

Folyamatunk egy LLM-mint-bíró (LLM-as-a-judge) beállítást használ. Adott egy felhasználói lekérdezés és egy jelölt weboldal a linkjével, címével és összefoglalójával, a bíró először elvégzi a lekérdezés megértését, elemezve a lekérdezést és előállítva a lehetséges felhasználói szándékok listáját. Ezen szándékokra horgonyozva a bíró ezután feldolgozza a jelölt kontextust, és a szövegből szóról szóra másolt szakaszokat ad vissza, minden egyes szakaszhoz egy kategóriát rendelve a címkék könnyebb áttekinthetősége érdekében.

Ezután visszapárosítottuk a visszaküldött szakaszokat a forrásszöveghez. Nem meglepő módon a bíró kimeneteinek a nagy része már eleve pontos másolat volt: a naiv karakterlánc-illesztés a szakaszok 98%-át helyreállította. Egy egyszerű reguláris kifejezésen alapuló illesztési lépés hozzáadása a szakaszok helyreállítását 100%-ra emelte. Ez megbízható, részletes szakaszokat biztosított számunkra, amelyek token szintű megtartási/elvetési felügyeletté alakíthatók.

Ezt a felügyeleti folyamatot egy kis, kézzel címkézett szakaszokat tartalmazó kurált adatkészlet segítségével értékeltük ki, összehasonlítva a kisebb bírómodelleket, a különböző promptokat és a különböző lépéskonfigurációkat. A legteljesebb beállítás egy kétlépcsős folyamat volt: először a lekérdezés megértése, majd a kategorizált szakaszcímkézés. A kinyerett szakaszok készletét olyan downstream ellenőrizhető kiértékelésekkel is validáltuk, mint a BrowseComp és a SimpleQA, ahol a megtartott bizonyítási szakaszok önmagukban is megőrizték az erős pontszámokat, miközben jelentősen csökkentették a bemeneti tokenek számát.

Ezt a folyamatot használva 750 ezer lekérdezés-dokumentum párt címkéztünk meg, és az így kapott szakaszokat használjuk a tömörítőfej bináris keresztezett entrópiával történő betanítására. Ez a folyamat lehetővé teszi lekérdezésalapú tömörítőmodellünk számára, hogy a forrásszöveget érintetlenül hagyja, miközben eltávolítja a kontextust, amely valószínűleg nem segíti a downstream modellt a felhasználó kérésének kiszolgálásában.

Valós idejű válaszidő biztosítása

A kontextustömörítés a downstream modell előtt helyezkedik el, ami blokkoló műveletté teszi azt. Sőt, minden tömörítés lekérdezésfüggő. Ezért az online útvonalnak minden jelölt dokumentumhoz pontoznia kell a lekérdezés-kontextus párokat egy szigorú válaszidő-kereten belül. A lassú tömörítőmodell önpusztító, mivel a magasabb precizitásból fakadó válaszidő-előnyöket maga a tömörítési válaszidő semmisíti meg. Ezzel párhuzamosan egy kevésbé intelligens tömörítőmodell rosszabb döntéseket hoz majd arról, hogy mit kell levágni és mit kell megtartani.

A gyakorlati kérdés az, hogy mennyi modellkapacitást tudunk biztonságosan eltávolítani, mielőtt a tömörítés minősége romlani kezdene. Összehasonlítjuk a teljes 28 rétegű pplx-diffusion gerincet a rétegmetszéssel előállított és a keresési útvonalra célzott 11 rétegű és 17 rétegű változatokkal. Mindegyiknél végigpásztázzuk a tömörítési küszöbértéket, és két mennyiséget mérünk: a lekérdezésenként downstream továbbított kontextustokenek átlagos számát, valamint a tömörítés után megőrzött hasznos bizonyítékok arányát.

A 2. ábra a minőségi és hatékonysági határt mutatja be. A modell akkor jobb, ha a bal felső sarok felé mozdul el: kevesebb downstream token több megőrzött hasznos bizonyítékkal. A 28 rétegű modell biztosítja a minőségi referenciát. A 11 rétegű modell bemutatja a modell túl agresszív tömörítésének kockázatait. A megmetszett 17 rétegű modell középutat képvisel: szorosan követi a 28 rétegű modellt a telített tartományban, de egy kis rés nyílik a görbe meredek részén, ahol a legtöbb éles forgalom halad.

E szakadék áthidalása érdekében token szintű tudásdisztillációt alkalmazunk. Megközelítésünk rutinszerű: a standard veszteséget kiegészítjük a tanító modell előrejelzésein alapuló lágy keresztezett entrópia taggal, amelyet egy disztillációs együtthatóval súlyozunk. Ez elegendő ahhoz, hogy a tanuló modellt a referenciatárssal azonos szintre hozza, így éles környezetben teljesen átállhatunk a disztillált 17 rétegű modellre. Ez az új éles modell 35–40%-os csökkenést eredményez a következtetési válaszidőben és 45-50%-os csökkenést az összesített GPU-számítási kapacitásban, miközben a minőség nem esik vissza a 28 rétegű tanító modellhez képest. Az éles válaszidő 20 ms (p99) alatt alakul: elég alacsony ahhoz, hogy hozzáadhassuk a kiszolgálási útvonalhoz, miközben nagymértékben csökkenti a válaszmodellnek átadott tokenek teljes számát.

Nagyítás

Minőség és tokenhatékonyság

A kontextustömörítés hatékonyságának elemzéséhez a Perplexity Agent API-ját használjuk tesztkörnyezetként. Három Agent API előbeállítást értékelünk ki:

Egy „alacsony” kontextusú előbeállítás, amely az egyes eredménysorozatok tokenkeretét 1000 tokenre korlátozza.

Egy „közepes” kontextusú előbeállítás, amely az egyes eredménysorozatok tokenkeretét 4000 tokenre korlátozza.

Egy „magas” kontextusú előbeállítás, amely az egyes eredménysorozatok tokenkeretét 10 000 tokenre korlátozza.

Mind a standard, tömörítés nélküli, mind a tömörítési beállítások úgy vannak kialakítva, hogy tiszteletben tartsák ezeket a tokenkereteket.

Ágensalapú többlépéses keresés (BrowseComp)

Először a tömörítés hatását vizsgáljuk az ágensalapú többlépéses keresési munkafolyamatokra a BrowseComp benchmarkon. Ezt a kiértékelést nyílt forráskódú search_evals keretrendszerünk használatával végezzük. Az értékelés az összes futtatás során azonos, az OpenAI kanonikus BrowseComp LLM judge prompt felhasználásával.

A két érdekes dimenzió a benchmark pontossága és a tokenhasználat. Fontos, hogy a tokenhasználatot lekérdezési szinten mérjük, nem pedig az egyes lépések szintjén, annak érdekében, hogy mérni tudjuk a kérés életciklusa során felmerülő tényleges tokenterhelést. A 3. ábra a „pontszám-token” határt mutatja be (pontossági pontszám a tokenhasználathoz képest).

Nagyítás

A tömörítés minden téren új Pareto-határt biztosít. Mindegyik beállítás esetében a tömörítés bevezetése 10%-ról 70%-ra csökkenti a lekérdezési szintű tokenhasználatot, miközben a pontossági növekedés 4 és 4,81 százalékpont között alakul. A tömörítés bevezetése lehetővé teszi még az „alacsony” előbeállításunk számára is, hogy felülmúlja a tömörítés nélküli „magas” előbeállítást, mindezt úgy, hogy a tokenhasználatot több mint háromannyival csökkenti.

Megfigyelhetjük, hogy a tömörítéssel a „magas” beállítás a várakozásoknak megfelelően nagyobb pontosságot eredményez, mint a „közepes”. Érdekes módon azonban ezt alacsonyabb tokenhasználat mellett teszi. Ez feltárja a tömörítés egy finom, de fontos hatását: a tömörítéssel még a lépésenkénti kontextusméret növelése is lehetővé teheti a modell számára, hogy kevesebb lépést tegyen meg a helyes eredmény eléréséhez. Ezen nem-monotonitás feltárása ígéretes irány a jövőbeli munkák számára.

SimpleQA: egylépéses ténybeliség

A BrowseComp a többlépéses kutatást helyezi előtérbe, mégis sok éles munkafolyamat magában foglalja az egylépéses ténybeli keresést. Annak megállapítására, hogy a tömörítés az egylépéses tartományban is segít-e, megvizsgáljuk a teljesítményt a SimpleQA benchmarkon is, amely 4326 kérdést foglal magában, amelyeket egyetlen keresési lépésben kell megválaszolni, nem pedig ágenshurkon keresztül.

Mint korábban, a pontosságot az átlagos feladatonkénti összes tokenhez viszonyítva ábrázoljuk a kanonikus bíró prompt használatával. A 4. ábra a pontszám-token határt mutatja be ebben az egylépéses beállításban. Bár a hatásméretek tömörebbek az egylépéses beállításban, ismét azt tapasztaljuk, hogy a tömörítés egyszerre javítja a pontosságot és a hatékonyságot az összes előbeállítás esetében, ezáltal új Pareto-határt vezet be. Az engedélyezett tömörítéssel a közepes előbeállítás 95%-os pontosságot ér el dokumentumonként átlagosan mindössze 200 tokennel. Tekintettel a több mint 10 000 tokenes átlagos dokumentumhosszra, ez csapatszintű teljesítményt képvisel több mint 50-szeres tömörítási arány mellett.

Nagyítás

Mi kerül végül a részletekbe?

A 4.1. és 4.2. szakaszban említett downstream nyereségek végponttól végpontig terjednek. Annak megértéséhez, hogy a tömörítés hogyan változtatja meg az egyes részleteket, egy külön kiértékelést futtatunk, amely egy LLM bíró segítségével az összes lekérdezett részlet minden egyes tokenjét hat kategória egyikébe sorolja be:

Létfontosságú (Vital): a felhasználó lekérdezésének megválaszolásához elengedhetetlen bizonyíték.

Témán kívüli (Off-topic): olyan információ, amely valamilyen más célra hasznos lehet, de nem kapcsolódik az aktuális lekérdezéshez.

Hirdetések (Ads): lényegtelen reklám, amely elvonja a figyelmet a felhasználó lekérdezésének megválaszolásáról.

Metaadatok (Metadata): metaadatok a dokumentum tartalmáról.

UI és navigáció (UI & navigation): a felületi megjelenítést és navigációt szolgáló elemek.

Duplikátum (Duplicate): a korábban már beépített információk megismétlése.

Értékelésünk a validációs készletünkből származó 1000 vegyes tartományú lekérdezésen fut, és az éles veremrendszert hasonlítja össze egy egyébként azonos, kikapcsolt tömörítésű alapvonallal. Ahogy az 5. ábrán látható, a tömörítés a tömörítés nélküli alapvonallal összehasonlítva átlagosan 63%-kal növeli a létfontosságú tokenek arányát részletenként. A lényegtelen tokenek 29%-os csökkenését figyelhetjük meg, különösen meredek esésekkel a UI/navigáció (-58%), a metaadatok (-46%) és a hirdetések (-43%) terén. Ezek az eredmények megerősítik a fent tárgyalt minőségi és hatékonysági fejlesztések mechanizmusát: a tömörítés mindkét dimenzióban javítja a teljesítményt azáltal, hogy meredeken növeli az egyes részletek jel-zaj arányát.

Nagyítás

A 6. ábra egy egyedi lekérdezés példáján szemlélteti ezt a változást. A „6 napos újszülött tejbevitele etetésenként” lekérdezés esetében bemutatjuk a tömörítetlen alapvonalat és a tömörített részleteket is. A tömörítés kiküszöböli a nem létfontosságú tartalomkategóriákat, és csak az újszülöttek etetésével kapcsolatos információkat tartja meg. Fontos, hogy a tömörítés sikeresen kiszűri azokat a tartalmakat, amelyek általában relevánsak lehetnek az oldal szempontjából, de irrelevánsak ehhez a konkrét, újszülöttekre fókuszáló lekérdezéshez.

Nagyítás

Következtetés

A mesterséges intelligencia rendszerek magas jelerősségű információkra támaszkodnak a felhasználói kérések intelligens és hatékony kiszolgálásához. Ezt az információt a lehető legsebészibb módon kell bemutatni az egyes kérésekhez való relevanciájának maximalizálása érdekében. Új lekérdezésalapú tömörítő modelljeink pontosan ezt érik el azáltal, hogy maximalizálják a részletenkénti témába vágó bizonyítékokat, és agresszíven kiszűrik a lényegtelen zavaró tényezőket.

Ezeknek az új modelleknek a keresési veremünkön belüli üzembe helyezésével képesek vagyunk gyorsabb és jobb válaszokat adni azoknak, akik a termékeinkre és az API-inkra támaszkodnak. Megközelítésünk egy egyszerű vezérlőfelületet hoz létre, amely lehetővé teszi rendszereink és API-ügyfeleink számára, hogy finomhangolják a tömörítés mértékét a visszahívás, a válaszidő és a költségek közötti egyensúly megteremtése érdekében.

A kontextuskurálás fejlődő terület, és még sok tennivaló van a mai határterületi intelligenciarendszerekben felhasznált egyes tokenek értékének optimalizálása terén. Aktívan dolgozunk azon, hogy modellfejlesztésekkel és a rendszerarchitektúra fejlesztésével még jobbá tegyük a kontextuskurálási technikáinkat, hogy még szélesebb körben tudjuk használni ezeket a modelleket.

Hivatkozások

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

Idézet

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