Компресиране на контекста, съобразено със заявката, за по-добри откъси

Всяко отговор започва с доказателства. В една система за търсене тези доказателства обикновено идват от документи: заглавия, резюмета, откъси и кратки текстове, които се предават като контекст на модел за отговори или агент.

Този суров контекст е шумен. Например уеб страницата може да съдържа информация, необходима за заявката на потребителя, но може да съдържа и разсейващи елементи. Тези разсейващи елементи могат да се появят както в основния текст, така и във второстепенни елементи, като текстови елементи за навигация, нерелевантни реклами, метаданни и други. Предаването на тези разсейващи елементи на модел от по-ниско ниво създава три проблема.

Първо, това влошава точността. Дори най-мощните модели имат краен капацитет. Дългите потоци от нерелевантна информация хабят капацитета на модела, което води до „контекстно гниене“, което влошава способността на модела да отговори на действителната потребителска заявка. В резултат на това крайното отговор е по-вероятно да пропусне ключови факти, да отдаде прекалено голямо значение на нискокачествената информация или да генерира твърдения, които са по-трудни за обосноваване в източника.

Второ, това води до регресия на закъснението. По-дългият контекст означава повече токени за обработка от следващия модел по веригата, особено когато една заявка се нуждае от доказателства от много страници кандидати. Въпреки че част от тази цена за закъснение се поема на етапа на предварително попълване, много по-значителна цена се плаща при разсъжденията, като моделите изискват повече токени за разсъждение, за да се справят с нерелевантния контекст.

Трето, това повишава разходите. Всеки ненужен токен, предаден на модела, прави обслужването на заявката на потребителя по-скъпо, тъй като използването както на входните токени, така и на токените за разсъждение се увеличава с по-шумния контекст. Разсейващите елементи не просто намаляват качеството; те в крайна сметка ви принуждават да плащате повече за това по-лошо качество.

Уголеми

За да подобрим едновременно точността, скоростта и икономическата ефективност в приложенията и API платформата на Perplexity, ние инвестираме сериозно в подобряване на точността на контекста. Един от начините да направим това е чрез усъвършенстване на нашите алгоритми за генериране на откъси. Ние третираме генерирането на откъси като проблем с компресията на контекста. Моделите, които търсят конкретна информация, нямат полза от обобщени резюмета или откъси от документ. Вместо това те се нуждаят от най-малката, най-прецизно извлечена част от изходната информация, за да отговорят на заявката на потребителя. Всичко останало може и трябва да бъде премахнато.

Следователно добвият откъс трябва да прави три неща:

Да насърчава точността, като представя прецизните доказателства, необходими за обосноваване на отговора на модела.

Да намалява закъснението и разходите чрез премахване на нерелевантния контекст преди извикването на големия езиков модел (LLM).

Да гарантира проследимост чрез запазване на точността на цитирането и запазване на формулировката на източника непокътната.

Този месец разгърнахме нов, съвременен генератор на откъси в нашите приложения и API платформа. Ядрото на този модул е модел за компресиране на контекста, съобразен със заявката, който решава за всяка заявка и кандидат-резултат кой подмножество от интервали трябва да бъде запазено. Тази статия описва нашия подход към изграждането и обучението на модела за постигане на най-добра в класа си производителност по тази критична задача.

Откъсите като компресия, съобразена със заявката

Първата задача е да се дефинира самата задача. Какво искаме да прави този модел и как трябва да дефинираме входната и изходната схема?

Методите за откъси се разделят на две основни семейства. Първото е базирано на избор: намерете релевантен прозорец, блок, изречение или пасаж и го предайте нататък. Второто е базирано на генериране: помолете модел да напише резюме, фокусирано върху заявката, от страницата.

Нашият фокус върху точността, закъснението и разходите прави избора на дизайн ясен. Можем да отхвърлим генерирането, тъй като създаването на ново резюме за всяка страница влошава производителността и по трите фокуса. Резюмирането е неподходящо за слоя от доказателства, който ни интересува. То може да преформулира източника, което затруднява съгласуването на цитатите. То може също така да въведе формулировки, които не са присъствали на страницата, което е рисковано, когато откъсът се използва като доказателство, а не като окончателен отговор. Включените закъснение и разходи правят генерирането още по-неприемливо.

Вместо това дефинираме нашата задача като извличаща компресия, съобразена със заявката: разделяне на полезните части от извлечения контекст от разсейващите части. По-конкретно, нашият модел трябва да приема заявка и резултат кандидат и да решава кои интервали да запази – тези, които най-добре поддържат заявката, и кои да отхвърли – останалите. Изходът на модела запазва изходния текст, вместо да го пренаписва. Това прави резултата по-лесен за цитиране, по-лесен за проверка и по-евтин за предаване надолу по веригата.

Например разгледайте тази заявка и извлечен резултат:

Уголеми

Плаузибилен изход на модела би бил изборът на удебеленото изречение: „В Comet асистентът може ...“.

Нашият подход следва същата обща идея като предишна работа по компресиране на контекста като FliCo, Provence и LooComp, адаптирана за генериране на откъси в производсвена система за търсене. Важно е, че моделът работи като етап на прецизност след нашия етап на сурово извличане. Както бе обсъдено в нашата предишна статия за изследвания на Perplexity, Представяне на Perplexity Search API, ние проектираме нашите системи за извличане да работят естествено на ниво поддокумент или откъс, което вече ни позволява да балансираме доста добре между прецизност и пълнота. Въвеждането на модел за компресиране на контекста, съобразен със заявката, избутва границата на Парето за прецизност и пълнота още по-напред.

Изграждане и обучение на модел за компресиране на контекста

Разработваме нашия модел с три основни съображения: съвместно разбиране на заявката и контекста, фино зърнест избор на ниво изречение и ефективност за вписване в изключително строг бюджет за закъснение.

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

Използваме модел pplx-diffusion като гръбнак. Това е същото семейство модели зад pplx-embed-v1 и както предишната ни академична работа, Дифузионно предварително обучени плътни и контекстуални вграждания, така и нашите производствени бенчмаркове потвърждават, че той е силен двупосочен енкодер за двойки заявка-контекст. Едно от ключовите свойства на това семейство модели е двупосочният контекст: всяко представяне на токен може да обърне внимание на пълната заявка и пълния контекст на кандидата, преди моделът да реши какво трябва да бъде запазено.

Върху този гръбнак тренираме лека глава за компресия, която предсказва кои части от контекста трябва да бъдат запазени. Тъй като няма генериране, тези прогнози се правят паралелно в целия контекст. В момента на обслужване двигателят за откъси агрегира тези прогнози на ниво изречение, прилага праг и изрязва резултата до заявения бюджет от токени.

Конвейер за надзор

Обучението на този компресор изисква надзор на правилното ниво на гранулиране. Етикет за релевантност на ниво документ е напълно неподходящ за нашата задача за извличаща компресия. За да генерираме достатъчно гранулирани данни за контролирано обучение, изградихме конвейер за етикетиране на интервали, който отбелязва релевантни за заявката интервали с доказателства, заедно с интервали с разсейващи елементи, които трябва да бъдат премахнати.

Нашият конвейер използва настройка на голям езиков модел като съдия (LLM-as-a-judge). Като се даде потребителска заявка и уеб страница кандидат със своята връзка, заглавие и резюме, съдията първо извършва разбиране на заявката, анализирайки заявката и изготвяйки списък с възможни потребителски намерения. Опирайки се на тези намерения, съдията след това обработва контекста на кандидата и връща интервали, копирани буквално от текста, с категория за всеки интервал, за да направи етикетите по-лесни за проверка.

След това съпоставихме върнатите интервали обратно към изходния текст. Нищо чудно, че повечето изходи на съдията вече бяха точни копия: наивното съвпадение на низове възстанови 98% от интервалите. Добавянето на опростен подход за съвпадение, базиран на регулярни изрази (regex), доведе възстановяването на интервалите до 100%. Това ни даде надеждни, гранулирани интервали, които могат да бъдат преобразувани в надзор за запазване/премахване на ниво токен.

Оценихме този конвейер за надзор, използвайки малък подбран набор от данни с ръчно етикетирани интервали, като сравнихме по-малки модели съдии, различни подкани и различни конфигурации на стъпки. Най-ефективната настройка беше двуетапен конвейер: първо разбиране на заявката, последвано от категоризирано етикетиране на интервали. Ние също така валидирахме набора от извлечени интервали чрез проверки за верифицируемост надолу по веригата, като BrowseComp и SimpleQA, където използването само на запазените интервали с доказателства запази силни резултати, като същевременно значително намали входните токени.

Използвайки този конвейер, етикетирахме 750 хиляди двойки заявка-документ и използваме получените интервали за обучение на главата за компресия с двоична кръстосана ентропия. Този процес позволява на нашия модел за компресия, съобразен със заявката, да запази изходния текст непокътнат, като същевременно премахва контекста, който е малко вероятно да помогне на низходящия модел да обслужи заявката на потребителя.

Гарантиране на латентност в реално време

Компресията на контекста се намира преди низходящия модел, което я прави блокираща операция. Освен това всяка компресия зависи от заявката. Следователно онлайн пътищата трябва да оценяват двойки заявка-контекст за всеки документ кандидат в рамките на строг диапазон на латентност. Бавният модел на компресия е саморазрушителен, тъй като ползите от латентността от по-високата прецизност се заличават от самите латентности на компресията. В същото време един по-малко интелигентен модел за компресия ще прави по-лоши решения относно това какво да бъде изрязано и запазено.

Практическият въпрос е колко от капацитета на модела можем безопасно да премахнем, преди качеството на компресията да започне да се влошава. Сравняваме пълния 28-слоен гръбнак pplx-diffusion с 11-слойни и 17-слойни варианти, получени чрез подрязване на слоеве и насочени към пътя за търсене. За всеки от тях преминаваме през прага на компресия и измерваме две количества: средния брой контекстни токени, изпратени надолу по веригата на заявка, и частта от полезните доказателства, запазени след компресия.

Фигура 2 показва границата качество-ефективност. Един модел е по-добър, когато се движи към горния ляв ъгъл: по-малко токени надолу по веригата с повече запазени полезни доказателства. 28-слойният модел осигурява референтната стойност за качество. 11-слойният модел демонстрира рисковете от твърде агресивно компресиране на модела. Подрязаният 17-слоен модел представлява средно положение: той следва отблизо 28-слойния модел в наситения режим, но се отваря малка празнина в стръмната част на кривата, където работи по-голямата част от производствения трафик.

За да затворим тази празнина, използваме дистилация на знания на ниво токени. Нашият подход е рутинен: разширяваме стандартната загуба с мек термин на кръстосана ентропия върху прогнозите на модела учител, претеглен с коефициент на дистилация. Това е достатъчно, за да доведе модела ученик до паритет, което ни позволява напълно да преминем към дистилирания 17-слоен модел в производството. Този нов производствен модел води до 35-40% намаление на латентността при инференция и 40-45% намаление на общите изчисления на графичния процесор (GPU) без спад на качеството спрямо 28-слойния учител. Производствената латентност е под 20 ms (p99): достатъчно малка, за да бъде добавена към пътя на обслужване, като същевременно значително се намаляват общите токени, подадени към модела за отговор.

Уголеми

Качество и ефективност на токените

Използваме Agent API на Perplexity като изпитвателна площадка за анализ на ефективността на компресията на контекста. Оценяваме три предварителни настройки на Agent API:

„Нисък“ контекстен пресет, който ограничава бюджета за токени за всеки набор от резултати до 1000 токена.

„Среден“ контекстен пресет, който ограничава бюджета за токени за всеки набор от резултати до 4000 токена.

„Висък“ контекстен пресет, който ограничава бюджета за токени за всеки набор от резултати до 10000 токена.

Как стандартните настройки без компресия, така и настройките за компресия са конфигурирани да спазват тези бюджети за токени.

Агентно многостъпково търсене (BrowseComp)

Първо разглеждаме въздействието на компресията върху работните процеси на агентно многостъпково търсене върху бенчмарка BrowseComp. Извършваме тази оценка, като използваме нашия софтуер с отворен код search_evals. Оценяването е идентично за всички изпълнения, като се използва каноничната подкана за съдия LLM на BrowseComp на OpenAI.

Двете измерения от интерес са точността на бенчмарка и използването на токени. Важно е, че измерваме използването на токени на ниво заявка, а не на ниво отделна стъпка, за да измерим действителното натоварване с токени, направено през жизнения цикъл на заявката. Фигура 3 показва границата „резултат-токен“, резултат за точност спрямо използване на токени.

Уголеми

Компресията осигурява нова граница на Парето навсякъде. За всяка настройка въвеждането на компресия намалява използването на токени на ниво заявка с от 10% до 70%, като придобивките в точността се движат между 4 и 4,81 процентни пункта. Въвеждането на компресия позволява дори на нашия „нисък“ пресет да надмисне „високия“ пресет без компресия, при това намалявайки използването на токени повече от три пъти.

Наблюдаваме, че с компресията „високият“ пресет дава по-голяма точност от „средния“, както бихме могли да очакваме. Интересното е обаче, че той прави това при по-ниско използване на токени. Това разкрива фин, но важен ефект от компресията: с компресията дори увеличаването на размера на контекста за стъпка може да даде възможност на модела да предприеме по-малко стъпки, за да стигне до правилния резултат. Изследването на тази немонотонност е обещаващо направление за бъдеща работа.

SimpleQA: едностъпкова фактологичност

BrowseComp акцентира върху многостъпковите проучвания, но много производствени работни процеси включват едностъпково търсене на факти. За да определим дали компресията помага и в едностъпковия режим, разглеждаме и производителността на SimpleQA, бенчмарк, състоящ се от 4326 въпроса, на които трябва да се отговори в рамките на една стъпка на търсене, а не на агентен цикъл.

Както и преди, нанасяме точността срещу средния общ брой токени на задача, като използваме каноничната подкана за съдия. Фигура 4 показва границата резултат-токен в тази едностъпкова настройка. Въпреки че ефектите са по-компресирани в едностъпковата настройка, отново забелязваме, че компресията едновременно подобрява точността и ефективността във всички пресети, като по този начин въвежда нова граница на Парето. С активирана компресия средният пресет постига 95% точност със средно само 200 токена на документ. Като се има предвид средната дължина на документа от над 10 000 токена, това представлява производителност на ниво граница при коефициент на компресия над 50.

Уголеми

Какво попада в откъсите?

Подобренията надолу по веригата в раздели 4.1 и 4.2 са крайни (end-to-end). За да разберем как компресията променя отделните откъси, пускаме отделна оценка, която използва съдия LLM за класифициране на всеки токен от всеки извлечен откъс в една от шест категории:

Жизненоважно: доказателства, съществени за отговора на заявката на потребителя.

Извън темата: информация, която може да бъде полезна за друга цел, но не е свързана с разглежданата заявка.

Реклами: нерелевантна реклама, която разсейва от отговора на заявката на потребителя.

Метаданни: метаданни за съдържанието на документа.

Потребителски интерфейс и навигация: елементи за фронтенд показване и навигация.

Дубликат: повтаряне на преди това включена информация.

Нашата оценка се провежда на 1000 заявки със смесен домейн от нашия набор за валидиране, като се сравнява производственият стек с иначе идентичен бейзлайн с деактивирана компресия. Както е показано на фигура 5, компресията увеличава дела на жизненоважните токени на откъс средно с 63% спрямо бейзлайна без компресия. Наблюдаваме съответно намаление от 29% на нерелевантните токени, с особено стръмни спадове в потребителския интерфейс/навигацията (-58%), метаданните (-46%) и рекламите (-43%). Тези резултати потвърждават механизма за подобренията на качеството и ефективността, обсъдени по-горе: компресията подобрява производителността в двете измерения чрез рязко увеличаване на съотношението сигнал/шум на всеки отделен откъс.

Уголеми

Фигура 6 илюстрира тази промяна за отделна заявка. За заявката „прием на мляко от 6-дневно новородено на хранене“ показваме както некомпресираните, базовите, така и компресираните откъси. Компресията елиминира нежизненоважните категории съдържание и запазва само информацията за храненето, свързана с новороденото. Важно е, че компресията успешно елиминира съдържание, което може да е общо взето по темата за страницата, но извън темата за тази конкретна заявка, фокус върху новороденото.

Уголеми

Заключение

Системите с изкуствен интелект разчитат на информация с висок сигнал, за да обслужват интелигентно и ефективно заявките на потребителите. Тази информация трябва да бъде представена възможно най-хирургично, за да се максимизира релевантността към всяка заявка. Нашите нови модели за компресия, съобразени със заявката, правят точно това, като максимизират доказателствата по темата на откъс и агресивно премахват нерелевантните разсейващи елементи.

Чрез внедряването на тези нови модели в нашия стек за търсене можем да предоставим по-бързи и по-добри отговори на тези, които разчитат на нашите продукти и API. Нашият подход създава опростена повърхност за управление, позволяваща на нашите системи и клиенти на API да настройват степента на компресия, за да балансират между извличане, латентност и разходи.

Курирането на контекст е развиваща се област и има още много работа за вършене за оптимизиране на стойността на всеки токен, използван в днешните модерни разузнавателни системи. Ние работим активно за подобряване на нашите техники за куриране на контекст както чрез подобрения на моделите, така и чрез системна архитектура, за да използваме още по-обширно тези модели.

Препратки

N. Chirkova, T. Formal, V. Nikoulina и S. Clinchant. Provence: Ефективно и надеждно подрязване на контекста за генерация, подпомогната от извличане (Retrieval-Augmented Generation), 2025. Прието за ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim и D. Kim. LooComp: Използване на стратегията Leave-One-Out към Transformer само за енкодер за ефективна компресия на контекста, съобразена със заявката, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang и D. Bykov. Дифузионно предварително обучени плътни и контекстуални вграждания, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez и G. Neubig. Обучение за филтриране на контекста за генерация, подпомогната от извличане (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://www.perplexity.ai/hub/blog/query-aware-context-compression-for-better-snippets}
}