Сжатие контекста с учетом запроса для улучшения сниппетов

Любой ответ начинается с доказательств. В поисковой системе эти доказательства обычно поступают из документов: заголовков, аннотаций, фрагментов и отрывков, которые передаются в качестве контекста модели ответов или агенту.

Этот необработанный контекст содержит много «шума». Например, веб-страница может содержать информацию, необходимую для запроса пользователя, но в ней также могут присутствовать отвлекающие факторы. Эти факторы могут встречаться как в основном тексте, так и во вспомогательных элементах, таких как элементы навигации, нерелевантная реклама, метаданные и многое другое. Передача этих отвлекающих факторов подчиненному агенту создает три проблемы.

Во-первых, это снижает точность. Даже самые мощные модели обладают ограниченной емкостью. Длинные потоки нерелевантной информации растрачивают ресурсы модели, приводя к «контекстному гниению», которое ухудшает способность модели отвечать на фактический запрос пользователя. В результате итоговый ответ с большей вероятностью пропустит ключевые факты, придаст избыточный вес некачественной информации или приведет к утверждениям, которые трудно обосновать источником.

Во-вторых, это негативно влияет на задержку. Увеличенный контекст означает больше токенов для обработки подчиненной моделью, особенно когда запросу требуются доказательства из множества страниц-кандидатов. Хотя часть этих затрат на задержку возникает на этапе префиллинга, гораздо более существенные затраты приходятся на логические рассуждения, поскольку моделям требуется больше токенов рассуждений для работы с нерелевантным контекстом.

В-третьих, это повышает стоимость. Каждый лишний токен, переданный модели, увеличивает стоимость обслуживания запроса пользователя, так как потребление токенов как на вводе, так и на этапе рассуждений возрастает при наличии «шумного» контекста. Отвлекающие факторы не просто снижают качество; в конечном итоге они вынуждают вас платить больше за это худшее качество.

Развернуть

Чтобы одновременно повысить точность, скорость и экономическую эффективность приложений Perplexity и API Platform, мы активно инвестируем в улучшение точности контекста. Один из способов сделать это — совершенствование наших алгоритмов генерации сниппетов. Мы рассматриваем генерацию сниппетов как проблему сжатия контекста. Моделям, ищущим конкретную информацию, не приносят пользы обобщенные аннотации или выдержки из документа. Скорее, им требуется наименьший, наиболее точно извлеченный фрагмент исходной информации для ответа на запрос пользователя. Все остальное может и должно быть удалено.

Хороший сниппет поэтому должен выполнять три функции:

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

Снижать задержку и стоимость за счет удаления нерелевантного контекста до вызова LLM.

Обеспечивать прослеживаемость путем сохранения достоверности цитирования и сохранения исходной формулировки текста.

В этом месяце мы развернули новый современный генератор сниппетов в наших приложениях и API Platform. Основой этого модуля является модель сжатия контекста с учетом запроса, которая определяет для каждого запроса и результата-кандидата подмножество фрагментов текста, которые следует сохранить. В этой статье описывается наш подход к созданию и обучению модели для достижения наилучшей в своем классе производительности в этой важной задаче.

Сниппеты как сжатие с учетом запроса

Первоочередная задача — определить саму суть задания. Что мы хотим, чтобы эта модель делала, и как нам следует определить схему ввода и вывода?

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

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

Скорее, мы определяем нашу задачу как экстрактивное сжатие с учетом запроса: отделение полезных частей извлеченного контекста от отвлекающих частей. В частности, наша модель должна принимать запрос и результат-кандидат, а затем решать, какие фрагменты текста сохранить — те, которые лучше всего подтверждают запрос, — а какие отбросить. Выходные данные модели сохраняют исходный текст, а не переписывают его. Это делает результат более легким для цитирования, проверки и более дешевым для передачи дальше.

Например, рассмотрим этот запрос и извлеченный результат:

Развернуть

Правдоподобным выходным результатом модели было бы выделение жирным шрифтом предложения: «В Comet помощник может ...».

Наш подход следует той же общей идее, что и предыдущие работы по сжатию контекста, такие как FliCo, Provence и LooComp, адаптированные для генерации сниппетов в производственной поисковой системе. Важно отметить, что модель работает как этап уточнения после нашего этапа первичного извлечения. Как обсуждалось в нашей предыдущей статье Perplexity Research «Представляем API поиска Perplexity», мы проектируем наши системы поиска так, чтобы они работали на уровне поддокумента или сниппета, что уже позволяет нам достаточно хорошо сбалансировать точность и полноту. Внедрение модели сжатия контекста с учетом запроса еще больше смещает границу Парето точности и полноты.

Создание и обучение модели сжатия контекста

Мы разрабатываем нашу модель с учетом трех основных соображений: совместное понимание запроса и контекста, детальный выбор на уровне предложений и эффективность для соответствия крайне жестким ограничениям по задержке.

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

В качестве основы мы используем модель pplx-diffusion. Это то же семейство моделей, которое стоит за pplx-embed-v1, и как наша предыдущая научная работа «Диффузионные предобученные плотные и контекстуальные эмбеддинги», так и наши производственные тесты подтверждают, что это мощный двунаправленный кодировщик для пар запрос-контекст. Одним из ключевых свойств этого семейства моделей является двунаправленный контекст: каждое представление токена может учитывать полный запрос и полный контекст-кандидат, прежде чем модель решит, что следует оставить.

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

Конвейер супервизии

Обучение этого компрессора требует супервизии с правильным уровнем гранулярности. Метка релевантности на уровне документа явно не подходит для нашей задачи экстрактивного сжатия. Чтобы сгенерировать достаточно гранулярные данные для обучения с учителем, мы создали конвейер разметки фрагментов, который отмечает фрагменты доказательств, релевантные запросу, а также отвлекающие фрагменты, которые следует удалить.

Наш конвейер использует настройку «LLM как судья». Получая запрос пользователя и страницу-кандидат с ее ссылкой, заголовком и аннотацией, судья сначала выполняет понимание запроса, анализируя его и создавая список возможных намерений пользователя. Опираясь на эти намерения, судья затем обрабатывает контекст-кандидат и возвращает фрагменты, скопированные дословно из текста, с категорией для каждого фрагмента, чтобы облегчить проверку меток.

Затем мы сопоставили возвращенные фрагменты с исходным текстом. Неудивительно, что большинство выходных данных судьи были уже точными копиями: наивное сопоставление строк восстановило 98% фрагментов. Добавление простого прохода сопоставления на основе регулярных выражений довело восстановление фрагментов до 100%. Это дало нам надежные, гранулярные фрагменты, которые можно было преобразовать в супервизию сохранения/удаления на уровне токенов.

Мы оценили этот конвейер супервизии, используя небольшой курируемый набор данных с вручную размеченными фрагментами, сравнивая модели судей меньшего размера, разные подсказки (промпты) и разные конфигурации шагов. Лучшей по производительности настройкой стал двухэтапный конвейер: сначала понимание запроса, затем категоризированная разметка фрагментов. Мы также валидировали набор извлеченных фрагментов с помощью последующих проверяемых оценок, таких как BrowseComp и SimpleQA, где использование только сохраненных фрагментов доказательств сохраняло высокие баллы при значительном сокращении входных токенов.

Используя этот конвейер, мы разметили 750 тысяч пар запрос-документ и используем полученные фрагменты для обучения головы сжатия с помощью бинарной кросс-энтропии. Этот процесс позволяет нашей модели сжатия с учетом запроса сохранять исходный текст нетронутым, удаляя при этом контекст, который вряд ли поможет подчиненной модели выполнить запрос пользователя.

Обеспечение задержки в режиме реального времени

Сжатие контекста находится перед подчиненной моделью, что делает его блокирующей операцией. Более того, каждое сжатие зависит от запроса. Следовательно, путь онлайн-обработки должен оценивать пары запрос-контекст для каждого документа-кандидата в рамках жесткого ограничения по задержке. Медленная модель сжатия противоречит самой себе, так как выигрыши в задержке от более высокой точности стираются самой задержкой сжатия. В то же время менее интеллектуальная модель сжатия будет принимать более неудачные решения о том, что вырезать, а что оставить.

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

Рисунок 2 показывает границу качества-эффективности. Модель лучше, когда она движется к верхнему левому углу: меньше токенов на выходе при большем количестве сохраненных полезных доказательств. 28-слойная модель предоставляет эталон качества. 11-слойная модель демонстрирует риски слишком агрессивного сжатия модели. 17-слойная модель с прунингом представляет собой «золотую середину»: она близко следует за 28-слойной моделью в насыщенном режиме, но небольшой разрыв открывается на крутой части кривой, где работает большая часть производственного трафика.

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

Развернуть

Качество и эффективность использования токенов

Мы используем Agent API от Perplexity как тестовую площадку для анализа эффективности сжатия контекста. Мы оцениваем три пресета Agent API:

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

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

«Высокий» (high) пресет контекста, который ограничивает бюджет токенов для каждого набора результатов 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 являются сквозными. Чтобы понять, как сжатие меняет отдельные сниппеты, мы проводим отдельную оценку, которая использует судью LLM для классификации каждого токена каждого извлеченного сниппета по одной из шести категорий:

Жизненно важные (Vital): доказательства, необходимые для ответа на запрос пользователя.

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

Реклама (Ads): нерелевантная реклама, отвлекающая от ответа на запрос пользователя.

Метаданные (Metadata): метаданные о содержимом документа.

UI и навигация: элементы для отображения во фронтенде и навигации.

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

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

Развернуть

Рисунок 6 иллюстрирует это изменение для отдельного запроса. Для запроса «6 day old newborn milk intake per feeding» (потребление молока новорожденным в возрасте 6 дней за кормление) мы показываем как несжатые базовые, так и сжатые сниппеты. Сжатие исключает категории нежизненно важного контента и сохраняет только информацию о кормлении, связанную с новорожденными. Важно отметить, что сжатие успешно исключает контент, который может быть в целом по теме страницы, но не по теме для конкретного запроса о новорожденных.

Развернуть

Заключение

Системы ИИ полагаются на высокоинформативные данные, чтобы интеллектуально и эффективно обслуживать запросы пользователей. Эта информация должна быть представлена максимально точно, чтобы максимизировать релевантность каждому запросу. Наши новые модели сжатия с учетом запроса делают именно это, максимизируя количество доказательств по теме в каждом сниппете и агрессивно удаляя нерелевантные отвлекающие факторы.

Развертывая эти новые модели в нашем поисковом стеке, мы можем предоставлять более быстрые и качественные ответы тем, кто полагается на наши продукты и API. Наш подход создает простую поверхность управления, позволяя нашим системам и клиентам API настраивать степень сжатия для баланса между полнотой, задержкой и стоимостью.

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

Ссылки

Н. Чиркова, Т. Формаль, В. Никулина и С. Клиншан. Provence: Эффективное и надежное прунинг контекста для генерации с поисковой аугментацией, 2025. Принято на ICLR 2025. arXiv:2501.16214.

Т. До, Д. П. Тран, А. Во, С. К. Ким и Д. Ким. LooComp: Использование стратегии Leave-One-Out для Трансформера (только кодировщик) для эффективного сжатия контекста с учетом запроса, 2026. arXiv:2603.09222.

С. Эслами, М. Гайдук, М. Криммель, Л. Милликен, Б. Ван и Д. Быков. Диффузионные предобученные плотные и контекстуальные эмбеддинги, 2026. arXiv:2602.11151.

З. Ван, Дж. Араки, З. Цзян, М. Р. Парвез и Г. Нойбиг. Обучение фильтрации контекста для генерации с поисковой аугментацией, 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}
}