Semantic Cache'iniz Neden Yanlış Cevaplar Döndürüyor?

Bir kullanıcı, çeviri eklentimizin girdi ne olursa olsun her istek için aynı önbelleğe alınmış sonucu döndürdüğünü bildirdi. Araştırdığımızda daha kötü bir şey bulduk: Platformumuzdaki tüm anlamsal önbellek (semantic cache) isabetlerinin %95'i hatalı pozitiflerden (false positive) oluşuyordu. 199 farklı çeviri isteği, 198 benzersiz istek gövdesi ve hepsine sunulan tek bir önbelleğe alınmış yanıt.

Uzun ömürlü aracı (agent) durumu ve üretim ortamındaki istek yönetimiyle ilgileniyorsanız, bu yazı Yapay Zeka Aracınız Neden Hafızasını Kaybedip Duruyor, tek anahtarlı sohbet botu rehberi ve Yapay Zeka API hız sınırlama rehberi ile birlikte okunabilir.

Önemli Çıkarımlar

• Platform genelindeki anlamsal önbellek isabetlerinin %95'i hatalı pozitiflerden oluşuyordu; 198 benzersiz isteğin tamamına aynı önbelleğe alınmış yanıt sunuluyordu.
• Temel neden yapılandırılmış girdidir. Sabit şablon metni, embedding vektörüne hakimdir; bu nedenle değişen içerik kosinüs benzerliğini neredeyse hiç etkilemez.
• Benzerlik eşiğini yükseltmek bu sorunu çözmez, çünkü doğru ve yanlış isabet dağılımları örtüşmektedir. Anlamsal önbellek güvenilirliği üzerine yapılan güncel araştırmalar da aynı modeli doğrulamaktadır.
• Çözüm iki katmanlıdır: embedding öncesinde anlamlı içeriği ayıklayın, ardından her isabeti hızlı bir FNV-1a parmak izi hashi ile doğrulayın. Bu, hatalı pozitifleri yaklaşık %95'ten %5'in altına düşürdü.
• Model seçimi maruziyeti etkiler. Uzun sistem istemleri (system prompts) ve JSON ile sarılmış girdiler, tamamlamayı hangi modelin sunduğuna bakılmaksızın sorunu daha da kötüleştirir; önbelleğe alınmış trafiği hangi modeller üzerinden yönlendireceğinize karar veriyorsanız, güncel model seçenekleri için TokenLab'in model dizinine (2026-07-07 itibarıyla gözlemlenmiştir) göz atın.

Hata Raporu

Rapor basitti: "Anlamsal önbelleği devre dışı bıraktım ama her çeviri aynı sonucu döndürüyor."

Üç istek kimliği, üç farklı çeviri segmenti, aynı önbelleğe alınmış yanıtlar. İstek gövdeleri 1.564 ile 8.676 bayt arasında değişiyordu. Önbelleğe alınmış yanıt kimliği hepsinde aynıydı: chatcmpl-DG6J03nhdvcF7Ek0C8rJkjh7lN9pF.

İlk şüphe: kullanıcının önbellek ayarlarının uygulanmadığı yönündeydi. Bunun ayrı bir veri kaynağı senkronizasyon hatası olduğu ortaya çıktı (yönetim paneli bir tabloya yazıyor, API ağ geçidi diğerinden okuyordu). Bunu düzeltmek sorunun sadece yarısını çözdü. Önbellek etkin ve düzgün çalışıyor olsa bile, anlamsal önbellek asla eşleşmemesi gereken istekleri eşleştiriyordu.

Üretim Verileri

ClickHouse'dan 24 saatlik önbellek isabet verilerini çektik. Rakamlar kötüydü.

Model	Toplam İstek	Önbellek İsabeti	Benzersiz İstek	Benzersiz Yanıt	İsabet Oranı
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 benzersiz çeviri isteği ve hepsi aynı önbelleğe alınmış yanıtı döndürüyor. Bu bir önbellek değil. Bu, sabit bir değer döndüren bozuk bir fonksiyondur.

Etkilenen her model iki ortak özelliğe sahipti: tüm istekler tek bir kullanıcıdan geliyordu ve hepsi, değişen kullanıcı içeriğine sahip sabit bir sistem istemi şablonu kullanıyordu. Platformda mevcut olan modellerin güncel listesi için, kadrolar sık sık değiştiğinden TokenLab'in model dizini (2026-07-07 itibarıyla gözlemlenmiştir) gerçek kaynak kabul edilmelidir.

Kendi Sisteminizde Bunu Nasıl Tespit Edersiniz?

Aynı sorunu yaşayıp yaşamadığınızı öğrenmek için günlüklerimize ihtiyacınız yok. En hızlı sinyal, model başına yanıt çeşitliliğidir. Bir model yüksek önbellek isabet oranına sahipse ancak neredeyse hiç benzersiz yanıtı yoksa, birçok farklı soruya tek bir cevap sunuyorsunuz demektir.

İşte kullandığımız, genelleştirilmiş ClickHouse tarzı sorgu:

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;

Sağlıklı bir önbelleğin diversity_ratio değeri 1.0'a yakındır; bu, çoğu isabetin farklı girdiler için farklı yanıtlar döndürdüğü anlamına gelir. 0'a yakın bir oran, birçok isteğin birkaç önbelleğe alınmış cevaba çöktüğü anlamına gelir. Gerçek girdi çeşitliliğine sahip bir modelde 0,5'in altındaki herhangi bir değer araştırmaya değerdir.

Yanıt gövdelerini günlüğe kaydetmiyorsanız, daha ucuz bir yöntem de işe yarar: benzersiz istek gövdelerinin sayısını, önbellekten sunulan benzersiz yanıtların sayısıyla karşılaştırın. 198 benzersiz istek 1 yanıta eşlendiğinde, önbellek anlamı eşleştirmiyor, şablonu (boilerplate) eşleştiriyor demektir.

İkinci bir ipucu, yapılandırılmış iş yüklerinde yoğunlaşan kullanıcı şikayetleridir. Çeviri eklentileri, özetleyiciler, form doldurucular ve JSON-girdi/JSON-çıktı araçları, değişken içeriği sabit bir şablon içine sardıkları için genellikle şüphelilerdir.

Embedding'ler Yapılandırılmış Girdide Neden Başarısız Olur?

Çeviri eklentisi şu şekilde istekler gönderir:

Sistem: "Bir çeviri API'si gibi davran. Sadece tek bir ham JSON nesnesi çıktı ver.
         Girdi: {"targetLanguage":"<lang>","title":"...","segments":[...]}"

Kullanıcı: {"targetLanguage":"zh","title":"Ürün Sayfası",
         "description":"Ürün açıklamalarını çevir",
         "tone":"resmi",
         "segments":[{"text":"burada gerçek değişen içerik var"}]}

Sistem istemi tüm isteklerde aynıdır. Kullanıcı mesajı; targetLanguage, title, description ve tone alanlarının sabit olduğu bir JSON nesnesidir. Sadece segments[].text değişir.

Anlamsal önbelleğimiz embedding için metni çıkardığında, sistem istemini ve kullanıcı mesajını birleştirir. Sabit şablon metnin yaklaşık %80'ini oluşturur. Embedding modeli (all-mpnet-base-v2, 768 boyut), bunu şablon yapısının baskın olduğu bir vektöre sıkıştırır. Gerçek çeviri içeriği sonucu neredeyse hiç değiştirmez.

Sonuç: "'Hello world' çevir" ile "'The quarterly financial report shows a 15% increase in revenue' çevir" arasındaki kosinüs benzerliği 0,95'i aşar. Bizim eşiğimiz 0,95'tir. Her çeviri isteği ilk önbelleğe alınmış girişle eşleşir.

Günlükleri incelediğimizde, bunun üç şekilde bozulduğunu gördük:

Çeviri eklentisi en kötü suçludur. Sabit JSON anahtarları ve değerleri, gerçek çeviri segmentlerini bastırır. DeepSeek V4 Flash ve gpt-5-nano'nun ikisi de buna takılır.

Bir bağlam özetleme asistanı, aynı sorunun farklı bir türünü yaşıyordu. Sistem istemi o kadar uzundu ki, 5KB ile 47KB arasında değişen kullanıcı içeriği embedding'de neredeyse hiç fark edilmiyordu. glm-4.6-thinking'in her konuşma için aynı özeti döndürmesinin nedeni buydu.

Üçüncü model daha incelikliydi. gpt-oss-120b ve qwen3-vl-flash için, her isteğin ilk 500 karakteri bayt bazında aynıydı. Değişen içerik sonradan geliyordu ancak embedding zaten paylaşılan önek (prefix) tarafından domine edilmişti.

Araştırmalar Ne Diyor?

Bu yeni bir sorun değil. Yakın tarihli makaleler bunu nicelleştirdi.

UC Berkeley'in vCache projesi, doğru ve yanlış önbellek isabeti benzerlik dağılımlarının büyük ölçüde örtüştüğünü buldu; bu da hiçbir sabit eşiğin gerçek bir eşleşmeyi yapısal olarak benzer bir hatalı eşleşmeden temiz bir şekilde ayıramadığı anlamına gelir. Bu bulgu, üretim ortamında gördüklerimizle tam olarak örtüşüyor: çeviri eklentisinin hatalı pozitifleri 0,95'in üzerinde kümelenmişti, yani meşru eş anlamlı eşleşmelerin de bulunduğu aralığın tam içindeydi.

Anlamsal önbellek güvenilirliği üzerine yapılan diğer çalışmalar da benzer sonuçlara ulaşıyor: ham embedding benzerliği, önbellek doğruluğu için gerekli ancak yeterli olmayan bir sinyaldir ve buna tek başına güvenen herhangi bir üretim sistemi, yapılandırılmış, şablon ağırlıklı trafikte anlamlı bir hatalı pozitif oranı beklemelidir.

İki Katmanlı Çözüm

1. Katman içerik ayıklamadır. Embedding öncesinde, sabit sistem istemini ve şablon iskeletini çıkarın ve yalnızca değişken yükü (payload) embedding'e dahil edin: çevredeki JSON anahtarları ve şablon metinleri değil, yalnızca gerçek segments[].text içeriği. Bu tek başına, embedding vektöründeki sinyal-gürültü oranını önemli ölçüde artırır.

2. Katman parmak izi doğrulamadır. Daha iyi ayıklamaya rağmen, birbirine yakın içerikler hala yüksek benzerlik puanları üretebilir. Bir önbellek isabetini sunmadan önce, hem gelen isteğin hem de önbelleğe alınmış girişin ayıklanmış içeriği üzerinde hızlı bir hash (biz FNV-1a kullandık) hesaplayın. Hash'ler tam olarak eşleşirse önbelleği sunun. Eşleşmezse, ya yeni bir tamamlamaya geçin ya da daha yüksek değerli trafik için anlamı puanlayan ucuz bir doğrulama çağrısına yönlendirin.

Hata, doğrulamayı tamamen atlayıp ham kosinüs benzerliğine güvenmektir. Tablodaki her yaklaşım bundan daha iyidir. Sorgu türünüze uyan en ucuz olanla başlayın ve yalnızca gerçek eş anlamlı kaçırmalarını ölçtüğünüzde bir üst seviyeye geçin.

Bu iki katman birlikte, etkilenen trafikte hatalı pozitif oranımızı yaklaşık %95'ten %5'in altına düşürdü.

Anlamsal Önbellekleme Ne Zaman Yanlış Araçtır?

Önbellekleme ücretsiz bir mühendislik değildir ve bazı iş yükleri önbelleğe almaya değmez.

• Yüksek kardinaliteli, düşük tekrarlı trafik. Eğer neredeyse her istek benzersizse (örneğin tek seferlik yaratıcı üretimler), isabet oranı embedding maliyetini haklı çıkarmak için çok düşüktür. Her şeyi embedding'e almak için ödeme yaparsınız ve nadiren kazanç sağlarsınız.
• Taze olması gereken çıktılar. Zamana duyarlı, canlı veriler, kişiselleştirilmiş sonuçlar veya içinde "bugün" geçen herhangi bir şey, eşleşme teknik olarak doğru olsa bile önbellekten bayat cevaplar döndürebilir. Cevap bir saat önce doğruydu, şimdi yanlış.
• Katı doğruluk alanları. Tıbbi, hukuki veya finansal cevaplar için tek bir hatalı pozitif, tasarruf edilen maliyetten daha kötü olabilir. Burada önbelleğe alıyorsanız, doğrulama katmanı isteğe bağlı değil zorunludur ve LLM düzeyinde bir kontrol kabul edilebilir tek yöntem olabilir.
• Model çağrısının zaten ucuz olduğu küçük istemler. Embedding, benzerlik araması ve doğrulamanın kendi maliyeti vardır. Eğer temel tamamlama ucuz bir modelde birkaç yüz token ise, önbellekleme tasarruf ettiğinden daha pahalıya mal olabilir.

Önbellekleme; tekrarlayan, şablon ağırlıklı, pahalı tamamlamalarda parlar; yani hatalı pozitifin de en kolay tanıtılabileceği iş yüklerinde. Bu gerilim, doğrulama katmanının neden önemli olduğunun sebebidir. Hedefiniz esas olarak maliyet kontrolü ise, önbelleğe almayı daha ucuz model yönlendirmesiyle eşleştirmek de mantıklıdır. Fiyatlandırma karşılaştırması ve kodlama için en iyi yapay zeka modelleri rehberi, token başına tasarrufun nereden geldiğini ele alır ve TokenLab'in model dizini (2026-07-07 itibarıyla gözlemlenmiştir), önbelleğe alınmış ve alınmamış trafiği hangi model üzerinden yönlendireceğinizi tartıyorsanız DeepSeek V4 Flash ve Gemini 3.5 Flash gibi düşük maliyetli yönlendirme seçenekleri dahil güncel seçenekleri gösterir. Bir yönlendirme planına karar vermeden önce bağlantılı dizindeki güncel fiyatları doğrulayın.

Neden Sadece Eşiği Yükseltmiyoruz?

Eşiğimiz zaten 0,95. Yükseltmek yardımcı olmuyor. Sorun şu ki, yapısal olarak benzer girdiler, gerçek içerik ne olursa olsun 0,95'in üzerinde benzerlik puanları üretir.

vCache'in verileri bunu destekliyor: doğru ve yanlış isabetlerin benzerlik dağılımları o kadar çok örtüşüyor ki, hiçbir tekil kesme noktası onları ayıramaz. Eşiği 0,99'a çekerseniz, gerçek eş anlamlılar için meşru önbellek isabetlerini öldürürsünüz; ancak çeviri JSON yüklerimiz gibi yapısal olarak aynı olan istekler, içerikten bağımsız olarak 0,99'un üzerinde kümelenmeye devam eder. Eşik bir kaldıraç değildir. Girdi temsilidir. 1. Katman (içerik ayıklama) ve 2. Katman (parmak izi doğrulama) eşik artışının işe yaramadığı yerde çalışır: karşılaştırmanın ne kadar katı olduğunu değil, neyin karşılaştırıldığını değiştirirler.

Bir anlamsal önbellek oluşturuyor veya bakımını yapıyorsanız, eşiği bir doğruluk garantisi değil, kaba bir filtre olarak görün. Embedding'in isteğin değişken kısmını gerçekten temsil etmesi için bunu içerik ayıklama ile eşleştirin, ardından yakın bir embedding eşleşmesinin üretimde sessizce yanlış bir cevaba dönüşmemesi için ucuz bir doğrulama adımı ekleyin.

Önbellek doğrulama katmanınızı bağlamadan önce, sınır, kodlama ve düşük maliyetli yönlendirme modelleri arasındaki güncel fiyatlandırmayı ve kıyaslamaları karşılaştırmak için TokenLab'in model dizini ile başlayın. Tamamlama uç noktanızın arkasında hangi model olursa olsun, hatalı pozitifleri gerçekten düzelten şey ayıklama artı parmak izi yaklaşımıdır.

SSS

Anlamsal benzerlik eşiğini yükseltmek anlamsal önbellek hatalı pozitiflerini düzeltir mi? Hayır. vCache ve ilgili çalışmalardan elde edilen araştırmalar, doğru ve yanlış isabet dağılımlarının eşik aralığında örtüştüğünü göstermektedir; bu nedenle kesme noktasını daha yükseğe çekmek, yapısal olarak benzer ancak anlamsal olarak farklı istekleri güvenilir bir şekilde filtrelemeden meşru eşleşmeleri engeller.

Anlamsal önbellek isabetini doğrulamanın en ucuz yolu nedir? Ayıklanmış, anlamlı içerik üzerinde bir parmak izi hashi (FNV-1a veya benzeri), bir milisaniyenin altında gecikme ekler ve hesaplanması ücretsizdir. Eş anlamlıları yakalamaz, ancak burada açıklananlar gibi tam hatalı pozitifleri ortadan kaldırır ki yapılandırılmış iş yüklerindeki hasarın çoğu buradan gelir.

Bu sorun tamamlamayı sunan modele bağlı mıdır? Hayır, hatalı pozitif sorunu tamamlayıcı modelde değil, embedding ve eşleştirme katmanındadır. Anlamsal önbelleğin arkasındaki herhangi bir model (DeepSeek V4 Flash, glm-4.6-thinking veya daha yenisi olsun), önbellek sabit şablon metnini değişken içerikle birlikte embedding'e alıyorsa aynı şekilde etkilenecektir. Önbelleğe alınmış bir boru hattı üzerinden hangi modelleri yönlendireceğinize karar verirken güncel model kullanılabilirliği için TokenLab'in model dizinine (2026-07-07 itibarıyla gözlemlenmiştir) göz atın.