Kendi ürünümün kullanmayı reddettiği uplift sayısı

Aegis bir churn ürünü. Kimin gideceğini skorluyor, nedenini açıklıyor ve asıl önemli olan şeyi tahmin ediyor: sen bir şey yaptığın için kimin kalacağını. Bu miktarın adı uplift ve elde tutma bütçesinin nereye harcanacağını söyleyen tek sayı o.

Aegis bunu hesaplıyor. T-learner eğitiyor, eğriyi çiziyor, panoya koyuyor. Sonra skoru gerçek bir aksiyona çeviren yerde o sayıyı çöpe atıyor ve segment düzeyi varsayımlara düşüyor.

Bu bilinçli bir karardı, demoya en iyi özelliğine mal oldu, ve tekrar aynısını yapardım.

Sayı neden kullanılamaz

Pakete gömülü veri seti IBM/Kaggle Telco Customer Churn. İyi bir duman testi veri seti: küçük, temiz, gerçekçi bir kolon kümesi, bir API'yi ve panoyu çalıştırmak için yeterli. Herkesin onunla yapmak istediği şey için ise diskalifiye eden tek bir özelliği var.

İçinde treatment ataması yok. Kimseye indirim teklif edilmemiş. Kimse kontrol grubu olarak ayrılmamış.

Uplift iki dünya arasındaki farktır — müdahaleyi alan müşteri ile aynı müşterinin almamış hali. Veri hiçbir müdahale kaydetmediyse o fark dosyada yoktur. Yine de bir sayı hesaplayabilirsin. Hesaplarsın da. Güven aralığıyla birlikte, düzgün biçimli bir ondalık sayı olur — ve senin kendi varsayımlarını tarif eder.

Kolay versiyonu nasıl görünür

Kolay versiyonu tek bir fonksiyon. Makul bir treatment kolonu üret — örnekle, organik dursun diye tenure ve sözleşme tipiyle biraz korelasyonla — iki sonuç modelini eğit, ve pano güzel bir uplift decile grafiğiyle dolsun. Demoda kusursuz durur. Ürünün yapabileceği en sahtekâr şey de budur, çünkü o grafiğin her parçası benim o öğleden sonra yazdığım üreticinin bir özelliğidir.

Tuzak sahte olması değil. Demo verisi normalde sorun değildir. Tuzak şu: uplift tanımı gereği treatment kolonuna bağlıdır, dolayısıyla treatment'ı uydurmak cevaba yaklaşmaz — soruyu değiştirir.

Aegis bunun yerine ne yapıyor

Üç şey, ve dişi olan üçüncüsü.

Gömülü treatment üreticisi duruyor ve ürün akışı yerelde çalıştırılabilsin diye simülasyon olarak belgeleniyor. Uplift motoru her sonuca açık treatment-kanıt üstverisi iliştiriyor, yani bir sayı her zaman treatment atamasının nereden geldiğini söyleyen bir ifadeyle birlikte dolaşıyor. Ve tahmin rotasında, simüle CATE karar başarı oranı tahmininde atlanıyor; sistem segment düzeyi varsayımlara düşüyor.

Yani grafik ekranda, sayı kararın içinde değil. İnceleyen biri mekanizmanın uçtan uca çalıştığını görebiliyor, ve aşağı akışta hiçbir şey yukarıda imal edilmiş bir miktarı harcamıyor.

Bedeli ne

Demo daha kötü. Bu ürünün gösterebileceği en etkileyici şey — "işte elde tutma teklifinin sonucu gerçekten değiştirdiği müşteriler, sıralı" — gözle görülür biçimde simüle kanıt üzerinde koşuyor ve bunu sayfada söylüyor. Bu ayrımı yapmayan bir rakiple ekran görüntüsü karşılaştıran biri, rakibinkini daha iyi bulacak.

Tüm değer önerisi "önerileri savunulabilir" olan bir ürün için doğru takas bu bence. Müşterilerini kendi uydurduğu bir uplift'e göre kendinden emin sıralayan bir churn aracı, iyisinin küçük hali değildir. Başka bir üründür ve kontrol etmeyen bir alıcıya bakar.

Çıkardığım genel kural

Belirli bir kolonu olmayan bir veri setinden, model ne kadar iyi olursa olsun tahmin edilemeyecek bir miktar sınıfı var. Uplift treatment ataması ister. Kalibrasyon eğrisi sonuç ister. A/B farkı iki kolu birden ister. Kolon eksikse seçenekler şunlar: onu elde et, miktarı reddet, ya da varsayımlarını anlatan bir sayı üret.

Üçüncüsü her zaman mevcuttur, her zaman çalışır ve asla hata vermez. Tam da bu yüzden dipnotta değil kodda reddedilmesi gerekir — README'deki bir uyarı, aşağı akıştaki bir servisin o alanı okumasını engellemez.

Tutmaya çalıştığım çizgi: bir pipeline her şeyi hesaplayabilir ve etiketlediği her şeyi gösterebilir. Yalnızca girdileri var olan miktarlara göre hareket edebilir.