Jupyter notebook kodu üretime nasıl taşınır?

Notebook neden olduğu gibi üretime verilmez?

Notebook keşif için tasarlanmış bir ortamdır. Hücreler sırasız çalıştırılabilir, değişkenler bellekte kalır, bir hücreyi silseniz bile eski değer başka bir hücreyi beslemeye devam eder. Sonuçta çıkan analiz yazarın makinesinde doğru görünür, ama aynı notebook'u başka biri sıfırdan çalıştırdığında farklı bir sonuç ya da hata alabilir.

Üretimde ise kod gözetimsiz, tekrar tekrar ve çoğu zaman başka bir makinede çalışır. Bu yüzden geçiş, kodu kopyalayıp bir betiğe yapıştırmak demek değildir. Notebook'un içine gömülü varsayımları görünür kılmak, bağımlılıkları sabitlemek ve çalışmayı otomatik yürütülebilen, test edilebilen bir akışa çevirmek gerekir.

Geçişin adımları nelerdir?

Sağlıklı bir geçiş genellikle şu sırayla ilerler:

• Notebook'u baştan sona temiz bir çekirdekte çalıştırın. Çalışmıyorsa asıl iş burada başlar: hangi hücre hangisine bağımlı, hangisi artık gereksiz belirleyin.
• Kodu işlevlere ayırın. Veri okuma, temizleme, özellik üretimi, model eğitimi ve değerlendirme ayrı işlevler olsun; her işlevin girdisi ve çıktısı açık olsun.
• İşlevleri notebook'tan çıkarıp bir Python paketine ya da modül klasörüne taşıyın. Notebook'ta yalnızca bu işlevleri çağıran ince bir katman kalsın.
• Sabit yolları, eşik değerlerini ve model ayarlarını koddan ayırıp bir yapılandırma dosyasına alın.
• Bağımlılıkları sürümleriyle birlikte bir kilit dosyasında sabitleyin.
• Testleri yazın ve sürekli entegrasyon hattına bağlayın.
• Çalışmayı bir zamanlayıcıya ya da orkestrasyon aracına verin, çıktıları ve hataları izleyin.

Her adım bir sonrakinin zeminidir. Test yazmadan önce işlevlere ayırmak, orkestrasyondan önce yapılandırmayı ayırmak gibi sıra önemlidir.

Tekrarlanabilirlik nasıl sağlanır?

Tekrarlanabilirlik şu şeylerin birlikte sabitlenmesine dayanır: kod, ortam ve veri. Kod için sürüm kontrol sistemi yeterlidir. Ortam için kütüphane sürümlerini bir kilit dosyasında tutmak, mümkünse çalışma ortamını bir konteyner imajı olarak paketlemek gerekir. Böylece geliştiricinin dizüstü bilgisayarındaki kütüphane sürümü ile sunucudaki sürüm arasındaki fark ortadan kalkar.

Veri tarafı çoğu ekibin atladığı yerdir. Model, eğitim anındaki veri kümesine bağlıdır; veri değişirse sonuç da değişir. Veri kümesine sürüm etiketi vermek, eğitimde kullanılan örneklemin nasıl seçildiğini kodda yazılı hale getirmek ve rastgelelik içeren adımlarda tohum değerini sabitlemek bu sorunu küçültür. Veri sürümleme için DVC gibi araçlar ya da nesne depolamada tarih damgalı klasörler kullanılabilir.

Basit bir sınama: temiz bir makinede, yalnızca depodaki dosyalarla çalışmayı yeniden kurup aynı çıktıyı alıp alamadığınıza bakın. Alamıyorsanız eksik bir varsayım vardır.

Notebook'u koddan nasıl ayırırsınız?

Notebook'u tamamen silmek gerekmez. İyi bir ayrım şudur: kalıcı mantık pakette, keşif ve görselleştirme notebook'ta yaşar. Notebook paketten işlevleri içe aktarır, sonuçları gösterir; hiçbir iş kuralı hücrelerin içinde kalmaz.

Bu ayrımı kolaylaştıran araç türleri vardır. Jupytext gibi araçlar notebook'u düz metin bir betiğe eşleyerek sürüm kontrolünde anlamlı farklar görmenizi sağlar. nbstripout gibi araçlar commit öncesi hücre çıktılarını temizleyerek depoyu şişirmez ve istemeden veri sızdırmaz. Papermill gibi araçlar bir notebook'u parametrelerle ve kod yazmadan çalıştırmaya yarar; geçiş sürecinde ara adım olarak işe yarar, ama kalıcı çözüm olarak paketlenmiş işlevleri tercih etmek daha sağlamdır.

Örneğin bir müşteri kaybı tahmin notebook'unda veri hazırlama hücrelerini bir hazırlama modülüne, model eğitim hücrelerini bir eğitim modülüne taşıyıp notebook'ta yalnızca metrik grafiklerini bırakabilirsiniz.

Test ve kalite kontrol neyi kapsamalı?

Makine öğrenmesi kodunda katmanlı test işe yarar. Birim testleri veri dönüştürme işlevlerinin küçük, elle hazırlanmış örneklerde beklenen çıktıyı verdiğini doğrular. Veri doğrulama testleri girişte gelen verinin şemasını, boş değer oranlarını ve değer aralıklarını kontrol eder; pandera ya da Great Expectations gibi kütüphaneler bu iş için yaygındır. Model davranış testleri ise bilinen birkaç örnekte çıktının makul olduğunu ve metriğin kabul edilen eşiğin altına düşmediğini sınar.

Bu testleri her değişiklikte otomatik çalıştıran bir sürekli entegrasyon hattı kurun. Biçimlendirme ve statik analiz araçlarını commit öncesi kancalara bağlamak, gözden geçirmede stil tartışmasını azaltır.

Modelin doğruluğunu tek seferlik bir sayıyla değil, her eğitimde kaydedilen bir metrik kaydıyla izlemek, sonradan 'bu model neden bir öncekinden kötü' sorusuna yanıt verebilmenizi sağlar.

Üretim hattına taşıma ve operasyon

Kod paketlenip test edildikten sonra iş, ne zaman ve nasıl çalışacağına gelir. Eğitim işi zamanlanmış ya da yeni veri geldiğinde tetiklenen bir iş olabilir; çıkarım ise bir servis ya da toplu iş olarak çalışır. Airflow, Prefect ya da Dagster gibi orkestrasyon araçları adımlar arasındaki bağımlılığı, yeniden denemeyi ve hata bildirimini yönetir. Bulut sağlayıcıların kendi iş akışı hizmetleri de aynı rolü üstlenebilir.

Üretimde izleme ayrı bir sorumluluktur. İşin başarılı bitip bitmediğinin yanında, gelen verinin dağılımının eğitim verisinden uzaklaşıp uzaklaşmadığına ve tahmin kalitesine de bakılır. Bir modelin geri alınabilmesi için önceki sürümün saklanması ve dağıtımın tek komutla geri çevrilebilmesi gerekir.

Bu aşamada veri bilimci ile mühendislik ekibi birlikte çalışır. Net bir devir teslim kontrol listesi, 'bu kod benim değil mühendislikte' türünden sahipsiz kalmayı önler.

Sık yapılan hatalar

• Notebook'u olduğu gibi zamanlayıcıya bağlamak. Çalışır gibi görünür, ama hata olduğunda nerede kırıldığını bulmak zordur.
• Sabit dosya yollarını ve gizli anahtarları koda gömmek. Yollar yapılandırmadan, gizli bilgiler güvenli bir saklama alanından gelmelidir.
• Yalnızca kodu sürümlemek, veriyi ve ortamı unutmak.
• Testi en sona bırakmak. Kod büyüdükten sonra test yazmak, işlevlerin zaten iç içe geçtiği yerde çok pahalıdır.
• Her şeyi bir seferde taşımaya çalışmak. Önce en değerli ve en sık çalışan hattı taşıyıp öğrenilenlerle diğerlerine geçmek daha güvenlidir.
• İzlemeyi atlamak. Model sessizce bozulabilir; kimse bakmıyorsa fark edilmez.

Bu beceriyi Mindset programlarında nerede çalışırsınız?

Notebook'tan Üretime Geçiş Süreçleri eğitimi, deneysel not defteri çalışmalarını üretim koduna taşımak zorunda olan veri bilimciler ve makine öğrenmesi mühendisleri için kurgulanmıştır. Modül başlıkları bu sayfadaki akışla örtüşür: Deneysel Koddan Üretim Koduna, Tekrarlanabilirlik ve Bağımlılık Yönetimi, Test, Kalite ve Otomasyon, Üretim Hattına Taşıma ve Operasyon.

MLOps Mühendisliği Sertifika Programı ise daha geniş bir çerçeve sunar. Modül başlıkları arasında deney takibi ve model versiyonlama, makine öğrenmesi için test ve sürekli entegrasyon, boru hattı orkestrasyonu, model servis mimarileri ve model izleme yer alır. Bir ekibin tek bir kişiye bağımlı kalmadan model teslim edebilmesini hedefleyen kurumsal ekipler için bu başlıklar birlikte düşünülebilir.