Makine Öğrenimi Kuralları:

ML Mühendisliği İçin En İyi Uygulamalar

Martin Zinkevich

Bu belgenin amacı, makine öğrenimi konusunda temel bilgiye sahip olanların Google'ın makine öğrenimiyle ilgili en iyi uygulamalarından yararlanmasına yardımcı olmaktır. Google C++ Stil Kılavuzu ve diğer popüler uygulamalı programlama kılavuzlarına benzer şekilde, makine öğrenimi için bir stil sunar. Makine öğrenimi dersi aldıysanız veya makine öğrenimiyle oluşturulan bir model geliştirdiyseniz ya da üzerinde çalıştıysanız bu belgeyi okumak için gereken arka plana sahipsiniz demektir.

Martin Zinkevich, makine öğrenimiyle ilgili en sevdiği 10 kuralı anlatıyor. 43 kuralın tümünü öğrenmek için okumaya devam edin.

Terminoloji

Etkili makine öğreniminden bahsederken aşağıdaki terimler tekrar tekrar karşınıza çıkacaktır:

  • Örnek: Hakkında tahmin yapmak istediğiniz şey. Örneğin, "kediler hakkında" veya "kediler hakkında değil" olarak sınıflandırmak istediğiniz bir web sayfası olabilir.
  • Etiket: Bir tahmin görevinin yanıtı, bir makine öğrenimi sistemi tarafından üretilen veya eğitim verilerinde sağlanan doğru yanıttır. Örneğin, bir web sayfasının etiketi "kediler hakkında" olabilir.
  • Özellik: Bir tahmin görevinde kullanılan örneğin özelliği. Örneğin, bir web sayfasında "'kedi' kelimesini içeren" bir özellik olabilir.
  • Özellik Sütunu: Kullanıcıların yaşayabileceği tüm olası ülkeler gibi ilgili özelliklerden oluşan bir grup. Bir örnekte, bir özellik sütununda bir veya daha fazla özellik bulunabilir. "Özellik sütunu" Google'a özgü terminolojidir. Bir özellik sütunu, VW sisteminde (Yahoo/Microsoft'ta) "ad alanı" veya bir alan olarak adlandırılır.
  • Örnek: Bir örnek (özellikleriyle birlikte) ve bir etiket.
  • Model: Bir tahmin görevinin istatistiksel bir temsili. Bir modeli örnekler üzerinde eğitirsiniz, ardından bu modeli tahminde bulunmak için kullanırsınız.
  • Metrik: Önem verdiğiniz bir sayı. Doğrudan optimize edilmiş olabilir veya olmayabilir.
  • Hedef: Algoritmanızın optimize etmeye çalıştığı bir metriktir.
  • Ardışık düzen: Makine öğrenimi algoritmasını çevreleyen altyapı. Kullanıcı arabiriminden veri toplamayı, eğitim veri dosyalarına eklemeyi, bir veya daha fazla modeli eğitmeyi ve modelleri üretime aktarmayı içerir.
  • Tıklama Oranı Bir web sayfasına gelen ve bir reklamdaki bağlantıyı tıklayan ziyaretçilerin yüzdesidir.

Genel bakış

Mükemmel ürünler yapmak için:

makine öğrenimi uzmanı olduğunuz gibi değil, en iyi mühendis olduğunuz gibi makine öğreniminden yararlanın.

Karşılaşacağınız sorunların çoğu aslında mühendislik sorunları. Başarılı bir makine öğrenimi uzmanının tüm kaynaklarıyla bile elde edilen kazançların çoğu, mükemmel makine öğrenimi algoritmalarından değil, mükemmel özelliklerden gelmektedir. Yani temel yaklaşım şöyledir:

  1. Ardışık düzeninizin uçtan uca sağlam olduğundan emin olun.
  2. Makul bir hedefle başlayın.
  3. Sağduyuya yönelik özellikleri basit bir şekilde ekleyin.
  4. Ardışık düzeninizin sabit kaldığından emin olun.

Bu yaklaşım, uzun süre işe yarar. Yalnızca, sizi daha fazla uzağa götürecek başka basit püf noktaları olmadığında bu yaklaşımdan ayrılın. Karmaşıklık eklemek, gelecekteki sürümleri yavaşlatır.

Basit püf noktalarını bitirdikten sonra, makine öğrenimi gelecekte sizin için ideal olabilir. III. Aşama makine öğrenimi projelerindeki bölüme bakın.

Bu belge aşağıdaki şekilde düzenlenmiştir:

  1. İlk bölüm, makine öğrenimi sistemi oluşturmak için doğru zaman olup olmadığını anlamanıza yardımcı olacaktır.
  2. İkinci kısım, ilk ardışık düzeninizi dağıtmakla ilgilidir.
  3. Üçüncü bölüm, ardışık düzeninize yeni özellikler eklerken lansman ve yineleme, modellerin nasıl değerlendirileceği ve eğitim sunumundaki sapmaların nasıl değerlendirileceği ile ilgilidir.
  4. Son kısım, platoya ulaştığınızda ne yapmanız gerektiğiyle ilgilidir.
  5. Ardından, ilgili çalışmaların bir listesi ve bu belgede yaygın olarak kullanılan sistemlerle ilgili bazı arka planların yer aldığı bir ek bulunur.

Makine Öğreniminden Önce

1. Kural: Bir ürünü makine öğrenimi olmadan kullanıma sunmaktan korkmayın.

Makine öğrenimi havalı bir şeydir ama veri gerektirir. Teorik olarak, farklı bir problemden verileri alıp daha sonra yeni bir ürün için modeli değiştirebilirsiniz, ancak bu muhtemelen temel heuristics daha düşük performans gösterecektir. Makine öğreniminin size% 100 artış sağlayacağını düşünüyorsanız bulgusal bir yaklaşım sizi hedefinize %50 oranında ulaştıracaktır.

Örneğin, bir uygulama ticaret sitesinde uygulamaları sıralıyorsanız yükleme oranını veya yükleme sayısını bulgusal olarak kullanabilirsiniz. Spam algılıyorsanız daha önce spam gönderen yayıncıları filtreleyin. Ayrıca gerçek kişiler tarafından yapılan düzenlemelerden de korkmayın. Kişileri sıralamanız gerekiyorsa en son kullanılan kişileri sıralayın (hatta alfabetik olarak da sıralayın). Ürününüz için makine öğreniminin kesinlikle gerekli olmadığı durumlarda veri elde edene kadar makine öğrenimi kullanmayın.

2. Kural: İlk olarak metrikleri tasarlayın ve uygulayın.

Makine öğrenimi sisteminizin ne yapacağını biçimlendirmeden önce, mevcut sisteminizde mümkün olduğunca çok izleme yapın. Bunu aşağıdaki nedenlerden dolayı yapın:

  1. Sistem kullanıcılarından önceden izin almak daha kolaydır.
  2. Bir şeyin gelecekte sorun yaratabileceğini düşünüyorsanız geçmiş verileri şimdi almanız daha iyi olur.
  3. Sisteminizi metrik enstrümantasyonlarını göz önünde bulundurarak tasarlarsanız gelecekte işler daha iyi olacaktır. Özellikle de metriklerinizi ölçmek için günlüklerdeki dizeleri bulmak zorunda kalmazsınız.
  4. Değişen ve değişmeyen şeyleri göreceksiniz. Örneğin, bir gün içindeki etkin kullanıcıları doğrudan optimize etmek istediğinizi varsayalım. Ancak sistemi erkenden değiştirirken, kullanıcı deneyiminde yapılan büyük değişikliklerin bu metriği belirgin şekilde değiştirmediğini fark edebilirsiniz.

Google Artı ekibi okuma başına genişletme, okuma başına yeniden paylaşım sayısı, okuma başına artı bir sayısı, yorum/okuma, kullanıcı başına yorum sayısı, kullanıcı başına yeniden paylaşım gibi ölçütleri ölçer. Bu ölçütleri, yayın sırasında bir yayının iyiliğini hesaplarken kullanır. Ayrıca, kullanıcıları gruplar halinde gruplandırabileceğiniz ve istatistikleri denemeye göre toplayabileceğiniz bir deneme çerçevesinin de önemli olduğunu unutmayın. 12. Kural'a bakın.

Metrik toplama konusunda daha özgür davranarak sisteminize dair daha geniş bir görünüm elde edebilirsiniz. Bir sorun mu fark ettiniz? Takip etmek için metrik ekleyin. Son sürümde niceliksel bir değişiklik yapmak sizi heyecanlandırıyor mu? Takip etmek için metrik ekleyin.

3. Kural: Karmaşık buluşsal yöntemler yerine makine öğrenimini seçin.

Basit bir buluşsal yöntem, ürününüzü piyasaya çıkarabilir. Karmaşık bir buluşsal biçim sürdürülemez. Verilere ve neyi başarmaya çalıştığınıza dair temel bir fikir edindikten sonra makine öğrenimine geçin. Çoğu yazılım mühendisliği görevinde olduğu gibi, ister sezgisel ister makine tarafından öğrenilmiş bir model olsun, yaklaşımınızı sürekli güncellemek istersiniz ve makine ile öğrenilen modelin güncellenmesi ve bakımının daha kolay olduğunu göreceksiniz (16. Kural'a bakın).

Makine Öğrenimi Aşaması I: İlk Ardışık Düzeniniz

İlk ardışık düzeniniz için sistem altyapınıza odaklanın. Hayal gücünü harekete geçiren makine öğrenimi üzerine düşünmek eğlenceli olsa da öncelikle ardışık düzeninize güvenmezseniz neler olup bittiğini anlamak zor olacaktır.

4. Kural: İlk modeli basit tutun ve altyapıyı doğru şekilde kullanın.

İlk model, ürününüz için en büyük desteği sağlar, dolayısıyla gösterişli olması gerekmez. Ancak beklediğinizden çok daha fazla altyapı sorunuyla karşılaşırsınız. Üretilen yeni makine öğrenimi sisteminizi herkesin kullanabilmesi için önce şunları belirlemeniz gerekir:

  • Öğrenme algoritmanıza örnek bulma.
  • Sisteminiz için "iyi" ve "kötü"nün ne anlama geldiğini gösteren ilk bölüm.
  • Modelinizi uygulamanıza nasıl entegre edebilirsiniz? Modeli canlı olarak uygulayabilir veya çevrimdışı örnekler üzerinde önceden hesaplayarak sonuçları bir tabloda depolayabilirsiniz. Örneğin, web sayfalarını önceden sınıflandırmak ve sonuçları bir tabloda depolamak isteyebilirsiniz, ancak sohbet mesajlarını canlı olarak sınıflandırmak isteyebilirsiniz.

Basit özellikleri seçmek aşağıdakileri yapmanızı kolaylaştırır:

  • Özellikler, öğrenme algoritmanıza doğru şekilde ulaşır.
  • Model makul ağırlıkları öğrenir.
  • Özellikler, sunucudaki modelinize doğru şekilde ulaşır.

Bu üç şeyi güvenilir şekilde yapan bir sisteminiz olduğunda işin çoğunu yapmış olursunuz. Basit modeliniz, daha karmaşık modelleri test etmek için kullanabileceğiniz temel metrikleri ve temel davranışı sağlar. Bazı ekipler "nötr" bir ilk lansman yapmayı, yani dikkatin dağılmaması için makine öğrenimi kazanımlarının önceliğini açıkça azaltan ilk lansman yapmayı hedefler.

5. Kural: Altyapıyı makine öğreniminden bağımsız olarak test edin.

Altyapının test edilebilir olduğundan ve sistemin öğrenme parçalarının içine alındığından emin olun. Böylece, etrafındaki her şeyi test edebilirsiniz. Özellikle:

  1. Verileri algoritmaya aktarmayı test etmek. Doldurulması gereken özellik sütunlarının doldurulup doldurulmadığını kontrol edin. Gizliliğin izin verdiği durumlarda, eğitim algoritmanıza yapılan girişi manuel olarak inceleyin. Mümkünse ardışık düzeninizdeki istatistikleri, başka bir yerde işlenen aynı verilerin istatistikleriyle karşılaştırarak kontrol edin.
  2. Modelleri eğitim algoritmasından çıkarmayı test edin. Eğitim ortamınızdaki modelin, sunum ortamınızdaki modelle aynı puanı verdiğinden emin olun (37 numaralı kurala bakın).

Makine öğreniminde öngörülemez bir öğe vardır. Bu nedenle, eğitim ve sunumda örnek oluşturmak için kod testleriniz olduğundan ve sunum sırasında sabit bir model yükleyip kullanabildiğinizden emin olun. Verilerinizi anlamanız da önemlidir: Büyük ve Karmaşık Veri Kümelerinin Analizi için Pratik Tavsiyeler bölümüne bakın.

6. Kural: Ardışık düzenleri kopyalarken atlanan verilere dikkat edin.

Genellikle mevcut bir boru hattını kopyalayarak (kargo kült programlama) bir ardışık düzen oluştururuz ve eski ardışık düzen, yeni hat için ihtiyacımız olan verileri bırakır. Örneğin, Google Artı Yenilikler kanalı eski yayınları bırakır (çünkü bu yeni yayınları sıralamaya çalışır). Bu ardışık düzen, eski yayınların hâlâ anlamlı olduğu Google Artı Akışı için kullanılmak üzere kopyalandı ancak söz konusu ardışık düzen hâlâ eski yayınları kaldırıyordu. Yaygın olarak kullanılan bir başka kalıp da yalnızca kullanıcı tarafından görülen verilerin günlüğe kaydedilmesidir. Bu nedenle, belirli bir yayının kullanıcı tarafından neden görülmediğini modellemek istiyorsak tüm olumsuz örnekler atıldığından bu veriler bir işe yaramaz. Play'de de benzer bir sorun yaşandı. Play Uygulamalar Ana Sayfası üzerinde çalışırken, Play Games'in açılış sayfasından örnekler de içeren yeni bir ardışık düzen oluşturuldu. Bu örnekte, her bir örneğin nereden geldiğini açıklayan hiçbir özellik bulunmadı.

7. Kural: Bulgusal yöntemleri özelliklere dönüştürün veya dışarıda kullanın.

Makine öğreniminin çözmeye çalıştığı sorunlar genellikle tamamen yeni değildir. Sıralama veya sınıflandırma ya da çözmeye çalıştığınız problem ne olursa olsun diye bir sistem var. Bu da bir dizi kural ve bulgusal yöntem olduğu anlamına gelir. Aynı bulgular, makine öğrenimi ile düzenlendiğinizde artış sağlayabilir. Bulgusal yöntemleriniz, sahip oldukları bilgiler için iki nedenden dolayı incelenmelidir. İlk olarak, makine öğrenimiyle öğrenilen bir sisteme geçiş daha yumuşak olacaktır. İkinci olarak, bu kurallar genellikle ortadan kaldırmak istemediğiniz sisteme dair epey sezgi içerir. Mevcut bir buluşsal yöntemi kullanabileceğiniz dört yol vardır:

  • Sezgisel kullanarak ön işleme. Bu özellik inanılmaz derecede muhteşemse bu bir seçenektir. Örneğin, bir spam filtresinde gönderen zaten kara listeye alınmışsa "kara listeye" eklemenin ne anlama geldiğini yeniden öğrenmeye çalışmayın. Mesajı engelleyin. Bu yaklaşım, ikili sınıflandırma görevlerinde en mantıklı olanıdır.
  • Bir özellik oluşturun. Doğrudan sezgisel işlemden bir özellik oluşturmak harika bir yöntemdir. Örneğin, bir sorgu sonucuna ilişkin alaka düzeyi puanını hesaplamak için buluşsal bir yöntem kullanıyorsanız puanı bir özelliğin değeri olarak ekleyebilirsiniz. Daha sonra, değeri değer katmak için makine öğrenimi tekniklerini kullanmak isteyebilirsiniz (örneğin, değeri sınırlı sayıda ayrı değer grubundan birine dönüştürmek veya diğer özelliklerle birleştirmek) ancak bulgusal yöntemin oluşturduğu ham değeri kullanarak işe başlayabilirsiniz.
  • Sezginin ham girdilerini çıkarın. Uygulamalar için yükleme sayısını, metindeki karakter sayısını ve haftanın gününü birleştiren bir bulgu varsa bu parçaları birbirinden ayırmayı ve bu girişleri öğrenime ayrıca göndermeyi düşünün. Topluluklar için geçerli olan bazı teknikler burada geçerlidir (40. Kural'a bakın).
  • Etiketi değiştirin. Bu, bulgusal yöntemin o sırada etikette yer almayan bilgileri yakaladığını düşündüğünüzde bu bir seçenektir. Örneğin, indirme sayısını en üst düzeye çıkarmaya çalışırken aynı zamanda kaliteli içerik de istiyorsanız çözüm, etiketi uygulamanın aldığı ortalama yıldız sayısıyla çarpmak olabilir. Burada çok fazla esneklik var. "İlk Hedefiniz" bölümüne bakın.

Bir ML sisteminde bulgusal yöntemler kullanırken bu karmaşıklığa dikkat edin. Yeni makine öğrenimi algoritmanızda eski buluşsal yöntemleri kullanmak, sorunsuz bir geçiş oluşturmanıza yardımcı olabilir. Ancak aynı etkiyi elde etmenin daha basit bir yolu olup olmadığını düşünün.

İzleme

Genel olarak, uyarıları harekete geçirici hale getirmek ve bir kontrol paneli sayfası bulundurmak gibi uyarı hijyeni kurallarına uyun.

8. Kural: Sisteminizin güncellik gereksinimlerini öğrenin.

Bir günlük modeliniz varsa performans ne kadar düşer? Bir haftalık mı? Üç aylık mı? Bu bilgiler, izleme sürecinizin önceliklerini anlamanıza yardımcı olabilir. Model bir gün boyunca güncellenmezse ürün kalitesinde önemli bir kayıp yaşanırsa bir mühendisin modeli sürekli olarak izlemesi mantıklıdır. Çoğu reklam sunma sisteminin her gün işlemesi gereken yeni reklamları vardır ve bunların günlük olarak güncellenmesi gerekir. Örneğin, Google Play Arama için makine öğrenimi modeli güncellenmezse bunun bir aydan kısa bir süre içinde olumsuz bir etkisi olabilir. Google Artı'daki Yenilikler ile ilgili bazı modellerin modellerinde yayın tanımlayıcısı yoktur. Bu nedenle bu modelleri nadiren dışa aktarabilirler. Yayın tanımlayıcıları olan diğer modeller çok daha sık güncellenir. Ayrıca, özellikle özellik sütunları modelinize eklendiğinde veya modelden kaldırıldığında, güncelliğin zaman içinde değişebileceğini de unutmayın.

9. Kural: Modelleri dışa aktarmadan önce sorunları tespit edin.

Çoğu makine öğrenimi sisteminde, modeli sunuma aktardığınız bir aşama bulunur. Dışa aktarılan bir modelle ilgili bir sorun varsa bu, kullanıcıyı etkileyen bir sorundur.

Modellik kontrollerini, modeli dışa aktarmadan hemen önce yapın. Özellikle, modelin elde tutulan verilerde makul performans gösterdiğinden emin olun. Verilerle ilgili endişeleriniz varsa bir modeli dışa aktarmayın. Modelleri sürekli olarak dağıtan birçok ekip, dışa aktarmadan önce ROC eğrisinin (veya AUC) altındaki alanı kontrol eder. Dışa aktarılmayan modellerle ilgili sorunlar için e-posta uyarısı gerekir ancak kullanıcılara yönelik modellerdeki sorunlar için sayfa gerekebilir. Bu nedenle, kullanıcıları etkilemeden önce bekleyip emin olmak daha iyidir.

10. Kural: Sessiz hatalara dikkat edin.

Bu sorun, diğer sistem türleri yerine makine öğrenimi sistemlerinde görülür. Birleştirilen belirli bir tablonun artık güncellenmediğini varsayalım. Makine öğrenimi sistemi uyum sağlayacak ve davranış, makul düzeyde iyi olmaya devam edecek ve bu değişim yavaş yavaş azalacaktır. Bazen aylarca geçerliliğini yitirmiş tablolar bulursunuz ve basit bir yenileme, performansı o çeyrekteki diğer tüm lansmanlardan daha fazla iyileştirir. Bir özelliğin kapsamı, uygulama değişikliklerine bağlı olarak değişebilir. Örneğin, bir özellik sütunu örneklerin% 90'ında doldurulabilir ve aniden örneklerin% 60'ına düşebilir. Play'in bir zamanlar 6 ay boyunca eski bir tablosu vardı ve sadece tabloyu yenilemek yükleme oranında% 2'lik bir artış sağladı. Veri istatistiklerini takip etmenin yanı sıra verileri zaman zaman manuel olarak incelerseniz bu tür hataları azaltabilirsiniz.

11. Kural: Özellik sütunlarının sahiplerini ve belgelerini verin.

Sistem büyükse ve çok sayıda özellik sütunu varsa her özellik sütununu kimin oluşturduğunu veya koruduğunu öğrenin. Bir özellik sütununu anlayan kişinin ayrıldığını fark ederseniz mutlaka bu bilgiye sahip olan biri. Birçok özellik sütununun açıklayıcı adları olsa da, özelliğin ne olduğu, nereden geldiği ve nasıl yardımcı olması beklendiğiyle ilgili daha ayrıntılı bir açıklamaya sahip olmak iyi bir fikirdir.

İlk Hedefiniz

Sistemle ilgili ilgilendiğiniz birçok metrik veya ölçüm vardır ancak makine öğrenimi algoritmanız genellikle algoritmanızın optimize etmeye "çalıştığı" tek bir hedef gerektirir. Hedefler ile metrikleri burada ayırıyorum. Metrik, sisteminizin raporladığı herhangi bir sayıdır. 2. Kural'a da bakın.

12. Kural: Hangi hedefi doğrudan optimize etmeyi seçeceğinize fazla düşünmeyin.

Para kazanmak, kullanıcılarınızı mutlu etmek ve dünyayı daha iyi bir yer haline getirmek istiyorsunuz. Önem verdiğiniz tonlarca metrik vardır ve bunların tümünü ölçmeniz gerekir (2. Kural'a bakın). Ancak makine öğrenimi sürecinin başlarında, doğrudan optimize etmedikleriniz dahil olmak üzere tüm dönüşümlerin arttığını fark edersiniz. Örneğin, tıklama sayısına ve sitede geçirilen zamana önem verdiğinizi varsayalım. Tıklama sayısına göre optimizasyon yaparsanız, büyük olasılıkla harcanan zamanın arttığını görebilirsiniz.

Bu nedenle, tüm metrikleri kolayca artırabiliyorsanız işleri basit tutun ve farklı metrikleri dengeleme konusunda çok fazla düşünmeyin. Yine de bu kuralı fazla aşmayın: Hedefinizi sistemin nihai durumuyla karıştırmayın (bkz. 39. Kural). Doğrudan optimize edilen metriği artırdığınız halde kullanıma sunmamaya karar verirseniz nesnel revizyon yapmanız gerekebilir.

13. Kural: İlk hedefiniz için basit, gözlemlenebilir ve ilişkilendirilebilir bir metrik seçin.

Genelde asıl hedefin ne olduğunu bilemezsiniz. Bildiğinizi düşünüyorsunuzdur. Ancak bir yandan eski sisteminizle yeni makine öğrenimi sisteminizin verileri ve yan yana analizine baktığınızda hedefi değiştirmek istediğinizi fark edersiniz. Üstelik farklı ekip üyeleri çoğu zaman gerçek hedef üzerinde anlaşamazlar. Makine öğrenimi hedefi, ölçülmesi kolay ve "doğru" hedefi temsil eden bir şey olmalıdır. Aslında, genellikle "doğru" bir hedef yoktur (bkz. 39. Kural). Bu nedenle, basit makine öğrenimi hedefiyle çalışın ve son sıralamayı yapmak için ek mantık (umarım çok basit bir mantık) eklemenize olanak tanıyan bir "politika katmanı" ekleyin.

Modellenmesi en kolay şey, doğrudan gözlemlenen ve sistemin yaptığı bir işlemle ilişkilendirilebilen kullanıcı davranışıdır:

  • Bu sıralama bağlantısı tıklandı mı?
  • Bu sıralanan nesne indirildi mi?
  • Bu sıralanan nesne yönlendirildi mi/yanıtlandı mı, e-postayla mı gönderildi?
  • Bu sıralanan nesne derecelendirildi mi?
  • Gösterilen bu nesne spam/pornografi/rahatsız edici olarak işaretlendi mi?

Başlangıçta dolaylı etkileri modellemekten kaçının:

  • Kullanıcı ertesi gün ziyaret etti mi?
  • Kullanıcı siteyi ne kadar süreyle ziyaret etti?
  • Günlük etkin kullanıcı sayısı kaçtı?

Dolaylı etkiler, mükemmel metrikler sağlar ve A/B testi sırasında ve kullanıma sunma kararları sırasında kullanılabilir.

Son olarak, aşağıdakileri tespit etmek için makine öğrenimiyle uğraşmayın:

  • Kullanıcı ürünü kullanmaktan memnun mu?
  • Kullanıcı deneyimden memnun mu?
  • Ürün, kullanıcının genel sağlığını iyileştiriyor mu?
  • Bu durum şirketin genel durumunu nasıl etkileyecek?

Bunların hepsi önemli ancak bunların ölçülmesi son derece zordur. Bunun yerine, proxy'leri kullanın: Kullanıcı mutluysa sitede daha uzun süre kalır. Kullanıcı memnun kalırsa siteyi yarın tekrar ziyaret eder. İşletme sağlığı ve şirket sağlığı açısından önemli olsa da, makine tarafından öğrenilen bir hedef ile sattığınız ürünün doğası ve iş planınız arasında bağlantı kurmak için insan değerlendirmeleri gerekir.

14. Kural: Yorumlanabilir bir modelle başlamak hata ayıklamayı kolaylaştırır.

Doğrusal regresyon, mantıksal regresyon ve Poisson regresyonu, doğrudan olasılıksal bir model tarafından desteklenir. Her tahmin bir olasılık veya beklenen bir değer olarak yorumlanır. Bu, sınıflandırma doğruluğunu veya sıralama performansını doğrudan optimize etmeye çalışan hedefler (sıfır bir kayıp, çeşitli menteşe kayıpları vb.) kullanan modellere kıyasla hata ayıklamayı kolaylaştırır. Örneğin, eğitimdeki olasılıklar yan yana veya üretim sistemini inceleyerek tahmin edilenlerden sapıyorsa bu sapma bir sorunu ortaya çıkarabilir.

Örneğin, doğrusal, mantıksal veya Poisson regresyonunda, ortalama tahmini beklentinin ortalama etikete eşit olduğu (1 an kalibre edilmiş veya sadece kalibre edilmiş) veri alt kümeleri vardır. Bu, herhangi bir normalleştirmenizin olmadığı ve algoritmanızın yakınlaştığı varsayıldığında doğrudur ve genel olarak yaklaşık olarak doğrudur. Her örnek için 1 veya 0 olan bir özelliğiniz varsa bu özelliğin 1 olduğu 3 örnek kümesi kalibre edilir. Ayrıca, her örnek için 1 olan bir özellik kullanıyorsanız tüm örnek kümesi kalibre edilir.

Basit modellerde, geri bildirim döngüleriyle çalışmak daha kolaydır (36. Kural'a bakın). Çoğu zaman karar vermek için şu olasılık tahminleri kullanırız: Örneğin, yayınları beklenen değeri düşürmede sıralarız (ör. tıklama/indirme/vb. olasılığı). Ancak hangi modeli kullanacağınızı seçme zamanı geldiğinde, model göz önünde bulundurulduğunda kararın verilerin olasılığından daha önemli olduğunu unutmayın (27 numaralı kurala bakın).

15. Kural: Spam Filtrelemesini ve Kalite Sıralamasını Politika Katmanında Ayrın.

Kalite sıralaması iyi bir iş olsa da spam filtrelemesi bir mücadeledir. Yüksek kaliteli yayınları belirlemek için kullandığınız sinyaller, sisteminizi kullananlar tarafından kolayca görülebilir ve yayınlarını bu özelliklere sahip olacak şekilde değiştirir. Bu nedenle, kalite sıralamanız iyi niyetle yayınlanan içeriğin sıralamasına odaklanmalıdır. Spam'i yüksek sıraladığı için kalite sıralamasında bir öğrenciyi küçük düşürmemeniz gerekir. Benzer şekilde, "müstehcen" içerikler Kalite Sıralaması'ndan ayrı olarak ele alınmalıdır. Spam filtreleme farklı bir konudur. Oluşturmanız gereken özelliklerin sürekli değişmesini beklemelisiniz. Çoğu zaman sisteme koyacağınız bariz kurallar olur (bir gönderi üçten fazla spam oyu almışsa geri almayın vb.). Öğrenilen modellerin her gün veya daha hızlı güncellenmesi gerekir. İçeriği üreten kişinin itibarı bu konuda önemli bir rol oynar.

Bir düzeyde, bu iki sistemin çıktısının entegre edilmesi gerekir. Arama sonuçlarında spam'i filtrelemenin, e-posta mesajlarındaki spam'leri filtrelemekten muhtemelen daha agresif olması gerektiğini unutmayın. Ayrıca, kalite sınıflandırıcısı için eğitim verilerinden spam'i kaldırmak da standart bir uygulamadır.

Makine Öğrenimi Aşaması II: Özellik Mühendisliği

Bir makine öğrenimi sisteminin yaşam döngüsünün ilk aşamasında önem taşıyan sorunlar eğitim verilerini öğrenim sistemine aktarmak, tüm ilgi metriklerinin izlenmesini sağlamak ve hizmet sunma altyapısı oluşturmaktır. Birim ve sistem testlerinin uygulandığı, çalışan bir uçtan uca sisteminiz olduğunda II. Aşama başlar.

İkinci aşamada, kolayca yapılabilecek birçok şey var. Sisteme aktarılabilecek birtakım bariz özellikler var. Bu nedenle, makine öğreniminin ikinci aşaması, mümkün olduğunca çok özelliği çekip bunları sezgisel şekillerde bir araya getirmeyi içerir. Bu aşamada tüm metrikler hâlâ yükseliyor olmalıdır. Çok sayıda lansman olacak. Tam anlamıyla muhteşem bir öğrenim sistemi oluşturmak için ihtiyacınız olan tüm verileri bir araya getirebilecek mühendisi sürece dahil etmenin tam zamanı.

16. Kural: Lansmanı ve yinelemeyi planlayın.

Şu anda üzerinde çalıştığınız modelin, lansmanı yapacağınız son model olmasını, hatta modelleri piyasaya sürmeyi hiç bırakmayacağınızı beklemeyin. Dolayısıyla, bu lansmanla eklediğiniz karmaşıklığın gelecekteki lansmanları yavaşlatıp yavaşlatmayacağını düşünün. Birçok ekip yıllar boyunca üç aylık veya daha uzun bir süre için bir model kullanıma sundu. Yeni modelleri kullanıma sunmanın üç temel nedeni vardır:

  • Yeni özellikler geliyor.
  • Normalleştirmeyle ilgili ayarlamalar yapıyor ve eski özellikleri yeni yollarla birleştiriyorsunuz.
  • Hedefte ayarlamalar yapıyorsunuz.

Ne olursa olsun, bir modele biraz sevgi göstermek iyi olabilir: Örneği inceleyerek eski ve bozuk sinyallerin yanı sıra yeni sinyalleri de bulabilirsiniz. Dolayısıyla, modelinizi oluştururken özellikleri eklemenin, kaldırmanın veya birleştirmenin ne kadar kolay olduğunu düşünün. Ardışık düzenin yeni bir kopyasını oluşturmanın ve doğruluğunun doğrulanmasının ne kadar kolay olduğunu düşünün. Paralel çalışan iki veya üç kopya olup olmadığını düşünün. Son olarak, 35 özellikten 16'sının, ardışık düzenin bu sürümüne dahil olup olmadığı konusunda endişelenmeyin. Önümüzdeki üç ayda tamamlanacak.

17. Kural: Öğrenilen özellikler yerine doğrudan gözlemlenen ve bildirilen özelliklerle başlayın.

Bu tartışmaya açık bir konu olsa da birçok tehlikeyi ortadan kaldırır. Öncelikle öğrenilen özelliğin ne olduğunu açıklayalım. Öğrenilen özellik, harici bir sistem (gözetilmeyen bir kümeleme sistemi gibi) ya da öğrencinin kendisi tarafından (ör. faktörlü bir model veya derin öğrenme) oluşturulan bir özelliktir. Bunların her ikisi de yararlı olabilir, ancak birçok soruna yol açabilirler, bu nedenle ilk modelde olmamalıdır.

Özellik oluşturmak için harici bir sistem kullanıyorsanız bu harici sistemin kendi amacı olduğunu unutmayın. Harici sistemin hedefi, mevcut hedefinizle çok az bağlantılı olabilir. Harici sistemin anlık görüntüsünü alırsanız bu bilgi güncelliğini yitirebilir. Özellikleri harici sistemden güncellerseniz anlamlar değişebilir. Bir özelliği sunmak için harici bir sistem kullanıyorsanız bu yaklaşımın çok özen gerektirdiğini unutmayın.

Faktöre dahil edilmiş modeller ve derin modellerdeki birincil sorun, dışbükey olmayan olmalarıdır. Bu nedenle, en iyi çözümün yaklaşık olarak bulunabileceği veya bulunabileceği konusunda garanti verilmez ve her iterasyonda bulunan yerel minimum değer farklı olabilir. Bu varyasyon, bir değişikliğin sisteminiz üzerindeki etkisinin anlamlı mı yoksa rastgele mi olduğuna karar vermeyi zorlaştırır. Derin özellikleri olmayan bir model oluşturarak mükemmel bir temel performans elde edebilirsiniz. Bu temel çizgiye ulaşıldıktan sonra, daha ezoterik yaklaşımları deneyebilirsiniz.

18. Kural: Bağlamlara göre genellenen içeriklerin özellikleriyle keşfedin.

Makine öğrenimi sistemi genelde çok daha büyük bir tablonun küçük bir parçasıdır. Örneğin, Popüler Olanlar'da kullanılabilecek bir yayının olduğunu düşünürseniz, birçok kullanıcı Daha Popüler'de gösterilmeden önce bir yayını artı bir şekilde ekler, yeniden paylaşır veya yorum yapar. Öğrenciye bu istatistikleri sağlarsanız, optimize ettiği bağlamda verisi olmayan yeni yayınları tanıtabilir. YouTube Sıradaki Video, YouTube aramasındaki izleme sayısını veya birlikte izleme sayısını (bir videonun diğerinin ardından kaç kez izlendiğinin sayısı) kullanabilir. Ayrıca uygunsuz kullanıcı puanlarını da kullanabilirsiniz. Son olarak, etiket olarak kullandığınız bir kullanıcı işlemi varsa bu işlemi doküman üzerinde farklı bir bağlamda görmek çok faydalı olabilir. Tüm bu özellikler, bağlama yeni içerikler eklemenize olanak tanır. Bunun kişiselleştirmeyle ilgili olmadığını unutmayın: Bir kişinin içeriği bu bağlamda beğenip beğenmediğini önceliklendirin, ardından kimlerin daha çok veya daha az sevdiğini belirleyin.

19. Kural: Mümkün oldukça spesifik özellikleri kullanın.

Tonlarca veri söz konusu olduğunda milyonlarca basit özelliği öğrenmek birkaç karmaşık özelliğe kıyasla daha kolay. Alınan belgelerin tanımlayıcıları ve standartlaştırılmış sorgular fazla genelleme yapmaz ancak sıralamanızı başlık sorgularında etiketlerinizle uyumlu hale getirir. Bu nedenle, her bir özelliğin verilerinizin çok küçük bir bölümüne uygulandığı ancak genel kapsamın %90'ın üzerinde olduğu özellik gruplarından korkmayın. Çok az örneğe uygulanan özellikleri elemek için normalleştirmeyi kullanabilirsiniz.

20. Kural: İnsanların anlayabileceği şekilde yeni özellikler oluşturmak için mevcut özellikleri birleştirin ve değiştirin.

Özellikleri birleştirmenin ve değiştirmenin çeşitli yolları vardır. TensorFlow gibi makine öğrenimi sistemleri, verilerinizi dönüşümler aracılığıyla önceden işlemenize olanak tanır. En standart iki yaklaşım, "ayrımcılık" ve "çarpılar"dır.

Ayrıştırma, sürekli bir özelliği alıp ondan birçok farklı özellik oluşturmayı içerir. Yaş gibi kesintisiz bir özellik üzerine düşünün. Yaş 18'den küçük olduğunda 1 olan başka bir özellik, yaş 18 ile 35 arasında olduğunda 1 olan başka bir özellik oluşturabilirsiniz. Bu histogramların sınırlarını fazla düşünmeyin: Temel yüzdelik dilimler size en büyük etkiyi verir.

Haçlar, iki veya daha fazla özellik sütununu birleştirir. TensorFlow'un terminolojisinde bir özellik sütunu, birbirinden farklı özellikler kümesidir (ör. {male, female}, {US, Canada, Mexico} vb.). Artı, {male, female} × {US,Canada, Mexico} gibi yeni bir özellik sütunudur. Bu yeni özellik sütununda bu özellik (erkek, Kanada) yer alır. TensorFlow kullanıyorsanız ve TensorFlow'a bu geçişi sizin için oluşturmasını söylerseniz, bu (erkek, Kanada) özelliği erkek Kanadalıları temsil eden örneklerde yer alacaktır. Üç, dört veya daha fazla temel özellik sütunu ile kesişen modelleri öğrenmek için çok büyük miktarda veri gerektiğini unutmayın.

Çok büyük özellik sütunları oluşturan haçlar fazla sığabilir. Örneğin, bir tür arama yaptığınızı, sorguda kelimelerin yer aldığı bir özellik sütununuz ve dokümanda kelimelerin yer aldığı bir özellik sütununuz olduğunu düşünün. Bunları bir çarpı işaretiyle birleştirebilirsiniz ancak çok sayıda özellik elde edersiniz (21. Kural'a bakın).

Metin üzerinde çalışırken iki alternatif vardır. En acımasız olanı nokta bir üründür. En basit biçimdeki nokta ürünü, sorgu ve doküman arasında ortak olan kelime sayısını sayar. Daha sonra bu özellik ayırt edilebilir. Başka bir yaklaşım da kesişimdir: Bu nedenle, yalnızca hem belgede hem de sorguda "midilli" kelimesi varsa mevcut olan bir özelliğimiz ve yalnızca hem belgede hem de sorguda "the" kelimesinin yer alması durumunda mevcut olan başka bir özelliğimiz olur.

21. Kural: Doğrusal bir modelde öğrenebileceğiniz özellik ağırlıklarının sayısı, yaklaşık olarak sahip olduğunuz veri miktarıyla orantılıdır.

Bir modele uygun karmaşıklık düzeyiyle ilgili olarak istatistiksel öğrenme teorisi sonuçları etkileyicidir, ancak bilmeniz gereken tek şey bu kuraldır. İnsanların bin örnekten herhangi bir şeyin öğrenilebileceğinden veya bir milyondan fazla örneğe ihtiyaç duyduğundan şüphelendiği, çünkü belirli bir öğrenme yöntemine takılıp kaldığım konuşmalar oldu. Önemli olan, öğrenme sürecinizi verilerinizin boyutuna göre ölçeklendirmektir:

  1. Bir arama sıralama sistemi üzerinde çalışıyorsanız, belgelerde ve sorguda milyonlarca farklı kelime varsa ve 1.000 etiketli örneğiniz varsa belge ile sorgu özellikleri arasında nokta çarpımı, TF-IDF ve yüksek düzeyde insan tarafından geliştirilmiş yarım düzine diğer özellik arasında bir fark kullanmanız gerekir. 1.000 örnek, bir düzine özellik.
  2. Bir milyon örneğiniz varsa normalleştirmeyi ve muhtemelen özellik seçimini kullanarak belge ve sorgu özelliği sütunlarını kesiştirin. Bu şekilde size milyonlarca özellik sunulur ancak normalleştirmeyle daha az özelliğe sahip olursunuz. On milyon örnek, belki yüz bin özellik.
  3. Milyarlarca, yüz milyarlarca örneğiniz varsa belge ve sorgu jetonlarıyla özellik sütunlarını seçerek ve normalleştirmeyi kullanarak özellik sütunlarını aşabilirsiniz. Bir milyar örneğiniz ve 10 milyon özelliğiniz olacak. İstatistiksel öğrenme teorisi nadiren dar sınırlar sunar, ancak bir başlangıç noktası için harika bir rehberlik sunar.

Son olarak, hangi özellikleri kullanacağınıza karar vermek için 28 numaralı kuralı kullanın.

22. Kural: Artık kullanmadığınız özellikleri temizleyin.

Kullanılmayan özellikler teknik borç oluşturur. Bir özelliği kullanmadığınızı ve bu özelliği diğer özelliklerle birleştirmenin çalışmadığını fark ederseniz özelliği altyapınızdan çıkarın. En fazla umut vadeden özelliklerin mümkün olduğunca hızlı bir şekilde denenebilmesi için altyapınızı temiz tutmak istersiniz. Gerekirse birisi özelliğinizi her zaman tekrar ekleyebilir.

Eklenecek veya saklanacak özellikleri düşünürken kapsamı göz önünde bulundurun. Bu özellik kaç örneği kapsar? Örneğin, bazı kişiselleştirme özellikleriniz varsa ancak kullanıcılarınızın yalnızca% 8'inin kişiselleştirme özelliği varsa bu çok etkili olmayacaktır.

Aynı zamanda, bazı özellikler kendi ağırlıklarının üzerinde etkili olabilir. Örneğin, verilerin yalnızca% 1'ini kaplayan bir özelliğine sahipseniz ancak bu özelliğe sahip örneklerin% 90'ı olumluysa eklemek harika bir özellik olacaktır.

Sistemin İnsanlar Tarafından Analiz Edilmesi

Makine öğreniminin üçüncü aşamasına geçmeden önce, makine öğrenimi sınıfında öğretilmeyen bir konuya, yani mevcut bir modele bakma ve onu iyileştirme konusuna odaklanmanız gerekir. Bu, bilimden çok bir sanattır, ancak yine de kaçınılması gereken birkaç karşıt kalıp vardır.

23. Kural: Sıradan bir son kullanıcı değilsiniz.

Ekiplerin sıkışmalarının en kolay yolu budur. Deneme sürümü kullanımı (ekibinizin bünyesinde bir prototip kullanarak) ve (şirketinizde bir prototip kullanarak) test sürümü kullanmanın pek çok avantajı olsa da, çalışanlar performansın doğru olup olmadığını kontrol etmelidir. Bariz bir şekilde kötü olan bir değişiklik kullanılmamalıdır. Ancak üretime yakın gibi görünen herhangi bir değişiklik daha ayrıntılı şekilde test edilmelidir. Bunun için, uzman olmayan kişilere kitle kaynak bulma platformundaki soruları yanıtlamaları için ödeme yapması veya gerçek kullanıcılar üzerinde canlı bir deneme yapılması gerekir.

Bunun iki nedeni var. İlki, koda çok yakın olmanızdır. Yayınların belirli bir yönünü arıyor veya sadece duygusal anlamda fazla dahil oluyorsunuz (ör. onay yanlılığı). İkincisi ise zamanınızın çok değerli olmasıdır. Bir saatlik bir toplantıda oturan dokuz mühendisin maliyetini ve bir kitle kaynağı platformundan kaç sözleşmeli insan etiketi satın aldığını düşünün.

Gerçekten kullanıcı geri bildirimi almak istiyorsanız kullanıcı deneyimi metodolojilerini kullanın. Bir sürecin başlarında kullanıcı karakterleri oluşturun (açıklaması Bill Buxton'ın Kullanıcı Deneyimleri adlı kitabında bir açıklama) ve daha sonra kullanılabilirlik testleri yapın (bu açıklamalardan biri Steve Krug'un Don't Make Me Think adlı oynatma listesinde verilmiştir). Kullanıcı karakterleri, varsayımsal bir kullanıcı oluşturmayı içerir. Örneğin ekibiniz tamamen erkekse 35 yaşındaki kadın kullanıcılardan oluşan bir karakter (kullanıcı özellikleri içeren) tasarlamak ve 25-40 yaş aralığındaki erkekler için 10 sonuç yerine ortaya çıkan sonuçlara bakmak faydalı olabilir. Kullanılabilirlik testi sırasında gerçek kişileri sitenize verdikleri tepkileri (yerel veya uzaktan) izlemeye davet etmek de yeni bir bakış açısı sağlayabilir.

24. Kural: Modeller arasındaki deltayı ölçün.

Herhangi bir kullanıcı yeni modelinizi incelemeden önce yapabileceğiniz en kolay ve bazen en kullanışlı ölçümlerden biri, yeni sonuçların üretimden ne kadar farklı olduğunu hesaplamaktır. Örneğin, bir sıralama sorununuz varsa tüm sistem genelinde her iki modeli bir sorgu örneğinde çalıştırın ve sonuçların simetrik farkının boyutuna (sıralama konumuna göre ağırlıklandırılmış) bakın. Fark çok küçükse, deneme çalıştırmadan çok az değişiklik olacağını söyleyebilirsiniz. Fark çok büyükse, değişikliğin iyi olduğundan emin olmak istersiniz. Simetrik farkın yüksek olduğu sorgulara bakmak, değişikliğin nasıl bir şey olduğunu nitel olarak anlamanıza yardımcı olabilir. Ancak, sistemin kararlı olduğundan emin olun. Kendisiyle karşılaştırıldığında bir modelin düşük (ideal olarak sıfır) bir simetrik farka sahip olduğundan emin olun.

25. Kural: Model seçerken kullanışlılık performansı tahmin gücüne göre önceliklidir.

Modeliniz, tıklama oranını tahmin etmeye çalışabilir. Ancak nihayetinde asıl soru, bu tahminle ne yapacağınızdır. Belgeleri sıralamak için kullanıyorsanız nihai sıralamanın kalitesi tahminin kendisinden daha önemlidir. Bir belgenin spam olma olasılığını tahmin eder ve ardından engellenen öğelerde kesinti olacağını düşünürseniz izin verilenlerin kesinliği daha önemlidir. Çoğu zaman bu iki unsur birbiriyle uyumlu olmalıdır: Uzlaşmadıklarında büyük olasılıkla küçük bir kazanç elde ederler. Bu nedenle, günlük kaybını iyileştiren ancak sistem performansını düşüren bir değişiklik varsa başka bir özellik arayın. Bu durum daha sık gerçekleşmeye başladığında modelinizin hedefini gözden geçirmenin zamanı gelmiş demektir.

26. Kural: Ölçülen hatalarda tekrarlar olup olmadığına bakın ve yeni özellikler oluşturun.

Modelin "yanlış" olduğunu belirten bir eğitim örneği gördüğünüzü varsayalım. Sınıflandırma görevlerinde bu hata, yanlış pozitif veya yanlış negatif olabilir. Bir sıralama görevinde hata, pozitif bir değerin negatiften daha düşük olduğu bir çift olabilir. En önemli nokta, bu durumun makine öğrenimi sisteminin hata yaptığını bildiği ve fırsat bulduğunda düzeltmek istediği bir örnek olmasıdır. Modele hatayı düzeltmesine olanak tanıyan bir özellik verirseniz model, bunu kullanmaya çalışır.

Diğer yandan, örneklere dayalı bir özellik oluşturmaya çalışırsanız sistem hata olarak görmez. Bu özellik yoksayılır. Örneğin, Play Apps Arama'da bir kullanıcının "ücretsiz oyunlar" araması yaptığını varsayalım. En iyi sonuçlardan birinin daha az alakalı bir gag uygulaması olduğunu varsayalım. Bu yüzden "gag uygulamaları" için bir özellik oluşturuyorsunuz. Ancak yükleme sayınızı en üst düzeye çıkarıyorsanız ve kullanıcılar ücretsiz oyun ararken bir gag uygulaması yüklerse "gag uygulamaları" özelliği istediğiniz etkiyi yaratmaz.

Modelin ters gittiğine dair örnekler aldıktan sonra, mevcut özellik grubunuzun dışında trendleri arayın. Örneğin, sistem daha uzun yayınların derecesini düşürüyor gibi görünüyorsa yayın uzunluğunu ekleyin. Eklediğiniz özellikler konusunda çok detaylı olmayın. Yayın uzunluğu ekleyecekseniz ne kadar uzun olduğunu tahmin etmeye çalışmayın. Tek yapmanız gereken bir düzine özellik ekleyip modelin bunlarla ne yapacağını belirlemesine izin vermektir (21. Kural'a bakın). Bu, istediğinizi elde etmenin en kolay yoludur.

27. Kural: Gözlemlenen istenmeyen davranışı ölçmeye çalışın.

Ekibinizin bazı üyeleri, sistemin mevcut kayıp fonksiyonu tarafından yakalanmayan ve beğenmedikleri sistem özellikleri nedeniyle hayal kırıklığına uğramaya başlar. Bu noktada, tutumlarını sağlam sayılara dönüştürmek için ne gerekiyorsa onu yapmalıdır. Örneğin, Play Arama'da çok fazla "gag uygulaması" gösterildiğini düşünüyorlarsa gerçek kişilerden oluşan derecelendirme görevlilerinin gag uygulamalarını tespit etmesini sağlayabilirler. (Bu durumda insan etiketli verileri rahatça kullanabilirsiniz çünkü sorguların küçük bir kısmı trafiğin büyük bir kısmını oluşturur.) Sorunlarınız ölçülebilirse bunları özellik, hedef veya metrik olarak kullanmaya başlayabilirsiniz. Genel kural "önce ölç, sonra optimize et" şeklindedir.

28. Kural: Aynı kısa vadeli davranışın, uzun vadede aynı davranışın aynısı anlamına gelmediğini unutmayın.

Tüm doc_id ve exact_query verilerini inceleyen ve daha sonra her sorgu için her dokümanın tıklama olasılığını hesaplayan yeni bir sisteminiz olduğunu düşünün. Sistemin davranışının, hem yan yana hem de A/B testi açısından mevcut sisteminizle neredeyse aynı olduğunu görüyorsunuz. Bu nedenle, basitliği göz önünde bulundurulduğunda sistemi başlatıyorsunuz. Ancak hiçbir yeni uygulamanın gösterilmediğini fark ediyorsunuz. Neden? Sisteminiz bir dokümanı yalnızca bu sorguyla ilişkili kendi geçmişine dayalı olarak gösterdiğinden, yeni bir dokümanın gösterilmesi gerektiğini öğrenmenin yolu yoktur.

Böyle bir sistemin uzun vadede nasıl çalışacağını anlamanın tek yolu, sistemin yalnızca model kullanıma sunulduğunda elde edilen verilerle eğitilmesini sağlamaktır. Bu çok zordur.

Eğitim-Sunum Sapması

Eğitim-sunum sapması, eğitim sırasındaki performans ile yayın sırasındaki performans arasındaki farktır. Bu sapmanın nedeni aşağıdakilerden biri olabilir:

  • Eğitim ve sunma ardışık düzenlerindeki verileri işleme şekliniz arasında tutarsızlık.
  • Eğitim ve hizmet verdiğiniz zamanlar arasındaki verilerde bir değişiklik.
  • Modeliniz ve algoritmanız arasında bir geri bildirim döngüsü.

Google'da üretim makine öğrenimi sistemlerinin, performansı olumsuz yönde etkileyen eğitim-sunum bozuklukları olduğunu gözlemledik. En iyi çözüm, sistem ve veri değişikliklerinin fark edilmeden sapmaya yol açmaması için veri akışını yakından izlemektir.

29. Kural: Sunum yaptığınız gibi eğittiğinizden emin olmanın en iyi yolu, sunum sırasında kullanılan özellik grubunu kaydetmek ve ardından bu özellikleri eğitim sırasında kullanmak için bir günlüğe kaydetmektir.

Bunu her örnek için yapamasanız bile küçük bir bölüm için yapın. Böylece, yayınlama ile eğitim arasındaki tutarlılığı doğrulayabilirsiniz (37 numaralı kurala bakın). Google'da bu ölçümü yapan ekipler sonuçlar konusunda bazen şaşırtıcıydı. YouTube ana sayfası, sunum sırasında önemli kalite iyileştirmeleri ve kod karmaşıklığında azalma ile günlük kaydı özelliklerine geçti. Pek çok ekip, bu konu hakkında konuşurken altyapılarını değiştiriyor.

30. Kural: Önem derecesi olan örneklenmiş veriler, rastgele bırakmayın!

Çok fazla veriniz olduğunda 1-12 arasındaki dosyaları alıp 13-99 arasındaki dosyaları yoksayabilirsiniz. Bu yanlıştır. Kullanıcıya asla gösterilmeyen veriler atlanabilir olsa da geri kalanlar için önem ağırlıklandırması en iyi seçenektir. Önem ağırlıklandırması, X örneğini% 30 olasılıkla yapmaya karar verirseniz buna 10/3 ağırlığı vermeniz anlamına gelir. Önem açısından ağırlıklandırma kullanıldığında, 14 numaralı kuralda açıklanan tüm kalibrasyon özelliklerinin tamamı değişmez.

31. Kural: Eğitim ve sunum sırasında bir tablodan veri katılırsanız tablodaki verilerin değişebileceğini unutmayın.

Doküman kimliklerini, bu dokümanlara ilişkin özellikleri (yorum veya tıklama sayısı gibi) içeren bir tabloyla birleştirdiğinizi varsayalım. Eğitim ve yayın zamanı arasında tablodaki özellikler değişebilir. Bu durumda modelinizin aynı belgeyle ilgili tahmini, eğitim ve sunma arasında farklılık gösterebilir. Bu tür bir sorunu önlemenin en kolay yolu, özellikleri sunum sırasında günlüğe kaydetmektir (32 numaralı kurala bakın). Tablo çok yavaş değişiyorsa makul ölçüde yakın veriler elde etmek için tablonun saatlik veya günlük anlık görüntüsünü alabilirsiniz. Bunun sorunu yine de tamamen çözmediğini unutmayın.

32. Kural: Mümkün olduğunda eğitim ardışık düzeniniz ile sunma ardışık düzeniniz arasında kodu yeniden kullanın.

Toplu işleme, online işlemeden farklıdır. Online işlemede, gelen her isteği işleme almanız gerekir (ör. her sorgu için ayrı bir arama yapmanız gerekir). Öte yandan, toplu işlemde görevleri birleştirebilirsiniz (ör. birleştirme yapma). Sunum sırasında online işlem yaparken eğitim toplu işlem görevidir. Ancak kodu yeniden kullanmak için yapabileceğiniz bazı şeyler var. Örneğin, herhangi bir sorgu veya birleştirme işleminin sonucunun kullanıcılar tarafından çok okunabilecek bir şekilde depolanabileceği ve hataların kolayca test edilebildiği, sisteminize özel bir nesne oluşturabilirsiniz. Daha sonra, tüm bilgileri topladıktan sonra sunum veya eğitim sırasında sisteminize özel, kullanıcılar tarafından okunabilen nesne ile makine öğrenimi sisteminin istediği biçim arasında köprü kurmak için ortak bir yöntem kullanırsınız. Böylece eğitim sunumunda sapmalar ortadan kaldırılır. Sonuç olarak, eğitim ve sunum arasında iki farklı programlama dili kullanmamaya çalışın. Bu karar, kodu paylaşmanızı neredeyse imkansız hale getirir.

33. Kural: 5 Ocak'a kadar verilere dayalı bir model üretirseniz modeli 6 Ocak ve sonrasına ait veriler üzerinde test edin.

Genel olarak bir modelin performansını, modeli eğittiğiniz verilerden sonra toplanan veriler üzerinde ölçün. Bu, sisteminizin üretimde ne yapacağını daha iyi yansıtır. 5 Ocak'a kadar olan verilere dayalı bir model üretirseniz modeli 6 Ocak'a ait veriler üzerinde test edin. Yeni verilerde performansın eskisi kadar iyi olmayacağını bekleyebilirsiniz, ancak bu, büyük ölçüde daha kötü olmayacaktır. Günlük etkiler olabileceğinden ortalama tıklama oranını veya dönüşüm oranını tahmin edemeyebilirsiniz ancak pozitif örneğe negatif örnekten daha yüksek bir puan verme olasılığını temsil eden eğrinin altındaki alan makul ölçüde yakın olmalıdır.

34. Kural: Filtreleme için ikili sınıflandırmada (spam algılama veya ilgi çekici e-postaları belirleme gibi) çok temiz veriler için performansta kısa süreli küçük ödünler verin.

Filtreleme görevinde, negatif olarak işaretlenen örnekler kullanıcıya gösterilmez. Sunum sırasında negatif örneklerin% 75'ini engelleyen bir filtreniz olduğunu varsayalım. Kullanıcılara gösterilen örneklerden ek eğitim verileri çekmek cazip gelebilir. Örneğin, bir kullanıcı filtrenizin izin verdiği bir e-postayı spam olarak işaretliyorsa bundan bilgi edinmek isteyebilirsiniz.

Ancak bu yaklaşım, örnekleme yanlılığına yol açar. Sunum sırasında bunun yerine tüm trafiğin% 1'ini "beklemede" olarak etiketler ve sunulan tüm örnekleri kullanıcıya gönderirseniz daha temiz veriler toplayabilirsiniz. Artık filtreniz, negatif örneklerin en az% 74'ünü engellemektedir. Gösterilen bu örnekler, eğitim verileriniz olabilir.

Filtreniz, olumsuz örneklerin% 95'ini veya daha fazlasını engelliyorsa bu yaklaşımın geçerliliğini yitirdiğini unutmayın. Bununla birlikte, sunum performansını ölçmek istiyorsanız daha da küçük bir örnek oluşturabilirsiniz (örneğin, %0,1 veya %0,001). Performansı oldukça doğru bir şekilde tahmin etmek için on bin örnek yeterlidir.

35. Kural: Sıralama problemlerinin yapısı nedeniyle sapmaya dikkat edin.

Sıralama algoritmanızı farklı sonuçların gösterileceği kadar köklü bir şekilde değiştirdiğinizde algoritmanızın gelecekte göreceği verileri de etkili bir şekilde değiştirmiş olursunuz. Böyle bir sapma ortaya çıkar ve modelinizi buna göre tasarlamanız gerekir. Birçok farklı yaklaşım vardır. Bu yaklaşımların hepsi, modelinizin önceden gördüğü verileri desteklemenin yollarıdır.

  1. Yalnızca tek bir sorgu için açık olan özelliklere kıyasla daha fazla sorguyu kapsayan özelliklerde daha yüksek düzenlileştirme elde edin. Bu şekilde model, tüm sorguları genelleyen özellikler yerine bir veya birkaç sorguya özel özellikleri tercih eder. Bu yaklaşım, çok popüler sonuçların alakasız sorgulara sızmasını önlemeye yardımcı olabilir. Bunun, daha benzersiz değerlere sahip özellik sütunlarını daha fazla normalleştirme tavsiyesinin tam tersi olduğunu unutmayın.
  2. Özelliklerin yalnızca pozitif ağırlıklara sahip olmasına izin ver. Böylece, iyi bir özellik "bilinmeyen" bir özellikten daha iyi olacaktır.
  3. Yalnızca doküman özelliklerini kullanmayın. Bu, 1 numaralı uygulamanın ekstrem bir sürümüdür. Örneğin, belirli bir uygulama, sorgu ne olursa olsun popüler bir indirme işlemi olsa bile bu uygulamayı her yerde göstermek istemezsiniz. Yalnızca belge gerektiren özelliklerin olmaması bunu basitleştirir. Belirli bir popüler uygulamanın her yerde gösterilmesini istememenizin nedeni, istenen tüm uygulamaları erişilebilir kılmanın önemidir. Örneğin, bir kullanıcı "kuş izleme uygulaması" için arama yaparsa "angry Birds" indirmesi yapabilir, ancak bu kullanıcının amacı kesinlikle bu değildi. Bu tür bir uygulamayı göstermek indirme oranını artırabilir, ancak nihayetinde kullanıcının ihtiyaçlarını karşılamaz.

36. Kural: Konumlandırma özellikleri içeren geri bildirim döngülerinden kaçının.

İçeriğin konumu, kullanıcının içerikle etkileşim kurma olasılığını önemli ölçüde etkiler. Bir uygulamayı ilk konuma getirirseniz daha sık tıklanır ve tıklanma olasılığının daha yüksek olduğuna inanırsınız. Bunu çözmenin bir yolu, konumsal özellikler (yani içeriğin sayfadaki konumuyla ilgili özellikler) eklemektir. Modelinizi konumlandırma özellikleriyle eğitirsiniz ve model, örneğin "1. konum" özelliğini yoğun bir şekilde ağırlıklandırmayı öğrenir. Dolayısıyla modeliniz, "1stposition=true" değerine sahip örnekler için diğer faktörlere daha az ağırlık verir. Daha sonra sunum sırasında hiçbir örneğe konumsal özelliği vermeyiz veya adayları hangi sırayla göstereceğinize karar vermeden önce puanladığınız için onlara aynı varsayılan özelliği verirsiniz.

Eğitim ve test arasındaki bu simetrik nedeniyle tüm konum özelliklerini modelin geri kalanından biraz ayrı tutmanın önemli olduğunu unutmayın. Modelin, konumlandırmasal özelliklerin bir fonksiyonu ile geri kalan özelliklerin bir fonksiyonunun toplamı olması idealdir. Örneğin, herhangi bir belge özelliğiyle konumsal özellikleri aşmayın.

37. Kural: Eğitim/Sunum Sapmasını Ölç.

En genel anlamda sapmaya neden olabilecek birkaç şey vardır. Dahası, bütçeyi birkaç bölüme ayırabilirsiniz:

  • Eğitim verilerindeki performans ile bloke edilen verilerdeki performans arasındaki fark. Genel olarak, bu her zaman var olacaktır ve her zaman kötü değildir.
  • Duraklatma verileri ile "sonraki gün" verilerindeki performans arasındaki fark. Bu da her zaman var olacak. Sonraki günlük performansı en üst düzeye çıkarmak için normalleştirmenizi ayarlamalısınız. Ancak bekletme ve sonraki gün verileri arasındaki performanstaki büyük düşüşler, bazı özelliklerin zamana duyarlı olduğunu ve model performansını düşürebileceğini gösterebilir.
  • "Sonraki gün" verileri ile canlı verilerdeki performans arasındaki fark. Eğitim verilerindeki bir örneğe ve yayın aşamasında aynı örneğe bir model uygularsanız modelin tam olarak aynı sonucu vermesi gerekir (5. Kural'a bakın). Bu nedenle, buradaki bir tutarsızlık büyük olasılıkla bir mühendislik hatasına işaret eder.

ML Aşama III: Yavaş Büyüme, Optimizasyon İyileştirme ve Karmaşık Modeller

İkinci aşamanın kapanışa yaklaştığına dair belirli göstergeler olacak. Öncelikle, aylık kazancınız azalmaya başlar. Metrikler arasında fark görmeye başlarsınız: Bazı denemelerde bazı metriklerde artış, bazılarında ise düşüşler görürsünüz. İşler burada ilginç hale gelir. Kazançlara ulaşmak daha zor olduğundan makine öğreniminin daha gelişmiş olması gerekiyor. Dikkat: Bu bölümde önceki bölümlere göre daha fazla mavi gökyüzü kuralı var. Birçok ekibin Aşama I ve Aşama II makine öğreniminin mutlu zamanlarından geçtiğini gördük. III. Aşamaya ulaşıldıktan sonra, ekiplerin kendi yollarını bulmaları gerekir.

38. Kural: Sorun, uyumsuz hedefler ortaya çıktıysa yeni özelliklerle zaman kaybetmeyin.

Ölçümleriniz düzeldikçe ekibiniz mevcut makine öğrenimi sisteminizin hedeflerinin kapsamı dışındaki sorunlara bakmaya başlar. Daha önce de belirtildiği gibi, ürün hedefleri mevcut algoritmik amaç kapsamında değilse hedefinizi ya da ürün hedeflerinizi değiştirmeniz gerekir. Örneğin, tıklamaları, artı birleri veya indirmeleri optimize edebilir, ancak kısmen gerçek kişi olan derecelendirme yapan kişilere dayalı lansman kararları verebilirsiniz.

39. Kural: Lansman kararları uzun vadeli ürün hedefleri için gösterge niteliğindedir.

Ayşe'nin yükleme tahminlerinde lojistik kaybını azaltmak için bir fikri var. Bir özellik ekliyor. Lojistik kaybı düşer. Bir deneme yaptığında yükleme oranında artış görüyor. Ancak lansman değerlendirme toplantısına gittiğinde birisi günlük etkin kullanıcı sayısının %5 azaldığını belirtiyor. Ekip, modeli kullanıma sunmamaya karar verir. Alice bu konuda hayal kırıklığına uğramakla birlikte, lansman kararlarının birden fazla kriteri temel aldığını ve bu kriterlerden yalnızca bazıları doğrudan makine öğrenimi kullanılarak optimize edilebileceğini fark ediyor.

Gerçek dünyada zindanlar ve ejderhalar yoktur. Ürününüzün sağlık durumunu tanımlayan hiçbir "isabet noktası" yoktur. Ekip, sistemin gelecekte ne kadar iyi olacağını etkili bir şekilde tahmin edebilmek için topladığı istatistikleri kullanmalıdır. Etkileşim, 1 günlük etkin kullanıcı sayısı (GEKS), 30 GEKS, gelir ve reklamverenin yatırım getirisine önem vermesi gerekir. Kendi başlarına A/B testlerinde ölçülebilen bu metrikler, kullanıcıları memnun etmek, kullanıcıları artırmak, iş ortaklarını memnun etmek ve kâr sağlamak gibi daha uzun vadeli hedeflerin sadece bir göstergesidir. Hatta beş yıl sonra bile yararlı ve yüksek kaliteli bir ürüne ve başarılı bir şirkete sahip olmak için dolaylı bilgileri düşünebilirsiniz.

Kullanıma sunmayla ilgili tek kolay karar, tüm metriklerin daha iyi hale gelmesi (veya en azından daha kötü hale gelmemesi) olur. Ekibin, gelişmiş bir makine öğrenimi algoritması ile basit bir bulgusal yöntem arasından seçim yapması durumunda, basit buluşsal yöntemin tüm bu metriklerde daha başarılı olması durumunda, bulgusal yöntemi seçmelidir. Ayrıca, tüm olası metrik değerlerinin açık bir sıralaması yoktur. Özellikle aşağıdaki iki senaryoyu göz önünde bulundurun:

Deneme Günlük Etkin Kullanıcı Sayısı Gelir/Gün
CEVAP 1 milyon 4 milyon dolar
B 2 milyon 2 milyon dolar

Mevcut sistem A ise ekibin B sistemine geçme olasılığı düşüktür. Mevcut sistem B ise ekibin A'ya geçme olasılığı düşüktür. Bu, rasyonel davranışla çelişiyor gibi görünse de, metriklerdeki değişikliklerle ilgili tahminler başarılı olabilir veya olmayabilir. Bu nedenle, her iki değişikliğin de beraberinde getirdiği büyük bir risk vardır. Her metrik, ekibin ilgilendiği bazı riskleri kapsar.

Dahası, hiçbir metrik ekibin nihai endişesini kapsamaz: "Ürünüm bundan sonra nerede olacak?"

Öte yandan bireyler, doğrudan optimize edebilecekleri tek bir hedefi tercih etme eğilimindedir. Çoğu makine öğrenimi aracı bu tür ortamları tercih eder. Yeni özellikleri ortaya çıkaran bir mühendis, böyle bir ortamda sürekli olarak lansman akışı elde edebilir. Bu sorunu çözmeye odaklanan çok amaçlı öğrenim türünde bir makine öğrenimi türü var. Örneğin, her metriğin daha düşük sınırları olan ve bazı doğrusal metrik kombinasyonlarını optimize eden kısıtlı bir memnuniyet problemi formüle edilebilir. Ancak bu durumda bile tüm metrikler makine öğrenimi hedefi olarak kolayca çerçevelenemez: Bir belge tıklandığında veya uygulama yüklenirse bunun nedeni içeriğin gösterilmesidir. Ancak, bir kullanıcının sitenizi neden ziyaret ettiğini anlamak çok daha zordur. Bir sitenin bir bütün olarak gelecekteki başarısını tahmin etmek, AI-complete: bilgisayar görüşü veya doğal dil işleme kadar zordur.

40. Kural: Toplulukları basit tutun.

Ham özellikleri alan ve içeriği doğrudan sıralayan birleştirilmiş modeller, hata ayıklaması ve anlaşılması en kolay modellerdir. Bununla birlikte, bir model topluluğu (diğer modellerin puanlarını birleştiren bir "model") daha iyi çalışabilir. İşin basitliğini korumak için her model, yalnızca diğer modellerin girdilerini alan bir derleme veya birçok özelliği (ikisi birden değil) temel alan bir temel model olmalıdır. Ayrı olarak eğitilen diğer modellerin dışında modelleriniz varsa bunları birleştirmek kötü davranışlara neden olabilir.

Yalnızca "temel" modellerinizin çıkışını giriş olarak alan basit bir birleştirme modeli kullanın. Bu topluluk modellerinde özellikleri uygulamak da istiyorsunuz. Örneğin, bir temel model tarafından oluşturulan puandaki artış, topluluğun puanını azaltmamalıdır. Ayrıca, temeldeki modellerde yapılan değişikliklerin bütün modelde karışıklığa yol açmaması için gelen modellerin anlamsal olarak yorumlanabilir olması (ör. kalibre edilmesi) en iyi seçenektir. Ayrıca, temel sınıflandırıcının tahmin edilen olasılığındaki artışın, topluluğun öngörülen olasılığını azaltmamasını sağlayın.

41. Kural: Performans düştüğünde, mevcut sinyalleri hassaslaştırmak yerine nitel olarak yeni bilgi kaynakları arayın.

Kullanıcı hakkında bazı demografik bilgiler eklediniz. Belgedeki kelimeler hakkında bazı bilgiler eklediniz. Şablon keşfinden geçtiniz, normalleştirmeyi düzenlediniz. Birkaç çeyrek içinde temel metriklerinizde% 1'den fazla iyileşme elde eden bir lansman görmediniz. Şimdi önemli olan nedir?

Kullanıcının son gün, hafta veya yıl içinde eriştiği belgelerin geçmişi ya da farklı bir mülkten gelen veriler gibi, tamamen farklı özellikler için altyapı oluşturmaya başlamanın zamanı geldi. wikidata varlıklarını veya şirketinize özgü bir unsuru (Google'ın bilgi grafiği gibi) kullanın. Derin öğrenmeyi kullanın. Ne kadar yatırım getirisi elde edebileceğinizle ilgili beklentilerinizi ayarlamaya başlayın ve çabalarınızı buna göre genişletin. Her mühendislik projesinde olduğu gibi, yeni özellikler eklemenin faydasını, artan karmaşıklığın maliyetiyle karşılaştırarak değerlendirmeniz gerekir.

42. Kural: Çeşitliliğin, kişiselleştirmenin veya alaka düzeyinin popülerlikle sizin kadar alakalı olmasını beklemeyin.

Bir içerik grubunda çeşitlilik birçok anlama gelebilir. İçerik kaynağının çeşitliliği en yaygın olanlardan biridir. Kişiselleştirme, her kullanıcının kendi sonuçlarını alacağı anlamına gelir. Alaka düzeyi, belirli bir sorgu için sonuçların o sorgu için diğer sorgulardan daha uygun olduğu anlamına gelir. Dolayısıyla bu özelliklerin üçü de sıradandan farklı olarak tanımlanır.

Sorun şu ki, sıradan olanı yenmek zor olma eğiliminde.

Sisteminiz tıklama sayısı, harcanan süre, izlemeler, +1'ler, yeniden paylaşımlar ve benzeri metrikleri ölçüyorsa içeriğin popülerliğini ölçtüğünüzü unutmayın. Ekipler bazen çeşitliliği kullanarak kişisel bir model öğrenmeye çalışırlar. Kişiselleştirmek için, sistemin kişiselleştirmesine (kullanıcının ilgi alanını temsil eden bazı özellikler) veya çeşitlendirmesine (bu belgenin, yazar veya içerik gibi döndürülen diğer belgelerde ortak bir özellik olup olmadığını gösteren özellikler) izin veren özellikler ekler ve bu özelliklerin beklediğinden daha az ağırlık aldığını (veya bazen farklı bir işaret aldığını) görürler.

Bu durum çeşitlilik, kişiselleştirme veya alaka düzeyinin değerli olmadığı anlamına gelmez. Önceki kuralda belirtildiği gibi, çeşitliliği veya alaka düzeyini artırmak için son işleme yapabilirsiniz. Daha uzun vadeli hedeflerde artış görüyorsanız popülerliğin yanı sıra çeşitliliğin/alaka düzeyinin de değerli olduğunu belirtebilirsiniz. Sonrasında işleme sonrası sürecinizi kullanmaya devam edebilir veya çeşitliliğe ya da alaka düzeyine göre hedefi doğrudan değiştirebilirsiniz.

43. Kural: Arkadaşlarınız farklı ürünlerde genellikle aynı olur. İlgi alanlarınız genelde öyle değil.

Google'daki ekipler, bir üründeki bağlantının yakınlığını tahmin eden bir model alıp başka bir üründe de iyi sonuç veriyor. Arkadaşlarınız kim olduklarıdır. Öte yandan, ürün dağılımındaki kişiselleştirme özellikleri konusunda mücadele eden birkaç ekibin olduğunu gördüm. Evet, işe yarayacak gibi görünüyor. Şimdilik böyle görünmüyor. Bir mülkteki ham verileri kullanarak diğer mülkteki davranışı tahmin etmek bazen işe yarar. Ayrıca, bir kullanıcının başka bir mülkle ilgili geçmişinin olduğunu bilmek bile yardımcı olabilir. Örneğin, iki üründe kullanıcı etkinliğinin varlığı tek başına bir gösterge olabilir.

Hem Google'da hem de şirket dışında makine öğrenimiyle ilgili birçok doküman mevcuttur.

Teşekkür

David Westbrook, Peter Brandt, Jamuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Mustafa Ispir, Jeremiah Harmsen ve Konstantiw Ayrıca, önceki bir sürümde yardımcı olan Kristen Lefevre, Sudha Basu ve Chris Berg'e de teşekkür ederiz. Hatalar, eksiklikler veya hoşnutsuzluklar bana ait.

Ek

Bu dokümanda Google ürünlerine çeşitli referanslar bulunmaktadır. Daha fazla bağlam sağlamak için aşağıda en yaygın örneklerin kısa bir açıklamasını veriyorum.

YouTube'a Genel Bakış

YouTube bir video yayını hizmetidir. Hem YouTube Sıradaki Video hem de YouTube Ana Sayfası ekipleri video önerilerini sıralamak için makine öğrenimi modellerini kullanır. Sıradakini İzle, şu anda oynatılan videodan sonra izlenecek videolar önerirken Ana Sayfa, ana sayfaya göz atan kullanıcılara video önerir.

Google Play'e Genel Bakış

Google Play'de çeşitli sorunları çözen birçok model vardır. Play Arama, Play Ana Sayfası Kişiselleştirilmiş Öneriler ve "Kullanıcılar Ayrıca Yükledi" uygulamalarının tümü makine öğrenimini kullanır.

Google Artı'ya Genel Bakış

Google Plus, makine öğrenimini çeşitli durumlarda kullandı: Yayınları, kullanıcının gördüğü yayınların "akışında" sıralama, "Popüler Olanlar" yayınlarını (şu anda çok popüler olan yayınlar) sıralama ve tanıdığınız kişileri sıralama vb. Google Plus, 2019'da tüm kişisel hesapları kapattı ve 6 Temmuz 2020'de işletme hesapları için Google Currents'ın yerini aldı.