deniz.in

Piyasalar

Hava durumu

Hava durumu yükleniyor

· kaynak dev.to (home feed)

Semantik önbellek tekrar testi: üç isabetten biri farklı bir sorunun cevabını verdi

DevOps Daily'in 288 operasyon sorusunu tekrar oynattığı deney, semantik önbelleklerin isabetlerin yaklaşık üçte birinde neredeyse aynı görünen bir sorunun cevabını verdiğini ve hiçbir benzerlik eşiğinin birbirine benzeyen soruları güvenilir şekilde ayıramadığını ortaya koydu.

Semantik önbellek tekrar testi: üç isabetten biri farklı bir sorunun cevabını verdi

Deneyin ölçtüğü şey

DevOps Daily, dev.io'da bir yazıda anlatılan ve semantik önbelleklemenin belirli bir zayıflığını zorlamayı hedefleyen bir tekrar (replay) testi gerçekleştirdi: neredeyse aynı okunan ama farklı cevaplar gerektiren sorular. Ekip 24这样的 çift oluşturdu — nginx'i yeniden başlatmak ile yeniden yüklemek, staging şifresi ile production şifresini değiştirmek, bellek limiti ile bellek talebini (request) artırmak — ve her tarafın altışar farklı ifade biçimini yazdı; toplamda 288 soru. Her soru yapısı gereği etiketlendiğinden, yanlış bir önbellek isabeti bir yargı modelinin görüşü değil, gerçekti.

Bge-m3 embedding modeli ve 0.80 kosinüs benzerliği eşiğindeki sonuçlar: önbellek soruların yüzde 32'sini hafızasından yanıtladı; ortalama bir koşuda 62 doğru, 30 yanlış isabet kaydedildi. Ortalama yanıt süresi 8.7 saniyeden 6.6 saniyeye düştü. Kabaca üç isabetten biri, farklı bir sorunun cevabını döndürdü.

Yazıdaki tipik başarısızlık örneği Git ile ilgili. Bir kullanıcı main'e zaten push edilmiş bir commit'i nasıl geri alacağını sordu. Önbellek, bunu push edilmemiş bir commit'i geri alma konusunda saklanmış bir soruyla eşleştirdi ve git reset --soft HEAD~1 komutunu servis etti. Paylaşılan geçmişe girmiş bir commit için doğru komut git revert; reset yapıp push etmek, başkalarının pull ettiği geçmişin üzerine force-push yapmak demektir.

Eşiği yükseltmek neden çözmüyor

Yazıya göre eşiği daraltmak işleri iyiye değil kötüye götürdü. 0.88 ile 0.92 arasında, kalan az sayıdaki isabet çoğu zaman doğru olmaktan çok yanlıştı. Altı embedding modeli ve 0.01 adımlarla 0.50'den 0.99'a uzanan eşikler genelinde, herhangi bir modelin elde ettiği en iyi sıfır-hata yapılandırması yüzde 0.7'lik bir isabet oranıydı. Dört modelde, hiçbir zaman yanlış cevap servis etmeyen eşikler hiçbir şey servis etmeyen eşiklerdi ve bir model 0.99'da bile yanlış cevap üretti.

Sorunun kaynağı dağılımların çakışması. Bge-m3 ile cevapları aynı olan parafraz çiftlerinin medyan benzerliği 0.723 iken, özellikle birbirine benzeyen şekilde tasarlanmış yakın-ıska çiftleri 0.646 medyanındaydı — ama yakın-ıska dağılımı 0.932'ye kadar uzanıyordu. Yakın-ıska çiftlerinin yaklaşık yüzde 23'ü, medyan parafraz çiftinden daha yüksek puan aldı. Eşik, iki dağılımın içinden geçen tek bir çizgidir ve onları ayıran hiçbir çizgi yoktur. Yazı bunu embedding modellerinin eğitim şekline bağlıyor: modeller aynı konudaki soruları birbirine yakın yerleştirir ve yakın-ıska çiftleri tam olarak aynı konu, yalnızca bir kelime farklıdır.

Üstelik sayılar modeller arasında aktarılamıyor. 0.80'de e5-large-v2 soruların yüzde 88'ini önbellekten yanıtladı ve bu isabetlerin yüzde 65'i yanlıştı.

Bariz çözüm, kazandırdığından fazlaya mal oluyor

DevOps Daily, çoğu ekibin ilk deneyeceği çözümü de test etti: her isabeti servis etmeden önce doğrulayan küçük bir model. Doğruluk açısından işe yaradı; her eşikte yanlış cevapları koşu başına birin altına indirdi. Ama önbelleği hiç önbellek olmaması kadar hızsız bıraktı ve test edilen her eşikte daha pahalıydı — böylece önbelleğin varoluş amacını ortadan kaldırdı.

Ölçülen tasarruflar zaten modesti. Yayınlanan fiyatlarla gpt-oss-120b'de maliyet, önbellek olmadan 1.000 soru başına 0.25 dolar, 0.80'de önbellekle 0.18 dolardı. Ortalama gecikme iyileşti; en yavaş yüzde 5'lik yanıtlar neredeyse hiç kımıldamadı.

Yazarların semantik önbelleğin muhtemelen güvenli olduğu tek yerin neredeyse birebir tekrarlar olduğunu düşünüyor; bunlar çoğunlukla orijinallerine karşı, herhangi bir yakın-ıska çiftinden daha yüksek puan aldı. Bu tekrarları önbellekten geçirerek test etmediklerini belirtiyorlar. Benchmark kodu GitHub'da The-DevOps-Daily/semantic-cache-wrong-answers olarak mevcut.

Neden önemli

Yazarlar bunun bir üretim hata oranı tahmini değil, bir stres testi olduğunu açıkça söylüyor: her sorunun yakın-ıska ortağı bilinçli olarak akışın içine konmuştu ve birebir tekrar yoktu. Gerik trafikte kaç yakın-ıska olduğunu ancak kayıtlardan (log) söylemek mümkün. Ama hiçbir eşiğin, altı modelden hiçbirinde, birbirine benzeyen soruları temiz şekilde ayıramaması, kurulumun bir eseri değil, embedding benzerliğinin yapısal bir özelliği. Operasyondaki yapay zekâ asistanları için — yakın-ıska cevapların çoğu zaman tam da işleri bozan şekilde farklılaştığı yerlerde: reset mi revert mi, FLUSHDB mi FLUSHALL mı, cordon mı drain mi — komşunun cevabını sessizce döndüren bir semantik önbellek, önbellek olmamasından daha kötü. Biri çalıştıran ekipler, isabet oranı panosuna güvenmeden önce kendi soru çiftleri üzerinde yanlış isabet oranlarını ölçmeli.

  • #semantic-cache
  • #ai
  • #llm
  • #embeddings
  • #reliability

İlgili yazılar