Стиснення контексту з урахуванням запиту для кращих фрагментів

Будь-яка відповідь починається з доказів. У пошуковій системі ці докази зазвичай надходять із документів: заголовків, коротких оглядів, фрагментів і витягів, які передаються як контекст моделі або агенту формування відповідей.

Цей сирий контекст містить чимало «шуму». Наприклад, вебсторінка може містити інформацію, необхідну для запиту користувача, але в ній також можуть бути відволікаючі елементи. Вони можуть з'являтися як в основному тексті, так і в допоміжних елементах, таких як елементи тексту навігації, нерелевантна реклама, метадані тощо. Передача цих відволікаючих елементів подальшому агенту створює три проблеми.

По-перше, це погіршує точність. Навіть найпотужніші моделі мають обмежену ємність. Довалі потоки нерелевантної інформації марно витрачають ємність моделі, призводячи до «деградації контексту» (context rot), яка знижує здатність моделі опрацьовувати реальний запит користувача. Як наслідок, у фінальній відповіді з більшою ймовірністю будуть пропущені ключові факти, надто велику вагу матиме низькоякісна інформація або з'являться твердження, які важче обґрунтувати джерелом.

По-друге, це погіршує затримку. Довший контекст означає більшу кількість токенів для обробки подальшою моделлю, особливо коли для запиту потрібні докази з багатьох сторінок-кандидатів. Хоча частина цих витрат на затримку припадає на етап попереднього заповнення (prefill), набагато більші витрати припадають на міркування: моделям потрібно більше токенів міркувань для роботи з нерелевантним контекстом.

По-третє, це збільшує вартість. Кожен зайвий токен, переданий моделі, робить обслуговування запиту користувача дорожчим, оскільки використання як вхідних токенів, так і токенів міркувань зростає зі збільшенням кількості шуму в контексті. Відволікаючі елементи не просто знижують якість — вони змушують вас платити більше за цю нижчу якість.

Розгорнути

Щоб одночасно підвищувати точність, швидкість і рентабельність у додатках і на платформі API Perplexity, ми робимо значні інвестиції в покращення точності контексту. Один із способів досягти цього — вдосконалення наших алгоритмів створення фрагментів. Ми розглядаємо створення фрагментів як проблему стиснення контексту. Моделям, які шукають конкретну інформацію, не потрібні узагальнені витяги чи уривки з документа. Натомість їм потрібен найменший, максимально хірургічно витягнутий шматок вихідної інформації, щоб відповісти на запит користувача. Все інше можна і потрібно видалити.

Тому якісний фрагмент повинен виконувати три завдання:

Підвищувати точність шляхом надання точних доказів, необхідних для обґрунтування відповіді моделі.

Зменшувати затримку та витрати завдяки видаленню нерелевантного контексту перед викликом LLM.

Забезпечувати простежуваність шляхом збереження точності цитування та незмінності формулювань джерела.

Цього місяця ми розгорнули новий сучасний генератор фрагментів у наших додатках і на платформі API. Основою цього модуля є модель стиснення контексту з урахуванням запитів, яка для кожного запиту та результату-кандидата визначає підмножину діапазонів, що підлягають збереженню. У цій статті описано наш підхід до створення та навчання моделі для досягнення найкращої у своєму класі продуктивності у вирішенні цього критично важливого завдання.

Фрагменти як стиснення з урахуванням запиту

Першочергове завдання полягає у визначенні самого завдання. Чого ми хочемо від цієї моделі і як слід визначити схему вхідних та вихідних даних?

Методи створення фрагментів поділяються на дві великі категорії. Перша — на основі вибору: знайти релевантне вікно, блок, речення чи уривок і передати його далі. Друга — на основі генерації: попросити модель написати короткий огляд сторінки, орієнтований на запит.

Наша увага до точності, затримки та вартості робить вибір архітектури очевидним. Ми можемо відкинути генерацію, оскільки створення нового короткого огляду для кожної сторінки погіршує показники за всіма трьома критеріями. Створення коротких оглядів погано підходить для шару доказів, який нас цікавить. Воно може перефразувати джерело, що ускладнює узгодженість цитування. Воно також може містити формулювання, яких не було на сторінці, що є ризикованим, коли фрагмент використовується як доказ, а не як остаточна відповідь. Пов'язані з цим затримка та витрати роблять генерацію ще більш неприйнятною.

Натомість ми визначаємо наше завдання як завдання екстрактивного стиснення з урахуванням запиту: відокремлення корисних частин отриманого контексту від тих, що відволікають. Зокрема, наша модель повинна приймати запит і результат-кандидат та визначати, які діапазони слід зберегти — ті, що найкраще підтримують запит, а які відкинути — решту. Вихідні дані моделі зберігають вихідний текст, а не переписують його. Це робить результат простішим для цитування, перевірки та дешевшим для передачі далі.

Наприклад, розглянемо такий запит і отриманий результат:

Розгорнути

Правдоподібним виходом моделі було б вибрати виділене жирним шрифтом речення: «У Comet асистент може...».

Наш підхід ґрунтується на тій самій загальній ідеї, що й попередні роботи зі стиснення контексту, такі як FliCo, Provence та LooComp, адаптовані для створення фрагментів у робочій пошуковій системі. Важливо, що модель працює як етап забезпечення точності після нашого етапу грубого пошуку. Як обговорювалося в нашій попередній дослідницькій статті Perplexity «Представляємо пошуковий API Perplexity» (Introducing the Perplexity Search API), ми проєктуємо наші пошукові системи так, щоб вони працювали на рівні піддокументів або фрагментів, що вже дозволяє нам досить добре збалансувати точність і повноту. Застосування моделі стиснення контексту з урахуванням запитів ще більше зміщує кордонів Парето за критерієм «точність-повнота» назовні.

Створення та навчання моделі стиснення контексту

Ми розробляємо нашу модель, маючи на увазі три основні міркування: спільне розуміння запиту та контексту, деталізований вибір на рівні речень і ефективність, щоб відповідати надзвичайно жорсткому ліміту затримки.

Архітектура моделі

Як основну архітектуру ми використовуємо модель pplx-diffusion. Це та сама родина моделей, на якій базується pplx-embed-v1, і як наші попередні академічні праці (Diffusion-Pretrained Dense and Contextual Embeddings), так і наші виробничі бенчмарки підтверджують, що це потужний двонаправлений енкодер для пар «запит-контекст». однією з ключових властивостей цієї родини моделей є двонаправлений контекст: кожне представлення токена може враховувати весь запит і весь контекст-кандидат до того, як модель вирішить, що слід залишити.

Поверх цієї основної архітектури ми навчаємо легкий шар стиснення, який прогнозує, які частини контексту слід зберегти. Оскільки генерація не задіяна, ці прогнози робляться паралельно по всьому контексту. Під час обслуговування рушій фрагментів агрегує ці прогнози на рівні речень, застосовує поріг і обрізає результат відповідно до запитаного ліміту токенів.

Конвеєр нагляду (Supervision pipeline)

Навчання цього компресора вимагає нагляду на потрібному рівні деталізації. Метка релевантності на рівні документа вочевидь не підходить для нашого завдання екстрактивного стиснення. Щоб згенерувати достатньо деталізовані дані для керованого навчання (supervised learning), ми створили конвеєр маркування діапазонів, який позначає релевантні до запиту діапазони доказів, а також діапазони-відволікачі, які слід видалити.

Наш конвеєр використовує налаштування LLM-як-судді. Отримавши запит користувача та вебсторінку-кандидат з її посиланням, заголовком і коротким оглядом, суддя спочатку виконує розуміння запиту, аналізуючи його та створюючи список можливих намірів користувача. Опираючись на ці наміри, суддя потім обробляє контекст-кандидат і повертає діапазони, скопійовані дослівно з тексту, з категорією для кожного діапазону, щоб мітки було легше перевіряти.

Потім ми зіставили повернуті діапазони з вихідним текстом. Очікувано, більшість результатів роботи судді вже були точними копіями: просте зіставлення рядків відновило 98% діапазонів. Додавання простого етапу зіставлення на основі регулярних виразів довело відновлення діапазонів до 100%. Це дало нам надійні, деталізовані діапазони, які можна було перетворити на нагляд збереження/видалення на рівні токенів.

Ми оцінили цей конвеєр нагляду, використовуючи невеликий підібраний набір даних із вручну позначеними діапазонами, порівнюючи менші моделі суддів, різні промпти та різні конфігурації кроків. Найефективнішим виявився двохетапний конвеєр: спочатку розуміння запиту, а потім категоризоване маркування діапазонів. Ми також перевірили набір витягнутих діапазонів за допомогою подальших перевірюваних оцінювань, таких як BrowseComp і SimpleQA, де використання лише збережених діапазонів доказів дозволило зберегти високі результати при значному зменшенні кількості вхідних токенів.

Використовуючи цей конвеєр, ми позначили 750 тисяч пар «запит-документ» і використали отримані діапазони для навчання шару стиснення за допомогою бінарної перехресної ентропії (binary cross-entropy). Цей процес дозволяє нашій моделі стиснення з урахуванням запиту зберігати вихідний текст неушкодженим, водночас видаляючи контекст, який навряд чи допоможе подальшій моделі опрацювати запит користувача.

Забезпечення затримки в реальному часі

Стиснення контексту відбувається перед подальшою моделлю, що робить його блокувальною операцією. Крім того, кожне стиснення залежить від запиту. Тому оперативний шлях має оцінювати пари «запит-контекст» для кожного документа-кандидата в межах суворого ліміту затримки. Повільна модель стиснення є контрпродуктивною, оскільки переваги в затримці від вищої точності нівелюються самою затримкою стиснення. Водночас менш інтелектуальна модель стиснення прийматиме гірші рішення щодо того, що потрібно вирізати, а що залишити.

Практичне питання полягає в тому, яку ємність моделі ми можемо безпечно видалити до того, як якість стиснення почне деградувати. Ми порівнюємо повну 28-шарову основну архітектуру pplx-diffusion з 11-шаровим і 17-шаровим варіантами, отриманими шляхом прунінгу (проріджування) шарів і націленими на пошуковий шлях. Для кожного з них ми перебираємо поріг стиснення і вимірюємо дві величини: середню кількість контекстних токенів, що надсилаються далі на запит, і частку корисної доказової бази, збереженої після стиснення.

На рисунку 2 показано кордон якості та ефективності. Модель є кращою, коли вона зміщується у верхній лівий кут: менше подальших токенів із збереженням більшої кількості корисних доказів. 28-шарова модель забезпечує еталон якості. 11-шарова модель демонструє ризики занадто агресивного стиснення моделі. Проріджена 17-шарова модель представляє золоту середину: вона тісно слідує за 28-шаровою моделлю в насиченому режимі, але невеликий розрив виникає на крутій ділянці кривої, де працює більшість виробничого трафіку.

Щоб подолати цей розрив, ми використовуємо дистиляцію знань на рівні токенів (token-level knowledge distillation). Наш підхід є стандартним: ми доповнюємо стандартну функцію втрат членом м'якої перехресної ентропії (soft cross-entropy) для прогнозів моделі-вчителя, зваженим за коефіцієнтом дистиляції. Цього достатньо, щоб вивести модель-учня на паритетний рівень, що дозволяє нам повністю перейти на дистильовану 17-шарову модель у виробництві. Ця нова робоча модель забезпечує зниження затримки інференсу на 35–40% і зниження сукупних обчислень GPU на 40–45% без зниження якості порівняно з 28-шаровим вчителем. Затримка у виробництві становить менше 20 мс (p99): достатньо мало, щоб додати її на шлях обслуговування, значно зменшуючи загальну кількість токенів, що передаються моделі відповідей.

Розгорнути

Якість та токеноефективність

Ми використовуємо Agent API від Perplexity як тестовий майданчик для аналізу ефективності стиснення контексту. Ми оцінюємо три пресети Agent API:

«Низький» (low) контекстний пресет, який обмежує бюджет токенів для кожного набору результатів до 1000 токенів.

«Середній» (medium) контекстний пресет, який обмежує бюджет токенів для кожного набору результатів до 4000 токенів.

«Високий» (high) контекстний пресет, який обмежує бюджет токенів для кожного набору результатів до 10 000 токенів.

І стандартні параметри без стиснення, і параметри зі стисненням налаштовані так, щоб дотримуватися цих бюджетів токенів.

Агентний багатокроковий пошук (BrowseComp)

Спочатку ми досліджуємо вплив стиснення на агентні багатокрокові пошукові робочі процеси на бенчмарку BrowseComp. Ми виконуємо це оцінювання за допомогою нашого інструмента з відкритим кодом search_evals. Оцінювання є ідентичним для всіх запусків із використанням канонічного промпту судді LLM для BrowseComp від OpenAI.

Двома цікавими для нас вимірами є точність бенчмарку та використання токенів. Важливо, що ми вимірюємо використання токенів на рівні запиту, а не на рівні окремих кроків, щоб вимірити реальне навантаження токенів, яке виникає протягом життєвого циклу запиту. На рисунку 3 показано кордон «оцінка-токен» (score-token): оцінка точності проти використання токенів.

Розгорнути

Стиснення забезпечує новий кордон Парето по всій лінії. Для кожного налаштування застосування стиснення зменшує використання токенів на рівні запиту від 10% до 70%, а приріст точності становить від 4 до 4,81 відсоткового пункту. Застосування стиснення дозволяє навіть нашому «низькому» пресету перевершити «високий» пресет без стиснення, при цьому зменшуючи використання токенів більш ніж у три рази.

Ми помічаємо, що зі стисненням «високий» пресет дає більшу точність, ніж «середній», як і слід було очікувати. Цікаво, однак, що це досягається при меншому використанні токенів. Це виявляє тонкий, але важливий ефект стиснення: зі стисненням навіть збільшення розміру контексту для кожного кроку може дозволити моделі робити менше кроків для досягнення правильного результату. Дослідження цієї немонотонності є перспективним напрямком для майбутньої роботи.

SimpleQA: однокрокова фактологічність

BrowseComp наголошує на багатокрокових дослідженнях, проте багато робочих процесів у виробництві включають однокроковий пошук фактів. Щоб визначити, чи допомагає стиснення також в однокроковому режимі, ми також досліджуємо продуктивність на SimpleQA, бенчмарку, що складається з 4326 запитань, на які потрібно відповісти за один пошуковий крок, а не в агентному циклі.

Як і раніше, ми будуємо графік точності залежно від середньої кількості токенів на завдання, використовуючи канонічний промпт судді. На рисунку 4 показано кордон «оцінка-токен» у цьому однокроковому режимі. Хоча ефекти є більш стисненими в однокроковому режимі, ми знову спостерігаємо, що стиснення одночасно покращує точність та ефективність для всіх пресетів, таким чином вводячи новий кордон Парето. З активованим стисненням середній пресет досягає 95% точності в середньому лише з 200 токенами на документ. З огляду на середню довжину документа понад 10 000 токенів, це є продуктивністю передового рівня при коефіцієнті стиснення понад 50.

Розгорнути

Що потрапляє у фрагменти?

Подальші покращення в розділах 4.1 та 4.2 є комплексними (end-to-end). Щоб зрозуміти, як стиснення змінює окремі фрагменти, ми запускаємо окреме оцінювання, яке використовує суддю LLM для класифікації кожного токена кожного отриманого фрагмента в одну з шести категорій:

Життєво важливе (Vital): докази, необхідні для відповіді на запит користувача.

Не за темою (Off-topic): інформація, яка може бути корисною для інших цілей, але не стосується поточного запиту.

Реклама (Ads): нерелевантна реклама, яка відволікає від відповіді на запит користувача.

Метадані (Metadata): метадані про вміст документа.

Інтерфейс та навігація (UI & navigation): елементи для відображення у фронтенді та навігації.

Дублікати (Duplicate): повторення раніше включеної інформації.

Наше оцінювання проводиться на 1000 запитах із різних доменів із нашого набору валідації, порівнюючи виробничий стек із ідентичним базовим рішенням, де стиснення вимкнено. Як показано на рисунку 5, стиснення збільшує частку життєво важливих токенів на фрагмент у середньому на 63% порівняно з базовим рівнем без стиснення. Ми спостерігаємо відповідне зменшення на 29% нерелевантних токенів, із особливо різким падінням у категоріях інтерфейсу/навігації (-58%), метаданих (-46%) та реклами (-43%). Ці результати підтверджують механізм покращення якості та ефективності, описаний вище: стиснення покращує продуктивність за обома вимірами завдяки різкому збільшенню співвідношення сигнал/шум кожного окремого фрагмента.

Розгорнути

На рисунку 6 проілюстровано цю зміну для окремого запиту. Для запиту «6 day old newborn milk intake per feeding» ми показуємо як нестиснений базовий фрагмент, так і стиснені фрагменти. Стиснення усуває нежиттєво важливі категорії вмісту та зберігає лише інформацію про годування новонароджених. Важливо, що стиснення успішно усуває вміст, який може бути загалом релевантним для сторінки, але не релевантним для цього конкретного запиту щодо новонароджених.

Розгорнути

Висновок

Системи штучного інтелекту покладаються на інформацію з високим рівнем сигналу для інтелектуального та ефективного обслуговування запитів користувачів. Ця інформація має бути представлена якомога точніше, щоб максимізувати релевантність до кожного запиту. Наші нові моделі стиснення з урахуванням запиту роблять саме це, максимізуючи докази на тему на один фрагмент і агресивно відсікаючи нерелевантні відволікаючі елементи.

Розгортаючи ці нові моделі у нашому пошуковому стеку, ми можемо надавати швидші та кращі відповіді тим, хто покладається на наші продукти та API. Наш підхід створює простий інтерфейс керування, що дозволяє нашим системам і клієнтам API налаштовувати ступінь стиснення для досягнення балансу між повнотою (recall), затримкою та вартістю.

Кураторство контексту є галуззю, що розвивається, і ще багато чого належить зробити для оптимізації цінності кожного токена, який використовується в сучасних передових інтелектуальних системах. Ми активно працюємо над тим, щоб зробити наші методи кураторства контексту ще кращими за рахунок як вдосконалення моделей, так і системної архітектури для ще більш масштабного використання цих моделей.

Посилання

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.

Цитування

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