MLOps Mimari Diyagramı: Eğitim Verisinden İzlenen Bir Modele

Bir not defterindeki model bir sistem değildir. Hidden Technical Debt in Machine Learning Systems (Sculley ve diğerleri, NeurIPS 2015) makalesindeki ünlü şekil bunu kutularla anlatır: gerçek dünyadaki bir ML sisteminin yalnızca küçük bir kısmı ML kodudur. Geri kalanı veri toplama, özellik çıkarımı, servis, izleme ve bunlar arasındaki tesisattır; üretimdeki sorunlar da oradan çıkar.

MLOps mimari diyagramı geri kalanı çizer. Bu yazı bir dolandırıcılık puanlama modeli için böyle bir diyagram kuruyor, her üretim modelinde bulunan iki döngüyü açıklıyor ve bir model yanlış davrandığında ortaya çıkan soruları yanıtlaması için diyagramda neyin etiketlenmesi gerektiğini listeliyor.

İki döngü ve bir tetikleyici

Her üretim modelinin bir eğitim döngüsü ve bir servis döngüsü vardır:

• Eğitim döngüsü. Veri toplanır, özelliklere dönüştürülür, bir adayı eğitmek için kullanılır, mevcut modelle karşılaştırılır ve kaydedilir.
• Servis döngüsü. Bir istek gelir, özellikler okunur, model onu puanlar ve tahmin kaydedilir.
• Tetikleyici ikisini bağlar. Servis döngüsünün izlenmesi, bir zamanlama ya da yeni veri eğitim döngüsünü yeniden başlatır.

Google'ın MLOps rehberi üç olgunluk düzeyi tanımlar: düzey 0 elle yürütülen bir süreçtir, düzey 1 sürekli eğitim için eğitim hattını otomatikleştirir, düzey 2 de hattın kendisi için CI/CD ekler. Planladığınız düzeyi değil, sahip olduğunuz düzeyi çizin ve elle yapılan adımları işaretleyin.

Eğitim ile servis arasındaki kayma

Bir MLOps diyagramının en sık önlediği hata eğitim-servis kaymasıdır (training-serving skew): bir özelliğin eğitim SQL'inde bir şekilde, servis kodunda başka bir şekilde hesaplanması. Model çevrim dışında iyi, üretimde daha kötü görünür ve kimse nedenini söyleyemez. Aynı Google rehberi, bir özelliğin tek bir tanımı olsun diye deneyler, sürekli eğitim ve çevrim içi servis için tek kaynak olarak bir özellik deposu önerir.

İkinci klasik hata, zaman üzerinden sızıntıdır. Bir ödeme için eğitim satırı, özellik değerlerini bugünkü hâliyle değil, o ödemenin yapıldığı andaki hâliyle kullanmalıdır. Bu "zamanın o anı" (point-in-time) gerekliliğini, özellik deposundan eğitim hattına giden kenarın üzerine yazın.

Örnek: kart ödemeleri için dolandırıcılık puanlaması

Bir ödeme API'si, bir kart ödemesini onaylamadan önce modelden bir dolandırıcılık puanı ister. Tasarım şöyle:

1. Olaylar. Ödeme API'si her ödemeyi Kafka'ya yayımlar. Bir akış işi, son bir saatteki kart başına ödeme sayısı gibi kayan özellikleri çevrim içi bir depoda tutar. Aynı olaylar veri ambarına da düşer.
2. Etiketler. Bir ödemenin dolandırıcılık olup olmadığı, haftalar ya da aylar sonra gelen ters ibrazlardan (chargeback) öğrenilir. Bunlar veri ambarına yüklenir ve özgün ödemelerle birleştirilir.
3. Özellikler. Özellik deposu her özelliği bir kez tanımlar, çevrim dışı değerleri veri ambarından hesaplar ve en güncel değerleri çevrim içi depoya yazar.
4. Eğitim. Orkestre edilen bir hat, zamanın o anına göre bir eğitim kümesi oluşturur, veriyi doğrular, bir aday eğitir, onu aynı değerlendirme kümesinde canlı modelle karşılaştırır ve metrikleriyle birlikte kaydeder.
5. Yayın. Onaylanan bir sürüm puanlama uç noktasına dağıtılır: önce gölge modunda, kararları etkilemeden canlı trafiğin kopyalarını puanlar; sonra trafiğin küçük bir payı için, sonra tamamı için.
6. İzleme. Her puan, özellikleriyle birlikte kaydedilir. İzleme, girdi ve puan dağılımlarını eğitim verisiyle karşılaştırır ve etiketler geldikçe precision ve recall hesaplar. Bir sapma ya da kalite uyarısı yeniden eğitimi başlatır.

Nasıl okunur:

• Üst sıra, eğitim. Ters ibraz etiketleri ve olay geçmişi veri ambarında buluşur. Özellik deposu hat için eğitim kümeleri oluşturur, hat da adayları model kayıt defterine kaydeder.
• Alt sıra, servis. Ödeme API'si olayları Kafka'ya yayımlar ve puanlama uç noktasını eşzamanlı olarak çağırır. Uç nokta özellikleri çevrim içi depodan okur ve her puanı tahmin günlüğüne yazar.
• Kayıt defteri kenarı, bir modelin üretime ulaşmasının tek yoludur: bir not defterinden kopyalanmış bir dosya değil, her zaman onaylanmış bir sürüm.
• Sağ, geri dönüş döngüsü. İzleme, tahminleri ve geç gelen etiketleri okur. Bir sapma ya da kalitedeki bir düşüş, eğitim hattını başlatan bir uyarı üretir.

Neler etiketlenmeli

• Eğitim kümesi kenarında zamanın o anı kuralları.
• Uç noktada ve kayıt defterinde model sürümü ve aşaması.
• Özellik okumaları ve puanlama için gecikme bütçeleri; çünkü ödeme onları bekler.
• Etiket gecikmesi. Etiketler haftalar sürüyorsa bunu belirtin: kaliteyi ne kadar hızlı ölçebileceğinize o karar verir.
• Yeniden eğitim tetikleyicileri: zamanlama, sapma eşiği, veri hacmi.
• Sahipler. Veri, özellikler, modeller ve uç nokta çoğu zaman farklı ekiplere aittir.

Yaygın hatalar

• "ML modeli" adlı tek bir kutu. Olayların başladığı yerleri, yani özellik deposunu, kayıt defterini ve izleme döngüsünü gizler.
• Geri bildirim yolu olmaması. Etiketler hiç geri gelmiyorsa, modelin ne zaman kötüleştiğini kimse bilmez.
• Üretim yolunda not defterleri. Bir model servise yalnızca hat ve kayıt defteri üzerinden ulaşmalıdır.
• Tek bir özelliğin iki uygulaması. "Aynı" değeri farklı hesaplayan eğitim SQL'i ve servis kodu kaymaya yol açar.
• Geri alma olmaması. Önceki sürümü kayıt defterinde tutun ve uç noktanın ona nasıl geri döndüğünü çizin.
• Yalnızca altyapı izlemesi. Model yanlışken gecikme ve hata oranları kusursuz olabilir; girdileri, puanları ve sonuçları da izleyin.

Servis tarafı sıradan bir dağıtık sistem işidir. Kafka tarafını olay güdümlü mimari diyagramı ele alır; erişimle zenginleştirilmiş dil modelleri için de RAG mimari diyagramı indeksleme ve servisi anlatır.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. ML paketinden bir Özellik deposu, kayıt defteri için bir Model ve puanlama için bir Uç nokta ekleyin.
3. Veri paketinden Kafka, bir Veri ambarı, çevrim içi depo için Redis ve tahmin günlüğü için bir Konu ekleyin.
4. DevOps paketinden eğitim için bir İş hattı, model izleme için bir Metrikler düğümü ve yeniden eğitim tetikleyicisi için bir Uyarı ekleyin.
5. Ödeme API'si için C4 Modeli paketinden bir Konteyner, kart ağının ters ibrazları için de bir Harici sistem ekleyin.
6. Bunları bağlayın, her kenarı taşıdığı veriyle etiketleyin ve geç gelen etiketleri ve yeniden eğitim tetikleyicisini kesikli yapın. Yayın adımlarıyla bir Temel paketi Markdown bloğu ekleyin.

Örnek 13 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. MCP üzerinden bağlanan bir yapay zekâ ajanıyla hattı anlatıp düğümleri ona yerleştirtebilir, sonra etiketleri düzenleyebilirsiniz.

SSS

Bir özellik deposuna ihtiyacım var mı? İlk gün değil. İhtiyacınız olan, hem eğitimin hem de servisin kullandığı özellik başına tek bir tanımdır. Birden fazla model özellik paylaştığında ya da çevrim içi taze özelliklere ihtiyaç duyduğunuzda, bunu sağlamanın olağan yolu bir özellik deposudur.

Model kayıt defteri ile artefakt deposu arasındaki fark nedir? Artefakt deposu dosyaları tutar. Kayıt defteri bunlara sürümler, metrikler, köken bilgisi ve bir onay durumu ekler; böylece dağıtım adımı bir dosya yolu yerine onaylanmış sürümü isteyebilir.

Bir model ne sıklıkla yeniden eğitilmeli? Veri, önemli ölçüde değiştiği sıklıkta. Bir zamanlamayla başlayın, izleme yerine oturunca sapma ve kalite tetikleyicileri ekleyin ve her yeniden eğitimin neden çalıştığını kaydedin.

Etiketler geç geldiğinde bir modeli nasıl izlerim? Şu anda görebildiklerinizi izleyin: girdi dağılımları, puan dağılımları ve işaretlenen ödemelerin payı. Precision ve recall'u etiketler gelince hesaplayın. İki yolu da çizin.

Eğitim ve servis aynı altyapıyı paylaşmalı mı? Özellik tanımlarını ve kayıt defterini paylaşabilirler, ama yük profilleri farklıdır. Onları özellik deposunda ve kayıt defterinde buluşan ayrı yollar olarak çizin.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.