Cache semantik LLM: ambang menentukan jawaban ulang

Untuk membuat cache semantik bagi LLM, mulai dengan menyimpan jawaban untuk permintaan yang cocok persis. Tambahkan embedding dan pencarian vektor untuk menemukan pertanyaan lama dengan makna serupa, lalu pakai ulang jawabannya hanya jika evaluator meloloskan kandidat pada ambang kemiripan yang telah diuji. Jika kandidat gagal, kirim permintaan ke LLM dan putuskan apakah respons barunya layak disimpan.

Cache semantik paling layak dicoba ketika pertanyaan dengan redaksi berbeda sering membutuhkan jawaban yang sama dan relatif stabil. Ambang yang terlalu longgar bisa meningkatkan jumlah hit sekaligus meloloskan jawaban yang salah. Karena itu, uji pasangan pertanyaan berbahasa Indonesia sebelum menganggap panggilan API yang terhindar sebagai penghematan.

Kapan kecocokan persis cukup

Ukur dahulu permintaan identik yang berulang. Cache kecocokan persis memberi pembanding untuk menilai manfaat tambahan pencarian semantik: jika pengulangan jarang dan variasi redaksi juga sedikit, biaya embedding, penyimpanan, serta pencarian mungkin tidak sepadan. Jika banyak pengguna menanyakan hal yang sama dengan kata berbeda, pencarian semantik berpeluang menemukan jawaban yang tidak terjangkau oleh kunci teks biasa.

Bentuk kunci kecocokan persis dari seluruh konteks yang menentukan jawaban, bukan hanya kalimat terakhir pengguna. Versi instruksi sistem, model yang digunakan, bahasa jawaban, hak akses, dan versi dokumen rujukan dapat membuat dua permintaan yang tampak sama membutuhkan respons berbeda. Gunakan atribut tersebut pula untuk membatasi kandidat sebelum pencarian semantik; skor embedding tidak dapat menetapkan siapa yang berhak menerima jawaban pelanggan lain.

Riset tentang ruang kueri berkelanjutan menjelaskan bahwa penggunaan ulang respons untuk pertanyaan yang serupa secara semantik dapat mengurangi biaya inferensi dan latensi. Kueri nyata menempati ruang embedding yang berkelanjutan, sehingga variasinya tidak tepat diperlakukan sebagai daftar pertanyaan tetap yang sudah diketahui. Untuk aplikasi tertentu, besarnya manfaat tetap bergantung pada pola permintaan dan mutu hit yang benar-benar terjadi.

Komponen yang memutuskan hit

Alur cache semantik dimulai dengan menentukan permintaan yang boleh dicari. Sistem kemudian membuat embedding, mengambil kandidat dari penyimpanan vektor, dan meminta evaluator menilai apakah jawaban kandidat masih sesuai. Simpan pertanyaan, jawaban, metadata pembatas, waktu pembuatan, dan vektornya sebagai entri yang saling terhubung. Pada cache miss, respons LLM baru hanya perlu disimpan bila dapat digunakan lagi dalam konteks yang diizinkan.

Panduan GPTCache memisahkan fungsi embedding, penyimpanan data, penyimpanan vektor, kebijakan eviction, dan evaluator. Contohnya memasangkan SQLite untuk data dengan FAISS untuk pencarian vektor. Evaluator dapat memakai kecocokan persis, jarak embedding, atau model ONNX; konfigurasi similarity_threshold menetapkan batas penerimaan kandidat. Nilai ambang dalam contoh konfigurasi bukan ukuran mutu untuk pertanyaan aplikasi lain.

Gunakan model embedding yang sama saat membuat entri dan saat mencari kandidat, serta catat versinya. Perubahan model dapat mengubah representasi dan skor, sehingga entri atau ambang lama perlu dievaluasi kembali. Untuk percakapan, sertakan fakta dari giliran sebelumnya yang menentukan jawaban: pertanyaan “Bagaimana caranya?” tidak bermakna sama jika satu percakapan membahas pembatalan pesanan dan percakapan lain membahas pengembalian barang.

Kalibrasi dengan pertanyaan Indonesia

Perbedaan tahap pesanan menentukan apakah jawaban perubahan alamat dapat dipakai ulang.

Susun pasangan pertanyaan dari ragam bahasa yang memang diperkirakan muncul di layanan, termasuk singkatan, susunan kata berbeda, dan perubahan kecil pada syarat. Beri label berdasarkan satu pertanyaan: apakah jawaban tersimpan tetap benar dan lengkap untuk permintaan baru? Kesamaan topik saja tidak cukup. Pasangan berikut adalah contoh hipotetis untuk layanan pengiriman, bukan hasil pengujian suatu aplikasi:

“Bagaimana mengubah alamat pengiriman sebelum pesanan diproses?” dan “Bisa ganti alamat kirim sebelum pesanan diproses?” dapat menjadi hit benar jika aturan serta jawaban yang berlaku sama.
“Bagaimana mengubah alamat pengiriman sebelum pesanan diproses?” dan “Bagaimana mengubah alamat setelah pesanan diproses?” menjadi hit salah apabila tahap pemrosesan mengubah prosedurnya.
“Apakah ongkir ke Bandung bisa dikembalikan?” dan “Apakah ongkir ke Surabaya bisa dikembalikan?” harus diberi label menurut ketentuan tujuan pengiriman yang sebenarnya.
“Bagaimana membatalkan pesanan?” dan “Bagaimana mengembalikan pesanan?” perlu jawaban terpisah jika pembatalan dan pengembalian mengikuti prosedur berbeda.

Jalankan pasangan berlabel melalui embedding, pencarian vektor, dan evaluator yang sama dengan rancangan produksi. Catat kandidat, skor, serta keputusan hit pada beberapa ambang. Bandingkan keputusan itu dengan label manusia, lalu pilih batas yang menjaga hit salah pada tingkat yang dapat diterima untuk jenis jawaban tersebut. Pertanyaan tentang status pesanan atau hak pelanggan mungkin membutuhkan toleransi kesalahan lebih rendah daripada jawaban penjelasan umum.

Hit salah terjadi ketika jawaban lama tidak dapat menggantikan jawaban baru, seperti prosedur sebelum pemrosesan yang diberikan untuk pesanan yang sudah diproses. Catat pula pasangan yang sebenarnya dapat berbagi jawaban tetapi ditolak cache. Jika skor untuk kedua kelompok banyak bertumpang tindih, perbaiki metadata pembatas, teks yang dijadikan embedding, atau evaluator; menggeser ambang saja belum tentu memisahkan keduanya.

Kesegaran jawaban dan batas kapasitas

Perubahan harga di toko menunjukkan mengapa jawaban cache yang sensitif waktu perlu dibatasi masa berlakunya.

Periksa kesegaran sebelum menilai kemiripan. Pertanyaan tentang harga hari ini, stok, status pesanan, atau kebijakan yang baru berubah sebaiknya melewati cache semantik jika aplikasi tidak dapat memastikan bahwa jawaban tersimpan masih berlaku. Untuk jawaban yang lebih stabil, tetapkan masa berlaku berdasarkan kecepatan perubahan sumber data dan hapus entri terkait ketika sumbernya diperbarui.

Panduan Amazon ElastiCache menyebut respons berulang yang relatif stabil sebagai kandidat cache dan respons sangat dinamis sebagai kandidat yang lemah. Panduan itu menjelaskan pertukaran antara tingkat hit dan risiko mutu saat ambang diubah, penggunaan TTL untuk membatasi usia respons, serta eviction LRU untuk membebaskan ruang ketika memori penuh. TTL mengatur kapan jawaban kedaluwarsa; eviction memilih entri yang dibuang karena kapasitas.

Ketika sebuah entri dihapus, buang pula hubungan antara jawaban dan vektornya. Vektor yang masih muncul dalam pencarian setelah jawabannya hilang menghasilkan kandidat tanpa respons yang dapat dipakai. Sebaliknya, jawaban yang terlepas dari metadata versi atau hak akses dapat lolos dalam konteks yang salah. Penghapusan akibat perubahan dokumen rujukan perlu menjangkau seluruh entri yang bergantung pada versi dokumen tersebut.

Ukur mutu sebelum menghitung penghematan

Bandingkan permintaan dari jenis yang sama dengan dan tanpa cache. Catat jumlah hit benar, hit salah, jawaban yang seharusnya dapat dipakai ulang tetapi terlewat, serta panggilan LLM yang benar-benar terhindar. Ukur latensi dari awal hingga jawaban diterima, termasuk waktu embedding dan pencarian; pisahkan hit dan miss agar respons cepat dari cache tidak menutupi miss yang menjadi lebih lambat.

Hit rate saja tidak menunjukkan mutu: semua kandidat yang diterima dapat dihitung sebagai hit meski sebagian jawabannya keliru. Untuk menilai biaya bersih, kurangi biaya embedding, penyimpanan, dan operasi cache dari biaya inferensi yang terhindar melalui hit benar. Hit salah tidak layak dihitung sebagai penghematan yang berhasil karena jawabannya mungkin memerlukan koreksi atau eskalasi di luar tagihan API.

Mulai penerapan pada kelompok pertanyaan dengan jawaban stabil dan batas akses yang jelas. Tinjau contoh hit salah dari lalu lintas tersebut, lalu perluas cakupan jika ketepatan jawaban dan penghematan bersih sama-sama terjaga. Ketika dokumen, model embedding, atau jenis permintaan berubah, ulangi evaluasi ambang dengan pasangan pertanyaan yang mewakili kondisi baru.