Üretim uygulamaları için AI API geçersiz durum kuralı şablonu

Üretim ortamlarında çalışan uygulamaların karşılaştığı en kritik sorunlardan biri, yapay zeka API'lerinin aniden yanıt vermemesi ya da performans düşüşüdür. Bu durumda, körü körüne yeniden denemeler yapmak yerine, doğru yedek modeli, sağlayıcıyı ya da bütçe yolunu seçmek önem taşır. Bu strateji, hem hizmet sürekliliğini korur hem de maliyetleri optimize ederken müşteri deneyimini de gözetmelidir.

Yedekleme politikası oluştururken dikkate alınması gereken temel unsurlar şunlardır:

• Hangi hataların yeniden denenebilir olduğunun belirlenmesi
• Farklı trafik sınıflarına göre model indirgemeye izin verilip verilmeyeceği
• Premium yedek rotaların hangi müşteri ya da API anahtarları için kullanılabilir olduğu
• Bütçe limitlerinin yönlendirme davranışını nasıl değiştireceği
• Takımın maliyet ve kalite sorunlarını debug edebilmesi için hangi metadata'ların kaydedileceği

Kritik ve Kritik Olmayan Trafik Sınıflarını Ayırın

Tek bir global yedekleme kuralı yerine, trafiğinizi sınıflandırarak başlayın. Bu sınıflandırma, yedekleme bütçesi ve kalite eşiğinin belirlenmesinde temel rol oynar:

• Kritik kullanıcı arayüzü: Destek sohbetleri, ödeme işlemleri, müşteri hizmetleri ajan yanıtları
• Kritik olmayan kullanıcı arayüzü: Özetleme, başlık oluşturma, veri zenginleştirme, öneriler
• İç otomasyon: Sıralama, etiketleme, veri temizleme, arka ofis ajanları
• Toplu işler: Uzun süren özetlemeler, veri çıkarma, rapor oluşturma
• Deneyler: Testler, staging ortamları, değerlendirme, prompt ayarlamaları

Her sınıf için farklı bir yedekleme bütçesi ve kalite sınırı tanımlanmalıdır. Örneğin, kritik arayüzler için yedekleme maliyetinden ödün vermeden yüksek performanslı modeller kullanılabilirken, toplu işler için daha ucuz ve yavaş modeller tercih edilebilir.

Hangi Hataların Yeniden Denenebilir Olduğunu Belirleyin

Yeniden denenmesi mantıklı olan hatalar genellikle geçici ve geçici olarak çözülebilir durumlardır:

• Üst düzey zaman aşımı
• 429 hız sınırı hatası
• Geçici 5xx sağlayıcı hatası
• Ağ kesintileri
• Model uç noktasının aşırı yüklenmesi
• Akış bağlantısının düşmesi

Buna karşılık, yeniden denenmesi gereksiz olan hatalar şunlardır:

• Geçersiz API anahtarı
• Bozuk istek yükü
• Desteklenmeyen araç çağırma şeması
• İçerik politikası reddi
• Kullanıcı kotasının aşılması
• Deterministik doğrulama hatası

Geçersiz hataları yeniden denemek, genellikle token tüketimini artırmanın yanı sıra ürün hatalarını da gizleyebilir.

Örnek Bir Yedekleme Politikası Matrisi

Aşağıda, farklı trafik sınıfları için önerilen bir yedekleme politikası örneği bulunmaktadır:

Trafik Sınıfı | Birincil Yönlendirme | İlk Yedek | İkinci Yedek | Sert Durdurma --- | --- | --- | --- | --- Kritik kullanıcı arayüzü | Öncü model | Aynı sınıf model (ikinci sağlayıcı) | Daha ucuz model (açık belirsizlik mesajı) | 2 sağlayıcı başarısızlığından sonra Kritik olmayan kullanıcı arayüzü | Dengeli model | Daha ucuz model | Önbellekli/ varsayılan yanıt | Bütçe limiti aşıldığında İç otomasyon | Düşük maliyetli model | Alternatif düşük maliyetli sağlayıcı | Günlük bütçe limitinden sonra yeniden deneme kuyruğu Toplu işler | En ucuz kabul edilebilir model | Toplu işi durdur ve daha sonra devam et | Yeniden deneme bütçesi aşıldıktan sonra elle inceleme kuyruğu Deneyler | Test rotası | Yedek yok | Hemen hızlı bir şekilde başarısız ol

Bu matriste model adları değil, politikanın şekli önemlidir. Asıl hedef, hangi durumlarda hangi yedekleme yoluna başvurulacağını net bir şekilde tanımlamaktır.

Bütçe Farkındalığına Sahip Yönlendirme

Yedekleme politikaları sadece hizmet sürekliliğini değil, maliyetleri de kontrol etmelidir. Örneğin:

• Kullanıcının aylık bütçesinin %70'inden azı kullanılmışsa, normal yedekleme izin verin.
• %80'in üzerindeyse, kritik olmayan trafiği indirgeyin.
• %95'in üzerindeyse, toplu işleri durdurun ve yalnızca kritik rotaları aktif tutun.
• Ön ödemeli bakiyenin tükenmesi durumunda, pahalı bir modeli gizlice kullanmak yerine net bir kotaya yanıt verin.

Bu yaklaşım, beklenmedik faturaların önüne geçer ve karlılığı korur.

Meta Verilerin Korunması

Her yedekleme olayında, orijinal istek bağlamını korumak kritik öneme sahiptir. Kaydedilmesi gereken metadata'lar şunlardır:

• Kullanıcı ya da müşteri kimliği
• Uygulama, özellik ya da yardımcı kimliği
• Oturum/konuşma kimliği
• Birincil sağlayıcı/model
• Yedek sağlayıcı/model
• Hata nedeni
• Girdi ve çıktı token sayıları
• Son maliyet
• Yedeklemeden önce ve sonraki gecikme süresi

Bu metadata olmadan, yedekleme davranışını optimize etmek neredeyse imkansızdır.

Kalite Düşüşlerinden Kaçının

Yedek model daha ucuz ya da daha erişilebilir olabilir, ancak her görev için güvenli olmayabilir. Özellikle aşağıdaki durumlarda model indirgemeden kaçınılmalıdır:

• Hukuki, tıbbi, finansal ya da uyum gerektiren metinler
• Otomatik olarak çalıştırılacak kod üretimi
• Yazma izinleri olan araçları çağıran ajanlar
• Tam hatırlama gerektiren uzun bağlam görevleri
• Zayıf modellerin halüsinasyon yapabileceği çok dilli müşteri destekleri

Bu durumlarda, sessizce yedekleme yapmaktansa net bir şekilde başarısız olmak daha güvenlidir.

Önerilen Varsayılan Politika

Çoğu SaaS ekibi için mantıklı bir başlangıç politikası şunları içerebilir:

• Geçici hatalar için aynı sağlayıcıyı bir kez yeniden deneyin.
• Kritik trafik için eşdeğer kalitede başka bir sağlayıcıya/modela geçin.
• Kritik olmayan görevler için yalnızca daha ucuz modellere geçin.
• Kullanıcı ya da anahtar bütçesi tükendiğinde yedeklemeyi durdurun.
• Her yedekleme kararını müşteri, özellik, model, sağlayıcı, gecikme ve maliyet bilgileriyle kaydedin.

Bu politika, uygulama kodunu değiştirmeden sağlayıcı seçimlerinin esnekliğini korurken, maliyet ve kalite kontrolünü de sağlar.

Üretim uygulamalarında yedekleme politikası, yalnızca hizmet sürekliliği değil, aynı zamanda maliyet, kalite ve risk kontrolü aracıdır. En iyi politika, mühendislik, ürün ve finans ekiplerinin tümünün anlayabileceği şekilde açık ve net olmalıdır. Unutmayın: birincil model başarısız olduğunda ya da çok pahalı hale geldiğinde ne olacağını herkesin bilmesi gerekir.