In Bölüm 1 veri bilimciler bu serinin Mars'tan ve yazılım mühendisleri biz yazılım ve modelleri arasındaki farkın beş temel boyutlarını ele Venüs'ten. Sorulacak doğal soru şudur: Peki Ne? Modellerin yazılımla birleştirilmesi ve veri bilimcilerinin yazılım mühendisi muamelesi görmesi gerçekten önemli mi? Sonuçta nüfusun geniş bir kesiti ve daha da önemlisi iş dünyası için aralarındaki benzerlikler farklılıklarından çok daha görünür. Aslında, Andrej Karpathy, modelleri kullanarak problem çözmenin bu yeni yolunu Yazılım 2.0 olarak adlandırıyor . Gerçekten yazılımın bir sonraki yinelemesiyse, bu farklılıklar gerçekten önemli.
Modeller oluşturmanın zorlukları, modelleri ve yazılımı birleştirdiğimizde çileden çıkıyor. Bu blogda, ikisini birleştirdiğimizde karşılaştığımız on iki 'tuzağı' anlatıyor ve farklılıkların farkında olmamız ve bunları buna göre ele almamız gerektiğini savunuyoruz.
Önceki blogumuzda incelediğimiz gibi, modeller, verilere uyacak şekilde uygulanabilen veya kalibre edilebilen resmi matematiksel temsillerdir . Dolayısıyla veriler, bir model oluşturmak için başlangıç noktasıdır. Yazılım oluşturmak için test verileri kritik olsa da, test verilerini toplamadan veya hazırlamadan önce belirli bir spesifikasyondan bir algoritma oluşturmaya başlayabilirsiniz.
Bununla birlikte, model oluşturmaya gelince, verilerin iyi kalitede (yani, çöp içeri, çöp dışarı), yeterli miktarda mevcut olması ve denetimli öğrenme modelleri için de etiketlenmiş olması gerekir (yani, bir etiket, bir yanıt değişkenidir. model tarafından tahmin edilir). Verilerin de amaca uygun olması gerekir. Bunun bir örneği, verilerin, model üretimde konuşlandırıldığında kullanacağımız popülasyonu temsil etmesi gerektiğidir. Yüz tanıma modellerinin cilt tipi ve cinsiyet önyargılarının son örnekleri, bina modelleri için temsili (ve istatistiksel olarak anlamlı) bir veri setine sahip olmanın önemini vurgulamaktadır. Bu tür veri önyargıları, pratikte şaşırtıcı derecede yaygındır.
Bir model oluşturmak için gerekli verileri toplama, kürleme ve etiketleme konusundaki bu zorluğun, yazılıma benzer hatalı modellerin önemli tuzaklarından biri olarak ele alınamadığını gördük. Yapay zeka veya makine öğrenimi programlarını başlatmak isteyen bir dizi şirket, bu konuya çok az dikkat ediyor ve çok az veriyle modeller oluşturmaya başlıyor. Örneğin, bir şirket yakın zamanda yalnızca sekiz PDF belgesiyle belgelerden yapılandırılmış bilgileri çıkarmak için bir NLP (doğal dil işleme) modeli oluşturmak istedi. Maliyet ve gereken süre - özellikle alan uzmanlarından (örneğin, hukuk uzmanları veya klinisyenler) - etiketlemeyi önemli bir zorluk haline getirir. Teknikler daha az veriden öğrenmek ve aynı zamanda uzmanların verileri normal çalışmalarının bir parçası olarak etiketlemelerine yardımcı olmak için gelişirken, yeterli, iyi etiketlenmiş veriye sahip olmak, modellerin oluşturulma biçiminden yazılımın geleneksel olarak nasıl geliştirildiğine göre hala önemli bir sapmadır.
Özet olarak, veri tuzağı , veri hacmi tuzağı , veri kalitesi tuzağı , veri önyargısı tuzağı ve veri etiketleme tuzağı olarak daha fazla kategorize edilebilir . Bir şirket bu tuzaklardan bir veya daha fazlasından muzdarip olabilir. Veri tuzağı hakkında gerçekçi bir fikir edinmek, yanlış yola girmemenizi ve modelleme çabanız için milyonlar harcamanızı ve beklenen getirileri gerçekleştirmemenizi sağlamak için çok önemlidir. Buna ek olarak, bu tuzakları anlamak, önce daha fazla etiketli veri toplayarak veya problemleri çözmek için alternatif kurala dayalı yollar arayarak modelleme çabanızı ele alma şeklinizi de değiştirebilir.
Otuz ila kırk yıldan fazla yazılım mühendisliği uygulamaları ve metodolojileriyle, yazılım geliştiricileri ve sistem analistleri, yazılımı oluşturmak ve test etmek için gereken süreyi tahmin etmede makul ölçüde iyi (veya en azından model geliştiricilerden çok daha iyi) hale geldiler. İle çevik yazılım geliştirme tipik iki haftalık ya da dört haftalık deparlarda - yöntemlerle, yazılım sabit süreler içinde aşamalı olarak ve iteratif geliştirilebilir.
Modellerimizin belirli performans kriterlerini (örneğin, doğruluk, kesinlik, geri çağırma, vb.) Karşılamasını istediğimizi varsayarsak, sonuçlara ulaşmak için harcayacağı çabayı ve süreyi tahmin etmek zordur. Daha da kötüsü, performans kriterlerini karşılamayı gerçekten başarabilirsek, a priori bir şey söyleyemeyebiliriz . Ek olarak, performans kriterlerini karşılamanın zorluğu doğrusal olmayabilir. Örneğin, son müşteri projelerimizden birinde, birkaç hafta içinde bir karar ağacı modeliyle% 90 doğruluk elde etmeyi başardık. Ancak müşteri% 99 doğruluk hedefliyordu. Birkaç ay harcadıktan sonra doğruluk, sinir ağı modeliyle% 93'ten daha iyi olamazdı.
Lukas Biewald , Kaggle yarışmalarından birinde, modelin doğruluğunu sadece bir hafta içinde% 35 doğruluktan% 65 doğruluğa yükseltmek için dünyanın dört bir yanından binlerce kişinin bir yarışmaya katıldığı bir başka klasik örnek veriyor. Ancak daha sonra, birkaç ay ve birkaç bin kişi bu sonucu iyileştirmeye çalıştıktan sonra bile başardıkları en iyi şey% 68'lik bir doğruluktu - sadece% 3'lük bir gelişme.
Buna, veri bilimcilerinin gereken çaba ve süreyi (veya zamanı), gereken verileri ve belirli bir performans kriterini (örneğin, doğruluk) elde etmek için gereken hesaplama kaynaklarını kapsayamadığı durumlarda kapsam belirleme tuzağı diyoruz . Bu kapsam belirleme tuzağı, modelin farklı aşamalarında ortaya çıkabilir. Model inşa edilmeden önce belirli bir performansa ulaşmak için modelin kapsamını belirlemek zor olabilir - buna, inşa öncesi kapsam belirleme tuzağı diyoruz . Eğitim kapsam tuzak yeni veriler, yeni teknikler, ek kaynaklar vb ile - - sırayla performans kriterlerini elde veri bilim adamları modeli eğitim devam etmelidir ne kadar söyleyemiyoruz zaman olduğu eğitim aşamasında .
Bu iki tuzak, modellerin geleneksel bir yazılım içine yerleştirilmesi veya bir veri bilimi projesinde sunulması söz konusu olduğunda bir ürün yöneticisini, saldırı ustasını veya proje yöneticisini çılgına çevirebilir. Büyük yazılım geliştirme çabalarında, veri bilimcilerinin 'sesinin' göz ardı edildiğini, veri bilimcilerini basit tanımlayıcı analizler yapmaya zorladığını ve sıkı ve sabit son tarihler nedeniyle modelden herhangi bir içgörü üretmediğini gördük. Alternatif olarak, kırılgan olan gerçek makine öğrenimi modellerinin aksine kural tabanlı modeller geliştirebilirler. Bunun, birçok AI / ML projesinde belirtilen ROI'lerini (Yatırım Getirisi) sağlamayan önemli sorunlardan biri olduğuna inanıyoruz.
Sürekli öğrenebilen modeller geliştirildiğinde, ek bir zorlukla karşı karşıya kalırız. Model dağıtımı için işletme tarafından belirlenen hedef doğruluğunun% 90 doğruluk olduğunu ve eğitilen modelin% 86 doğruluk elde ettiğini varsayalım. İşletme ve veri bilimciler birlikte modeli devreye alma kararı alabilir ve modelin sürekli öğrenmesini sağlayabilir ve doğruluğun% 90 eşiğini geçmesini umabilir. Bir kez daha, veri bilimcileri, modelin bu eşiği ne zaman ve hangi koşullar altında geçeceğini belirleyemeyecekler. Bu varyanta dağıtım kapsam belirleme tuzağı diyoruz .
Son olarak, modeller , altta yatan koşullar değiştiği için üretim modelinin performansının düştüğü model sapmasından zarar görebilir . Bu tür model sapmaları aniden veya sürekli olarak gerçekleşebilir. Bir kez daha, veri bilimcileri model doğruluğunun doğasını, zamanlamasını ve bozulmasını kapsayamayacak. Biz buna drift kapsam belirleme tuzağı diyoruz . Sonuç olarak, bu tür model sapmalarını ölçmek ve bunlara göre hareket etmek için model izleme uygulamalarının kurulması gerekir.
Özetle, kapsam belirleme tuzağı , derleme öncesi kapsam belirleme , eğitim kapsamı belirleme , dağıtım kapsamı belirleme ve sürüklenme kapsam belirleme tuzakları olarak daha fazla kategorize edilebilir . Aşağıdaki şekil, açıklayıcı bir örnek kullanarak bu farklı türdeki kapsam belirleme tuzaklarını vurgulamaktadır.
İşletme sponsorları ve proje yöneticileri, herhangi bir büyük ölçekli yazılım oluşturmaya başlamadan önce genellikle beklenen yatırım getirisini göstermek zorundadır. Veri bilimi projeleri işletmelerde daha yaygın hale geldikçe, iş liderlerinin yatırımlarını yapmadan veya önceliklendirmeden önce beklenen ROI'yi anlamak istemeleri doğaldır. Yeni bir yazılım parçasının getirilerini tahmin etmek kolay olmasa da, modellerin beklenen yatırım getirisi söz konusu olduğunda görev daha da karmaşık hale gelir.
Kavramsal olarak, yatırım getirisi nispeten basit bir hesaplamadır - maliyetlere göre net faydadır
ROI = (Modelin faydaları - Modelin maliyeti) / Modelin maliyeti
Yapay zeka / makine öğrenimi modellerinin şirketlerdeki faydaları genellikle iki geniş kategoriye ayrılır - verimlilik ve etkinlik . Şirketler, doğası gereği tekrar eden manuel veya bilişsel görevleri otomatikleştirdiklerinde, sürecin verimliliğini artırır, bu görevleri yerine getirmek için gereken süreyi azaltır ve işgücünün üretkenliğini artırır. Şirketler, insanların daha iyi kararlar almalarını sağlamak için modeller kullandıklarında, kararlarının etkinliğini artırırlar. Başka bir deyişle, faydalar daha hızlı ve daha iyi olmaktan kaynaklanmaktadır . Sormamız gereken soru - hangi temele göre daha hızlı ve daha iyi ? Şirketlerin genellikle yetersiz kaldığı bu temelin tahmin edilmesidir.
Bir görevi otomatikleştirirken , bir insanın görevi yerine getirmesinin ne kadar sürdüğüne dair bir temele sahip olmamız gerekir ? Ne yazık ki, bir kişinin bir görevi yerine getirmesinin ne kadar sürdüğünü tahmin etmek - özellikle bilişsel bir görev olduğunda (örneğin, bir müşterinin riskini değerlendirmek) veya tekrar etmeyen bir görev olduğunda (örneğin, masraf onayında istisnaları ele almak) kolay değildir. Farklı becerilere, geçmişe ve görev süresine sahip kişilerin görevi tamamlaması farklı zamanlar alabilir. Bir görevin gerçek süresini belirlemek için tüm bu faktörlerin doğru bir analizi, önemsiz bir alıştırmadır ve ayrıca bir hizmet organizasyonunda veya bir dizi karmaşıklık düzeyini kapsayan çok çeşitli görevlere sahip bilgi tabanlı bir organizasyonda pratik olmayabilir.
Verimlilik için temelin türetilmesindeki diğer bir yaygın sorun, verilen görevin tahminini, yapılan diğer tüm görevler arasında izole etmenin zor olabileceğidir. Bir gün içindeki farklı faaliyetleri arasında sistemdeki bir satın alma siparişini inceleyen, işlemin doğru olup olmadığını belirlemek için paketleme fişi ve satıcı faturasıyla çapraz kontroller yapan bir satın alma yöneticisi örneğini ele alalım. Faturadan anahtar alanları çıkarmak için bir NLP modeli oluşturduğumuzu varsayalım, böylece satınalma siparişiyle mutabık kılınabilirler. Bu tek kişi için bile, fatura işleme için harcadıkları toplam süreyi hesaplamak zor olabilir, çünkü bu görev toplantılara katılmak, sevkiyatı denetlemek vb. Gibi diğer görevlerle bütünleşiktir ve satın alma siparişinin karmaşıklığına bağlıdır. faturalar ve paketleme makbuzları (örneğin, gönderi birden fazla satın alma siparişi veya birden fazla fatura üzerinden yapılan bir teslimatsa karmaşıklık ve zaman artar).
Etkinlik için bir temel elde etmek söz konusu olduğunda daha da zorlu bir çabaya giriyoruz. Görevler için verimlilikler hesaplandı - aldığı süre boyunca ölçülebilen ayrı etkinlikler. Ancak, etkinlik söz konusu olduğunda, kararları ve eylemleri değerlendiriyoruz . Bir eylemin diğerinden daha iyi olup olmadığını nasıl belirleriz ? Bir eylemin sonuçları çok boyutludur, belirsiz olabilir ve etkisi gecikebilir. Diyelim ki aracınızı sürüyorsunuz ve tam bir sinyale yaklaştığınızda yeşil ışık sarıya dönüyor. Arkanızı, arkanızdaki bir arabanın sizi potansiyel olarak çarpması için riske atmasını durdurmak için molalar veriyor musunuz yoksa kehribar renginde (hala yasal) mı geçiyorsunuz? Hangi eylem daha iyi ve ne şekilde - arkanızdaki araç için daha iyi, yakıt tüketimi açısından daha iyi, yasalara daha sıkı uymak açısından daha iyi. Bu basit bir eylem olsa da, kararların temelini tahmin etmek daha da karmaşıktır.
Şimdiye kadar, verimlilik ve etkililik için bir temel tahminini inceledik. Bu, modeli oluşturmaya başlamadan önce gerçekleşmelidir, böylece modelimizden hangi performansı istediğimiz konusunda iyi bir fikre sahip oluruz. Buna geri dönüş tahmini tuzağı diyoruz . Modelimizi oluşturup uyguladığımızda ve şimdi faydalarını gerçekleştirmeye çalıştığımızda ortaya çıkan başka bir tür geri dönüş tuzağı var. Buna dönüş farkındalık tuzağı diyoruz .
Getirileri hesaplarken bir kez daha sorunlarla karşılaşıyoruz. Verimlilik faydaları söz konusu olduğunda, otomasyonun bir görevi tamamlamak için gereken süreyi azaltabildiğini kategorik olarak gösterebiliriz. Otomatik fatura işleme modelinizin bir faturayı işleme koyma süresini 30 dakikadan 15 dakikaya düşürdüğünü varsayalım. Kişi günde dört fatura işliyorsa, kişi günde bir saat veya haftada beş saat tasarruf etmiş olur. Şimdi diyelim ki kişi günde on saat veya haftada elli saat çalışıyor. Zamandaki tasarruf% 10'dur. Ancak, şirkete elle tutulur bir $-fayda sağlanmayabilir. Bu, birkaç nedenden dolayı olabilir. Çalışan haftada 50 saat çalışıyor ve 5 saatlik tasarrufla çalıştıkları saatlerin sayısını azaltabilir. Bu, çalışan memnuniyeti ve elde tutma açısından kuruluşa yine de genel bir fayda sağlayabilir - ancak muhtemelen bunu fayda tahminimize dahil etmedik. Haftada sadece 40 saat çalışıyor olsalar ve otomasyon nedeniyle onlara 5 saat kazandırmış olsak bile, kuruluşun kısmi zamandan para kazanabilmesinin aksine, boşluğu doldurmak için yapacak başka şeyler bulabilirler. Bu, RPA (Robotik Süreç Otomasyonu) ve IPA (Akıllı Süreç Otomasyonu) ile ilgili en büyük zorluklardan biridir; bireyler için zaman tasarrufu sağlanır, böylece FTE'de (Tam Zaman Eşdeğerleri) bir azalma olur, ancak bu tasarruf kişi sayısına dönüşmez otomasyondan dönüşü açıkça gösterebileceğiniz bir azalma.
Kararların veya eylemlerin etkililiğinin faydalarını anlamaya gelince, benzer sorunlarla da karşılaşıyoruz. Bu durumlarda en büyük zorluk, ilişkilendirmenin zorluğudur . Bir eylemin bir alternatiften ölçülebilir şekilde daha iyi olduğu gösterilebildiğinde, bu eylemin gerçekleştirildiği bağlamın tamamını izole etmek her zaman mümkün değildir. Örneğin, aracı durdurma veya kehribar üzerinde bir kavşağı geçme durumunda, kuru ve güneşli bir gün olduğunda aniden durma eylemi daha iyi olabilir ve ıslak, kaygan, karlı bir günde potansiyel olarak yanlış seçim olabilir. Bu durumda, kuru ve güneşli bir günde durmanın tüm faydalarını eyleminize tam olarak bağlayamazsınız - kredinin bir kısmı, eyleminiz için size doğru ortamı sağlamak için doğaya gider. Bu ilişkilendirme zorluğu, rakiplerin, müşterilerin, tedarikçilerin, düzenlemelerin ve bir dizi diğer paydaşın 'daha iyi' veya 'daha kötü' bir eylem veya karar verme konusunda parmağı olabileceği kararları ve eylemleri değerlendirmek söz konusu olduğunda çok yaygındır.
Geri dönüş tuzağının yazılımdan ziyade modeller için daha akut olmasının nedeni, bu modellerin performansını insan performansı ile karşılaştırıyor olmamızdır. İnsanların otomatikleştirilmiş modellerin hızında belirli görevleri yerine getiremediği durumlarda (örneğin, algoritmik ticaret) veya model, insanca imkansız sayıda seçimi değerlendirip doğru kararı verebiliyorsa (örneğin, Go veya Chess oyununu oynamak), modellerin değeri oldukça açık olacaktır. Bununla birlikte, modellerin görevleri otomatikleştirdiği veya insan kararlarını veya eylemlerini artırdığı vakaların çoğunda değer tuzağı, mücadele edilmesi gereken önemli bir zorluktur.
Özetle, dört farklı türde getiri tuzağı elde ediyoruz - getiri verimliliği tahmini , getiri etkinliği tahmini , getiri verimliliği gerçekleştirme ve getiri etkinliği gerçekleştirme tuzakları.
Aşağıda gösterildiği gibi üç geniş tuzak kategorisine ve toplam on iki farklı alt kategoriye baktık.
In Bölüm 1 biz modelleri ve yazılım arasındaki farkların beş boyutu incelendi. Yukarıda tartışılan veri tuzağı, büyük ölçüde modellerin verilere uyacak şekilde yapılandırılmasının temel yolundan kaynaklanmaktadır. Ek olarak, çıktı etrafındaki belirsizlik ve endüktif çıkarım mekanizması da farklı veri tuzaklarına katkıda bulunur. Kapsam belirleme tuzağı, modellerin eğitiminde bilimsel olma ihtiyacından (yani, test et ve öğren veya deneysel yaklaşım) doğar. Aynı kapsam belirleme tuzakları, bilim insanlarının bir durumu iyileştirmek için bir ilacı bulmak için gereken süreyi veya bir ilacın farklı klinik deneylerden başarıyla geçip geçmeyeceğini tahmin edemediği farmasötik sektöründe de yaygındır. Benzer şekilde, ilaç piyasaya sürüldükten sonra bile etkinliği düşebilir (örneğin antibiyotiğe dirençli bakteriler). Sürüklenme kapsam belirleme tuzağı, karar alanının evrildiği dinamik tarzın bir etkisidir. Son olarak, geri dönüş tuzakları, modellerin deneysel ve bilimsel zihniyetinden ve ayrıca karar uzayının dinamik doğasından kaynaklanmaktadır.
Sonraki bloglarda, modellerin kapsamını belirleme, oluşturma ve sunmanın bu tuzaklarını ve zorluklarını ele almak için en iyi uygulamalardan bazılarına 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.
Kubernetes'in yaygınlaştığını söylemek yetersiz kalır. Aslında, modern dağıtılmış sistemlerin nasıl tasarlandığını ve işletildiğini etkiledi.
Bu sadece kodlama ve teknik becerilerle ilgili değil Üç yıl önce, kurumsal dünyaya işlerin nasıl görüneceğine dair tonlarca varsayım ve beklentiyle ilk kez adım attım. Ne kadar yanıldığımı kanıtlamak üzere olduğumu çok az biliyordum.
Kubernetes Kabul Denetleyicisi nedir? Kubernetes kabul denetleyicileri, kimliği doğrulanmış istekleri Kubernetes API sunucusuna yakalayarak ve herhangi bir nesne verisi etcd veri deposunda saklanmadan önce bunları işleyerek ağ geçidi koruyucusu görevi gören eklentilerdir. Kabul denetleyicileri, bir istek nesnesini değiştirebilir / değiştirebilir (Değişen Kabul Denetleyicileri) veya bir isteğe izin verebilir / izin vermeyebilir (Kabul Denetleyicileri) ve bazen her ikisini de yapabilir.
Sprint günlerinde bir Hikaye, önceki 2 haftadaki başarılarımızı (veya başarısızlıklarımızı) yansıtıyoruz. Yakınlaştırmaya atlayıp düşüncelerimizi paylaşıp derinlemesine düşünmeden önce yaklaşık 20 dakika.