MLflow ile deney takibi: ne kaydedilir, nasıl karşılaştırılır, nerede hata yapılır

Deney takibi neden gerekir?

Bir model üzerinde çalışırken çok sayıda küçük karar verilir: hangi veri dilimi, hangi özellikler, hangi öğrenme oranı, hangi kod sürümü. Bunlar kaydedilmezse haftalar sonra en yüksek skoru veren modeli yeniden üretmek ya da neden iyi olduğunu açıklamak mümkün olmaz. Defter, tablo hesabı ya da dosya adlarına gömülmüş notlar ekip büyüdüğünde dağılır.

Deney takibi, her eğitim çalıştırmasının girdilerini ve çıktılarını sistematik biçimde kaydetmektir. Amaç, geçmişteki herhangi bir sonucu açıklayabilmek, farklı çalıştırmaları adil biçimde karşılaştırabilmek ve seçilen modeli yeniden üretebilmektir. Örneğin bir kredi riski ekibinde yeni özelliğin gerçekten fayda sağladığını göstermek için, aynı veri bölünmesiyle yapılmış önceki ve sonraki çalıştırmaları yan yana koymak gerekir. Kayıt yoksa bu karşılaştırma tahmine dayanır.

MLflow Tracking'in temel kavramları

MLflow'un resmî belgeleri Tracking bileşenini, makine öğrenmesi kodunun girdi ve çıktılarını sonradan incelenebilmesi için kaydeden yapı olarak tanımlar. Temel kavramlar şunlardır: • Run: kodun bir çalıştırması, örneğin eğitim betiğinin bir kez koşturulması. Her run başlangıç ve bitiş zamanı, parametreler, metrikler ve artefaktlar taşır. • Experiment: aynı göreve ait run'ların grubu. • Parametre: eğitim öncesinde seçilen ayarlar, örneğin öğrenme oranı. • Metrik: sonuçları ölçen değerler, örneğin doğrulama kaybı; adım bazlı kaydedilebilir. • Artefakt: model ağırlıkları, grafikler, veri dosyaları gibi çıktı dosyaları; artefakt deposunda saklanır. • Dataset: eğitimde kullanılan veri hakkındaki üst bilgi.

Belgelere göre kod içinde mlflow.start_run ile run açılır, mlflow.log_param ve mlflow.log_metric ile değerler yazılır, mlflow.set_experiment ile deney seçilir. mlflow.autolog ise açık kayıt satırları yazmadan metrik, parametre ve model kaydı yapabilir.

Adım adım: bir eğitim betiğine takip eklemek

Mevcut bir eğitim betiğine takip eklemek genellikle küçük bir değişikliktir. Şu sıra izlenebilir: • Önce deney adını belirleyin; görev başına bir deney, run'ları anlamlı grupta tutar. • Eğitimi bir run bloğunun içine alın. • Sonuçları etkileyen her ayarı parametre olarak kaydedin: model türü, hiperparametreler, veri bölünme biçimi, rastgele tohum. • Eğitim sırasında metrikleri adım bazında, bitişte ise doğrulama ve test metriklerini ayrı adlarla kaydedin. • Modeli, önemli grafikleri (karışıklık matrisi gibi) ve gerekiyorsa özellik listesini artefakt olarak ekleyin. • Kodun hangi sürümle çalıştığını ve hangi veri anlık görüntüsünün kullanıldığını bir etiket ya da veri kaydı olarak belirtin.

İlk denemede otomatik kayıt işe yarar; neyin kaydedildiğini görürsünüz. Ardından kritik değerleri elle de kaydetmek iyi bir alışkanlıktır, çünkü otomatik kayıt sizin iş kuralınıza özgü metrikleri bilemez. Örneğin yanlış negatiflerin maliyetine göre ağırlıklandırılmış bir skor sizin tanımınızdır ve açıkça kaydedilmelidir.

Deneyleri karşılaştırmak ve doğru sonuca varmak

Kayıt tutmak yetmez; karşılaştırma disiplini gerekir. Arayüzde run'lar metriğe göre sıralanabilir, parametre değişimlerine göre süzülebilir ve grafikle yan yana konabilir. Ancak aynı metrik farklı veri bölünmeleriyle ölçüldüyse karşılaştırma yanıltıcıdır. Bu nedenle değerlendirme veri kümesi ve bölünme yöntemi sabit tutulmalı, hangi değerin değiştiği bilinmelidir.

İyi bir karşılaştırma pratiği şunları içerir: • Her seferinde yalnız bir şeyi değiştirmek; aksi halde farkın nedeni anlaşılmaz. • Rastgelelik taşıyan eğitimlerde birden çok tohumla tekrarlamak ve dağılımı görmek. • Seçim ölçütünü önceden belirlemek; sonuçlara bakıp ölçütü değiştirmemek. • Test kümesine yalnız son adımda bakmak; deney sırasında doğrulama kümesi kullanmak.

Programatik olarak da run'ları aramak mümkündür; belgeler MlflowClient.search_runs gibi arayüzleri anlatır. Bu, en yüksek skorlu run'ı otomatik seçip bir sonraki adıma, örneğin model kaydına taşımak için kullanılır.

Modelden kayda: Model Registry ve soy ağacı

Deney takibi eğitim aşamasını kapsar; seçilen modelin yaşam döngüsü ise ayrı bir sorudur. MLflow belgeleri Model Registry kavramını ve models URI biçimlerini anlatır: bir modelin sürümleri kaydedilir ve her sürüm onu üreten run'a bağlanır. Eski anlatımlarda sık görülen Staging ve Production gibi aşamalar (stage) belgelere göre kullanımdan kaldırıldı. Yerine sürümlere takma ad (alias) vermek önerilir: örneğin canlı trafiğe hizmet eden sürüme champion adı verilir, yeni sürüm onaylanınca aynı ad o sürüme taşınır ve servis kodu değişmez. Sürümün doğrulama durumu gibi bilgiler etiketlerle tutulur; ortamları ve yetkileri ayırmak için ise her ortam için ayrı kayıtlı model kullanılabilir. Bu, üretime çıkan modelin hangi run'dan geldiğini, hangi veri ve hangi kodla eğitildiğini bulmayı mümkün kılar.

Bu bağlantıya soy ağacı (lineage) denir. Üretimde bir sorun çıktığında ya da denetim sorusu geldiğinde, modelden geriye doğru eğitim run'ına, oradan veriye ve koda ulaşabilmek büyük zaman kazandırır. Ekip büyüdükçe merkezi bir izleme sunucusu, erişim kuralları ve kayıt adlandırma standardı da gerekir. Weights & Biases gibi alternatif araçlar benzer sorunu çözer; kavramlar aynı kalır: run, metrik, artefakt, karşılaştırma ve raporlama. Aracı değiştirseniz de disiplin taşınır.

Sık yapılan hatalar

Deney takibinde en sık karşılaşılan sorunlar şunlardır: • Yalnız sonuç metriğini kaydetmek. Parametre, veri ve kod bilgisi olmayan metrik, yeniden üretilemeyen bir sayıdır. • Anlamsız run adları ve etiketsiz deneyler. Birkaç hafta sonra hangi run'ın ne denediği anlaşılmaz. • Her şeyi tek deneyde toplamak. Görevler karışır, arama zorlaşır. • Büyük dosyaları gelişigüzel artefakt olarak yüklemek; depolama şişer ve gerekli olan bulunamaz. • Doğrulama ve test metriklerini aynı adla kaydetmek; hangisine bakıldığı bilinmez. • Başarısız run'ları silmek. Neyin işe yaramadığı da bilgidir. • Rastgele tohumu ve ortam sürümlerini kaydetmemek; sonuç yeniden üretilemez. • Kişisel dizüstü bilgisayarda yerel kayıt tutup ekiple paylaşmamak.

Bu hatalar araçla değil, kayıt alışkanlığıyla ilgilidir. Ekip düzeyinde bir adlandırma ve etiket sözleşmesi bu sorunların büyük bölümünü önler.

Öğrenme yolu

Başlangıç için yerel bir MLflow kurulumu ve basit bir sınıflandırma modeli yeterlidir. Önce otomatik kayıtla bir run üretin, arayüzde parametre ve metrikleri inceleyin. Sonra aynı betiği farklı hiperparametrelerle çalıştırıp run'ları karşılaştırın. Ardından kendi metriğinizi ve artefaktlarınızı elle kaydedin.

İleri aşamada paylaşımlı bir izleme sunucusu, model paketleme, Model Registry ile sürüm yönetimi, değerlendirme kayıtları ve dağıtım entegrasyonuna geçin. Hiperparametre taraması yapıyorsanız tarama sonuçlarını tek bir üst run altında toplamayı öğrenin. Son olarak deney kayıtlarını bir üst veri modeline bağlayıp soy ağacı sorgulamayı deneyin. Bu yolun her aşaması, bir önceki aşamanın alışkanlığını pekiştirir: önce kaydet, sonra karşılaştır, sonra yönet.

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

ML Deney Takibi (Weights & Biases) programı modül başlıklarına göre deney takibi temelleri ve kurulum, metrik kaydı ve görselleştirme, hiperparametre taraması ve karşılaştırma, artefaktlar, raporlama ve ekip kullanımını kapsar. MLflow İleri Seviye programı merkezi MLflow mimarisi, model paketleme ve flavor yapısı, Model Registry ileri kullanımı, değerlendirme ve kalite kayıtları, dağıtım entegrasyonu ile işletme ve yönetişimi işler. ML Metadata ve Deney Yönetimi programı ise metadata modeli, kayıt akışının otomatikleştirilmesi ve soy ağacı sorgulamayı içerir.