Pemangkasan Konteks LLM: Panduan bagi Pengembang untuk Hasil RAG dan AI Agen yang Lebih Baik
Jendela konteks di LLM menjadi sangat besar akhir-akhir ini. Beberapa model dapat mengambil satu juta token atau lebih dalam sekali jalan, dan setiap rilis baru tampaknya mendorong angka itu lebih tinggi. Ini menarik, tetapi jika Anda benar-benar telah membuat sesuatu yang menggunakan konteks yang panjang, Anda tahu bahwa ada kesenjangan antara apa yang mungkin dan apa yang berguna.
Hanya karena sebuah model dapat membaca seluruh buku dalam satu prompt, bukan berarti Anda harus memberikannya. Kebanyakan input yang panjang penuh dengan hal-hal yang tidak dibutuhkan oleh model. Begitu Anda mulai memasukkan ratusan ribu token ke dalam sebuah prompt, Anda biasanya akan mendapatkan respons yang lebih lambat, tagihan komputasi yang lebih tinggi, dan terkadang jawaban yang berkualitas lebih rendah karena model mencoba memperhatikan semuanya sekaligus.
Jadi, meskipun jendela konteks terus bertambah besar, pertanyaan yang sebenarnya adalah: apa yang harus kita masukkan ke sana? Di situlah Context Pruning berperan. Pada dasarnya ini adalah proses pemangkasan bagian dari konteks yang diambil atau dirakit yang tidak membantu model menjawab pertanyaan. Jika dilakukan dengan benar, proses ini akan membuat sistem Anda cepat, stabil, dan lebih mudah diprediksi.
Dalam artikel ini, kita akan membahas tentang mengapa konteks yang panjang sering berperilaku berbeda dari yang Anda harapkan, bagaimana pemangkasan membantu menjaga segala sesuatunya tetap terkendali, dan bagaimana alat pemangkasan seperti Provence dapat masuk ke dalam pipa RAG yang sebenarnya tanpa membuat penyiapan Anda menjadi lebih rumit.
Empat Mode Kegagalan Umum dalam Sistem Konteks Panjang
Jendela konteks yang lebih besar tidak secara ajaib membuat model menjadi lebih pintar. Jika ada, setelah Anda mulai memasukkan banyak informasi ke dalam prompt, Anda membuka serangkaian cara baru yang dapat menyebabkan kesalahan. Berikut adalah empat masalah yang akan Anda lihat setiap saat ketika membangun sistem konteks panjang atau RAG.
1. Benturan Konteks
Context Clash terjadi ketika informasi yang terakumulasi di beberapa putaran menjadi saling bertentangan.
Sebagai contoh, seorang pengguna mungkin mengatakan "Saya suka apel" di awal percakapan dan kemudian menyatakan "Saya tidak suka buah." Ketika kedua pernyataan tersebut tetap berada dalam konteks, model tidak memiliki cara yang dapat diandalkan untuk menyelesaikan konflik, yang mengarah pada respons yang tidak konsisten atau ragu-ragu.
2. Kebingungan Konteks
Kebingungan Konteks muncul ketika konteks berisi sejumlah besar informasi yang tidak relevan atau terkait dengan lemah, sehingga menyulitkan model untuk memilih tindakan atau alat yang benar.
Masalah ini terutama terlihat pada sistem yang dilengkapi dengan alat bantu. Ketika konteks dipenuhi dengan detail yang tidak berhubungan, model dapat salah menafsirkan maksud pengguna dan memilih alat atau tindakan yang salah-bukan karena opsi yang benar tidak ada, tetapi karena sinyal terkubur di bawah noise.
3. Gangguan Konteks
Gangguan Konteks terjadi ketika informasi kontekstual yang berlebihan mendominasi perhatian model, sehingga mengurangi ketergantungannya pada pengetahuan yang sudah terlatih dan penalaran umum.
Alih-alih mengandalkan pola yang telah dipelajari secara luas, model akan lebih menitikberatkan pada detail-detail terbaru dalam konteks, bahkan ketika detail-detail tersebut tidak lengkap atau tidak dapat diandalkan. Hal ini dapat menyebabkan penalaran yang dangkal atau rapuh yang mencerminkan konteks terlalu dekat daripada menerapkan pemahaman tingkat yang lebih tinggi.
4. Keracunan Konteks
Keracunan konteks terjadi ketika informasi yang salah masuk ke dalam konteks dan berulang kali direferensikan serta diperkuat secara berulang-ulang.
Satu pernyataan salah yang diperkenalkan di awal percakapan dapat menjadi dasar untuk penalaran berikutnya. Ketika dialog berlanjut, model dibangun berdasarkan asumsi yang salah ini, menambah kesalahan dan semakin menjauh dari jawaban yang benar.
Apa Itu Pemangkasan Konteks dan Mengapa Itu Penting
Begitu Anda mulai berurusan dengan konteks yang panjang, Anda akan segera menyadari bahwa Anda membutuhkan lebih dari satu trik untuk mengendalikannya. Dalam sistem yang sebenarnya, tim biasanya menggabungkan banyak taktik-RAG, pemuatan alat, peringkasan, mengkarantina pesan-pesan tertentu, menghapus riwayat lama, dan sebagainya. Semuanya membantu dengan cara yang berbeda. Tetapi Context Pruning adalah salah satu yang secara langsung memutuskan apa yang sebenarnya diumpankan ke model.
Context Pruning, secara sederhana, adalah proses secara otomatis menghapus informasi yang tidak relevan, bernilai rendah, atau informasi yang saling bertentangan sebelum masuk ke dalam jendela konteks model. Pada dasarnya, ini adalah filter yang hanya menyimpan bagian teks yang paling penting untuk tugas saat ini.
Strategi lain mungkin mengatur ulang konteks, memampatkannya, atau menyisihkan beberapa bagian untuk nanti. Pemangkasan lebih bersifat langsung: pemangkasan menjawab pertanyaan, "Haruskah bagian informasi ini masuk ke dalam prompt?"
Itulah mengapa pemangkasan menjadi sangat penting dalam sistem RAG. Pencarian vektor sangat bagus, tetapi tidak sempurna. Ia sering kali menghasilkan banyak sekali kandidat - beberapa berguna, beberapa tidak berhubungan, beberapa sama sekali tidak relevan. Jika Anda membuang semuanya ke dalam prompt, Anda akan mengalami mode kegagalan yang telah kita bahas sebelumnya. Pemangkasan berada di antara pengambilan dan model, bertindak sebagai penjaga gerbang yang memutuskan potongan mana yang akan disimpan.
Ketika pemangkasan bekerja dengan baik, manfaatnya akan segera terlihat: konteks yang lebih bersih, jawaban yang lebih konsisten, penggunaan token yang lebih rendah, dan lebih sedikit efek samping yang aneh dari teks yang tidak relevan yang menyelinap masuk. Bahkan jika Anda tidak mengubah apa pun tentang pengaturan pengambilan Anda, menambahkan langkah pemangkasan yang solid dapat secara nyata meningkatkan kinerja sistem secara keseluruhan.
Dalam praktiknya, pemangkasan adalah salah satu pengoptimalan dengan leverage tertinggi dalam konteks panjang atau pipeline RAG - ide sederhana, dampak besar.
Provence: Model Pemangkasan Konteks yang Praktis
Ketika menjelajahi pendekatan untuk pemangkasan konteks, saya menemukan dua model sumber terbuka yang menarik yang dikembangkan di Naver Labs Eropa: Provence dan varian multibahasanya, XProvence.
Provence adalah metode untuk melatih model pemangkasan konteks yang ringan untuk pembuatan hasil pencarian, dengan fokus khusus pada jawaban pertanyaan. Diberikan sebuah pertanyaan pengguna dan bagian yang diambil, metode ini mengidentifikasi dan menghapus kalimat yang tidak relevan, dan hanya menyimpan informasi yang berkontribusi pada jawaban akhir.
Dengan memangkas konten bernilai rendah sebelum dibuat, Provence mengurangi noise pada input model, memperpendek petunjuk, dan menurunkan latensi inferensi LLM. Provence juga plug-and-play, dapat bekerja dengan LLM atau sistem retrieval apa pun tanpa memerlukan integrasi yang ketat atau perubahan arsitektur.
Provence menawarkan beberapa fitur praktis untuk pipeline RAG di dunia nyata.
1. Pemahaman Tingkat Dokumen
Provence memahami dokumen secara keseluruhan, daripada menilai kalimat secara terpisah. Hal ini penting karena dokumen dunia nyata sering kali mengandung referensi seperti "itu," "ini," atau "metode di atas." Jika berdiri sendiri-sendiri, kalimat-kalimat ini dapat menjadi ambigu atau bahkan tidak berarti. Jika dilihat dalam konteks, relevansinya menjadi jelas. Dengan memodelkan dokumen secara holistik, Provence menghasilkan keputusan pemangkasan yang lebih akurat dan koheren.
2. Pemilihan Kalimat Adaptif
Provence secara otomatis menentukan berapa banyak kalimat yang harus disimpan dari dokumen yang diambil. Alih-alih bergantung pada aturan tetap seperti "pertahankan lima kalimat teratas", Provence beradaptasi dengan kueri dan konten.
Beberapa pertanyaan dapat dijawab dengan satu kalimat, sementara yang lain memerlukan beberapa pernyataan pendukung. Provence menangani variasi ini secara dinamis, menggunakan ambang batas relevansi yang bekerja dengan baik di seluruh domain dan dapat disesuaikan bila diperlukan - tanpa penyetelan manual dalam banyak kasus.
3. Efisiensi Tinggi dengan Pemeringkatan Terintegrasi
Provence dirancang untuk menjadi efisien. Ini adalah model yang ringkas dan ringan, sehingga jauh lebih cepat dan lebih murah untuk dijalankan daripada pendekatan pemangkasan berbasis LLM.
Lebih penting lagi, Provence dapat menggabungkan pemeringkatan ulang dan pemangkasan konteks ke dalam satu langkah. Karena pemeringkatan ulang sudah menjadi tahap standar dalam pipeline RAG modern, mengintegrasikan pemangkasan pada tahap ini membuat biaya tambahan pemangkasan konteks mendekati nol, sambil tetap meningkatkan kualitas konteks yang diteruskan ke model bahasa.
4. Dukungan Multibahasa melalui XProvence
Provence juga memiliki varian yang disebut XProvence, yang menggunakan arsitektur yang sama tetapi dilatih pada data multibahasa. Hal ini memungkinkannya untuk mengevaluasi kueri dan dokumen lintas bahasa - seperti bahasa Mandarin, Inggris, dan Korea - sehingga cocok untuk sistem RAG multibahasa dan lintas bahasa.
Bagaimana Provence Dilatih
Provence menggunakan desain pelatihan yang bersih dan efektif berdasarkan arsitektur penyandi silang. Selama pelatihan, kueri dan setiap bagian yang diambil digabungkan menjadi satu masukan dan dikodekan bersama. Hal ini memungkinkan model untuk mengamati konteks penuh dari pertanyaan dan bagian sekaligus dan menalar secara langsung tentang relevansinya.
Pengkodean bersama ini memungkinkan Provence untuk belajar dari sinyal relevansi yang halus. Model ini disetel dengan baik pada DeBERTa sebagai penyandi yang ringan dan dioptimalkan untuk melakukan dua tugas secara bersamaan:
Penilaian relevansi tingkat dokumen (skor peringkat): Model ini memprediksi skor relevansi untuk seluruh dokumen, yang mengindikasikan seberapa cocok dokumen tersebut dengan kueri. Sebagai contoh, skor 0,8 menunjukkan relevansi yang kuat.
Pelabelan relevansi tingkat token (topeng biner): Secara paralel, model memberikan label biner untuk setiap token, menandai apakah token tersebut relevan (
1) atau tidak relevan (0) dengan kueri.
Hasilnya, model yang terlatih dapat menilai relevansi keseluruhan dokumen dan mengidentifikasi bagian mana yang harus disimpan atau dihapus.
Pada saat inferensi, Provence memprediksi label relevansi pada tingkat token. Prediksi ini kemudian digabungkan pada tingkat kalimat: sebuah kalimat dipertahankan jika mengandung lebih banyak token yang relevan daripada yang tidak relevan; jika tidak, kalimat tersebut akan dipangkas. Karena model dilatih dengan pengawasan tingkat kalimat, prediksi token dalam kalimat yang sama cenderung konsisten, membuat strategi agregasi ini dapat diandalkan dalam praktiknya. Perilaku pemangkasan juga dapat disetel dengan menyesuaikan ambang batas agregasi untuk mencapai pemangkasan yang lebih konservatif atau lebih agresif.
Yang terpenting, Provence menggunakan kembali langkah pemeringkatan ulang yang sudah ada di sebagian besar pipeline RAG. Ini berarti pemangkasan konteks dapat ditambahkan dengan sedikit atau tanpa biaya tambahan, membuat Provence sangat praktis untuk sistem RAG dunia nyata.
Mengevaluasi Kinerja Pemangkasan Konteks di Seluruh Model
Sejauh ini, kita telah berfokus pada desain dan pelatihan Provence. Langkah selanjutnya adalah mengevaluasi bagaimana kinerjanya dalam praktik: seberapa baik pemangkasan konteks, bagaimana perbandingannya dengan pendekatan lain, dan bagaimana perilakunya dalam kondisi dunia nyata.
Untuk menjawab pertanyaan-pertanyaan tersebut, kami merancang serangkaian eksperimen kuantitatif untuk membandingkan kualitas pemangkasan konteks pada beberapa model dalam pengaturan evaluasi yang realistis.
Eksperimen ini berfokus pada dua tujuan utama:
Efektivitas pemangkasan: Kami mengukur seberapa akurat setiap model mempertahankan konten yang relevan sambil menghapus informasi yang tidak relevan, menggunakan metrik standar seperti Precision, Recall, dan skor F1.
Generalisasi di luar domain: Kami mengevaluasi seberapa baik kinerja setiap model pada distribusi data yang berbeda dari data pelatihannya, menilai ketahanan dalam skenario di luar domain.
Model-model yang Dibandingkan
OpenSearch Semantic Highlighter (Model pemangkasan berdasarkan arsitektur BERT, yang dirancang khusus untuk tugas-tugas penyorotan semantik)
Dataset
Kami menggunakan WikiText-2 sebagai dataset evaluasi. WikiText-2 berasal dari artikel Wikipedia dan berisi struktur dokumen yang beragam, di mana informasi yang relevan sering kali tersebar di berbagai kalimat dan hubungan semantiknya tidak sepele.
Yang penting, WikiText-2 berbeda secara substansial dari data yang biasanya digunakan untuk melatih model pemangkasan konteks, namun tetap menyerupai konten dunia nyata yang sarat dengan pengetahuan. Hal ini membuatnya cocok untuk evaluasi di luar domain, yang merupakan fokus utama eksperimen kami.
Pembuatan Kueri dan Anotasi
Untuk membuat tugas pemangkasan di luar domain, kami secara otomatis menghasilkan pasangan pertanyaan-jawaban dari korpus WikiText-2 mentah menggunakan GPT-4o-mini. Setiap sampel evaluasi terdiri dari tiga komponen:
Pertanyaan: Pertanyaan bahasa alami yang dihasilkan dari dokumen.
Konteks: Dokumen lengkap yang belum dimodifikasi.
Ground Truth: Anotasi tingkat kalimat yang menunjukkan kalimat mana yang berisi jawaban (untuk dipertahankan) dan mana yang tidak relevan (untuk dipangkas).
Pengaturan ini secara alami mendefinisikan tugas pemangkasan konteks: dengan adanya kueri dan dokumen lengkap, model harus mengidentifikasi kalimat-kalimat yang benar-benar penting. Kalimat yang mengandung jawaban diberi label relevan dan harus dipertahankan, sementara semua kalimat lainnya dianggap tidak relevan dan harus dipangkas. Formulasi ini memungkinkan kualitas pemangkasan diukur secara kuantitatif dengan menggunakan Precision, Recall, dan skor F1.
Yang terpenting, pertanyaan yang dihasilkan tidak muncul dalam data pelatihan model yang dievaluasi. Hasilnya, performa mencerminkan generalisasi yang sebenarnya, bukan hafalan. Secara keseluruhan, kami menghasilkan 300 sampel, yang mencakup pertanyaan berbasis fakta sederhana, tugas penalaran multi-hop, dan permintaan analitis yang lebih kompleks, untuk lebih mencerminkan pola penggunaan di dunia nyata.
Jalur Evaluasi
Pengoptimalan Hyperparameter: Untuk setiap model, kami melakukan pencarian grid pada ruang hyperparameter yang telah ditentukan sebelumnya dan memilih konfigurasi yang memaksimalkan skor F1.
Hasil dan Analisis
Hasilnya menunjukkan perbedaan kinerja yang jelas di ketiga model.
Provence mencapai kinerja keseluruhan terkuat, dengan skor F1 66,76%. Presisi(69,53%) dan Recall(64,19%) seimbang, menunjukkan generalisasi di luar domain yang kuat. Konfigurasi optimal menggunakan ambang batas pemangkasan sebesar 0.6 dan α = 0.051, yang menunjukkan bahwa skor relevansi model telah dikalibrasi dengan baik dan perilaku pemangkasan bersifat intuitif dan mudah untuk disetel dalam praktiknya.
XProvence mencapai skor F1 sebesar 58,97%, ditandai dengan recall yang tinggi (75,52% ) dan presisi yang lebih rendah (48,37%). Hal ini mencerminkan strategi pemangkasan yang lebih konservatif yang memprioritaskan mempertahankan informasi yang berpotensi relevan daripada menghilangkan noise secara agresif. Perilaku seperti itu dapat diinginkan dalam domain di mana negatif palsu mahal - seperti aplikasi perawatan kesehatan atau hukum - tetapi juga meningkatkan positif palsu, yang menurunkan presisi. Terlepas dari pertukaran ini, kemampuan multibahasa XProvence menjadikannya pilihan yang kuat untuk pengaturan non-Inggris atau lintas bahasa.
Sebaliknya, OpenSearch Semantic Highlighter berkinerja jauh lebih buruk, dengan skor F1 46,37% (Presisi 62,35%, Recall 36,98%). Kesenjangan relatif terhadap Provence dan XProvence menunjukkan keterbatasan dalam kalibrasi skor dan generalisasi di luar domain, terutama dalam kondisi di luar domain.
Penyorotan Semantik: Cara Lain untuk Menemukan Apa yang Sebenarnya Penting dalam Teks
Setelah kita membahas tentang pemangkasan konteks, ada baiknya kita melihat bagian teka-teki yang terkait: penyorotan semantik. Secara teknis, kedua fitur ini melakukan pekerjaan yang hampir sama-mereka menilai potongan teks berdasarkan seberapa relevan mereka dengan kueri. Perbedaannya adalah bagaimana hasilnya digunakan dalam pipeline.
Kebanyakan orang mendengar "penyorotan" dan memikirkan penyorot kata kunci klasik yang Anda lihat di Elasticsearch atau Solr. Alat-alat ini pada dasarnya mencari kecocokan kata kunci secara harfiah dan membungkusnya dengan sesuatu seperti <em>. Alat-alat ini murah dan dapat diprediksi, tetapi hanya berfungsi ketika teks menggunakan kata-kata yang sama persis dengan kueri. Jika dokumen memparafrasekan, menggunakan sinonim, atau frasa ide secara berbeda, penyorot tradisional akan melewatkannya sama sekali.
Penyorotan semantik mengambil rute yang berbeda. Alih-alih memeriksa kecocokan string yang tepat, ia menggunakan model untuk memperkirakan kesamaan semantik antara kueri dan rentang teks yang berbeda. Hal ini memungkinkannya menyoroti konten yang relevan bahkan ketika kata-katanya benar-benar berbeda. Untuk pipeline RAG, alur kerja agen, atau sistem pencarian AI apa pun di mana makna lebih penting daripada token, penyorotan semantik memberi Anda gambaran yang jauh lebih jelas tentang mengapa sebuah dokumen diambil.
Masalahnya adalah sebagian besar solusi penyorotan semantik yang ada tidak dibuat untuk beban kerja AI produksi. Kami menguji semua yang tersedia, dan tidak ada satu pun yang memberikan tingkat presisi, latensi, atau keandalan multibahasa yang kami perlukan untuk sistem RAG dan agen yang sebenarnya. Jadi, kami akhirnya melatih dan membuat model kami sendiri sebagai gantinya: zilliz/semantic-highlight-bilingual-v1
Pada tingkat tinggi, pemangkasan konteks dan penyorotan semantik menyelesaikan tugas inti yang sama: diberi kueri dan sepotong teks, cari tahu bagian mana yang benar-benar penting. Satu-satunya perbedaan adalah apa yang terjadi selanjutnya.
Pemangkasankonteks membuang bagian yang tidak relevan sebelum dibuat.
Penyorotan semantik mempertahankan teks lengkap tetapi secara visual menampilkan bagian yang penting.
Karena operasi yang mendasarinya sangat mirip, model yang sama sering kali dapat mendukung kedua fitur tersebut. Hal ini mempermudah penggunaan ulang komponen di seluruh tumpukan dan membuat sistem RAG Anda lebih sederhana dan efisien secara keseluruhan.
Penyorotan Semantik di Milvus dan Zilliz Cloud
Penyorotan semantik kini didukung penuh di Milvus dan Zilliz Cloud (layanan yang dikelola sepenuhnya oleh Milvus), dan telah terbukti bermanfaat bagi siapa pun yang bekerja dengan RAG atau pencarian berbasis AI. Fitur ini memecahkan masalah yang sangat sederhana namun menyakitkan: ketika pencarian vektor menghasilkan banyak sekali potongan, bagaimana Anda dengan cepat mengetahui kalimat mana di dalam potongan-potongan itu yang benar-benar penting?
Tanpa penyorotan, pengguna akan membaca seluruh dokumen hanya untuk memahami mengapa sesuatu diambil. Dengan penyorotan semantik, Milvus dan Zilliz Cloud secara otomatis menandai rentang tertentu yang secara semantik terkait dengan kueri Anda - meskipun kata-katanya berbeda. Tidak perlu lagi mencari kecocokan kata kunci atau menebak-nebak mengapa sebuah potongan muncul.
Hal ini membuat pencarian menjadi jauh lebih transparan. Alih-alih hanya mengembalikan "dokumen yang relevan", Milvus menunjukkan di mana relevansinya. Untuk pipeline RAG, hal ini sangat membantu karena Anda dapat langsung melihat apa yang seharusnya dilakukan oleh model, sehingga membuat debugging dan konstruksi yang cepat menjadi lebih mudah.
Kami membangun dukungan ini langsung ke dalam Milvus dan Zilliz Cloud, sehingga Anda tidak perlu memasang model eksternal atau menjalankan layanan lain hanya untuk mendapatkan atribusi yang dapat digunakan. Semuanya berjalan di dalam jalur pencarian: pencarian vektor → penilaian relevansi → rentang yang disorot. Ini bekerja di luar kotak pada skala besar dan mendukung beban kerja multibahasa dengan model zilliz/semantic-highlight-bilingual-v1 kami.
Melihat ke Depan
Rekayasa konteks masih cukup baru, dan masih banyak yang harus dipelajari. Bahkan dengan pemangkasan dan penyorotan semantik yang bekerja dengan baik di dalam Milvus dan Zilliz Cloud, kami masih belum sampai pada akhir cerita. Ada banyak area yang masih membutuhkan pekerjaan teknik yang nyata - membuat model pemangkasan lebih akurat tanpa memperlambat segalanya, menjadi lebih baik dalam menangani kueri yang aneh atau di luar domain, dan menyambungkan semua bagian bersama-sama sehingga pengambilan → peringkat ulang → pemangkasan → sorotan terasa seperti satu jalur pipa yang bersih alih-alih satu set peretasan yang direkatkan.
Karena jendela konteks terus berkembang, keputusan ini menjadi semakin penting. Manajemen konteks yang baik bukanlah "bonus yang bagus" lagi; manajemen konteks menjadi bagian inti untuk membuat sistem konteks panjang dan RAG berperilaku dengan baik.
Kami akan terus bereksperimen, melakukan benchmarking, dan mengirimkan bagian-bagian yang benar-benar membuat perbedaan bagi para pengembang. Tujuannya sangat jelas: mempermudah pembuatan sistem yang tidak rusak karena data yang berantakan, kueri yang tidak dapat diprediksi, atau beban kerja berskala besar.
Jika Anda ingin membicarakan semua ini - atau hanya butuh bantuan untuk men-debug sesuatu - Anda bisa masuk ke saluran Discord kami atau memesan sesi tatap muka selama 20 menit untuk mendapatkan wawasan, panduan, dan jawaban atas pertanyaan Anda melalui Milvus Office Hours.
Kami selalu senang mengobrol dan bertukar catatan dengan para pembuat lainnya.
Try Managed Milvus for Free
Zilliz Cloud is hassle-free, powered by Milvus and 10x faster.
Get StartedLike the article? Spread the word



