Kompresi konteks sadar kueri untuk cuplikan yang lebih baik

Setiap jawaban dimulai dengan bukti. Dalam sistem pencarian, bukti ini biasanya berasal dari dokumen: judul, ringkasan, potongan, dan cuplikan yang diteruskan sebagai konteks ke model jawaban atau agen.

Konteks mentah ini penuh dengan derau (noise). Misalnya, halaman web mungkin berisi informasi yang diperlukan untuk permintaan pengguna, tetapi halaman tersebut juga dapat berisi elemen pengganggu. Elemen pengganggu ini dapat muncul baik di badan utama maupun di elemen pendukung, seperti elemen teks navigasi, iklan yang tidak relevan, metadata, dan lainnya. Meneruskan elemen pengganggu ini ke agen hilir menimbulkan tiga masalah.

Pertama, hal ini merusak akurasi. Bahkan model paling canggih sekalipun memiliki kapasitas yang terbatas. Aliran informasi tidak relevan yang panjang membuang-buang kapasitas model, mengakibatkan "kebusukan konteks" (context rot) yang menurunkan kemampuan model untuk menangani permintaan aktual pengguna. Akibatnya, respons akhir lebih cenderung melewatkan fakta penting, terlalu membebani informasi berkualitas rendah, atau menghasilkan klaim yang lebih sulit didasarkan pada sumber.

Kedua, hal ini menurunkan latensi. Konteks yang lebih panjang berarti lebih banyak token yang harus diproses oleh model hilir, terutama ketika kueri memerlukan bukti dari banyak halaman kandidat. Meskipun sebagian dari biaya latensi ini ditanggung pada tahap pra-pengisian (prefill), biaya yang jauh lebih signifikan dibayar dalam penalaran, dengan model yang memerlukan lebih banyak token penalaran untuk menangani konteks yang tidak relevan.

Ketiga, hal ini meningkatkan biaya. Setiap token tidak perlu yang diteruskan ke model membuat pemenuhan permintaan pengguna menjadi lebih mahal, karena penggunaan token input dan token penalaran meningkat seiring dengan konteks yang semakin bising. Elemen pengganggu tidak hanya mengurangi kualitas; mereka akhirnya memaksa Anda membayar lebih untuk kualitas yang lebih buruk tersebut.

Perbesar

Untuk secara bersamaan meningkatkan akurasi, kecepatan, dan efektivitas biaya di seluruh aplikasi dan Platform API Perplexity, kami berinvestasi besar-besaran dalam meningkatkan presisi konteks. Salah satu cara yang kami lakukan adalah melalui penyempurnaan algoritma pembuatan cuplikan kami. Kami memperlakukan pembuatan cuplikan sebagai masalah kompresi konteks. Model yang mencari informasi spesifik tidak mendapat manfaat dari ringkasan atau kutipan dokumen yang digeneralisasi. Sebaliknya, mereka memerlukan bagian informasi sumber terkecil yang diekstrak secara paling presisi untuk menanggapi permintaan pengguna. Segala hal lainnya dapat dan harus dihapus.

Oleh karena itu, cuplikan yang baik harus melakukan tiga hal:

Meningkatkan akurasi dengan menyajikan bukti tepat yang diperlukan untuk mendasari respons model.

Mengurangi latensi dan biaya dengan menghapus konteks yang tidak relevan sebelum pemanggilan LLM.

Memastikan keterlacakan dengan mempertahankan keandalan sitasi dan menjaga agar kata-kata sumber tetap utuh.

Bulan ini, kami menerapkan generator cuplikan baru yang canggih di dalam aplikasi dan Platform API kami. Inti dari modul ini adalah model kompresi konteks yang sadar kueri (query-aware) yang memutuskan, untuk setiap kueri dan hasil kandidat, subset rentang yang harus dipertahankan. Artikel ini menjelaskan pendekatan kami dalam membangun dan melatih model untuk mencapai kinerja terbaik di kelasnya pada tugas penting ini.

Cuplikan sebagai Kompresi yang Sadar Kueri

Hal pertama yang harus dilakukan adalah mendefinisikan tugas itu sendiri. Apa yang ingin kita lakukan pada model ini, dan bagaimana kita harus mendefinisikan skema input dan output?

Metode cuplikan terbagi menjadi dua kelompok besar. Yang pertama berbasis seleksi: temukan jendela, potongan, kalimat, atau bagian yang relevan, lalu teruskan ke hilir. Yang kedua berbasis generasi: minta model untuk menulis ringkasan yang berfokus pada kueri dari halaman tersebut.

Fokus kami pada akurasi, latensi, dan biaya membuat pilihan desain menjadi jelas. Kita dapat mengesampingkan pembuatan (generation), karena membuat ringkasan baru untuk setiap halaman merusak kinerja di ketiga fokus tersebut. Peringkasan kurang cocok untuk lapisan bukti yang kita pedulikan. Ringkasan mungkin memparafrasekan sumber, sehingga membuat penyelarasan sitasi menjadi lebih sulit. Ringkasan juga dapat memperkenalkan kata-kata yang tidak ada di halaman, yang berbahaya ketika cuplikan digunakan sebagai bukti daripada sebagai jawaban akhir. Latensi dan biaya yang terlibat membuat pembuatan menjadi semakin tidak menarik.

Sebaliknya, kami mendefinisikan tugas kami sebagai kompresi ekstraktif yang sadar kueri: memisahkan bagian yang berguna dari konteks yang diambil dari bagian yang mengganggu. Khususnya, model kami harus menerima kueri dan hasil kandidat, serta memutuskan rentang mana yang harus dipertahankan (yang paling mendukung kueri) dan mana yang harus dihapus (sisanya). Output model mempertahankan teks sumber daripada menulis ulang. Hal ini membuat hasil lebih mudah dikutip, lebih mudah diverifikasi, dan lebih murah untuk diteruskan ke hilir.

Sebagai contoh, pertimbangkan kueri dan hasil pengambilan ini:

Perbesar

Output model yang masuk akal adalah memilih kalimat yang dicetak tebal: “Di Comet, asisten dapat ...”.

Pendekatan kami mengikuti gagasan umum yang sama seperti pekerjaan kompresi konteks sebelumnya seperti FliCo, Provence, dan LooComp, yang disesuaikan untuk pembuatan cuplikan dalam sistem pencarian produksi. Yang penting, model ini bekerja sebagai tahap presisi setelah tahap pengambilan mentah kami. Sebagaimana dibahas dalam artikel Riset Perplexity kami sebelumnya, Memperkenalkan API Pencarian Perplexity, kami merancang sistem pengambilan kami untuk beroperasi secara native pada tingkat sub-dokumen atau cuplikan, yang sudah memungkinkan kami menyeimbangkan presisi dan perolehan kembali (recall) dengan cukup baik. Memperkenalkan model kompresi konteks yang sadar kueri menggeser batas Pareto presisi-perolehan kembali (precision-recall Pareto frontier) lebih jauh ke luar.

Membangun dan Melatih Model Kompresi Konteks

Kami mengembangkan model kami dengan memikirkan tiga pertimbangan utama: pemahaman bersama tentang kueri dan konteks, seleksi tingkat kalimat berbutir halus (fine-grained), dan efisiensi agar pas dalam anggaran latensi yang sangat ketat.

Arsitektur model

Kami menggunakan model pplx-diffusion sebagai tulang punggung (backbone). Ini adalah keluarga model yang sama di balik pplx-embed-v1, dan baik pekerjaan akademik kami sebelumnya, Embedding Padat dan Kontekstual yang Dilatih-Prarilis Difusi (Diffusion-Pretrained Dense and Contextual Embeddings), maupun tolok ukur produksi kami mengonfirmasi bahwa model ini merupakan encoder dua arah (bidirectional) yang kuat untuk pasangan kueri-konteks. Salah satu properti utama dari keluarga model ini adalah konteks dua arah: setiap representasi token dapat memperhatikan kueri penuh dan konteks kandidat penuh sebelum model memutuskan apa yang harus disimpan.

Di atas tulang punggung ini, kami melatih kepala kompresi (compression head) ringan yang memprediksi bagian konteks mana yang harus disimpan. Karena tidak ada generasi yang terlibat, prediksi ini dibuat secara paralel di seluruh konteks. Pada saat penyajian (serving time), mesin cuplikan menggabungkan prediksi ini pada tingkat kalimat, menerapkan ambang batas (threshold), dan memangkas hasil sesuai dengan anggaran token yang diminta.

Pipeline supervisi

Melatih kompresor ini memerlukan supervisi pada tingkat granularitas yang tepat. Label relevansi tingkat dokumen jelas tidak cocok untuk tugas kompresi ekstraktif kami. Untuk menghasilkan data berbutir cukup halus untuk pembelajaran ter监督 (supervised learning), kami membangun pipeline pelabelan rentang yang menandai rentang bukti yang relevan dengan kueri, beserta rentang pengganggu yang harus dihapus.

Pipeline kami menggunakan penyiapan LLM-sebagai-hakim (LLM-as-a-judge). Mengingat kueri pengguna dan halaman web kandidat beserta tautan, judul, dan ringkasannya, hakim pertama-tama melakukan pemahaman kueri, menganalisis kueri dan menghasilkan daftar kemungkinan niat (intent) pengguna. Berdasarkan niat ini, hakim kemudian memproses konteks kandidat dan mengembalikan rentang yang disalin kata demi kata dari teks, dengan kategori untuk setiap rentang agar label lebih mudah diperiksa.

Kami kemudian mencocokkan kembali rentang yang dikembalikan ke teks sumber. Tidak mengherankan, sebagian besar output hakim sudah merupakan salinan persis: pencocokan string naif memulihkan 98% rentang. Menambahkan langkah pencocokan berbasis regex sederhana meningkatkan pemulihan rentang menjadi 100%. Ini memberi kami rentang yang andal dan terperinci yang dapat dikonversi menjadi supervisi simpan/buang (keep/drop) tingkat token.

Kami mengevaluasi pipeline supervisi ini menggunakan dataset kurasi kecil dengan rentang yang diberi label secara manual, membandingkan model hakim yang lebih kecil, prompt yang berbeda, dan konfigurasi langkah yang berbeda. Penyiapan dengan kinerja terbaik adalah pipeline dua tahap: pemahaman kueri terlebih dahulu, diikuti oleh pelabelan rentang terkategori. Kami juga memvalidasi set rentang yang diekstrak melalui evaluasi terverifikasi hilir seperti BrowseComp dan SimpleQA, di mana penggunaan hanya rentang bukti yang disimpan mempertahankan skor yang kuat sekaligus secara signifikan mengurangi token input.

Menggunakan pipeline ini, kami memberi label 750 ribu pasangan kueri-dokumen dan menggunakan rentang yang dihasilkan untuk melatih kepala kompresi dengan entropi silang biner (binary cross-entropy). Proses ini memungkinkan model kompresi sadar kueri kami menjaga teks sumber tetap utuh sambil menghapus konteks yang kecil kemungkinannya membantu model hilir melayani permintaan pengguna.

Memastikan latensi waktu nyata (realtime)

Kompresi konteks berada sebelum model hilir, menjadikannya operasi pemblokiran. Selain itu, setiap kompresi bergantung pada kueri. Oleh karena itu, jalur online harus menilai pasangan kueri-konteks untuk setiap dokumen kandidat dalam amplop latensi yang ketat. Model kompresi yang lambat akan merugikan diri sendiri, karena manfaat latensi dari presisi yang lebih tinggi dihapuskan oleh latensi kompresi itu sendiri. Pada saat yang sama, model kompresi yang kurang cerdas akan membuat keputusan yang lebih buruk tentang apa yang harus dipotong dan dipertahankan.

Pertanyaan praktisnya adalah berapa banyak kapasitas model yang dapat dengan aman kita hapus sebelum kualitas kompresi mulai menurun. Kami membandingkan tulang punggung pplx-diffusion 28 lapisan penuh dengan varian 11 lapisan dan 17 lapisan yang dihasilkan oleh pemangkasan lapisan (layer pruning) dan ditujukan ke jalur pencarian. Untuk masing-masing, kami menyapu ambang batas kompresi dan mengukur dua kuantitas: jumlah rata-rata token konteks yang dikirim ke hilir per kueri, dan pecahan bukti berguna yang dipertahankan setelah kompresi.

Gambar 2 menunjukkan batas kualitas-efisiensi. Model menjadi lebih baik ketika bergerak ke kiri atas: lebih sedikit token hilir dengan lebih banyak bukti berguna yang dipertahankan. Model 28 lapisan menyediakan referensi kualitas. Model 11 lapisan menunjukkan risiko mengompresi model terlalu agresif. Model 17 lapisan yang dipangkas mewakili jalan tengah: model ini mengikuti model 28 lapisan dengan cermat dalam rezim jenuh, tetapi celah kecil terbuka di bagian kurva yang curam tempat sebagian besar lalu lintas produksi beroperasi.

Untuk menutup celah tersebut, kami menggunakan distilasi pengetahuan tingkat token (token-level knowledge distillation). Pendekatan kami rutin: kami memperbanyak loss standar dengan suku entropi silang lunak (soft cross-entropy term) pada prediksi model guru, dibobot oleh koefisien distilasi. Ini sudah cukup untuk membawa model siswa ke tingkat yang setara, memungkinkan kami beralih sepenuhnya ke model 17 lapisan yang didistilasi dalam produksi. Model produksi baru ini menghasilkan penurunan latensi inferensi sebesar 35-40% dan penurunan komputasi GPU agregat sebesar 40-45% tanpa penurunan kualitas relatif terhadap guru 28 lapisan. Latensi produksi tercatat di bawah 20 ms (p99): cukup kecil untuk ditambahkan ke jalur penyajian sekaligus sangat mengurangi total token yang diteruskan ke model jawaban.

Perbesar

Kualitas dan Efisiensi Token

Kami menggunakan API Agen Perplexity sebagai tempat uji (testbed) untuk menganalisis efektivitas kompresi konteks. Kami mengevaluasi tiga prasetel API Agen:

Prasetel konteks "rendah" yang membatasi anggaran token untuk setiap set hasil hingga 1000 token.

Prasetel konteks "sedang" yang membatasi anggaran token untuk setiap set hasil hingga 4000 token.

Prasetel konteks "tinggi" yang membatasi anggaran token untuk setiap set hasil hingga 10000 token.

Baik pengaturan standar, tanpa kompresi, maupun kompresi dikonfigurasi untuk mematuhi anggaran token ini.

Pencarian multi-langkah agen (BrowseComp)

Kami pertama-tama memeriksa dampak kompresi pada alur kerja pencarian multi-langkah agen pada tolok ukur BrowseComp. Kami melakukan evaluasi ini menggunakan perangkat sumber terbuka search_evals kami. Penilaian identik di semua proses (runs), menggunakan prompt hakim LLM BrowseComp kanonik OpenAI.

Dua dimensi yang menarik adalah akurasi tolok ukur dan penggunaan token. Yang penting, kami mengukur penggunaan token pada tingkat kueri alih-alih tingkat langkah individual untuk mengukur beban token aktual yang terjadi di seluruh siklus hidup permintaan. Gambar 3 menunjukkan batas "skor-token", skor akurasi vs. penggunaan token.

Perbesar

Kompresi memberikan batas Pareto baru secara menyeluruh. Untuk setiap pengaturan, memperkenalkan kompresi mengurangi penggunaan token tingkat kueri dari 10% hingga 70%, dengan perolehan akurasi mencapai antara 4 dan 4,81 persentase poin. Memperkenalkan kompresi bahkan memungkinkan prasetel "rendah" kami mengungguli prasetel "tinggi" tanpa kompresi, semuanya sambil mengurangi penggunaan token lebih dari tiga kali lipat.

Kami mengamati bahwa dengan kompresi, "tinggi" menghasilkan akurasi yang lebih besar daripada "sedang" seperti yang mungkin kita harapkan. Menariknya, hal ini dilakukan pada penggunaan token yang lebih rendah. Ini mengungkapkan efek kompresi yang halus namun penting: dengan kompresi, bahkan meningkatkan ukuran konteks per langkah dapat memungkinkan model mengambil lebih sedikit langkah untuk tiba di hasil yang benar. Mengeksplorasi ketidakmonotonan ini adalah arah yang menjanjikan untuk pekerjaan masa depan.

SimpleQA: faktualitas satu langkah

BrowseComp menekankan riset multi-langkah, namun banyak alur kerja produksi melibatkan pencarian faktual satu langkah. Untuk menentukan apakah kompresi juga membantu dalam rezim satu langkah, kami juga memeriksa kinerja pada SimpleQA, sebuah tolok ukur yang terdiri dari 4.326 pertanyaan yang harus dijawab dalam satu langkah pencarian, alih-alih loop agen.

Seperti sebelumnya, kami memetakan akurasi terhadap rata-rata total token per tugas menggunakan prompt hakim kanonik. Gambar 4 menunjukkan batas skor-token dalam pengaturan satu langkah ini. Meskipun besar efeknya lebih terkompresi dalam pengaturan satu langkah, kami kembali mengamati bahwa kompresi secara bersamaan meningkatkan akurasi dan efisiensi di semua prasetel, sehingga memperkenalkan batas Pareto baru. Dengan kompresi diaktifkan, prasetel sedang mencapai akurasi 95% dengan rata-rata hanya 200 token per dokumen. Mengingat panjang dokumen rata-rata lebih dari 10.000 token, ini mewakili kinerja tingkat batas (frontier-level) pada rasio kompresi lebih dari 50.

Perbesar

Apa yang berakhir di cuplikan?

Keuntungan hilir dalam Bagian 4.1 dan 4.2 bersifat ujung-ke-ujung (end-to-end). Untuk memahami bagaimana kompresi mengubah cuplikan individual, kami menjalankan evaluasi terpisah yang menggunakan hakim LLM untuk mengklasifikasikan setiap token dari setiap cuplikan yang diambil ke dalam salah satu dari enam kategori:

Vital: bukti yang sangat penting untuk menjawab kueri pengguna.

Di luar topik (Off-topic): informasi yang mungkin berguna untuk tujuan lain tetapi tidak berkaitan dengan kueri yang sedang dihadapi.

Iklan (Ads): iklan tidak relevan yang mengalihkan perhatian dari menjawab kueri pengguna.

Metadata: metadata tentang isi dokumen.

UI & navigasi: elemen untuk tampilan ujung depan (frontend) dan navigasi.

Duplikat (Duplicate): pengulangan informasi yang telah dimasukkan sebelumnya.

Evaluasi kami berjalan pada 1.000 kueri domain campuran dari set validasi kami, membandingkan tumpukan produksi dengan baseline yang identik kecuali kompresinya dinonaktifkan. Sebagaimana ditunjukkan dalam Gambar 5, kompresi meningkatkan proporsi token vital per cuplikan sebesar rata-rata 63% dibandingkan baseline tanpa kompresi. Kami mengamati penurunan yang sesuai sebesar 29% pada token yang tidak relevan, dengan penurunan yang sangat tajam pada UI/navigasi (-58%), metadata (-46%), dan iklan (-43%). Hasil ini mengonfirmasi mekanisme untuk peningkatan kualitas-efisiensi yang dibahas di atas: kompresi meningkatkan kinerja di kedua dimensi dengan meningkatkan rasio sinyal terhadap derau (signal-to-noise ratio) dari setiap cuplikan individual secara tajam.

Perbesar

Gambar 6 mengilustrasikan perubahan ini untuk kueri individual. Untuk kueri "asupan susu bayi baru lahir berusia 6 hari per menyusui", kami menampilkan cuplikan yang tidak dikompresi, baseline, dan dikompresi. Kompresi menghilangkan kategori konten non-vital dan hanya mempertahankan informasi pemberian makan yang terkait dengan bayi baru lahir. Yang penting, kompresi berhasil menghilangkan konten yang mungkin umumnya relevan untuk halaman tersebut, tetapi di luar topik untuk kueri khusus yang berfokus pada bayi baru lahir ini.

Perbesar

Kesimpulan

Sistem AI mengandalkan informasi sinyal tinggi untuk melayani permintaan pengguna secara cerdas dan efisien. Informasi ini harus disajikan sespesifik mungkin untuk memaksimalkan relevansi dengan setiap kueri. Model kompresi sadar kueri baru kami melakukan hal ini secara persis dengan memaksimalkan bukti sesuai topik per cuplikan dan secara agresif memangkas elemen pengganggu yang tidak relevan.

Dengan menerapkan model baru ini dalam tumpukan pencarian kami, kami dapat memberikan respons yang lebih cepat dan lebih baik kepada mereka yang mengandalkan produk dan API kami. Pendekatan kami menciptakan permukaan kontrol yang sederhana, memungkinkan sistem kami dan pelanggan API untuk menyetel tingkat kompresi guna menyeimbangkan antara perolehan kembali (recall), latensi, dan biaya.

Kurasi konteks adalah bidang yang sedang berkembang, dan masih banyak lagi yang harus dilakukan untuk mengoptimalkan nilai setiap token yang digunakan dalam sistem kecerdasan batas (frontier intelligence systems) saat ini. Kami secara aktif bekerja untuk membuat teknik kurasi konteks kami menjadi lebih baik melalui peningkatan model dan arsitektur sistem guna memanfaatkan model-model ini secara lebih luas.

Referensi

N. Chirkova, T. Formal, V. Nikoulina, dan S. Clinchant. Provence: Pemangkasan Konteks yang Efisien dan Kuat untuk Generasi yang Diperkaya Pengambilan (Retrieval-Augmented Generation), 2025. Diterima di ICLR 2025. arXiv:2501.16214.

T. Do, D. P. Tran, A. Vo, S. K. Kim, dan D. Kim. LooComp: Memanfaatkan Strategi Leave-One-Out pada Transformer Khusus-Encoder untuk Kompresi Konteks Sadar Kueri yang Efisien, 2026. arXiv:2603.09222.

S. Eslami, M. Gaiduk, M. Krimmel, L. Milliken, B. Wang, dan D. Bykov. Embedding Padat dan Kontekstual yang Dilatih-Prarilis Difusi (Diffusion-Pretrained Dense and Contextual Embeddings), 2026. arXiv:2602.11151.

Z. Wang, J. Araki, Z. Jiang, M. R. Parvez, dan G. Neubig. Belajar Menyaring Konteks untuk Generasi yang Diperkaya Pengambilan (Retrieval-Augmented Generation), 2023. arXiv:2311.08377.

Sitasi

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