On-Premises Yapay Zeka Modelleri İçin Otomatik Canary Deployment

Model yayınlarında mavi-yeşil yaklaşım neden yeterli değil?

Mavi-yeşil ya da rolling update gibi geleneksel yazılım yayın stratejileri deterministik kod için iyi çalışır: geçişten önce doğruluğu testlerle doğrulayabilir, geri alma yaptığınızda da tam olarak önceki davranışa dönebilirsiniz. Yapay zeka modellerinde ise bu varsayım geçerli değildir. Yeni bir model sürümü tüm offline değerlendirmeleri geçse bile üretim trafiğinde ancak gerçek ölçekte fark edilen ince davranış değişiklikleri üretebilir. Bir sınıflandırma modeli uç vakalarda karar sınırını kaydırabilir. Bir dil modeli, belirli prompt kalıplarında biraz daha uzun ya da biraz daha az doğru yanıtlar verebilir. Bu tür gerilemeler ikili değil istatistikseldir ve çoğu zaman ancak gerçek kullanıcı sorgularının dağılımı altında görünür hale gelir.

Canary deployment yaklaşımı bunu, üretim trafiğinin küçük bir yüzdesini yeni model sürümüne yönlendirip çoğunluğu mevcut sürümde tutarak çözer. Canary trafikte izlenen kalite metriklerinin otomatik analizi, yeni sürümün tam üretime alınmasına mı yoksa geri çekilmesine mi karar verir. Böylece offline değerlendirmenin kaçırdığı gerilemeleri, tüm kullanıcı tabanınızı olası kalite düşüşlerine maruz bırakmadan yakalayabilirsiniz.

Canary deployment hattının mimarisi

On-premises bir canary deployment hattının üç temel bileşeni vardır: trafik ayırıcı, metrik toplayıcı ve yayına alma denetleyicisi.

Trafik ayırıcı, inference gateway katmanında yer alır ve isteklerin yapılandırılabilir bir yüzdesini canary model instance'ına yönlendirir. On-premises ekipler bunu genellikle ağırlıklı upstream yönlendirmeyi destekleyen Kong, Envoy veya NGINX gibi API gateway'lerle kurar. Tek bir etkileşim içinde kullanıcıya tutarsız deneyimler yaşatmamak için bu ayrımın kullanıcı ya da oturum bazında deterministik olması gerekir. Kullanıcı kimliği veya oturum belirteci üzerinden yapılan hash tabanlı yönlendirme bunu pratik ve güvenilir biçimde sağlar.

Metrik toplayıcı, hem canary hem de referans model instance'larından kalite sinyalleri toplar. Bu sinyaller iki gruba ayrılır: yanıt gecikmesi, hata oranları, çıktı uzunluğu dağılımları ve güven skorları gibi otomatik metrikler; ayrıca kullanıcı geri bildirimleri, aşağı akış görev başarı oranları veya model çıktısını puanlayan otomatik değerlendiriciler gibi dolaylı kalite metrikleri. Toplayıcı, bu verileri zaman pencerelerine göre bir araya getirerek canary ve referans sürüm arasında karşılaştırır.

Yayına alma denetleyicisi, bu metrik karşılaştırmalarını kullanarak otomatik karar verir. Kritik metrikler için eşikler tanımlar: örneğin canary'nin hata oranı referans sürümü belirlenen marjın üzerinde aşarsa otomatik geri alma başlatılır. Tüm metrikler trafik payı kademeli olarak artırılırken sınırlar içinde kalırsa canary tam üretime alınır. Kubernetes tabanlı ortamlarda Flagger gibi araçlar ya da orkestrasyon platformunuz üzerinde geliştirilmiş özel denetleyiciler bu süreci yönetebilir.

Yapay zeka için canary analizinde doğru metrikleri seçmek

Canary rollout sırasında hangi metrikleri izlediğiniz, gerilemeleri yakalayıp yakalayamayacağınızı belirler. Yapay zeka modelleri için gecikme ve hata oranı gibi standart altyapı metrikleri gereklidir, ama tek başına yeterli değildir. Kullanıcının gerçekten yaşadığı kaliteyi yansıtan kalite odaklı metriklere ihtiyacınız vardır.

Dil modelleri için çıktı entropisini (ani değişimler modelin yanıtlarından daha emin ya da daha az emin hale geldiğini gösterebilir), ret oranlarını (canary modelin referans sürümün yanıtladığı sorguları reddetmesi ya da tam tersi) ve aynı girdiler için canary ile referans yanıtları arasındaki semantik benzerliği izlemeyi düşünün. Yanıtları alaka düzeyi ve tutarlılık gibi ölçütlerle puanlayan hafif bir değerlendirici model kullanmak, ham çıktı istatistiklerinden daha zengin bir sinyal sağlar.

Sınıflandırma ve çıkarma modelleri için sadece toplam doğruluğa bakmayın; üretim verisi üzerinde sınıf bazında precision ve recall metriklerini de izleyin. Toplam doğruluğu %0,5 artırırken kritik bir azınlık sınıfındaki performansı %3 düşüren bir model, toplam metrikler iyileşmiş görünse bile çoğu iş bağlamında bir gerilemedir.

Canary başarı kriterlerini dağıtımdan önce tanımlayın, dağıtım sırasında değil. Bu yaklaşım, sınırda kalan sonuçları sonradan rasyonelleştirme eğilimini azaltır. Hangi metriklerin geçiş için zorunlu, hangilerinin yalnızca bilgilendirici olduğunu önceden belgeleyin; eşikleri de rastgele yüzdelerle değil, üretim metriklerinizin tarihsel oynaklığına göre belirleyin.

Trafiği kademeli artırmak

Trafiğin %5'ine tek seferde çıkan bir canary, gerilemeleri saptamak için sınırlı istatistiksel güç sunar. Kademeli artırma bunu, canary'nin trafik payını aşamalar halinde yükselterek çözer: önce %1, sonra %5, ardından %20, sonra %50 ve en sonunda tam yayına alma. Her aşama minimum bir süre çalışır ve bir sonrakine geçmeden önce tüm kritik metrikleri geçmek zorundadır.

Başlangıçtaki düşük trafik aşaması; çökme, zaman aşımı ya da dramatik biçimde yanlış çıktı üretimi gibi felaket sınıfındaki sorunları yakalar. Orta seviye aşamalar, kalite metrikleri üzerinde istatistiksel karşılaştırma yapabilmek için yeterli hacmi sağlar. Son %50 aşaması ise modelin önbellek katmanları, rate limiter'lar ve ancak yüksek ölçekte ortaya çıkan eşzamanlı istek örüntüleriyle birlikte yük altında da iyi çalıştığını doğrular.

On-premises ortamlar çoğu zaman bulut sistemlerine göre daha düşük toplam trafiğe sahiptir. Bu nedenle her canary aşamasının istatistiksel olarak anlamlı örnekler biriktirebilmesi için daha uzun sürmesi gerekir. Örneğin servisiniz saatte 1.000 istek alıyorsa, %1'lik bir canary sadece saatte 10 istek görür. Güvenilir bir karar verebilmek için ilk aşamada saatlerce beklemeniz gerekebilir. Bunu release planlamasına dahil edin ve rollout takvimini paydaşlarla önceden paylaşın.

Geri alma ve olay yönetimi

Otomatik geri alma, canary deployment yaklaşımını güvenilir kılan emniyet katmanıdır. Kritik bir metrik tanımlı eşiği aştığında, yayına alma denetleyicisi tüm trafiği hemen referans modele geri yönlendirmeli ve ML mühendisliği ekibini uyarmalıdır. Geri alma süreci anlık ve önceden test edilmiş olmalıdır: trafik ayırıcınızın birkaç saniye içinde canary trafiğini %0'a indirebildiğini doğrulayın; bunun dakikalar sürmesini kabul etmeyin.

Geri almadan sonra canary model instance'ını ve ilgili log'ları inceleme için elinizde tutun. Canary başarısızlıklarının yaygın kök nedenleri arasında offline değerlendirmede yakalanmayan eğitim verisi sorunları, eğitim ve serving ortamları arasındaki tokenizer veya preprocessing uyumsuzlukları ve canary'nin eğitim kümesinden farklı GPU tiplerinde çalışmasından kaynaklanan donanıma özgü sayısal farklar bulunur.

Denenen her rollout'u kaydeden bir canary deployment günlüğü tutun: hangi model sürümü denendi, hangi metrikler gözlendi, model tam yayına alındı mı yoksa geri mi çekildi ve geri almalar için kök neden analizi neydi. Bu günlük, offline testleri geçen ama canary analizinde tekrar tekrar başarısız olan modelleri üreten eğitim ya da değerlendirme hattınızdaki sistematik sorunları bulmak açısından son derece değerlidir.

Canary deployment yaklaşımını MLOps iş akışına yerleştirmek

Canary deployment, model yayına alma hattınızda isteğe bağlı bir eklenti değil, standart bir aşama olmalıdır. Bir model offline değerlendirmeyi geçip model registry'nize kaydedildikten sonra sıradaki adım, staging ya da production ortamına otomatik canary deployment olmalıdır. Yayına alma denetleyicisinin verdiği karar da registry'ye geri yazılarak model durumunu, ilişkili metriklerle birlikte, "production" ya da "failed-canary" olarak güncellemelidir.

Birden fazla model çalıştıran ekipler için canary-as-a-service yaklaşımını değerlendirin: Her model ekibi, metriklerini, eşiklerini ve trafik artırma planını bir yapılandırma dosyasında tanımlar; ortak platform ise bu tanımlarla çalışan paylaşılan bir rollout yeteneği sunar. Böylece her ekip kendi özel deployment otomasyonunu sıfırdan kurmak zorunda kalmaz ve organizasyon genelinde tutarlı güvenlik standartları sağlanır. Platform ekibi trafik ayırma ve yayına alma altyapısından sorumlu olurken, model ekipleri kendi kalite metrikleri ve başarı kriterlerinden sorumlu olur.

Canary deployment süreçleri release döngüsünü biraz uzatır, ancak üretim olaylarının maliyetini ciddi biçimde düşürür. Kötü bir model sürümünün iç kullanıcıları, müşterileri ya da aşağı akış otomatik sistemleri etkileyebildiği on-premises yapay zeka platformlarında bu takas açık biçimde canary yaklaşımı lehinedir. Asıl yatırım, yalnızca model yayınları için değil, platformunuzun genelinde işinize yarayacak gözlemlenebilirlik ve otomasyon altyapısınadır.

Öne çıkan görsel: Jahhid Fitrah Alamsyah tarafından Unsplash'ta paylaşılmıştır.