Kompresi Token untuk LLM: Kurangi Biaya Konteks Sebelum Routing

Kompresi token untuk LLM adalah praktik mengecilkan prompt, konteks yang diambil, output alat, riwayat obrolan, dan log sebelum mencapai model. Ini tidak menggantikan routing, evaluasi, atau failover. Ini membuat sistem tersebut bekerja dengan input yang lebih bersih.

Hal ini penting karena sebagian besar masalah biaya dan latensi AI dimulai sebelum permintaan meninggalkan aplikasi Anda. Bot dukungan mungkin mengirimkan seluruh thread tiket ketika hanya tiga fakta yang penting. Agen mungkin menempelkan respons alat penuh ketika hanya membutuhkan status, jumlah, dan tindakan berikutnya. Alur kerja RAG mungkin mengambil lima potongan ketika satu jawaban ringkas sudah cukup.

OpenAI menjelaskan bahwa penggunaan API diukur dalam token, dan token tersebut berasal dari teks input dan output. Konteks panjang bukanlah konteks gratis. Tujuannya bukan untuk membuat model kekurangan. Tujuannya adalah mengirimkan konteks terkecil yang tetap mempertahankan keputusan, bukti, dan batasan yang dibutuhkan model.

Mengapa kompresi token penting sebelum routing

Banyak tim menganggap optimasi biaya sebagai masalah pemilihan model: mengirimkan pekerjaan mudah ke model yang lebih murah, menyimpan model premium untuk pekerjaan yang lebih sulit, dan menggunakan failover ketika rute penyedia menurun. Itu berguna, tetapi melewatkan poin dasar: router hanya melihat permintaan yang Anda berikan.

Jika permintaan terlalu besar, setiap keputusan di hilir menjadi lebih sulit. Model murah mungkin gagal karena menerima terlalu banyak kebisingan. Model frontier mungkin terlihat diperlukan karena prompt terlalu berantakan. Observabilitas mungkin menunjukkan pengeluaran tinggi, tetapi tidak konteks yang dapat dihindari yang menyebabkannya.

Kompresi menambahkan langkah sebelum akses model: mengurangi payload, mempertahankan niat, lalu melakukan routing. Dengan Marketplace model ShareAI, permintaan yang lebih bersih itu kemudian dapat dievaluasi terhadap pilihan model, harga, latensi, ketersediaan, dan kebutuhan routing di satu API.

Apa yang harus dikompresi?

Tidak semua token layak mendapatkan perlakuan yang sama. Beberapa teks sangat penting untuk instruksi. Beberapa teks adalah bukti. Beberapa teks hanya residu dari langkah sebelumnya.

Area input	Pendekatan kompresi	Apa yang harus dipertahankan
Riwayat obrolan	Ringkas putaran sebelumnya menjadi keadaan, keputusan, batasan, dan pertanyaan terbuka.	Maksud pengguna, komitmen, nama, preferensi, dan tugas yang belum terselesaikan.
Potongan RAG	Ambil secara sempit, deduplikasi, dan ekstrak bagian yang menjawab pertanyaan saat ini.	Kutipan, fakta tepat, bukti yang bertentangan, dan sinyal kesegaran.
Output alat	Ubah respons yang panjang menjadi bidang terstruktur yang ringkas.	Status, ID, jumlah, kesalahan, cap waktu, dan tindakan berikutnya.
Log dan jejak	Kelompokkan peristiwa yang berulang dan simpan hanya anomali, jumlah, dan sampel yang relevan.	Pola kesalahan, frekuensi, layanan yang terpengaruh, dan garis waktu.
Instruksi sistem	Hapus teks kebijakan yang duplikat dan pisahkan instruksi yang stabil dari konteks spesifik tugas.	Aturan keselamatan, kontrak output, batasan peran, dan izin alat.

Lima metode kompresi praktis

1. Ringkas keadaan, bukan prosa

Ringkasan yang lemah menulis ulang percakapan panjang menjadi paragraf yang lebih pendek. Ringkasan yang berguna mempertahankan keadaan operasional: apa yang diinginkan pengguna, apa yang sudah dicoba, apa yang gagal, batasan apa yang tersisa, dan keputusan berikutnya.

Untuk agen, ringkasan keadaan harus diperbarui pada batas yang diketahui: setelah pemanggilan alat, setelah keputusan pengguna, setelah langkah alur kerja, atau sebelum beralih model. Jangan menghilangkan ID, persyaratan, atau batasan negatif.

2. Ekstrak bidang dari keluaran alat

Banyak pemanggilan alat menghasilkan teks jauh lebih banyak daripada yang dibutuhkan langkah model berikutnya. Alih-alih meneruskan seluruh respons, ekstrak bidang yang penting. Pencarian pembayaran mungkin menjadi ID pelanggan, status faktur, saldo, tanggal jatuh tempo, dan tanda risiko. Hasil pencarian mungkin menjadi judul, URL kanonik, tanggal, dan satu kalimat yang mendukung klaim.

3. Saring pengambilan sebelum generasi

Sistem RAG sering membuang token dengan mengirimkan potongan yang serupa, potongan lama, atau potongan yang cocok dengan kata kunci tetapi tidak dengan maksud. Lapisan kompresi dapat menduplikasi ulang bagian yang tumpang tindih, menghapus konteks yang usang, dan hanya menyimpan bukti yang menjawab pertanyaan saat ini.

Ini sangat penting ketika jawaban akhir membutuhkan kutipan. Kompres konteks, tetapi pertahankan detail sumber yang cukup untuk memverifikasi jawaban nanti.

4. Gunakan keluaran antara yang terstruktur

Teks antara yang bebas bentuk tumbuh dengan cepat. Keluaran terstruktur tetap lebih kecil dan lebih mudah diaudit. Alih-alih meminta satu model untuk menjelaskan setiap tindakan kandidat, mintalah model tersebut mengembalikan daftar opsi yang ringkas dengan bidang seperti tindakan, kepercayaan, alasan, masalah penghalang, dan input yang diperlukan.

5. Perlakukan caching prompt sebagai tuas terpisah

Caching prompt dapat mengurangi biaya atau latensi prefiks yang berulang dalam sistem yang didukung, tetapi ini tidak sama dengan kompresi token. Teks yang di-cache masih dapat mengonsumsi ruang jendela konteks, dan masih dapat membuat permintaan lebih sulit untuk diperiksa. Anthropic’s jendela-konteks dan penyimpanan-prompt dokumentasi adalah pengingat yang berguna bahwa caching dan desain konteks menyelesaikan masalah yang terkait tetapi berbeda.

Di mana kompresi cocok dalam alur kerja ShareAI

ShareAI adalah pasar AI dan API, bukan tempat di mana Anda membangun aplikasi itu sendiri. Aplikasi Anda memiliki pengalaman pengguna, logika alur kerja, pemilihan konteks, dan langkah kompresi. ShareAI membantu sisi akses model: satu API untuk 150+ model, visibilitas pasar, routing, failover, dan pelacakan penggunaan.

1. Kumpulkan permintaan pengguna mentah dan konteks aplikasi.
2. Hapus duplikasi, konteks yang usang, dan hasil pencarian yang tidak relevan.
3. Kompres keadaan percakapan yang lebih lama dan keluaran alat yang panjang.
4. Kirimkan permintaan yang telah dibersihkan melalui ShareAI API.
5. Rute berdasarkan kecocokan model, harga, latensi, ketersediaan, dan kebutuhan fallback.
6. Ukur kualitas, biaya, dan pola kegagalan setelah respons.

Untuk Pembuat, kompresi juga dapat membuat monetisasi lebih bersih. Jika aplikasi yang ada merutekan lalu lintas inferensi AI melalui ShareAI, Pembuat dapat mengonfigurasi biaya tambahan atau margin dan menerima pembayaran bulanan berdasarkan penggunaan yang dihasilkan. Konteks yang lebih bersih membantu menjaga penggunaan yang dirutekan lebih mudah dijelaskan kepada pelanggan karena pengguna berat membayar untuk lalu lintas AI yang benar-benar mereka hasilkan.

Cara mengukur apakah kompresi bekerja

Kompresi hanya berguna jika kualitas tetap terjaga. Lacak itu seperti perubahan produksi, bukan trik prompt yang cerdas.

• Token input per permintaan: harus turun untuk alur kerja yang ditargetkan.
• Kualitas keluaran: harus tetap stabil pada tugas-tugas representatif.
• Tingkat fallback: tidak boleh meningkat karena rute yang lebih murah menerima konteks yang lebih lemah.
• Latensi: harus meningkat, atau setidaknya membenarkan setiap langkah praproses.
• Tingkat eskalasi: harus mengungkapkan ketika konteks terkompresi memaksa pengguna atau agen untuk bertanya lagi.
• Biaya per tugas yang berhasil: harus menurun, bukan hanya biaya per permintaan.

Set pengujian yang baik mencakup prompt pendek, prompt panjang, tugas agen yang banyak menggunakan alat, pertanyaan RAG, dan kasus tepi di mana konteks yang hilang akan menyebabkan jawaban yang salah. Bandingkan hasil terkompresi dan tidak terkompresi sebelum menjadikan kompresi sebagai default.

Kapan tidak melakukan kompresi secara agresif

Kompresi memiliki trade-off. Ini dapat menghilangkan nuansa, menyembunyikan ketidakpastian, atau meratakan bukti yang dibutuhkan model. Gunakan kompresi ringan ketika kata-kata yang tepat penting, ketika model harus menalar kontrak atau kebijakan, ketika kutipan harus dipertahankan, atau ketika pengguna secara eksplisit meminta materi sumber yang lengkap.

Pola yang paling aman adalah kompresi progresif. Simpan materi sumber dengan fidelitas tinggi tersedia dalam aplikasi Anda, berikan konteks yang ringkas kepada model, dan ambil kembali bukti asli ketika tugas membutuhkan verifikasi.

FAQ: Kompresi token untuk LLM

Apa itu kompresi token untuk LLM?

Kompresi token untuk LLM berarti mengurangi teks input yang tidak perlu sebelum panggilan model sambil mempertahankan fakta, instruksi, dan batasan yang diperlukan untuk respons yang baik.

Apakah kompresi token sama dengan menggunakan model yang lebih kecil?

Tidak. Kompresi mengurangi permintaan. Pemilihan model menentukan ke mana permintaan itu diarahkan. Pengaturan terkuat sering kali melakukan keduanya: kompres konteks terlebih dahulu, lalu arahkan ke model yang tepat.

Apakah ShareAI secara otomatis mengompresi prompt?

Kompresi biasanya merupakan pilihan desain di sisi aplikasi. ShareAI menyediakan marketplace AI dan lapisan API untuk akses model, pengalihan, failover, dan visibilitas penggunaan setelah aplikasi Anda mempersiapkan permintaan.

Bagaimana kompresi membantu mengurangi biaya LLM?

Sebagian besar API AI menetapkan harga penggunaan berdasarkan token input dan output. Jika Anda mengurangi token input dengan aman sambil menjaga kualitas tetap stabil, biaya per tugas yang berhasil dapat turun.

Apakah kompresi token dapat merusak kualitas respons?

Ya. Kompresi berlebihan dapat menghilangkan bukti, nuansa, atau batasan. Uji prompt yang dikompresi terhadap tugas nyata dan pantau kualitas jawaban, tingkat fallback, dan koreksi pengguna.

Apa yang harus diketahui oleh Builders tentang kompresi?

Builders yang mengarahkan penggunaan AI dari aplikasi yang ada melalui ShareAI dapat menggunakan kompresi untuk menjaga lalu lintas yang diarahkan tetap bersih. Mereka masih dapat menetapkan biaya tambahan atau margin dan menerima pembayaran bulanan dari penggunaan yang dihasilkan.

Apakah kompresi token berguna untuk RAG?

Ya. Sistem RAG sering kali mengirimkan potongan yang redundan atau kurang relevan. Kompresi dapat menduplikasi, menyaring, dan mengekstrak bagian yang menjawab pertanyaan saat ini.

Apakah caching prompt merupakan pengganti kompresi?

Tidak. Caching prompt dapat membantu dengan prefiks yang berulang dalam sistem yang didukung, tetapi kompresi tetap penting ketika konteks berisik, usang, duplikat, atau terlalu besar untuk tugas tersebut.

Tim mana yang paling diuntungkan dari kompresi token?

Tim dengan riwayat obrolan panjang, agen yang banyak menggunakan alat, alur kerja dokumen, otomatisasi dukungan, asisten penelitian, dan sistem RAG biasanya melihat kebutuhan yang paling jelas untuk kompresi.

Bagaimana saya harus mulai menguji kompresi?

Pilih satu alur kerja yang mahal, tangkap permintaan yang representatif, buat versi yang dikompresi, dan bandingkan penggunaan token, kualitas jawaban, latensi, dan biaya per tugas yang berhasil.

Bagaimana kompresi bekerja dengan pengaturan AI?

Kompresi mempersiapkan permintaan yang lebih bersih. Pengaturan menentukan model atau rute penyedia terbaik untuk permintaan tersebut berdasarkan harga, latensi, ketersediaan, keandalan, dan kebutuhan kualitas.

Langkah berikutnya

Mulailah dengan satu alur kerja di mana pembengkakan konteks terlihat. Kompres bagian yang berisik, simpan bukti yang penting, lalu gunakan ShareAI untuk membandingkan rute model melalui satu API. Target praktisnya sederhana: lebih sedikit token yang terbuang, lebih sedikit eskalasi yang dapat dihindari, dan data penggunaan yang lebih jelas.