Azure Databricks'te MLOps iş akışları

Bu makalede, makine öğrenmesi (ML) sistemlerinizin performansını ve uzun vadeli verimliliğini iyileştirmek için Databricks platformunda MLOps'u nasıl kullanabileceğiniz açıklanmaktadır. MLOps mimarisi için genel öneriler içerir ve DATABricks platformunu kullanarak ML geliştirmeden üretime süreciniz için model olarak kullanabileceğiniz genelleştirilmiş bir iş akışını açıklar.

Daha fazla ayrıntı için bkz . BÜYÜK MLOps Kitabı.

MLOps nedir?

MLOps, kod, veri ve modelleri yönetmeye yönelik bir dizi işlem ve otomatik adımdır. DevOps, DataOps ve ModelOps'ı birleştirir.

Kod, veri ve model gibi ML varlıkları, sıkı erişim sınırlamaları olmayan ve sıkı bir şekilde test edilmeyen erken geliştirme aşamalarından sıkı bir şekilde kontrol edilen son üretim aşamasına kadar ilerleyen aşamalarda geliştirilir. Databricks platformu, birleşik erişim denetimiyle bu varlıkları tek bir platformda yönetmenize olanak tanır. Aynı platformda veri uygulamaları ve ML uygulamaları geliştirerek verilerin taşınmasıyla ilgili riskleri ve gecikmeleri azaltabilirsiniz.

MLOps için genel öneriler

Bu bölüm, daha fazla bilgi için bağlantılar içeren Databricks'te MLOps için bazı genel öneriler içerir.

Her aşama için ayrı bir ortam oluşturma

Yürütme ortamı, modellerin ve verilerin kod tarafından oluşturulduğu veya kullanıldığı yerdir. Her yürütme ortamı işlem örneklerinden, çalışma zamanlarından ve kitaplıklarından ve otomatik işlerden oluşur.

Databricks, aşamalar arasında açıkça tanımlanmış geçişlerle ML kodunun ve model geliştirmenin farklı aşamaları için ayrı ortamlar oluşturulmasını önerir. Bu makalede açıklanan iş akışı, aşamaların ortak adlarını kullanarak bu işlemi izler:

• Geliştirme
• Hazırlama
• Üretim

Kuruluşunuzun belirli gereksinimlerini karşılamak için diğer yapılandırmalar da kullanılabilir.

Erişim denetimi ve sürüm oluşturma

Erişim denetimi ve sürüm oluşturma, herhangi bir yazılım işlemi işleminin temel bileşenleridir. Databricks aşağıdakileri önerir:

• Sürüm denetimi için Git'i kullanın. İşlem hatları ve kod, sürüm denetimi için Git'te depolanmalıdır. Daha sonra ML mantığının aşamalar arasında taşınması, kodu geliştirme dalından hazırlama dalı ile yayın dalı arasında taşıma olarak yorumlanabilir. Databricks Git klasörlerini kullanarak Git sağlayıcınızla tümleştirin ve not defterlerini ve kaynak kodunu Databricks çalışma alanlarıyla eşitleyin. Databricks ayrıca Git tümleştirmesi ve sürüm denetimi için ek araçlar sağlar; Geliştirici araçları ve rehberliğe bakın.
• Delta tablolarını kullanarak verileri göl evi mimarisinde depolayın. Veriler bulut hesabınızdaki bir göl evi mimarisinde depolanmalıdır. Hem ham veriler hem de özellik tabloları, kimlerin okuyup değiştirebileceğini belirlemek için erişim denetimleri olan Delta tabloları olarak depolanmalıdır.
• MLflow ile model geliştirmeyi yönetin. MLflow kullanarak model geliştirme sürecini izleyebilir ve kod anlık görüntülerini, model parametrelerini, ölçümleri ve diğer meta verileri kaydedebilirsiniz.
• Model yaşam döngüsünü yönetmek için Unity Kataloğu'ndaki Modelleri kullanın. Model sürümü oluşturma, idare ve dağıtım durumunu yönetmek için Unity Kataloğu'ndaki Modelleri kullanın.

Modelleri değil kodu dağıtma

Çoğu durumda Databricks, ML geliştirme sürecinde bir ortamdan diğerine model yerine kodu yükseltmenizi önerir. Proje varlıklarının bu şekilde taşınması, ML geliştirme sürecindeki tüm kodların aynı kod gözden geçirme ve tümleştirme testi işlemlerinden geçirilmesini sağlar. Ayrıca modelin üretim sürümünün üretim kodu üzerinde eğitilmesini sağlar. Seçenekler ve dengeler hakkında daha ayrıntılı bir tartışma için bkz . Model dağıtım desenleri.

Önerilen MLOps iş akışı

Aşağıdaki bölümlerde geliştirme, hazırlama ve üretim olmak üzere üç aşamadan her birini kapsayan tipik bir MLOps iş akışı açıklanmaktadır.

Bu bölümde arketik kişilik olarak "veri bilimcisi" ve "ML mühendisi" terimleri kullanılır; MLOps iş akışındaki belirli roller ve sorumluluklar ekipler ve kuruluşlar arasında farklılık gösterir.

Geliştirme aşaması

Geliştirme aşamasının odak noktası denemedir. Veri bilimciler, model performansını iyileştirmek için özellikler ve modeller geliştirir ve denemeler çalıştırır. Geliştirme işleminin çıktısı özellik hesaplaması, model eğitimi, çıkarım ve izleme içerebilen ML işlem hattı kodudur.

Numaralandırılmış adımlar diyagramda gösterilen sayılara karşılık gelir.

1. Veri kaynakları

Geliştirme ortamı, Unity Kataloğu'ndaki geliştirme kataloğuyla temsil edilir. Veri bilimciler geliştirme çalışma alanında geçici veriler ve özellik tabloları oluştururken geliştirme kataloğuna okuma-yazma erişimine sahiptir. Geliştirme aşamasında oluşturulan modeller geliştirme kataloğuna kaydedilir.

İdeal olarak, geliştirme çalışma alanında çalışan veri bilimciler de üretim kataloğundaki üretim verilerine salt okunur erişime sahip olur. Veri bilim adamlarının üretim verilerine, çıkarım tablolarına ve ölçüm tablolarına üretim kataloğunda okuma erişimi sağlaması, mevcut üretim modeli tahminlerini ve performansını analiz etmelerini sağlar. Veri bilimciler de deneme ve analiz için üretim modellerini yükleyebilmelidir.

Üretim kataloğuna salt okunur erişim vermek mümkün değilse, veri bilimcilerinin proje kodu geliştirmesini ve değerlendirmesini sağlamak için geliştirme kataloğuna üretim verilerinin anlık görüntüsü yazılabilir.

2. Keşif veri analizi (EDA)

Veri bilimciler, not defterlerini kullanarak etkileşimli ve yinelemeli bir işlemde verileri inceler ve analiz eder. Amaç, kullanılabilir verilerin iş sorununu çözme potansiyeline sahip olup olmadığını değerlendirmektir. Bu adımda, veri bilimcisi model eğitimi için veri hazırlama ve özellik geliştirme adımlarını belirlemeye başlar. Bu geçici işlem genellikle diğer yürütme ortamlarında dağıtılacak bir işlem hattının parçası değildir.

Databricks AutoML , bir veri kümesi için temel modeller oluşturarak bu işlemi hızlandırır. AutoML, bir dizi deneme gerçekleştirir ve kaydeder ve her deneme çalıştırması için kaynak kodu içeren bir Python not defteri sağlar; böylece kodu gözden geçirebilir, yeniden üretebilir ve değiştirebilirsiniz. AutoML ayrıca veri kümenizdeki özet istatistikleri hesaplar ve bu bilgileri gözden geçirebileceğiniz bir not defterine kaydeder.

3. Kod

Kod deposu, ml projesi için tüm işlem hatlarını, modülleri ve diğer proje dosyalarını içerir. Veri bilimciler, proje deposunun geliştirme ("geliştirme") dalında yeni veya güncelleştirilmiş işlem hatları oluşturur. EDA'dan ve projenin ilk aşamalarından başlayarak, veri bilimcilerinin kodu paylaşmak ve değişiklikleri izlemek için bir depoda çalışması gerekir.

4. Modeli eğitme (geliştirme)

Veri bilimciler geliştirme ortamında geliştirme veya üretim kataloglarındaki tabloları kullanarak model eğitim işlem hattını geliştirir.

Bu işlem hattı 2 görev içerir:

• Eğitim ve ayarlama. Eğitim işlemi model parametrelerini, ölçümlerini ve yapıtlarını MLflow İzleme sunucusuna kaydeder. Hiper parametreleri eğitip ayarladıktan sonra, model, eğitildiği giriş verileri ve bunu oluşturmak için kullanılan kod arasında bir bağlantı kaydetmek için son model yapıtı izleme sunucusuna kaydedilir.

• Değerlendirme. Tutulan verileri test ederek model kalitesini değerlendirin. Bu testlerin sonuçları MLflow İzleme sunucusuna kaydedilir. Değerlendirmenin amacı, yeni geliştirilen modelin geçerli üretim modelinden daha iyi performans gösterip göstermediğini belirlemektir. Yeterli izinler verildiğinde, üretim kataloğuna kayıtlı tüm üretim modelleri geliştirme çalışma alanına yüklenebilir ve yeni eğitilen modelle karşılaştırılabilir.

  Kuruluşunuzun idare gereksinimleri model hakkında ek bilgiler içeriyorsa, MLflow izlemesini kullanarak kaydedebilirsiniz. Tipik yapıtlar, SHAP tarafından oluşturulan çizimler gibi düz metin açıklamaları ve model yorumlarıdır. Belirli idare gereksinimleri bir veri idaresi görevlisinden veya iş paydaşlarından gelebilir.

Model eğitim işlem hattının çıkışı, geliştirme ortamı için MLflow İzleme sunucusunda depolanan bir ML modeli yapıtıdır. İşlem hattı hazırlama veya üretim çalışma alanında yürütülürse, model yapıtı bu çalışma alanının MLflow İzleme sunucusunda depolanır.

Model eğitimi tamamlandığında, modeli Unity Kataloğu'na kaydedin. İşlem hattı kodunuzu modeli, model işlem hattının yürütüldiği ortama karşılık gelen kataloğa kaydedecek şekilde ayarlayın; bu örnekte geliştirme kataloğu.

Önerilen mimariyle, ilk görevin model eğitim işlem hattı ve ardından model doğrulama ve model dağıtım görevleri olduğu çok görevli bir Databricks iş akışı dağıtırsınız. Model eğitim görevi, model doğrulama görevinin kullanabileceği bir model URI'sini verir. Bu URI'yi modele geçirmek için görev değerlerini kullanabilirsiniz.

5. Modeli doğrulama ve dağıtma (geliştirme)

Model eğitim işlem hattına ek olarak, geliştirme ortamında model doğrulama ve model dağıtım işlem hatları gibi diğer işlem hatları da geliştirilir.

• Model doğrulama. Model doğrulama işlem hattı model eğitim işlem hattından model URI'sini alır, Unity Kataloğu'ndan modeli yükler ve doğrulama denetimleri çalıştırır.

  Doğrulama denetimleri bağlama bağlıdır. Biçim ve gerekli meta verileri onaylama gibi temel denetimlerin yanı sıra önceden tanımlanmış uyumluluk denetimleri ve seçilen veri dilimlerindeki model performansını onaylama gibi yüksek düzeyde düzenlenmiş sektörler için gerekli olabilecek daha karmaşık denetimler içerebilir.

  Model doğrulama işlem hattının birincil işlevi, bir modelin dağıtım adımına devam edip etmeyeceğini belirlemektir. Model dağıtım öncesi denetimleri geçerse, Unity Kataloğu'nda "Challenger" diğer adı atanabilir. Denetimler başarısız olursa işlem sona erer. İş akışınızı, kullanıcılara doğrulama hatası bildirecek şekilde yapılandırabilirsiniz. bkz. İş olayları için e-posta ve sistem bildirimleri ekleme.

• Model dağıtımı. Model dağıtım işlem hattı genellikle bir diğer ad güncelleştirmesi kullanarak yeni eğitilen "Challenger" modelini doğrudan "Şampiyon" durumuna yükseltir veya mevcut "Şampiyon" modeli ile yeni "Challenger" modeli arasında bir karşılaştırmayı kolaylaştırır. Bu işlem hattı, Model Sunma uç noktaları gibi gerekli çıkarım altyapısını da ayarlayabilir. Model dağıtım işlem hattında yer alan adımların ayrıntılı bir tartışması için bkz . Üretim.

6. Kodu işleme

Eğitim, doğrulama, dağıtım ve diğer işlem hatları için kod geliştirdikten sonra, veri bilimcisi veya ML mühendisi geliştirme dalı değişikliklerini kaynak denetimine işler.

Hazırlama aşaması

Bu aşamanın odak noktası ML işlem hattı kodunu test etmek ve üretime hazır olduğundan emin olmaktır. Model eğitimi için kod ve özellik mühendisliği işlem hatları, çıkarım kodu vb. dahil olmak üzere ml işlem hattı kodunun tamamı bu aşamada test edilmiştir.

ML mühendisleri, bu aşamada çalıştırılacak birim ve tümleştirme testlerini uygulamak için bir CI işlem hattı oluşturur. Hazırlama işleminin çıktısı, CI/CD sistemini üretim aşamasını başlatmak için tetikleyen bir yayın dalıdır.

1. Veriler

Hazırlama ortamının ML işlem hatlarını test etmek ve modelleri Unity Kataloğu'na kaydetmek için Unity Kataloğu'nda kendi kataloğu olmalıdır. Bu katalog diyagramda "hazırlama" kataloğu olarak gösterilir. Bu kataloğa yazılan varlıklar genellikle geçicidir ve yalnızca test tamamlanana kadar korunur. Geliştirme ortamı, hata ayıklama amacıyla hazırlama kataloğuna erişim de gerektirebilir.

2. Kodu birleştirme

Veri bilimciler geliştirme veya üretim kataloglarındaki tabloları kullanarak geliştirme ortamında model eğitim işlem hattını geliştirir.

• Çekme isteği. Dağıtım işlemi, kaynak denetiminde projenin ana dalında bir çekme isteği oluşturulduğunda başlar.

• Birim testleri (CI). Çekme isteği otomatik olarak kaynak kodu oluşturur ve birim testlerini tetikler. Birim testleri başarısız olursa çekme isteği reddedilir.

  Birim testleri yazılım geliştirme sürecinin bir parçasıdır ve herhangi bir kodun geliştirilmesi sırasında sürekli yürütülür ve kod tabanına eklenir. Birim testlerinin CI işlem hattının bir parçası olarak çalıştırılması, geliştirme dalında yapılan değişikliklerin mevcut işlevselliği bozmamasını sağlar.

3. Tümleştirme testleri (CI)

CI işlemi daha sonra tümleştirme testlerini çalıştırır. Tümleştirme testleri, birlikte düzgün çalıştıklarından emin olmak için tüm işlem hatlarını (özellik mühendisliği, model eğitimi, çıkarım ve izleme dahil) çalıştırır. Hazırlama ortamı, üretim ortamıyla makul olduğu kadar yakın eşleşmelidir.

Bir ML uygulamasını gerçek zamanlı çıkarımla dağıtıyorsanız hazırlama ortamında hizmet verme altyapısı oluşturup test etmelisiniz. Bu, hazırlama ortamında bir sunum uç noktası oluşturan ve bir model yükleyen model dağıtım işlem hattını tetiklemektedir.

Tümleştirme testlerini çalıştırmak için gereken süreyi azaltmak için, bazı adımlar test uygunluğu ile hız veya maliyet arasında denge sağlayabilir. Örneğin, modeller eğitmek pahalıysa veya zaman alıyorsa, küçük veri alt kümeleri kullanabilir veya daha az eğitim yinelemesi çalıştırabilirsiniz. Model sunma için, üretim gereksinimlerine bağlı olarak tümleştirme testlerinde tam ölçekli yük testi yapabilir veya geçici bir uç noktaya yönelik küçük toplu işleri veya istekleri test edebilirsiniz.

4. Hazırlama dalı ile birleştirme

Tüm testler başarılı olursa, yeni kod projenin ana dalı ile birleştirilir. Testler başarısız olursa CI/CD sistemi kullanıcıları bilgilendirmeli ve çekme isteğinde sonuçları göndermelidir.

Ana dalda düzenli tümleştirme testleri zamanlayabilirsiniz. Dalın birden çok kullanıcıdan gelen eşzamanlı çekme istekleriyle sık sık güncelleştirilip güncelleştirilmediğini bu iyi bir fikirdir.

5. Yayın dalı oluşturma

CI testleri geçtikten ve geliştirme dalı ana dala birleştirildikten sonra ML mühendisi, üretim işlerini güncelleştirmek için CI/CD sistemini tetikleyen bir yayın dalı oluşturur.

Üretim aşaması

ML mühendisleri, ML işlem hatlarının dağıtıldığı ve yürütüldüğü üretim ortamına sahiptir. Bu işlem hatları model eğitimini tetikler, yeni model sürümlerini doğrular ve dağıtır, aşağı akış tablolarında veya uygulamalarda tahminler yayımlar ve performans düşüşü ve dengesizliğini önlemek için tüm süreci izler.

Veri bilimciler genellikle üretim ortamında yazma veya işlem erişimine sahip değildir. Ancak test sonuçları, günlükler, model yapıtları, üretim işlem hattı durumu ve izleme tablolarında görünürlüğe sahip olmaları önemlidir. Bu görünürlük, üretimdeki sorunları belirleyip tanılamalarına ve yeni modellerin performansını şu anda üretimde olan modellerle karşılaştırmalarına olanak tanır. Bu amaçlar için veri bilimcilerine üretim kataloğundaki varlıklara salt okunur erişim vekleyebilirsiniz.

Numaralandırılmış adımlar diyagramda gösterilen sayılara karşılık gelir.

1. Modeli eğitin

Bu işlem hattı, kod değişiklikleri veya otomatik yeniden eğitme işleri tarafından tetiklenebilir. Bu adımda, aşağıdaki adımlar için üretim kataloğundaki tablolar kullanılır.

• Eğitim ve ayarlama. Eğitim işlemi sırasında günlükler üretim ortamı MLflow İzleme sunucusuna kaydedilir. Bu günlükler model ölçümlerini, parametreleri, etiketleri ve modelin kendisini içerir. Özellik tabloları kullanıyorsanız model, modeli çıkarım zamanında kullanılan özellik arama bilgileriyle paketleyen Databricks Özellik Deposu istemcisi kullanılarak MLflow'a kaydedilir.

  Geliştirme sırasında veri bilimciler birçok algoritmayı ve hiper parametreyi test edebilir. Üretim eğitim kodunda yalnızca en yüksek performanslı seçeneklerin dikkate alınması yaygındır. Ayarlamayı bu şekilde sınırlamak zaman kazandırır ve otomatik yeniden eğitmede ayarlamanın varyansını azaltabilir.

  Veri bilimciler üretim kataloğuna salt okunur erişime sahipse bir model için en uygun hiper parametre kümesini belirleyebilir. Bu durumda, üretimde dağıtılan model eğitim işlem hattı, genellikle işlem hattına bir yapılandırma dosyası olarak dahil edilen seçili hiper parametre kümesi kullanılarak yürütülebilir.

• Değerlendirme. Model kalitesi, dışarıda tutulan üretim verileri üzerinde test edilip değerlendirilir. Bu testlerin sonuçları MLflow izleme sunucusuna kaydedilir. Bu adım, geliştirme aşamasında veri bilimciler tarafından belirtilen değerlendirme ölçümlerini kullanır. Bu ölçümler özel kod içerebilir.

• Modeli kaydedin. Model eğitimi tamamlandığında model yapıtı, Unity Kataloğu'ndaki üretim kataloğunda belirtilen model yolunda kayıtlı model sürümü olarak kaydedilir. Model eğitim görevi, model doğrulama görevinin kullanabileceği bir model URI'sini verir. Bu URI'yi modele geçirmek için görev değerlerini kullanabilirsiniz.

2. Modeli doğrulama

Bu işlem hattı 1. Adımdaki model URI'sini kullanır ve Unity Kataloğu'ndan modeli yükler. Ardından bir dizi doğrulama denetimi yürütür. Bu denetimler kuruluşunuza ve kullanım örneğine bağlıdır ve temel biçim ve meta veri doğrulamaları, seçili veri dilimlerinde performans değerlendirmeleri ve etiketler veya belgeler için uyumluluk denetimleri gibi kuruluş gereksinimleriyle uyumluluk gibi öğeleri içerebilir.

Model tüm doğrulama denetimlerini başarıyla geçirirse Unity Kataloğu'nda model sürümüne "Challenger" diğer adını atayabilirsiniz. Model tüm doğrulama denetimlerini geçmezse işlemden çıkar ve kullanıcılara otomatik olarak bildirim gönderilebilir. Bu doğrulama denetimlerinin sonucuna bağlı olarak anahtar-değer öznitelikleri eklemek için etiketleri kullanabilirsiniz. Örneğin, "model_validation_status" etiketi oluşturabilir ve testler yürütülürken değeri "BEKLEMEDE" olarak ayarlayabilir ve işlem hattı tamamlandığında "GEÇDİ" veya "BAŞARISIZ" olarak güncelleştirebilirsiniz.

Model Unity Kataloğu'na kayıtlı olduğundan geliştirme ortamında çalışan veri bilimciler, modelin doğrulanamaması durumunda araştırma yapmak için bu model sürümünü üretim kataloğundan yükleyebilir. Sonuçtan bağımsız olarak sonuçlar, model sürümüne yönelik ek açıklamalar kullanılarak üretim kataloğundaki kayıtlı modele kaydedilir.

3. Modeli dağıtma

Doğrulama işlem hattı gibi model dağıtım işlem hattı da kuruluşunuza ve kullanım örneğine bağlıdır. Bu bölümde, yeni doğrulanan modele "Challenger" diğer adını atadığınız ve mevcut üretim modeline "Şampiyon" diğer adı atandığı varsayılır. Yeni modeli dağıtmadan önce ilk adım, en azından geçerli üretim modelinin yanı sıra performans sergilediğini onaylamaktır.

• "CHALLENGER" ile "CHAMPION" modelini karşılaştırın. Bu karşılaştırmayı çevrimdışı veya çevrimiçi olarak gerçekleştirebilirsiniz. Çevrimdışı karşılaştırma, her iki modeli de tutulan bir veri kümesine göre değerlendirir ve MLflow İzleme sunucusunu kullanarak sonuçları izler. Gerçek zamanlı model sunma için, A/B testleri veya yeni modelin aşamalı dağıtımı gibi daha uzun süre çalışan çevrimiçi karşılaştırmalar yapmak isteyebilirsiniz. "Challenger" model sürümü karşılaştırmada daha iyi performans gösterirse, geçerli "Şampiyon" diğer adının yerini alır.

  Databricks Model Sunma ve Databricks Lakehouse İzleme, bir uç nokta için istek ve yanıt verileri içeren çıkarım tablolarını otomatik olarak toplamanıza ve izlemenize olanak sağlar.

  Mevcut bir "Şampiyon" modeli yoksa, "Challenger" modelini iş buluşsal modeliyle veya temel olarak başka bir eşikle karşılaştırabilirsiniz.

  Burada açıklanan işlem tamamen otomatiktir. El ile onay adımları gerekiyorsa, model dağıtım işlem hattından iş akışı bildirimlerini veya CI/CD geri çağrılarını kullanarak bunları ayarlayabilirsiniz.

• Modeli dağıtma. Batch veya akış çıkarım işlem hatları modeli "Şampiyon" diğer adıyla kullanacak şekilde ayarlanabilir. Gerçek zamanlı kullanım örnekleri için modeli REST API uç noktası olarak dağıtmak için altyapıyı ayarlamanız gerekir. Databricks Model Sunum'u kullanarak bu uç noktayı oluşturabilir ve yönetebilirsiniz. Geçerli model için bir uç nokta zaten kullanılıyorsa uç noktayı yeni modelle güncelleştirebilirsiniz. Databricks Model Sunma, yeni yapılandırma hazır olana kadar mevcut yapılandırmayı çalışır durumda tutarak sıfır kapalı kalma süresi güncelleştirmesini yürütür.

4. Model Sunma

Model Sunma uç noktasını yapılandırırken, Unity Kataloğu'nda modelin adını ve kullanıma sunulması gereken sürümü belirtirsiniz. Model sürümü Unity Kataloğu'ndaki tablolardaki özellikler kullanılarak eğitildiyse, model özellikler ve işlevler için bağımlılıkları depolar. Model Sunma, çıkarım zamanında uygun çevrimiçi mağazalardan özellikleri aramak için bu bağımlılık grafiğini otomatik olarak kullanır. Bu yaklaşım, veri ön işleme işlevleri uygulamak veya model puanlaması sırasında isteğe bağlı özellikleri hesaplamak için de kullanılabilir.

Birden çok model içeren tek bir uç nokta oluşturabilir ve bu modeller arasında bölünmüş uç nokta trafiğini belirterek çevrimiçi "Şampiyon" ile "Challenger" karşılaştırmaları gerçekleştirmenizi sağlayabilirsiniz.

5. Çıkarım: toplu iş veya akış

Çıkarım işlem hattı üretim kataloğundan en son verileri okur, isteğe bağlı özellikleri hesaplamak için işlevleri yürütür, "Şampiyon" modelini yükler, verileri puanlar ve tahminler döndürür. Toplu işlem veya akış çıkarımı genellikle daha yüksek aktarım hızı ve daha yüksek gecikme süresi kullanım örnekleri için en uygun maliyetli seçenektir. Düşük gecikme süreli tahminlerin gerekli olduğu ancak tahminlerin çevrimdışı hesaplanabildiği senaryolarda, bu toplu tahminler DynamoDB veya Cosmos DB gibi çevrimiçi bir anahtar-değer deposunda yayımlanabilir.

Unity Kataloğu'ndaki kayıtlı modele diğer adıyla başvurulur. Çıkarım işlem hattı , "Şampiyon" model sürümünü yükleyip uygulayacak şekilde yapılandırılmıştır. "Şampiyon" sürümü yeni bir model sürümüne güncelleştirilirse çıkarım işlem hattı yeni sürümü bir sonraki yürütmesi için otomatik olarak kullanır. Bu şekilde model dağıtım adımı çıkarım işlem hatlarından ayrılmıştır.

Toplu işler genellikle tahminleri üretim kataloğundaki tablolara, düz dosyalara veya bir JDBC bağlantısı üzerinden yayımlar. Akış işleri genellikle Unity Kataloğu tablolarında veya Apache Kafka gibi ileti kuyruklarında tahminler yayımlar.

6. Lakehouse İzleme

Lakehouse İzleme, veri kayması ve model performansı gibi giriş verilerinin ve model tahminlerinin istatistiksel özelliklerini izler. Bu ölçümleri temel alan uyarılar oluşturabilir veya bunları panolarda yayımlayabilirsiniz.

• Veri alımı. Bu işlem hattı toplu iş, akış veya çevrimiçi çıkarımdan günlüklerde okur.
• Doğruluğu ve veri kayma durumunu denetleyin. İşlem hattı giriş verileri, modelin tahminleri ve altyapı performansı hakkındaki ölçümleri hesaplar. Veri bilimciler geliştirme sırasında veri ve model ölçümlerini, ML mühendisleri ise altyapı ölçümlerini belirtir. Lakehouse İzleme ile özel ölçümler de tanımlayabilirsiniz.
• Ölçümleri yayımlayın ve uyarıları ayarlayın. İşlem hattı analiz ve raporlama için üretim kataloğundaki tablolara yazar. Veri bilimciler analize erişebilmesi için bu tabloları geliştirme ortamından okunabilir olacak şekilde yapılandırmanız gerekir. Databricks SQL'i kullanarak model performansını izlemek için izleme panoları oluşturabilir ve ölçüm belirtilen eşiği aştığında bildirim göndermek için izleme işini veya pano aracını ayarlayabilirsiniz.
• Modeli yeniden eğitme tetikleme. Ölçümler performans sorunlarını veya giriş verilerindeki değişiklikleri gösterirken, veri bilimcisinin yeni bir model sürümü geliştirmesi gerekebilir. Bu durum oluştuğunda veri bilimciler için bildirim göndermek için SQL uyarıları ayarlayabilirsiniz.

7. Yeniden eğitme

Bu mimari, yukarıdaki aynı model eğitim işlem hattını kullanarak otomatik yeniden eğitme işlemini destekler. Databricks, zamanlanmış, düzenli olarak yeniden eğitme ile başlayıp gerektiğinde tetiklenen yeniden eğitmeye geçmenizi önerir.

• Zamanlanmış. Düzenli olarak yeni veriler kullanılabiliyorsa model eğitim kodunu kullanılabilir en son verilerde çalıştırmak için zamanlanmış bir iş oluşturabilirsiniz.
• Tetiklenen. İzleme işlem hattı model performansı sorunlarını tanımlayıp uyarılar gönderebiliyorsa, yeniden eğitme işlemini de tetikleyebilir. Örneğin, gelen verilerin dağılımı önemli ölçüde değişirse veya model performansı düşerse, otomatik yeniden eğitme ve yeniden dağıtma en düşük insan müdahalesiyle model performansını artırabilir. Bu, bir ölçümün anormal olup olmadığını denetlemek için SQL uyarısı aracılığıyla elde edilebilir (örneğin, bir eşiğe göre kayma veya model kalitesini denetleme). Uyarı, daha sonra eğitim iş akışını tetikleyebilen bir web kancası hedefi kullanacak şekilde yapılandırılabilir.

Yeniden eğitme işlem hattında veya diğer işlem hatlarında performans sorunları varsa, veri bilimcisinin sorunları çözmek için ek denemeler için geliştirme ortamına dönmesi gerekebilir.