Çoklu Sağlayıcılı LLM Yönlendirmesi Bir Politika Sorunudur

Kullanışlı bir model yönlendirici, yetenekleri, izinleri, bölge gerekliliklerini, bütçeleri ve arıza davranışlarını açık bir sözleşme çerçevesinde bir araya getirir.

Birkaç model sağlayıcısını desteklemek, bir adaptör sorununa benziyor: isteği standart hale getirin, bir API’yi çağırın ve yanıtı standart hale getirin. Bu gerekli bir adımdır, ancak zorlu ürün kararlarını çözüme kavuşturmaz.

Bu kiracı için hangi sağlayıcı izin verilmiştir? Gerekli çıktı sözleşmesini destekliyor mu? İstek, yapılandırılmış veri sınırını aşabilir mi? İlk yanıt akışa başladıktan sonra hata verirse ne olmalıdır?

Modeli seçmeden önce işi tanımlayın

Yönlendirmenin görevle birlikte başlamasını istiyorum. Bir veri alma yeniden yazımı, müşteriye yönelik bir cevap ve bir araç kullanılarak gerçekleştirilen planlama adımı, kalite, gecikme süresi, bağlam boyutu ve çıktı yapısı açısından farklı gereksinimlere sahiptir.

Talepte bu şartlar, kiracı politikası ve bütçeyle birlikte açıkça belirtilmelidir. Model seçimi aşamasında, uygun olmayan adaylar elenebilir ve ardından kalan seçenekler karşılaştırılabilir.

Uygulamanın çeşitli yerlerine dağılmış sağlayıcı adına dayalı koşul ifadeleri yerine, yetenek denetimlerini tercih ederim. Bir yetenek kaydı, araç desteğini, yapılandırılmış çıktıyı, akış davranışını, bağlam sınırlarını ve o yapılandırma için doğrulanmış dağıtım bölgesini tanımlayabilir.

Paylaşılan sözleşmeyi dürüst tutun

Genel bir adaptör, uygulamanın gerçekte neye ihtiyaç duyduğunu belirlemelidir. Her sağlayıcının her özelliği aynı şekilde uyguladığını varsaymamalıdır.

Örneğin, akış sırasında araç çağrıları aşamalı olarak gelebilir. Kullanım hesaplamaları, metinden farklı bir aşamada gelebilir. Bir sağlayıcı, başka bir sağlayıcının kabul ettiği bir şemayı reddedebilir. Adaptörün, bu farklılıklar için tanımlanmış bir davranışa ve gerçek veri aktarım formatını test eden denemelere ihtiyacı vardır.

Bir işlev kullanılamadığında, ya açık bir hata mesajını ya da açıkça onaylanmış bir alternatif yolu tercih ederim. Gerekli bir kısıtlamayı sessizce ortadan kaldırmak, görev sözleşmesini ihlal ederken başarılı gibi görünen bir sonuç doğurur.

Yedek plan, hak kazanma koşullarını korumalıdır

Bir yedekleme zinciri, yalnızca mevcut istek için izin verilen sağlayıcıları içermelidir. Kullanılabilirlik, kiracı kısıtlamasını, bölge gerekliliğini veya harcama sınırını geçersiz kılmaz.

Hata türlerini birbirinden ayırırım. Geçici bir hizmet hatası, başka bir sağlayıcıya geçmeyi haklı kılabilir. Geçersiz kimlik bilgileri, yapılandırmanın düzeltilmesini gerektirir. Geçersiz bir istek, her yerde aynı şekilde hata verebilir. Bir reddetme durumu da, otomatik olarak aktarım hatası olarak değerlendirilmek yerine, uygulamanın kurallarına göre yorumlanmalıdır.

Her ek deneme zaman alır ve maliyetli olabilir. Yönlendiriciye, sağlayıcı her değiştiğinde yeni bir kota değil, toplam bir son tarih ve bir deneme kotası gerekir.

“Kısmi çıktı”nın ne anlama geldiğine karar verin

Kullanıcıya herhangi bir çıktı ulaşmamışsa, başka bir sağlayıcıyı denemek nispeten kolay olabilir. Cevabın bir kısmı görüntülendikten sonra, ikinci bir modelin yeni cevabını eklemek kafa karıştırıcı veya çelişkili bir mesaj ortaya çıkarabilir.

Ya seçilen yayınlanma noktasına kadar oluşturma işlemini tamponlayarak bekletirdim ya da açıkça bir hata yanıt durumu gösterip yeniden başlatma seçeneği sunardım. Doğru seçim ürüne bağlıdır, ancak bu karar bilinçli bir şekilde verilmelidir.

Araç yürütme işlemi başka bir sınır getirir. Bir modelin yeniden denemesi, sırf bir sonraki planlama adımı başarısız oldu diye tamamlanmış bir harici eylemi tekrarlamamalıdır. İşlem defteri, sağlayıcı adaptörünün dışında yer almalıdır.

Hizmet kalitesindeki düşüş dahil olmak üzere yönlendirme kararlarını değerlendirin

Yönlendirme izlemem, görev türü, uygun adaylar, seçilen sağlayıcı, yedekleme nedeni, politika sürümü, gecikme süresi ve hesaplanan kullanımı içermektedir. Hassas komut içeriğinin her metrik içine kopyalanması gerekmez.

Ayrıca, bağımlılıkların durumunu arızanın kapsamına göre de ayırıyorum. Yanlış yapılandırılmış bir dahili yardımcı, normalde sorunsuz çalışan bir müşteri sohbet yolunun devresini mutlaka kesmemelidir. Doğru devre kesici sınırı, hangi kimlik bilgileri, modeller ve dağıtımların arıza koşullarını paylaştığına bağlıdır.

Çoklu sağlayıcı tasarımı, değişen koşullar altında ürünün vaatlerini yerine getirebildiği durumlarda faydalıdır. Mühendislik çalışması, acil durum yolu da dahil olmak üzere her yolun kontrol edilebilmesi için bu vaatleri yeterince açık bir şekilde ortaya koymaktır.

25 Eylül 2026 tarihinde güncellenmiştir.