Güvenilir LLM API Yönlendirmesi: Semantik Regresyonlar Olmadan Zaman Aşımları, Yeniden Denemeler ve Model Geri Dönüşleri

Başka bir model HTTP 200 döndürdüğü için bir geri dönüş isteği başarılı olmaz. Değiştirme, orijinal gecikme bütçesini aşabilir, gerekli JSON alanlarını atlayabilir, farklı bir araç çağırabilir veya önemli ölçüde farklı anlambilime sahip bir yanıt üretebilir. Bu nedenle güvenilir LLM API yönlendirmesi, sıralı bir model listesinden daha fazlasını gerektirir: bir sözleşme, bir başarısızlık sınıflandırıcısı, sınırlı bir girişim politikası ve kabulden önce doğrulama gerektirir.

Temel kural basittir: yalnızca başarısızlık makul derecede geçici olduğunda yeniden deneyin ve yalnızca bir sonraki rota orijinal istek sözleşmesini hâlâ karşılayabildiğinde geri çekilin.

Define the routing contract before choosing models

Başarılı bir yanıtın neler sağlaması gerektiğini açıklayarak başlayın. This routing contract should be machine-readable and attached to each workload or request class.

{
  "workload": "invoice_extraction",
  "modalities": ["text", "image"],
  "max_input_tokens": 50000,
  "requires_tools": false,
  "structured_output": {
    "required": true,
    "schema_id": "invoice-v3",
    "strict": true
  },
  "allowed_model_classes": ["document-extraction"],
  "max_cost_usd": 0.08,
  "deadline_ms": 8000
}

Sözleşme gerekli yöntemleri, bağlam kapasitesini, araç desteğini, yapılandırılmış çıktı davranışını, kabul edilebilir model sınıflarını, maksimum maliyeti ve uçtan uca son tarihi kapsamalıdır. Add application-specific constraints where necessary, such as permitted regions, minimum output length, or a required finish reason.

Öneri: Düz metin, şemayla kısıtlı çıktı, araç kullanımı, vizyon ve uzun bağlam istekleri için ayrı, test edilmiş rota grupları bulundurun. A model that is an acceptable text fallback is not automatically an acceptable fallback for tool calling or image input.

Harekete geçmeden önce hatayı sınıflandırın

Kimlik doğrulama hataları, hatalı biçimlendirilmiş istekler, hız sınırları ve sunucu arızaları farklı yanıtlar gerektirir. Treating every non-success response as retryable wastes capacity and can hide defects.

Gerçek: Hızla sınırlı başarısız istekler yine de sağlayıcı sınırlarına dahil edilebilir. Agresif acil yeniden denemeler bu nedenle kısıtlamayı çözmek yerine derinleştirebilir. Yeniden denemeler ayrıca kesinti sırasında ek kapasite tüketir ve çeşitli uygulama katmanlarındaki yeniden deneme politikaları, ortaya çıkan yükü çoğaltabilir.

Öneri: bir katmanın model oluşturma yeniden denemelerine sahip olmasına izin verin. Tipik bir mimaride AI API ağ geçidi doğru sahiptir çünkü rota durumunu, deneme geçmişini, gecikmeyi ve maliyeti görür. Mümkün olduğunda alt düzey istemcilerde otomatik yeniden denemeleri devre dışı bırakın veya bunları açıkça aynı deneme bütçesine dahil edin.

Bir uçtan uca gecikme bütçesi harcayın

Deneme başına zaman aşımları yetersiz. Beş saniyelik zaman aşımına sahip üç deneme, geri çekilme ve doğrulama dahil edilmeden önce amaçlanan beş saniyelik işlemi on beş saniyelik bir yanıta dönüştürebilir.

İstek ağ geçidine girdiğinde kesin bir son tarih kaydedin. Her denemeden önce kalan süreyi hesaplayın:

remaining = deadline - current_time
required  = connect_allowance + generation_allowance + validation_allowance

if remaining < required:
    stop_without_launching_another_attempt

Sekiz saniyelik bir son tarih için, makul bir başlangıç tahsisi, ağ geçidi çalışması ve son doğrulama için 300 ms ayırabilir, birincil rota için 4,5 saniyeye kadar izin verebilir ve bir geri dönüş için yaklaşık 3,2 saniyeyi koruyabilir. Bu değerler bir kıyaslama değil örnektir. Bunların gerçek sağlayıcılar, modeller, bölgeler ve çıktı boyutları için ölçülen gecikme dağılımlarından türetilmesi gerekir.

Geçici yeniden denemeler için titreşimli sınırlı üstel gerilemeyi kullanın:

delay = random(0, min(cap, base * 2^retry_index))

Sağlayıcının yeniden deneme değeri gibi yeniden deneme ipuçları, kalan süreye uyduklarında öncelikli olmalıdır. Az sayıda denemeden sonra durun. Yaygın bir politika, yalnızca faturalandırılabilir çıktı oluşturamayan erken bir bağlantı hatası için isteğe bağlı aynı rota yeniden denemesiyle birlikte bir birincil deneme artı bir yedektir.

Ödül: sıralı geri dönüş, kullanılabilirliği artırır ancak kuyruk gecikmesini artırır. Paralel veya korunan istekler, yavaşlamalar sırasında gecikmeyi azaltabilir ancak daha fazla kapasite tüketir ve birden fazla başarılı nesil için ücret alınmasına neden olabilir. Korunma, iptal ve maliyet kontrolleri ile gecikme açısından kritik, yan etkisi olmayan iş yükleriyle sınırlandırılmalıdır.

Yedekleri sıralamaya göre değil, yeteneğe göre seçin

Bir yedek tablo, genel tercih sırası yerine uyumluluğu kodlamalıdır. Durum, gecikme veya fiyatı dikkate almadan önce aday rotaları sözleşmeye göre filtreleyin.

candidates = routes
  .filter(supports_required_modalities)
  .filter(context_limit >= estimated_input_size)
  .filter(supports_required_tools)
  .filter(supports_requested_schema_mode)
  .filter(model_class in allowed_model_classes)
  .filter(estimated_cost <= remaining_cost_budget)
  .filter(not_temporarily_suppressed)

selected = rank(candidates, health, latency, cost)

Yapılandırılmış çıktı desteği açık bir şekilde test edilmeyi hak eder. İki rota, şema kısıtlı oluşturmanın reklamını yaptığında bile, farklı JSON Şema alt kümelerini destekleyebilir veya uç durumları farklı şekilde yorumlayabilir. Araç özellikli modeller aynı şekilde araç seçimi, bağımsız değişken oluşturma ve paralel çağrı davranışı açısından da farklılık gösterebilir.

Gerçek: Model ailelerini değiştirmek, stili, muhakeme kalitesini, güvenlik davranışını, simgeleştirmeyi ve araç seçimini değiştirirken aktarım kullanılabilirliğini koruyabilir. HTTP başarı anlamsal eşdeğerliğin kanıtı değildir.

Tahmin: Model katalogları genişledikçe üretim yönlendirme politikaları, statik model listeleri yerine giderek daha fazla sürümlendirilmiş yetenek profillerini ve iş yüküne özel kabul testlerini kullanacak. Bunu, sağlayıcı davranışına ilişkin bir garanti olarak değil, bir tasarım yönlendirmesi olarak değerlendirin.

Yanıtı kabul etmeden önce doğrulayın

Birincil yanıt da dahil olmak üzere her yanıtı aynı kabul hattı üzerinden çalıştırın. Doğrulama, sonuç önbelleğe alınmadan, dahili olarak başarılı olarak faturalandırılmadan veya bir araç yürütücüsüne aktarılmadan önce gerçekleştirilmelidir.

1. Aktarım işleminin tamamlandığını ve yanıt zarfının ayrıştırılabileceğini onaylayın.
2. Bitiş nedenini kontrol edin ve çıktının tamamı gerektiğinde kesmeyi reddedin.
3. Yapılandırılmış çıktıyı orijinal şemaya göre doğrulayın.
4. Gerekli alanları, numaralandırma değerlerini ve uygulama değişmezlerini doğrulayın.
5. Yalnızca kayıtlı araç adlarına izin verin ve bağımsız değişkenleri her araç şemasına göre doğrulayın.
6. Yanlış kabulün maliyetli olacağı durumlarda iş yüküne özel anlamsal kontroller uygulayın.

Fatura çıkarma için anlamsal kontroller, negatif olmayan bir toplam, desteklenen bir para birimi kodu ve açıkça tanımlanmış bir tolerans dahilindeki satır öğesi toplamlarını gerektirebilir. Sınıflandırma için izin verilen gruptan bir etiket isteyin. Kod üretimi için ayrıştırma veya derleme uygun olabilir. Bu kontroller kaliteyi kanıtlamaz ancak öngörülebilir sözleşme ihlallerinin başarı olarak değerlendirilmesini engeller.

Her hatalı biçimlendirilmiş yanıtı sessizce onarmayın. Çevredeki zararsız boşlukların kaldırılması gibi deterministik normalleştirme kabul edilebilir. Eksik mali alanları tahmin etmek veya araç argümanlarını yeniden yazmak, modelin anlamını değiştirir ve reddedilmeyi veya gerçek kişi tarafından incelemeyi tetiklemelidir.

Yeniden oluşturma denemelerini yan etkilerden ayırın

LLM istekleri genellikle doğası gereği bağımsız olmayan HTTP POST'u kullanır. Daha da önemlisi, bir model yanıtı, bir ödeme yöntemini ücretlendirmek, mesaj göndermek, destek talebi oluşturmak veya altyapıyı değiştirmek gibi harici bir eylemi başlatabilir. Oluşturmayı yeniden denemek ve bu eylemi yeniden oynatmak ayrı kararlardır.

Uygulama sınırında bir işlem kimliği ve her model çağrısına bir deneme kimliği atayın. Belirleyici bir anahtara karşı araç yürütme durumunu devam ettirin, örneğin:

execution_key = operation_id + tool_name + canonical_arguments_hash

Bir aracı çalıştırmadan önce anahtarın beklemede, tamamlanmış veya başarısız olup olmadığını kontrol edin. Tamamlanmış bir yürütme için saklanan sonucu tekrar çalıştırmak yerine döndürün. Bağımsız değişkenleri yasal olarak değişebilecek işlemler için uygulama düzeyinde onay veya yeni bir işlem kimliği gerektir.

Belirsiz bir zaman aşımı özel bir işlem gerektirir. Bir istek iletildikten sonra bağlantı başarısız olursa ağ geçidi, oluşturmanın gerçekleşip gerçekleşmediğini bilemeyebilir. Sağlayıcı tarafından desteklenen bir idempotency anahtarı, mevcut olduğunda yardımcı olabilir. Aksi takdirde sonucu bilinmiyor olarak günlüğe kaydedin ve hiçbir şey olmadığını varsaymak yerine iş yüküne özel bir yeniden oynatma politikası uygulayın.

Sağlıksız rotaları bastırın ve her girişimi açığa çıkarın

Bir devre kesici veya geçici durum engellemesi, her yeni isteğin aynı başarısız rotayı yeniden keşfetmesini engeller. Tanımlanmış bir hata oranı veya ardışık arıza eşiğinden sonra devreyi açın, ardından sınırlı probları yarı açık durumda kabul edin. Yanlış biçimlendirilmiş bir istemci isteğinin sağlıklı bir modelin kullanılamaz görünmesine neden olmaması için eşikleri rotaya ve hata sınıfına göre ayarlayın.

İstek düzeyinde bir etkinlik ve deneme başına bir etkinlik kaydedin. Yararlı alanlar arasında işlem kimliği, deneme kimliği, seçilen sağlayıcı ve model, arıza sınıfı, durum kodu, gecikme, belirteç sayıları, tahmini maliyet, geri dönüş nedeni, doğrulama sonucu, devre durumu ve nihai sonuç yer alır. İstemleri, çıktıları ve araç bağımsız değişkenlerini hassasiyet ve saklama gereksinimlerine göre düzenleyin veya karma hale getirin.

Yararlı operasyonel ölçümler arasında geri dönüş oranı, tamamlanan istek başına girişim sayısı, son tarih tükenme oranı, doğrulama red oranı, belirsiz sonuçlar, kabul edilen yanıt başına maliyet ve son rotaya göre gecikme yer alır. Yükselen HTTP başarı oranının yanı sıra doğrulama red oranının artması, taşıma kullanılabilirliğinin sözleşme başarısızlıklarını maskelediğine dair bir uyarıdır.

Üretim kullanıma sunma kontrol listesi

• Her iş yükü sınıfı için sürümlendirilmiş bir yönlendirme sözleşmesi tanımlayın.
• Sağlayıcı hatalarını kalıcı, geçici, uyumsuz, geçersiz yanıt ve belirsiz kategorilere ayırın.
• Bir yeniden deneme sahibi seçin ve toplam deneme sayısını sınırlayın.
• Ağ geçidi, sağlayıcı istemcisi, doğrulama ve araç yürütme aracılığıyla mutlak bir son tarih yayınlayın.
• Tek bir küresel model zinciri yerine, yetenekleri test edilmiş yedek gruplar oluşturun.
• Şemaları, araç çağrılarını, bitiş nedenlerini ve etki alanı değişmezlerini doğrulayın.
• İşlem ve yürütme anahtarlarıyla yan etkileri tekilleştirin.
• Sınırlı yarı açık araştırmalarla rota bastırma ekleyin.
• Deneme düzeyindeki gecikmeyi, belirteçleri, maliyeti, hataları ve kabul sonuçlarını günlüğe kaydedin.
• Enjekte zaman aşımları, 429'lar, seçili 5xx hataları, hatalı biçimlendirilmiş JSON, içerik taşması ve aşamalandırmada yavaş başarılar.

Tek bir düşük riskli iş yükü için birincil rota ve uyumlu bir yedek ile başlayın. Politikayı genişletmeden önce kabul edilen yanıt kalitesini, gecikmeyi ve maliyeti karşılaştırın. Amaç mümkün olan en yüksek geri dönüş oranı değildir. Orijinal sözleşmeyi karşılayan bir yanıt döndüren veya yinelenen çalışmaya veya anlamsal hasara neden olmadan önce açıkça başarısız olan sınırlı bir sistemdir.

İlgili okuma

• önceki API test notu
• önceki İngilizce makale