2011’de bir reklam modeline eklediğim on bir özellik

Haziran 2011’de Palo Alto’da, Facebook’un Reklam Optimizasyonu ekibinde yazılım mühendisliği stajyeri olarak işe başladım; Eylül’de ayrıldım. O üç ayda yaptığım işin adı özellik çıkarımıydı (feature extraction). Bugün o iş büyük ölçüde ortadan kalktı.

Ekibin merkezindeki model tıklama oranı (CTR) tahminiydi. Bir kullanıcı ve bir reklam verildiğinde, o reklamın tıklanma olasılığını tahmin eder. Bu sayı reklamın gösterilip gösterilmeyeceğini, hangi sırada duracağını ve fiyatlamanın nereden başlayacağını belirlediği için sistemin geri kalanı onun etrafına kurulur. Modelin biçiminden çok, modele hangi kolonların verildiği belirleyiciydi.

Arkadaş sayısı

Fark ettiğim ilk şey basitti: kullanıcının arkadaş sayısı, tıklama tahminini belirgin biçimde iyileştiriyordu.

Bir önceki yaz IPAM’da, UCLA ve IBM Research ortaklığındaki bir projede mikrobloglarda konu tespiti ve nedensel etki modellemesi üzerine çalışmıştım. Sosyal veriye bu gözle bakma alışkanlığı oradan geliyordu.

Arkadaş sayısı tek başına bir reklam sinyali değildir; kimse arkadaşı çok diye bir reklama tıklamaz. O kolonun yaptığı iş, ölçemediğiniz onlarca şeyin yerine geçmekti: hesabın ne kadar eski olduğu, kişinin platformda gerçekten yaşayıp yaşamadığı, akışında ne kadar tanıdık içerik gördüğü. Bu benim açıklamamdı, kanıtlanmış bir mekanizma değil. Ölçüm tarafı ise nettir: kolon eklendiğinde tahmin iyileşiyordu.

Asıl mesele tek bir kolon değildi, açtığı kapıydı. Bir özelliğin beklenenden fazla iş görmesi çoğu zaman o özellikle ilgili değildir; modelin hiç bakmadığı bir bölge olduğunu gösterir. Önemli olan kazanılan puan değil, puanın nereden geldiğidir. Arkadaş sayısı küçük bir kolondu ama bütün bir veri kümesinin adresini veriyordu: sosyal grafikten türetilebilecek ne varsa denenmeye değerdi. Sosyal özellik çıkarımı çalışmasını buradan başlayarak yürüttüm.

Özellik çıkarımı gerçekte neye benziyordu

Döngü şuydu. Bir hipotez yazarsınız: şu bilgi tıklama olasılığıyla ilgilidir. Sonra o bilginin hangi tabloda, hangi biçimde durduğunu bulursunuz — çoğu zaman hiçbir yerde durmuyordur ve türetmeniz gerekir. Kolonu yeterince büyük bir örneklem üzerinde hesaplarsınız. Modele ekler, ölçersiniz. Sonra asıl soruyu sorarsınız: bu kolon, modelde zaten olanların üzerine ne koyuyor?

Fikirlerin çoğu iki yerde ölür. Birincisi, korelasyon vardır ama katkı yoktur; yeni kolonun taşıdığı bilgiyi model başka bir yoldan zaten görmektedir. İkincisi sızıntıdır (leakage): kolon, tahmin anında henüz var olmayan bir bilgiyi dolaylı olarak içerir. İkincisi tehlikelidir, çünkü sonuçları olağanüstü gösterir. Geçmiş veride kusursuz çalışan bir özellik canlı sistemde hiçbir şey ifade etmeyebilir.

Bir de üçüncü eşik vardı: özelliğin, kullanıcı sayfayı yüklerken hesaplanabiliyor olması gerekiyordu. Hesaplaması ağır olan iyi bir özellik, iyi bir özellik değildir.

Bu döngünün ne kadar sürdüğü, işin karakterini belirliyordu. Bir fikirden ölçülmüş bir sonuca gitmek günler alıyorsa günde bir fikir denersiniz ve denediğiniz fikre bağlanırsınız. Döngü kısaldıkça daha çoğunu denersiniz, daha çabuk elersiniz ve fikrin kimden geldiği önemini kaybeder. Bir ekibin özellik üretme hızı, aslında ölçüm altyapısının hızıdır.

On bir özellik

Sonunda on bir yeni özellik buldum ve bunlar eski modele göre ciddi bir iyileşme sağladı. Sonucun asıl kısmı tek tek kolonlardan büyüktü: çalışma, Sponsored Stories için yeni bir CTR modeli geliştirilmesi gerektiğine ekibi ikna etti. Aynı dönemde yeni bir Dağıtım Optimizasyonu Modeli tasarlayıp geliştirdim.

On bir özelliğin listesini buraya yazmıyorum. On beş yıl önce kapalı bir sistemin içindeki kolonlardı; bugün devredilebilir olan da liste değil, listenin nasıl bulunduğu.

O çalışmanın gelir karşılığını dönemin rakamlarıyla kendimce hesaplamıştım ve o sayı yıllarca eski sitemde durdu. Buraya almıyorum: kendi kaba tahminimdi, arkasında duracak bir kaynağım yok. Doğrulayamadığınız bir sayı, yazdığınız her şeyi kendi seviyesine çeker.

Bu iş neden ortadan kalktı

Elle özellik çıkarımı 2011’de bir mühendisin işiydi, bugün büyük ölçüde modelin kendi işi. Aradaki on beş yılda sıralama ve tahmin sistemleri ham sinyalleri doğrudan alıp temsili kendisi öğrenen mimarilere geçti. “Arkadaş sayısı” diye bir kolon yazmak yerine grafiği ya da davranış dizisini modele verirsiniz, model kendi gömme vektörünü (embedding) çıkarır. Elle yazılmış bir kolonun anlatabildiği şey ile öğrenilmiş bir temsilin yakalayabildiği şey arasındaki fark, veri ve hesap gücü ucuzladıkça sürekli açıldı.

Kaybedilen bir şey de var. Elle yazılmış bir kolon aynı zamanda bir tezdir: birinin dünya hakkında kurduğu, tek cümleyle söylenebilen ve yanlışlanabilen bir iddia. “Platformda daha uzun süredir yaşayan insanlar reklamlara farklı tepki verir” gibi. Öğrenilmiş bir temsilde o cümle yoktur. Sistem daha iyi çalışır ama neden çalıştığını anlatan bir cümle bırakmaz, dolayısıyla hata yaptığında elinizde düzeltilecek bir iddia da olmaz.

Bu işin tamamen bittiğini söylemek doğru olmaz. Veri küçükse, tablo hâlindeyse ya da yeni bir kullanıcı hakkında elinizde üç satır varsa, hâlâ birinin oturup doğru kolonu yazması gerekir. Değişen şu: bir zamanlar ekibin merkezinde duran iş artık kenarda duruyor.

Kolon gitti, altındaki dört şey kaldı

Hedefi tanımlamak hâlâ insanın işi. Model temsili öğrenir, neyi tahmin etmesini istediğinizi öğrenmez. Neyi sayıyorsunuz, hangi kullanıcı kümesinde, hangi zaman penceresinde — bu soruların cevabı yanlışsa sistemin geri kalanı kusursuz çalışırken yanlış sonuç üretir. Udemy’de yorumları sıralarken kendime sorduğum soru buydu: “Elimdeki oylara bakınca, gerçek olumlu oy oranının en az ne olduğundan %95 eminim?” Cevabı Wilson skoru güven aralığının alt sınırı veriyordu, ama işin zor kısmı formül değil, soruyu o hâle getirmekti.

Veriyi üretenin ne olduğunu bilmek. Sızıntının bugünkü karşılıkları bol: değerlendirme kümesine karışmış eğitim verisi, geleceği bilen bir bağlam parçası, sırf kullanıcıya gösterildiği için tıklanmış bir öğe. Model size bir kolonun sonradan doldurulduğunu söylemez. Söyleyecek olan sizsiniz.

Hangi sinyalin var olduğunu bilmek. Toolio’da talep tahmini üzerine çalışırken çözmeye uğraştığımız cümle şuydu: “1.000 farklı kıyafet satıyorum ve 100 mağazam var. Her birinden kaç tane üretmeliyim, hangisinden hangi mağazaya kaç tane, ne zaman göndermeliyim?” Buradaki zorluk model seçmek değildi; bu soruya cevap verebilecek bilginin şirketin hangi kaydında durduğunu bulmaktı. 2011’de sorduğum soruyla aynı soru.

Bir fikri hızla elemek. Özellik çıkarımı, kulağa mantıklı gelen fikirlerin çoğunun ölçüldüğünde hiçbir şey getirmediğini gösterir. Bu iş insanın kendi sezgisine duyduğu güveni kalibre eder, çünkü sezginin ne kadar sık yanıldığını sayıyla görürsünüz. On beş yıl sonra da elimde kalan en işe yarar alışkanlık bu.

Aynı soru

Bir modeli iyileştirmenin büyük kısmı modeli değiştirmek değil, ona ne gösterdiğinizi değiştirmektir. 2011’de bu iş bir kolon yazmaktı. Bugün Procurable AI için maliyet modelleri kurarken de aynı yerde duruyorum: sisteme, istek anında hangi bilgiyi koyabiliyorum. Araç değişti, soru olduğu gibi kaldı.