Mengapa Semantic Cache Anda Memberikan Jawaban yang Salah

Seorang pengguna melaporkan bahwa plugin terjemahan kami memberikan hasil cache yang sama untuk setiap permintaan, terlepas dari inputnya. Kami melakukan investigasi dan menemukan sesuatu yang lebih buruk: 95% dari semua hit semantic cache di seluruh platform kami adalah positif palsu (false positive). 199 permintaan terjemahan yang berbeda, 198 badan permintaan unik, namun satu respons cache yang sama disajikan untuk semuanya.

Jika Anda peduli dengan status agen jangka panjang dan penanganan permintaan produksi, postingan ini sangat cocok disandingkan dengan Mengapa Agen AI Anda Terus Kehilangan Memorinya, panduan chatbot satu kunci, dan panduan pembatasan laju AI API.

Poin Utama

• 95% dari hit semantic cache di seluruh platform adalah positif palsu, dengan 198 permintaan unik semuanya mendapatkan respons cache tunggal yang sama.
• Penyebab utamanya adalah input terstruktur. Teks template tetap mendominasi vektor embedding, sehingga konten yang bervariasi hampir tidak mengubah kemiripan kosinus (cosine similarity).
• Meningkatkan ambang batas kemiripan tidak memperbaiki masalah ini, karena distribusi hit yang benar dan salah saling tumpang tindih. Penelitian terbaru tentang keandalan semantic cache mengonfirmasi pola yang sama.
• Perbaikannya berjalan dalam dua lapisan: ekstrak konten yang bermakna sebelum embedding, lalu verifikasi setiap hit dengan hash sidik jari FNV-1a yang cepat. Ini menurunkan positif palsu dari sekitar 95% menjadi di bawah 5%.
• Pilihan model memengaruhi paparan. Prompt sistem yang panjang dan input yang dibungkus JSON memperburuk masalah terlepas dari model mana yang menyajikan penyelesaian; periksa direktori model TokenLab (diamati 07-07-2026) untuk opsi model saat ini jika Anda memutuskan model mana yang akan digunakan untuk merutekan lalu lintas cache.

Laporan Bug

Laporannya sederhana: "Saya menonaktifkan semantic cache, tetapi setiap terjemahan mengembalikan hasil yang sama."

Tiga ID permintaan, tiga segmen terjemahan berbeda, respons cache identik. Badan permintaan berkisar dari 1.564 hingga 8.676 byte. ID respons cache sama untuk semuanya: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

Kecurigaan pertama: pengaturan cache pengguna tidak diterapkan. Ternyata itu adalah bug sinkronisasi sumber data yang terpisah (panel admin menulis ke satu tabel, API gateway membaca dari tabel lain). Memperbaiki hal itu hanya menyelesaikan separuh masalah. Bahkan dengan cache yang diaktifkan dan berfungsi dengan benar, semantic cache mencocokkan permintaan yang seharusnya tidak pernah cocok.

Data Produksi

Kami menarik data hit cache selama 24 jam dari ClickHouse. Angkanya buruk.

Model	Total Permintaan	Hit Cache	Permintaan Unik	Respons Unik	Tingkat Hit
DeepSeek V4 Flash	200	199	198	1	99,5%
glm-4.6-thinking	100	38	13	1	38%
gpt-5-nano	31	29	28	2	93,5%
gpt-oss-120b	18	17	17	1	94,4%
qwen3-vl-flash	17	16	16	1	94,1%

198 permintaan terjemahan unik, semuanya mengembalikan respons cache tunggal yang sama. Itu bukan cache. Itu adalah fungsi rusak yang mengembalikan konstanta.

Setiap model yang terdampak memiliki dua kesamaan: semua permintaan berasal dari satu pengguna, dan semuanya menggunakan template prompt sistem tetap dengan konten pengguna yang bervariasi. Untuk daftar model terkini yang tersedia di platform, direktori model TokenLab (diamati 07-07-2026) adalah sumber kebenaran karena jajaran model sering berubah.

Cara Mendeteksi Ini di Sistem Anda Sendiri

Anda tidak memerlukan log kami untuk mengetahui apakah Anda memiliki masalah yang sama. Sinyal tercepat adalah keragaman respons per model. Jika sebuah model memiliki tingkat hit cache yang tinggi tetapi hampir tidak ada respons unik, Anda menyajikan satu jawaban untuk banyak pertanyaan yang berbeda.

Berikut adalah kueri gaya ClickHouse yang kami gunakan, yang telah digeneralisasi:

SELECT
  model,
  count() AS total_hits,
  uniqExact(substring(response_body, 1, 200)) AS unique_responses,
  round(uniqExact(substring(response_body, 1, 200)) / count(), 3) AS diversity_ratio
FROM request_logs
WHERE cache_hit = true
GROUP BY model
ORDER BY total_hits DESC;

Cache yang sehat memiliki diversity_ratio mendekati 1,0, yang berarti sebagian besar hit mengembalikan respons yang berbeda untuk input yang berbeda. Rasio mendekati 0 berarti banyak permintaan runtuh menjadi segelintir jawaban cache. Apa pun di bawah 0,5 pada model dengan variasi input nyata layak untuk diselidiki.

Jika Anda tidak mencatat badan respons, proksi yang lebih murah juga berfungsi: bandingkan jumlah badan permintaan unik dengan jumlah respons unik yang disajikan dari cache. Ketika 198 permintaan unik dipetakan ke 1 respons, cache tidak mencocokkan makna, melainkan mencocokkan boilerplate.

Indikasi kedua adalah keluhan pengguna yang mengelompok pada beban kerja terstruktur. Plugin terjemahan, peringkas, pengisi formulir, dan alat JSON-in/JSON-out adalah tersangka utama karena mereka membungkus konten variabel dalam template tetap.

Mengapa Embedding Gagal pada Input Terstruktur

Plugin terjemahan mengirimkan permintaan seperti ini:

System: "Bertindaklah sebagai API terjemahan. Keluarkan hanya satu objek JSON mentah.
         Input: {"targetLanguage":"<lang>","title":"...","segments":[...]}"

User:   {"targetLanguage":"zh","title":"Halaman Produk",
         "description":"Terjemahkan deskripsi produk",
         "tone":"formal",
         "segments":[{"text":"konten bervariasi yang sebenarnya di sini"}]}

Prompt sistem identik di semua permintaan. Pesan pengguna adalah objek JSON di mana targetLanguage, title, description, dan tone bersifat tetap. Hanya segments[].text yang berubah.

Ketika semantic cache kami mengekstrak teks untuk embedding, ia menggabungkan prompt sistem dan pesan pengguna. Template tetap menyumbang sekitar 80% dari teks. Model embedding (all-mpnet-base-v2, 768 dimensi) mengompresi ini menjadi vektor di mana struktur template mendominasi. Konten terjemahan yang sebenarnya hampir tidak mengubah hasil.

Hasilnya: kemiripan kosinus antara "terjemahkan 'Hello world'" dan "terjemahkan 'Laporan keuangan kuartalan menunjukkan peningkatan pendapatan sebesar 15%'" melebihi 0,95. Ambang batas kami adalah 0,95. Setiap permintaan terjemahan cocok dengan entri cache pertama.

Menggali log, kami menemukan tiga cara hal ini rusak:

Plugin terjemahan adalah pelanggar terburuk. Kunci dan nilai JSON yang tetap menenggelamkan segmen terjemahan yang sebenarnya. DeepSeek V4 Flash dan gpt-5-nano keduanya terkena masalah ini.

Asisten peringkasan konteks memiliki masalah serupa dengan variasi berbeda. Prompt sistemnya sangat panjang sehingga konten pengguna, mulai dari 5KB hingga 47KB, hampir tidak terdeteksi dalam embedding. Begitulah cara glm-4.6-thinking akhirnya memberikan ringkasan yang sama untuk setiap percakapan.

Pola ketiga lebih halus. Untuk gpt-oss-120b dan qwen3-vl-flash, 500 karakter pertama dari setiap permintaan identik byte-demi-byte. Konten yang bervariasi muncul setelahnya, tetapi embedding sudah didominasi oleh awalan yang sama.

Apa Kata Penelitian

Ini bukan masalah baru. Makalah terbaru telah mengukurnya.

Proyek vCache dari UC Berkeley menemukan bahwa distribusi kemiripan hit cache yang benar dan salah sangat tumpang tindih, yang berarti tidak ada ambang batas tetap yang secara bersih memisahkan kecocokan yang benar dari kecocokan palsu yang secara struktural mirip. Temuan itu persis dengan apa yang kami lihat dalam produksi: positif palsu plugin terjemahan mengelompok di atas 0,95, tepat di dalam rentang di mana kecocokan parafrasa yang sah juga berada.

Pekerjaan terbaru lainnya tentang keandalan semantic caching mencapai kesimpulan serupa: kemiripan embedding mentah adalah sinyal yang diperlukan tetapi tidak cukup untuk kebenaran cache, dan sistem produksi apa pun yang hanya mengandalkan hal itu harus mengharapkan tingkat positif palsu yang signifikan pada lalu lintas terstruktur yang padat template.

Perbaikan Dua Lapisan

Lapisan 1 adalah ekstraksi konten. Sebelum embedding, hapus prompt sistem tetap dan perancah template, dan sematkan (embed) hanya payload variabel: konten segments[].text yang sebenarnya, bukan kunci JSON di sekitarnya dan boilerplate. Ini saja secara dramatis meningkatkan rasio sinyal-terhadap-derau dalam vektor embedding.

Lapisan 2 adalah verifikasi sidik jari. Bahkan dengan ekstraksi yang lebih baik, konten yang hampir duplikat masih dapat menghasilkan skor kemiripan yang tinggi. Sebelum menyajikan hit cache, hitung hash cepat (kami menggunakan FNV-1a) atas konten yang diekstraksi dari permintaan masuk dan entri cache. Jika hash cocok persis, sajikan cache. Jika tidak, lakukan fallback ke penyelesaian baru atau, untuk lalu lintas bernilai lebih tinggi, arahkan ke panggilan verifikasi murah yang menilai makna, bukan byte.

Kesalahannya adalah melewatkan verifikasi sepenuhnya dan memercayai kemiripan kosinus mentah. Setiap pendekatan dalam tabel mengalahkan itu. Mulailah dengan yang termurah yang sesuai dengan jenis kueri Anda, dan hanya naik ke tingkat berikutnya saat Anda mengukur kehilangan parafrasa yang nyata.

Bersama-sama, kedua lapisan ini menurunkan tingkat positif palsu kami dari sekitar 95% menjadi di bawah 5% pada lalu lintas yang terdampak.

Kapan Semantic Caching Menjadi Alat yang Salah

Caching bukanlah rekayasa gratis, dan beberapa beban kerja tidak layak untuk di-cache sama sekali.

• Lalu lintas kardinalitas tinggi, pengulangan rendah. Jika hampir setiap permintaan unik, misalnya pembuatan kreatif satu kali, tingkat hit terlalu rendah untuk membenarkan overhead embedding. Anda membayar untuk menyematkan semuanya dan jarang mendapatkan keuntungan.
• Output yang harus segar. Apa pun yang sensitif terhadap waktu, data langsung, hasil yang dipersonalisasi, apa pun dengan "hari ini" di dalamnya, dapat mengembalikan jawaban basi dari cache bahkan ketika kecocokannya secara teknis benar. Jawaban itu benar satu jam yang lalu dan salah sekarang.
• Domain kebenaran ketat. Untuk jawaban medis, hukum, atau keuangan, satu positif palsu bisa lebih buruk daripada biaya yang dihematnya. Jika Anda melakukan cache di sini, lapisan verifikasi bersifat wajib, bukan opsional, dan pemeriksaan tingkat LLM mungkin satu-satunya yang dapat diterima.
• Prompt kecil di mana panggilan model sudah murah. Embedding, pencarian kemiripan, dan verifikasi memiliki biayanya sendiri. Jika penyelesaian dasarnya adalah beberapa ratus token pada model murah, caching bisa memakan biaya lebih banyak daripada yang dihemat.

Caching bersinar pada penyelesaian yang repetitif, padat template, dan mahal, tepatnya beban kerja di mana positif palsu juga paling mudah diperkenalkan. Ketegangan itulah mengapa lapisan verifikasi penting. Jika tujuan Anda terutama pengendalian biaya, ada baiknya juga memasangkan caching dengan perutean model yang lebih murah. Perbandingan harga dan panduan model AI terbaik untuk coding membahas dari mana penghematan per-token sebenarnya berasal, dan direktori model TokenLab (diamati 07-07-2026) menunjukkan opsi saat ini, termasuk pilihan perutean berbiaya rendah seperti DeepSeek V4 Flash dan Gemini 3.5 Flash, jika Anda menimbang model mana yang akan digunakan untuk merutekan lalu lintas cache versus non-cache. Verifikasi harga saat ini di direktori yang ditautkan sebelum berkomitmen pada rencana perutean.

Mengapa Tidak Menaikkan Ambang Batas Saja?

Ambang batas kami sudah 0,95. Menaikkannya tidak membantu. Masalahnya adalah input yang secara struktural mirip menghasilkan skor kemiripan di atas 0,95 tidak peduli apa isi konten yang sebenarnya.

Data vCache mendukung ini: distribusi kemiripan hit yang benar dan salah sangat tumpang tindih sehingga tidak ada batas tunggal yang memisahkannya. Dorong ambang batas ke 0,99 dan Anda akan mematikan hit cache yang sah untuk parafrasa asli, sementara permintaan yang identik secara struktural, seperti payload JSON terjemahan kami, akan tetap mengelompok di atas 0,99 terlepas dari kontennya. Ambang batas bukanlah tuasnya. Representasi inputlah yang menjadi tuasnya. Itulah mengapa Lapisan 1 (ekstraksi konten) dan Lapisan 2 (verifikasi sidik jari) bekerja di mana kenaikan ambang batas tidak: mereka mengubah apa yang dibandingkan, bukan seberapa ketat perbandingannya.

Jika Anda membangun atau memelihara semantic cache, perlakukan ambang batas sebagai filter kasar, bukan jaminan kebenaran. Pasangkan dengan ekstraksi konten sehingga embedding benar-benar mewakili bagian variabel dari permintaan, lalu tambahkan langkah verifikasi murah sehingga kecocokan embedding yang hampir meleset tidak akan pernah secara diam-diam menjadi jawaban yang salah dalam produksi.

Mulailah dengan direktori model TokenLab untuk membandingkan harga dan tolok ukur saat ini di seluruh model frontier, coding, dan perutean berbiaya rendah sebelum Anda memasang lapisan verifikasi cache Anda. Model apa pun yang berada di belakang titik akhir penyelesaian Anda, pendekatan ekstraksi-plus-sidik jari adalah apa yang sebenarnya memperbaiki positif palsu.

FAQ

Apakah menaikkan ambang batas kemiripan memperbaiki positif palsu semantic cache? Tidak. Penelitian dari vCache dan studi terkait menunjukkan distribusi hit yang benar dan salah tumpang tindih di seluruh rentang ambang batas, jadi mendorong batas lebih tinggi memblokir kecocokan yang sah tanpa secara andal memfilter permintaan yang secara struktural mirip tetapi berbeda secara semantik.

Apa cara termurah untuk memverifikasi hit semantic cache? Hash sidik jari (FNV-1a atau serupa) atas konten yang diekstraksi dan bermakna menambah latensi di bawah satu milidetik dan gratis untuk dihitung. Ini tidak akan menangkap parafrasa, tetapi menghilangkan positif palsu yang tepat seperti yang dijelaskan di sini, yang merupakan tempat sebagian besar kerusakan pada beban kerja terstruktur berasal.

Apakah masalah ini bergantung pada model mana yang menyajikan penyelesaian? Tidak, masalah positif palsu ada pada lapisan embedding dan pencocokan, bukan model penyelesaian. Model apa pun di belakang semantic cache, baik itu DeepSeek V4 Flash, glm-4.6-thinking, atau sesuatu yang lebih baru, akan terpengaruh dengan cara yang sama jika cache menyematkan teks template tetap bersama konten variabel. Periksa direktori model TokenLab (diamati 07-07-2026) untuk ketersediaan model saat ini saat memutuskan model mana yang akan dirutekan melalui pipeline cache.