Gecikme, Maliyet veya Çıktı Sözleşmelerini Bozmadan LLM Geri Dönüşleri Nasıl Tasarlanır?

Yedek yalnızca bir yedekleme modeli listesi değildir. Birkaç LLM sağlayıcısı kullanan mühendislik ekipleri için geri dönüş, bir isteğin ne zaman bir sağlayıcıdan veya modelden diğerine geçebileceğine, nelerin değişmez kalması gerektiğine ve sistemin alternatif yolun uygulamayı daha güvenilir hale getirdiğini nasıl kanıtlayacağına karar veren bir yönlendirme politikasıdır.

Okuyucunun sorunu genellikle basittir: çıktı kalitesini, şema geçerliliğini, güvenlik davranışını veya maliyeti sessizce değiştirmeden başarısız istekleri azaltın ve kuyruk gecikmesini azaltın. Çözüm "başka bir sağlayıcı deneyin"den daha spesifiktir. Güvenilir bir LLM geri dönüş stratejisi, hata sınıflandırmasına, istek son tarihlerine, model uyumluluk kurallarına, maliyet sınırlarına, devre kesicilere ve sağlayıcı ve rota düzeyinde gözlemlenebilirliğe ihtiyaç duyar.

Bir Geri Dönüş Politikasıyla Başlayın, Kodu Yeniden Denemeyin

Yeniden denemeler ve geri dönüş, farklı sorunları çözer. Yeniden deneme, aynı sağlayıcıdan geçici bir hatadan sonra aynı isteği tamamlamasını ister. Geri dönüş, işi tamamlamak için farklı bir model, sağlayıcı, bölge veya rota ister. Bu endişelerin bir araya gelmesi, olaylar sırasında akıl yürütmenin zor olduğu sistemler oluşturur.

Gerçek: Bulut altyapısı sağlayıcılarının güvenilirlik rehberliği genellikle sınırlı üstel geri çekilme, titreşim, maksimum yeniden deneme sınırları, geçicilik kontrolleri ve yeniden deneme fırtınaları aşırı yükü daha da kötüleştirebileceği için birden çok katmanda yeniden denemelerden kaçınılmasını önerir. Büyük LLM sağlayıcıları ayrıca geçici hataları, hız sınırlarını, aşırı yük yanıtlarını, zaman aşımlarını ve SDK yeniden deneme davranışını da belgelemektedir.

Öneri: her istek yolu için bir yeniden deneme katmanı uygulayın. Uygulama ağ geçidi yeniden denerse, yeniden deneme sahipliği açık olmadığı sürece aşağı akış hizmetleri de bağımsız olarak yeniden denememelidir. Her yeniden deneme, arayan için aynı son tarihi kullanmalı, yeni bir açık uçlu zaman aşımı oluşturmamalıdır.

Minimal bir politika, herhangi bir kod yazılmadan önce şu soruları yanıtlamalıdır:

• Hangi hatalar aynı sağlayıcıda yeniden denenebilir?
• Hangi hatalar başka bir sağlayıcıya veya modele geri dönüşe izin verir?
• Hangi hatalar hiçbir zaman tetiklenmemelidir geri dönüş?
• Hangi çıktı sözleşmesi aynı kalmalı?
• İzin verilen maksimum maliyet artışı nedir?
• Yede izin verilmeden önce istek son tarihinin ne kadarı harcanabilir?
• Hangi telemetri, geri dönüşün bir kusura yardımcı olup olmadığını veya bir kusuru gizlediğini kanıtlar?

Yönlendirmeden Önce Hataları Sınıflandırın Onları

Her non-200 yanıtı aynı şekilde ele alındığında geri çekilme tehlikelidir. Sağlayıcının zaman aşımı, hatalı biçimlendirilmiş bir istekle aynı şey değildir. Oran sınırı güvenlik reddi ile aynı şey değildir.Çıkış doğrulama hatası, ağ hatasıyla aynı şey değildir.

Pratik bir sınıflandırma en azından şu sınıfları içermelidir:

• Yeniden denenebilir aktarım hatası: bağlantı sıfırlama, DNS sorunu, geçici ağ hatası veya ağ geçidi zaman aşımı.
• Sağlayıcı aşırı yükü: belgelenmiş aşırı yük veya sunucu tarafı geçici başarısızlık.
• Hız sınırı: istek, belirteç, hızlandırma veya kota ilerleme hızı sınırı, özellikle bir Yeniden Deneme Sonrası değeri sağlandığında.
• Sağlayıcı zaman aşımı: sağlayıcı isteği kabul etti ancak hizmet penceresi içinde tamamlamadı.
• Geçersiz request: hatalı biçimlendirilmiş yük, desteklenmeyen parametre, geçersiz şema veya modelle uyumlu olmayan seçenek.
• Kimlik doğrulama veya yapılandırma hatası: bozuk anahtar, devre dışı bırakılmış hesap, eksik yetki veya hesap düzeyi kotası tükenmiş.
• Güvenlik reddi veya engelleme: sağlayıcı, içeriği kasıtlı olarak reddeder veya engeller güvenlik politikasıyla ilgili.
• Çıktı doğrulama hatası: model yanıt verdi, ancak yanıt uygulama sözleşmesini karşılamıyor.

Öneri: arayanın gecikme bütçesi dahilinde yalnızca geçici hataları yeniden deneyin. Yalnızca ürün ve platform ekiplerinin açıkça onayladığı hata sınıfları için geri dönüşe izin verin. Ürün belirli bir alternatif güvenli davranış tanımlamadığı sürece kimlik doğrulama hatalarına, hatalı biçimlendirilmiş isteklere, deterministik şema hatalarına veya güvenlik retlerine başvurmayın.

Bu ayrım önemlidir çünkü geri dönüş, hataları gizleyebilir. Bir şema birincil sağlayıcı için geçersizse ve yedek sağlayıcı tarafından yoksayılırsa, sistem daha az kısıtlı çıktı döndürürken daha sağlıklı görünebilir. Bu güvenilirlik değildir; bu sözleşmenin sapmasıdır.

Yalnızca Zaman Aşımlarını Değil, Son Tarihleri ​​Kullanın

Kuyruk gecikmesi sorunları genellikle teknik olarak sınırlı ancak pratik olarak çok yavaş olan yeniden denemelerden kaynaklanır. Kullanıcıya yönelik 15 saniyelik bütçeye sahip bir istek, birincil rotada 14 saniye boyunca başarısız olarak kalmamalı ve ardından, zamanında tamamlanamayan tam bir geri dönüş girişimi başlatmamalıdır.

Tüm yığın boyunca geçen bir istek son tarihi kullanın. Her yönlendirme kararı, yeniden denemeden veya geri düşmeden önce kalan süreyi kontrol etmelidir. Örneğin:

request_deadline_ms = 6000
primary_attempt_timeout_ms = 3500
retry_backoff_budget_ms = 500
minimum_fallback_budget_ms = 1800

if remaining_deadline_ms < minimum_fallback_budget_ms:
    return controlled_failure

Tam sayılar iş yüküne bağlıdır. Sohbet tamamlama rotası, bir alternatif model için yeterli süre ayırabilir. Bir arka plan çıkarma işi birden fazla denemeye izin verebilir. Gerçek zamanlı bir otomatik tamamlama yolu, geç geri dönüş yanıtı yerine hızlı bir başarısızlığı tercih edebilir.

Öneri: Gecikme bütçelerini genel olarak değil, rota sınıfına göre tanımlayın. Düşük gecikmeli bir kullanıcı arayüzü rotası, toplu sınıflandırma rotası ve uzun bağlam analizi rotası, aynı yeniden deneme ve geri dönüş zarfını paylaşmamalıdır.

Model Sınıflarını İş Yüküne Göre Tanımlayın

Satıcı adları, geri dönüş için zayıf bir soyutlamadır. Uygulama iş yükü özelliklerine önem verir: bağlam uzunluğu, muhakeme derinliği, araç desteği, yapılandırılmış çıktı davranışı, gecikme, veri işleme kısıtlamaları ve maliyet.Geri dönüş rotaları bu özellikler etrafında düzenlenmelidir.

Yararlı model sınıfları şunları içerir:

• Hızlı taslak: kısa yanıtlar, düşük gecikme, orta kalite toleransı.
• Yapılandırılmış çıkarma: katı JSON çıktı, şema doğrulama, format için düşük tolerans drift.
• Akıl yürütme: çok adımlı analiz, daha yüksek kalite gereksinimleri, daha yüksek kabul edilebilir gecikme.
• Uzun bağlam: büyük belgeler, yüksek belirteçli pencereler, dikkatli kesme kuralları.
• Düşük maliyetli toplu iş: eşzamansız veya acil olmayan işler birim ekonomi için optimize edilmiştir.
• Premium yükseltme: pahalı ancak yetenekli modeller yalnızca politika izin verdiğinde kullanılır.

Her sınıf için izin verilen birincil modelleri, izin verilen yedek modelleri ve yasak sürüm düşürme yollarını listeleyin. Uzun bağlamlı bir istek, istemi sessizce kesen kısa bağlamlı bir modele geri dönmemelidir. Yapılandırılmış bir çıkarma görevi, şema kısıtlamalarını karşılayamayan bir modele geri dönmemelidir. Premium muhakeme görevi, başka bir premium modele geri dönüşe izin verebilir, ancak kullanıcı deneyimi düşürülmüş bir yanıtı açıkça desteklemediği sürece hızlı taslak modele geri dönüşe izin veremez.

enterprise LLM API oluşturan ekipler için bu sınıflar, uygulama hizmetlerine dağılmak yerine yapılandırma veya politika verilerinde yer almalıdır. Bu, yönlendirme davranışının denetlenebilir olmasını sağlar ve sağlayıcı olayları sırasında değiştirilmesini kolaylaştırır.

Yapılandırılmış Çıkış Sözleşmelerini Koruyun

Yapılandırılmış çıktı geri dönüşü, incelikli üretim hataları oluşturmanın en kolay yerlerinden biridir. Sağlayıcılar JSON modunu, JSON Şemasını, araç çağrılarını, ret alanlarını, güvenlik geri bildirimini, bitiş nedenlerini ve şema alt kümelerini destekleme biçimleri açısından farklılık gösterir. Bir modelle çalışan bir şemanın diğerine taşınabilir olduğu garanti edilmez.

Gerçek: Bazı sağlayıcı dokümanları, desteklenen modeller için katı şema bağlılığını açıklarken, diğer doküman notları yalnızca JSON Şemanın bir alt kümesini destekler. Sağlayıcı yanıtları aynı zamanda reddetme alanlarını, istem geri bildirimini, güvenlik derecelendirmelerini, bitiş nedenlerini veya bir istem engellendiğinde veya geçersiz olduğunda hiçbir adayın bulunmamasını da içerebilir.

Öneri: Çıktı doğrulamayı arayan için isteğe bağlı bir sorun olarak değil, rotanın bir parçası olarak değerlendirin. Ağ geçidinin uygulamaya geri göndermeden önce son yanıtı doğrulaması gerekir. Doğrulama başarısız olursa rota, başarısızlığı sınıflandırmalı ve bir geri dönüş girişimine izin verilip verilmediğine karar vermelidir.

İki uygulanabilir model vardır:

Taşınabilir Bir Şema Alt Kümesi Kullanın

Şemaları, onaylanmış yedek sağlayıcılar arasında desteklenen özelliklerin kesişim noktasında tutun. Bu, taşınabilirliği artırır ve operasyonel karmaşıklığı azaltır. Bunun karşılığında sağlayıcıya özgü daha zengin kısıtlamaları kaybedebilirsiniz.

Sağlayıcıya Özel Şema Bağdaştırıcıları Kullanın

Uygulama sözleşmesini her sağlayıcının desteklenen şema biçimine çeviren bağdaştırıcıları koruyun. Bu, yeteneği korur ancak test ve bakım yükünü artırır.Ayrıca mühendislerin hangi rotaların güvenli bir şekilde geri dönebileceğini bilmesi için bir uyumluluk matrisi de gerekir.

Temel bir uyumluluk kaydı şu şekilde görünebilir:

{
  "route": "invoice_extraction_v3",
  "contract": "invoice_json_schema_v3",
  "primary": "provider_a.structured_model",
  "fallbacks": ["provider_b.extraction_model"],
  "disallowed": ["provider_c.fast_model"],
  "requires": ["json_schema", "enum", "required_fields"],
  "validation": "strict_before_return"
}

Öneri: yalnızca iyi biçimlendirilmiş bir metin olduğu için asla geri dönüş çıktısı döndürmez. Yalnızca birincil rotadan beklenen uygulama düzeyindeki sözleşmenin aynısını karşıladıktan sonra iade edin.

Olaylar Olmadan Önce Maliyeti Kontrol Edin

Yedek genellikle trafiğin arttığı veya sağlayıcının kalitesinin düştüğü anda trafiği daha pahalı modellere kaydırır. Maliyet kontrolleri olmadan, güvenilirlik mekanizması bir harcama olayına dönüşebilir.

Aşağıdakileri içeren geri dönüş kuralları belirleyin:

• Yol başına maksimum geri dönüş fiyat çarpanı.
• Kuruluş, çalışma alanı veya ortama göre izin verilen model katmanları.
• Günlük veya saatlik yedek harcama bütçeler.
• Etkileşimli ve toplu iş yükleri için ayrı politika.
• Yedekliğin sağlayıcıyı, bölgeyi veya model ailesi sınırlarını aşıp aşmadığına ilişkin kurallar.

Öneri: yalnızca ham istek maliyetini değil, başarılı yanıt başına maliyeti ölçer. Kritik bir rotada kullanıcının görebileceği bir arızayı önlüyorsa, daha pahalı bir geri dönüş haklı görülebilir. Aynı geri dönüş, düşük öncelikli toplu işler için kabul edilemez.

Maliyet politikasının, platformu kullanan kuruluşlar tarafından da görülebilmesi gerekir. Ekipler, üretim müşteri desteği iş akışları için premium geri dönüşe izin verirken bunu geliştirme, test etme veya dahili denemeler için engellemek isteyebilir. Bu yalnızca bir yönlendirme kararı değil, bir yönetim kararıdır.

Sağlayıcıya, Modele, Bölgeye ve Hata Sınıfına Göre Devre Kesiciler Ekleyin

Saf geri dönüş, kalitesi düşük bir sağlayıcıya zarar verebilir. Başarısız olan her birincil istek, başka bir birincil girişimi, ardından başka bir geri dönüş girişimini tetikler; diğer hizmetler de aynısını yapar. Devre kesiciler tekrarlanan baskıyı azaltır ve yönlendirme davranışını daha öngörülebilir hale getirir.

Devre kesici aşırı tepki vermeyi önleyecek kadar spesifik olmalıdır. Bir bölgedeki bir model yapılandırılmış çıktı hataları döndürdüğü için sağlayıcının tamamını sağlıksız olarak işaretlemeyin. Mümkün olduğunda sağlayıcıya, modele, bölgeye, rotaya ve hata sınıfına göre sağlığı izleyin.

Basit bir devre kesici durum makinesi birçok ekip için yeterlidir:

• Kapalı: rotaya normal trafik akar.
• Açık: hata eşikleri aşıldıktan sonra rotadan geçici olarak kaçınılır aşıldı.
• Yarı açık: Tam trafik devam etmeden önce sınırlı araştırma trafiği kurtarma testleri.

Eşikler hacmi hesaba katmalıdır. Dakikada on arıza, düşük hacimli bir rota için anlamlı olabilir ancak dakikada binlerce isteği karşılayan bir rota için önemsiz olabilir. Minimum örnek boyutlarını, kayan pencereleri ve hata sınıfı filtrelerini kullanın.

Öneri: devre kesiciler yalnızca HTTP arızayı saymamalıdır. Ayrıca çıktı doğrulama hatalarını, zaman aşımı oranlarını, hız sınırı oranlarını ve reddetme veya engelleme modellerini ayrı ayrı izlemeleri gerekir. Bu sınıflar farklı operasyonel yanıtlar anlamına gelir.

Yalnızca Son Hatayı Değil, Yönlendirme Kararını da Günlüğe Kaydedin

Kullanıcı deneyimini iyileştiren yedek, olayların teşhis edilmesini yine de zorlaştırabilir.Günlükler yalnızca son başarılı sağlayıcıyı gösteriyorsa, mühendisler birincil sağlayıcının başarısız olduğuna dair kanıtları kaybederler.

Her istek şunu kaydetmelidir:

• Orijinal sağlayıcı, model ve rota.
• Kullanıldığında yedek sağlayıcı, model ve rota.
• Yeniden denemeyi veya geri dönüşü tetikleyen hata sınıfı.
• Sağlayıcı istek kimlikleri mevcut.
• Yeniden deneme sayısı ve geri çekilme süresi.
• Her denemeden önce tüketilen son tarih.
• Çıktı doğrulama sonucu.
• Her deneme için tahmini maliyet ve son maliyet.
• Nihai yanıtın birincil yanıttan mı yoksa yedek yanıttan mı geldiği.
• Kuruluş, çalışma alanı, ortam ve politikanın izin verdiği yerlerde uygulama meta verileri.

Bu telemetri hem mühendislik hem de ticari yönetimi destekler. Ayrıca, farklı ekipler, ürünler veya müşteriler farklı güvenilirlik ve bütçe politikalarına sahip olduğunda geri dönüş davranışını AI API maliyet kontrolüne bağlar.

Yedeklemenin Gerçekten Yardımcı Olup Olmadığını Ölçün

Ham başarı oranı yeterli değildir. Bir geri dönüş stratejisi, son 200 yanıtı artırırken p99 gecikmesini kötüleştirebilir, maliyeti iki katına çıkarabilir veya daha az geçerli yapılandırılmış çıktı döndürebilir.

En azından şu metrikleri yola göre ölçün:

• Birincil başarı oranı.
• Yeniden deneme ve geri dönüş sonrasındaki nihai başarı oranı.
• p50, p95, ve geri dönüşten önceki ve sonraki p99 gecikmesi.
• Yedek çağrı oranı.
• Başarılı yanıt başına maliyet.
• Sözleşme açısından geçerli yanıt oranı.
• Sağlayıcıya göre güvenlik reddi veya engelleme oranı.
• Uygulamaya özel kalite gerileme sinyalleri değerlendirme.

Tahmin: Daha fazla şirket çok sağlayıcılı LLM altyapısını kullandıkça, yedek politikalar daha çok trafik mühendisliğine ve daha az geçici istisna işlemeye benzeyecek.Ekipler, bir modelin neden seçildiğini açıklayan denetim günlükleriyle birlikte çalışma alanı, ortam ve iş yükü sınıfına göre politika kontrolleri bekleyecektir.

Uygulama Kontrol Listesi

Bir üretim rotasında geri dönüşü etkinleştirmeden önce bu kontrol listesini kullanın:

• Rotanın gecikme bütçesini ve istek son tarihini tanımlayın.
• Sağlayıcı hatalarını yeniden denenebilir, geri dönüşe uygun, ve terminal sınıfları.
• Hangi hataların geri dönüşü tetiklememesi gerektiğini belgeleyin.
• Onaylanan birincil ve yedek modelleri iş yükü sınıfına göre listeleyin.
• Her yedek için bağlam uzunluğunu, araç desteğini, şema desteğini ve güvenlik davranışını doğrulayın.
• Uygulama sözleşmesine göre her nihai yanıtı doğrulayın.
• Maksimum yeniden deneme sayısını ayarlayın, geri çekilme, titreşim ve Sonra Yeniden Dene işleme.
• Devre kesicileri sağlayıcıya, modele, bölgeye ve hata sınıfına göre yapılandırın.
• Maliyet çarpanlarını ve yedek harcama sınırlarını ayarlayın.
• İstek kimliklerini, hata sınıflarını, girişimleri, doğrulama sonuçlarını, gecikmeyi ve maliyeti günlüğe kaydedin.
• p95 ve p99 gecikmesini inceleyin kullanıma sunulduktan sonra yalnızca ortalama gecikme değil.
• Test sağlayıcı kesintisi, hız sınırı, geçersiz şema, güvenlik reddi ve çıktı doğrulama hatası senaryoları.

Uygulanabilir Sonuç

İyi bir LLM geri dönüş stratejisi, yönetilen bir yönlendirme politikasıdır. Yeniden denemeyi geri dönüşten ayırır, hataları kesin olarak sınıflandırır, çıktı sözleşmelerini korur, gecikme son tarihlerine saygı gösterir ve maliyetleri olaylar gerçekleşmeden görünür hale getirir.

Temel tasarım ilkesi değişmezliktir. Trafik birincil modelden yedek modele geçtiğinde neyin doğru kalması gerektiğine karar verin: şema geçerliliği, güvenlik davranışı, bağlam yönetimi, araç desteği, maliyet sınırları ve gözlemlenebilirlik. Daha sonra yalnızca bu değişmezler korunabildiğinde geri dönüşe izin verin.

Genel bir geri dönüş anahtarı yerine yüksek değerli tek bir rotayla başlayın. Hata sınıflandırmasını, uyumlu geri dönüş modellerini, doğrulama kurallarını, devre kesicileri ve ölçümleri tanımlayın. Bu rotaya karşı başarısızlık tatbikatları yapın. Kabul edilemez p99 gecikmesi, sözleşme geçerli yanıt kaybı veya maliyet artışı olmaksızın nihai başarı oranı iyileşiyorsa, politikayı bir sonraki iş yükü sınıfına genişletin.

İlgili okuma

• LLM harcamasını ekibe ve uygulamaya göre ayırma