Kompresja kontekstu z uwzględnieniem zapytania dla lepszych wycinków

Każda odpowiedź zaczyna się od materiału dowodowego. W systemie wyszukiwania materiał ten zazwyczaj pochodzi z dokumentów: tytułów, podsumowań, fragmentów i wycinków, które są przekazywane jako kontekst do modelu odpowiedzi lub agenta.

Ten surowy kontekst jest zaszumiony. Na przykład strona internetowa może zawierać informacje potrzebne do spełnienia zapytania użytkownika, ale może również zawierać elementy rozpraszające. Takie elementy mogą występować zarówno w głównej treści, jak i w elementach pomocniczych, takich jak elementy nawigacyjne, nieistotne reklamy, metadane i inne. Przekazywanie tych elementów rozpraszających do dalszego agenta tworzy trzy problemy.

Po pierwsze, obniża to dokładność. Nawet najpotężniejsze modele mają ograniczoną wydajność. Długie strumienie nieistotnych informacji marnują zasoby modelu, prowadząc do „erozji kontekstu”, co upośledza zdolność modelu do obsługi rzeczywistego zapytania użytkownika. W rezultacie ostateczna odpowiedź z większym prawdopodobieństwem pominie kluczowe fakty, nada nadmierną wagę informacjom niskiej jakości lub wygeneruje twierdzenia, które trudniej uzasadnić w źródłach.

Po drugie, powoduje to opóźnienia. Dłuższy kontekst oznacza więcej tokenów do przetworzenia przez model, zwłaszcza gdy zapytanie wymaga dowodów z wielu stron kandydujących. Chociaż część tego kosztu opóźnienia jest ponoszona na etapie wstępnego wypełniania (prefill), znacznie większy koszt jest płacony na etapie wnioskowania, ponieważ modele wymagają więcej tokenów rozumowania do obsługi nieistotnego kontekstu.

Po trzecie, zwiększa to koszty. Każdy niepotrzebny token przekazany do modelu sprawia, że obsługa zapytania użytkownika staje się droższa, ponieważ zarówno wykorzystanie tokenów wejściowych, jak i tokenów rozumowania rośnie wraz z bardziej zaszumionym kontekstem. Elementy rozpraszające nie tylko obniżają jakość, ale ostatecznie zmuszają do płacenia więcej za gorszą jakość.

Powiększ

Aby jednocześnie poprawić dokładność, szybkość i opłacalność w aplikacjach Perplexity oraz Platformie API, inwestujemy znaczne środki w poprawę precyzji kontekstu. Jednym ze sposobów jest udoskonalanie naszych algorytmów generowania wycinków. Traktujemy generowanie wycinków jako problem kompresji kontekstu. Modele poszukujące konkretnych informacji nie odnoszą korzyści z uogólnionych podsumowań lub fragmentów dokumentu. Potrzebują one natomiast najmniejszej, najbardziej precyzyjnie wyekstrahowanej części informacji źródłowej, aby odpowiedzieć na zapytanie użytkownika. Wszystko inne może i musi zostać usunięte.

Dobry wycinek powinien zatem spełniać trzy zadania:

Zwiększać dokładność poprzez prezentowanie precyzyjnego materiału dowodowego potrzebnego do ugruntowania odpowiedzi modelu.

Zmniejszać opóźnienia i koszty poprzez usuwanie nieistotnego kontekstu przed wywołaniem LLM.

Zapewniać możliwość śledzenia poprzez zachowanie wierności cytowań i nienaruszonego brzmienia źródeł.

W tym miesiącu wdrożyliśmy nowy, najnowocześniejszy generator wycinków w naszych aplikacjach oraz Platformie API. Rdzeniem tego modułu jest model kompresji kontekstu uwzględniający zapytanie, który dla każdego zapytania i wyniku kandydującego decyduje, który podzbiór zakresów (spans) powinien zostać zachowany. Niniejszy artykuł opisuje nasze podejście do budowy i szkolenia modelu w celu osiągnięcia najwyższej wydajności w tym krytycznym zadaniu.

Wycinki jako kompresja z uwzględnieniem zapytania

Pierwszą kwestią do rozstrzygnięcia jest zdefiniowanie samego zadania. Co chcemy, aby ten model robił i jak powinniśmy zdefiniować schemat danych wejściowych i wyjściowych?

Metody wycinków dzielą się na dwie szerokie rodziny. Pierwsza opiera się na selekcji: znalezieniu odpowiedniego okna, segmentu, zdania lub fragmentu i przekazaniu go dalej. Druga opiera się na generowaniu: poproszeniu modelu o napisanie podsumowania strony skoncentrowanego na zapytaniu.

Nasz nacisk na dokładność, opóźnienia i koszty sprawia, że wybór projektowy jest jasny. Możemy wykluczyć generowanie, ponieważ tworzenie nowego podsumowania dla każdej strony pogarsza wydajność w odniesieniu do wszystkich trzech wymienionych czynników. Podsumowywanie nie jest odpowiednie dla warstwy dowodowej, na której nam zależy. Może ono parafrazować źródło, co utrudnia dopasowanie cytowań. Może również wprowadzać sformułowania, których nie było na stronie, co jest ryzykowne, gdy wycinek jest używany jako materiał dowodowy, a nie jako ostateczna odpowiedź. Opóźnienia i koszty związane z generowaniem sprawiają, że staje się ono jeszcze mniej atrakcyjne.

Definiujemy natomiast nasze zadanie jako ekstraktywną kompresję z uwzględnieniem zapytania: oddzielenie pomocnych części pobranego kontekstu od części rozpraszających. Konkretnie, nasz model musi przyjąć zapytanie i wynik kandydujący, a następnie zdecydować, które zakresy zachować – te, które najlepiej wspierają zapytanie – a które odrzucić, czyli całą resztę. Wyjście modelu zachowuje tekst źródłowy zamiast go przepisywać. To sprawia, że wynik jest łatwiejszy do cytowania, weryfikacji i tańszy w dalszym przetwarzaniu.

Rozważmy na przykład poniższe zapytanie i pobrany wynik:

Powiększ

Wiarygodnym wynikiem modelu byłoby wybranie pogrubionego zdania: „W Comet asystent może ...”.

Nasze podejście opiera się na tym samym ogólnym założeniu, co wcześniejsze prace nad kompresją kontekstu, takie jak FliCo, Provence i LooComp, dostosowane do generowania wycinków w produkcyjnym systemie wyszukiwania. Co ważne, model działa jako etap precyzyjny po naszym etapie surowego wyszukiwania. Jak omówiono w naszym poprzednim artykule badawczym Perplexity, Wprowadzenie Perplexity Search API, nasze systemy wyszukiwania zostały zaprojektowane tak, aby działały natywnie na poziomie poddokumentu, czyli wycinka, co już pozwala nam całkiem dobrze zrównoważyć precyzję i kompletność (recall). Wprowadzenie modelu kompresji kontekstu uwzględniającego zapytanie przesuwa granicę Pareto precyzji i kompletności jeszcze dalej.

Budowa i szkolenie modelu kompresji kontekstu

Opracowujemy nasz model, mając na uwadze trzy główne aspekty: wspólne rozumienie zapytania i kontekstu, szczegółową selekcję na poziomie zdań oraz wydajność umożliwiającą zmieszczenie się w wyjątkowo rygorystycznym budżecie opóźnień.

Architektura modelu

Jako szkielet wykorzystujemy model pplx-diffusion. Jest to ta sama rodzina modeli, która stoi za pplx-embed-v1, a zarówno nasze wcześniejsze prace akademickie, Diffusion-Pretrained Dense and Contextual Embeddings, jak i nasze testy porównawcze potwierdzają, że jest to silny dwukierunkowy enkoder dla par zapytanie-kontekst. Jedną z kluczowych właściwości tej rodziny modeli jest dwukierunkowy kontekst: każda reprezentacja tokena może odnosić się do pełnego zapytania i pełnego kontekstu kandydującego, zanim model zdecyduje, co powinno zostać zachowane.

Na wierzchu tego szkieletu trenujemy lekką głowicę kompresującą, która przewiduje, które części kontekstu powinny zostać zachowane. Ponieważ nie zachodzi proces generowania, przewidywania te są dokonywane równolegle dla całego kontekstu. W czasie serwowania silnik wycinków agreguje te przewidywania na poziomie zdań, stosuje próg i przycina wynik do wymaganego budżetu tokenów.

Potok nadzoru (Supervision pipeline)

Szkolenie tego kompresora wymaga nadzoru na odpowiednim poziomie szczegółowości. Etykieta relewancji na poziomie dokumentu jest całkowicie nieodpowiednia dla naszego zadania ekstraktywnej kompresji. Aby wygenerować wystarczająco szczegółowe dane do uczenia nadzorowanego, zbudowaliśmy potok etykietowania zakresów, który oznacza zakresy dowodowe istotne dla zapytania oraz zakresy rozpraszające, które powinny zostać usunięte.

Nasz potok wykorzystuje konfigurację LLM-as-a-judge (LLM jako sędzia). Biorąc pod uwagę zapytanie użytkownika i kandydującą stronę internetową wraz z jej linkiem, tytułem i podsumowaniem, sędzia najpierw przeprowadza analizę zapytania, analizując je i tworząc listę możliwych intencji użytkownika. Bazując na tych intencjach, sędzia przetwarza kontekst kandydujący i zwraca zakresy skopiowane słowo w słowo z tekstu, z kategorią dla każdego zakresu, aby ułatwić weryfikację etykiet.

Następnie dopasowaliśmy zwrócone zakresy z powrotem do tekstu źródłowego. Nic dziwnego, że większość wyników sędziego stanowiła już dokładne kopie: naiwne dopasowywanie ciągów znaków odzyskało 98% zakresów. Dodanie prostego procesu dopasowywania opartego na wyrażeniach regularnych podniosło odzysk zakresów do 100%. Dało nam to wiarygodne, szczegółowe zakresy, które można było przekonwertować na nadzór typu zachowaj/odrzuć na poziomie tokena.

Oceniliśmy ten potok nadzoru, używając małego, wyselekcjonowanego zbioru danych z ręcznie oznaczonymi zakresami, porównując mniejsze modele sędziowskie, różne prompty i różne konfiguracje kroków. Najlepiej działającą konfiguracją był dwuetapowy potok: najpierw zrozumienie zapytania, a następnie kategoryzowane etykietowanie zakresów. Zweryfikowaliśmy również zestaw wyekstrahowanych zakresów poprzez weryfikowalne ewaluacje, takie jak BrowseComp i SimpleQA, gdzie użycie tylko zachowanych zakresów dowodowych pozwoliło utrzymać wysokie wyniki przy znacznym ograniczeniu liczby tokenów wejściowych.

Korzystając z tego potoku, oznaczyliśmy 750 tys. par zapytanie-dokument i wykorzystaliśmy powstałe zakresy do wytrenowania głowicy kompresującej za pomocą binarnej entropii krzyżowej. Proces ten pozwala naszemu modelowi kompresji z uwzględnieniem zapytania zachować nienaruszony tekst źródłowy, usuwając jednocześnie kontekst, który prawdopodobnie nie pomoże modelowi dalszego przetwarzania w obsłudze zapytania użytkownika.

Zapewnienie opóźnienia w czasie rzeczywistym

Kompresja kontekstu znajduje się przed modelem końcowym, co czyni ją operacją blokującą. Co więcej, każda kompresja zależy od zapytania. Dlatego ścieżka online musi oceniać pary zapytanie-kontekst dla każdego dokumentu kandydującego w ramach wymagającego limitu opóźnień. Wolny model kompresji jest nieefektywny, ponieważ korzyści z opóźnień wynikające z wyższej precyzji są niwelowane przez same opóźnienia kompresji. Jednocześnie mniej inteligentny model kompresji będzie podejmował gorsze decyzje dotyczące tego, co wyciąć, a co zatrzymać.

Praktyczne pytanie brzmi: ile pojemności modelu możemy bezpiecznie usunąć, zanim jakość kompresji zacznie spadać. Porównujemy pełny 28-warstwowy szkielet pplx-diffusion z 11- i 17-warstwowymi wariantami wyprodukowanymi poprzez przycinanie warstw (pruning) i ukierunkowanymi na ścieżkę wyszukiwania. Dla każdego z nich analizujemy próg kompresji i mierzymy dwie wielkości: średnią liczbę tokenów kontekstu przesyłanych dalej na zapytanie oraz ułamek przydatnych dowodów zachowanych po kompresji.

Rysunek 2 pokazuje granicę jakości i wydajności. Model jest lepszy, gdy przesuwa się w stronę górnego lewego rogu: mniej tokenów końcowych przy większej ilości zachowanych przydatnych dowodów. Model 28-warstwowy stanowi odniesienie jakościowe. Model 11-warstwowy demonstruje ryzyko zbyt agresywnej kompresji modelu. Przycięty model 17-warstwowy stanowi złoty środek: ściśle podąża za modelem 28-warstwowym w reżimie nasycenia, ale niewielka różnica pojawia się w stromej części krzywej, w której operuje większość ruchu produkcyjnego.

Aby zamknąć tę lukę, stosujemy destylację wiedzy na poziomie tokenów. Nasze podejście jest rutynowe: rozszerzamy standardową funkcję straty o człon miękkiej entropii krzyżowej dla przewidywań modelu nauczyciela, ważony współczynnikiem destylacji. Wystarcza to, aby doprowadzić model ucznia do poziomu modelu nauczyciela, co pozwala nam w pełni przejść na destylowany 17-warstwowy model w produkcji. Ten nowy model produkcyjny daje 35-40% spadku opóźnienia wnioskowania i 40-45% spadku zagregowanych obliczeń GPU bez spadku jakości w stosunku do 28-warstwowego nauczyciela. Opóźnienie produkcyjne wynosi poniżej 20 ms (p99): wystarczająco mało, aby dodać je do ścieżki serwowania, jednocześnie znacznie redukując całkowitą liczbę tokenów przekazywanych do modelu odpowiedzi.

Powiększ

Jakość i wydajność tokenowa

Używamy Agent API firmy Perplexity jako poligonu do analizy skuteczności kompresji kontekstu. Ocenimy trzy presety Agent API:

„Niski” preset kontekstu, który ogranicza budżet tokenów dla każdego zestawu wyników do 1000 tokenów.

„Średni” preset kontekstu, który ogranicza budżet tokenów dla każdego zestawu wyników do 4000 tokenów.

„Wysoki” preset kontekstu, który ogranicza budżet tokenów dla każdego zestawu wyników do 10000 tokenów.

Zarówno ustawienia standardowe (bez kompresji), jak i ustawienia kompresji są skonfigurowane tak, aby przestrzegać tych budżetów tokenów.

Agentowe wyszukiwanie wieloetapowe (BrowseComp)

Najpierw sprawdzamy wpływ kompresji na agentowe przepływy pracy (workflow) wyszukiwania wieloetapowego w benchmarku BrowseComp. Przeprowadzamy tę ocenę przy użyciu naszego narzędzia open-source search_evals. Punktacja jest identyczna we wszystkich uruchomieniach, przy użyciu kanonicznego promptu sędziego LLM BrowseComp OpenAI.

Interesują nas dwa wymiary: dokładność benchmarku i wykorzystanie tokenów. Co ważne, mierzymy wykorzystanie tokenów na poziomie zapytania, a nie na poziomie poszczególnych kroków, aby zmierzyć rzeczywiste obciążenie tokenami poniesione w całym cyklu życia zapytania. Rysunek 3 pokazuje granicę „wynik-token”, czyli wynik dokładności w stosunku do wykorzystania tokenów.

Powiększ

Kompresja zapewnia nową granicę Pareto w całym zakresie. Dla każdego ustawienia wprowadzenie kompresji redukuje wykorzystanie tokenów na poziomie zapytania od 10% do 70%, przy zyskach w dokładności wahających się między 4 a 4,81 punktu procentowego. Wprowadzenie kompresji pozwala nawet naszemu „niskiemu” presetowi przewyższyć „wysoki” preset bez kompresji, przy jednoczesnym zmniejszeniu wykorzystania tokenów ponad trzykrotnie.

Zauważamy, że przy kompresji „wysoki” daje wyższą dokładność niż „średni”, zgodnie z oczekiwaniami. Co ciekawe jednak, robi to przy mniejszym zużyciu tokenów. Ujawnia to subtelny, ale ważny efekt kompresji: dzięki kompresji nawet zwiększenie rozmiaru kontekstu na krok może umożliwić modelowi podjęcie mniejszej liczby kroków do uzyskania poprawnego wyniku. Badanie tej nieliniowości jest obiecującym kierunkiem przyszłych prac.

SimpleQA: jednoetapowa faktualność

BrowseComp kładzie nacisk na wieloetapowe badania, jednak wiele produkcyjnych przepływów pracy (workflow) obejmuje jednoetapowe wyszukiwanie faktów. Aby ustalić, czy kompresja pomaga również w reżimie jednoetapowym, badamy również wydajność w SimpleQA, benchmarku składającym się z 4326 pytań, na które należy odpowiedzieć w jednym kroku wyszukiwania, zamiast w pętli agentowej.

Jak poprzednio, wykreślamy dokładność względem średniej całkowitej liczby tokenów na zadanie przy użyciu kanonicznego promptu sędziego. Rysunek 4 pokazuje granicę wynik-token w tym ustawieniu jednoetapowym. Chociaż efekty są bardziej skompresowane w tym ustawieniu, ponownie obserwujemy, że kompresja jednocześnie poprawia dokładność i wydajność we wszystkich presetach, wprowadzając tym samym nową granicę Pareto. Z włączoną kompresją średni preset osiąga 95% dokładności przy średnio zaledwie 200 tokenach na dokument. Biorąc pod uwagę średnią długość dokumentu przekraczającą 10 000 tokenów, stanowi to wydajność na poziomie granicy przy współczynniku kompresji przekraczającym 50.

Powiększ

Co trafia do wycinków?

Zyski w modelu końcowym w sekcjach 4.1 i 4.2 mają charakter end-to-end. Aby zrozumieć, jak kompresja zmienia poszczególne wycinki, przeprowadzamy oddzielną ewaluację, która wykorzystuje sędziego LLM do zaklasyfikowania każdego tokena każdego pobranego wycinka do jednej z sześciu kategorii:

Kluczowe: dowody niezbędne do odpowiedzi na zapytanie użytkownika.

Nie na temat: informacje, które mogą być przydatne do innych celów, ale nie odnoszą się do bieżącego zapytania.

Reklamy: nieistotne reklamy, które odciągają uwagę od odpowiedzi na zapytanie użytkownika.

Metadane: metadane dotyczące zawartości dokumentu.

UI i nawigacja: elementy interfejsu użytkownika i nawigacji.

Duplikaty: powtórzenie wcześniej uwzględnionych informacji.

Nasza ewaluacja jest przeprowadzana na 1000 zapytań z różnych dziedzin z naszego zbioru walidacyjnego, porównując stos produkcyjny z identyczną linią bazową z wyłączoną kompresją. Jak pokazano na rysunku 5, kompresja zwiększa proporcję kluczowych tokenów w wycinku średnio o 63% w stosunku do linii bazowej bez kompresji. Obserwujemy odpowiedni spadek o 29% w tokenach nieistotnych, z szczególnie wyraźnymi spadkami w interfejsie użytkownika/nawigacji (-58%), metadanych (-46%) i reklamach (-43%). Wyniki te potwierdzają mechanizm poprawy jakości i wydajności omówiony powyżej: kompresja poprawia wydajność w obu wymiarach poprzez gwałtowne zwiększenie stosunku sygnału do szumu w każdym poszczególnym wycinku.

Powiększ

Rysunek 6 ilustruje tę zmianę dla pojedynczego zapytania. Dla zapytania „spożycie mleka przez 6-dniowego noworodka na karmienie” pokazujemy zarówno niekompresowane wycinki bazowe, jak i kompresowane. Kompresja eliminuje kategorie treści niekluczowej i zachowuje tylko informacje związane z karmieniem noworodka. Co ważne, kompresja z powodzeniem eliminuje treść, która może być ogólnie na temat strony, ale jest nieistotna dla tego konkretnego zapytania dotyczącego noworodka.

Powiększ

Podsumowanie

Systemy AI polegają na informacjach o wysokim sygnale, aby inteligentnie i wydajnie obsługiwać zapytania użytkowników. Informacje te muszą być prezentowane w sposób możliwie najbardziej precyzyjny, aby zmaksymalizować trafność dla każdego zapytania. Nasze nowe modele kompresji uwzględniające zapytanie robią dokładnie to, maksymalizując dowody na dany temat w każdym wycinku i agresywnie usuwając nieistotne elementy rozpraszające.

Dzięki wdrożeniu tych nowych modeli w naszym stosie wyszukiwania możemy zapewniać szybsze i lepsze odpowiedzi tym, którzy polegają na naszych produktach i API. Nasze podejście tworzy prostą powierzchnię kontrolną, umożliwiając naszym systemom i klientom API dostosowanie stopnia kompresji w celu zrównoważenia kompletności, opóźnień i kosztów.

Kuratela kontekstu to rozwijająca się dziedzina i pozostaje wiele do zrobienia, aby zoptymalizować wartość każdego tokena używanego w dzisiejszych wiodących systemach inteligentnych. Aktywnie pracujemy nad tym, aby nasze techniki kurateli kontekstu były jeszcze lepsze dzięki ulepszeniom modeli oraz architekturze systemowej, co pozwoli na jeszcze szersze wykorzystanie tych modeli.

Bibliografia

N. Chirkova, T. Formal, V. Nikoulina i S. Clinchant. Provence: Wydajne i odporne przycinanie kontekstu dla generowania wspomaganego wyszukiwaniem, 2025. Zaakceptowane na ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim i D. Kim. LooComp: Wykorzystanie strategii leave-one-out w enkoderze Transformer dla wydajnej kompresji kontekstu z uwzględnieniem zapytania, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang i D. Bykov. Dyfuzyjne, wstępnie wytrenowane osadzenia gęste i kontekstowe, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez i G. Neubig. Uczenie filtrowania kontekstu dla generowania wspomaganego wyszukiwaniem, 2023. arXiv:2311.08377.

Cytat

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