Yapay zeka modeli takma adları, her sağlayıcı model kimliğini doğrudan ürün koduna kodlamak yerine uygulamaların çağırabileceği sabit adlardır. Basit görünüyorlar: Bir istek chat-default, coding-fast, gpt-latest veya başka bir adlandırılmış hedefin kullanılmasını söylüyor. Ancak bu adın arkasında, istek anında hangi sağlayıcının, model sürümünün, uç noktanın, politikanın, fiyatın ve geri dönüş davranışının uygulanması gerektiğine ilişkin operasyonel bir karar vardır.

Prototipler için, sağlayıcı adlarını doğrudan kullanmak genellikle iyidir. Geliştirici belirli bir OpenAI, Anthropic, Gemini veya yönlendirici modelini arayabilir ve hızlı bir şekilde gönderebilir. Sorun daha sonra, sağlayıcı bir takma adı değiştirdiğinde, anlık görüntüyü kullanımdan kaldırdığında, fiyatlandırmayı güncellediğinde, yetenekleri ayarladığında veya daha iyi bir model yayınladığında ortaya çıkar. Model adları hizmetler, işler, istemler, testler ve yapılandırma dosyaları arasında dağılmışsa her geçiş yavaş ve riskli hale gelir.

LLM API'leri için model takma ad yönetimi, model adlarını kontrollü bir katmana dönüştürür. Amaç sadece daha güzel adlandırma değil. Bunun amacı, operatörlerin AI model sürümlerini sabitleme, çözümlenen hedefleri değiştirme, davranışı denetleme, maliyeti ilişkilendirme ve bir model güncellemesi regresyonlara neden olduğunda güvenli bir şekilde geri alma yeteneğini korurken, AI uygulamaları için uygulamalara kararlı model adları vermektir.

AI modeli takma adı nedir?

AI modeli takma adı, daha somut bir model hedefine çözümlenen bir addır. Takma ad, sağlayıcıya, bir yönlendiriciye, dahili bir ağ geçidine veya tek bir uygulama ekibine ait olabilir.

Sağlayıcı takma adı, model sağlayıcı tarafından kontrol edilir. Aile düzeyindeki model, latest varyantı veya kullanışlı takma ad gibi adlar, sağlayıcı yeni anlık görüntüler yayınladıkça zaman içinde değişebilir. Sağlayıcı takma adları, geçiş işini azalttığı ve iyileştirmeleri otomatik olarak algılayabildiği için kullanışlıdır. Bunlar, tekrarlanabilirlik garantileriyle aynı değildir.

Anlık görüntü veya sürüm kimliği, daha spesifik bir model tanımlayıcıdır. Sağlayıcılar farklı adlandırma sistemleri kullanır, ancak amaç aynıdır: Sürümü değiştirilmiş bir ad genellikle hareketli bir takma addan daha az değişir. Anlık görüntünün sabitlenmesi olaylar, değerlendirmeler ve düzenlenmiş iş akışları sırasında davranışların karşılaştırılmasını kolaylaştırabilir. Bu yine de modelin sonsuza kadar var olacağı anlamına gelmez; sağlayıcılar, hem takma adlar hem de sürümlendirilmiş modeller için kullanımdan kaldırma ve kullanımdan kaldırma planları yayınlar.

Dahili bir model takma adı, uygulamanıza, platformunuza veya ağ geçidinize aittir. Örnekler arasında chat-default, support-fast, coding-deep, extract-json-strict, summarizer-cheap veya vision-review yer alır. Uygulama kodu dahili adı gönderir ve çözümleyici bunu bir sağlayıcıya, somut model kimliğine, sürüme, uç noktaya, kimlik bilgisi moduna, bölgeye ve politika paketine eşler.

Çözümlenmiş bir model kaydı, şu soruya istek zamanında verilen yanıttır: Bu çağrıyı gerçekte ne gerçekleştirdi? İstenen takma adı, sağlayıcıyı, model kimliğini veya sürümünü, uç nokta ailesini, geri dönüş denemelerini, fiyatlandırma kataloğu sürümünü, politika kararını ve son kullanımı içermelidir. Çözümlenmiş kayıt olmadan, bir takma ad, hata ayıklama ve maliyet analizi için gereken ayrıntıları gizler.

Takma adlar neden var?

Takma adlar var çünkü model seçimi, uygulama kodunun olması gerekenden daha hızlı değişiyor. Bir ürün ekibi support-fast adının aylarca sabit kalmasını isteyebilir, platform ekibi ise bunun altındaki daha ucuz, daha hızlı veya daha kaliteli hedefleri değerlendirir. Bir arka plan çıkarma işi, deterministik yapılandırılmış çıktıya ve sürüm sabitlemeye ihtiyaç duyabilir. Tüketici sohbeti deneyimi, yeniden dağıtım gerektirmeden kalite iyileştirmeleri alan, hareketli bir sağlayıcı takma adından yararlanabilir.

Aynı kuruluş, her iki modele de aynı anda ihtiyaç duyabilir. Müşteriyle yüz yüze görüşen bir asistan chat-default'ı arayabilir. Bir kodlama iş akışı coding-deep'ı çağırabilir. Düşük riskli bir özetleme işi summarizer-cheap'ı çağırabilir. Uyumluluk açısından hassas bir iş akışı, regulated-review-v1 üzerinden sabitlenmiş bir model anlık görüntüsünü çağırabilir. Uygulamanın sağlayıcıya özel her model adını, fiyat katmanını, yedek kuralını veya kullanımdan kaldırılma tarihini bilmesi gerekmemelidir.

Takma adlar aynı zamanda çok modelli sistemlerin çalıştırılmasını da kolaylaştırır.OpenAI uyumlu bir ağ geçidi birçok model için tek bir istek şeklini kabul ederse, takma adlar uygulamaların istikrarlı bir model sözleşmesi kullanmasına izin verirken ağ geçidi sağlayıcıya özel kimlikleri, model listelemeyi, ayrıntıları, faturalandırmayı, kullanım analizlerini ve ekip düzeyindeki kontrolleri yönetir. OpenAI SDK uyumlu bir ağ geçidi planlayan ekipler, uygulamaların ham sağlayıcı kimlikleri göndermeye devam edip etmeyeceğine veya açık çözümleyici kurallarına sahip dahili takma adlara mı geçeceğine erkenden karar vermelidir.

Sağlayıcı takma adları, anlık görüntüler ve dahili takma adlar

Sağlayıcı takma adları

Sağlayıcı takma adları, yukarı akış sağlayıcısı tarafından tutulan kullanışlı adlardır. Otomatik yükseltmeler istediğinizde ve kesin tekrarlanabilirliğe ihtiyaç duymadığınızda kullanışlıdırlar. Sağlayıcı, en son takma adın bir model ailesindeki en yeni sürümü izlediğini veya önizleme takma adının sürümden sonra kararlı bir sürüme yönlendirdiğini belgeleyebilir.

Operasyonel risk, sağlayıcının destek modelini değiştirdikten sonra aynı isteğin farklı davranışlara neden olabilmesidir. Kalite artabilir ancak gecikme, maliyet, güvenlik davranışı, JSON güvenilirliği, araç çağırma davranışı veya reddetme kalıpları da değişebilir. Bu, bazı iş yükleri için kabul edilebilir, bazıları için ise kabul edilemez.

Anlık görüntü ve sürüm kimlikleri

Anlık görüntü veya sürüm kimlikleri, tutarlılık önemli olduğunda daha iyidir. Değerlendirmeler, yasal incelemeler, mali analizler, tıbbi triyaj desteği, yapılandırılmış çıkarımlar ve vakaların çoğaltılması genellikle istikrarlı bir hedefe ihtiyaç duyar. Sabitleme ayrıca yeni modeli tanıtımdan önce eski modelle karşılaştırmayı da kolaylaştırır.

Sabitleme, yaşam döngüsü yönetiminin yerine geçmez. Sağlayıcılar yine de anlık görüntüleri kullanımdan kaldırabilir. Sabitlenmiş bir modelin bir sahibi, geçiş tarihi, yedek adayları ve emeklilik bildirimlerini izleme özelliği bulunmalıdır. Her modelin sonsuza kadar sabitlenmesi farklı bir hata modu oluşturur: eski modeller birikir, maliyetler düşer ve yükseltmeler acil işler haline gelir.

Dahili takma adlar

Dahili model takma adları, uygulama ekiplerine sağlayıcının pazarlama etiketleri yerine iş yükü amacına uygun adlar verir. extract-json-strict gibi bir ad, sözleşme hakkında best-model'den daha fazlasını anlatır. support-fast gibi bir adı yönetmek, beş hizmete yerleştirilmiş ham sağlayıcı dizesinden daha kolaydır.

En güçlü dahili takma adlar, bir yetenek sözleşmesini tanımlar. Hangi uç noktalara izin verildiğini, akışın desteklenip desteklenmediğini, araç çağrılarının desteklenip desteklenmediğini, JSON şema çıktısının beklenip beklenmediğini, görüntüye veya sese izin verilip verilmediğini, hangi bağlam penceresinin varsayıldığını, hangi maksimum çıktı boyutunun güvenli olduğunu, hangi veri saklama kurallarının geçerli olduğunu ve hangi fiyat katmanının kabul edilebilir olduğunu söylüyorlar.

Yapay zeka modeli sürümleri ne zaman sabitlenmeli

Tekrarlanabilirlik, denetlenebilirlik veya uyumluluk otomatikten daha önemli olduğunda AI modeli sürümlerini sabitleyin yükseltmeler. Yaygın görülen durumlar arasında regresyon testleri, değerlendirme temelleri, uyumluluğa duyarlı iş akışları, sözleşmeye bağlı müşteri davranışları, yapılandırılmış çıktı hatları, katı araç çağrısı şemalarına sahip iş akışları ve olay araştırmaları yer alır.

Sabitleme, pratik soruların yanıtlanmasına yardımcı olur. Bilgi istemi mi değişti, yoksa model mi değişti? Maliyet artışı trafik hacminden mi, jeton uzunluğundan mı yoksa yeni çözümlenen hedeften mi kaynaklandı? Geri dönüş modeli farklı bir şema mı üretti? Ekip aynı hedefi kullanarak geçen haftaki başarısızlığı yeniden üretebilir mi?

İş yükünün davranış değişikliklerini karşılayabildiği ve sağlayıcı iyileştirmelerinden yararlanabildiği durumlarda hareketli bir takma ad kullanın. Örnekler arasında keşif amaçlı sohbet, düşük riskli özetleme, beyin fırtınası araçları veya kalite iyileştirmelerinin memnuniyetle karşılandığı ve tam tekrarlanabilirliğin gerekli olmadığı dahili üretkenlik özellikleri yer alır.

Yararlı bir kural, değerlendirme ve üretim açısından kritik bağımlılıkları sabitlemek, ancak düşük riskli iş yüklerini sebepsiz sabitlemekten kaçınmaktır. Taşıma takma adları her istekte çözümlenen hedefleriyle birlikte günlüğe kaydedilmelidir.Aksi takdirde, bir takma adın istendiğini biliyor olabilirsiniz ancak gerçekte hangi modelin trafiğe hizmet ettiğini bilmiyor olabilirsiniz.

Yapay zeka uygulamaları için kararlı model adları nasıl tasarlanır

Kararlı model adları iş yükü odaklı olmalıdır. Bu ay hangi sağlayıcının en iyi olduğunu değil, uygulamanın ne beklediğini açıklamaları gerekir. İyi takma adlar sıkıcı ve spesifiktir: chat-default, support-fast, coding-deep, extract-json-strict, search-grounded-chat, vision-review veya summarizer-cheap.

Kuruluşunuz bu adların ne anlama geldiğini tanımlamadığı sürece best, smart, premium veya gpt-wrapper gibi belirsiz adlardan kaçının. Belirsiz takma adlar politik hale geliyor ve değiştirilmesi zorlaşıyor. Sağlayıcı markalı takma adlar, en iyi hedef başka bir sağlayıcıya değiştiğinde de kötü şekilde eskir.

Bir takma ad nesnesi, takma adı, sahibi, açıklamayı, iş yükü sözleşmesini, izin verilen uç noktaları, giriş ve çıkış yöntemlerini, araç desteğini, bağlam penceresi beklentisini, maliyet katmanını, veri politikasını, mevcut hedefi, önceki hedefi, yaşam döngüsü durumunu ve değişiklik geçmişini içermelidir. Nesne bir veritabanında, yapılandırma deposunda, ağ geçidi kontrol düzleminde veya hizmet kayıt defterinde bulunabilir. Depolama seçimi, takma ad değişikliklerini açık ve denetlenebilir hale getirme disiplininden daha az önemlidir.

Model takma ad yönetimi için çözümleyici modeli

Bir model takma ad çözümleyici, istenen adı somut bir istek hedefine dönüştürür. Küçük bir uygulamada bu bir konfigürasyon haritası olabilir. Daha büyük bir sistemde genellikle dahili bir ağ geçidinin, üçüncü taraf yönlendiricinin veya çok modelli API ağ geçidinin bir parçasıdır.

Güçlü bir çözümleyici akışı genellikle şöyle görünür:

  1. API anahtarının veya kullanıcısının kimliğini doğrulayın.
  2. Kiracıyı, ekibi veya anahtar düzeyi modelini yükleyin profile.
  3. İstenen takma ada izin verildiğini doğrulayın.
  4. Sohbet tamamlamalar, mesajlar, yerleştirmeler, resimler veya toplu iş gibi uç nokta uyumluluğunu kontrol edin.
  5. Araçlar, JSON şema, akış, vizyon, bağlam uzunluğu ve saklama politikası dahil olmak üzere yetenek gereksinimlerini kontrol edin.
  6. Birincil sağlayıcı modelini seçin target.
  7. İlgili olduğunda bütçe kurallarını, kota kontrollerini veya maliyet tavanlarını uygulayın.
  8. Geliş yönündeki isteği gönderin.
  9. Yalnızca hata sınıfı ve politikası buna izin veriyorsa geri dönüş girişiminde bulunun.
  10. İstenen takma adı, çözümlenen hedefi, geri dönüş girişimlerini, fiyatlandırma sürümünü, kullanımı, gecikmeyi ve son durumu kaydedin status.

Model profili, takma adın etrafındaki politika paketidir. İzin verilen takma adları, yedek adayları, harcama tavanlarını, veri saklama gerekliliklerini, araç izinlerini, engellenen sağlayıcıları, bölge kurallarını ve kiracıya özgü geçersiz kılmaları içerebilir. Takma ad yönetiminin adlandırmadan daha fazlası haline geldiği yer burasıdır. Yönlendirme, maliyet, yönetim ve olaylara müdahale için kontrol noktası haline gelir.

Takma adlar ve bütçeler de çözümleyicide buluşmalıdır. Hedef bir sağlayıcı modelinden diğerine değişirse uygulama kodu değişmese bile maliyet davranışı değişebilir. LLM API anahtara göre harcama sınırlarını uygulayan ekipler, yalnızca kolay takma adı değil, somut çözümlenmiş modeli kaydetmek için çözümleyiciye ve kullanım defterine ihtiyaç duyar.

Yedek zincirler ve çözümlenmiş model kayıtları

Yedek zincir, birincil hedef başarısız olduğunda kullanılan uyumlu yedekleme modellerinin veya sağlayıcıların bir listesidir. Geri çekilme; ücret limitleri, kesintiler, geçici sağlayıcı hataları veya politika reddi durumlarında kullanılabilirliği iyileştirebilir.Yedekleme hedefi gerçekten uyumlu değilse, aynı zamanda ince ürün hataları da oluşturabilir.

Benzer adlara veya karşılaştırma konumlarına sahip iki modelin birbirinin yerine kullanılabileceğini varsaymayın. Bir yedek model, farklı araç davranışına, JSON güvenilirliğe, bağlam sınırlarına, güvenlik filtrelerine, veri saklama koşullarına, fiyatlandırmaya, gecikmeye, bölge kullanılabilirliğine veya desteklenen uç noktalara sahip olabilir. extract-json-strict aynı şema davranışını izlemeyen bir modele geri dönerse, model isteği teknik olarak başarılı olsa bile uygulama aşağı yönde başarısız olabilir.

Geri dönüş politikaları, hangi hataların geri dönüşü tetiklediğini, hangi hedeflere izin verildiğini, kullanıcının mı yoksa kiracının mı devre dışı bırakılabileceğini ve kullanımın nasıl ilişkilendirileceğini belirtmelidir. Tek bir takma ad hedefinin hatalarını ayıklamak ve yeniden oluşturmak daha kolaydır. Geri dönüş zinciri daha dayanıklıdır ancak daha az belirleyicidir. Doğru seçim iş yüküne bağlıdır.

Her istek çözümlenmiş bir model kaydı oluşturmalıdır. Kayıt, istenen takma adı, çözümlenen sağlayıcıyı, çözümlenen modeli veya sürümü, uç noktayı, geri dönüş yolunu, politika kontrollerini, belirteç kullanımını, fiyat kataloğu sürümünü, gecikmeyi, hata sınıfını ve son durumu içermelidir. Faturalandırma, analiz, destek, kötüye kullanım incelemesi ve olaya müdahale, ürün adı ile çağrıya hizmet eden somut model arasındaki bu ayrıma bağlıdır.

Takma ad yükseltme ve geri alma

Takma ad yükseltme, bir takma adı çözümlenmiş bir hedeften diğerine değiştirmeye yönelik kontrollü bir süreçtir. Buna bir üretim bağımlılığını değiştirmek gibi davranın. Bir model, geniş kapsamlı karşılaştırmalarda iyileşme gösterebilir ancak istemlerinizde, şemalarınızda, araç çağrılarınızda, gecikme gereksinimlerinizde veya güvenlik beklentilerinizde gerilemeye devam edebilir.

Promosyondan önce göreve özel değerlendirmeler çalıştırın. Regresyon fikstürlerini, yapılandırılmış çıktı kontrollerini, araç çağrısı testlerini, akış davranışını, reddetme davranışını, gecikme eşiklerini ve maliyet karşılaştırmalarını ekleyin. Müşteriye yönelik iş akışları için, yalnızca temiz karşılaştırma istemlerini değil, ürününüzün gördüğü karmaşık girdileri temsil eden gerçek örnekleri de ekleyin.

Kademeli kullanıma sunma, sistem desteklediğinde daha güvenlidir. Ekipler gölge testleriyle başlayabilir, ardından API anahtarlarını, kanarya kiracılarını, yüzde yönlendirmeyi ve son olarak tam terfiyi etkinleştirebilir. Gelişmiş kullanıma sunma mekanizması olmasa bile, bir takma adı değiştirmeden önce yine de kanıta, onaya, geçerlilik süresine ve bir geri alma hedefine ihtiyaç duyabilirsiniz.

Model sürümü geri alma ağ geçidi, yalnızca eski model dizesini geri yükleyen bir düğme değildir. Geri alma, çözümlenen hedefi geri yüklemeli ve ilgili varsayımların hala eşleştiğini doğrulamalıdır: bilgi istemi değişkenleri, araç şemaları, önbelleğe alınmış yanıtlar, değerlendirme temelleri, fiyatlandırma beklentileri, geri dönüş kuralları ve kullanım ilişkilendirmesi. Geri alma kaydı, geri almanın neden gerçekleştiğini, hangi kiracıların etkilendiğini, hangi hedefin geri yüklendiğini ve hangi takip taşıma işleminin gerekli olduğunu belirtmelidir.

Model listeleri, model ayrıntıları ve kullanıcıya yönelik netlik

Ağ geçitleri ve yönlendiriciler, model listesi ve model ayrıntısı uç noktalarını açığa çıkarırken dikkatli olmalıdır. API takma adları kabul ederse yanıtta, öğenin standart bir sağlayıcı modeli mi, ağ geçidine ait bir takma ad mı, sağlayıcıyı hareket ettiren bir takma ad mı yoksa halihazırda çözümlenmiş bir hedef mi olduğu açıkça belirtilmelidir. Bu kavramların karıştırılması, geliştiricilerin aslında hareketli bir takma ad kullanırken istikrarlı bir model varsaymalarına yol açabilir.

Model ayrıntısı yanıtı; yetenekleri, uç nokta desteğini, bağlam penceresini, fiyatlandırma alanlarını, yaşam döngüsü durumunu, sahibini ve adın takma ad olup olmadığını içerebilir. OpenAI-uyumlu bir API'de uyumluluk değerlidir, ancak uyumluluk operasyonel gerçeği silmemelidir. Ağ geçidi sağlayıcıları özetliyorsa, günlüklerin ve analizlerin yine de çözümlenen sağlayıcıyı ve model sürümünü yetkili kullanıcılara sunması gerekir.

Model Gate, OpenAI uyumlu çok modelli API ağ geçidi olarak bu kalıba uyar.Genel yüzeyi, model listeleme ve model ayrıntısı davranışını, OpenAI-uyumlu sohbet tamamlamaları, Anthropic-uyumlu mesajları, faturalandırmayı, API-anahtar yönetimini, kullanım analizlerini, ekip kontrollerini, Telegram entegrasyonlarını ve İş Ortağı API otomasyonunu içerir. Takma ad bilinçli işlemler için pratik değer merkezileştirmedir: ağ geçidi, sağlayıcılar arasındaki model kullanımını ve faturalandırmayı kaydederken uygulamalar istikrarlı istek modellerini kullanabilir. Bu özellikler üründe açıkça belgelenmediği sürece Model Gate'nin tam bir özel takma ad düzenleyicisi, değerlendirme tanıtım iş akışı, canary kullanıma sunma konsolu veya geri alma konsolu sağladığı varsayılmamalıdır.

Faturalandırma, analiz ve denetim gereksinimleri

Faturalandırma ve analiz yalnızca istenen adı depoladığında takma ad yönetimi çöker. chat-default geçen ay bir modele ve bu ay başka bir modele çözümlendiyse, kullanım kontrol panelinin harcama, gecikme, kalite ve olay raporlarını açıklamak için hem takma ada hem de somut çözümlenmiş modele ihtiyacı vardır.

Fiyatlandırma kataloglarının geçerlilik tarihleri ​​olmalıdır. Aynı takma ad zaman içinde farklı bir hedefe çözümlenebilir ve aynı sağlayıcı hedefi fiyatı değiştirebilir. Güvenilir bir defter, her istek için kullanılan fiyatlandırma versiyonunu kaydeder. Bu, birden fazla sağlayıcı, anahtar, ekip veya ürün genelinde merkezi LLM API faturalandırma kullanan ekipler için özellikle önemlidir.

Denetim kayıtları, bir takma adı kimin değiştirdiğini, değişikliğin ne zaman etkili olduğunu, neden değiştiğini, hangi testleri geçtiğini, hangi hedefi değiştirdiğini, hangi geri alma hedefinin mevcut olduğunu ve hangi patlama yarıçapının beklendiğini içermelidir. Takma adlar kiracıya veya ekibe göre değişiklik gösterebiliyorsa denetim günlüğü, her isteğe hangi profilin uygulandığını göstermelidir.

Yaygın hatalar

En yaygın hata, sağlayıcı model kimliklerini uygulama kodu boyunca sabit kodlamaktır. Bu, bir sağlayıcının kullanılabilirliği, fiyatlandırmayı veya adlandırmayı her değiştirdiğinde geçiş işi yaratır. İkinci yaygın hata, latest gibi bir sağlayıcı takma adının veya aile düzeyindeki bir adın tekrarlanabilirlik garantisi olduğunu varsaymaktır. Bu genellikle bir istikrar sözleşmesi değil, uygun bir sözleşmedir.

Diğer bir hata da dahili bir takma adın nedenini, onaylayanı, testleri, önceki hedefi ve geri alma yolunu kaydetmeden değiştirmektir. Sessiz takma ad değişiklikleri kafa karıştırıcı olaylara neden olur çünkü uygulama ekipleri kod değişikliği görmez ve bunların altında model davranışı değişir.

Geri dönüş hataları da yaygındır. Ekipler, arızalar sırasında araç desteğini, şema davranışını, bağlam uzunluğunu, veri politikasını veya fiyatı kontrol etmeden bir modelden diğerine yönlendirme yapar. Yedek, kullanılabilirlikten tasarruf sağlar ancak ürünün anlamını değiştirir.

Son olarak birçok ekip, model takma ad yönetimini bir adlandırma sorunu olarak ele alır. Bu gerçekten bir yaşam döngüsü ve politika sorunudur. Adı arayüzdür. Çözümleyici, günlükler, fiyatlandırma kayıtları, değerlendirmeler ve geri alma planı, arayüzü güvenilir kılan unsurlardır.

İşlem yapılabilir başlangıç ​​noktası

Küçük bir takma ad envanteriyle başlayın. Uygulama kodunda, zamanlanmış işlerde, istem testlerinde, not defterlerinde ve yapılandırmada halihazırda kullanılan her model adını listeleyin. Hangi adların sağlayıcı takma adları, sabitlenmiş sürümler, yönlendirici bilgileri veya dahili adlar olduğunu işaretleyin. Ardından üretim yolları için iş yüküne dayalı birkaç takma ad seçin ve bunları mevcut hedeflerle eşleştirin.

Her takma ad için yetenek sözleşmesini, sahibini, izin verilen uç noktaları, mevcut hedefi, önceki hedefi, geri dönüş politikasını ve yaşam döngüsü durumunu tanımlayın. Agresif değişiklikler yapmadan önce hem istenen takma ad hem de çözümlenen model için istek günlüğü ekleyin. Takma ad kullanımını ve çözümlenmiş kullanımı bir arada görebildiğinizde yükseltme ve geri alma yönetilebilir hale gelir.

Tekrarlanabilirliğin önemli olduğu yerlerde sabitlenmiş sürümleri kullanın. Otomatik iyileştirmelerin kabul edilebilir olduğu yerlerde hareketli takma adlar kullanın. Sağlayıcı yaşam döngüsü izlemesini bir programa uygun tutun. Takma ad değişikliklerini, kanıtlarla ve geri alma planıyla desteklenen üretim değişiklikleri olarak değerlendirin. İyi uygulandığında AI model takma adları, model katmanı gelişmeye devam ederken uygulama kodunun sabit kalmasını sağlar.