Mars ve Venüs çok farklı gezegenlerdir. Mars'ın atmosferi çok incedir ve çok soğuk olabilir; Venüs'ün atmosferi çok kalın ve çok sıcak olabilir - kurşunu eritecek kadar sıcak !. Yine de onlar bizim en yakın kardeş gezegenlerimizdir. Onların da bir takım benzerlikleri var. Her ikisi de atmosferlerinde yüksek konsantrasyonda karbondioksit içerir ve koruyucu manyetik alan olmaksızın güneş radyasyonuna maruz kalır.
Yazılım Mühendisleri ve Veri Bilimcileri, biri Venüs'ten, diğeri Mars'tan olmak üzere iki farklı dünyadan geliyor. Farklı geçmiş zihniyetleri vardır ve farklı konularla ilgilenirler. Onların da ortak noktaları var. Bu ve sonraki bloglarda, aralarındaki temel farklılıklara (ve benzerliklere) ve bu farklılıkların neden var olduğuna ve bunlar arasında ne tür bir köprü oluşturmamız gerektiğine bakacağız. Bu blogda, yazılım ve modeller arasındaki temel farkları keşfediyoruz.
Geleneksel programlamada, bir bilgisayarın belirli bir yazılım spesifikasyonuna uyan istenen çıktıyı üretmek için girdi verilerini işlemesi için satır satır talimatlar (genellikle bir algoritma olarak adlandırılır) sağlanır. Satır satır talimatlar, Lisp, Prolog, C ++, Java, Python, Julia vb. Gibi birçok bilgisayar dilinden birinde olabilir.
Veri biliminde, girdi verilerini ve bazı durumlarda (örneğin, denetimli makine öğrenimi) girdi verilerindeki kalıpları tanıyan bir model oluşturmak için çıktı verilerinin bir örneğini sağlar. Geleneksel programlamanın aksine, veri bilimi modelleri, kalıpları tanımak veya çıkarımlar yapmak için girdi verileri (veya girdi ve çıktı verileri) sağlayarak eğitilir . Tam eğitildiklerinde, doğrulandıklarında ve test edildiklerinde , yeni veriler üzerinde tahminler veya çıkarımlar yaparlar.
Model, verilere uyacak şekilde uygulanabilen veya kalibre edilebilen resmi bir matematiksel temsildir . Scott Page, bir dizi model örneği ve karar vermek için nasıl kullanıldıklarını sağlar. Modeller makine öğrenimi modelleri, sistem dinamik modelleri, aracı tabanlı modeller, ayrık olay modelleri veya bir dizi başka farklı matematiksel temsil türleri olabilir. Bu yazıda öncelikle makine öğrenimi (ML) modellerine odaklanacağız.
Yazılım ve modeller beş temel boyuta göre farklılık gösterir. Bu boyutlar Şekil 3'te gösterilmektedir.
Yazılımın çıktısı kesindir . Örneğin, bir sayı dizisini sıralamak için bir algoritma (örneğin, bubbleort) düşünün. Baloncuk sıralaması algoritması, girdi olarak bir sayı dizisi alır ve artan veya azalan sıraya göre sıralanmış bir çıktı dizisi üretmek için yinelemeli olarak bir dizi adımdan geçer. Herhangi bir dizi verildiğinde, bubbleort algoritması her zaman çıktı olarak sıralanmış bir dizi üretir. Çıktısında belirsizlik yok. Program doğru bir şekilde test edilmişse, algoritma her zaman sonucu üretecek ve sonuç% 100 doğru olacaktır.
Bunun aksine, çok sayıda resim üzerinde eğitilmiş ve farklı kedi türlerini tanıyabilen bir derin öğrenme modelini ele alalım. Model, bir kedi resmi girdi olarak sağlandığında, modeli kedinin cinsini tahmin etmek için kullanır. Bununla birlikte, her zaman% 100 doğrulukta bir cevap vermeyebilir - aslında, çoğu zaman doğruluk% 100'den az olacaktır. Şekil 3, bir derin öğrenme modelinin girdisini, derin öğrenme ağ katmanlarını ve çıktısını göstermektedir. Model, görüntünün% 45 doğrulukla tekir kedi içerdiğini ve% 23 doğrulukla Mısır kedisi olabileceğini tahmin ediyor. Diğer bir deyişle, modellerden gelen tahminler genellikle belirsizdir. Tahminlerdeki bu belirsizlik, işletmelerin kavraması için zorlu bir kavramdır. Sonraki bir blogda geliştirmeyi modellemek için bu boyutun sonuçlarına geri döneceğiz.
Yazılım ve modeller arasındaki farkın ikinci boyutu, karar alanıdır. Karar alanı ile kastettiğimiz , yazılımın veya modelin karar vermek için kullanıldığı bağlamdır. Yazılım oluşturduğumuzda, genellikle bir algoritma olarak kodlanmış bir spesifikasyona veya bir kullanıcı ihtiyacına sahibiz. Yazılım test edilir ve tam olarak test edildiğinde kullanıma hazırdır. Yazılım, bir sonuç üretmek için çalıştırılır. Bu karar alanı sabittir veya statiktir . Kullanıcının ihtiyaçları değişirse, algoritmanın değiştirilmesi veya yeniden oluşturulması ve test edilmesi gerekir. Algoritmanın kendisini öğreneceğine veya kendisini değiştireceğine dair hiçbir söz yok. Şekil 4, yazılımın nasıl kullanıldığına dair bağlamı gösterir ( Tahmin Makineleri kitabından modellerin nasıl kullanıldığına dair bir uyarlama )
Modeller söz konusu olduğunda karar alanı daha dinamiktir . Akıllı telefonlarla ilgili sorgular için birinci seviye destek sağlamak üzere eğitilmiş, makine öğrenimi tabanlı bir chatbot düşünün. Model eğitildiğinde, farklı akıllı telefonların markası, modeli ve aksesuarları hakkındaki geçmiş verilerle eğitilmiş olacaktı. Sohbet robotu konuşlandırıldıktan sonra piyasadaki tüm akıllı telefonlarda müşteri sorgularını yanıtlayabilecektir. Sohbet botunun sorgulara belirli bir doğruluk düzeyinin ötesinde yanıt veremediğinde, sorguları bir insan müşteri hizmetleri temsilcisine gönderdiğini varsayalım. Böyle bir sohbet robotu birkaç ay boyunca iyi çalışacaktır, ancak piyasaya yeni modeller ve aksesuarlar sunulduğunda, sohbet robotu müşteri sorgularını yanıtlayamayacak ve giderek daha fazla çağrıyı insan temsilcisine aktaracak ve sonunda sohbet botunu oluşturacaktır. Faydasız.
Modeller, geçmiş verilere dayanır ve bu geçmiş veriler artık alakalı olmadığında daha yeni verilerle yenilenmeleri gerekir. Bu, modellerin çalıştığı bağlamı daha dinamik hale getirir. Kullanıcı ihtiyaçları veya yazılım özellikleri de değişebilirken, daha az sıklıkta gerçekleşir. Ayrıca, teknik özellik değiştiğinde yazılımın çalışmaya devam edeceğine dair bir beklenti yoktur. Modeller söz konusu olduğunda, modelin performansı kötüleştiğinde, en azından bu bozulma konusunda (genellikle model sapması olarak adlandırılır) uyarılırız veya en iyi ihtimalle sonuçların ve yeni verilerin sürekli olarak iyileştirmek için kullanıldığına dair açık bir beklenti vardır. model (bu sürekli iyileştirme konusuna şüpheli bir blogda geri döneceğiz). Şekil 5, modellerin nasıl kullanıldığına dair bağlamı göstermektedir. Sonuçtan eğitime kadar olan geri bildirim döngüsüne dikkat edin (kırmızı noktalı çizgiler vurgu için Tahmin Makineleri'ndeki orijinal diyagramdan eklenmiştir ). Modeller için karar alanını daha dinamik hale getiren bu geri bildirim sürecidir.
Geleneksel yazılım tipik olarak tümdengelimli bir çıkarım mekanizması kullanırken, makine öğrenimi modelleri tümevarımlı çıkarıma dayanır. Şekil 6'da gösterildiği gibi, bir yazılım spesifikasyonu, kodun geliştirildiği teori görevi görür. Kod, gözlemlere dayalı teori ile doğrulanması gereken hipotez olarak görülebilir. Gözlemler, spesifikasyona göre tekrarlanması gereken kod tarafından üretilen çıktıdan başka bir şey değildir.
Modeller, gözlemsel verilerden türetilen modellerdir. İlk model, modelin gözlemsel verilere en iyi şekilde uymasını sağlamak için yinelemeli olarak iyileştirilmesi gereken hipotez gibi davranır. Eğitilen model, doğrulandığında verilerin altında yatan teoriyi yakalar. Modelin verilere aşırı veya yetersiz uymamasını sağlamak için yeterli özen gösterilmelidir .
Yazılımın yaptığı gibi teoriden gözleme geçmek, modellerin yaptığı gibi gözlemden teoriye geçmekten tartışmasız daha kolaydır. Bu aynı zamanda, birinci boyutta tartışıldığı gibi çıktının kesinliği / belirsizliği etrafındaki zorluğun altını çizer.
Yazılımın geliştirildiği süreç, modellerin tipik olarak geliştirilme biçiminden temelde farklıdır. Yazılım geliştirme, genellikle bir şelale yaklaşımı veya çevik bir yaklaşım izler . Şelale yaklaşımı, spesifikasyondan tasarıma, kodlamaya, test etmeye ve devreye almaya kadar bir dizi adımdan geçer. Çevik bir yaklaşım söz konusu olduğunda, yazılım geliştirme süreci yinelemelidir ve genellikle kullanıcı ihtiyaçları ve kendi kendini organize eden, işlevler arası ekipler etrafında merkezlenmiş bir dizi ilkeyi içerir. Yazılım genellikle bir ila dört haftalık sprintlerde geliştirilir. Her bir ardışık sprint, kullanıcılara sunulan minimum uygulanabilir bir ürüne yol açan ek işlevselliği kodlar.
Model geliştirme süreci vardır biraz daha farklı bir yaklaşımı takip etmek. Verilerin kullanılabilirliği, kalitesi ve etiketlenmesi ve istenen doğruluğu veya daha genel olarak algoritmanın performansını tahmin etmenin zorluğu, model geliştirmenin bir portföy yaklaşımı benimsemesi gerektiği anlamına gelir. Veri bilimcilerinin bir dizi model geliştirmesi gerekir ve bu modellerin bir alt kümesi performans kriterlerini karşılayabilir. Sonuç olarak, model geliştirme sürecinin, sonraki deneyleri iyileştirmek için daha bilimsel bir deney, test ve bu deneylerden öğrenme sürecini takip etmesi gerekir. Bu hipotez-test-öğrenme süreci, çevik bir yazılım geliştirme yaşam döngüsüne pek uymuyor. Sonraki bir blogda, model geliştirme sürecini ve çevik yaklaşımla nasıl entegre edilebileceğini gözden geçireceğiz.
Şimdiye kadar değindiğimiz dört boyut, yazılım geliştirenlerin ve model geliştirenlerin zihniyetlerini açıkça ayırıyor. Yazılım geliştiriciler tipik olarak bir mühendislik zihniyetine sahiptir - mimari planlar, farklı bileşenler arasındaki bağlantılar üzerinde çalışırlar ve tipik olarak üretim yazılımından sorumludurlar. Yazılım mühendisleri tipik olarak bir bilgisayar bilimi, bilgi teknolojisi veya bilgisayar mühendisliği geçmişine veya eğitimine sahiptir. Verileri oluşturan yazılım ürünleri geliştirirler.
Öte yandan, model geliştiriciler daha bilimsel bir zihniyete sahiptirler - deneyler üzerinde çalışırlar, belirsizlikle başa çıkmada daha iyidirler ve tipik olarak üretim modellerinin aksine inovasyonla ilgilenirler. Bir veri bilimci verileri analiz ve matematiksel modeller geliştirmek için programlama ile matematik ve istatistik arka plan artar kişidir. Öngörüler elde etmek ve sonuçları etkilemek için verileri kullanırlar.
Sonraki bloglarda, kuruluşlarda yazılım ve modellerin nasıl geliştirildiğine ilişkin bu farklılıkların sonuçlarını göreceğiz. Ayrıca model geliştirme sürecine, bunların çevik yazılım geliştirme ile nasıl entegre edilebileceğine ve ModelOps ve MLEngineers gibi yeni rollerin ortaya çıkışına da ayrıntılı olarak bakacağız.
Yazarlar: Anand S. Rao ve Joseph Voyles
Java'da volatile anahtar kelimesini kullandığımızda perde arkasında neler olduğuna ve neden senkronizasyonun yerini tam olarak almadığına kısa bir bakış uçucu anahtar kelime genelinde. Bu anahtar kelime, bir değişkende yapılan herhangi bir değişikliğin diğer ileti dizileri tarafından hemen görülebilmesini sağlamak için kullanılabilir, bu nedenle verilerimizin eski, senkronize olmayan ve yanlış hale gelmesini önlemeye yardımcı olur.
MIT Seçim Laboratuvarı'nda yüksek lisans araştırmacısı ve doktora derecesi olan Jesse Clark tarafından yazılmıştır.
Oakland, CA'da halka açık verileri kullanarak hava kalitesini tahmin etmek Google ve EDF, Oakland'daki hava kirliliğini haritalama çalışmalarını yayınladığında, bu çalışmanın sonuçları büyük ilgi gördü. Yayınladıkları veriler, hava kalitesinin Doğu ve Batı Oakland'daki şehir bloklarına göre nasıl değiştiğini gösteren ilk veri kümelerinden biriydi.
Daniel Fleck ve David Lubert ile yazılmıştır Dizimizin ilk blogu, bir veri bilimi projesini uygun şekilde değerlendirmek için Net Şimdiki Değer (NPV), İç Getiri Oranı (IRR) ve Karlılık Endeksi'ni (PI) kullanmaya odaklanacaktır. Ayrıca, bir veri bilimi metodolojisinin kullanılmasının, bu aynı ekonomik ölçütlerin girdilerini daha yüksek kaliteli değerlendirmeler geliştirmek için nasıl daha da iyileştirebileceğini tartışacağız.
Öz bileşimi ve SVD için yararlı olan doğrusal cebir temel kavramını anlayın Bu makalede, öz ayrıştırma veya tekil değer ayrıştırma (SVD) gibi matris çarpanlara ayırma yöntemlerini anlamanın ilginç bir yolu olan temel kavramını öğreneceksiniz. Tanımlar Temel, vektör uzaylarını (vektör setleri) tanımlamak için kullanılan bir koordinat sistemidir.