Anthropic Batch API postmortem'i: 1.842 işin 112'si sessizce başarısız oldu

Ne oldu

Bir geliştirici, dev.to üzerinde yayımladığı bir postmortem'de, 30 gün boyunca Anthropic'in Batch API'si üzerinden gönderilen 1.842 isteğin 112'sinin tek bir görünür hata bile olmadan kullanılabilir bir sonuç üretmediğini anlatıyor. Yazar, sesli mülakat simülasyonları yapıp yazılı raporlar döndüren Preterview platformunu geliştirip işletiyor ve hem gece yapılan portföy puanlamasını hem de mülakat sonrası rapor üretimini batch API'sine taşımıştı.

Yüzeyde her şey sağlıklı görünüyordu: batch'ler tamamlanıyor, worker çalışıyor, hata logları sessizdi. İlk gerçek sinyal, boş bir raporun ve boş bir puan alanının ekran görüntüsünü e-postayla gönderen bir kullanıcıdan geldi; sorunun kaynağı dört saattir NULL olarak bekleyen bir veritabanı satırıydı.

112 istek nereye gitti

dev.to yazısına göre 30 günlük süreç 96 batch'i kapsıyordu. Ham sonuçlar: 1.747 istek succeeded durumuna döndü, 71'i hata verdi, 24'ü API'nin 24 saatlik sınırında expire oldu ve hiçbiri cancel edilmedi. 71 hatanın 52'si overloaded_error, 14'ü transkriptlerin yazarın kendi token bütçesini aşması kaynaklı invalid_request_error ve 5'i genel api_error'du.

Geriye kalan 17 başarısızlık ise başarıların içinde gizliydi. Bu yanıtlar stop_reason: max_tokens taşıyordu; yani çıktı JSON'un ortasında kesilmişti. Geliştiricinin parser'ı kesik gövdelerde exception fırlatıyordu, bir exception handler bunu DEBUG seviyesinde logluyor ve satırlar sessizce boş kalıyordu. Gerçekten kullanılabilir sayı 1.730 — yüzde 93,9 — ve mevcut izlemenin hiç görmediği yüzde 6,1'lik bir başarısızlık oranı ortaya çıkıyordu.

Kullanıcı verilerini birbirine karıştıran hata

En zarar verici kusur, eksik sonuçlardan çok yanlış sonuçlar üretti. Batch sonuçları rastgele bir sırayla geri gelir, ancak orijinal kod sonuç listesini gönderilen oturumlarla zip'liyor, ikisinin hizalı olduğunu varsayıyordu. Her istek başarılıyken sıralama genellikle yeterince yakındı ve hiçbir şey yanlış görünmüyordu. Tek bir istek düştüğünde ise ondan sonaki her kayıt bir kayıt yukarı kayıyor ve bir adayın raporu başka bir adayın oturumuna kaydediliyordu.

Yazar, bir adayın hiç bahsetmediği bir Kubernetes projesini öven bir rapor okuduktan sonra durumu fark ettiğinde iki oturum etkilenmişti. Her iki kullanıcıyla da doğrudan iletişime geçildi. Yazı bunu gerçekten korku yaratan hata olarak tanımlıyor: exception yok, uyarı yok, sadece yanlış kişiye bağlı, makul görünen bir çıktı.

Düzeltmeler

Yazıda paylaşılan düzeltilmiş kod birkaç kuralı izliyor:

• Sonuçları custom_id ile eşleştir, asla pozisyonla değil. custom_id ayrıca opak bir iç tanımlayıcı olmalı — yazar bir oturum UUID'si kullandı — e-posta adresi gibi pratik bir şey değil.

• result.type'ın her değerini (succeeded, errored, expired, canceled) açıkça ele al, bir isteğin sızmaması için varsayılan bir dal bırakma.

• Başarılarında bile stop_reason'ü kontrol et ve max_tokens'i yeniden denenecek bir kesilme hatası olarak değerlendir.

• Batch'i göndermeden önce veritabanına bir pending satırı yaz, böylece hiç dönmeyen bir istek görünmez bir delik değil, görünür bir boşluk olarak ortaya çıkar.

Yazarın daha geniş çıkarımı şu: custom_id, batch_id, durum ve deneme sayılarını takip eden, zamanlanmış bir job tarafından taranan reconciler — herhangi bir batch hattı için ilk inşa edilmesi gereken bileşen olmalı, sonradan akla gelen bir şey değil.

Gecikme süresi ve senkrona geri çekilme

Süreç boyunca batch gecikmesi güçlü biçimde çarpıktı: medyan 9 dakika, p90 51 dakika ve p99 altı saatin üzerindeydi; 24 istek ise 24 saatlik işleme sınırına kadar bekleyip expire oldu. Bu kanıta dayanarak mülakat sonrası rapor senkron API'ye geri taşındı — 25 dakikalık bir mülakatı yeni bitirmiş biri saatlerce sayfayı yenilemeyecek — gece yapılan portföy puanlaması ise batch'te kaldı; burada yaklaşık yüzde 50'lik indirim (aylık fatura 209 dolardan 104 dolara düştü) beklemeyi haklı kılıyor.

Neden önemli

Anthropic'in Batch API'si, 24 saatlik bir işleme penceresi içinde batch başına 100.000'e kadar isteği kabul ederek, yaklaşık yarı fiyatına asenkron toplu çıkarım sunuyor. Bu gece işleri için güçlü bir teklif, ancak bu postmortem sözleşmenin senkron bir API'den, sessizce başarısız olan yönlerde farklılaştığını gösteriyor. ended durumuna ulaşan bir batch, içindeki her isteğin akıbeti hakkında hiçbir şey söylemez; sıralama garanti edilmez ve başarılı bir yanıt yine de kesilmiş olabilir. Bu API'yi — ya da benzer semantiğe sahip herhangi bir asenkron kuyruğu — kullanan her ekibin, öğe bazında mutabakata, kapsamlı sonuç işlemeye ve hiç geri gelmeyen istekleri fark edecek bir mekanizmaya ihtiyacı var.