Makine Öğrenimi Kuralları:

Makine Öğrenimi Mühendisliği İçin En İyi Uygulamalar

Martin Zinkevich

Bu belgenin temel amacı, makine öğrenimi konusunda temel bilgilere sahip kullanıcıların, Google'ın makine öğrenimi konusundaki en iyi uygulamalarından yararlanmasına yardımcı olmaktır. Google C++ Stil Kılavuzu'na benzer şekilde ve pratik programlama için diğer popüler kılavuzlara benzer bir makine öğrenimi stili sunar. Makine öğrenimi dersine katıldıysanız veya makine öğrenimili bir model üzerinde çalıştıysanız bu belgeyi okumak için gerekli olan arka plana sahipsinizdir.

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 tartışmamızda aşağıdaki terimler tekrar tekrar geçerlidir:

• Örnek: Hakkında tahminde bulunmak 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ı, makine öğrenimi sistemi tarafından oluşturulan yanıt veya eğitim verilerinde sağlanan doğru cevaptı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ı ülkelerin grubu gibi bir dizi alakalı özellik. Örneğin, bir özellik sütununda bir veya daha fazla özellik mevcut olabilir. "Özellik sütunu" Google'a özel bir terminolojidir. Özellik sütunu, VW sisteminde (Yahoo/Microsoft'ta) "ad alanı" veya alan olarak adlandırılır.
• Örnek: Bir örnek (özellikleri ile) ve bir etiket.
• Model: Bir tahmin görevinin istatistiksel temsili. Modeller üzerinde eğitilir ve daha sonra tahmin oluşturmak için bu model kullanılır.
• Metrik: Sizin için önemli olan bir sayı. Doğrudan optimize edilebilir veya uygulanmayabilir.
• Amaç: Algoritmanızın optimize etmeye çalıştığı bir metrik.
• Alma: Makine öğrenimi algoritmasını çevreleyen altyapı. Verileri kullanıcı arabiriminden toplamak, eğitim veri dosyalarına yerleştirmek, bir veya daha fazla modeli eğitmek ve modelleri üretime aktarmak dahildir.
• Tıklama oranı Bir reklamdaki bağlantıyı tıklayan web sayfasının ziyaretçilerinin yüzdesi.

Genel bakış

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

Makine öğrenimini mükemmel mühendis gibi yapın, sizin olmadığın en iyi makine öğrenimi uzmanı gibi yapın.

Karşılaşacağınız sorunların çoğu aslında mühendislik sorunlarıdır. Muhteşem bir makine öğrenimi uzmanının tüm kaynaklarıyla birlikte, kazanımların çoğu harika makine öğrenimi algoritmalarından değil, mükemmel özelliklerden gelir. Temel yaklaşım:

1. Ardışık düzeninizin uçtan uca sabit olduğundan emin olun.
2. Makul bir hedefle başlayın.
3. Anlamlı özellikleri basit bir şekilde ekleyin.
4. Ardışık düzeninizin sabit olduğundan emin olun.

Bu yaklaşım uzun süre işe yarayacaktır. Bu yaklaşımı yalnızca sizi daha da ileri götürecek basit hileler olmadığında ayrıntılı düşünün. Karmaşıklık eklemek gelecekteki sürümleri yavaşlatır.

Basit püf noktalarını bitirdikten sonra, makine öğreniminin geleceğini şekillendirebilirsiniz. III. Aşama makine öğrenimi projeleriyle ilgili bölüme bakın.

Belge şu şekilde düzenlenmiştir:

1. İlk bölümde, makine öğrenimi sistemi oluşturmak için doğru zamanın olup olmadığını anlamanıza yardımcı olacağız.
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 özelliğin başlatılması ve tekrarlanması, modellerin değerlendirilmesi ve eğitim sunma sapmasının ele alınmasıyla ilgilidir.
4. Son kısım, bir platoya ulaştığınızda ne yapmanız gerektiğiyle ilgilidir.
5. Ardından, bu çalışmanın bir listesi ve bu dokümanda yaygın olarak örnek olarak kullanılan sistemler hakkında bilgi veren bir ek bulunmaktadır.

Makine Öğreniminden Önce

1. Kural: Bir ürünü makine öğrenimi olmadan başlatmaktan korkmayın.

Makine öğrenimi havalıdır ancak veri gerektirir. Teorik olarak farklı bir problemden veri alıp daha sonra yeni bir ürün için modeli değiştirebilirsiniz, ancak bu muhtemelen temel selamsal performansından daha düşük olacaktır. Makine öğreniminin size% 100 artış sağlayacağını düşünüyorsanız sezgisel bir yol ile oradan %50 oranında sonuç alabilirsiniz.

Örneğin, bir uygulama pazarındaki uygulamaları sıralıyorsanız buluşsal yöntem olarak yükleme oranını veya yükleme sayısını kullanabilirsiniz. Spam tespit ediyorsanız daha önce spam gönderen yayıncıları filtreleyin. İnsan düzenlemelerini de kullanmaktan korkmayın. Kişileri sıralamanız gerekiyorsa en son kullanılan sıralamayı (hatta alfabetik olarak) sıralayın. Makine öğrenimi, ürününüz için kesinlikle gerekli değilse verileriniz ortaya çıkana kadar kullanmayın.

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

Makine öğrenimi sisteminizin ne yapacağını resmileştirmeden önce mevcut sisteminizde mümkün olduğunca çok yol izleyin. Bunu aşağıdaki nedenlerden dolayı yapın:

1. Daha önce sistemin kullanıcılarından izin almak daha kolaydır.
2. Bir şeyin ileride endişe verici olabileceğini düşünüyorsanız hemen geçmiş verileri almanızı öneririz.
3. Sisteminizi metrik araçları göz önünde bulundurularak tasarlarsanız ileride her şey daha iyi olur. Özellikle, metriklerinizi desteklemek için günlüklerdeki dizeler arasında kendinizi bulabilmek istemezsiniz.
4. Nelerin değiştiğini ve aynı kalanları fark edeceksiniz. Örneğin, bir günlük etkin kullanıcıları doğrudan optimize etmek istediğinizi varsayalım. Ancak, sistem üzerinde ilk manipülasyonlarınız sırasında kullanıcı deneyiminde büyük değişiklikler yapıldığında bu metriğin belirgin bir şekilde değişmediğini fark edebilirsiniz.

Google Plus ekibi ölçümler şunları yapar: Okuma başına okuma sayısı, okuma başına yeniden paylaşımlar, okuma başına artı birler, okuma başına yorumlar, okumalar, kullanıcı başına yorumlar, kullanıcı başına yeniden paylaşımlar vb.; yayın sırasında bir yayının ne kadar iyi olduğunun hesaplanmasında kullanılır. Ayrıca, kullanıcıları gruplara ayırıp denemelere göre istatistikleri birleştirebileceğiniz bir deneme çerçevesinin de önemli olduğunu unutmayın. 12. Kural'a bakın.

Metrik toplama konusunda daha serbest davranarak sisteminizin daha kapsamlı bir görünümünü elde edebilirsiniz. Bir sorun mu fark ettiniz? İzlemek için bir metrik ekleyin! Son sürümde niceliksel değişiklikler sizi heyecanlandırdı mı? İzlemek için bir metrik ekleyin!

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

Basit bir buluşsal yöntem, ürününüzü satışa sunabilir. Karmaşık bir buluşsal yöntem sabittir. Elinizde verilere dair temel bir fikir edindikten sonra, neyi başarmak istediğinize dair temel bir fikir edindikten sonra makine öğrenimine geçin. Çoğu yazılım mühendisliği görevinde olduğu gibi, hem bulgusal hem de makine öğrenimine dayalı bir model olsun, yaklaşımınızı sürekli olarak güncellemek istersiniz. Makine öğrenimi modelinin güncellenmesinin ve bakımının daha kolay olduğunu görürsünüz (16. Kural).

ML Aşaması: İlk Ardışık Düzeniniz

İlk ardışık düzeniniz için sistem altyapınıza odaklanın. Yapacağınız tüm hayali makine öğrenimini düşünmek eğlenceli olsa da önce ardışık düzeninize güvenmiyorsanız ne olduğunu anlamak zor olur.

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

İlk model, ürününüze yönelik en yüksek artışı sağladığından bu ürünün gösterişli olması gerekmez. Ancak beklediğinizden çok daha fazla altyapı sorunuyla karşılaşırsınız. Herkesin yeni makine öğrenimi sisteminizi kullanabilmesi için şunları belirlemeniz gerekir:

• Öğrenme algoritmanıza örnekler alma.
• "İyi" ve "kötü" ifadelerinin sisteminiz için ne anlama geldiği konusundaki ilk kesinti.
• Modelinizi uygulamanıza nasıl entegre edebilirsiniz? Modeli canlı olarak uygulayabilir veya çevrimdışıyken örneklerde modeli önceden hesaplayıp sonuçları bir tabloda depolayabilirsiniz. Örneğin, web sayfalarını önceden sınıflandırmayı ve sonuçları bir tabloda depolamayı, ancak sohbet mesajlarını canlı olarak sınıflandırmayı düşünebilirsiniz.

Basit özelliklerin seçilmesini sağlayarak:

• Özellikler, öğrenim algoritmanıza doğru şekilde erişir.
• Model makul ağırlıklar öğrenir.
• Özellikler, sunucudaki modelinize doğru şekilde erişir.

Bu üç şeyi güvenilir bir şekilde yapan bir sisteminiz olduğunda, işin çoğunu tamamladınız demektir. Basit modeliniz size temel metrikler ve daha karmaşık modelleri test etmek için kullanabileceğiniz bir temel davranış sağlar. Bazı ekipler "nötr" bir ilk lansman gerçekleştirmek istiyor: ilk karşılaşma, dikkat dağıtıcı unsurları önlemek için makine öğreniminin kazanımlarını açıkça öncelik dışı bırakıyor.

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

Altyapının test edilebildiğinden ve sistemin öğrenme parçalarının kapalı olduğundan emin olun. Böylece ortamdaki her şeyi test edebilirsiniz. Özellikle:

1. Algoritmaya veri almayı test edin. Doldurulması gereken özellik sütunlarının doldurulduğundan emin olun. Gizliliğin izin verdiği durumlarda, eğitim algoritmanızın girişini manuel olarak inceleyin. Mümkünse başka bir yerde işlenen aynı verilerle ilgili istatistiklerle karşılaştırıldığında hattınızdaki istatistikleri kontrol edin.
2. Modelleri eğitim algoritmasından çıkarmayı test edin. Eğitim ortamınızdaki modelin, sunum ortamınızdaki modelle aynı puana sahip olduğundan emin olun (37. Kural'a bakın).

Makine öğreniminin öngörülemez bir unsuru vardır. Bu nedenle, eğitim ve sunum sırasında örnek oluşturmak için kod testlerinden geçtiğinizden ve sunum sırasında sabit 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 azalan verilere dikkat edin.

Mevcut bir ardışık düzeni (ör. kargo kült programlaması) kopyalayarak genellikle bir ardışık düzen oluştururuz ve eski ardışık düzen, yeni ardışık düzen için ihtiyaç duyduğumuz verileri çıkarır. Örneğin, Google Plus Popüler Olanlar ardışık düzeni, eski yayınları (yeni yayınları sıralamaya çalıştığı için) çıkarır. Bu ardışık düzen, eski gönderilerin anlamlı olduğu ancak eski yayınları kaybettiği Google Plus Akışı için kullanılmak üzere kopyalandı. Yaygın olarak karşılaşılan başka bir kalıp da yalnızca kullanıcı tarafından görülen verilerin günlüğe kaydedilmesidir. Bu nedenle, tüm negatif örnekler bırakıldığından belirli bir yayının kullanıcı tarafından neden görülemediğini modellemek istersek bu veriler işe yaramaz. Play'de de benzer bir sorun oluştu. Play Apps Home'da çalışırken yeni bir ardışık düzen oluşturuldu. Bu ardışık düzende, her örneğin nereden geldiğinin belirlenmesine yardımcı olacak herhangi bir özellik olmadan Play Games açılış sayfasından örnekler de bulunuyordu.

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

Genellikle, makine öğreniminin çözmeye çalıştığı sorunlar tamamen yeni değildir. Sıralama, sınıflandırma ve çözmeye çalıştığınız problem için mevcut bir sistem vardır. Bu da çok sayıda kural ve buluşsal yöntem olduğu anlamına gelir. Aynı buluşsal bulgular makine öğrenimiyle düzenlendiklerinde size bir artış sağlayabilir. Sezgileriniz, sahip oldukları tüm bilgiler için iki nedenden dolayı araştırılmalıdır. Makine öğrenimi destekli bir sisteme geçiş daha sorunsuz olacak. İkinci olarak, bu kurallar genellikle silmek istemediğiniz sistemle ilgili çok fazla içgüdü içerir. Mevcut bir bulguyu kullanmanın dört yolu vardır:

• Sezgileri kullanarak ön işlem yapın. Bu özellik inanılmaz derecede mükemmelse bu seçenek sunulmaktadır. Örneğin, bir spam filtresinde gönderen zaten kara listeye eklenmişse "kara listeye alınan" şeyin ne anlama geldiğini tekrar öğrenmeye çalışmayın. Mesajı engelleyin. Bu yaklaşım, ikili sınıflandırma görevlerinde en mantıklı olandır.
• Bir özellik oluşturun. Sezgiden doğrudan bir özellik oluşturmak harikadır. Örneğin, bir sorgu sonucunun alaka düzeyi puanını hesaplamak için buluşsal bir yöntem kullanırsanız puanı bir özelliğin değeri olarak ekleyebilirsiniz. Daha sonra, değere masaj yapmak için makine öğrenimi tekniklerini kullanmak isteyebilirsiniz (örneğin, değeri sonsuz bir ayrı değer grubundan birine dönüştürme veya diğer özelliklerle birleştirme) ancak başlangıçta elde edilen ham değeri kullanarak başlayabilirsiniz.
• Sezgisellerin ham girişlerini araştırın. Uygulamalar için yükleme sayısını, metindeki karakter sayısını ve haftanın gününü birleştiren bir buluşsal yöntem varsa bu parçaları parçalara ayırıp bu girişleri öğrenime ayrı ayrı aktarmak isteyebilirsiniz. Topluluklar için geçerli olan bazı teknikler burada geçerlidir (bkz. 40 numaralı kural).
• Etiketi değiştirin. Bu, etikette bulunmayan, buluşsal bilgileri yakaladığınızı düşündüğünüzde, bir seçenektir. Örneğin, indirme sayısını en üst düzeye çıkarmaya çalışıyorsanız ancak aynı zamanda kaliteli içerik istiyorsanız çözüm, etiketi uygulamanın aldığı ortalama yıldız sayısıyla çarpmak olabilir. Burada çok fazla yol var. "İlk Hedefiniz" başlıklı makaleyi inceleyin.

Sezgileri makine öğrenimi sistemlerinde kullanırken ortaya çıkan karmaşık durumlara dikkat edin. Yeni makine öğrenimi algoritmanızda eski buluşsal yöntemleri kullanmak yumuşak 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çirme ve kontrol paneli sayfası ekleme gibi iyi uyarı hijyenleri uygulayın.

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

Bir günlük bir modeliniz varsa performans ne kadar azalır? Bir hafta mı? Üç aylık mı? Bu bilgiler, izleme işleminin önceliklerini anlamanıza yardımcı olur. Model bir gün boyunca güncellenmezse ürün kalitesini önemli ölçüde kaybederseniz bir mühendisin modeli sürekli olarak izlemesi mantıklı olacaktır. Çoğu reklam sunma sisteminin her gün kullanabileceği yeni reklamlar vardır ve reklamların günlük olarak güncellenmesi gerekir. Örneğin, Google Play Arama için makine öğrenimi modeli güncellenmezse bir aydan kısa bir süre içinde olumsuz etkisi olabilir. Google Plus'taki Yenilikler'in bazı modellerinin modellerinde gönderi tanımlayıcısı olmadığından 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 modelinizden kaldırıldığında yeniliğ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 sunuma aktardığınız bir aşama vardır. Dışa aktarılan bir modelle ilgili sorun varsa bu, kullanıcının karşılaştığı bir sorundur.

Modeli dışa aktarmadan hemen önce sağlık kontrolleri yapın. Özellikle, modelin elde tutulan verilerde makul düzeyde performans gösterdiğinden emin olun. Ayrıca, verilerle ilgili uzun süredir endişeniz varsa bir modeli dışa aktarmayın. Modelleri sürekli olarak dağıtan birçok ekip, dışa aktarma işleminden ö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 beklemek iyi bir fikirdir.

10. Kural: Sessiz hatalara dikkat edin.

Bu, makine öğrenimi sistemlerinde diğer sistemlerden daha çok karşılaşılan bir sorundur. Katılmakta olduğunuz belirli bir tablonun artık güncellenmediğini varsayalım. Makine öğrenimi sistemi buna göre ayarlanır ve davranış yavaş yavaş iyileşerek yavaş yavaş azalır. Bazen güncelliğini yitirmiş aylar olduğunu görürsünüz. Basit bir yenileme ile o çeyrekteki diğer lansmanlardan daha iyi bir performans elde edebilirsiniz. Bir özelliğin kapsamı, uygulama değişiklikleri nedeniyle değişebilir. Örneğin, bir özellik sütunu örneklerin% 90'ında doldurulabilir ve aniden örneklerin% 60'ına düşebilir. Play'in bir tablosu 6 ay boyunca eskiydi ve yalnızca tabloyu yenilemek, yükleme oranında% 2'lik bir artış sağladı. Verilerin istatistiklerini izler ve verileri zaman zaman manuel olarak incelerseniz bu tür hataları azaltabilirsiniz.

11. Kural: Özellik sütunlarının sahiplerine ve dokümanlara yer verin.

Sistem büyükse ve çok sayıda özellik sütunu varsa, her bir özellik sütununu kimin oluşturduğunu veya kime ait olduğunu öğrenin. Bir özellik sütununu anlayan kişinin ayrıldığını saptarsanız bilginin başka birisine ait olmadığından 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ğiyle ilgili daha ayrıntılı bir açıklamanız olması iyi olacaktır.

İlk Hedefiniz

Önemsediğiniz sistem hakkında önem verdiğiniz birçok metrik veya ölçüm vardır. Ancak makine öğrenimi algoritmanız genellikle tek bir hedef (algoritmanızın optimize etmeye çalıştığı bir sayı) gerektirir. Burada hedefler ile metrikler arasında ayrım yaparım: Metrik, sisteminizin bildirdiği ve önemli olup olamayan bir sayıdır. 2. Kural'ı da inceleyin.

12. Kural: Doğrudan optimize etmeyi seçtiğiniz hedefin ne olduğunu düşünmeyin.

Para kazanmak, kullanıcılarınızı memnun etmek ve dünyayı daha iyi bir yer haline getirmek istiyorsunuz. Önemsediğiniz çok sayıda metrik var ve hepsini ölçmelisiniz (bkz. 2. Kural). Ancak makine öğrenimi işleminin başlarında, doğrudan optimize etmeseniz bile tüm makinelerin arttığını görürsünüz. Örneğin, tıklama sayısını ve sitede geçirilen süreyi önemsediğinizi varsayalım. Tıklama sayısına göre optimizasyon yaparsanız muhtemelen harcanan sürenin arttığını görebilirsiniz.

Bu nedenle, basit metrikler kullanın ve tüm metrikleri kolayca artırabilmek için farklı metrikler arasında denge kurmaktan çekinmeyin. Bu kuralı çok ciddiye almayın: Hedefinizi, sistemin son sağlığıyla karıştırmayın (39. Kural'a bakın). Doğrudan optimize edilmiş metriği artırdığınız halde lansmanı başlatmamaya karar verirseniz bazı nesnel düzeltmeler yapmanız gerekebilir.

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

Genellikle asıl hedefin ne olduğunu bilmiyorsunuz. Ancak, sanırım eski sisteminiz ve yeni makine öğrenimi sisteminizin verilerine ve yan yana analizine baktığınızda hedefi değiştirmek istediğinizi anlıyorsunuz. Ayrıca, farklı ekip üyeleri genellikle gerçek hedef konusunda anlaşamazlar. Makine öğrenimi hedefi, kolay ölçülen ve "doğru" bir hedefe işaret eden bir şey olmalıdır. Aslında genellikle "doğru" hedef yoktur (bkz. Kural#39). Basit bir makine öğrenimi hedefi üzerine çalışın ve en üst sırayı almak için ek mantık (umarız çok basit bir mantık) eklemenize imkan tanıyan bir "politika katmanı" oluşturmayı düşünün.

Modellemenin en kolay yolu, doğrudan gözlemlenen ve sistemin davranışıyla ilişkilendirilebilecek bir kullanıcı davranışıdır:

• Bu sıralı bağlantı tıklandı mı?
• Sıralanmış bu nesne indirildi mi?
• Sıralama yapılan nesne yönlendirildi mi/yanıtlandı/e-posta ile gönderildi mi?
• Bu sıralı nesneye puan verildi mi?
• Bu gösterilen nesne spam/pornografi, 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ı neydi?

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

Son olarak, makine öğrenimini anlamaya çalışmayın:

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

Bunların hepsi önemli ama aynı zamanda ölçülmesi son derece zor. Bunun yerine proxy'ler kullanın: Kullanıcı memnun kalırsa sitede daha uzun süre kalır. Kullanıcı memnun kalırsa yarın tekrar ziyaret edecektir. Sağlık ve şirket sağlığı açısından bakıldığında, makine öğrenimine dayalı herhangi bir makine hedefini, sattığınız ürünün doğasına ve iş planınıza bağlamak amacıyla gerçek kişi tarafından yapılan değerlendirmeler gerekir.

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

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

Örneğin doğrusal, lojistik veya Poisson regresyonunda, tahmini ortalama beklentinin ortalama etikete eşit olduğu (1 an kalibre edilmiş veya yalnızca kalibre edilmiş) verilerin alt kümeleri vardır. Bu, herhangi bir normalleştirmenizin olmadığı ve algoritmanızın birleştiği ve genel olarak yaklaşık olarak doğru olduğu varsayılarak doğrudur. Her örnek için 1 veya 0 olan bir özelliğiniz varsa bu özelliğin 1 olduğu 3 örnek grubu kalibre edilir. Ayrıca, her örnek için 1 olan bir özelliğiniz varsa tüm örnek kümesi kalibre edilir.

Basit modellerle, geri bildirim döngüleriyle başa çıkmak daha kolaydır (bkz. 36. Kural). Genellikle bu olasılık tahminlerini karar vermek için kullanırız: Örneğin, yayınları beklenen değeri (ör. tıklama/indirme/indirme vb.) azaltma. Bununla birlikte, kullanılacak modeli seçme zamanı geldiğinde karar, modelin sağladığı verilerin olasılığından daha önemlidir (27. Kural'a bakın).

15. Kural: Spam Katmanı ve Kalite Sıralamasını bir Politika Katmanında ayırın.

Kalite sıralaması çok güzel bir iştir ancak spam filtrelemesi savaştır. Yüksek kaliteli yayınları belirlemek için kullandığınız sinyaller, sisteminizi kullananlar için görünür olur ve bu özellikleri sağlamak için yayınlarını düzenler. Bu nedenle kalite sıralamanız, iyi niyetle yayınlanan içerikleri sıralamaya odaklanmalıdır. Kalite sıralaması öğrencisini spam sıralamaya göre sınıflandırmamalısınız. Benzer şekilde, "Müstehcen" içerik Kalite Sıralamadan ayrı olarak ele alınmalıdır. Spam filtreleme farklı bir konudur. Oluşturmanız gereken özelliklerin sürekli olarak değişmesini bekliyor olmalısınız. Çoğu zaman sisteme uyguladığınız belirgin kurallar vardır (bir yayının üçten fazla spam oyu varsa almayın). Öğrenilen modellerin daha hızlı olmasa bile her gün güncellenmesi gerekir. İçeriği oluşturan kişinin itibarı önemli bir rol oynayacaktır.

Bir düzeyde, bu iki sistemin çıkışının entegre edilmesi gerekir. Arama sonuçlarında spam filtrelemenin, e-posta iletilerindeki spam'leri filtrelemekten daha agresif olması gerektiğini unutmayın. Bu, herhangi bir normalleştirmenizin olmadığı ve algoritmanızın birleştiği varsayılarak doğrudur. Genel olarak bu doğrudur. Ayrıca, kalite sınıflandırıcıya ait eğitim verilerindeki spam'in kaldırılması standart bir uygulamadır.

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

Makine öğrenimi sisteminin yaşam döngüsünün ilk aşamasında önemli olan, eğitim verilerini öğrenme sistemine dahil etmek, ilgilenilen tüm metrikleri edinmek ve bir sunum altyapısı oluşturmaktır. Birim ve sistem testlerinin uygulandığı çalışır durumda bir uçtan uca sisteminiz olduğunda, 2. Aşama başlar.

İkinci aşamada, kolayca sarkan çok fazla meyve vardır. Sisteme dahil edilebilecek çeşitli bariz özellikler vardır. Bu yüzden makine öğreniminin ikinci aşaması mümkün olduğunca fazla özellik çekmeyi ve bunları sezgisel şekillerde birleştirmeyi içerir. Bu aşamada tüm metrikler hâlâ yükselmelidir. Çok sayıda lansman olacak. Mükemmel bir öğrenim sistemi oluşturmak için ihtiyacınız olan tüm verileri bir araya getirebilecek birçok mühendisi çekmenin tam zamanı.

16. Kural: Başlatmayı ve tekrarlamayı planlayın.

Şu anda üzerinde çalıştığınız modelin, kullanıma sunacağınız son model olacağını veya model lansmanını durduracağınızı bile beklemeyin. Bu nedenle, bu lansmanda eklediğiniz karmaşıklığın, gelecekteki lansmanları yavaşlatıp yavaşlatamayacağını düşünün. Birçok ekip, yıllardır her yıl veya daha uzun bir süre önce bir model kullanıma sundu. Yeni modelleri üç şekilde kullanıma sunabilirsiniz:

• Yeni özellikler geliyor.
• Normalleştirmeyi değiştiriyor ve eski özellikleri yeni yöntemlerle birleştiriyorsunuz.
• Hedefe ince ayar yapıyorsunuz.

Yine de bir modeli biraz sevmek işe yarayabilir: Veri feed'ini örneğe bakmak, eski ve bozuk sinyallerin yanı sıra yeni sinyallerin bulunmasına da yardımcı olabilir. Dolayısıyla, modelinizi oluştururken özellik eklemenin veya kaldırmanın ya da 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 onaylamanın ne kadar kolay olduğunu düşünün. İki veya üç kopyanın paralel olarak çalışmasının mümkün olup olmadığını düşünün. Son olarak, 35 numaradan 16. sıranın, ardışık düzenin bu sürümüne dahil olup olmayacağı konusunda endişelenmeyin. Gelecek çeyrekte mesela kazanacaksınız.

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

Bu tartışmaya açık bir konu olabilir, ancak çok sayıda hatadan kaçınır. Her şeyden önce, öğrenilen bir özelliğin ne olduğunu açıklayalım. Öğrenilen bir özellik, harici bir sistem (gözetimsiz kümeleme sistemi gibi) veya öğrencinin kendisi (ör. faktörlü model veya derin öğrenme aracılığıyla) tarafından oluşturulan bir özelliktir. Bunların ikisi de yararlı olabilir, ancak çok sayıda sorunla karşılaşılabilir. Bu nedenle bunlar ilk modelde olmamalıdır.

Özellik oluşturmak için harici sistem kullanıyorsanız harici sistemin kendi amacı olduğunu unutmayın. Harici sistemin hedefi yalnızca mevcut hedefinizle zayıf bir şekilde ilişkilendirilebilir. Harici sistemin anlık görüntüsünü alırsanız bu sistem güncel olmayabilir. Harici sistemdeki özellikleri güncellerseniz anlamları değişebilir. Özellik sunmak için harici bir sistem kullanıyorsanız bu yaklaşımın son derece dikkatli olunması gerektiğini unutmayın.

Faktörlü modeller ve derin modellerle ilgili asıl sorun, dönüştürülememeleridir. Dolayısıyla, en uygun çözümün yaklaşık olarak bulunabileceği veya bulunabileceği garanti edilmez ve her yinelemede bulunan yerel minimum değer farklı olabilir. Bu varyasyon, sisteminizdeki bir değişikliğin etkisinin anlamlı mı yoksa rastgele mi olduğunu değerlendirmeyi zorlaştırır. Derin özellikler olmadan bir model oluşturarak mükemmel bir temel performans elde edebilirsiniz. Bu referansa ulaştıktan sonra daha fazla ezoterik yaklaşımı deneyebilirsiniz.

18. Kural: Bağlamları genelleştiren içerik özelliklerini keşfedin.

Makine öğrenimi sistemi genellikle çok daha büyük bir resmin küçük bir parçasıdır. Örneğin, Popüler Olanlar'da kullanılabilecek bir yayın hayal ederseniz birçok kişi bir yayını Yenilikler'de göstermeden önce bir artı bir, bir yayını yeniden paylaşır veya yorum yapar. Bu istatistikleri öğrenciye sağlarsanız optimize ettiği bağlamda veri içermeyen yeni yayınlar tanıtılabilir. YouTube Sonrakini İzle özelliği, YouTube aramasından elde edilen izlenme sayısını veya birlikte izleyen izleme sayısını (bir videonun kaç kez izlendikten sonra kaç kez izlendiğini) kullanabilir. Uygunsuz 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 faydalı bir özellik olabilir. Tüm bu özellikler, bağlamla ilgili yeni içerikler sunmanıza olanak tanıyor. Bunun kişiselleştirmeyle ilgili olmadığını unutmayın. Kullanıcılar önce bu bağlamda içeriği beğenip beğenmediklerini, ardından kimlerin beğenip beğenmediğini öğrenin.

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

Çok fazla veri içeren milyonlarca basit özelliği öğrenmek, birkaç karmaşık özellikten daha kolaydır. Alınan dokümanların tanımlayıcıları ve standartlaştırılmış sorgular çok fazla genelleme sağlamaz, ancak sıralamanızı head sorgularındaki etiketlerinizle hizalar. Bu nedenle, her bir özelliğin verilerinizin çok küçük bir kısmı için geçerli olduğu, ancak toplam kapsamı %90'ın üzerinde olduğu özellik gruplarından korkmayın. Çok az sayıda örnek için geçerli olan özellikleri kaldırmak üzere normalleştirmeden yararlanabilirsiniz.

20. Kural: İnsan tarafından anlaşılabilir şekillerde 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ıştırma" ve "çapraz" yaklaşımdır.

Kesintisiz bir deneyim, sürekli bir özellik adı verilen ve bu özellikten çok sayıda farklı özelliğin oluşturulmasından oluşur. Yaş gibi devamlı bir özellik düşünün. Yaş 18'den küçük olduğunda 1, yaş 18 ile 35 arasında olduğunda 1 olan bir özellik oluşturabilirsiniz. Bu histogramların sınırlarını düşünmeyin: Etkinin büyük bir kısmını temel niceliklere verirsiniz.

Çaprazlar, iki veya daha fazla özellik sütununu birleştirir. TensorFlow'un terminolojisinde yer alan özellik sütunu, bir homojen özellik grubudur (ör. {male, female}, {US, Canada, Mexico} ve benzeri). Çapraz, {male, female} × {US,Canada, Mexico} gibi özelliklere sahip yeni bir özellik sütunudur. Bu yeni özellik sütunu özelliği (erkek, Kanada) içerecektir. TensorFlow kullanıyorsanız ve bu tıkanmayı sizin adınıza oluşturması için TensorFlow'a bilgi verirseniz bu (erkek, Kanada) özellik, erkek Kanadalıları temsil eden örneklerde yer alır. Üç, dört veya daha fazla temel özellik sütununun haçlarını içeren modelleri öğrenmek için büyük miktarda veri gerektiğini unutmayın.

Çok büyük özellik sütunları üreten haçlar fazla sığabilir. Örneğin, bir tür arama yaptığınızı ve sorguda kelimeleri içeren bir özellik sütununuz ve dokümanda kelimeleri olan bir özellik sütununuz olduğunu varsayalım. Bunları bir çarpı işaretiyle birleştirebilirsiniz ancak çok sayıda özelliğe sahip olursunuz (21. Kural'a bakın).

Metinle çalışırken iki alternatif vardır. En acılı şey bir nokta ürünüdür. En basit biçimde bir nokta ürünü, sorgu ile doküman arasında ortak kullanılan kelimelerin sayısını sayar. Bu özellik daha sonra ayrıştırılabilir. Başka bir yaklaşım da kesişimdir: Yani, yalnızca hem belgede hem de sorguda "midilli" kelimesi varsa bulunan bir özellik, yalnızca hem dokümanda hem de sorguda bulunduğu takdirde yalnızca mevcut olan bir özelliğimiz olacaktır.

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

Bir modelin uygun karmaşıklık düzeyi hakkında istatistiksel öğrenme teorisi alanında etkileyici sonuçlar vardır. Ancak bu kural temel olarak bilmeniz gereken tek şeydir. İnsanların bin örnekten bir şeyler öğrenebileceğinden veya belirli bir öğrenme yöntemine mahkum oldukları için bir milyondan fazla örneğe ihtiyaç duyduğunuzdan şüphelendiği konuşmalar yaptım. Önemli olan, öğrendiklerinizi verilerinizin boyutuna göre ölçeklendirmektir:

1. Bir arama sıralama sistemi üzerinde çalışıyorsanız ve dokümanlarda ve sorguda milyonlarca farklı kelime varsa ve etiketli 1.000 örneğiniz varsa doküman ve sorgu özellikleri (TF-IDF) ile son derece insan tarafından tasarlanmış diğer yarım düzine başka özellik arasında bir nokta ürünü kullanmanız gerekir. 1000 örnek, bir düzine özellik.
2. Bir milyon örneğiniz varsa, normalleştirme ve muhtemelen özellik seçimi yöntemlerini kullanarak belge ve sorgu özellik sütunlarını kesiştirin. Bu yöntem size milyonlarca özellik sunar ancak normalleştirme olarak daha az özelliğe sahip olursunuz. On milyon örnek, belki yüz bin özellik.
3. Milyarlarca veya yüz milyarlarca örneğiniz varsa özellik seçimini ve normalleştirmeyi kullanarak özellik sütunlarını belge ve sorgu jetonlarıyla karşılaştırabilirsiniz. Bir milyar örneğiniz ve 10 milyon özelliğiniz olacak. İstatistiksel öğrenme teorisi, nadiren sınırlı sınırlar sağlar, ancak başlangıç noktası için oldukça faydalıdır.

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

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

Kullanılmayan özellikler teknik borcu oluşturur. Bir özelliği kullanmadığınızı ve bu özelliği diğer özelliklerle birleştiremeyeceğinizi fark ederseniz 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 istiyorsunuz. Gerekirse birisi özelliğinizi her zaman tekrar ekleyebilir.

Eklenecek veya saklanacak özellikler üzerinde düşünürken kapsamı göz önünde bulundurun. Bu özellik kaç örnek kapsamındadır? Örneğin, bazı kişiselleştirme özellikleriniz olmasına rağmen kullanıcılarınızın yalnızca% 8'inde kişiselleştirme özellikleri varsa bu özellik çok etkili olmayacaktır.

Aynı zamanda, bazı özellikler ağırlıklarının üzerinde bir etki oluşturabilir. Örneğin, verilerin yalnızca% 1'ini kaplayan bir özelliğe sahipseniz, ancak bu özelliğin bulunduğu örneklerin% 90'ının pozitif olduğunu düşünüyorsanız eklemek istediğiniz bir özellik olabilir.

Sistemin İnsan Analizi

Makine öğreniminin üçüncü aşamasına geçmeden önce, makine öğrenimi sınıfında öğretilmeyen bir şeye, ayrıca mevcut bir modele bakıp bunu iyileştirmenin yollarını bulmaya odaklanmak önemlidir. Bu daha çok bir bilimden ziyade bir sanattır ancak yine de kaçınılması gereken çeşitli karşıt kalıplar vardır.

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

Belki de bu sürecin en hızlı yolu ekibin tek başına eğlenmesini sağlamaktır. Balık avcılığının (ekibinizde prototip kullanılması) ve test sürümünü (şirketinizdeki prototipin kullanılması) birçok avantajı olsa da çalışanlar performansın doğru olup olmadığına bakmalıdır. Bariz şekilde kötü olan bir değişiklik kullanılmamalıdır. Ancak, üretime makul ölçüde yakın görünen her şey, bir kitle kitlesine yönelik platformdaki soruları yanıtlamak için işsizlere ödeme yaparak veya gerçek kullanıcılar üzerinde canlı bir deneme yaparak daha fazla test edilmelidir.

Bunun iki nedeni vardır. Bunların birincisi, koda çok yakın olmanızdır. Gönderilerin belirli bir yönünü arıyor olabilirsiniz veya duygusal açıdan fazlasıyla ilgileniyorsunuz (ör. onay ön yargısı). İkincisi, zamanınızın çok değerli olduğu. Bir saatlik toplantıda çalışan dokuz mühendisin maliyetini düşünün ve bir kitle platformunda satın alma işlemi gerçekleştiren gerçek kişi olan kaç adet etiketin bulunduğunu düşünün.

Kullanıcılardan gerçekten geri bildirim almak istiyorsanız kullanıcı deneyimi yöntemlerini kullanın. Kullanıcı karakterleri oluşturun (açıklamalardan biri Bill Buxton'un Sketching User Experiences'ta, bir işlemde erkenden) ve kullanılabilirlik testi yapın (açıklamalardan biri Steve Krug'un Don’t Think Me bölümünde). Kullanıcı karakterleri varsayımsal bir kullanıcı oluşturmayı kapsar. Örneğin, ekibiniz tüm erkeklerse 35 yaşındaki bir kadın kullanıcı karakteri (kullanıcı özellikleriyle birlikte) tasarlayabilir ve 25-40 yaş arasındaki erkekler için 10 sonuç yerine elde edilen sonuçlara bakabilir. Kullanılabilirlik testiyle gerçek kullanıcıların sitenize verdiği tepkiyi (yerel veya uzaktan) izlemelerini sağlayarak yeni bir bakış açısına sahip olabilirsiniz.

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

Herhangi 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, bir sıralama sorununuz varsa her iki modeli de tüm sistem genelinde bir sorgu örneğinde çalıştırın ve sonuçların simetrik farkının (sıralama konumuna göre ağırlıklandırılan) boyutuna bakın. Fark çok küçükse, deneme çalıştırmadan ç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 ne şekilde olduğunu niteliksel olarak anlamanıza yardımcı olabilir. Bununla birlikte, sistemin kararlı olduğundan emin olun. Kendisiyle karşılaştırıldığında bir modelin simetrik farkının (ideal olarak sıfır) düşük olduğundan emin olun.

25. Kural: Kullanışlı performans, tahmin gücüne üstün gelir.

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 son sıralamanın kalitesi, tahminin kendisinden daha önemlidir. Bir dokümanın spam olasılığını tahmin eder ve ardından engellenecek noktalara son verilirse izin verilen şeyin kesinliği daha önemlidir. Çoğu zaman bu iki şeyin üzerinde anlaşmaya varılması gerekir. Aynı görüşte olmadıklarında küçük bir kazanç elde edebilirler. 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 daha sık gerçekleşmeye başladığında modelinizin hedefini tekrar gözden geçirmiş olursunuz.

26. Kural: Ölçülen hatalarda kalıplar olup olmadığını kontrol edin ve yeni özellikler oluşturun.

Modelin "yanlış" olduğuna dair bir eğitim örneği gördüğünüzü varsayalım. Bir sınıflandırma görevinde bu hata yanlış pozitif veya yanlış negatif olabilir. Sıralama görevinde hata, pozitifin negatiften daha düşük sıralamaya sahip olduğu bir çift olabilir. En önemli nokta, makine öğrenimi sisteminin bir hata olduğunu bildiği ve bu fırsatta hatanın düzeltilmesini istediği bir örnektir. Modele, hatayı düzeltmesine olanak tanıyan bir özellik verirseniz model kullanmaya çalışır.

Diğer yandan, sistemin hata olarak görmediği örneklere dayanarak bir özellik oluşturmaya çalışırsanız bu özellik yok sayılır. Örneğin, Play Uygulamalar Araması'nda bir kullanıcının "ücretsiz oyunlar"ı aradığını varsayalım. En iyi sonuçlardan birinin alaka düzeyi daha düşük olan bir ölçüm uygulaması olduğunu varsayalım. Bu durumda "gaga 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 oyunlar aradıklarında bir gaga uygulaması yüklerse "gaga uygulamaları" özelliği istediğiniz etkiyi yaratmaz.

Modelin hatalı örneklerine dair örnekler bulduktan sonra, mevcut özellik kümenizin dışındaki eğilimleri arayın. Örneğin, sistem daha uzun gönderilerin sıralamasını düşürüyorsa yayın uzunluğu ekleyin. Eklediğiniz özellikler konusunda çok spesifik olmayın. Gönderi uzunluğu ekleyecekseniz bunun ne anlama geldiğini tahmin etmeye çalışmayın, bir düzine özellik ekleyin ve modelin bunlarla ne yapacağını belirlemesine izin verin (21. Kural'ı inceleyin). İstediğiniz her şeyi elde etmenin en kolay yolu budur.

27. Kural: İstenmeyen istenmeyen davranışı ölçmeye çalışın.

Ekibinizin bazı üyeleri, mevcut kayıp işlevi tarafından yakalanmayan, beğenmedikleri sistem özelliklerinden sıkılmaya başlayacaktır. Bu noktada, üzerlerini katı sayılara dönüştürmek için gereken her şeyi yapmalıdır. Örneğin, Play Arama'da çok fazla "gaga uygulamasının" gösterildiğini düşünüyorlarsa gerçek kişi olan değerlendiricilerin gaga uygulamalarını tanımlamalarını sağlayabilirler. (Bu durumda gerçek kişi tarafından etiketlenmiş verileri kullanabilirsiniz, çünkü sorguların nispeten küçük bir kısmı trafiğin büyük bir kısmını oluşturmaktadır.) Sorunlarınız ölçülebilirse özellik, hedef veya metrik olarak kullanmaya başlayabilirsiniz. Genel kural "ilkini ölç, ikinciyi optimize et" şeklindedir.

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

Her doc_id ve tam_sorguya bakan, ardından her sorgu için her bir dokümanın tıklama olasılığını hesaplayan yeni bir sisteminiz olduğunu düşünün. Hem yan yana hem de A/B testi açısından mevcut sisteminizle neredeyse aynı olduğunu göreceksiniz. Bu nedenle, basit olması açısından bunu kullanıma sunacaksınız. Ancak yeni uygulamaların gösterilmediğini fark ediyorsunuz. Bunun sebebi nedir? Sisteminiz bu sorguyla yalnızca kendi geçmişine dayalı bir doküman gösterdiğinden, yeni bir dokümanın gösterilmesini sağlamanın bir yolu yoktur.

Böyle bir sistemin uzun vadede nasıl çalışacağını anlamanın tek yolu, sistemin yalnızca model yayınlanırken elde edilen verilerle eğitilmesidir. Bu oldukça zor.

Eğitim Sunum Sapı

Eğitim sunma sapması, eğitim sırasında performans ile yayınlama sırasındaki performans arasındaki farktır. Bu sapmanın nedeni şunlar olabilir:

• Eğitim ve sunum ardışık düzenlerindeki verileri işleme şekliniz arasında tutarsızlık.
• Eğitme ile yayınlama arasındaki verilerde değişiklik.
• Modelinizle algoritmanız arasında geri bildirim döngüsü.

Google'da üretim makine öğrenimi sistemlerinin performansı olumsuz etkileyen eğitim odaklı sapmalar gözlemledik. En iyi çözüm, sistem ve veri değişikliklerinin fark edilmeden çarpıklığa neden olmayacak şekilde açık bir şekilde izlemektir.

29. Kural: Sunma 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.

Bu işlemi her örnek için yapamasanız bile küçük bir bölüm için uygulayın. Böylece, yayınlama ve eğitim arasındaki tutarlılığı doğrulayabilirsiniz (37. Kural'ı inceleyin). Google'da bu ölçümü yapan ekipler bazen sonuçlardan dolayı şaşırıyor. YouTube ana sayfası, önemli kalite iyileştirmeleri ve kod karmaşıklığında azalma ile sunum sırasında günlük kaydı özelliklerine geçiş yapmıştır ve birçok ekip, biz konuşurken altyapılarını değiştirmiştir.

30. Kural: Önem ağırlığıyla örneklenmiş veriler, rastgele bırakmayın!

Çok fazla veriniz olduğunda, 1-12 dosyalarını alıp 13-99 arasındaki dosyaları yoksaymak isteyebilirsiniz. Bu yanlıştır. Kullanıcıya hiç gösterilmeyen veriler çıkarılabilir ancak geri kalan öğeler için önem ağırlıklandırma en iyi seçenektir. Önem ağırlıklandırması, %30'lık bir olasılıkla X örneği kullanmaya karar verirseniz buna 10/3 ağırlığını verir. Önem ağırlıklandırması ile 14. Kural'da açıklanan tüm kalibrasyon özellikleri devam eder.

31. Kural: Eğitim ve sunum saatinde bir tablodaki verileri birleştirirseniz tablodaki verilerin değişebileceğini unutmayın.

Doküman kimliklerini bu dokümanlara ilişkin özellikler (yorum veya tıklama sayısı gibi) içeren bir tabloyla birleştirdiğinizi varsayalım. Tablodaki özellikler, eğitim ve sunum zamanı arasında değiştirilebilir. Daha sonra modelinizin aynı dokümana yönelik tahmini, eğitim ve sunum açısından farklılık gösterebilir. Bu tür bir sorundan kaçınmanın en kolay yolu, özellikleri yayın sırasında kaydetmektir (32. Kural'a bakın). Tablo yalnızca yavaş değişiyorsa verileri önemli ölçüde kapatmak için tablonun saatlik veya günlük anlık görüntüsünü de alabilirsiniz. Yine de sorunun tamamen çözülmediğini unutmayın.

32. Kural: Mümkün olduğunda eğitim hattınız ile hizmet hattınız arasında yeniden kod kullanın.

Toplu işlem, online işlemeden farklıdır. Online işlemlerde, her isteği geldikçe işlemeniz gerekir (ör. her sorgu için ayrı bir arama yapmanız gerekir). Toplu işlemlerde ise görevleri birleştirebilirsiniz (ör. katılma). Yayınlama sırasında çevrimiçi işlem yapıyorsunuz ancak eğitim bir toplu işlem görevidir. Ancak, kodu yeniden kullanmak için yapabileceğiniz bazı işlemler vardır. Örneğin, sisteminize özgü bir nesne oluşturabilirsiniz. Bu nesnede, sorgu veya birleştirme işlemi sonuçları herkese açık şekilde okunabilir ve hatalar kolayca test edilebilir. Tüm bilgileri topladıktan sonra, sunum veya eğitim sırasında sisteminize özgü, kullanıcılar tarafından okunabilir nesne ile makine öğrenimi sisteminin seçtiği biçim arasında köprü kurmak için yaygın olarak kullanılan bir yöntem çalıştırırsınız. Bu, eğitim sunma sapmasından kaynaklanan bir kaynağı ortadan kaldırır. Ortak çalışma 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: Verilere dayalı bir model 5 Ocak'a kadar oluşturursanız modeli 6 Ocak'tan sonraki verilere göre test edin.

Genel olarak, bir modelin eğitilmesinden sonra toplanan verilerde modelin performansını ölçün. Bu, sisteminizin üretimde ne yapacağını daha iyi yansıtır. 5 Ocak'a kadar olan verileri temel alan bir model oluşturursanız modeli 6 Ocak'a ait veriler üzerinde test edin. Performansın yeni verilerde muhtemelen daha iyi olmasını bekleyeceksiniz, ancak kesinlikle daha kötü olmayacak. Günlük etkileri olabileceği için ortalama tıklama oranını veya dönüşüm oranını tahmin etmeyebilirsiniz. Ancak eğrinin altındaki alan, pozitif örneğe negatif örnek üzerinden daha yüksek bir puan verme olasılığını temsil eder.

34. Kural: Filtreleme için ikili sınıflandırmada (spam tespiti veya ilgi çekici e-postaları belirleme gibi) çok temiz veriler için performansta küçük ölçekli kısa süreli fedakarlıklar yapın.

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

Ancak bu yaklaşım örneklemede sapmalara yol açar. Bunun yerine, sunum sırasında tüm trafiğin% 1'ini "beklemede" olarak etiketler ve tüm hariç tutulan örnekleri kullanıcıya gönderirseniz daha temiz veriler toplayabilirsiniz. Filtreniz negatif örneklerin en az% 74'ünü engelliyor. Bu örnekler, eğitim verileriniz haline gelebilir.

Filtreniz negatif örneklerin% 95'ini veya daha fazlasını engelliyorsa bu yaklaşımın daha az uygulanabilir hale geleceğ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ı doğru şekilde tahmin etmek için on bin örnek yeterli.

35. Kural: Sıralama sorunlarının yapısındaki sapmaya dikkat edin.

Sıralama algoritmanızı farklı sonuçlar ortaya çıkacak kadar önemli ölçüde değiştirdiğinizde, algoritmanızın gelecekte göreceği verileri etkili bir şekilde değiştirmiş olursunuz. Bu tür sapmalar görünür. Modelinizi buna göre tasarlamanız gerekir. Birden fazla farklı yaklaşım vardır. Bu yaklaşımların hepsi, modelinizin önceden görmüş olduğu verileri tercih etmenin yollarıdır.

1. Yalnızca bir sorgu için etkin olan özelliklere kıyasla daha fazla sorgu içeren özelliklere daha yüksek bir normalleştirme yapabilirsiniz. Bu şekilde model, tüm sorgular için genel olan özelliklere kıyasla bir veya birkaç sorguya özgü özellikleri tercih eder. Bu yaklaşım, çok popüler sonuçların alakasız sorgulara sızmasını önlemeye yardımcı olabilir. Bunun, daha özgün değerlerle özellik sütunlarında daha fazla normalleştirme önerisinin tersi olduğuna dikkat edin.
2. Yalnızca özelliklerin ağırlıkları pozitif olmalıdır. Yani iyi bir özellik, "bilinmeyen" bir özellikten daha iyi olacaktır.
3. Yalnızca doküman özelliklerini kullanmayın. Bu, 1 numaralı sürümün aşırı derecede kullanımıdır. Örneğin, belirli bir uygulama, sorgunun ne olduğundan bağımsız olarak popüler bir indirme olsa bile bunu her yerde göstermek istemezsiniz. Yalnızca doküman özelliğine sahip olmamak, bu kadar basit. Her yerde belirli bir popüler uygulamayı göstermemenizin nedeni, istenen tüm uygulamaları erişilebilir hale getirmenin önemidir. Örneğin, "kuş izleme uygulaması" için arama yapan bir kullanıcı "öfkeli kuşlar"ı indirebilir, ancak amacı her zaman bu değildir. Böyle bir uygulama göstermek indirme oranını artırabilir ancak kullanıcının nihayetinde tatmin olmamasına neden olur.

36. Kural: Konum özelliği olan geri bildirim döngülerinden kaçının.

İçeriğin konumu, kullanıcının içerikle etkileşime geçme olasılığını önemli ölçüde etkiler. İlk sıraya koyduğunuz uygulama daha sık tıklanır ve tıklanma olasılığınız artar. Bu konuyla başa çıkmanın bir yolu, konum özellikleri (ör. içeriğin sayfadaki konumuyla ilgili özellikler) eklemektir. Modelinizi konumlandırma özellikleriyle eğitiyorsunuz ve ağırlıklandırmayı öğreniyor (örneğin, "1. sıra"). Bu nedenle modeliniz, "1stposition=true" içeren örnekler için diğer faktörlere daha az ağırlık verir. Ardından, sunma sırasında herhangi bir konuma sahip özellik sağlamazsınız veya örneklere aynı varsayılan özelliği sağlamazsınız. Böylece, adayları hangi sırayla göstereceğinize karar vermeden önce puan kazanırsınız.

Eğitim ve test arasındaki asimetri nedeniyle konum özelliklerinin, modelin geri kalanından biraz farklı tutulmasının önemli olduğunu unutmayın. Modelin, konum özelliklerinin ve geri kalan özelliklerin işlevlerinin toplamı olması idealdir. Örneğin, konum özelliklerini herhangi bir doküman özelliğiyle çarpın.

37. Kural: Eğitim/Sapma Ölçümü.

En genel anlamda sapmaya neden olabilecek birkaç şey vardır. Ayrıca, raporu birkaç bölüme ayırabilirsiniz:

• Eğitim verileri ile elden çıkarma verilerindeki performans arasındaki fark. Genel olarak bu her zaman var olacaktır ve her zaman kötü değildir.
• Duraklatma verilerindeki performans ile "sonraki gün" verileri arasındaki fark. Aynı şekilde, bu öğe her zaman mevcut olacak. Sonraki gün performansı en üst düzeye çıkarmak için normalleştirmenizde ayarlamalar yapmanız gerekir. Ancak, muhafaza ve sonraki günün verileri arasında büyük performans düşüşleri, bazı özelliklerin zamana duyarlı olduğu ve muhtemelen model performansının düştüğü anlamına gelebilir.
• "Ertesi gün" verilerindeki performans ile canlı veriler arasındaki fark. Bir modeli eğitim verilerindeki bir örneğe ve sunum sırasında da aynı örneğe uygularsanız, tam olarak aynı sonucu vermelisiniz (5. Kural'a bakın). Bu nedenle, burada bir tutarsızlık büyük olasılıkla bir mühendislik hatasıdır.

ML 3. Aşama: Yavaş Büyüme, Optimizasyon Ayrıntılandırması ve Karmaşık Modeller

İkinci aşamanın sona ermek üzere olduğuna dair belirli göstergeler olacaktır. Öncelikle, aylık kazancınız azalmaya başlar. Metrikler arasında bazı dengeler kurulacaktır: Bazı denemelerde bazı artışlar görürsünüz, bazılarında ise düşüş olur. İş burada ilginçtir. Kazançların gerçekleştirilmesi daha zor olduğundan, makine öğreniminin daha gelişmiş olması gerekir. Dikkat: Bu bölümün önceki bölümlerden daha fazla mavi gökyüzü kuralı vardır. Birçok ekibin II. Aşama ve makine öğrenimi 2. aşamanın mutluluğuna şahit olduğunu gördük. III. Aşamaya ulaşıldığında ekiplerin kendi yollarını bulmaları gerekir.

38. Kural: Uyumlu olmayan hedefler sorun haline gelirse yeni özelliklerle zaman harcamayın.

Ölçümleriniz lokomotif olduğundan, ekibiniz mevcut makine öğrenimi sisteminizin hedeflerinin dışında kalan sorunları incelemeye başlayacak. 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ıklama sayısını, artı birleri veya indirmeleri optimize edebilir ancak başlatma kararlarını kısmen insan değerlendiricilere göre verebilirsiniz.

39. Kural: Lansman kararları, uzun vadeli ürün hedeflerini temsil eden proxy'lerdir.

Ayşe, yüklemeleri tahmin etmenin lojistik kaybını azaltma konusunda bir fikir edinmiştir. Bir özellik ekliyor. Lojistik kayıplar. Canlı deneme yaptığında, yükleme oranındaki artışı görüyor. Bununla birlikte, lansman incelemesi toplantısına gittiğinde birisi günlük etkin kullanıcı sayısının %5 düştüğünü görüyor. Ekip, modeli başlatmamaya karar verir. Hayal kırıklığına uğrayan Alice, başlatma kararlarının artık yalnızca bir kısmı makine öğrenimi kullanılarak doğrudan optimize edilebilen birden çok ölçüte dayandığını fark ediyor.

Gerçek dünyada zindanların ve ejderhaların olmadığı gerçektir: Ürününüzün durumunu tanımlayan "isabet noktaları" yoktur. Ekibin, gelecekte sistem için ne kadar iyi olacağını etkili bir şekilde tahmin etmek için topladığı istatistikleri kullanması gerekir. Etkileşim, 1 günlük etkin kullanıcı sayısı (GEKS), 30 günlük etkin kullanıcı sayısı, gelir ve reklamverenin yatırım getirisi gibi konulara önem vermelidir. A/B testlerinde kendi başına ölçülebilen bu metrikler, daha uzun süreli hedeflerin yalnızca bir göstergesidir: kullanıcıları memnun etme, kullanıcıları artırma, iş ortaklarını tatmin etme ve kâr; bu süre zarfında beş yıl içinde kullanışlı, yüksek kaliteli bir ürün ve başarılı bir şirket haline gelmek için proxy'leri de düşünebilirsiniz.

Kullanıma sunulan tek kolay karar tüm metriklerin daha iyi hale gelmesi (veya en azından kötüleşmemesi) şeklindedir. Ekip gelişmiş bir makine öğrenimi algoritması ve basit bir buluşsal yöntem arasında seçim yapabiliyorsa basit buluşsal, tüm bu metriklerde daha iyi sonuç verirse, buluşsalyı seçmelidir. Dahası, 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
C	1 milyon	4 milyon ABD doları
B	2 milyon	2 milyon ABD doları

Mevcut sistem A ise ekibin B'ye geçme olasılığı düşüktür. Mevcut sistem B ise ekibinizin A'ya geçme olasılığı düşüktür. Bu, rasyonel davranışla çelişiyor gibi görünüyor. Ancak, metriklerin değiştirilmesiyle ilgili tahminler gözden kaçabilir veya kaybolabilir ve bu nedenle, bu iki değişikliğin büyük bir riski vardır. Her metrik, ekibin endişelendiği bazı riskleri kapsar.

Üstelik, ekibin en büyük endişesi olan "ürünüm bundan sonra beş yıl sonra nerede olacak?" gibi soruların cevabını bulmuyor.

Diğer yandan, bireyler doğrudan optimize edebildikleri bir hedefi tercih eder. Çoğu makine öğrenimi aracı böyle bir ortamı tercih eder. Yeni özellikleri fark eden bir mühendisin faaliyetleri, böyle bir ortamda istikrarlı bir şekilde lansman başlatabiliyor. Bu sorunu gidermeye başlayan bir makine öğrenimi türü, çok amaçlı öğrenme vardır. Örneğin, her bir metriğe daha düşük sınırlar sunan ve bazı metrik kombinasyonunu optimize eden bir kısıtlama memnuniyeti oluşturabilir. Bununla birlikte bile, bazı metrikler makine öğrenimi hedefleri olarak kolayca çerçevelenemez: Bir belgenin tıklanması ya da bir uygulamanın yüklenmesi, içeriğin gösterilmesinden kaynaklanır. Ancak bir kullanıcının sitenizi neden ziyaret ettiğini anlamak çok daha zordur. Bir sitenin tamamının gelecekteki başarısını tahmin etmek için AI'yı kullanabilirsiniz. Bu, 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ıklamak ve anlamak için en kolay modellerdir. Ancak, çeşitli modellerin bir kombinasyonu (diğer modellerin puanlarını birleştiren bir "model") daha iyi çalışabilir. Her şeyin basit olması için her model yalnızca diğer modellerin girdilerini içeren bir topluluk veya birçok özelliği temel alan bir temel model olmalıdır ancak ikisini birden değil. Ayrı olarak eğitilen diğer modellerin üzerinde modelleriniz varsa bu modelleri birleştirmek kötü davranışa neden olabilir.

Birleştirme için, yalnızca "taban" modellerinizin çıkışını giriş olarak alan basit bir model kullanın. Bu toplu taşıma modellerinde de özellikleri uygulamak istersiniz. Örneğin, temel model tarafından üretilen puandaki artış, topluluğun puanını da düşürmemelidir. Ayrıca, temel modellerdeki değişikliklerin toplu modeli etkilememesi için gelen modellerin anlam açısından yorumlanabilir olması (örneğin, kalibre edilmesi) en iyisidir. Ayrıca, temel alınan bir sınıflandırıcının tahmini olasılığındaki artışın, topluluğun tahmini olasılığını azaltmayacağını zorunlu kılın.

41. Kural: Performans göstergeleri söz konusu olduğunda mevcut sinyalleri hassaslaştırmak yerine niteliksel olarak eklenecek yeni bilgi kaynaklarını arayın.

Kullanıcıyla ilgili bazı demografik bilgileri eklediniz. Dokümandaki kelimeler hakkında bazı bilgiler eklediniz. Şablon keşfini tamamladınız ve düzenlemeyi ayarladınız. Birkaç ayda temel metriklerinizde% 1'den fazla artış sağlayan bir lansman görmediniz. Şimdi önemli olan nedir?

Bu kullanıcının son bir gün, bir hafta veya bir yıl içinde eriştiği dokümanların geçmişi ya da farklı bir mülke ait veriler gibi tamamıyla farklı özellikler için altyapı oluşturmaya başlamanın zamanı geldi. wikiveri öğelerini veya şirketinizin içinde bulunan bir şeyi kullanın (Google’ın bilgi grafiği gibi). Derin öğrenmeyi kullanın. Yatırım getirisi beklentilerinizi ayarlamaya başlayın ve çalışmalarınızı buna göre genişletin. Tüm mühendislik projelerinde olduğu gibi, yeni özellikler eklemenin avantajını artan karmaşıklık maliyetine göre değerlendirmeniz gerekir.

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

Bir içerik kümesindeki çeşitlilik çok fazla anlam ifade edebilir. Bu nedenle, içeriğin kaynağı en yaygın olanlardan biridir. Kişiselleştirme, her kullanıcının kendi sonuçlarına ulaşacağı anlamına gelir. Alaka düzeyi, belirli bir sorguya ait sonuçların diğerinden daha uygun olduğunu belirtir. Dolayısıyla, bu özelliklerin üçü de sıradandan farklıdır.

Sorun şu ki sıradan bir şeyi geçmek zor.

Sisteminiz tıklama sayısını, harcanan süreyi, izlenme süresini, +1'leri, yeniden paylaşımları vb. ölçüyorsa içeriğin popülerliğini ölçtüğünüzü unutmayın. Ekipler bazen çeşitliliğe sahip 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 dokümanın, döndürülen diğer dokümanlarla (yazar veya içerik gibi) ortak özelliklere sahip olup olmadığını belirten özellikler) ekleyeceği ve bu özelliklerin beklenenden daha az ağırlık aldığını (veya bazen farklı bir işaret aldığını) ekler.

Bu, ç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 işleme sonrası yapabilirsiniz. Uzun vadeli hedeflerde artış gözlemlerseniz popülerliğin yanı sıra çeşitliliğin/alakanın değerli olduğunu belirtebilirsiniz. Daha sonra, işleme sürecini kullanmaya devam edebilir veya hedefi çeşitliliğe veya alaka düzeyine göre doğrudan değiştirebilirsiniz.

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

Google'daki ekipler, bir üründeki bağlantının yakınlığını tahmin eden ve bu ürünleri başka bir üründe iyi kullanan bir model kullanarak çok ilgi gördü. Arkadaşlarınız kimdir? Diğer yandan, çeşitli gruplarda ürün grupları arasında kişiselleştirme özellikleriyle mücadele eden bazı ekipler izledim. Evet, çalışması gibi görünüyor. Şimdilik öyle görünmüyor. Zaman zaman işe yarayan bir şey, bir mülk üzerindeki davranışı tahmin etmek için bir mülkün ham verilerini kullanmaktır. Ayrıca, bir kullanıcının başka bir mülkte geçmişi olduğunu bilmenin bile yardımcı olabileceğini unutmayın. Örneğin, iki üründeki kullanıcı etkinliğinin varlığı başlı başına bir gösterge olabilir.

İlgili İş

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

• Makine Öğrenimi Kilitlenme Kursu: Uygulamalı makine öğrenimine giriş.
• Makine Öğrenimi alanını anlamayı amaçlayan Kevin Murphy tarafından Makine Öğrenimi: Olasılık Yaklaşımı başlıklı makaleyi inceleyin.
• İyi Veri Analizi: Veri kümeleri hakkında düşünmeye yönelik bir veri bilimi yaklaşımı.
• Lineer olmayan modelleri öğrenmek için Ian Goodfellow ve diğerleri tarafından Deep Learning.
• Çok sayıda genel tavsiye içeren teknik borç hakkında Google makalesi.
• Tensorflow Dokümanları.

Onaylar

David Westbrook, Peter Brandt, Samuel Ieong, Chenyu Zhao, Li Wei, Michalis Potamias, Evan Rosen, Barry Rosenberg, Christine Robson, James Pine, Tal Shaked, Tushar Chandra, Mustafa Ispir, Jeremiah Harmsen, Prassay Norveç, Norveç Norveç, Norveç, Norveç, Norveç, Norveç, Cephe Ayrıca, daha önceki bir sürüme yardımcı olan Kristen Lefevre, Suddha Basu ve Chris Berg'e de teşekkür ederiz. Tüm hatalar, eksiklikler veya (popüler!) popüler olmayan düşünceler bana aittir.

Ek

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

YouTube'a Genel Bakış

YouTube bir akışlı video hizmetidir. Hem YouTube Next hem de YouTube Ana Sayfası ekipleri, video önerilerini sıralamak için makine öğrenimi modellerini kullanır. Sıradaki Video, ş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, çeşitli sorunları çözen birçok modele sahiptir. Play Arama, Play Ana Sayfa Kişiselleştirilmiş Öneriler ve "Kullanıcılar Aynı zamanda Yüklü" uygulamalarının tümü makine öğrenimini kullanır.

Google Artı'ya Genel Bakış

Google Plus, makine öğrenimini çeşitli durumlarda kullandı: Kullanıcı tarafından görülen yayınların "akışında" yayınları sıralama, "Popüler Olanlar" yayınları (şu anda çok popüler olan yayınlar), tanıdığınız kullanıcıları sıralama vb. Google Plus, 2019'da tüm kişisel hesapları kapattı ve 6 Temmuz 2020'de işletme hesaplarının yerine Google Currents'ı kullanmaya başladı.