Güvenilir LLM API Yönlendirmesi: Semantik Regresyonlar Olmadan Zaman Aşımları, Yeniden Denemeler ve Model Geri Dönüşleri
LLM API hatalarını sınıflandırmak, tek bir gecikme bütçesi uygulamak, uyumlu geri dönüş modellerini seçmek, yan etkileri korumak ve kabul edilen her yanıtı doğrulamak için pratik bir mimari.
Bir geri dönüş isteği, yalnızca başka bir model HTTP 200 döndürdüğü için 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ı anlamlara 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şmeyi, bir başarısızlık sınıflandırıcısını, sınırlı bir girişim politikasını ve kabul edilmeden önce doğrulamayı 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.
Modelleri seçmeden önce yönlendirme sözleşmesini tanımlayın
Başarılı bir yanıtın neler sağlaması gerektiğini açıklayarak başlayın. Bu yönlendirme sözleşmesi makine tarafından okunabilir olmalı ve her iş yüküne veya istek sınıfına eklenmelidir.
<ön>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. Gerektiğinde izin verilen bölgeler, minimum çıktı uzunluğu veya gerekli bitiş nedeni gibi uygulamaya özel kısıtlamalar ekleyin.
Ö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. Kabul edilebilir bir metin geri dönüşü olan bir model, araç çağırma veya resim girişi için otomatik olarak kabul edilebilir bir geri dönüş değildir.
Harekete geçmeden önce arızayı 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. Başarısız olan her yanıtı yeniden denenebilir olarak ele almak, kapasiteyi boşa harcar ve kusurları gizleyebilir.
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ün kat kat artmasına neden olabilir.
Öneri: bir katmanın model oluşturma yeniden denemelerine sahip olmasına izin verin. Tipik bir mimaride AI API ağ geçidi, rota durumunu, deneme geçmişini, gecikmeyi ve maliyeti gördüğü için doğru sahiptir. 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ı süresine 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:
kalan = son tarih - geçerli_zaman
gerekli = connect_allowance + Generation_allowance + validation_allowance
eğer kaldıysa < gerekli:
stop_without_launching_another_attemptSekiz 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 geri çekilmeyi kullanın:
gecikme = 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ı arızası için isteğe bağlı aynı rotada yeniden denemeyle birlikte bir birincil deneme artı bir yedekten oluşur.
Ö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. Riskten 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 geri dönüş tablosu, genel tercih sırası yerine uyumluluğu kodlamalıdır. Durum, gecikme veya fiyat dikkate alınmadan önce aday rotaları sözleşmeye göre filtreleyin.
adaylar = rotalar
.filter(supports_required_modality)
.filter(context_limit >= tahmini_giriş_boyutu)
.filter(supports_required_tools)
.filter(supports_requested_schema_mode)
.filter(izin verilen_model_sınıflarındaki model_sınıfı)
.filter(tahmini_maliyet <= kalan_maliyet_bütçe)
.filter(not_temporarily_suppressed)
seçilen = sıralama(adaylar, sağlık, gecikme, maliyet)Yapılandırılmış çıktı desteği açık bir şekilde test edilmeyi hak ediyor. İki rota şema kısıtlı oluşturmayı tanıtsa bile, farklı JSON Şeması alt kümelerini destekleyebilir veya uç durumları farklı şekilde yorumlayabilirler. 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ısı 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.
- Aktarım işleminin tamamlandığını ve yanıt zarfının ayrıştırılabileceğini onaylayın.
- Bitiş nedenini kontrol edin ve çıktının tamamı gerektiğinde kesmeyi reddedin.
- Yapılandırılmış çıktıyı orijinal şemaya göre doğrulayın.
- Gerekli alanları, numaralandırma değerlerini ve uygulama değişmezlerini doğrulayın.
- 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.
- 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 görülmesini 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 finansal alanları tahmin etmek veya araç argümanlarını yeniden yazmak, modelin anlamını değiştirir ve modelin reddedilmesini veya gerçek kişi tarafından incelenmesini tetikleyebilir.
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ı kararlarlardır.
Uygulama sınırında bir işlem kimliği ve her model çağrısına bir deneme kimliği atayın. Aşağıdakiler gibi deterministik bir anahtara karşı araç yürütme durumunu sürdürün:
execution_key = işlem_kimliği + araç_adı + canonical_arguments_hashBir 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 gerekir.
Belirsiz bir zaman aşımı özel 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 baskılaması, 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ç argümanlarını 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 süresi yer alır. Yükselen doğrulama red oranının yanı sıra artan HTTP başarı oranı, aktarım 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.
- Zaman aşımları, 429'lar, seçilen 5xx hataları, hatalı biçimlendirilmiş JSON, bağlam taşması ve hazırlamada yavaş başarıların eklenmesi.
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 açıkça başarısız olan sınırlı bir sistemdir.