Model geçiş işlemi

Bu makale, LLM destekli bir iş yükünü bir temel modelden diğerine taşımaya yönelik altı aşamalı bir süreci açıklamaktadır: her aşamada nelerin dikkate alınması gerektiği, hangi Microsoft Foundry özelliklerinin geçerli olduğu ve yapılacak işin farklı ekip türleri için nasıl değiştiği.

Model geçişinin anlamı

Üretimde çalıştırdığınız her modelin kullanımdan kaldırma tarihi vardır. Bağımlı olduğunuz bir model değiştirildiğinde veya daha yeni bir model iş yükünüz için daha iyi hizmet verecekse geçiş yaparsınız. Modeli değiştirmek tek satırlık bir değişiklik değildir: Farklı bir model sessizce ton, biçimlendirme, JSON şekli, gecikme süresi, maliyet veya araç çağırma davranışı kaydırabilir ve eski davranışa bağlı olan aşağı akış kodunu kırabilir.

Başarılı bir geçiş, uygulamanın davranışını korur veya ölçülebilir yollarla geliştirir. Başarılı olmak için kaymayı algılamak, güvenli bir şekilde uyum sağlamak ve geniş bir dağıtımdan önce kaliteyi kanıtlamak için tekrarlanabilir bir süreç gerekir.

Ne zaman geçilmeli?

Geçiş genellikle dört nedenden biriyle başlar:

  • Bir model emekli oluyor. Foundry'de genel kullanıma sunulan her model kullanımdan kaldırma tarihiyle birlikte gelir ve yaşlı aileler zaman içinde değiştirilir. Kullanımdan kaldırılma politikası ve tarihleri için Foundry Models yaşam döngüsü ve destek politikası ile Model kullanımdan kaldırılma takvimi'ne bakın.
  • Daha iyi bir model kullanılabilir. Daha yeni bir model daha yüksek kalite, daha düşük maliyet, daha iyi gecikme süresi veya iş yükünüzün ihtiyaç duyduğu bir özellik (yapılandırılmış çıkış veya geliştirilmiş araç çağrısı gibi) sunar.
  • Maliyet veya gecikme süresi sorunu bir değişikliği zorlar. Geçerli modelin gecikme süresi veya birim maliyeti artık gereksinimlerinizi karşılamıyor.
  • Yetenek boşluğu ürünü engeller. Geçerli model artık ürününüzün gerektirdiği bir şeyi yapamaz.

Kullanımdan kaldırma tarihinde ne olur?

Model kullanımdan çıktığında Azure ne yaptığı, kapasiteyi nasıl satın almanıza bağlıdır ve Foundry her yol için farklı terminoloji kullanır:

  • Standart, Genel Standart ve Veri Bölgesi Standart (kullandıkça öde) dağıtımları, bölgeye göre sıralı bir zamanlamayla otomatik olarak yükseltilir . Zamanlamayı, versionUpgradeOption değerini şu seçeneklerden birine ayarlayarak denetleyebilirsiniz: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired veya NoAutoUpgrade (bu, dağıtımın kullanımdan kaldırıldığında çalışmayı durduracağı anlamına gelir). Öncelik İşleme aynı yolu izler.
  • Sağlanan (PTU) dağıtımlar otomatik olarak yükseltilmiyor . Bunları kendiniz taşırsınız; bunu ya yerinde (trafik, kesinti süresi olmadan 20–30 dakikalık bir zaman aralığında taşınır) ya da yan yana (yeni dağıtımı ayağa kaldırın, test edin, trafiği aktarın, eskisini silin) yaparsınız.
  • Toplu dağıtımlar paralel geçiş yaklaşımını izler: yeni modeli dağıtın, görevleri yeniden gönderin, eski dağıtımı kullanımdan kaldırın.

Hangi yol geçerli olursa olsun, geliştirici sınaması aynıdır: belirli bir tarihte trafiğiniz farklı bir modele çarpmaya başlar. Hala yanıt veren bir uç nokta, uygulamanızın hala düzgün davrandığı anlamına gelmez, bu nedenle hem otomatik yükseltilen hem de el ile geçirilen iş yükleri bu makalede açıklanan değerlendirme ve doğrulamadan yararlanıyor.

Kullanımdan kaldırma tarihinden önce geçiş yapın

Otomatik yükseltme, bir geçiş planı değil, yalnızca kullandıkça öde modeliyle yapılan dağıtımlar için bir emniyet mekanizmasıdır. Önceden sağlanan dağıtımlar için bir koruma mekanizması yoktur. Her iki durumda da, geçiş planının yerine geçmez. İki ilke taahhüdü, son tarihi beklemek yerine kendi zamanlamanıza göre geçiş yapmak için size yer sağlar:

  • Yerine geçecek model, Global Standard'da kullanımdan kaldırılmadan yaklaşık 90 gün önce ve önceki modelin kullanımdan kaldırıldığı ayrılmış bölgelerde kullanımdan kaldırılmadan yaklaşık 30 gün önce kullanılabilir hale gelir. Bu pencereyi, yeni modeli değerlendirmek ve taşıma işlemini el ile gerçekleştirmek için kullanın.
  • Kullanımdan kaldırma tarihleri uzatılamaz. Özel durum işlemi olmadığından planlamadığınız bir tarih sizin için geçerli olmaya devam eder.

Başlamak için kullanımdan kaldırma bildirimi gerekmez. Daha yeni bir model daha ucuz, daha hızlı veya daha yetenekliyse, onu hemen süreçten geçirin. Bilinçli bir geçiş, kullanımdan kaldırma tarihini yalnızca bir formalite hâline getirir. Geçişler yinelendiği için işlemi yinelenebilir hale getirmek faydalı olur.

Geçiş işlemini kimler kullanmalıdır?

Geçiş süreci; ekibinizin daha büyük bir ürün veya platform içinde LLM destekli bir özellik geliştirdiği, yaklaşık üç ayda bir geçiş yaptığı ve her geçişi bilinçli bir şekilde yöneten açıkça belirlenmiş bir sorumlunun (örneğin merkezi bir platform ekibi veya uygulama ekibi) bulunduğu durumlarda en iyi sonucu verir.

Bu işlem, modelin ürün olduğu yapay zekaya özel ekiplere de uygundur. Aşamalar aynıdır, ancak katı dizi yerine daha hızlı ve genellikle paralel çalışır.

Bu işlem, ağırlık düzeyinde özelleştirme olmadan, yani model kataloğunda yayımlandığı şekliyle dağıttığınız temel modeller arasında geçiş yaptığınızı varsayar. hassas ayarlı iş yükleri kapsam dışındadır. Kendi eğitim ve dağıtım için kullanımdan kaldırılma zaman çizelgelerine sahip olduklarından, otomatik olarak yükseltilemezler. hassas ayarlı iş yüklerini uyarlamak, istem ve şema değişiklikleri yerine damıtma veya yeniden eğitim anlamına gelir. İnce ayar yapılmış dağıtımlar kullanıyorsanız, yerine geçecek temel modeli temel alarak yeniden ince ayar yapmayı erken aşamada planlayın.

Geçiş aşamaları

Geçiş altı aşamadan geçer. Her aşama, sonraki aşamanın kullandığı bir çıkış oluşturur. Geçiş aşamaları şunlardır:

Keşfet → Değerlendir → Uyarla → Doğrula → Kullanıma sun → Kullanımdan kaldır

Bulma, Değerlendirme, Uyarlama, Doğrulama, Kullanıma Sunma ve Kullanımdan Kaldırma işlemlerini saat yönünde düzenlenmiş olarak gösteren altı aşamalı model geçiş işleminin döngüsel diyagramı.

Aşağıdaki tabloda her aşama ve onu destekleyen Foundry özellikleri ve araçları açıklanmaktadır. Özellikler, Yalnızca Foundry olarak işaretlenmedikçe hem Microsoft Foundry'de hem de Azure OpenAI'da kullanılabilir; bu da Azure OpenAI'da eşdeğerinin olmadığı anlamına gelir.

Bu makalenin devamında yer alan aşama başına bölümler, her aşamanın neden mevcut olduğunu, başarılı bir sonucun nasıl göründüğünü, nelerin dikkate alınacağı, her özelliğin ne zaman kullanılacağı ve aşamanın sık sık nerede kırıldığı açıklanmaktadır.

Phase Description Özellikler ve araçlar
Keşfetmek Model değişikliğinin geldiğini veya gerekli olduğunu öğrenin ve harekete geçmek isteyip istemediğinize karar verin.
Değerlendirmek Hedef modeli seçin ve kullanıma hazır olduğunu onaylayın.
Uyarlayın Yeni modelde geçerli iş yükünü yeniden yürüterek davranış değişikliklerini tanılayın ve istemleri, parametreleri, araç tanımlarını, çıkış şemalarını ve bunların etrafındaki çağrı kodunu yeniden mühendislikleyin.
Doğrulama Uyarlanmış iş yükünü bir kalite puanlama anahtarına göre puanlayın ve göndermenin güvenli olup olmadığına karar verin.
Yayınla Kademeli sunumla üretime alın, canlı davranışı izleyin ve değişiklikleri kalıcılaştırın ya da geri alın.
Kullanımdan Kaldır Eski dağıtımı devreden çıkarın, kapasiteyi serbest bırakın, değerlendirmeleri arşivleyin ve sonraki süreçlerde kullanılan dokümantasyonu güncelleyin.

Geçirmeden önce: Test veri kümesi hazırlama

Bu hazırlık adımı, herhangi bir geçiş çalışması başlamadan önce bir dizi temsili girişi, beklenen çıkışları ve üzerinde anlaşmaya varılan başarı ölçütlerini bir araya toplar. Bu küme, sürecin orta kısmı için kapı niteliğinde bir bağımlılıktır: girdiler olmadan Uyarlama aşamasında yeniden oynatma yapamazsınız ve gerçek referans verileri ile ölçütler olmadan Doğrulama aşamasında puanlama yapamazsınız.

Dikkat edilmesi gerekenler

  • Hedef seçmeden önce veri kümesini oluşturun. Veri kümesi, aday modeli değil, iş yükünüzü tanımlar; bu nedenle onu Discover ile paralel olarak oluşturabilirsiniz.
  • Gerçek veya sentetik kaynaklardan girdileri toplayın. Yakalanan üretim trafiğini veya seçilmiş etki alanı örneklerini CSV veya JSONL olarak kullanın. Henüz temsili verileriniz olmadığında Simülatör ile yapay ve saldırgan girişler oluşturun.
  • İhtiyacınız olmadan önce izleme aleti yakalama. Üretim içeriğinin yakalanması isteğe bağlıdır ve hiçbir zaman geriye dönük olarak uygulanmaz; bu nedenle kaydetmediğiniz trafiği değerlendiremezsiniz. Şimdi istemleri, yanıtları, gecikme süresini ve belirteç sayılarını günlüğe kaydetmeye başlayın.
  • Veri kümesini dondurma. Girişleri, temel bilgileri ve başarı ölçütlerini tüm geçiş için sabit tutun. Bunlardan herhangi biri değişirse, artık kaynak ve hedef sonuçlarını karşılaştıramazsınız.

Ayrıca, iş yükünüzün kullandığı model dağıtımlarının bir envanterini de (Standart, Sağlanan veya Batch) içeren bir envantere ihtiyacınız vardır. Her kaynak model için kullanımdan kaldırma tarihini ve Model kullanımdan kaldırma zamanlamasından önerilen değiştirmeyi not edin.

1. Aşama: Keşif

Keşif aşamasının amacı, model değişikliğinin yaklaştığını veya buna değeceğini tanımak ve harekete geçmek isteyip istemediğinize karar vermektir. Çıkış bir go/no-go kararıdır ve geçerli modelde kalmak geçerli bir seçimdir. Başarılı bir sonuç, kullanımdan kaldırma tarihi, değiştirme modeli ve geçiş penceresi ya da geçerli modelde kalmak için kasıtlı bir karar veren erken, yapılandırılmış bir sinyaldir.

Dikkat edilmesi gerekenler

  • Kullanımdan kaldırma tarihi nedir ve gerçekten ne kadar pistiniz var? Kullanımdan kaldırma tarihinden doğrulama ve dağıtım sürenizi çıkardıktan sonra kalan süreyi gerçek son tarih olarak kabul edin.
  • Önerilen adlandırılmış bir değiştirme var mı yoksa adayları kendiniz kısa listeye eklemeniz mi gerekiyor?
  • Değişiklik uyumluluk veya bölgesel kısıtlamalar taşıyor mu (düzenlenen iş yükleri için, kullanılabilirlik ve sertifikasyon genellikle kaliteden önce önemlidir)?

Sık sık kırıldığı yer

Ekipler bir e-posta, portal başlığı veya dahili bir ileti aracılığıyla tutarsız bir şekilde kullanımdan kaldırma işlemleri hakkında bilgi edinerek sinyalin geç olduğunu fark eder. Bu gecikme, zaten dar olan bir pencereyi kısaltır. Solo geliştiriciler ve küçük ekipler, bir özelliğin kullanımdan kaldırıldığını çoğu zaman bir duyurudan değil, canlı ortamda ortaya çıkan bir hatadan fark eder.

Ne getirdiniz?

Kullanımdan kaldırma takvimi ve Modeller API’si, verileri kararlı bir sözleşme kapsamında erişime sunar. Olgun kuruluşlar, doğru sahiplere yönlendirmek için üzerine ince bir iç bildirim katmanı ekler.

2. Aşama: Değerlendirme

Değerlendirme aşamasının amacı, aday hedef modeli seçmek ve onu çalıştırabileceğinizi doğrulamaktır: doğru bölge, doğru dağıtım türü, yeterli kota ve geri dönüşün mümkün kalması için mevcut modelle birlikte kullanılabilir olması. Başarılı bir sonuç, ince ayar başlamadan önce bölge, SKU, kota ve maliyetin doğrulandığı aday modeller arasından açık bir seçim yapılmasıdır.

Dikkat edilmesi gerekenler

  • Adaylar arasında kalite ve konum belirleme. Birden fazla model kullanımdayken, yalnızca herkese açık bir kıyaslamada en yüksek puanı alanı değil, kalite açısından iş yükünüze en uygun olanı seçin.
  • Kendi trafiğinizin maliyeti. Fiyatlandırma yapısı model nesilleri arasında değişir. Yönetim belirteçleri, önbelleğe alınan giriş ve yapılandırılmış çıkış ek yükü birim ekonomisini 2 kat veya daha fazla artırabileceğinden, yalnızca liste fiyatı yerine geçmiş trafik üzerinde aylık maliyet yansıtılır.
  • İşletimsel kullanılabilirlik. Bölgeyi, SKU’yu ve kotayı doğrulayın; ayrıca geri dönüş yolunu korumak için hedefin kaynakla paralel olarak çalışabildiğini de doğrulayın.
  • Uyumluluk denetimi. Düzenlemeye tabi iş yükleri için sertifikasyon ve bölgesel kullanılabilirlik, kalite değerlendirmesi başlamadan önce aday listesini filtreleyebilir.

Sık sık kırıldığı yer

Birkaç adayın konum belirlemesi belirsiz olduğunda seçim paralizisi ortaya çıkar. Ekipler, ancak planlama sürecinin ortasında, seçilen modelin kendi bölgelerinde veya SKU’larında mevcut olmadığını fark eder. Ya da maliyet projeksiyonu, yeni modelin gerçek trafikte çok daha pahalı olduğunu ortaya koyuyor.

Ne getirdiniz?

Karşılaştırmalar genel veri kümelerinde hesaplanır, bu nedenle puan tablosunu bitiş çizgisi yerine filtre olarak değerlendirin ve kendi iş yükünüz için kısa listeyi onaylayın. Maliyet projeksiyonunda da durum aynıdır: aylık görünüm, kendi token kayıtlarınızdan elde edilir; trafik verileriniz olduğunda bunu hesaplamak oldukça kolaydır.

3. Aşama: Uyarlama

Uyarlama aşamasının amacı, iş yükünün yeni modelde düzgün çalışmasını sağlamaktır. Önce mevcut iş yükünü değiştirmeden yeniden yürüt (model temelli davranış değişikliklerini yalıtmak için), neyin kaydırıldığını tanılayın ve yinelemeli olarak yeniden mühendislik yapın. Başarılı bir sonuç, her değişikliğin izlendiği gerçek veya temsili trafikle yan yana yapılan bir davranış karşılaştırmasıdır.

Uyarlama, istem düzenlemeden daha fazlasıdır

İstemler en görünür kısımdır, ancak bir geçiş genellikle diğer dört alanı da etkiler:

  • Parameters.temperature, top_p, max_tokensve reasoning-effort denetimleri nesiller arasında bire bir eşlenmez ve daha yeni model aileleri bazı parametreleri desteklemeyebilir.
  • Araç tanımları. Eski modeli güvenilir biçimde yönlendiren argüman adlarını, açıklamaları ve zorunlu alanları yeniden ifade etmeniz veya netleştirmeniz gerekebilir.
  • Çıkış şemaları. Modeller, yapılandırılmış çıkışa nasıl uyduklarına göre farklılık gösterir. Bir şemaya eski modelin gevşek bir şekilde yerine getirmesi için açık kısıtlamalar eklemeniz gerekebilir veya sonunda bir şemayı zorunlu kılabilirsiniz.
  • Çağrı kodu. API kapsamı ve SDK farkları (Chat Completions ile Responses, akış yapısı ve yeni veya yeniden adlandırılmış istek alanları). Ayrıca eski yanıt şeklinin varsayıldığı aşağı akış ayrıştırma işlemini de güncelleştirmeniz gerekebilir.

Ajan tabanlı ve iş akışı iş yüklerinde, şema ve araç çağrısı ile ilgili çalışmalar çoğu zaman istem çalışmalarından daha baskındır.

Dikkat edilmesi gerekenler

  • Ayarlamadan önce değiştirmeden yeniden oynat. Geçerli yapılandırmanızı herhangi bir değişiklik yapmadan hedef modelde çalıştırın. Bu yaklaşım , modelin değiştirdiği davranışı , eklediğiniz değişikliklerden ayırmanıza yardımcı olur ve size bir temel sağlar.
  • Gerçekte nelerin kaydığını izleyin. Ayrıntı düzeyi, mantık derinliği, yapılandırılmış çıkış uyumluluğu, araç çağrısı şekli, reddetme davranışı ve gecikme süresi varyansı yaygın olarak değişir.
  • Araç çağrısı regresyonlarını yakalamak için gerçek izleri yeniden oynatın. Ek alanlar, yeniden adlandırılmış argümanlar ve değişen sıralama yalnızca gerçek izlerde ortaya çıkar; tek turlu kıyaslamalarda değil.
  • Değişikliklerinizi izleyin. Prompt yeniden tasarımı yapmak kolaydır, ancak aynı derecede kolayca kaybedilebilir. Özgün öğeyi koruyun ve nelerin değiştiğini ve nedenini kaydedin.

Dökümhane özellikleri

Üç Dökümhane özelliği bu aşamayı destekler:

  • Prompt Optimizer, Agent playground’da sistem yönergeleri alanının hemen altındaki İyileştir düğmesidir. Komut istemi mühendisliği en iyi yöntemlerini kullanarak yönergelerinizi yeniden yapılandırırken, her değişiklik için paragraf başına mantığı gösterir ve yineleme döngüsünü destekler: "JSON şemasını tam olarak koru" ve yeniden iyileştirme gibi bir öneri ekleyin. Yalnızca Foundry'de kullanılabilir, Azure OpenAI'da kullanılamaz.
  • Aracı iyileştirmesi , aracı iş yükleri için yönergeleri, araçları ve model seçimini birlikte ayarlar. Yalnızca Foundry'de kullanılabilir, Azure OpenAI'da kullanılamaz.
  • Simülatör , yeniden yürütülecek üretim verileriniz olmadığında yapay ve saldırgan girişler oluşturur.

Sık sık kırıldığı yer

Katıştırılmış, ürüne yönelik iş yükleri için bu aşama genellikle en çok zaman alır çünkü tanılama döngüsü el ile gerçekleştirilir: ekipler istemleri yeniden çalıştırır, farklılıkları karşılaştırır ve neleri değiştirdiklerini veya nedenlerini nadiren kaydeder.

Ne getirdiniz?

  • Optimizasyon araçlarıyla başlayın, ardından doğrulayın. Veri kümenize uydurmak yerine tek bir geçişte genel en iyi yöntemleri uygular ve araç tanımları veya çıkış şemaları yerine yönerge metnini ayarlarlar. Çıkışı güçlü bir taslak olarak değerlendirin: önce özgün isteminizi kopyalayın (sürüm geçmişi yoktur), ardından değişikliğe güvenmeden önce donmuş veri kümenizde yeniden değerlendirin.
  • Aileler arası hareketler için ekstra uygulamalı iş planlayın. "Hedef model X için iyileştirme" akışı olmadığından model aileleri arasında hareket etmek için kasıtlı istem ve şema çevirisi gerekir.
  • İhtiyacınız olmadan önce trafiği kaydedin. Yeniden oynatma yalnızca yakalamanızın kalitesi kadar iyidir ve içerik yakalama isteğe bağlıdır ve asla geriye dönük olarak uygulanmaz.

4. Aşama: Doğrulama

Doğrulama aşamasının amacı, uyarlanmış iş yükünün, seçilen bir veri kümesindeki kalite puanlama anahtarına göre puanlayarak güvenli bir şekilde gönderilip göndermeyeceğine karar vermektir. Değerlendirme ölçütü kural tabanlı, referans tabanlı, değerlendirici olarak LLM kullanan, insan incelemesine dayalı veya alana özgü bir çerçeve olabilir. Başarılı bir sonuç, hem uygulama ekibinin hem de gözden geçirenlerin inandığı, dondurulmuş bir veri kümesinde çalıştırılacak güvenilir bir değerlendirme paketi sunmaktır.

Doğrulama bir aşamadır, ancak iki dokunma noktası vardır, bu nedenle bunu tek bir satır sonu olayı olarak değerlendirmayın:

  • Erken hazırlanın. Veri kümesini ve başarı kriterlerini Geçiş yapmadan önce, Uyarlamadan önce dondurun. Bunlar değiştiği anda kaynağınız ve hedefiniz karşılaştırılabilir olmayı durdurur.
  • Kapı gecikmesi, iki geçişte. İlk olarak geçerli modeli dondurulan kümede çalıştırarak bir kaynak taban çizgisi (aşmanız gereken sayı) oluşturun. Ardından hedefi aynı ölçütlere göre puanlayın ve karar verin.

Dikkat edilmesi gerekenler

  • Veri kümesini ve ölçütleri dondurulmuş tutun. Bu, sonuçları karşılaştırılabilir hale getirme sürecindeki en önemli tek uzmanlık alanıdır.
  • İmzalamayla eşleşen üç boyutu ölçün: kalite (değerlendirici veya gözden geçiren puanları), gecikme süresi (geçirdiğiniz çağrıya göre yalıtılmış belirteç ve işleme süresi) ve maliyet (istek başına giriş ve çıkış belirteci maliyeti).
  • Ölçütü iş yüküyle eşleştirin. Klinik özetleme rubriği, aracılar için araç çağrısı sıralamasına ilişkin bir doğrulama veya mevcut kullanıcı geri bildirimi sinyalleri, genel bir puandan daha anlamlı olabilir.
  • Geçidi yapay zekaya özel ekipler için bir sinyal olarak değerlendirin. Değerlendirme, tek seferlik bir geçti/kaldı değerlendirmesi olmak yerine sürekli çalışır, her kod gönderiminde yürütülür ve Rollout ile bütünleşir.

Dökümhane özellikleri

İki Dökümhane özelliği bu aşamayı destekler:

  • Azure Yapay Zeka Değerlendirme SDK'sı, temellendirme, ilgili olma, geri getirme, tutarlılık, akıcılık, referans tabanlı ölçümler (F1, BLEU ve ROUGE), güvenlik, ajan ve Azure OpenAI puanlayıcıları dahil olmak üzere 30'dan fazla yerleşik değerlendirici içerir. Ayrıca göreve özel değerlendirme ölçütleri için özel bir LLM-as-judge içerir.
  • Portal değerlendirmesi model, aracı, veri kümesi ve izleme hedefleri üzerinde aynı değerlendiricileri çalıştırır.

Sayıların karşılaştırılabilir olması için aynı değerlendirici kümesini dondurulan veri kümesinde hem kaynak hem de hedef üzerinde çalıştırın.

Dimension Ölçülecek şeyler Where
Quality Kaynak metin ve hedef metne göre değerlendirici puanları Azure AI Değerlendirme SDK'sı, portal değerlendirmesi
Latency İlk belirteç ve aktarım hızına kadar olan süre Karşılaştırma puan tablosu, operasyonel ölçümler
Cost İstek başına giriş ve çıkış belirteci maliyeti Değerlendirme çıkışları, model fiyatlandırması

Sık sık kırıldığı yer

Çoğu ekibin değerlendirme paketi yoktur ve genellikle bunu kendileri oluşturur. Düzenlemeye tabi iş yükleri için, zorunlu bir insan veya kalite yönetimi incelemesi bunun üstüne eklenir ve darboğaz haline gelir. Bu geçişler Adapt’ta değil, Validate’te takılı kalır.

Ne getirdiniz?

Değerlendiriciler çalışmaya hazırdır, ancak kendi üretim trafiğinizden etki alanıyla ilgili bir test kümesi seçmek, model (aracı olmayan) iş yükleri için uygulamalı bir çalışmadır. İşte bu yüzden hazırlık adımı kendini amorti eder.

5. Aşama: Dağıtım

Bu aşamanın amacı, doğrulanmış yapılandırmayı üretim aşamasına yükseltmektir: önce üretim dışı, sonra bir kanarya veya ağırlıklı yüzde, sonra daha geniş pozlama. Süreç boyunca, gerçek zamanlı gecikmeyi, hataları ve ideal olarak kaliteyi geçiş öncesi başlangıç düzeyine göre izleyin. Ardından onaylayın veya geri alın. Başarılı bir sonuç; trafiğin kanarya, ağırlıklı veya gölge trafik yoluyla aşamalı olarak yönlendirilmesi, gecikme ve hata metriklerinin ötesinde canlı bir kalite sinyali ve korunmuş bir geri dönüş yoludur.

Dikkat edilmesi gerekenler

  • Dağıtım türünüzü bilin. Dağıtım türünüz mekanikleri belirler: Standart aile dağıtımları, sizin denetlediğiniz bir zamanlamaya göre otomatik olarak yükseltilebilir. Sağlanmış, toplu iş ve ince ayarlanmış dağıtımlar manuel olarak taşınır. Aşağıdaki tabloda türe göre mekanik gösterilmektedir.
  • Geri dönüş koridorunu koru. Emin olana kadar eski dağıtımı erişilebilir durumda tutun. Kanıta dayalı olmak yerine kullanımdan kaldırma için belirlenen son tarih nedeniyle alınan geri alma kararları, çok geç başladığınızın bir uyarı işaretidir.
  • Kanarya kullanamıyorsanız gölge veya yansıtma modunu kullanın. Düzenlenen akışlar (PHI, finansal işlemler) genellikle yeni bir modeli gerçek müşteri trafiğine sunmaz. Eşdeğeri, yeni modeli üretim girişlerinde çevrimdışı çalıştırmak ve çıkışları kullanıcıları etkilemeden eski modelle karşılaştırmaktır.
  • Çevrimdışı değerlendirmenin gözden kaçırdığı regresyonlara dikkat edin. Gerçek kullanıcı gecikmesi ve uç durum davranışı yalnızca üretim ortamındaki yük altında ortaya çıkabilir.

Dağıtım türüne göre geçiş mekaniği

Dağıtım türü Geçiş yaklaşımı Quota
Standart, Genel Standart, Veri Bölgesi Standardı Sıralı bir zamanlamaya göre otomatik yükseltme. (OnceNewDefaultVersionAvailable, OnceCurrentVersionExpiredveya NoAutoUpgrade) ile versionUpgradeOption zamanlama denetimi Öncelik İşleme aynı yolu izler. Otomatik olarak devreder
Sağlandı Manuel: yerinde (trafik 20-30 dakikalık bir zaman diliminde aktarılır) veya yan yana (yeni dağıtım, trafiği yeni ortama yönlendirme, eski olanı silme). Önce hedef model kotasının mevcut olduğundan emin olun
Batch Paralel olarak: yeni modeli dağıtın, işleri yeniden gönderin, ardından eski dağıtımı kullanımdan kaldırın. Hedef model için kotayı sağlayın
İnce ayar yapılmış (bu makalenin kapsamı dışında) Otomatik olarak yükseltilmez; eğitim ve dağıtım için kullanımdan kaldırma süresi ayrı işler. Yedek taban modeline yeniden ayarlayın veya damıtın. Hedef model için kotayı sağlayın

Trafik yönlendirildikten sonra, üretim trafiğinin örneklenmiş bir yüzdesini puanlamak için, kök neden analizi amacıyla izlere bağlanan Foundry Observability panosunda sürekli değerlendirmeyi yapılandırın; ayrıca kalite düştüğünde Azure İzleyici uyarılarını da ayarlayın.

Sık sık kırıldığı yer

Çevrimdışı değerlendirmenin eksik olduğu kalite regresyonları üretim yükü altında görünür. Geri alma kararları genellikle kanıtlara değil, kullanımdan kaldırma için belirlenen son tarihe dayanır; bu da geçiş sürecine çok geç başlandığının bir işaretidir.

Ne getirdiniz?

İki dağıtım arasındaki ağırlıklı yönlendirme, kendi ağ geçidinizde veya uygulama katmanınızda uygulanır; geri dönüş aralığı ise eski dağıtımı belirli bir süre boyunca hazır durumda tutmak için yapılan bilinçli bir tercihtir (gömülü sistem ekipleri genellikle yaklaşık 30 gün ister). Her ikisini de bir kez tasarlayıp her geçişte yeniden kullanmaya değer.

6. Aşama: Kullanımdan kaldırma

Kullanımdan Kaldırma aşamasının amacı eski dağıtımı devreden çıkarmak, kapasiteyi serbest bırakmak, değerlendirme artefaktlarını arşivlemek ve değişikliği, saklanmasının gerekli olduğu durumlarda, müşteriyle paylaşılan dokümantasyona, pazarlama sayfalarına, destek runbook'larına ve denetim günlüklerine aşağı akışta iletmektir. Sonunda eski dağıtım ortadan kalkar, dağıtım sayısı düşüş eğilimi gösterir ve çıkarılan dersler bir sonraki döngüye aktarılır.

Dikkat edilmesi gerekenler

  • Emekliliği yalnızca temizlik olarak değil idare olarak ele alma. Düzenlenen iş yükleri için bekletme yükümlülükleri, yapıtların yıllar boyunca saklanmasını gerektirebilir.
  • Kaynağın gerçekten artık mevcut olmadığını doğrulayın. Eski sürümün kullanımdan kaldırıldığından emin olun ve ardından dağıtımı silip kapasiteyi tüketmeyi durdurmasını sağlayın.
  • Öğrenilenleri ileriye taşıyın. Üretimden gelen yeni izleri altın veri kümenize geri dahil edin; böylece bir sonraki geçiş daha düşük maliyetle başlar.

Sık sık kırıldığı yer

Ekipler kullanımdan kaldırmayı atlar; bu da zombi dağıtımların birikmesine yol açar. Aktif olarak kullanımdan kaldırma yapmayan ekipler, benzer ekiplerden çok daha fazla aktif dağıtıma sahiptir ve bu adedin büyük kısmı önceki geçişlerden kalan yapısal kalıntılardan oluşur. Sıkça gözden kaçan bir alt adım iletişimdir: pazarlama ve ürün belgeleri, değişiklikten sonra hâlâ eski modele atıfta bulunur.

Ne getirdiniz?

Gözlemlenebilirlik panosu, dağıtım sayısının düşüş gösterdiğini gösterir, ancak hangi dağıtımların hala yük taşıdığına karar vermek ekibinizin yaptığı bir karardır. Kullanımdan kaldırmayı bir umut olmaktan çıkarıp açıkça takip edilen bir görev haline getirin.

Geçiş nadiren ikilidir

Gerçek geçişler genellikle bölünmüş durumdur: Gecikmeye duyarlı veya daha yüksek riskli bir yol bazen haftalarca eski modelde kalırken iş yükünün bir bölümü yeni modelde çalışır. Eski modelden yeni modele tek seferde geçiş yerine, kademeli dağıtım ve kademeli geri dönüş planlayın. Devreden çıkarma genellikle kullanıma sunmanın haftalar veya aylar gerisinden gelir ve ortada kalan bu eski dağıtımlar dağınıklık olarak ortaya çıkar.

İlgili içerik

  • Son güncelleştirme: