Claude’daki son üç kalite düşüşü sorununun postmortem analizi

• Ağustostan eylül başına kadar görülen Claude yanıt kalitesi düşüşü, üç ayrı altyapı hatası nedeniyle yaşandı
• Sorunların başlıca nedenleri sırasıyla bağlam penceresi yönlendirme hatası, çıktı bozulması ve XLA:TPU approximate top-k derlenmeme hatasıydı
• Her bir hata, farklı donanım ve dağıtım yollarında birbirinin üzerine binerek ortaya çıktığı için teşhis daha da zorlaştı
• Tespit ve çözümün gecikmesinde doğrulama sürecindeki açıklar ve gizlilik politikaları kaynaklı erişim kısıtları etkili oldu
• Anthropic, değerlendirme ve izlemeyi güçlendirerek ve daha hızlı hata ayıklama araçları geliştirerek benzer olayları önlemeye çalışıyor

---

Genel bakış ve arka plan

• Ağustostan eylül başına kadar Claude yanıt kalitesinde aralıklı düşüşler bildirildi
• Başlangıçta bu durum kullanıcı geri bildirimlerindeki olağan dalgalanmalar olarak değerlendirildi, ancak bildirimler sürekli artınca inceleme başlatıldı
• Anthropic, sorunun talep ya da sunucu yükünden değil, yalnızca altyapı hatalarından kaynaklandığını açıkça belirtti
• Claude, milyonlarca kullanıcıya API’ler, Amazon Bedrock ve Google Vertex AI gibi çeşitli platformlar üzerinden sunuluyor; ayrıca AWS Trainium, NVIDIA GPU ve Google TPU gibi farklı donanımlarda eşdeğer sonuçları garanti etmek için sıkı doğrulama standartları uygulanıyor
• Bu postmortem, hataların nedenlerini, teşhis ve çözümde yaşanan gecikmelerin sebeplerini ve tekrarını önlemeye yönelik tedbirleri açıklıyor

Claude’un büyük ölçekte hizmet sunma yöntemi

• Claude hizmeti, farklı donanımlar (Trainium, GPU, TPU) üzerinden küresel dağıtımı sürdürüyor
• Her platformda aynı kaliteyi garanti etmek için uygulama eşdeğerliği standartları katı tutuluyor
• Altyapı değişikliklerinde, tüm platformlar ve yapılandırmalar için ayrıntılı bir doğrulama süreci gerekiyor

Başlıca sorunların zaman çizelgesi

• 5 Ağustos: İlk hata, Sonnet 4 isteklerinin yaklaşık %0,8’ini etkiledi
• 25 ve 26 Ağustos: İkinci ve üçüncü hata ayrı ayrı devreye alındı
• 29 Ağustos: Yük dengeleme değişikliği nedeniyle sorunlu trafik keskin biçimde arttı ve daha fazla kullanıcı etkilendi
• Her bir hatanın belirtileri üst üste bindiği için teşhis son derece zordu

Birbirinin üzerine binen üç hata ve çözüm süreci

1. Bağlam penceresi yönlendirme hatası

• 5 Ağustos’ta bazı Sonnet 4 istekleri, 1M token bağlam penceresi için ayrılmış sunuculara yanlış yönlendirildi
• Yük dengeleme değişikliğinden sonra en fazla Sonnet 4 isteklerinin %16’sı etkilendi; Amazon Bedrock ve Google Vertex AI’da da sınırlı etki görüldü
• Yönlendirme yöntemi "sticky" olduğu için bir kez yanlış sunucuya bağlanan istekler sonrasında da aynı sunucuya gitmeye devam etti
• Çözüm: Yönlendirme mantığı iyileştirildi; 4 Eylül’de Anthropic’in kendi platformuna yama uygulandı, Google Cloud’a 16 Eylül’e kadar dağıtıldı, Bedrock için ise kademeli dağıtım sürüyor

2. Çıktı bozulması (bug)

• 25 Ağustos’ta Claude API’nin TPU sunucularına hatalı bir yapılandırma uygulandı ve token üretimi sırasında hatalar oluştu
• İngilizce sorulara Tayca ya da Çince gibi alakasız karakterlerin karışması ve koda açık sözdizimi hatalarının eklenmesi gibi sorunlar görüldü
• Yalnızca Opus 4.1, Opus 4 ve Sonnet 4 etkilendi; üçüncü taraf platformlar etkilenmedi
• Çözüm: 2 Eylül’de ilgili değişiklik geri alındı ve anormal karakter çıktısını tespit eden testler dağıtım sürecine eklendi

3. Approximate top-k için XLA:TPU derlenmeme hatası

• 25 Ağustos’ta token seçimi yöntemi iyileştirilirken XLA:TPU derleyicisindeki potansiyel bir hata açığa çıktı
• Claude Haiku 3.5, bazı Sonnet 4 örnekleri ve Opus 3 etkilendi
• Üçüncü taraf platformlar etkilenmedi
• Çözüm: Haiku 3.5 için 4 Eylül’de, Opus 3 için 12 Eylül’de geri alma yapıldı; Sonnet 4’te doğrudan yeniden üretilemese de önleyici tedbir olarak geri alındı
• Buna paralel olarak XLA:TPU ekibiyle birlikte derleyici hatası düzeltiliyor ve exact top-k yöntemine geçiliyor

XLA derleyici hatasının ayrıntılı analizi

• Claude, token üretim sürecinde her aday için olasılık hesaplama ve örnekleme yapıyor
• TPU’lar dağıtık ortamda çalıştığı için token olasılık hesaplarının senkronize edilmesi gerekiyor ve bu da karmaşıklık yaratıyor
• Aralık 2024’te, bf16-32 bit karma hassasiyet kullanımından kaynaklanan hata nedeniyle en yüksek olasılıklı token’ın atlanabildiği bir sorun bulundu ve buna geçici bir düzeltme dağıtıldı
• 26 Ağustos’ta, temel nedeni çözmek için örnekleme kodu yeniden düzenlenirken approximate top-k işleminde belirli durumlarda tamamen yanlış sonuç üreten daha derin bir hata ortaya çıktı
• Önceki geçici düzeltme bu sorunu maskeliyordu
• Ayrıca approximate top-k işlemindeki hata, üretim ortamına ve batch boyutuna bağlı olarak düzensiz biçimde farklı belirtiler gösteriyordu
• Approximate top-k yerine, son dönemde performans maliyeti belirgin biçimde azalan exact top-k yöntemine geçildi ve ana işlemler fp32 standardizasyonu ile iyileştirildi

Tespitte yaşanan gecikmenin nedenleri

• Düzenli otomatik değerlendirmeler ve önceden tanımlı grup dağıtımları gibi süreçler kullanılıyordu
• Bu olaylar, değerlendirme sürecindeki açıkları ortaya çıkardı. Örneğin, sorunlu durumları yeterince iyi yakalayamayan değerlendirme maddeleri ve iç gizlilik politikaları nedeniyle (mühendislerin belirli kullanıcı isteklerine erişememesi) hızlı analiz yapmak zorlaştı
• Belirtiler platforma ve sürüme göre farklılaştığından tek bir kök neden belirlemek güç oldu
• Çevrim içi raporlar hızla artsa da bunun standart bir yük dengeleme değişikliğiyle ilişkisi hemen fark edilemedi

Gelecekteki iyileştirmeler ve önlemler

• Yüksek duyarlılıklı değerlendirme maddeleri geliştirilecek; bozulmuş durumlarla sağlıklı uygulamaları daha net ayırt eden otomatik değerlendirmeler güçlendirilecek
• Değerlendirme ve izleme sistemleri gerçek üretim ortamının tamamına genişletilecek; örneğin bağlam penceresi yönlendirme hatası gibi üretim ortamı odaklı değerlendirmeler yapılacak
• Daha hızlı ve daha gelişmiş hata ayıklama araçları kurulacak; topluluk geri bildirimlerini gizliliği koruyarak hızlı analiz etmeye yönelik altyapı ve özel araçlar geliştirilecek
• Yalnızca iç değerlendirmeler değil, kullanıcı geri bildiriminin sürekli toplanmasının güvenilirliği de vurgulanıyor: öngörülmesi zor hatalar ve bug’lar için gerçek kullanıcı bildirimleri önemli bir sinyal görevi görüyor
• /bug komutunun ya da 'thumbs down' özelliğinin kullanılması ve model kalite değerlendirme yöntemleriyle ilgili bildirimlerin e-posta yoluyla iletilmesi aktif biçimde teşvik ediliyor

Ek açıklama

• XLA:TPU, XLA yüksek seviyeli optimizasyon dili kodunu TPU komutlarına dönüştüren bir derleyicidir
• Model boyutu büyük olduğu için tek bir çip yerine birden fazla çipe bölünerek yerleştirilir; sorting işlemleri gibi operasyonların da vektörleştirilmiş biçimde uygulanması gerekir
• Approximate top-k işlemi performansı artırmak için kullanılır, ancak en yüksek olasılıklı token’ı atlamak gibi ciddi sorunlar barındırabilir
• Şu anda exact top-k yöntemi kullanılmaktadır; bu nedenle top-p eşiğine yakın token’ların dahil edilme biçiminde küçük değişiklikler olabilir. Bazı durumlarda kullanıcıların top-p değerini ayarlaması gerekebilir

[GN⁺]

Hacker News görüşü

• Son dönemde dikkat çekici olan şeyin birim testlerinin yokluğu olduğunu fark ettim. XLA derleyici hatasına yönelik testler bile sadece çıktıyı yazdırma düzeyinde; gerçek bir test harness içinde çalıştırılıp kapsamı izlenen gerçek birim testlerinden oldukça uzak. Çözüm olarak da daha fazla Eval’e güvenilmesi öneriliyor gibi. Şu anda tüm LLM için birim testi yapmak gerçekçi olmayabilir, ancak şimdiye kadar ortaya çıkan hataların çoğu sistemin küçük ve deterministik parçalarındaydı. Örneğin yük dengeleme, top-k olasılık hesaplaması gibi şeyler diğer yazılımlardan farklı olmayan, mühendislikle kurulmuş parçalardır; dolayısıyla prensipte birim testine uygundurlar. Gerekirse en fazla enjekte edilebilir bir PRNG yeterlidir. Deterministik olmayan optimizasyon hataları elbette can sıkıcıdır, ama geçmişte klasik uygulama test paketleriyle derleyici ve veritabanı hataları da yakalandı. CI içinde çok sayıda testi tekrar tekrar çalıştırırsanız nadir olaylar da ortaya çıkabilir. Kendi yürüttüğüm bir projede tüm birim testlerini aynı süreçte paralel çalıştırıyorum ve bu yöntemle nadir görülen thread safety sorunlarını ya da veritabanı deadlock’larını da etkili biçimde bulabildim. Birkaç gün önce Java lansmanıyla ilgili bir başlıkta, Java’nın Python’dan daha “enterprise” görülmesinin nedenlerinden birinin kodun birim test odaklı yazılması olduğunu söylemiştim. Dependency injection gibi ihtiyaçlar yüzünden çok daha fazla soyutlama yapılıyor. Buna karşılık script dili kültüründe testler ya hiç olmuyor ya da çok yüzeysel kalıyor (ör. sadece type assertion). PyTorch öğrenirken de benzer bir izlenim edinmiştim; eğitimler giderek daha karmaşık şeylere geçiyor ama testler ya da kod yapısı neredeyse hiç konuşulmuyor. ML araştırmalarında amaç değerlendirme puanını artırmak olabilir, ama bu yaklaşım büyük ölçekli production dağıtımları için uygun değil. Belki de AI laboratuvarlarında SRE ya da HA yazılım mühendisi geçmişine sahip daha fazla kişiye ihtiyaç vardır diye düşünüyorum. Kişisel olarak production’da sadece Eval’i agresif biçimde çalıştırmanın hata önlemede en iyi yöntem olduğundan şüpheliyim
  • AI’ın Python’da benim istediğim tarzda birim testleri yazması için ayrıntılı prompt’lar ve örnekler vermek zorunda kaldığım oldu. Sadece type assertion kullandığını da sık sık gördüm. Benim istediğim şey değerlerin kendisine yönelik assertion’lar. AI her şeyi fazla mock etme eğiliminde; mocking faydalıdır ama birim testte ne kadar çok gerçek kod çağrılırsa kod etkileşimleri ve arayüz riskleri de o kadar kapsanabilir. Oysa AI’ın ürettiği Python birim testleri mocking’e fazla takılıyor ve çoğu zaman sadece kendi kendini doğrulayan (tautological) kodu kontrol edip bitiyor. Bu yüzden prompt’lara mocking konusunda dikkatli olunması yönünde uyarılar ve titiz test örnekleri özellikle ekliyorum. Bu arada Python’da da dependency injection gibi yapılandırılmış kod yazımı için çok iyi araçlar var
• Haberde, Anthropic’in AWS Bedrock altyapısını doğrudan etkileyebildiğinin yazması beni şaşırttı. Bu, AWS’nin ilk vaatleriyle de çelişiyor. Sanırım Google Vertex AI için de benzer durum geçerli olabilir, ama compliance açısından bunu henüz doğrulamadım.

Dahili gizlilik ve güvenlik politikaları gereği mühendislerin Claude kullanıcı etkileşimlerine erişiminin sınırlı olduğu ifadesine katılıyorum. Kullanıcının doğrudan geri bildirim göndermesinin hâlâ en faydalı yol olması ve Claude Code içinde /bug komutunun kullanılabilmesi de mantıklı. Bu komutla rapor edilirse mühendisler bağlamı görebilir, ama kullanıcı açısından bu sürecin çok net biçimde anlatılmasını isterim (ben Claude Code kullanıcısı değilim). Claude uygulamasındaki "thumbs down" düğmesinin kullanımına dair yönlendirme biraz endişe verici. Çoğu kullanıcı bu düğmeye basmanın mahremiyetten vazgeçmek kadar ciddi bir anlam taşıdığını düşünmez

• (Anthropic çalışanı, kişisel görüş olarak yazıyorum)

Anthropic’in AWS Bedrock altyapısını doğrudan yönettiği iddiası doğru değil. Şu anda bunu doğrudan AWS işletiyor. "thumbs down" düğmesindeki gizlilik uyarısı konusunda, ilgili modal’da "Bu geri bildirim gönderildiğinde mevcut konuşmanın tamamı Anthropic’e iletilir ve model iyileştirmesinde kullanılır" ifadesi yer alıyor. Bu uyarı metnini daha anlaşılır hâle getirmek için bir öneri olup olmadığını merak ediyorum

• "thumbs down" tıklanınca, "Bu geri bildirim gönderildiğinde konuşmanın tamamı Anthropic’e iletilir" mesajı gösteriliyor; bence uyarı epey açık
• Anthropic gibi bir laboratuvarın altyapı ayrıntılarını paylaşacak noktaya gelmesi, işlerin epey zorlaştığını düşündürüyor. Gerçekten de FMA (fused multiply-add) tarafındaki hassasiyet hatası oldukça talihsiz; sayısal sorunlar çoğu zaman çok kafa karıştırıcı olur ve hâlâ AI’ın çözemediği alanlardan biridir. Rakiplerin gerçek zamanlı olarak pazar payı aldığı aşırı baskılı bir ortamda insan müdahalesi kaçınılmaz oluyor ve kök neden analizi haftalar sürebiliyor
• “29 Ağustos’taki yük dengeleme değişikliği tesadüfen 1M context sunucularına daha fazla kısa context isteği göndermeye başladı ve 31 Ağustos’ta bir saat boyunca Sonnet 4 isteklerinin %16’sı etkilendi” deniyor; bu da 1M context sunucularının kısa context girdilerde aslında daha kötü performans verdiğini düşündürüyor. Belki bu sunucularda KV cache sıkıştırma, eviction, sparse attention gibi ayrı önlemler uygulanıyordur?
  • Bunun nedeni RoPE (rotary positional embedding) scaling. Popüler açık kaynak framework’lerin çoğu static YaRN uyguluyor; burada scaling factor giriş uzunluğundan bağımsız olarak sabit kalıyor ve bu da kısa metinlerde performansı etkileyebiliyor. rope_scaling ayarını sadece uzun context gerektiğinde eklemek ve factor’ü uygulamanın ortalama giriş uzunluğuna göre ayarlamak iyi olur. Örneğin yaklaşık 520 bin token civarı için factor 2.0 daha iyi olabilir Kaynak (Qwen3-Next-80B açıklama sayfası)
  • Bu postmortem raporunda asıl önemli nokta, üç sorundan ikisinde kesin kök nedenin bulunamamış olması. Bildiğim kadarıyla benim isteğim şu anda tamamen farklı üç ayrı kod yolundan herhangi birine gidebilir ve her birinde farklı stack ile tuning uygulanıyor. Bu optimizasyonlar model sürüm yükseltmesi olmadan da aniden değişebilir; dolayısıyla dün çalışan şey bugün bozulabilir. İnsanların bu tür postmortem’leri övmesini anlamıyorum; benim için bu daha da sinir bozucu
• Anthropic ekibine saygı duyarak söylüyorum, Claude status sayfasındaki kalite dahili olarak code red seviyesinde alarm vermeliydi. Temmuz’da 50, Ağustos’ta 40, Eylül’de 21 incident vardı. Geçmişte bunun yarısı kadar sayıda olay olduğunda bile herkesin uptime ve kaliteye odaklanması için sert yön değişiklikleri gördüm. Yine de Claude hâlâ harika bir ürün olduğu için ücretli kullanmaya devam ediyorum. API’yi deneyip hemen ardından Max üyeliği aldım. Bunun sayesinde üretkenliğim ciddi biçimde arttı. Ama son birkaç haftadaki tekrarlayan kalite düşüşleri yüzünden aboneliği sürdürüp sürdürmemeyi düşünmeye başladım. Sorunların dürüstçe paylaşılmasına teşekkür ederim ama müşteri tarafında ciddi bir memnuniyetsizlik var. Bence yük dengeleme gibi sorunlar hâlâ tam olarak ne tespit edildi ne de çözüldü. Özellikle 12:00 ET / 9:00 PT civarında Claude Code kalitesinin hissedilir biçimde düştüğünü fark ediyorum. Ekibin bu sorunları bulup çözmeye devam etmesini umuyorum. Evde yerel model çalıştırırken de çok karmaşık hatalarla uğraştığım için bunların kolay olmadığını biliyorum. status sayfası bağlantısı
  • Claude’un diğer şirketlerden daha iyi mi daha kötü mü olduğunu kesin söyleyemem, ama bir şey net: birçok şirketin status sayfasında bolca yalan var. Gerçekte sık sık arıza yaşanıyor ama status sayfasına yansımıyor. Hatta günümüzde bir şirket sorunları dürüstçe bildirince daha çok şaşırıyorum. Ben kişisel olarak Claude’da ciddi bir sorun yaşamadım ama belki şanslıydım. Benim açımdan Claude, kesintileri raporlama konusunda daha dürüst davranıyor gibi görünüyor. Tabii bu sadece tesadüf de olabilir
  • Daha da endişe verici olan, küçük olayların status page’den topluca dışarıda bırakılması. Tüm AI sağlayıcılarında benzer durum var. Gerçek zamanlı token gecikmesi, başarısız istekler, saniye başına token işleme hızı gibi istatistik grafiklerini yayınlasalar birçok kişi şok olurdu. OpenRouter verileri API uptime’ının hiç de iyi olmadığını gösteriyor. Claude Code da bazen aşırı yavaşlıyor; manuel durdurup yeniden denemek zorunda kalıyorum. Özellikle 16:00-18:00 Birleşik Krallık saatleri arasında çok yavaşlıyor (Avrupa, ABD doğu ve batı yakasının aynı anda yüklendiği saatler). Bugün Gemini AI Studio’da da model aşırı yük nedeniyle 503 hatası aldım ama status page’de hiçbir şey görünmüyordu. Claude ve benzerleri yoğun olmayan saatlerde daha ucuz tarifeler sunsa talebi dengeleyebilirler mi diye düşünüyorum. Ancak böyle bir tarife dışarıdan olumsuz algılanabilir. Ayrıca GB200 GPU’nun devreye alınması beklenenden çok daha yavaştı ve çok sayıda donanım/yazılım kusuru olduğu görülüyor. Sıvı soğutma sorunları da hafife alınacak gibi değildi (başarısız olursa felaket olur)
  • “Yine de Claude o kadar iyi ki para ödüyorum” ifadesi başlı başına önemli bir gösterge. Şu anda AI kalitesi, müşteriler için (ben dahil) hizmet güvenilirliğinden daha önemli. Elbette sağlayıcılar zamanla güvenilirliğe daha çok odaklanacaktır, ama neden bugün kalite yerine güvenilirliği önceliklendirsinler?
  • Son dönemdeki kalite düşüşü beni ciddi biçimde tedirgin etti. Neyse ki henüz production hizmetlerinde AI kullanmıyorum, ama geliştirme sürecinde modelin bir anda “aptallaşması” gerçekten etrafından dolaşması zor bir durum. Bu noktada OpenRouter’daki çeşitli sağlayıcıların gizlice context’i kısaltmak, quantization seviyesini düşürmek ya da expert sayısını azaltmak gibi küçük hesaplama tasarrufu hileleri yapıp yapmadığından şüpheleniyorum
  • Bu yüzden status sayfasında görünen incident sayısını minimumda tutma stratejisi uygulanıyor. Müşteri değerlendirmesi kısa vadede kötüleşebilir ama zamanla olumsuz etkinin izi silinir. Oysa düzenli bir status sayfası tutulursa sorunların “kanıtı” açıkça kalır. Uzun vadede kandırmak daha avantajlı olur. Gerçekte S3 de defalarca hata ve kesinti yaşadı ama bunları açıklamadı, kimse de bunun peşine düşmedi. İnsanlar çok şey söylüyor ama fiiliyatta saklayan taraf ödüllendiriliyor. Bütün startup growth hacker’ları bunu zaten biliyor
• Açıklamada, 25 Ağustos’ta Claude API TPU sunucularına yanlış bir yapılandırma dağıtıldığı ve bunun token üretimi sırasında hatalara yol açtığı söyleniyor. Kod hatalarına alışığım ama LLM’ler insanın tek tek yazdığı sistemler değil, büyük ölçüde otomatik eğitimle ortaya çıkıyor; böyle bir hatanın nasıl oluşabildiğini merak ediyorum. Örneğin model İngilizce bir sorgunun ortasında bir anda 'สวัสดี' yazarsa bunun yapısal olarak sisteme nasıl enjekte edilebildiğini anlamak istiyorum
  • LLM sonuçta insanlar tarafından yazılmış kodla çalıştırılır. Son aşamada model, tüm token’lar için (vocab yaklaşık 200 bin) bir olasılık dağılımı üretir. Ardından gerçek sonraki token’ın hangi yöntemle seçileceğine insan karar verir. Örneğin her zaman en yüksek olasılıklı token seçilebilir ya da yaratıcılığı artırmak için top-k içinden rastgele seçim yapılabilir. Bu top-k sampling işlemini verimli yapmak için çekirdekler XLA ile derlenir; görünen o ki bu çekirdekte bir hata oluşmuş ve zaman zaman top-k dışındaki token’ların seçilmesine yol açmış
  • LLM, bir sonraki token için olasılık dağılımı üretir ve gerçek çıktı kullanılan sampling yöntemine örnek göre değişir. Mesela “en yüksek olasılığa sahip 4 seçenekten rastgele seç” denirken operatör (eşitsizlik) yanlış yazılırsa metindeki gibi bir sonuç çıkabilir
  • Kullanıcı ile model parametreleri arasında insanlar tarafından yazılmış birçok kod katmanı var
  • Basitçe söylemek gerekirse iki aşama var: training ve inference. Training uzun süren otomatik bir süreçtir, ama inference kullanıcı prompt’u geldiğinde anında çalışan ayrı bir yazılım stack’idir. Bu stack performans iyileştirmeleri için sürekli güncellenir ve bu sırada bu tür inference kaynaklı sorunlar ortaya çıkabilir
  • AI çekirdekleri floating point işlemler kullandığı için, normalde negatif olmaması gereken değerler bazen tuhaf biçimde negatif olabilir. Performans uğruna overflow kontrolleri kapatılabiliyor ve sonra negatif bir değer çıkarsa bu çok büyük bir sayı gibi ele alınabiliyor (tıpkı -1’inci dizi indeksini istediğinizde son elemanı almanız gibi)
• LLM inference sürecini deterministik hâle getirmeye çalışmanın sorun izleme açısından faydalı olabileceğini düşünüyorum. Yakın zamanda “bunun sadece floating point toplama sırasından kaynaklandığı” yönündeki yaygın görüşün aslında temel neden olmadığını anlatan bir makale de yayımlandı İlgili yazı
  • Ağ trafiği ya da makine yükü doğası gereği non-deterministic’tir. Yakın vadede tam determinism (ör. denetim için) ancak maliyet hassasiyeti olmayan batch işleri için gerçekçi olabilir. Nitekim Google arama da sosyal medya öneri sayılarının yüklenmesi de hiç deterministik değildir. Dağıtık sistemlerde temel tavsiye graceful degradation’dır; tamamen deterministik bir sistemde bunu yapmak mümkün değildir
  • Deterministik tasarım performansı olumsuz etkiler. Sonuçta geriye, mevcut modelin kalitesini izleyip alarm veren bir tür “IQ testi” modeli oluşturma yaklaşımı kalıyor
• “Google Cloud Vertex AI’da 27 Ağustos-16 Eylül arasında yanlış yönlendirme oranı %0,0004’ün altındaydı” ifadesine katılıyorum. Gerçekten de iş gereği o hesap üzerinden CC kullanıyorum ve kalite düşüşünü hiç fark etmedim. Genel olarak bu hatalar ciddi olsa da çevrimiçi yorumlarda söylendiğinden çok daha nadir yaşanmış gibi geldi. Sorun dönemi de aslında çoğunlukla 1-2 haftaya sıkışmıştı. Etkilenen istek oranı da toplam içinde nispeten küçüktü
  • Ama şirketin kendi yazısında da “Claude Code kullanıcılarının %30’u en az bir kez yanlış sunucuya yönlendirildi ve düşük yanıt kalitesi yaşadı” deniyor. Yönlendirme “sticky” olduğu için bir kez yanlış sunucuya düştüğünüzde sonrasında da art arda aynı sunucuya gidiyorsunuz. Claude Code kullanıcılarının %30’u kalite düşüşü yaşadıysa bu devasa bir hata demektir
  • Son zamanlarda, küresel bir kesinti olduğunda bile şirketlerin sadece “az sayıda kullanıcı için hata oranları arttı” gibi yumuşatılmış ifadeler kullandığını ve CTO onay verene kadar status sayfasını güncellemediklerini gördüğüm için şirketlere kolay güvenemiyorum. Gerçekten dürüst iletişim kuran bir şirket olursa bu piyasada ciddi avantaj sağlar
• LLM hizmetlerini deterministik çalışacak şekilde kurmanın sorun takibi için yardımcı olabileceği görüşü var. Son dönemde, nedenleri sadece floating point işlemlerin birleşme sırasına bağlamanın yetersiz kaldığını ve determinismin bozulmasına yol açan daha çeşitli etkenler olduğunu anlatan bir çalışma da anılıyor. Makale bağlantısı
• Son zamanlarda web uygulaması tasarımında Claude’un DOM içinde rastgele metinler göstermesine neden olan ciddi bir durum yaşadım. Özellikle svelte ile birlikte kullanıldığında ortaya çıkıyor gibi görünüyor; bunun yazıdaki olaylarla bağlantılı olduğundan emin değilim ama daha önce böylesine ağır bir kalite düşüşü yaşamamıştım
• Keşke yazıya somut başarısızlık örnekleri de ekleselerdi. Claude Code’da araç çağrısından sonra tamamen durup kalma sorununu sık yaşıyorum; bunun burada anlatılan hatalardan biriyle ilgili olup olmadığını merak ediyorum
  • Ben de son birkaç gündür aynı sorunu giderek daha sık yaşıyorum. Muhtemelen bu yazıdaki hatalardan bağımsızdır (ama yine de bir hata), yine de umarım yanılıyorumdur. “Neden durdun? Devam et” gibi komutları tekrar tekrar gönderme ihtiyacım belirgin şekilde arttı