Yeniden Deneme Döngünüz En Pahalı Özelliğinizdir

Gizli 4 kat token vergisi en çok yoğun yük altında vurur

Birlikte çalıştığım bir geliştirici ekip, görev başına maliyeti tek bir token'a kadar takip ediyordu. Bağlam (context) sınırları koydular ve bütçe uyarıları tanımladılar. Ardından model istemcisine retries: 3 (3 yeniden deneme) eklediler ancak bunu bütçe hesabına hiç katmadılar.

Bu yeniden deneme yolu yalnızca model yavaşladığında veya çöktüğünde, yani tam da yoğun yük (peak load) anlarında devreye girer. Üstelik her yeniden deneme, tüm bağlamı baştan sona tekrar gönderir. Sonuç olarak sistemde kimsenin hesaba katmadığı tek kısım, bütçenizin en kısıtlı olduğu anda en yüksek maliyeti çıkaran kısma dönüşür.

İnsanları Şaşırtan Rakamlar#

Bir e-ticaret mağazasının destek ajanını (support agent) ele alalım. Zorlu bir destek talebi; sipariş geçmişi, politika dokümanları ve önceki konuşmalarla birlikte 50k token bağlam çeker ve yaklaşık 1k token yanıt üretir. Tek bir deneme yaklaşık 51k token tutar.

İstemciye retries: 3 eklendiğinde ve görev yine de başarısız olduğunda, 4 deneme için ödeme yaparsınız: 51k olarak bütçelediğiniz bir görev için 51k × 4 ≈ 204k token ödersiniz. Bu 4 katlık bir vergidir ve eşit dağılmaz. Başarısız olan görevler zaten en pahalı olanlardır: uzun bağlamlar, ağır araç zincirleri (tool chains) ve karmaşık girdiler. Yeniden denemeler tam olarak maliyetin en yüksek olduğu yerde yoğunlaşır.

retry_policy:
  naive:
    attempts: 3
    on_failure: "replay full context to same model"
    hidden_cost_multiplier: 4 # 1 deneme + 3 tam bağlam tekrarı
    shows_up_in_dashboard: false
  cost_aware:
    attempts: 3
    on_failure: "route to next equivalent model"
    carries_context: true
    hidden_cost_multiplier: 1 # bağlam taşınır, tekrar oynatılmaz
    shows_up_in_dashboard: true

Fatura Neden Görünmez Kalır?#

Çoğu maliyet panosu (dashboard), başarılı istek başına ortalama maliyeti raporlar. Üç kez başarısız olup dördüncüde başarılı olan bir görev panoda "4 kat maliyet" olarak görünmez; sadece gecikme (latency) sıçraması yaşanmış tek bir başarılı işlem gibi görünür. Yeniden deneme, harcamaların gizli dördüncü eksenidir:

• Gecikme üç katına çıkar → birileri bunu hemen fark eder.
• Maliyet üç katına çıkar → neredeyse kimse ölçmez, çünkü "başarısız olup yeniden denenen" trafiğin içine gömülüdür.

Bu yüzden yazılım ekipleri sadece her şeyin yolunda gittiği senaryoyu (happy path) optimize eder, ancak stres altında çalışan ve faturayı katlayan o kritik kod yolunu görmezden gelir.

Çözüm Yeniden Denemek Değil, Yönlendirmektir (Routing)#

Daha fazla yeniden deneyerek sistemi ucuzlatamazsınız. Bağlamı tekrar tekrar göndermeyi bırakmalısınız: Bir model kullanılamadığında, görevi aynı devir bağlamını (handoff_context) alabilecek bir sonraki eşdeğer modele yönlendirmelisiniz. Böylece bağlam görevle birlikte taşınır ve "yeniden deneme" adı altında tekrar ücretlendirilmez.

OpenAI uyumlu tek bir uç nokta (endpoint) arkasında 25'ten fazla model bulunduğunda, "eşdeğer model" kavramı teorik olmaktan çıkar; istemleri (prompts) veya adaptörleri yeniden yazmadan doğrudan yönlendirme yapabileceğiniz pratik bir katman elde edersiniz. Ayrıca veri yerleşimi kurallarına (PDPA vb.) tabi ekipler için bağlamı sırf yeniden denemek adına farklı bir sağlayıcıda tekrar çalıştırmak sadece maliyet değil, uyumluluk sorunları da doğurur.

def step(task, model_registry):
    # Maliyet odaklı yaklaşım: Bağlam BİR KEZ ödenir ve görevle taşınır
    for model in model_registry.ordered_for(task.capability):
        try:
            return model.call(task.handoff_context)  # tekrar gönderim yok
        except Unavailable:
            continue  # aynı bağlamla sıradaki eşdeğer modele geç
    raise NoCapableModel

Geliştiriciler İçin Pratik Çıkarımlar:

• Observability (Gözlemlenebilirlik): LLM izleme araçlarınızda sadece başarılı yanıtları değil, başarısız deneme (failed attempt) başına harcanan token miktarını da ayrı bir metrik olarak takip edin.
• Akıllı Fallback Mimarisi: Körü körüne aynı modele retry atmak yerine, eşdeğer yeteneklere sahip alternatif modellere geçiş yapan bir yönlendirme (routing) katmanı kurgulayın.

Bu konuyu derinlemesine öğrenmek isterseniz: Production'da Agent Güvenilirliği modülüne göz atın.