Makine Öğrenimi Kuralları:

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

Martin Zinkevich

Bu doküman, makine öğrenimi hakkında temel düzeyde bilgi sahibi olan kullanıcıların Google'ın makine öğrenimiyle ilgili en iyi uygulamalarından yararlanmasına yardımcı olmayı amaçlamaktadır. Google C++ Stil Kılavuzu ve pratik programlamaya yönelik diğer popüler kılavuzlara benzer şekilde makine öğrenimi için bir stil sunar. Makine öğrenimi dersi aldıysanız veya makine öğrenimi modelleri oluşturduysanız ya da bu modeller üzerinde çalıştıysanız bu dokümanı okumak için gerekli temel bilgilere sahipsiniz demektir.

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

Terminoloji

Etkili makine öğrenimi hakkındaki tartışmamızda aşağıdaki terimler tekrar tekrar geçecektir:

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

Genel Bakış

Mükemmel ürünler oluşturmak için:

Makine öğrenimini, olmadığınız mükemmel makine öğrenimi uzmanı gibi değil, olduğunuz mükemmel mühendis gibi yapın.

Karşılaşacağınız sorunların çoğu aslında mühendislik sorunlarıdır. İyi bir makine öğrenimi uzmanının tüm kaynaklarına sahip olsanız bile kazanımların çoğu, iyi makine öğrenimi algoritmalarından değil, iyi özelliklerden gelir. Temel yaklaşım şu şekildedir:

  1. Dönüşüm hunilerinizin uçtan uca sağlam olduğundan emin olun.
  2. Makul bir hedef belirleyin.
  3. Basit bir şekilde sağduyulu özellikler ekleyin.
  4. Dönüşüm huninizin sağlam kalmasını sağlayın.

Bu yaklaşım uzun süre boyunca işe yarayacaktır. Bu yaklaşımdan yalnızca daha fazla ilerlemenizi sağlayacak basit hileler kalmadığında uzaklaşın. Karmaşıklık eklemek, gelecekteki sürümleri yavaşlatır.

Basit hileleri denedikten sonra, ileri düzey makine öğrenimi sizin için de uygun olabilir. III. Aşama makine öğrenimi projeleri bölümüne bakın.

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

  1. İlk bölüm, makine öğrenimi sistemi oluşturmanın doğru zaman olup olmadığını anlamanıza yardımcı olacaktır.
  2. İkinci bölüm, ilk ardışık düzeninizi dağıtmayla ilgilidir.
  3. Üçüncü bölüm, ardışık düzeninize yeni özellikler eklerken modelleri nasıl değerlendireceğiniz, modelleri nasıl eğiteceğiniz ve modelleri sunarken nasıl bir sapma oluşabileceği ile ilgilidir.
  4. Son bölümde, bir platoya ulaştığınızda ne yapmanız gerektiği ele alınmaktadır.
  5. Ardından, ilgili çalışmaların listesi ve bu belgede örnek olarak yaygın olarak kullanılan sistemlerle ilgili bazı bilgiler içeren bir ek yer alır.

Makine Öğrenimi'nden önce

1. Kural: Makine öğrenimi içermeyen bir ürün lansmanı yapmaktan çekinmeyin.

Makine öğrenimi harikadır ancak veri gerektirir. Teorik olarak, farklı bir sorundan veri alıp modeli yeni bir ürün için değiştirebilirsiniz ancak bu, temel heuristic'lerden daha düşük performans gösterecektir. Makine öğreniminin size% 100 artış sağlayacağını düşünüyorsanız bir sezgisel yöntem, bu hedefe ulaşma yolunda size %50'lik bir katkı sağlar.

Örneğin, bir uygulama mağazasındaki uygulamaları sıralıyorsanız yükleme oranını veya yükleme sayısını heuristikler olarak kullanabilirsiniz. Spam tespit ediyorsanız daha önce spam göndermiş yayıncıları filtreleyin. Gerçek kişiler tarafından yapılan düzenlemelerden de yararlanabilirsiniz. Kişileri sıralamanız gerekiyorsa en son kullanılanları en üstte (veya alfabetik olarak) sıralayın. Ürününüz için makine öğrenimi kesinlikle gerekli değilse verileriniz olana kadar kullanmayın.

2. Kural: Önce metrikleri tasarlayın ve uygulayın.

Makine öğrenimi sisteminizin ne yapacağını belirlemeden önce mevcut sisteminizde mümkün olduğunca fazla veri izleyin. Bunun nedeni aşağıdakilerden biri olabilir:

  1. Sistemin kullanıcılarından daha önce izin almak daha kolaydır.
  2. Gelecekte sorun oluşturabilecek bir durum olabileceğini düşünüyorsanız geçmiş verileri şimdi almanız daha iyidir.
  3. Sisteminizi metrik enstrümantasyonu göz önünde bulundurarak tasarlarsanız gelecekte daha iyi sonuçlar elde edersiniz. Daha açık belirtmek gerekirse, metriklerinizi ayarlamak için günlüklerdeki dizelerde grep komutunu kullanmak istemezsiniz.
  4. Nelerin değiştiğini ve nelerin aynı kaldığını fark edeceksiniz. Örneğin, doğrudan bir günlük etkin kullanıcılar için optimizasyon yapmak istediğinizi varsayalım. Ancak sistem üzerinde yaptığınız ilk işlemler sırasında, kullanıcı deneyiminde yapılan önemli değişikliklerin bu metriği önemli ölçüde değiştirmediğini fark edebilirsiniz.

Google Plus ekibi, okuma başına genişleme, okuma başına yeniden paylaşım, okuma başına +1, okuma başına yorum, kullanıcı başına yorum, kullanıcı başına yeniden paylaşım vb. ölçümler yapar ve bu ölçümleri, yayın sırasında bir yayının ne kadar iyi olduğunu hesaplamak için kullanır. Ayrıca, kullanıcıları gruplara ayırabileceğiniz ve istatistikleri denemeye göre toplayabileceğiniz bir deneme çerçevesinin önemli olduğunu unutmayın. 12. Kural'a bakın.

Metrik toplama konusunda daha özgür davranarak sisteminizin daha geniş bir resmini elde edebilirsiniz. Sorun mu fark ettiniz? İzlemek için bir metrik ekleyin. Son sürümdeki bazı nicel değişikliklerden heyecan duyuyor musunuz? İzlemek için bir metrik ekleyin.

3. Kural: Karmaşık bir sezgisel yöntem yerine makine öğrenimini tercih edin.

Basit bir sezgisel yaklaşım, ürününüzün satışa sunulmasını sağlayabilir. Karmaşık bir sezgisel yöntem sürdürülebilir değildir. Verileriniz ve neyi başarmaya çalıştığınız hakkında temel bir fikriniz olduğunda makine öğrenimine geçin. Çoğu yazılım mühendisliği görevinde olduğu gibi, yaklaşımınızı (heuristic veya makine öğrenimi modeli olsun) sürekli olarak güncellemek istersiniz. Ayrıca, makine öğrenimi modelinin güncellenmesi ve bakımı daha kolaydır (Kural 16'ya bakın).

ML I. Aşama: İlk Ardışık Düzeniniz

İlk ardışık düzeniniz için sistem altyapınıza odaklanın. Yapacağınız tüm yaratıcı makine öğrenimi işlemlerini düşünmek eğlenceli olsa da önce ardışık düzeninize güvenmezseniz neler olduğunu anlamak zor olacaktır.

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

İlk model, ürününüze en büyük artışı sağlar. Bu nedenle, modelin çok gelişmiş olması gerekmez. Ancak beklediğinizden çok daha fazla altyapı sorunuyla karşılaşacaksınız. Yeni ve gelişmiş makine öğrenimi sisteminizi kullanabilmeleri için kullanıcıların aşağıdakileri belirlemesi gerekir:

  • Öğrenme algoritmanıza örnek ekleme
  • Sisteminiz için "iyi" ve "kötü"nün ne anlama geldiğine dair ilk kesme noktası.
  • Modelinizi uygulamanıza entegre etme. Modeli canlı olarak uygulayabilir veya modelin örnekleri çevrimdışı olarak önceden hesaplamasını sağlayıp sonuçları bir tabloda saklayabilirsiniz. Ö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 özellikler seçmek, aşağıdakileri sağlamanı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 bir şekilde yapan bir sisteme sahip olduğunuzda işin büyük kısmını tamamlamış olursunuz. Basit modeliniz, daha karmaşık modelleri test etmek için kullanabileceğiniz referans metrik ve referans davranış sağlar. Bazı ekipler, dikkatin dağılmasını önlemek için makine öğrenimi kazanımlarına açıkça öncelik vermeyen "nötr" bir 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 bölümlerinin, etrafındaki her şeyi test edebilmeniz için kapsüllendiğinden emin olun. Özellikle:

  1. Algoritmaya veri aktarmayı test edin. Doldurulması gereken özellik sütunlarının doldurulup doldurulmadığını kontrol edin. Gizliliğin izin verdiği durumlarda, eğitim algoritmanıza giren verileri manuel olarak inceleyin. Mümkünse ardışık düzeninizdeki istatistikleri, başka bir yerde işlenen aynı verilerin istatistikleriyle karşılaştırın.
  2. Eğitim algoritmasından model alma işlemini test edin. Eğitim ortamınızdaki modelin, yayınlama ortamınızdaki modelle aynı puanı verdiğinden emin olun (Kural #37'ye bakın).

Makine öğrenimi öngörülemez bir unsura sahiptir. Bu nedenle, eğitim ve yayınlama sırasında örnek oluşturmak için kodunuza yönelik testler yaptığınızdan ve yayınlama sırasında sabit bir model yükleyip kullanabileceğinizden emin olun. Ayrıca verilerinizi anlamak da önemlidir: Büyük ve Karmaşık Veri Kümelerinin Analizi İçin Pratik Tavsiyeler başlıklı makaleyi inceleyin.

6. Kural: Boru hatlarını kopyalarken bırakılan verilere dikkat edin.

Genellikle mevcut bir ardışık düzeni kopyalayarak ardışık düzen oluştururuz (ör. kargo kültü programlama) ve eski ardışık düzen, yeni ardışık düzen için ihtiyaç duyduğumuz verileri düşürür. Örneğin, Google Plus'taki Trendler akışında eski yayınlar kaldırılır (çünkü yeni yayınları sıralamaya çalışır). Bu ardışık düzen, eski yayınların hâlâ anlamlı olduğu Google Plus Akışı için kullanılmak üzere kopyalandı ancak ardışık düzen eski yayınları atmaya devam ediyordu. Yaygın bir kalıp da yalnızca kullanıcı tarafından görüntülenen verileri günlüğe kaydetmektir. Bu nedenle, tüm negatif örnekler atlandığı için belirli bir yayını kullanıcının neden görmediğini modellemek isterseniz bu veriler işe yaramaz. Play'de de benzer bir sorun oluştu. Play Uygulamaları Ana Sayfası üzerinde çalışırken, Play Games açılış sayfasından örnekler içeren ve her bir örneğin nereden geldiğini açıklığa kavuşturacak herhangi bir özellik içermeyen yeni bir ardışık düzen oluşturuldu.

7. Kural: Heuristics'i özelliklere dönüştürün veya harici olarak yönetin.

Makine öğreniminin çözmeye çalıştığı sorunlar genellikle tamamen yeni değildir. Çözmeye çalıştığınız sıralama, sınıflandırma veya başka bir sorun için mevcut bir sistem var. Bu, bir dizi kural ve sezgisel kural olduğu anlamına gelir. Aynı sezgisel kurallar, makine öğrenimiyle ayarlandığında size artış sağlayabilir. Heuristics'leriniz, iki nedenden dolayı sahip oldukları tüm bilgiler için kazılmalıdır. Öncelikle, makine öğrenimi sistemine geçiş daha sorunsuz olur. İkincisi, bu kurallar genellikle sistemle ilgili atlamak istemeyeceğiniz birçok sezgi içerir. Mevcut bir sezgisel yöntemi dört şekilde kullanabilirsiniz:

  • Buluşsal yöntemi kullanarak ön işleme yapın. Özellik gerçekten çok iyiyse bu seçeneği kullanabilirsiniz. Örneğin, bir spam filtresinde gönderen kara listeye eklenmişse "kara listeye eklenmiş" ifadesinin ne anlama geldiğini yeniden öğrenmeye çalışmayın. Mesajı engelleyin. Bu yaklaşım, ikili sınıflandırma görevlerinde en uygun olanıdır.
  • Özellik oluşturun. Heuristic'ten doğrudan bir özellik oluşturmak harika. Örneğin, bir sorgu sonucu için alaka düzeyi puanını hesaplamak üzere bir sezgisel yöntem kullanıyorsanız puanı bir özelliğin değeri olarak dahil edebilirsiniz. Daha sonra, değer üzerinde işlem yapmak için makine öğrenimi tekniklerini kullanabilirsiniz (örneğin, değeri sonlu bir ayrık değer grubundan birine dönüştürerek veya diğer özelliklerle birleştirerek). Ancak, keşif yöntemi tarafından üretilen ham değeri kullanarak başlayın.
  • Heuristic'in ham girişlerini kazıyın. Uygulamalar için yükleme sayısını, metindeki karakter sayısını ve haftanın gününü birleştiren bir keşif varsa bu parçaları ayırıp bu girişleri öğrenmeye ayrı ayrı beslemeyi düşünebilirsiniz. Toplu çalışmalar için geçerli olan bazı teknikler burada da geçerlidir (40. Kural'a bakın).
  • Etiketi değiştirin. Bu seçenek, sezgisel algoritmanın şu anda etikette bulunmayan bilgileri yakaladığını düşündüğünüzde kullanılabilir. Örneğin, indirme sayısını en üst düzeye çıkarmaya çalışırken aynı zamanda kaliteli içerik de istiyorsanız etiketi uygulamanın aldığı ortalama yıldız sayısıyla çarpabilirsiniz. Burada çok fazla esneklik var. "İlk Hedefiniz" bölümüne bakın.

Bir yapay zeka sisteminde sezgisel yaklaşımları kullanırken ek karmaşıklığa dikkat edin. Yeni makine öğrenimi algoritmanızda eski sezgisel kuralları 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ı uygulanabilir hale getirmek ve kontrol paneli sayfası oluşturmak gibi iyi uyarı hijyeni uygulamalarına uyun.

8. Kural: Sisteminizin güncellik koşullarını öğrenin.

Bir gün önce oluşturulmuş bir modeliniz varsa performans ne kadar düşer? Bir hafta önce mi? Çeyrek yaşında mı? Bu bilgiler, izlemenizin önceliklerini anlamanıza yardımcı olabilir. Model bir gün boyunca güncellenmezse önemli ölçüde ürün kalitesi kaybediyorsanız bir mühendisin modeli sürekli olarak izlemesi mantıklı olur. Çoğu reklam sunma sisteminin her gün işlemesi gereken yeni reklamlar vardır ve bu sistemlerin günlük olarak güncellenmesi gerekir. Örneğin, Google Play Arama için ML modeli güncellenmezse bir aydan kısa bir süre içinde olumsuz bir etki görebilirsiniz. Google Plus'ta Öne Çıkanlar için bazı modellerde gönderi tanımlayıcısı olmadığından bu modeller nadiren dışa aktarılabilir. Yayın kimlikleri olan diğer modeller çok daha sık güncellenir. Ayrıca, özellikle modelinize özellik sütunları eklendiğinde veya modelinizden kaldırıldığında tazeliğin zaman içinde değişebileceğini unutmayın.

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

Birçok makine öğrenimi sisteminde, modeli yayınlamak için dışa aktardığınız bir aşama bulunur. Dışa aktarılan bir modelle ilgili bir sorun varsa bu kullanıcıya yönelik bir sorundur.

Modeli dışa aktarmadan hemen önce doğruluk kontrolleri yapın. Özellikle, modelin performansının ayrılan verilerde makul olduğundan emin olun. Verilerle ilgili endişeleriniz varsa model 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ılmamış modellerle ilgili sorunlar için e-posta uyarısı gerekir ancak kullanıcılara yönelik bir modeldeki sorunlar için sayfa gerekebilir. Bu nedenle, kullanıcıları etkilemeden önce bekleyip emin olmanız daha iyi olur.

10. Kural: Sessiz hatalara dikkat edin.

Bu sorun, diğer sistem türlerine kıyasla makine öğrenimi sistemlerinde daha sık görülür. Birleştirilen belirli bir tablonun artık güncellenmediğini varsayalım. Makine öğrenimi sistemi ayarlanır ve davranış, kademeli olarak azalarak makul düzeyde iyi olmaya devam eder. Bazen aylarca güncellenmemiş tablolar görebilirsiniz. Basit bir yenileme, performansı o çeyrekte yapılan diğer tüm lansmanlardan daha fazla artırır. Bir özelliğin kapsamı, uygulama değişiklikleri nedeniyle değişebilir. Örneğin, bir özellik sütunu örneklerin% 90'ında doldurulurken aniden örneklerin% 60'ına düşebilir. Play'de 6 ay boyunca güncellenmemiş bir tablo vardı. Yalnızca tabloyu yenilemek, yükleme oranında% 2 artış sağladı. Verilerin istatistiklerini izler ve zaman zaman verileri manuel olarak incelerseniz bu tür hataları azaltabilirsiniz.

11. Kural: Özellik sütunlarına sahipler ve dokümanlar atayın.

Sistem büyükse ve çok sayıda özellik sütunu varsa her özellik sütununu kimin oluşturduğunu veya sürdürdüğünü öğrenin. Bir özellik sütununu anlayan kişinin ayrıldığını fark ederseniz bu bilgilere sahip olan başka bir kişi olduğundan emin olun. 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ği hakkında daha ayrıntılı bir açıklamaya sahip olmak iyi bir fikirdir.

İlk Hedefiniz

Önem verdiğiniz sistemle ilgili birçok metriğiniz veya ölçümünüz vardır ancak makine öğrenimi algoritmanız genellikle tek bir hedefe (algoritmanızın "optimize etmeye çalıştığı" bir sayıya) ihtiyaç duyar. Burada hedefler ile metrikler arasında ayrım yapıyorum: Metrik, sisteminizin raporladığı ve önemli olup olmayacağı değişen bir sayıdır. 2. Kural'a da bakın.

12. Kural: Doğrudan optimize etmek için hangi hedefi seçeceğinizi fazla düşünmeyin.

Para kazanmak, kullanıcılarınızı mutlu etmek ve dünyayı daha iyi bir yer hâline getirmek istiyorsunuz. Önemsediğiniz çok sayıda 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 etmediğiniz metriklerin bile yükseldiğini fark edeceksiniz. Örneğin, tıklama sayısını ve sitede geçirilen süreyi önemsediğinizi varsayalım. Tıklama sayısı için optimizasyon yaparsanız harcanan sürenin arttığını görebilirsiniz.

Bu nedenle, basit bir yol izleyin ve tüm metrikleri kolayca artırabildiğiniz halde farklı metrikleri dengeleme konusunda çok fazla düşünmeyin. Ancak bu kuralı çok fazla zorlamayın: Hedefinizi, sistemin nihai sağlığıyla karıştırmayın (Kural 39'a bakın). Ayrıca, doğrudan optimize edilen metriği artırdığınız halde lansman yapmamaya karar verirseniz bazı hedef düzeltmeleri gerekebilir.

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

Gerçek hedefin ne olduğunu genellikle bilmezsiniz. Bildiğinizi düşünürsünüz ancak eski sisteminizin ve yeni yapay zeka sisteminizin yan yana analizine ve verilere bakarken hedefte değişiklik yapmak istediğinizi fark edersiniz. Ayrıca, farklı ekip üyeleri genellikle gerçek hedef konusunda anlaşamaz. Makine öğrenimi hedefi, ölçülmesi kolay ve "gerçek" hedefin proxy'si olan bir şey olmalıdır. Aslında genellikle "gerçek" bir hedef yoktur (Kural 39'a bakın). Bu nedenle, basit ML hedefi üzerinde eğitin ve nihai sıralamayı yapmak için ek mantık (umarım çok basit mantık) eklemenize olanak tanıyan bir "politika katmanı" kullanmayı düşünün.

Modellenmesi en kolay kullanıcı davranışı, doğrudan gözlemlenen ve sistemin bir işlemiyle ilişkilendirilebilen davranıştır:

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

İlk başta dolaylı etkileri modellemekten kaçının:

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

Dolaylı etkiler mükemmel metrikler oluşturur ve A/B testi sırasında ve lansman kararları sırasında kullanılabilir.

Son olarak, makine öğreniminin çözmesini istemeyin:

  • 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 önemlidir ancak ölçülmesi son derece zordur. Bunun yerine proxy'ler kullanın: Kullanıcı memnun olursa sitede daha uzun süre kalır. Kullanıcı memnun kalırsa yarın tekrar ziyaret eder. Sağlığın ve şirketinizin durumunun korunması söz konusu olduğunda, makine öğrenimi ile elde edilen hedefleri sattığınız ürünün yapısına ve işletme planınıza bağlamak için insan yargısı gerekir.

Kural 14: 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 modelden esinlenir. Her tahmin, olasılık veya beklenen değer olarak yorumlanabilir. Bu, sınıflandırma doğruluğunu veya sıralama performansını doğrudan optimize etmeye çalışan hedefleri (sıfır-bir kaybı, çeşitli menteşe kayıpları vb.) kullanan modellere kıyasla bu modellerde hata ayıklama işlemini kolaylaştırır. Örneğin, eğitimdeki olasılıklar, karşılaştırmalarda veya üretim sistemini inceleyerek tahmin edilen olasılıklardan farklıysa bu sapma bir sorunun göstergesi olabilir.

Örneğin, doğrusal, mantıksal veya Poisson regresyonunda ortalama tahmin edilen beklentinin ortalama etikete eşit olduğu veri alt kümeleri vardır (1-moment kalibre edilmiş veya yalnızca kalibre edilmiş). Bu, normalleştirme yapmadığınız ve algoritmanızın birleştiği varsayıldığında doğrudur ve genel olarak yaklaşık olarak doğrudur. Her örnek için 1 veya 0 değerine sahip bir özelliğiniz varsa bu özelliğin 1 olduğu 3 örnek grubu kalibre edilir. Ayrıca, her örnek için 1 değerine sahip bir özelliğiniz varsa tüm örneklerin kümesi kalibre edilir.

Basit modellerde geri bildirim döngüleriyle çalışmak daha kolaydır (Kural 36'ya bakın). Karar vermek için genellikle bu olasılıksal tahminleri kullanırız: Örneğin, gönderileri azalan beklenen değere (ör. tıklama/indirme olasılığı) göre sıralayın. Ancak, hangi modelin kullanılacağını seçerken veriye dayalı modelin veri olasılığından daha önemli olduğunu unutmayın (Kural 27'ye bakın).

Kural 15: Spam Filtrelemeyi ve Kalite Sıralamasını Politika Katmanında Ayırın.

Kalite sıralaması bir sanattır ancak spam filtreleme bir savaştır. Yüksek kaliteli yayınları belirlemek için kullandığınız sinyaller, sisteminizi kullananlar tarafından anlaşılır ve bu özelliklerle yayınlarını düzenlerler. Bu nedenle, kalite sıralamanızda dürüstlükle yayınlanan içeriklerin sıralanmasına odaklanılmalıdır. Spam'i yüksek sıraya koyduğu için kalite sıralaması öğrenicisini göz ardı etmemelisiniz. Benzer şekilde, "müstehcen" içerikler de Kalite Sıralaması'ndan ayrı olarak ele alınmalıdır. Spam filtreleme ise farklı bir konudur. Oluşturmanız gereken özelliklerin sürekli değişeceğini göz önünde bulundurmanız gerekir. Genellikle sisteme koyduğunuz bariz kurallar vardır (bir yayın üçten fazla spam oy aldıysa yayını alma vb.). Öğrenilen tüm modellerin daha hızlı olmasa da günlük olarak güncellenmesi gerekir. İçerik üreticinin itibarı büyük rol oynar.

Bu iki sistemin çıktısının bir düzeyde entegre edilmesi gerekir. Arama sonuçlarındaki spam'in filtrelenmesinin, e-posta iletilerindeki spam'in filtrelenmesinden daha agresif olması gerektiğini unutmayın. Ayrıca, kalite sınıflandırıcının eğitim verilerinden spam'i kaldırmak standart bir uygulamadır.

ML 2. Aşama: Özellik Mühendisliği

Bir makine öğrenimi sisteminin yaşam döngüsünün ilk aşamasında önemli konular arasında eğitim verilerini öğrenme sistemine aktarma, ilgilenilen tüm metrikleri enstrümante etme ve yayınlama altyapısı oluşturma yer alır. Birim ve sistem testlerinin entegre edildiği, çalışan bir uçtan uca sisteminiz olduktan sonra II. Aşama başlar.

İkinci aşamada, kolayca ulaşılabilecek çok sayıda hedef vardır. Sisteme dahil edilebilecek çeşitli belirgin özellikler vardır. Bu nedenle, makine öğreniminin ikinci aşaması mümkün olduğunca çok özellik çekmeyi ve bunları sezgisel yollarla birleştirmeyi içerir. Bu aşamada tüm metrikler hâlâ yükseliyor olmalıdır. Birçok lansman olacak. Bu, gerçekten harika bir öğrenme sistemi oluşturmak için ihtiyaç duyduğunuz tüm verileri birleştirebilecek çok sayıda mühendisi işe almak için mükemmel bir zaman.

16. Kural: Lansman ve iterasyon planlayın.

Şu anda üzerinde çalıştığınız modelin, kullanıma sunacağınız son model olacağını veya model yayınlamayı bırakacağınızı düşünmeyin. Bu nedenle, bu lansmanla eklediğiniz karmaşıklığın gelecekteki lansmanları yavaşlatıp yavaşlatmayacağını düşünün. Birçok ekip, yıllarca üç ayda bir veya daha sık model yayınlamıştır. Yeni modeller yayınlamanın üç temel nedeni vardır:

  • Yeni özellikler geliştiriyorsunuz.
  • Düzenlemeyi ayarlıyor ve eski özellikleri yeni şekillerde birleştiriyorsunuz.
  • Hedefi ayarlıyorsunuz.

Yine de bir modele biraz ilgi göstermek iyi olabilir: Örneğe beslenen verilere göz atmak, hem yeni hem de eski ve bozuk sinyalleri bulmanıza yardımcı olabilir. Bu nedenle, modelinizi oluştururken özellikleri eklemenin, kaldırmanın veya yeniden birleştirmenin ne kadar kolay olduğunu düşünün. Ardışık düzenin yeni bir kopyasını oluşturmanın ve doğruluğunu doğrulamanın ne kadar kolay olduğunu düşünün. Paralel olarak iki veya üç kopya çalıştırmanın mümkün olup olmadığını düşünün. Son olarak, 35 özellikten 16'sının ardışık düzenin bu sürümüne eklenip eklenmeyeceği konusunda endişelenmeyin. Önümüzdeki çeyrekte alırsınız.

Kural 17: Öğrenilmiş özelliklerin aksine doğrudan gözlemlenen ve raporlanan özelliklerle başlayın.

Bu, tartışmalı bir nokta olabilir ancak birçok tuzağa düşmenizi önler. Öncelikle, öğrenilen özelliğin ne olduğunu açıklayalım. Öğrenilmiş özellik, harici bir sistem (ör.gözetimsiz küme oluşturma sistemi) veya öğrenmenin kendisi (ör. faktörlü model veya derin öğrenme aracılığıyla) tarafından oluşturulan bir özelliktir. Her ikisi de yararlı olabilir ancak çok fazla soruna yol açabileceğinden ilk modelde bulunmamalıdır.

Bir özellik oluşturmak için harici bir sistem kullanıyorsanız harici sistemin kendi hedefini olduğunu unutmayın. Harici sistemin hedefi, mevcut hedefinizle yalnızca zayıf bir şekilde ilişkili olabilir. Harici sistemin anlık görüntüsünü alırsanız bu görüntü güncelliğini yitirebilir. Özellikleri harici sistemden güncellerseniz anlamları değişebilir. Bir özelliği sağlamak için harici bir sistem kullanıyorsanız bu yaklaşımın çok dikkatli bir şekilde uygulanması gerektiğini unutmayın.

Faktörlü modeller ve derin modellerle ilgili temel sorun, bunların dışbükey olmamasıdır. Bu nedenle, optimum bir çözümün yaklaşık olarak bulunabileceği veya bulunabileceğine dair bir garanti yoktur ve her iterasyonda bulunan yerel minimumlar farklı olabilir. Bu varyasyon, sisteminizde yapılan bir değişikliğin etkisinin anlamlı mı yoksa rastgele mi olduğunu değerlendirmeyi zorlaştırır. Derin özellikler içermeyen bir model oluşturarak mükemmel bir temel performans elde edebilirsiniz. Bu temele ulaştıktan sonra daha gizemli yaklaşımları deneyebilirsiniz.

18. Kural: Bağlamlar arasında genelleştirilebilen içerik özellikleriyle keşfedin.

Makine öğrenimi sistemleri genellikle çok daha büyük bir resmin küçük bir parçasıdır. Örneğin, Öne Çıkanlarda kullanılabilecek bir yayın düşünün. Birçok kullanıcı, Öne Çıkanlarda gösterilmeden önce yayına beğenme, yeniden paylaşma veya yorum yapma işlemi uygular. Bu istatistikleri kullanıcıya sağlarsanız kullanıcı, optimize ettiği bağlamda veri bulunmayan yeni yayınları tanıtabilir. YouTube Sıradaki Video özelliği, YouTube aramasından görüntüleme sayısını veya birlikte izleme sayısını (bir videonun başka bir videodan sonra kaç kez izlendiğinin sayısı) kullanabilir. Belirli kullanıcı puanlarını da kullanabilirsiniz. Son olarak, etiket olarak kullandığınız bir kullanıcı işlemi varsa bu işlemi dokümanda farklı bir bağlamda görmek harika bir özellik olabilir. Bu özelliklerin tümü, bağlama yeni içerikler eklemenize olanak tanır. Bunun kişiselleştirmeyle ilgili olmadığını unutmayın: Öncelikle kullanıcıların bu bağlamda içeriği beğenip beğenmediğini, ardından içeriği daha çok veya daha az kimlerin beğendiğini öğrenin.

19. Kural: Mümkün olduğunda çok spesifik özellikleri kullanın.

Tonlarca veri olduğunda, birkaç karmaşık özellikten ziyade milyonlarca basit özelliği öğrenmek daha kolaydır. Alınan belgelerin tanımlayıcıları ve standartlaştırılmış sorgular çok fazla genelleme sağlamaz ancak sıralamanızı başlık sorgularındaki etiketlerinizle uyumlu hale getirir. Bu nedenle, her özelliğin verilerinizin çok küçük bir kısmı için geçerli olduğu ancak genel kapsamın %90'ın üzerinde olduğu özellik gruplarından korkmayın. Çok az sayıda örnek için geçerli olan özellikleri ortadan kaldırmak üzere normalleştirmeyi kullanabilirsiniz.

20. Kural: Kullanıcıları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, dönüşümler aracılığıyla verilerinizi ön işleme almanıza olanak tanır. En standart iki yaklaşım "değer ayrımı" ve "çaprazlar"dır.

Discontinuity, sürekli bir özelliği alıp bundan birçok ayrı özellik oluşturmaktan oluşur. Yaş gibi sürekli bir özelliği düşünün. Yaş 18'den küçük olduğunda 1 değerini, yaş 18 ile 35 arasında olduğunda 1 değerini vb. döndüren bir özellik oluşturabilirsiniz. Bu histogramların sınırlarını fazla düşünmeyin: Etkinin büyük kısmını temel yüzdelik dilimler size sunar.

Çaprazlar iki veya daha fazla özellik sütununu birleştirir. TensorFlow'un terminolojisinde özellik sütunu, homojen özelliklerden oluşan bir kümedir (ör. {erkek, kadın}, {ABD, Kanada, Meksika} vb.). Çapraz, örneğin {erkek, kadın} × {ABD, Kanada, Meksika} gibi özellikler içeren yeni bir özellik sütunudur. Bu yeni özellik sütunu, özelliği (erkek, Kanada) içerir. TensorFlow kullanıyorsanız ve TensorFlow'a bu kesişimi sizin için oluşturmasını söylerseniz bu (erkek, Kanada) özelliği, Kanadalı erkekleri temsil eden örneklerde bulunur. Üç, dört veya daha fazla temel özellik sütununun çaprazlamasını içeren modelleri öğrenmek için çok fazla veri gerektiğini unutmayın.

Çok büyük özellik sütunları oluşturan çaprazlamalar aşırı uyum sağlayabilir. Örneğin, bir tür arama yaptığınızı ve sorguda kelimeler içeren bir özellik sütununuz olduğunu ve belgede kelimeler içeren bir özellik sütununuz olduğunu düşünün. Bunları bir çarpı ile birleştirebilirsiniz ancak çok fazla özellik elde edersiniz (21. Kural'a bakın).

Metinle çalışırken iki alternatif vardır. En katı olanı nokta çarpımıdır. En basit haliyle nokta çarpımı, sorgu ile belge arasında ortak kelime sayısını hesaplar. Bu özellik daha sonra diskritleştirilebilir. Başka bir yaklaşım da kesişimdir: Böylece, yalnızca "pony" kelimesi hem dokümanda hem de sorguda varsa mevcut olan bir özelliğe ve yalnızca "the" kelimesi hem dokümanda hem de sorguda varsa mevcut olan başka bir özelliğe sahip oluruz.

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

Bir model için uygun karmaşıklık düzeyiyle ilgili ilginç istatistiksel öğrenme teorisi sonuçları vardır ancak bilmeniz gereken temel şey bu kuraldır. Belirli bir öğrenme yöntemine takılıp kalarak bin örnekten bir şey öğrenilip öğrenilemeyeceği veya bir milyondan fazla örneğe ihtiyaç duyup duyulmayacağı konusunda şüpheleri olan kişilerle konuştum. Öğrenme sürecinizi verilerinizin boyutuna göre ölçeklendirmeniz önemlidir:

  1. Bir arama sıralama sistemi üzerinde çalışıyorsanız ve dokümanlarda ile sorguda milyonlarca farklı kelime varsa ve 1.000 etiketli örneğiniz varsa doküman ve sorgu özellikleri, TF-IDF ve insan tarafından tasarlanmış yarım düzine başka özellik arasında nokta çarpımı kullanmanız gerekir. 1.000 örnek, bir düzine özellik.
  2. Bir milyon örneğiniz varsa normalleştirme ve muhtemelen özellik seçimini kullanarak doküman ve sorgu özellik sütunlarını kesiştirin. Bu sayede milyonlarca özellik elde edersiniz ancak normalleştirmeyle daha az özellik elde edersiniz. On milyon örnek, belki yüz bin özellik.
  3. Milyarlarca veya yüz milyarlarca örneğiniz varsa özellik seçimi ve normalleştirmeyi kullanarak özellik sütunlarını doküman ve sorgu jetonlarıyla çaprazlayabilirsiniz. Bir milyar örnek ve 10 milyon özellik elde edersiniz. İstatistiksel öğrenme teorisi nadiren sıkı sınırlar verir ancak başlangıç noktası için mükemmel bir rehberlik sağlar.

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

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

Kullanılmayan özellikler teknik borç oluşturur. Bir özelliği kullanmadığınızı ve diğer özelliklerle birlikte kullanıldığında işe yaramadığını fark ederseniz bu özelliği altyapınızdan çıkarın. En umut verici özelliklerin mümkün olduğunca hızlı bir şekilde denenebilmesi için altyapınızı temiz tutmak istersiniz. Gerekirse özelliğiniz her zaman tekrar eklenebilir.

Hangi özellikleri ekleyeceğinizi veya tutacağınızı belirlerken kapsamı göz önünde bulundurun. Bu özellik kaç örnek içeriyor? Örneğin, bazı kişiselleştirme özellikleriniz varsa ancak kullanıcılarınızın yalnızca% 8'inde kişiselleştirme özellikleri varsa bu çok etkili olmayacaktır.

Aynı zamanda bazı özellikler, ağırlıklarının üzerinde performans gösterebilir. Örneğin, verilerin yalnızca% 1'ini kapsayan ancak bu özelliğe sahip örneklerin% 90'ının olumlu olduğu bir özelliği eklemek iyi bir fikirdir.

Sistemin İnsan Tarafından Analizi

Makine öğreniminin üçüncü aşamasına geçmeden önce, hiçbir makine öğrenimi sınıfında öğretilmeyen bir konuya odaklanmak önemlidir: Mevcut bir modeli inceleme ve iyileştirme. Bu, bilimden çok bir sanattır. Yine de, kaçınmanıza yardımcı olacak birkaç anti-pattern vardır.

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

Bu, bir ekibin tıkanmasının belki de en kolay yoludur. Balık yemi (prototipi ekibinizde kullanma) ve köpek yemi (prototipi şirketinizde kullanma) yöntemlerinin birçok avantajı olsa da çalışanların performansın doğru olup olmadığını kontrol etmesi gerekir. Açıkça kötü olan bir değişiklik kullanılmamalıdır ancak üretime yakın görünen her şey, kitle kaynaklı bir platformda soruları yanıtlamaları için sıradan kullanıcılara ödeme yapılarak veya gerçek kullanıcılar üzerinde canlı bir deneme yapılarak daha ayrıntılı bir şekilde test edilmelidir.

Bunun iki nedeni vardır. Birincisi, koda çok yakın olmanızdır. Yayınların belirli bir yönünü arıyor veya konuyla duygusal olarak çok fazla ilgileniyor olabilirsiniz (ör. onay yanlılığı). İkincisi, zamanınız çok değerli. Bir saatlik toplantıda bulunan dokuz mühendisin maliyetini ve kitle kaynaklı bir platformda kaç tane sözleşmeli insan etiketi satın aldığını düşünün.

Kullanıcı geri bildirimi almak istiyorsanız kullanıcı deneyimi metodolojilerini kullanın. Kullanıcı karakterleri oluşturun (Bill Buxton'un Sketching User Experiences kitabında bu konu hakkında bilgi verilmektedir) ve sürecin başlarında bunu yapın. Daha sonra kullanılabilirlik testi yapın (Steve Krug'un Don’t Make Me Think kitabında bu konu hakkında bilgi verilmektedir). Kullanıcı karakterleri, varsayımsal bir kullanıcı oluşturmayı içerir. Örneğin, ekibinizin tamamı erkekse 25-40 yaş aralığındaki erkekler için 10 sonuç yerine 35 yaşında bir kadın kullanıcı kimliği (kullanıcı özellikleriyle birlikte) tasarlayıp bu kimliğin oluşturduğu sonuçlara bakmak yararlı olabilir. Kullanılabilirlik testinde sitenize tepkilerini izlemek için gerçek kullanıcılar da getirebilirsiniz (yerel olarak veya uzaktan). Bu sayede yeni bir bakış açısı edinebilirsiniz.

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

Hiçbir kullanıcı yeni modelinize bakmadan önce yapabileceğiniz en kolay ve bazen en yararlı ölçümlerden biri, yeni sonuçların üretimden ne kadar farklı olduğunu hesaplamaktır. Örneğin, sıralama sorunu yaşıyorsanız her iki modeli de sistemin tamamında bir sorgu örneği üzerinde ç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 yapmadan çok az değişiklik olacağını anlayabilirsiniz. Fark çok büyükse değişikliğin iyi olduğundan emin olmak istersiniz. Simetrik farkın yüksek olduğu sorguları incelemek, değişikliğin nasıl olduğunu niteliksel olarak anlamanıza yardımcı olabilir. Ancak sistemin kararlı olduğundan emin olun. Bir modelin kendisiyle karşılaştırıldığında simetrik farkının düşük (ideal olarak sıfır) olduğundan emin olun.

Kural #25: Model seçerken faydacı performans, tahmin gücünden daha önemlidir.

Modeliniz tıklama oranını tahmin etmeye çalışabilir. Ancak en önemli soru, bu tahmini ne şekilde kullanacağınızdır. Belgeleri sıralamak için kullanıyorsanız nihai sıralamanın kalitesi, tahminin kendisinden daha önemlidir. Bir dokümanın spam olma olasılığını tahmin edip engellenecek içerikler için bir sınır belirlerseniz izin verilen içeriklerin doğruluğu daha önemlidir. Çoğu durumda bu iki değer birbirine yakındır. Değerler birbirinden farklı olduğunda, bu genellikle küçük bir kazançla ilgilidir. Bu nedenle, günlük kaybını iyileştiren ancak sistemin 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 tekrar gözden geçirmeniz gerekir.

Kural 26: Ölçülen hatalarda kalıplar arayın ve yeni özellikler oluşturun.

Modelin "yanlış" yanıt verdiği bir eğitim örneği gördüğünüzü varsayalım. Sınıflandırma görevinde bu hata yanlış pozitif veya yanlış negatif olabilir. Sıralama görevinde, pozitif bir öğenin negatif bir öğeden daha düşük sıralandığı bir çift olabilir. En önemli nokta, bu durumun makine öğrenimi sisteminin hatalı olduğunu bildiği ve fırsat verilirse düzeltmek istediği bir örnek olmasıdır. Modele hatayı düzeltmesine olanak tanıyan bir özellik verirseniz model bunu kullanmayı dener.

Öte yandan, sistemin hata olarak görmediği örneklere dayalı bir özellik oluşturmaya çalışırsanız özellik yok sayılır. Örneğin, bir kullanıcının Play Uygulamalar Arama'da "ücretsiz oyunlar" araması yaptığını varsayalım. En başarılı sonuçlardan birinin, alakalılığı daha düşük bir şaka uygulaması olduğunu varsayalım. Bu durumda "şaka uygulamaları" için bir özellik oluşturursunuz. Ancak yükleme sayısını en üst düzeye çıkarıyorsanız ve kullanıcılar ücretsiz oyun aradığında şaka uygulaması yüklüyorsa "şaka uygulaması" özelliği istediğiniz etkiyi yaratmaz.

Modelin yanlış tahmin ettiği örnekleri bulduktan sonra mevcut özellik grubunuzun dışındaki trendleri arayın. Örneğin, sistem daha uzun gönderileri sıralamada geriye alıyorsa gönderi uzunluğunu ekleyin. Eklediğiniz özellikler konusunda çok ayrıntılı olmayın. Yayın uzunluğunu ekliyorsanız uzun kelimesinin ne anlama geldiğini tahmin etmeye çalışmayın. Sadece bir düzine özellik ekleyin ve modelin bunlarla ne yapacağını bulmasına izin verin (21. Kural'a bakın). İstediğiniz sonucu elde etmenin en kolay yolu budur.

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

Ekibinizin bazı üyeleri, mevcut kayıp işlevi tarafından yakalanmayan ve sistemde hoşlanmadıkları özelliklerden rahatsız olmaya başlar. Bu noktada, şikayetlerini somut rakamlara dönüştürmek için gereken her şeyi yapmalıdırlar. Örneğin, Play Arama'da çok fazla "şaka uygulaması" gösterildiğini düşünüyorlarsa gerçek kişilerden oluşan değerlendirme ekibine şaka uygulamalarını tanımlamalarını isteyebilirler. (Sorguların nispeten küçük bir kısmı trafiğin büyük bir kısmını oluşturduğundan bu durumda insan tarafından etiketlenmiş verileri kullanabilirsiniz.) Sorunlarınız ölçülebilirse bunları özellik, hedef veya metrik olarak kullanmaya başlayabilirsiniz. Genel kural "önce ölçün, sonra optimize edin" şeklindedir.

Kural #28: Kısa vadede aynı davranışın uzun vadede aynı davranışı göstermeyeceğini unutmayın.

Her doc_id ve exact_query değerine bakan ve ardından her sorgu için her dokümanın tıklanma olasılığını hesaplayan yeni bir sisteminiz olduğunu varsayalım. Hem yan yana karşılaştırmalarda hem de A/B testlerinde davranışının mevcut sisteminizle neredeyse aynı olduğunu görüyorsunuz. Bu nedenle, basitliği nedeniyle sistemi kullanıma sunuyorsunuz. Ancak yeni uygulama gösterilmediğini fark edersiniz. Neden? Sisteminiz yalnızca bu sorguyla ilgili kendi geçmişine dayalı bir doküman gösterdiğinden yeni bir dokümanın gösterilmesi gerektiğini öğrenmenin bir yolu yoktur.

Bu tür bir sistemin uzun vadede nasıl çalışacağını anlamanın tek yolu, yalnızca model yayınlandığında edinilen verilerle eğitmesini sağlamaktır. Bu çok zor.

Eğitim ve sunma arası sapma

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

  • Eğitim ve sunma ardışık düzenlerinde verileri işleme şekliniz arasında tutarsızlık.
  • Eğitim verdiğiniz zaman ile reklam yayınladığınız zaman arasında verilerde değişiklik olması.
  • Modeliniz ile algoritmanız arasında bir geri bildirim döngüsü.

Google'da, performansı olumsuz yönde etkileyen eğitim-yayınlama sapması olan üretim makine öğrenimi sistemleri gözlemledik. En iyi çözüm, sistem ve veri değişikliklerinin fark edilmeden sapma oluşturmaması için bu metriği açıkça izlemektir.

Kural #29: Eğitimi, yayınladığınız gibi yaptığınızdan emin olmanın en iyi yolu, yayınlama sırasında kullanılan özellik grubunu kaydetmektir. Ardından, bu özellikleri eğitim sırasında kullanmak için bir günlüke aktarın.

Bunu her örnek için yapamıyorsanız küçük bir örnek için yapın. Böylece, yayınlama ve eğitim arasındaki tutarlılığı doğrulayabilirsiniz (Kural #37'ye bakın). Google'da bu ölçümü yapan ekipler bazen sonuçlara şaşırıyordu. YouTube ana sayfası, önemli kalite iyileştirmeleri ve kod karmaşıklığında azalma sağlayan yayınlama sırasında günlük kaydı özelliklerine geçti. Şu anda birçok ekip de altyapısını bu özelliklere geçiriyor.

Kural 30: Önem ağırlıklı örneklenmiş verileri keyfi olarak atmayın.

Çok fazla veriniz varsa 1-12 arasındaki dosyaları alıp 13-99 arasındaki dosyaları yoksaymak isteyebilirsiniz. Bu yanlıştır. Kullanıcıya hiç gösterilmeyen veriler atılabilir ancak geri kalan veriler için önem ağırlığı en iyi seçenektir. Önem ağırlığı, X örneğini% 30 olasılıkla örnekleyeceğinize karar verirseniz ona 10/3 ağırlığı vermeniz anlamına gelir. Önem ağırlığıyla, 14. Kural'da ele alınan tüm kalibrasyon özellikleri geçerliliğini korur.

Kural #31: Eğitim ve yayınlama sırasında bir tablodaki verileri birleştirirseniz tablodaki verilerin değişebileceğini unutmayın.

Doküman kimliklerini, bu dokümanlara ait özellikleri (ör. yorum sayısı veya tıklama sayısı) içeren bir tabloyla birleştirdiğinizi varsayalım. Eğitim ve yayınlama zamanı arasında tablodaki özellikler değiştirilebilir. Bu durumda, modelinizin aynı doküman için tahmini, eğitim ve sunma aşamaları arasında farklılık gösterebilir. Bu tür sorunları önlemenin en kolay yolu, özellikleri yayınlama zamanında günlüğe kaydetmektir (Kural #32'ye bakın). Tablo yalnızca yavaşça değişiyorsa makul ölçüde yakın veriler elde etmek için tablonun anlık görüntüsünü saatlik veya günlük olarak da alabilirsiniz. Bu işlemin sorunu tamamen çözmediğini unutmayın.

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

Toplu işleme, online işlemeden farklıdır. Online işleme sırasında her isteği geldikçe işlemeniz gerekir (ör. her sorgu için ayrı bir arama yapmanız gerekir), toplu işleme sırasında ise görevleri birleştirebilirsiniz (ör. birleştirme yapabilirsiniz). Yayınlama sırasında online işlem yapıyorsunuzdur. Eğitim ise toplu işleme görevidir. Ancak kodu yeniden kullanmak için yapabileceğiniz bazı işlemler vardır. Örneğin, sisteminize özel bir nesne oluşturabilirsiniz. Bu nesnede, sorguların veya birleştirme işlemlerinin sonucu çok kolay okunabilir bir şekilde depolanabilir ve hatalar kolayca test edilebilir. Ardından, tüm bilgileri topladıktan sonra, sunma veya eğitim sırasında, sisteminize özgü, insanlar tarafından okunabilen nesne ile makine öğrenimi sisteminin beklediği biçim arasında köprü oluşturmak için ortak bir yöntem çalıştırırsınız. Bu, eğitim sunmadaki bir sapma kaynağını ortadan kaldırır. Bu nedenle, eğitim ve yayınlama arasında iki farklı programlama dili kullanmamaya çalışın. Bu karar, kodu paylaşmanızı neredeyse imkansız hale getirir.

Kural #33: 5 Ocak'a kadar olan verilere dayalı bir model oluşturursanız modeli 6 Ocak ve sonraki verilerle test edin.

Genel olarak, bir modelin performansını, modelin eğitildiği 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 oluşturursanız modeli 6 Ocak'taki verilerle test edin. Yeni verilerde performansın eski kadar iyi olmayacağını tahmin edersiniz ancak performansın çok daha kötü olması beklenmez. Günlük etkiler olabileceğinden ortalama tıklama oranını veya dönüşüm oranını tahmin edemeyebilirsiniz ancak pozitif bir örneğe negatif bir örnekten daha yüksek bir puan verme olasılığını temsil eden eğrin altındaki alan makul ölçüde yakın olmalıdır.

Kural #34: Filtreleme için ikili sınıflandırmada (ör. spam algılama veya ilgi çekici e-postaları belirleme), çok temiz veriler için performansta kısa vadede küçük fedakarlıklar yapın.

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

Ancak bu yaklaşım, örnekleme önyargısı oluşturur. Bunun yerine, yayınlama sırasında tüm trafiğin% 1'ini "ayıklanmış" olarak etiketleyip tüm ayrılmış örnekleri kullanıcıya gönderirseniz daha net veriler toplayabilirsiniz. Filtreniz artık negatif örneklerin en az% 74'ünü engelliyor. Bu ayrılan örnekler, eğitim verileriniz olabilir.

Filtreniz olumsuz örneklerin% 95'ini veya daha fazlasını engelliyorsa bu yaklaşımın daha az uygulanabilir hale geldiğini unutmayın. Yine de yayınlama performansını ölçmek istiyorsanız daha da küçük bir örnek (ör. %0, 1 veya %0, 001) oluşturabilirsiniz. Performansı oldukça doğru bir şekilde tahmin etmek için on bin örnek yeterlidir.

Kural 35: Sıralama sorunlarında doğal olarak bulunan sapmalara dikkat edin.

Sıralama algoritmanızı farklı sonuçların gösterileceği kadar radikal bir şekilde değiştirdiğinizde, algoritmanızın gelecekte göreceği verileri etkili bir şekilde değiştirmiş olursunuz. Bu tür bir sapma ortaya çıkar ve modelinizi buna göre tasarlamanız gerekir. Birden fazla farklı yaklaşım vardır. Bu yaklaşımlar, modelinizin daha önce gördüğü verileri tercih etmenin tüm yolları olarak kabul edilir.

  1. Yalnızca bir sorgu için etkin olan özelliklerin aksine, daha fazla sorguyu kapsayan özelliklerde daha yüksek normalleştirmeye sahip olun. Bu sayede model, tüm sorgular için genelleştirilmiş ö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 fazla benzersiz değere sahip özellik sütunlarında daha fazla normalleştirme yapılmasıyla ilgili daha geleneksel tavsiyenin tam tersi olduğunu unutmayın.
  2. Yalnızca özelliklerin pozitif ağırlıklara sahip olmasına izin verin. Bu nedenle, iyi bir özellik "bilinmeyen" bir özellikten daha iyi olur.
  3. Yalnızca dokümanlarda kullanılabilen özellikler yoktur. Bu, 1. yöntemin uç bir versiyonudur. Örneğin, belirli bir uygulama, sorgu ne olursa olsun popüler bir indirme olsa bile her yerde gösterilmesini istemezsiniz. Yalnızca dokümanlarla ilgili özelliklerin olmaması bu işlemi basitleştirir. Belirli bir popüler uygulamayı her yerde göstermek istememenizin nedeni, istenen tüm uygulamaların erişilebilir olmasının önemidir. Örneğin, "kuş gözlemleme uygulaması" araması yapan bir kullanıcı "Angry Birds" uygulamasını indirebilir ancak bu kullanıcının amacı kesinlikle bu değildir. Bu tür bir uygulamanın gösterilmesi indirme oranını artırabilir ancak kullanıcının ihtiyaçlarını karşılamayabilir.

Kural 36: Konumsal özelliklerle 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 sıraya koyarsanız daha sık tıklanır ve tıklanma olasılığının daha yüksek olduğundan emin olabilirsiniz. Bu sorunun üstesinden gelmenin bir yolu, konumsal özellikler (ör. içeriğin sayfada konumuyla ilgili özellikler) eklemektir. Modelinizi konumsal özelliklerle eğitirsiniz ve model, örneğin "1. sıra" özelliğine ağırlık vermeyi öğrenir. Bu nedenle, modeliniz "1st­position=true" olan örneklerde diğer faktörlere daha az ağırlık verir. Ardından, sunma sırasında adayların gösterilme sırasına karar vermeden önce puanladığınız için hiçbir örneğe konumsal özellik atamazsınız veya hepsine aynı varsayılan özelliği atarsınız.

Eğitim ve test arasındaki bu asimetri nedeniyle, konumsal özelliklerin modelin geri kalanından biraz ayrı tutulmasının önemli olduğunu unutmayın. Modelin, konumsal özelliklerin bir işlevinin ve diğer özelliklerin bir işlevinin toplamı olması idealdir. Örneğin, konumsal özellikleri herhangi bir doküman özelliğiyle çaprazlamayın.

37. Kural: Eğitim/Sunma Arasındaki Sapmayı Ölçün.

Genel anlamda, verilerin çarpıtılmasına neden olabilecek çeşitli faktörler vardır. Ayrıca, raporu birkaç bölüme ayırabilirsiniz:

  • Eğitim verilerindeki performans ile ayrılan verilerdeki performans arasındaki fark. Genel olarak bu durum her zaman vardır ve her zaman kötü değildir.
  • Test dışı verilerdeki performans ile "sonraki gün" verileri arasındaki fark. Bu durum her zaman geçerli olacaktır. Düzenlemenizi, ertesi günkü performansı en üst düzeye çıkaracak şekilde ayarlamanız gerekir. Ancak, ayrılan veri kümesi ile sonraki gün verileri arasındaki performansta büyük düşüşler, bazı özelliklerin zamana duyarlı olduğunu ve model performansını düşürdüğünü gösterebilir.
  • "Sonraki gün" verilerindeki performans ile canlı veriler arasındaki fark. Bir modeli eğitim verilerindeki bir örneğe ve sunma sırasında aynı örneğe uygularsanız tam olarak aynı sonucu alırsınız (5. Kural'a bakın). Dolayısıyla, buradaki tutarsızlık muhtemelen bir mühendislik hatasını gösterir.

Makine Öğrenimi III. Aşama: Yavaşlayan Büyüme, Optimizasyon İncelenmesi ve Karmaşık Modeller

İkinci aşamanın sona ermek üzere olduğuna dair belirli göstergeler olacaktır. Öncelikle, aylık kazançlarınız azalmaya başlar. Metrikler arasında bazı değişimler yaşamaya başlayacaksınız: Bazı denemelerde bazı metrikler yükselirken diğerleri düşecektir. İşte bu noktada işler ilginçleşiyor. Elde edilecek kazançların elde edilmesi daha zor olduğundan makine öğreniminin daha karmaşık hale gelmesi gerekir. Not: Bu bölümde, önceki bölümlere kıyasla daha fazla genel kural vardır. Birçok ekibin makine öğreniminin 1. ve 2. aşamalarında mutlu zamanlar geçirdiğini gördük. 3. aşamaya ulaşıldığında ekiplerin kendi yollarını bulması gerekir.

Kural 38: Hedefler uyumlu değilse yeni özelliklerle zaman kaybetmeyin.

Ölçümleriniz sabitlendiğinde ekibiniz, mevcut makine öğrenimi sisteminizin hedeflerinin kapsamı dışındaki sorunları incelemeye başlar. Daha önce de belirtildiği gibi, ürün hedefleri mevcut algoritmik hedef kapsamında değilse hedefinizi veya ürün hedeflerinizi değiştirmeniz gerekir. Örneğin, tıklamaları, artı bir eklemeleri veya indirmeleri optimize edebilir ancak lansman kararlarını kısmen gerçek kişiler tarafından yapılan değerlendirmelere göre alabilirsiniz.

Kural 39: Lansman kararları, uzun vadeli ürün hedefleri için bir proxy'dir.

Ayla, yükleme tahmininin mantıksal kaybını azaltmayla ilgili bir fikre sahiptir. Bir özellik ekler. Mantıksal kayıp düşer. Canlı deneme yaptığında yükleme oranında artış olduğunu görüyor. Ancak lansman inceleme toplantısına gittiğinde, günlük etkin kullanıcı sayısının %5 oranında düştüğüne dikkat çekilir. Ekip, modeli kullanıma sunmamaya karar verir. Alice hayal kırıklığına uğrasa da lansman kararlarının birden fazla ölçüte bağlı olduğunu ve bunların yalnızca bir kısmının doğrudan yapay zeka kullanılarak optimize edilebileceğini fark eder.

Gerçek dünyada, Dungeons and Dragons gibi bir oyun yoktur: Ürününüzün sağlığını tanımlayan "vurgun noktaları" yoktur. Ekip, sistemin gelecekte ne kadar iyi olacağını etkili bir şekilde tahmin etmek için topladığı istatistikleri kullanmalıdır. Etkileşim, 1 günlük etkin kullanıcı sayısı (GEKS), 30 günlük GEKS, gelir ve reklamverenin yatırım getirisini dikkate almaları gerekir. A/B testlerinde ölçülebilir olan bu metrikler, daha uzun vadeli hedeflerin (kullanıcı memnuniyeti, kullanıcı sayısını artırma, iş ortaklarını memnun etme ve kâr elde etme) yalnızca birer göstergesidir. Bu hedefleri, beş yıl sonra kullanışlı, yüksek kaliteli bir ürüne ve başarılı bir şirkete sahip olmanın göstergesi olarak da düşünebilirsiniz.

Yalnızca tüm metriklerin iyileştiği (veya en azından kötüleşmediği) durumlarda lansmanla ilgili kolay kararlar verilebilir. Ekip, karmaşık bir makine öğrenimi algoritması ile basit bir sezgisel yöntem arasında seçim yapıyorsa ve basit sezgisel yöntem tüm bu metriklerde daha iyi performans gösteriyorsa sezgisel yöntemi seçmelidir. Ayrıca, olası tüm 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
A 1 milyon 4 milyon ABD doları
B 2 milyon 2 milyon ABD doları

Mevcut sistem A ise ekibin B'ye geçmesi pek olası değildir. Mevcut sistem B ise ekibin A'ya geçmesi pek olası değildir. Bu durum, mantıklı davranışla çelişiyor gibi görünse de değişen metriklerle ilgili tahminler doğru çıkabilir veya çıkmayabilir. Bu nedenle, her iki değişiklikle ilgili de büyük bir risk vardır. Her metrik, ekibin endişelendiği bazı riskleri kapsar.

Ayrıca hiçbir metrik, ekibin "Ürünüm beş yıl içinde nereye gelecek?" sorusunu yanıtlamıyor.

Öte yandan, bireyler doğrudan optimize edebilecekleri bir hedefi tercih etme eğilimindedir. Çoğu makine öğrenimi aracı bu tür bir ortamı tercih eder. Yeni özellikler geliştiren bir mühendis, bu tür bir ortamda sürekli olarak lansman yapabilir. Bu sorunu çözmeye başlayan bir makine öğrenimi türü olan çok amaçlı öğrenme vardır. Örneğin, her metrik için alt sınırlara sahip olan ve bazı doğrusal metrik kombinasyonlarını optimize eden bir kısıtlama memnuniyeti problemi formüle edilebilir. Ancak bu durumda bile tüm metrikler kolayca makine öğrenimi hedefleri olarak çerçevelenemez. Bir belgenin tıklanması veya bir uygulamanın yüklenmesi, içeriğin gösterildiği anlamına gelir. Ancak kullanıcıların sitenizi neden ziyaret ettiğini anlamak çok daha zordur. Bir sitenin gelecekteki başarısını bir bütün olarak tahmin etmek yapay zeka ile tamamlanmış bir işlemdir. Bu işlem, bilgisayar görüşü veya doğal dil işleme kadar zordur.

Kural 40: Grupları basit tutun.

Ham özellikleri alan ve içeriği doğrudan sıralayan birleşik modeller, hata ayıklama ve anlama açısından en kolay modellerdir. Ancak bir model grubu (diğer modellerin puanlarını birleştiren bir "model") daha iyi sonuç verebilir. İşleri basit tutmak için her model ya yalnızca diğer modellerin girişini alan bir topluluk ya da birçok özelliği alan bir temel model olmalıdır. İkisi birden olamaz. Ayrı olarak eğitilmiş diğer modellerin üzerine modeller eklerseniz bunları birleştirmek kötü davranışlara neden olabilir.

Birleştirme için yalnızca "temel" modellerinizin çıkışını giriş olarak alan basit bir model kullanın. Ayrıca bu toplu modellerde özellikleri de zorunlu kılmak istersiniz. Örneğin, bir temel model tarafından üretilen puanda artış olması, toplu modelin puanını düşürmemelidir. Ayrıca, temel modellerdeki değişikliklerin toplu modelde kafa karışıklığına yol açmaması için gelen modellerin anlamsal olarak yorumlanabilir (ör. kalibre edilmiş) olması en iyisidir. Ayrıca, temel sınıflandırıcının tahmini olasılığındaki bir artışın, toplu tahminin tahmini olasılığını azaltmamasını zorunlu kılın.

41. Kural: Performans durduğunda, mevcut sinyalleri hassaslaştırmak yerine niteliksel olarak yeni bilgi kaynakları eklemeye çalışın.

Kullanıcıyla ilgili bazı demografik bilgiler eklediyseniz Dokümanda geçen kelimelerle ilgili bazı bilgiler eklediniz. Şablon keşfini tamamlayıp normalleştirmeyi ayarladınız. Birkaç çeyrekte temel metriklerinizde% 1'den fazla artış sağlayan bir lansman görmediniz. Şimdi önemli olan nedir?

Bu kullanıcının son gün, hafta veya yıl içinde eriştiği dokümanların geçmişi ya da farklı bir mülkten alınan veriler gibi tamamen farklı özellikler için altyapı oluşturmaya başlamanın zamanı geldi. wikidata öğelerini veya şirketinize ait bir öğeyi (ör. Google'ın Bilgi Grafiği) kullanın. Derin öğrenmeyi kullanın. Yatırımdan ne kadar getiri elde edeceğinize dair 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 maliyetine karşı tartmanız gerekir.

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

İçerik grubundaki çeşitlilik birçok anlama gelebilir. İçeriğin kaynağının çeşitliliği en yaygın olanlardan biridir. Kişiselleştirme, her kullanıcının kendi sonuçlarını aldığını gösterir. Alakalılık, belirli bir sorgunun sonuçlarının söz konusu sorgu için diğerlerinden daha uygun olduğunu ifade eder. Bu nedenle, bu özelliklerin üçü de sıradan olandan farklı olarak tanımlanır.

Sorun, sıradanlığın üstesinden gelmenin zor olmasıdır.

Sisteminiz tıklamaları, harcanan süreyi, izleme sayısını, +1'ları, yeniden paylaşımları vb. ölçüyorsa içeriğin popülerliğini ölçtüğünüz anlamına gelir. Ekipler bazen çeşitlilik içeren kişisel bir model öğrenmeye çalışır. Kişiselleştirmek için sisteme kişiselleştirme (kullanıcı ilgisini temsil eden bazı özellikler) veya çeşitlendirme (bu dokümanın, döndürülen diğer dokümanlarla ortak özellikleri (ör. yazar veya içerik) olup olmadığını belirten özellikler) olanağı tanıyan özellikler ekler ve bu özelliklerin beklediklerinden daha az ağırlık (veya bazen farklı bir işaret) aldığını fark eder.

Bu, çeşitliliğin, kişiselleştirmenin 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şlem yapabilirsiniz. Uzun vadeli hedeflerin arttığını görürseniz popülerliğin yanı sıra çeşitliliğin/alaka düzeyinin de değerli olduğunu söyleyebilirsiniz. Ardından, son işleminizi kullanmaya devam edebilir veya doğrudan çeşitliliğe ya da alaka düzeyine göre hedefi değiştirebilirsiniz.

Kural 43: Arkadaşlarınız farklı ürünlerde aynı olma eğilimindedir. İlgi alanlarınız genellikle bu şekilde değildir.

Google'daki ekipler, bir üründeki bağlantının yakınlığını tahmin eden bir modeli alıp başka bir üründe iyi çalıştırarak çok başarılı sonuçlar elde etti. Arkadaşlarınız kim olduklarını bilir. Öte yandan, birçok ekibin ürün ayrımları arasında kişiselleştirme özellikleriyle mücadele ettiğini gördüm. Evet, çalışacak gibi görünüyor. Şu an için öyle görünmüyor. Bazen, bir mülkte davranışı tahmin etmek için başka bir mülkten alınan ham verileri kullanmak işe yaramıştır. Ayrıca, kullanıcının başka bir mülkte geçmişi olduğunu bilmenin bile faydalı olabileceğini unutmayın. Örneğin, iki üründe kullanıcı etkinliğinin bulunması tek başına bir gösterge olabilir.

Google'da ve dışında makine öğrenimi hakkında birçok doküman mevcuttur.

Teşekkür ederiz

Bu dokümanda birçok düzeltme, öneri ve faydalı örnek sunan David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michail Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Konstantinos Katsiapis, Glen Anderson, Dan Duckworth, Shishir Birmiwal, Gal Elidan, Su Lin Wu, Jaihui Liu, Fernando Pereira ve Hrishikesh Aradhye'ye teşekkür ederiz. Ayrıca, önceki bir sürümde bize yardımcı olan Kristen Lefevre, Suddha Basu ve Chris Berg'e de teşekkür ederiz. Tüm hatalar, eksiklikler veya (korkunç!) popüler olmayan görüşler bana aittir.

Ek

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

YouTube'a Genel Bakış

YouTube, video akış hizmetidir. Hem YouTube Sıradaki Video hem de YouTube Ana Sayfa Ekibi, video önerilerini sıralamak için makine öğrenimi modellerini kullanır. Sıradaki, şu anda oynatılan videodan sonra izlenebilecek videoları önerir. Ana Sayfa ise 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ş Önerileri ve "Kullanıcılar Ayrıca Yükledi" uygulamaları makine öğrenimini kullanır.

Google Artı'ya Genel Bakış

Google Plus, makine öğrenimini çeşitli durumlarda kullanır: Kullanıcının gördüğü "akış"taki gönderileri sıralama, "Trendler"deki gönderileri (şu anda çok popüler olan gönderiler) sıralama, tanıdığınız kişileri sıralama vb. Google Plus, 2019'da tüm kişisel hesapları kapatmış ve 6 Temmuz 2020'de işletme hesapları için Google Currents ile değiştirilmiştir.