더 나은 스니펫을 위한 쿼리 인식 컨텍스트 압축

모든 답변은 증거에서 시작됩니다. 검색 시스템에서 이러한 증거는 일반적으로 문서, 즉 답변 모델이나 에이전트에 컨텍스트로 전달되는 제목, 요약, 청크 및 스니펫에서 비롯됩니다.

이 원시 컨텍스트에는 노이즈가 포함되어 있습니다. 예를 들어, 웹 페이지에는 사용자의 요청에 필요한 정보가 포함되어 있을 수 있지만, 주의를 분산시키는 요소도 포함되어 있을 수 있습니다. 이러한 주의 분산 요소는 본문뿐만 아니라 탐색 텍스트 요소, 관련 없는 광고, 메타데이터 등과 같은 부수적인 요소에도 나타날 수 있습니다. 이러한 주의 분산 요소를 다운스트림 에이전트에 전달하면 세 가지 문제가 발생합니다.

첫째, 정확도가 저하됩니다. 가장 강력한 모델조차도 유한한 용량을 가집니다. 관련 없는 정보가 긴 스트림으로 유입되면 모델 용량이 낭비되어 실제 사용자 요청을 처리하는 모델의 능력을 저하시키는 "컨텍스트 로트(context rot)"가 발생합니다. 결과적으로 최종 응답에서 주요 사실이 누락되거나, 품질이 낮은 정보에 너무 많은 가중치를 두거나, 출처에 근거하기 어려운 주장을 생성할 가능성이 높아집니다.

둘째, 대기 시간이 길어집니다. 컨텍스트가 길어지면 쿼리에 많은 후보 페이지의 증거가 필요할 때 특히 다운스트림 모델이 처리해야 할 토큰이 많아집니다. 이러한 대기 시간 비용의 일부는 프리필(prefill) 단계에서 발생하지만, 훨씬 더 중요한 비용은 관련 없는 컨텍스트를 처리하기 위해 더 많은 추론 토큰이 필요한 추론 단계에서 발생합니다.

셋째, 비용이 증가합니다. 모델에 전달되는 불필요한 모든 토큰은 사용자 요청을 처리하는 비용을 증가시킵니다. 컨텍스트에 노이즈가 많을수록 입력 토큰과 추론 토큰 사용량이 모두 증가하기 때문입니다. 주의 분산 요소는 품질을 저하시킬 뿐만 아니라, 결국 품질 저하에 대해 더 많은 비용을 지불하게 만듭니다.

확대

Perplexity의 애플리케이션과 API Platform 전반에 걸쳐 정확도, 속도 및 비용 효율성을 동시에 향상시키기 위해 당사는 컨텍스트 정밀도 향상에 많은 투자를 하고 있습니다. 이를 위한 방법 중 하나는 스니펫 생성 알고리즘을 개선하는 것입니다. 당사는 스니펫 생성을 컨텍스트 압축 문제로 취급합니다. 특정 정보를 찾는 모델은 문서의 일반화된 요약이나 발췌문으로부터 이득을 얻지 못합니다. 오히려 모델은 사용자 요청에 응답하기 위해 소스 정보 중에서 가장 작고 가장 정밀하게 추출된 부분을 필요로 합니다. 그 외의 모든 것은 제거될 수 있으며 반드시 제거되어야 합니다.

따라서 좋은 스니펫은 다음 세 가지를 수행해야 합니다:

모델의 응답을 뒷받침하는 데 필요한 정확한 증거를 제시하여 정확도를 높입니다.

LLM 호출 전에 관련 없는 컨텍스트를 제거하여 대기 시간과 비용을 줄입니다.

인용의 정확성을 유지하고 원문의 표현을 온전하게 보존하여 추적 가능성을 보장합니다.

이번 달에 당사는 애플리케이션 및 API Platform 내에 새로운 최첨단 스니펫 생성기를 배포했습니다. 이 모듈의 핵심은 각 쿼리 및 후보 결과에 대해 보존되어야 할 스팬의 하위 집합을 결정하는 쿼리 인식 컨텍스트 압축 모델입니다. 이 기사에서는 이 중요한 작업에서 동급 최고의 성능을 달성하기 위해 모델을 구축하고 학습시키는 당사의 접근 방식을 설명합니다.

쿼리 인식 압축으로서의 스니펫

첫 번째 당면 과제는 작업 자체를 정의하는 것입니다. 우리는 이 모델이 무엇을 수행하기를 원하며, 입력 및 출력 스키마를 어떻게 정의해야 할까요?

스니펫 방법은 크게 두 가지 범주로 나뉩니다. 첫 번째는 선택 기반 방식으로, 관련 윈도우, 청크, 문장 또는 구절을 찾아 다운스트림으로 전달하는 것입니다. 두 번째는 생성 기반 방식으로, 모델에게 페이지에서 쿼리 중심의 요약을 작성하도록 요청하는 것입니다.

정확도, 대기 시간 및 비용에 대한 당사의 초점은 설계 선택을 명확하게 합니다. 모든 페이지에 대해 새로운 요약을 생성하는 것은 세 가지 목표 모두에서 성능을 저하시키기 때문에 생성 방식을 배제할 수 있습니다. 요약은 우리가 중요하게 생각하는 증거 계층에는 적합하지 않습니다. 소스를 의역하여 인용 정렬을 더 어렵게 만들 수 있습니다. 또한 스니펫이 최종 답변이 아닌 증거로 사용될 때 위험한, 페이지에 존재하지 않았던 표현을 도입할 수도 있습니다. 이와 관련된 대기 시간과 비용은 생성 방식을 더욱 부적합하게 만듭니다.

대신, 당사는 작업을 쿼리 인식 추출형 압축으로 정의합니다. 즉, 검색된 컨텍스트에서 도움이 되는 부분과 주의를 산만하게 하는 부분을 분리하는 것입니다. 구체적으로 당사의 모델은 쿼리와 후보 결과를 받아 어떤 스팬을 보존할지(쿼리를 가장 잘 뒷받침하는 것)와 어떤 스팬을 삭제할지(나머지)를 결정해야 합니다. 모델 출력은 원문을 다시 작성하는 대신 보존합니다. 이를 통해 결과를 인용하기 쉽고, 검증하기 쉬우며, 다운스트림으로 전달하는 비용이 저렴해집니다.

예를 들어, 이 쿼리와 검색된 결과를 고려해 보십시오:

확대

그럴듯한 모델 출력은 굵게 표시된 문장인 "Comet에서 어시스턴트는 ..."을 선택하는 것입니다.

당사의 접근 방식은 프로덕션 검색 시스템의 스니펫 생성을 위해 조정된 FliCo, Provence, LooComp와 같은 이전 컨텍스트 압축 연구와 동일한 광범위한 아이디어를 따릅니다. 중요하게도, 이 모델은 원시 검색 단계 이후의 정밀도 단계로서 작동합니다. 이전 Perplexity 연구 기사인 Introducing the Perplexity Search API에서 논의한 바와 같이, 당사는 검색 시스템을 문서 하위 수준 또는 스니펫 수준에서 기본적으로 작동하도록 설계하여 정밀도와 재현율을 이미 잘 균형 잡고 있습니다. 쿼리 인식 컨텍스트 압축 모델을 도입하면 정밀도-재현율 파레토 프론티어가 훨씬 더 밖으로 이동합니다.

컨텍스트 압축 모델 구축 및 학습

당사는 쿼리와 컨텍스트에 대한 공동 이해, 세밀한 문장 수준 선택, 그리고 극도로 촉박한 대기 시간 예산 내에 맞추기 위한 효율성이라는 세 가지 주요 고려 사항을 염두에 두고 모델을 개발합니다.

모델 아키텍처

당사는 pplx-diffusion 모델을 백본으로 사용합니다. 이는 pplx-embed-v1의 기반이 되는 동일한 모델 제품군이며, 당사의 이전 학술 연구인 Diffusion-Pretrained Dense and Contextual Embeddings와 프로덕션 벤치마크 모두에서 쿼리-컨텍스트 쌍을 위한 강력한 양방향 인코더임이 확인되었습니다. 이 모델 제품군의 핵심 속성 중 하나는 양방향 컨텍스트입니다. 각 토큰 표현은 모델이 무엇을 유지할지 결정하기 전에 전체 쿼리와 전체 후보 컨텍스트를 모두 어텐션할 수 있습니다.

이 백본 위에 당사는 컨텍스트 중 어떤 부분을 유지할지 예측하는 경량 압축 헤드를 학습시킵니다. 생성이 포함되지 않기 때문에 이러한 예측은 전체 컨텍스트에 걸쳐 병렬로 수행됩니다. 서빙 시점에 스니펫 엔진은 이러한 예측을 문장 수준에서 집계하고, 임계값을 적용하며, 결과를 요청된 토큰 예산에 맞춰 다듬습니다.

지도 학습 파이프라인

이 압축기를 학습시키려면 적절한 수준의 세분화된 감독이 필요합니다. 문서 수준의 관련성 라벨은 당사의 추출형 압축 작업에 전혀 적합하지 않습니다. 지도 학습을 위해 충분히 세분화된 데이터를 생성하기 위해 당사는 쿼리 관련 증거 스팬과 제거해야 할 주의 분산 스팬을 표시하는 스팬 라벨링 파이프라인을 구축했습니다.

당사의 파이프라인은 LLM-as-a-judge(심사위원으로서의 LLM) 설정을 사용합니다. 사용자 쿼리와 링크, 제목 및 요약이 포함된 후보 웹 페이지가 주어지면, 심사위원은 먼저 쿼리를 분석하고 가능한 사용자 의도 목록을 생성하여 쿼리 이해를 수행합니다. 이러한 의도를 기반으로 심사위원은 후보 컨텍스트를 처리하고 텍스트에서 그대로 복사된 스팬을 반환하며, 라벨을 검사하기 쉽도록 각 스팬에 대한 범주를 함께 제공합니다.

그런 다음 당사는 반환된 스팬을 원문과 다시 일치시켰습니다. 예상대로 대부분의 심사위원 출력은 이미 정확한 복사본이었습니다. 단순 문자열 일치로 스팬의 98%를 복구했습니다. 간단한 정규 표현식 기반 일치 단계를 추가하여 스팬 복구율을 100%로 높였습니다. 이를 통해 토큰 수준의 유지/삭제 감독으로 변환할 수 있는 신뢰할 수 있고 세분화된 스팬을 얻었습니다.

당사는 수동으로 라벨이 지정된 스팬이 있는 소규모 큐레이션 데이터셋을 사용하여 이 감독 파이프라인을 평가하고, 더 작은 심사위원 모델, 다양한 프롬프트 및 다양한 단계 구성을 비교했습니다. 가장 성능이 좋은 설정은 2단계 파이프라인이었습니다. 먼저 쿼리 이해를 수행하고 이어서 범주화된 스팬 라벨링을 수행하는 것입니다. 또한 당사는 BrowseComp 및 SimpleQA와 같은 다운스트림 검증 평가를 통해 추출된 스팬 세트를 검증했습니다. 여기에서는 유지된 증거 스팬만 사용해도 높은 점수를 유지하면서 입력 토큰을 크게 줄였습니다.

이 파이프라인을 사용하여 75만 개의 쿼리-문서 쌍에 라벨을 지정하고, 생성된 스팬을 사용하여 이진 교차 엔트로피로 압축 헤드를 학습시켰습니다. 이 과정을 통해 당사의 쿼리 인식 압축 모델은 원문을 그대로 유지하면서 다운스트림 모델이 사용자 요청을 처리하는 데 도움이 되지 않을 가능성이 높은 컨텍스트를 제거할 수 있습니다.

실시간 대기 시간 보장

컨텍스트 압축은 다운스트림 모델 앞에 위치하므로 차단 작업이 됩니다. 더욱이 각 압축은 쿼리에 의존합니다. 따라서 온라인 경로는 정확한 대기 시간 범위 내에서 모든 후보 문서에 대해 쿼리-컨텍스트 쌍의 점수를 매겨야 합니다. 느린 압축 모델은 정밀도 향상으로 인한 대기 시간 이점이 압축 대기 시간 자체에 의해 상쇄되기 때문에 스스로를 무력화시킵니다. 동시에 지능이 낮은 압축 모델은 무엇을 자르고 유지할지에 대해 더 나쁜 결정을 내릴 것입니다.

실질적인 질문은 압축 품질이 저하되기 전에 모델 용량을 얼마나 안전하게 제거할 수 있는가입니다. 당사는 레이어 가지치기를 통해 생성되고 검색 경로를 대상으로 하는 11레이어 및 17레이어 변형과 전체 28레이어 pplx-diffusion 백본을 비교합니다. 각각에 대해 압축 임계값을 조정하고 두 가지 양, 즉 쿼리당 다운스트림으로 전송되는 평균 컨텍스트 토큰 수와 압축 후 보존된 유용한 증거의 비율을 측정합니다.

그림 2는 품질-효율성 프론티어를 보여줍니다. 모델은 왼쪽 상단으로 이동할 때 더 좋습니다. 즉, 더 유용한 증거가 보존되면서 다운스트림 토큰은 더 적어집니다. 28레이어 모델은 품질 기준을 제공합니다. 11레이어 모델은 모델을 너무 공격적으로 압축할 때의 위험을 보여줍니다. 가지치기된 17레이어 모델은 중간 지점을 나타냅니다. 포화 상태에서는 28레이어 모델을 밀접하게 추적하지만, 대부분의 프로덕션 트래픽이 운영되는 곡선의 가파른 부분에서는 작은 격차가 발생합니다.

그 격차를 줄이기 위해 당사는 토큰 수준의 지식 증류를 사용합니다. 당사의 접근 방식은 일상적인 것입니다. 당사는 증류 계수에 의해 가중치가 부여된 티처 모델의 예측에 대한 소프트 교차 엔트로피 항으로 표준 손실을 보강합니다. 이것만으로도 스튜던트 모델을 동등한 수준으로 끌어올리기에 충분하며, 이를 통해 프로덕션에서 완전히 증류된 17레이어 모델로 전환할 수 있습니다. 이 새로운 프로덕션 모델은 28레이어 티처 모델 대비 품질 저하 없이 추론 대기 시간을 35-40% 감소시키고 총 GPU 컴퓨팅을 40-45% 감소시킵니다. 프로덕션 대기 시간은 20ms(p99) 미만으로 기록되어, 답변 모델로 전달되는 총 토큰을 크게 줄이면서 서빙 경로에 추가하기에 충분히 작습니다.

확대

품질 및 토큰 효율성

당사는 컨텍스트 압축의 효과를 분석하기 위한 테스트베드로 Perplexity의 Agent API를 사용합니다. 당사는 세 가지 Agent API 사전 설정을 평가합니다:

각 결과 세트에 대한 토큰 예산을 1000 토큰으로 제한하는 "낮음" 컨텍스트 사전 설정.

각 결과 세트에 대한 토큰 예산을 4000 토큰으로 제한하는 "중간" 컨텍스트 사전 설정.

각 결과 세트에 대한 토큰 예산을 10000 토큰으로 제한하는 "높음" 컨텍스트 사전 설정.

표준, 압축 없음 및 압축 설정 모두 이러한 토큰 예산을 준수하도록 구성됩니다.

에이전트식 다단계 검색(BrowseComp)

당사는 먼저 BrowseComp 벤치마크에서 에이전트식 다단계 검색 워크플로우에 미치는 압축의 영향을 조사합니다. 당사는 오픈 소스 search_evals 하네스를 사용하여 이 평가를 수행합니다. 평가 점수는 OpenAI의 표준 BrowseComp LLM judge prompt를 사용하여 모든 실행에서 동일하게 산정됩니다.

관심 있는 두 가지 차원은 벤치마크 정확도와 토큰 사용량입니다. 중요하게도, 당사는 요청 수명 주기 전반에 걸쳐 발생하는 실제 토큰 부하를 측정하기 위해 개별 단계 수준이 아닌 쿼리 수준에서 토큰 사용량을 측정합니다. 그림 3은 "점수-토큰" 프론티어, 즉 정확도 점수 대 토큰 사용량을 보여줍니다.

확대

압축은 전반적으로 새로운 파레토 프론티어를 제공합니다. 각 설정에 대해 압축을 도입하면 쿼리 수준의 토큰 사용량이 10%에서 70%까지 감소하며, 정확도는 4에서 4.81 퍼센트 포인트 사이로 향상됩니다. 압축을 도입하면 "낮음" 사전 설정조차도 토큰 사용량을 3배 이상 줄이면서 압축 없는 "높음" 사전 설정을 능가할 수 있습니다.

당사는 압축을 사용하면 예상대로 "높음"이 "중간"보다 더 높은 정확도를 나타낸다는 점을 관찰했습니다. 그러나 흥미롭게도 이는 더 낮은 토큰 사용량에서 달성됩니다. 이는 압축의 미묘하지만 중요한 효과를 보여줍니다. 압축을 사용하면 단계별 컨텍스트 크기를 늘려도 모델이 올바른 결과에 도달하기 위해 수행하는 단계를 줄일 수 있습니다. 이러한 비단조성을 탐색하는 것은 향후 연구의 유망한 방향입니다.

SimpleQA: 단일 단계 사실성

BrowseComp는 다단계 조사를 강조하지만, 많은 프로덕션 워크플로우에는 단일 단계 사실 조회 작업이 포함됩니다. 압축이 단일 단계 체제에서도 도움이 되는지 확인하기 위해 당사는 에이전트식 루프가 아닌 단일 검색 단계에서 답변해야 하는 4,326개의 질문으로 구성된 벤치마크인 SimpleQA에서의 성능도 조사합니다.

이전과 마찬가지로 표준 심사위원 프롬프트를 사용하여 작업당 평균 총 토큰 대비 정확도를 플롯합니다. 그림 4는 이 단일 단계 설정에서의 점수-토큰 프론티어를 보여줍니다. 단일 단계 설정에서 효과 크기가 더 압축되지만, 당사는 다시 한번 압축이 모든 사전 설정에서 정확도와 효율성을 동시에 향상시켜 새로운 파레토 프론티어를 도입한다는 점을 관찰합니다. 압축을 활성화하면 중간 사전 설정은 문서당 평균 200 토큰만으로 95%의 정확도를 달성합니다. 평균 문서 길이가 10,000 토큰이 넘는다는 점을 감안할 때, 이는 50 이상의 압축률에서 프론티어 수준의 성능을 나타냅니다.

확대

스니펫에는 무엇이 포함될까요?

4.1절과 4.2절에서의 다운스트림 이점은 엔드 투 엔드 방식입니다. 압축이 개별 스니펫을 어떻게 변화시키는지 이해하기 위해 당사는 LLM 심사위원을 사용하여 검색된 모든 스니펫의 모든 토큰을 6가지 범주 중 하나로 분류하는 별도의 평가를 실행합니다:

필수: 사용자 쿼리에 답변하는 데 필수적인 증거.

주제 외: 다른 목적으로는 유용할 수 있지만 현재 쿼리와는 관련이 없는 정보.

광고: 사용자 쿼리에 대한 답변을 방해하는 관련 없는 광고.

메타데이터: 문서 콘텐츠에 대한 메타데이터.

UI 및 탐색: 프론트엔드 표시 및 탐색을 위한 요소.

중복: 이전에 포함된 정보의 반복.

당사의 평가는 검증 세트에서 1,000개의 혼합 도메인 쿼리를 대상으로 실행되었으며, 압축이 비활성화된 동일한 기준 모델과 프로덕션 스택을 비교했습니다. 그림 5에서 볼 수 있듯이, 압축은 스니펫당 필수 토큰의 비율을 압축 없는 기준 대비 평균 63% 증가시킵니다. 당사는 관련 없는 토큰이 29% 감소하는 것을 관찰했으며, 특히 UI/탐색(-58%), 메타데이터(-46%), 광고(-43%)에서 가파른 감소를 보였습니다. 이러한 결과는 위에서 논의된 품질-효율성 개선에 대한 메커니즘을 확인시켜 줍니다. 즉, 압축은 각 개별 스니펫의 신호 대 잡음비를 크게 높여 두 차원 모두에서 성능을 향상시킵니다.

확대

그림 6은 개별 쿼리에 대한 이러한 변화를 보여줍니다. "6일 된 신생아 수유당 우유 섭취량"이라는 쿼리에 대해 당사는 압축되지 않은 기준 스니펫과 압축된 스니펫을 모두 보여줍니다. 압축은 비필수 콘텐츠 범주를 제거하고 신생아 관련 수유 정보만 유지합니다. 중요하게도, 압축은 페이지에 대해서는 일반적으로 주제와 관련이 있을 수 있지만, 이 특정 신생아 중심 쿼리에 대해서는 주제 외인 콘텐츠를 성공적으로 제거합니다.

확대

결론

AI 시스템은 사용자 요청을 지능적이고 효율적으로 처리하기 위해 고신호 정보에 의존합니다. 이 정보는 각 요청에 대한 관련성을 극대화하기 위해 가능한 한 외과적으로 정확하게 제시되어야 합니다. 당사의 새로운 쿼리 인식 압축 모델은 스니펫당 주제 관련 증거를 최대화하고 관련 없는 주의 분산 요소를 공격적으로 제거함으로써 이를 정확하게 수행합니다.

당사의 검색 스택 내에 이러한 새로운 모델을 배포함으로써 당사는 당사 제품과 API를 사용하는 사람들에게 더 빠르고 더 나은 응답을 제공할 수 있게 되었습니다. 당사의 접근 방식은 간단한 제어 표면을 생성하여 당사 시스템과 API 고객이 재현율, 대기 시간 및 비용 간의 균형을 맞추기 위해 압축 정도를 조정할 수 있도록 합니다.

컨텍스트 큐레이션은 발전하는 분야이며, 오늘날의 최첨단 지능형 시스템 내에서 사용되는 각 토큰의 가치를 최적화하기 위해 해야 할 일이 훨씬 더 많습니다. 당사는 모델 개선과 시스템 아키텍처를 통해 컨텍스트 큐레이션 기술을 더욱 향상시키고 이러한 모델을 더욱 광범위하게 활용하기 위해 적극적으로 노력하고 있습니다.

참고 문헌

N. Chirkova, T. Formal, V. Nikoulina, and S. Clinchant. Provence: 검색 증강 생성을 위한 효율적이고 강력한 컨텍스트 가지치기, 2025. ICLR 2025 채택. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, and D. Kim. LooComp: 효율적인 쿼리 인식 컨텍스트 압축을 위한 인코더 전용 Transformer로의 Leave-One-Out 전략 활용, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, and D. Bykov. 확산 사전 학습된 밀집 및 컨텍스트 임베딩, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, and G. Neubig. 검색 증강 생성을 위한 컨텍스트 필터링 학습, 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}
}