Daha iyi alıntılar için sorgu farkında bağlam sıkıştırma

Her yanıt kanıtla başlar. Bir arama sisteminde bu kanıt genellikle belgelerden gelir: bir yanıt modeline veya aracıya bağlam olarak iletilen başlıklar, özetler, parçalar ve alıntılar.

Bu ham bağlam gürültülüdür. Örneğin bir web sayfası kullanıcının isteği için gereken bilgileri içerebileceği gibi dikkat dağıtıcı unsurlar da içerebilir. Bu dikkat dağıtıcı unsurlar hem ana gövdede hem de gezinti metni öğeleri, ilgisiz reklamlar, üstveri ve benzeri ikincil öğelerde görünebilir. Bu dikkat dağıtıcı unsurları alt akıştaki bir aracıya iletmek üç soruna yol açar.

Birincisi, doğruluğu olumsuz etkiler. En güçlü modellerin bile kapasitesi sınırlıdır. Uzun alakasız bilgi akışları model kapasitesini boşa harcar ve modelin gerçek kullanıcı isteğini ele alma yeteneğini zayıflatan "bağlam çürümesine" neden olur. Sonuç olarak, nihai yanıtın temel gerçekleri kaçırma, düşük kaliteli bilgiyə aşırı ağırlık verme veya kaynakta temellendirilmesi daha zor iddialar üretme olasılığı daha yüksek olur.

İkincisi, gecikmeyi artırır. Daha uzun bağlam, özellikle bir sorgunun birçok aday sayfadan kanıta ihtiyaç duyduğu durumlarda, alt akıştaki modelin işleyeceği daha fazla belirteç (token) anlamına gelir. Bu gecikme maliyetinin bir kısmı ön doldurma (prefill) aşamasında karşılanırken, çok daha önemli bir maliyet, modellerin alakasız bağlamla başa çıkmak için daha fazla akıl yürütme belirtecine ihtiyaç duymasıyla mantık yürütme aşamasında ödenir.

Üçüncüsü, maliyeti yükseltir. Modele iletilen gereksiz her belirteç, gürültülü bağlamla birlikte hem girdi belirteci hem de akıl yürütme belirteci kullanımı arttığından, kullanıcı isteğine hizmet etmeyi daha maliyetli hale getirir. Dikkat dağıtıcı unsurlar yalnızca kaliteyi düşürmekle kalmaz, sonuçta bu daha düşük kalite için daha fazla ödeme yapmanıza neden olur.

Büyüt

Perplexity’nin uygulamaları ve API Platform genelinde doğruluğu, hızı ve maliyet etkinliğini aynı anda artırmak için bağlam hassasiyetini iyileştirmeye büyük yatırım yapıyoruz. Bunu yapmanın bir yolu, alıntı üretim algoritmalarımızı geliştirmektir. Alıntı üretimini bir bağlam sıkıştırma problemi olarak ele alıyoruz. Belirli bilgileri arayan modeller genelleştirilmiş özetlerden veya bir belgenin alıntılarından fayda görmez. Bunun yerine, kullanıcının isteğine yanıt vermek için kaynak bilginin en küçük, en cerrahi olarak çıkarılmış parçasına ihtiyaç duyarlar. Diğer her şey kaldırılabilir ve kaldırılmalıdır.

Bu nedenle iyi bir alıntı üç şeyi yapmalıdır:

Modelin yanıtını temellendirmek için gereken kesin kanıtı sunarak doğruluğu teşvik edin.

Büyük Dil Modeli (LLM) çağrısından önce alakasız bağlamı kaldırarak gecikmeyi ve maliyeti azaltın.

Atıf sadakatini koruyarak ve kaynak kelimelerini olduğu gibi tutarak izlenebilirliği sağlayın.

Bu ay, uygulamalarımız ve API Platform içinde yeni, son teknoloji ürünü bir alıntı üreteci devreye aldık. Bu modülün çekirdeği, her sorgu ve aday sonuç için hangi veri aralıklarının (span) korunması gerektiğine karar veren sorgu farkında bir bağlam sıkıştırma modelidir. Bu makale, bu kritik görevde sınıfının en iyisi performansı elde etmek için modelin oluşturulması ve eğitilmesine yönelik yaklaşımımızı açıklamaktadır.

Sorgu Farkında Sıkıştırma Olarak Alıntılar

İşin ilk adımı görevin kendisini tanımlamaktır. Bu modelin ne yapmasını istiyoruz ve girdi ile çıktı şemasını nasıl tanımlamalıyız?

Alıntı yöntemleri iki geniş aileye ayrılır. Birincisi seçime dayalıdır: ilgili bir pencere, öbek (chunk), cümle veya pasaj bulunur ve alt akışa iletilir. İkincisi ise üretime dayalıdır: bir modelden sayfadan sorgu odaklı bir özet yazması istenir.

Doğruluk, gecikme ve maliyete odaklanmamız tasarım seçimini netleştirmektedir. Her sayfa için yeni bir özet oluşturmak her üç odak noktasında da performansı olumsuz etkilediğinden üretimi eleyebiliriz. Özetleme, önemsediğimiz kanıt katmanı için kötü bir uyumdur. Kaynağı başka sözcüklerle ifade edebilir ve atıf uyumunu zorlaştırabilir. Ayrıca, alıntının nihai yanıt olarak değil kanıt olarak kullanıldığı durumlarda riskli olan ve sayfada bulunmayan ifadeler içerebilir. İlgili gecikme ve maliyet, üretimi daha da cazip olmaktan çıkarmaktadır.

Bunun yerine görevimizi sorgu farkında özütleyici (extractive) sıkıştırma olarak tanımlıyoruz: getirilen bağlamın yararlı kısımlarını dikkat dağıtıcı kısımlardan ayırmak. Spesifik olarak, modelimiz bir sorgu ve aday sonuç kabul etmeli, hangi veri aralıklarının korunacağına (sorguyu en iyi destekleyenler) ve hangilerinin atılacağına (geri kalanı) karar vermelidir. Model çıktısı kaynak metni yeniden yazmak yerine korur. Bu, sonucun alıntılanmasını, doğrulanmasını ve alt akışa iletilmesini daha ucuz hale getirir.

Örneğin şu sorguyu ve getirilen sonucu ele alalım:

Büyüt

Makul bir model çıktısı, kalın yazılmış cümleyi seçmek olacaktır: “Comet'te, asistan şunları yapabilir ...”.

Yaklaşımımız, üretim arama sisteminde alıntı üretimi için uyarlanmış FliCo, Provence ve LooComp gibi önceki bağlam sıkıştırma çalışmalarıyla aynı genel fikri takip etmektedir. Önemli olarak model, ham getirme aşamasından sonra bir hassasiyet aşaması olarak çalışır. Önceki Perplexity Araştırma makalemiz olan Introducing the Perplexity Search API'de tartışıldığı gibi, getirme sistemlerimizi yerel olarak alt belge veya alıntı düzeyinde çalışacak şekilde mimari olarak tasarlıyoruz; bu da hassasiyet ile geri çağırmayı (recall) oldukça iyi dengelememizi sağlıyor. Sorgu farkında bir bağlam sıkıştırma modeli sunmak, hassasiyet-geri çağırma Pareto sınırını daha da ileriye taşır.

Bağlam Sıkıştırma Modeli Oluşturma ve Eğitme

Modelimizi üç ana hususu göz önünde bulundurarak geliştiriyoruz: sorgu ve bağlamın ortak anlaşılması, ince taneli cümle düzeyinde seçim verimliliği ve son derece sıkı bir gecikme bütçesine uyum sağlama.

Model mimarisi

Omurga olarak bir pplx-diffusion modeli kullanıyoruz. Bu, pplx-embed-v1'in arkasındaki model ailesiyle aynıdır ve hem önceki akademik çalışmamız olan Diffusion-Pretrained Dense and Contextual Embeddings hem de üretim kıyaslamalarımız bunun sorgu-bağlam çiftleri için güçlü bir çift yönlü kodlayıcı olduğunu doğrulamaktadır. Bu model ailesinin temel özelliklerinden biri çift yönlü bağlamdır: model neyin tutulacağına karar vermeden önce her belirteç temsili tüm sorguyu ve tüm aday bağlamı dikkate alabilir.

Bu omurganın üzerine, bağlamın hangi kısımlarının tutulması gerektiğini öngören hafif bir sıkıştırma başlığı (head) eğitiyoruz. Herhangi bir üretim söz konusu olmadığı için bu tahminler tüm bağlam boyunca paralel olarak yapılır. Sunum zamanında alıntı motoru bu tahminleri cümle düzeyinde toplar, bir eşik uygular ve sonucu istenen belirteç bütçesine göre kırpar.

Denetim boru hattı (pipeline)

Bu sıkıştırıcıyı eğitmek, doğru ayrıntı düzeyinde denetim gerektirir. Belge düzeyinde bir alaka düzeyi etiketi, özütleyici sıkıştırma görevimiz için açıkça uygun değildir. Denetimli öğrenme için yeterince ayrıntılı veriler üretmek üzere, sorguyla ilgili kanıt aralıklarını ve kaldırılması gereken dikkat dağıtıcı aralıkları işaretleyen bir aralık etiketleme boru hattı oluşturduk.

Boru hattımız hakem olarak LLM (LLM-as-a-judge) kurulumunu kullanır. Bir kullanıcı sorgusu ve bağlantısı, başlığı ve özetiyle birlikte bir aday web sayfası verildiğinde, hakem önce sorguyu analiz ederek olası kullanıcı niyetlerinin bir listesini üreterek sorgu anlama gerçekleştirir. Bu niyetlere tutunarak hakem daha sonra aday bağlamı işler ve etiketlerin incelenmesini kolaylaştırmak için her aralık için bir kategoriyle birlikte metinden kelimesi kelimesine kopyalanan aralıkları döndürür.

Döndürülen aralıkları daha sonra kaynak metinle yeniden eşleştirdik. Şaşırtıcı olmayan bir şekilde, hakem çıktılarının çoğu zaten tam kopyalardı: saf dize eşleştirme, aralıkların %98'ini kurtardı. Düzenli ifade (regex) tabanlı basit bir eşleştirme aşaması eklemek, aralık kurtarma oranını %100'e çıkardı. Bu bize belirteç düzeyinde tut/atla denetimine dönüştürülebilen güvenilir, ayrıntılı aralıklar sağladı.

Bu denetim boru hattını, manuel olarak etiketlenmiş aralıklara sahip küçük bir küratörlü veri kümesi kullanarak değerlendirdik; daha küçük hakem modellerini, farklı istemleri (prompt) ve farklı adım yapılandırmalarını karşılaştırdık. En iyi performans gösteren kurulum iki aşamalı bir boru hattıydı: önce sorgu anlama, ardından kategorize edilmiş aralık etiketleme. Ayrıca, çıkarılan aralık kümesini, yalnızca tutulan kanıt aralıklarının kullanılmasının güçlü puanları korurken girdi belirteçlerini önemli ölçüde azalttığı BrowseComp ve SimpleQA gibi alt akış doğrulanabilir değerlendirmeleri aracılığıyla doğruladık.

Bu boru hattını kullanarak 750 bin sorgu-belge çiftini etiketledik ve ikili çapraz entropi (binary cross-entropy) ile sıkıştırma başlığını eğitmek için ortaya çıkan aralıkları kullandık. Bu süreç, sorgu farkında sıkıştırma modelimizin, alt akıştaki modelin kullanıcının isteğini yerine getirmesine yardımcı olma olasılığı düşük olan bağlamı kaldırırken kaynak metni bozulmamış halde tutmasını sağlar.

Gerçek zamanlı gecikmenin sağlanması

Bağlam sıkıştırma, alt akıştaki modelin önünde yer alır ve bunu engelleyici (blocking) bir işlem haline getirir. Dahası, her sıkıştırma sorguya bağlıdır. Bu nedenle çevrimiçi yol, zorlu bir gecikme zarfı içinde her aday belge için sorgu-bağlam çiftlerini puanlamalıdır. Yavaş bir sıkıştırma modeli kendi kendini boşa çıkarır, çünkü daha yüksek hassasiyetten elde edilen gecikme avantajları sıkıştırma gecikmesinin kendisi tarafından silinir. Aynı zamanda, daha az akıllı bir sıkıştırma modeli neyin kesileceği ve tutulacağı konusunda daha zayıf kararlar verecektir.

Pratik soru, sıkıştırma kalitesi bozulmaya başlamadan önce model kapasitesini ne kadar güvenli bir şekilde kaldırabileceğimizdir. Tam 28 katmanlı pplx-diffusion omurgasını, katman budama ile üretilen ve arama yolunu hedefleyen 11 katmanlı ve 17 katmanlı varyantlarla karşılaştırıyoruz. Her biri için sıkıştırma eşiğini tarıyor ve iki miktarı ölçüyoruz: sorgu başına alt akışa gönderilen ortalama bağlam belirteci sayısı ve sıkıştırmadan sonra korunan yararlı kanıtların oranı.

Şekil 2 kalite-verimlilik sınırını göstermektedir. Bir model sol üst köşeye doğru hareket ettiğinde daha iyidir: daha fazla yararlı kanıtın korunduğu daha az alt akış belirteci. 28 katmanlı model kalite referansını sağlar. 11 katmanlı model, modelin çok agresif bir şekilde sıkıştırılmasının risklerini gösterir. Budanan 17 katmanlı model orta bir noktayı temsil eder: doymuş rejimde 28 katmanlı modeli yakından takip eder, ancak üretim trafiğinin çoğunun çalıştığı eğrinin dik kısmında küçük bir boşluk açılır.

Bu boşluğu kapatmak için belirteç düzeyinde bilgi damıtımı (knowledge distillation) kullanıyoruz. Yaklaşımımız rutin bir yöntemdir: standart kayba, bir damıtma katsayısıyla ağırlıklandırılmış öğretmen modelin tahminleri üzerinden yumuşak bir çapraz entropi terimi ekliyoruz. Bu, öğrenci modeli başa baş duruma getirmek için yeterlidir ve üretimde tamamen damıtılmış 17 katmanlı modele geçmemizi sağlar. Bu yeni üretim modeli, 28 katmanlı öğretmene kıyasla kalite kaybı olmaksızın çıkarım gecikmesinde %35-40'lık bir azalma ve toplam GPU bilgi işleminde %45'lik bir azalma sağlar. Üretim gecikmesi 20 ms'nin altında (p99) gerçekleşir: yanıt modeline iletilen toplam belirteçleri büyük ölçüde azaltırken sunum yoluna eklenecek kadar küçüktür.

Büyüt

Kalite ve Belirteç Verimliliği

Bağlam sıkıştırmanın etkinliğini analiz etmek için Perplexity’nin Agent API'sini bir test ortamı olarak kullanıyoruz. Üç Agent API ön ayarını değerlendiriyoruz:

Her sonuç kümesi için belirteç bütçesini 1000 belirteçle sınırlayan bir “düşük” bağlam ön ayarı.

Her sonuç kümesi için belirteç bütçesini 4000 belirteçle sınırlayan bir “orta” bağlam ön ayarı.

Her sonuç kümesi için belirteç bütçesini 10000 belirteçle sınırlayan bir “yüksek” bağlam ön ayarı.

Hem standart, sıkıştırmasız ayarlar hem de sıkıştırma ayarları, bu belirteç bütçelerine uvecek şekilde yapılandırılmıştır.

Aracılı (agentic) çok adımlı arama (BrowseComp)

Önce sıkıştırmanın, BrowseComp kıyaslaması üzerindeki etmenli çok adımlı arama iş akışlarına etkisini inceliyoruz. Bu değerlendirmeyi açık kaynaklı search_evals araç setimizi kullanarak gerçekleştiriyoruz. Derecelendirme, OpenAI’nin kanonik BrowseComp LLM değerlendirici istemi kullanılarak tüm çalıştırmalarda aynıdır.

İlgi duyulan iki boyut, kıyaslama doğruluğu ve belirteç kullanımıdır. Önemli olarak, istek yaşam döngüsü boyunca ortaya çıkan gerçek belirteç yükünü ölçmek için belirteç kullanımını bireysel adım düzeyinde değil sorgu düzeyinde ölçüyoruz. Şekil 3, "puan-belirteç" sınırını, yani doğruluk puanına karşı belirteç kullanımını göstermektedir.

Büyüt

Sıkıştırma, her alanda yeni bir Pareto sınırı sunar. Her ayar için sıkıştırma getirmek, sorgu düzeyindeki belirteç kullanımını %10 ila %70 oranında azaltırken, doğruluk kazançları 4 ila 4.81 yüzde puan arasında gerçekleşir. Sıkıştırma getirmek, "düşük" ön ayarımızın bile sıkıştırmasız "yüksek" ön ayardan daha iyi performans göstermesini sağlarken belirteç kullanımını üç katından fazla azaltır.

Sıkıştırma ile, bekleyebileceğimiz gibi "yüksek" ayarının "orta" ayarından daha yüksek doğruluk sağladığını gözlemliyoruz. Bununla birlikte, ilginç bir şekilde bunu daha düşük belirteç kullanımında yapar. Bu, sıkıştırmanın incelikli ama önemli bir etkisini ortaya koymaktadır: sıkıştırma ile, adım başına bağlam boyutunu artırmak bile modelin doğru sonuca ulaşmak için daha az adım atmasını sağlayabilir. Bu monotonik olmayış durumunu keşfetmek, gelecekteki çalışmalar için umut vadeden bir yöndür.

SimpleQA: tek adımlı olgusallık (factuality)

BrowseComp çok adımlı araştırmayı vurgular, ancak birçok üretim iş akışı tek adımlı olgusal arama içerir. Sıkıştırmanın tek adımlı rejimde de yardımcı olup olmadığını belirlemek için, aracılı bir döngü yerine tek bir arama adımında yanıtlanacak 4.326 sorudan oluşan bir kıyaslama olan SimpleQA'daki performansı da inceliyoruz.

Daha önce olduğu gibi, kanonik hakem istemini kullanarak görev başına ortalama toplam belirtece karşı doğruluğu grafiklendiriyoruz. Şekil 4, bu tek adımlı ayarda puan-belirteç sınırını göstermektedir. Etki boyutları tek adımlı ayarda daha sıkıştırılmış olsa da, sıkıştırmanın tüm ön ayarlar genelinde aynı anda doğruluğu ve verimliliği iyileştirdiğini ve böylece yeni bir Pareto sınırı sunduğunu yine gözlemliyoruz. Sıkıştırma etkinleştirildiğinde, orta ön ayar belge başına ortalama yalnızca 200 belirteçle %95 doğruluk elde eder. 10.000 belirtecin üzerindeki ortalama belge uzunluğu göz önüne alındığında, bu 50'den fazla bir sıkıştırma oranında sınır düzeyinde (frontier-level) performansı temsil eder.

Büyüt

Alıntılarda ne kalıyor?

Bölüm 4.1 ve 4.2'deki alt akış kazançları uçtan uca (end-to-end) gerçekleşir. Sıkıştırmanın bireysel alıntıları nasıl değiştirdiğini anlamak için, getirilen her alıntının her bir belirtecini altı kategoriden birine sınıflandırmak üzere bir LLM hakemi kullanan ayrı bir değerlendirme çalıştırıyoruz:

Hayati (Vital): kullanıcının sorgusunu yanıtlamak için gerekli kanıt.

Konu dışı (Off-topic): başka bir amaç için yararlı olabilecek ancak eldeki sorguyla ilgili olmayan bilgiler.

Reklamlar (Ads): kullanıcının sorgusunu yanıtlamaktan uzaklaştıran alakasız reklamlar.

Üstveri (Metadata): belgenin içeriği hakkındaki üstveri.

Arayüz ve gezinti (UI & navigation): ön uç ekran ve gezinti öğeleri.

Yinelenen (Duplicate): önceden eklenmiş bilgilerin tekrarı.

Değerlendirmemiz, üretim yığınını sıkıştırma devre dışı bırakılmış özdeş bir taban çizgiyle karşılaştırarak, doğrulama kümemizden 1.000 karışık etki alanlı sorgu üzerinde çalışır. Şekil 5'te gösterildiği gibi, sıkıştırma, alıntı başına hayati belirteçlerin oranını sıkıştırmasız taban çizgiye göre ortalama %63 oranında artırır. UI/gezinti (-%58), üstveri (-%46) ve reklamlarda (-%43) özellikle keskin düşüşlerle birlikte alakasız belirteçlerde %29'luk karşılık gelen bir düşüş gözlemliyoruz. Bu sonuçlar, yukarıda tartışılan kalite-verimlilik iyileştirmelerinin mekanizmasını doğrulamaktadır: sıkıştırma, her bir alıntının sinyal-gürültü oranını keskin bir şekilde artırarak her iki boyutta da performansı iyileştirir.

Büyüt

Şekil 6, bireysel bir sorgu için bu değişimi göstermektedir. “6 day old newborn milk intake per feeding” (6 günlük yeni doğan bebekte beslenme başına süt alımı) sorgusu için hem sıkıştırılmamış taban çizgiyi hem de sıkıştırılmış alıntıları gösteriyoruz. Sıkıştırma, hayati olmayan içerik kategorilerini ortadan kaldırır ve yalnızca yeni doğanla ilgili beslenme bilgilerini korur. Önemli olarak sıkıştırma, sayfa için genellikle konuyla ilgili olabilecek ancak bu özel yeni doğan odaklı sorgu için konu dışı olan içeriği başarıyla ortadan kaldırır.

Büyüt

Sonuç

Yapay zeka sistemleri, kullanıcı isteklerini akıllı ve verimli bir şekilde karşılamak için yüksek sinyalli bilgilere güvenir. Her istekle ilgili alakalılığı en üst düzeye çıkarmak için bu bilgiler mümkün olduğunca cerrahi olarak sunulmalıdır. Yeni sorgu farkında sıkıştırma modellerimiz, alıntı başına konuyla ilgili kanıtları en üst düzeye çıkararak ve alakasız dikkat dağıtıcı unsurları agresif bir şekilde ayıklayarak tam olarak bunu yapar.

Bu yeni modelleri arama yığınımız içinde dağıtarak, ürünlerimize ve API'lerimize güvenenlere daha hızlı ve daha iyi yanıtlar sağlayabiliyoruz. Yaklaşımımız, sistemlerimizin ve API müşterilerimizin geri çağırma, gecikme ve maliyet arasında denge kurmak için sıkıştırma derecesini ayarlamasına olanak tanıyan basit bir kontrol yüzeyi oluşturur.

Bağlam küratörlüğü gelişen bir alandır ve günümüzün sınır zeka sistemleri içinde kullanılan her bir belirtecin değerini optimize etmek için yapılacak çok daha fazla şey var. Bu modellerin daha da geniş kapsamlı kullanımını sağlamak hem model iyileştirmeleri hem de sistem mimarisi aracılığıyla bağlam küratörlüğü tekniklerimizi daha da iyi hale getirmek için aktif olarak çalışıyoruz.

Kaynakça

N. Chirkova, T. Formal, V. Nikoulina ve S. Clinchant. Provence: Efficient and Robust Context Pruning for Retrieval-Augmented Generation, 2025. ICLR 2025'te kabul edilmiştir. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim ve 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 ve D. Bykov. Diffusion-Pretrained Dense and Contextual Embeddings, 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez ve G. Neubig. Learning to Filter Context for Retrieval-Augmented Generation, 2023. arXiv:2311.08377.

Alıntı

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