Judea Pearl’in nedensel modellerinin ekiplerin yapay zekâ davranışını açıklamasına, hataları ayıklamasına ve korelasyonların ötesinde daha net ürün kararları almasına nasıl yardımcı olduğunu öğrenin.
Bir ekip panosunda “açık” görünen bir şey fark eder: daha fazla bildirim alan kullanıcılar daha sık geri dönüyor. Bu yüzden bildirim hacmini artırırlar. Bir hafta sonra tutunma düşer ve iptal şikayetleri artar. Ne oldu?
Orijinal desen gerçekti—ama yanıltıcıydı. En ilgili kullanıcılar doğal olarak daha fazla bildirim tetikler (ürünü daha fazla kullandıkları için) ve aynı zamanda daha sık geri dönerler. Bildirimler tutunmayı neden olmadı; etkileşim her ikisini de neden oluyordu. Ekip korelasyona göre hareket etti ve istemeden daha kötü bir deneyim yarattı.
Nedensel düşünme, şu soruyu sorma alışkanlığıdır: ne neyi neden olur ve bunu nasıl bilebiliriz? “Bu iki şey birlikte mi hareket ediyor” ile yetinmek yerine şunları ayırmaya çalışırsınız:
Bu veriye şüpheci bakmak değil—soru konusunda spesifik olmaktır. “Bildirimler ile tutunma korelasyonlu mu?” sorusu, “Daha fazla bildirim göndermek tutunmayı artırır mı?” sorusundan farklıdır. İkinci soru nedenseldir.
Bu yazı desen bulmanın sıkça başarısız olduğu üç pratik alana odaklanıyor:
Bu, nedensel çıkarımın matematiksel açıdan ağır bir turu değil. Değer almak için do-calculus notasyonunu öğrenmenize gerek yok. Amaç, ekibinizin kullanabileceği zihinsel modeller ve bir iş akışı seti sunmak:
Eğer verilerde “iyi görünüp” gerçekte işe yaramayan bir değişiklik göndermişseniz, nedensel düşünme eksik olan bağlantıdır.
Judea Pearl, bilgisayar bilimci ve bilim felsefecisidir; çalışmaları birçok ekip için veri, yapay zeka ve karar verme şekillerini yeniden şekillendirdi. Onun nedensel devriminden önce, bilgisayarda “veriden öğrenme” çoğunlukla istatistiksel ilişkiler üzerine kuruluydu: desenleri bulun, modelleri uydurun, ne olacağını tahmin edin. Bu yaklaşım güçlüdür—ama sorunuz cümlesinde "çünkü" kelimesi olduğunda genellikle başarısız olur.
Pearl’in ana değişimi, nedenselliği birinci sınıf bir kavram olarak ele almaktı; yalnızca korelasyonların üstüne eklenmiş bulanık bir sezgi değil. "X yüksek olduğunda Y de yüksek mi?" demek yerine, nedensel düşünme "Eğer X'i değiştirirsek Y değişir mi?" diye sorar. Bu fark küçük görünse de tahmin ile karar verme arasındaki ayrımı yaratır.
İlişki "ne birlikte olur"u yanıtlar. Nedensellik ise "müdahale edersek ne olur"u cevaplamayı amaçlar. Bu, ürün ve mühendislikte önemlidir çünkü birçok gerçek karar müdahaledir: bir özelliği yayınlamak, sıralamayı değiştirmek, bir koruma eklemek, eğitim setini ayarlamak veya bir politikayı güncellemek.
Pearl, nedenselliği bir modelleme seçimi ve açık varsayımlar olarak çerçevelendirerek daha uygulanabilir hale getirdi. Genel olarak veriden otomatik olarak nedenselliği “keşfetmezsiniz”; bir nedensel hikâye önerirsiniz (genellikle alan bilgisine dayanarak) ve sonra veriyi bunu test etmek, tahmin etmek ve düzeltmek için kullanırsınız.
Bu araçlar, ekiplerin desen bulmaktan net ve disiplinli bir şekilde nedensel soruları yanıtlamaya geçmeleri için ortak bir dil verdi.
Korelasyon, iki şeyin birlikte hareket ettiği anlamına gelir: biri yükseldiğinde diğerinin de yükselme (ya da düşme) eğilimi vardır. Bu son derece kullanışlıdır—özellikle veri ağırlıklı ekiplerde—çünkü tahmin ve tespit için yardımcı olur.
Dondurma satışları sıcaklık yükseldiğinde artıyorsa, korele sinyal (sıcaklık) tahminleri iyileştirebilir. Ürün ve yapay zeka çalışmalarında korelasyonlar sıralama modellerini, anomalileri ve hızlı teşhisleri güçlendirir.
Sorun, korelasyonu farklı bir sorunun cevabı gibi kabul ettiğimizde başlar: Bir şeyi kasıtlı olarak değiştirirsek ne olur? İşte bu nedenselliktir.
Bir korele ilişki üçüncü bir faktör tarafından her iki değişkenin de etkilenmesiyle oluşabilir. X'i değiştirmek Y'yi değiştirmez—çünkü X, Y'nin hareket etmesinin nedeni olmayabilir.
Haftalık pazarlama harcaması ile haftalık satışları çizdiğinizi ve güçlü bir pozitif korelasyon gördüğünüzü varsayın. "Daha çok harcama daha çok satışa neden olur" demek cazip gelebilir.
Ama her ikisinin de tatiller sırasında arttığını farz edin. Mevsimsellik (bir karıştırıcı) hem talebi artırır hem de daha büyük bütçeleri tetikler. Tatil olmayan bir haftada harcamayı artırırsanız, satışlar pek yükselmeyebilir—çünkü alttaki talep yoktur.
Kendinizi şu soruları sorarken buluyorsanız nedensel alandasınız:
Fiilin değiştirmek, yayınlamak, kaldırmak veya azaltmak olduğu durumlarda korelasyon bir başlangıç ipucudur—karar kuralı değildir.
Bir nedensel diyagram—genellikle DAG (Yönlendirilmiş Döngüsüz Grafik) olarak çizilir—ekibin varsayımlarını görünür kılmanın basit bir yoludur. “Model olmuş olabilir” veya “Belki UI” gibi belirsiz tartışmalar yerine hikâyeyi kağıda aktarırsınız.
Amaç mükemmel gerçeği yakalamak değil; “sistemin nasıl çalıştığını düşündüğümüz” konusunda paylaşılan bir taslaktır.
Diyelim ki yeni bir onboarding eğitimi (T)'nin aktivasyonu (A) artırıp artırmadığını değerlendiriyorsunuz.
Analitik refleks genellikle mevcut tüm değişkenleri kontrol etmektir. DAG terimleriyle bu, yanlışlıkla:
DAG ile değişkenleri bir sebeple kontrol edersiniz—genellikle karıştırıcı yollarını kapatmak için—varlar diye değil.
Bir beyaz tahta ve üç adımla başlayın:
Kaba bir DAG bile ürün, veri ve mühendisliği aynı nedensel soru etrafında hizalar.
Pearl’in nedensel düşüncesindeki büyük kayma, gözlemleme ile değiştirmeyi ayırmaktır.
Eğer bildirimleri etkinleştiren kullanıcıların daha iyi tutunduğunu gözlemlerseniz, bir desen öğrenmişsiniz demektir. Ama bildirimlerin tutunmaya neden olup olmadığını hâlâ bilmiyorsunuz; belki ilgili kullanıcılar sadece bildirimleri açmaya meyillidir.
Bir müdahale, bir değişkeni aktif olarak belirlemeniz ve sonra ne olduğunu gözlemlemeniz demektir. Ürün terimleriyle bu, “kullanıcıların X'i seçmesi” değil, “biz X'i gönderdik” demektir.
Pearl bu farkı şöyle özetler:
“Do” fikri, bir değişkenin değer almasının olağan nedenlerini kırdığınızın zihinsel bir notudur. Müdahale ettiğinizde bildirimler, ilgili kullanıcıların seçimi yüzünden değil sizin ayarlamanızla açık olur; amaç budur: müdahaleler nedenselliği izole etmeye yardımcı olur.
Çoğu ürün işi birer müdahaledir:
Bu eylemler sonuçları değiştirmeyi hedefler; sadece tanımlamayı değil. Nedensel düşünme soruyu dürüst tutar: “Bunu yaparsak neyi değiştirir?”
Bir müdahaleyi yorumlamak (veya iyi bir deney tasarlamak) için hangi şeylerin neyi etkilediğine dair varsayımlar—yani nedensel diyagram—gereklidir. Örneğin, mevsimsellik hem pazarlama harcamasını hem de kayıtları etkiliyorsa, mevsimselliği hesaba katmadan bir harcama değişikliği yapmak yine yanıltıcı olabilir. Müdahaleler güçlüdür ama alttaki nedensel hikâye en azından kabaca doğru olduğunda nedensel sorulara yanıt verir.
Karşıt durum, belirli bir tür “ya olsaydı?” sorusudur: bu tam vaka için, farklı bir eylem yapsaydık ne olurdu? Bu "ortalama ne olur" değil—"bu kişi, bu bilet, bu işlem için ne olurdu?"
Karşıt durumlar şu durumlarda çıkar:
Bu sorular kullanıcı düzeyindedir ve ürün değişiklikleri, politikalar ve açıklamalar için yol gösterir.
Bir kredi modeli başvuru reddederse, korelasyona dayalı açıklama “Düşük tasarruf reddedilme ile korelasyonlu” diyebilir. Bir karşıt durum şöyle sorar:
Eğer başvuranın tasarrufları 3.000$ daha fazla olsaydı (başka her şey aynı kalsaydı), model onaylar mıydı?
Cevap “evet” ise eyleme geçirilebilir bir bilgi elde etmiş olursunuz: kararı tersine çevirecek makul bir değişiklik. Cevap “hayır” ise yanlış bir tavsiye vermekten kaçınırsınız; gerçek engel borç/gelir oranı veya istikrarsız istihdam olabilir.
Karşıt durumlar bir nedensel modele dayanır—değişkenlerin nasıl etkileştiğine dair bir hikâye—sadece veri setine değil. Ne değiştirmenin mümkün olduğunu, bunun neleri sonuçlandıracağını ve nelerin sabit kalacağını belirlemelisiniz. Nedensel yapı olmadan karşıt durumlar imkansız senaryolar üretebilir ve yanıltıcı öneriler doğurabilir.
Bir ML modeli üretimde başarısız olduğunda kök nedeni nadiren “algoritma bozuldu” olur. Çoğunlukla sistemde neler değişti: toplanan veriler, etiket üretimi veya kullanıcı davranışları. Nedensel düşünme, tahminde bulunmayı bırakıp hangi değişikliğin neden bozduğunu izole etmeye yardımcı olur.
Bazı tekrar eden sorunlar:
Toplam panolarda korelasyon yüksek kalabildiği için bu durumlar “iyi” görünebilir; ama modelin doğru olma nedeni değişmiştir.
Basit bir DAG, hata ayıklamayı bir haritaya çevirir. Bu, şunu sormanızı sağlar: bu özellik etiketin bir nedeni mi, sonucu mu yoksa ölçüm şeklinin bir sonucu mu?
Örneğin, Etiketleme politikası → Özellik mühendisliği → Model girdileri ise boru hattınızı modelin altında yatan olgu yerine politikayı tahmin edecek şekilde kurmuş olabilirsiniz. Bir DAG bu yolu görünür kılar; böylece özelliği kaldırmak, enstrümantasyonu değiştirmek veya etiketi yeniden tanımlamak gibi yollarla bu yolu kapatabilirsiniz.
Sadece tahminleri incelemek yerine kontrollü müdahaleler deneyin:
Birçok “açıklanabilirlik” aracı dar bir soruyu yanıtlar: Model bu skoru neden verdi? Genellikle bunu etkili girdileri vurgulayarak yaparlar (özellik önemi, saliency haritaları, SHAP değerleri). Bu faydalı olabilir—ama modelin içinde bulunduğu sistemi açıklamaz.
Bir tahmin açıklaması yerel ve betimleyicidir: “Bu kredi reddedildi çünkü gelir düşüktü ve kullanım yükü yüksekti.”
Bir sistem açıklaması ise nedenseldir ve operasyoneldir: “Doğrulanmış geliri (veya kullanımı) gerçek bir müdahale ile artırırsak, karar değişir mi ve sonuçlar düzelir mi?”
İlki modeli yorumlamaya yardımcı olur. İkincisi ne yapmanız gerektiğini söyler.
Nedensel düşünme açıklamaları müdahalelerle ilişkilendirir. Hangi değişkenlerin korelasyon gösterdiğini sormak yerine, hangi değişkenlerin gerçek kollar olduğunu ve bunların değiştirildiğinde hangi etkileri üreteceğini sorarsınız.
Bir nedensel model sizi şunları açıkça yapmaya zorlar:
Bu önemlidir çünkü “önemli bir özellik” tahmin için faydalı ama eylem için tehlikeli bir vekil olabilir.
Sonradan yapılan açıklamalar ikna edici görünebilir ama tamamen korelasyonel kalabilir. Eğer “destek talepleri sayısı” churn'i güçlü şekilde tahmin ediyorsa, bir özellik önem grafiği ekibi destek erişimini zorlaştırmaya ve böylece ticket sayısını azaltmaya teşvik edebilir. Bu tür bir müdahale churn'i artırabilir, çünkü ticket'ler ürün sorunlarının semptomudur—neden değil.
Korelasyona dayalı açıklamalar ayrıca dağılım kaydığında kırılgandır: kullanıcı davranışı değişince aynı vurgulanan özelliklerin anlamı da değişebilir.
Kararlar sonuç ve hesap verebilirlik gerektirdiğinde nedensel açıklamalar özellikle değerlidir:
Harekete geçmeniz gerektiğinde, açıklama bir nedensel omurgaya ihtiyaç duyar.
A/B testi en basit ve en pratik haliyle nedensel çıkarımdır. Kullanıcıları rastgele A veya B'ye atadığınızda bir müdahale yapmış olursunuz: insanların seçtiği şeyi gözlemlemek yerine onlara ne gösterildiğini ayarlarsınız. Pearl’in terimleriyle, rastgeleleştirme “do(variant = B)”’yi gerçeğe dönüştürür—bu yüzden sonuç farkları değişikliğe bağlanabilir.
Rastgele atama, gizli kullanıcı özellikleri ile maruziyet arasındaki birçok bağlantıyı kırar. Güç kullanıcılar, yeni kullanıcılar, günün saati, cihaz türü—bu faktörler hâlâ vardır ama gruplar arasında (ortalama olarak) dengelenir. Bu denge, bir metrik farkını nedensel bir iddiaya dönüştürür.
Temiz rastgele testler her zaman mümkün değildir:
Bu durumlarda yine de nedensel düşünebilirsiniz—ancak varsayımlarınızı ve belirsizliği açıkça belirtmelisiniz.
Yaygın seçenekler arasında difference-in-differences (zaman içinde grup farklarını karşılaştırma), regression discontinuity (bir eşik kuralı kullanma), instrumental variables (maruziyeti doğrudan değiştiren ama sonucu doğrudan etkilemeyen doğal bir dürtü) ve matching/weighting (grupları daha karşılaştırılabilir kılma) vardır. Her yöntem rastgeleleştirmeyi varsayımlarla değiştirir; bir nedensel diyagram bu varsayımları netleştirmenize yardımcı olur.
Bir testi (veya gözlemsel çalışmayı) başlatmadan önce birincil metriği, korumaları, hedef popülasyonu, süresini ve karar kuralını yazın. Ön kayıt yanlılığı ortadan kaldırmaz ama metrik avcılığını azaltır ve nedensel iddiaları daha güvenilir—ve ekip içinde tartışılması daha kolay—hale getirir.
Çoğu ürün tartışması şöyle duyar: “Y metrik Y değişti, Y çalıştı.” Nedensel düşünme bunu netleştirir: “Y değişikliğinin X'i hareket ettirmesine sebep oldu mu ve ne kadar?” Bu kayma panoları kanıt olmaktan çok başlangıç noktası yapar.
Fiyat değişikliği: “Fiyatı %10 artırmanın mevsimselliği sabit tutarak ücretli dönüşüm, churn ve destek talepleri üzerindeki etkisi nedir?”
Onboarding ayarı: “Onboarding'i 6 adımdan 4 adıma kısaltırsak, yeni kullanıcıların aktivasyonu ve 4. haftadaki tutunması ne olur?”
Öneri sıralama değişikliği: “Tazeliği öne çıkarırsak uzun vadeli memnuniyet (geri dönüşler, gizlemeler, abonelik iptalleri) üzerinde etkisi ne olur, sadece tıklara bakmayalım?”
Panolar genellikle “değişikliği kim aldı” ile “zaten iyi performans gösterecek olan kim”i karıştırır. Klasik örnek: yeni onboarding akışını yayınladınız ama ilk önce yeni uygulama sürümünü kullananlara gösterildi. Yeni sürümleri benimseyenler daha ilgili olabilir; grafik yükselişinin bir kısmı (veya tamamı) onboarding değil sürüm benimsemesi yüzünden olabilir.
Diğer sık karıştırıcılar:
Yararlı bir PRD bölümü gerçekten “Nedensel Sorular” başlıklı olabilir ve şunları içerebilir:
Hızlı geliştirme döngüsü kullanıyorsanız (özellikle LLM destekli gelişimle), bu bölüm daha da önem kazanır: “hızlı yayınlayabiliriz”un “ne yaptığımızın etkisini bilmeden yayınladık”a dönüşmesini engeller. Koder.ai'da inşa eden ekipler genellikle bu nedensel soruları planlama moduna baştan entegre eder, ardından hızlıca feature-flag'li varyantlar uygular, snapshot/rollback ile sonuçlar şaşırttığında güvenli geri dönüş sağlar.
PM karar ve başarı kriterlerini tanımlar. Veri ortakları bunu ölçülebilir nedensel tahminlere ve kontrolleri çevirir. Mühendislik değişikliğin kontrol edilebilir olmasını sağlar (feature flagler, temiz maruziyet loglama). Destek nitel sinyaller paylaşır—fiyat değişiklikleri genellikle “çalışıyor” gibi görünür ama sessizce iptalleri veya ticket hacmini artırabilir. Herkes nedensel soru üzerinde anlaştığında, gönderme öğrenme olur—sadece gönderme değil.
Nedensel düşünme doktora seviyesinde bir uygulama gerektirmez. Bunu bir ekip alışkanlığı olarak görün: nedensel hikâyenizi yazın, test edin, sonra veri (ve mümkünse deneyler) ile doğrulayın veya düzeltin.
İlerlemek için önden dört girdi toplayın:
Pratikte hız önemlidir: bir nedensel soruyu kontrollü bir değişikliğe çevirme hızınız ne kadar yüksekse, belirsiz desenler üzerinde tartışmak için harcadığınız zaman o kadar az olur. Bu yüzden ekipler Koder.ai gibi platformları kullanarak “hipotez + plan”dan çalışan, enstrümante edilmiş bir uygulamaya (web, backend veya mobil) günler içinde geçebiliyor—aynı zamanda kademeli açılışlar, dağıtımlar ve rollback ile titizliği koruyorlar.
Eğer deneyler konusunda bir tazeleme isterseniz, /blog/ab-testing-basics'e bakın. Ürün metriklerinde “etkiyi taklit eden” yaygın tuzaklar için /blog/metrics-that-mislead'e bakın.
Nedensel düşünme, “ne birlikte hareket etme eğiliminde?” sorusundan “hareket edersek ne değişir?” sorusuna kayıştır. Bu kayma—Judea Pearl tarafından bilgisayar bilimi ve istatistikte popüler hale getirildi—ekiplerin gerçek dünyada müdahalelerle hayatta kalmayan kendinden emin hikâyelerden kaçınmasına yardımcı olur.
Korelasyon bir ipucudur, cevap değildir.
Nedensel diyagramlar (DAG'lar) varsayımları görünür ve tartışılabilir kılar.
Müdahaleler (“do”) gözlemlerden (“see”) farklıdır.
Karşıt durumlar tek vakaları açıklamaya yardımcı olur: “bu bir şey farklı olsaydı ne olurdu?”
İyi nedensel çalışma belirsizliği ve alternatif açıklamaları belgelemelidir.
Nedensellik dikkat ister: gizli karıştırıcılar, ölçüm hataları ve seçim etkileri sonuçları ters çevirebilir. Çözüm şeffaflıktır—varsayımları yazın, kullandığınız veriyi gösterin ve iddianızı çürütecek neyin olacağını not edin.
Daha derine inmek isterseniz /blog'daki ilgili yazılara göz atın ve nedensel yaklaşımları diğer analitik ve “açıklanabilirlik” yöntemleriyle karşılaştırarak her birinin nerede yardımcı olduğunu ve nerede yanıltıcı olabileceğini görün.
Korelasyon size tahmin veya tespit yapmada yardımcı olur (ör. “X yükseldiğinde Y genellikle yükselir”). Nedensellik ise bir karar sorusunu yanıtlar: “Eğer X'i kasıtlı olarak değiştirirsek, Y değişir mi?”
Korelasyonu tahminleme ve izleme için, nedensel düşünmeyi ise bir değişiklik göndereceğiniz, politika belirleyeceğiniz veya bütçe ayıracağınız zaman kullanın.
Çünkü korelasyon karıştırıcı tarafından yönlendiriliyor olabilir. Bildirim örneğinde, çok ilgili kullanıcılar hem daha fazla bildirim tetikler/asıldır hem de daha sık geri döner.
Herkese daha fazla bildirim gönderirseniz, deneyimi (bir müdahale) değiştirirsiniz ama temel etkileşimi değiştirmezsiniz—bu yüzden tutunma artmayabilir, hatta kötüleşebilir.
Bir DAG (Yönlendirilmiş Döngüsüz Grafik), şöyle bir diyagramdır:
Takımın neden hangi değişkenleri kontrol edeceği, hangilerini kontrol etmemesi gerektiği ve hangi deneyin soruyu gerçekten yanıtlayacağı konusunda varsayımları açık hale getirir.
Yaygın hata “her şeye kontrol et” refleksidir; bu, yanlışlıkla ara değişkenleri veya çarpışıcıları kontrol ederek sonuçları yanlılaştırabilir.
“See” doğal olarak olanı gözlemlemektir (kullanıcılar tercih etti). “Do” ise bir değişkeni aktif olarak ayarlamaktır (özelliği yayınlamak, varsayılanı değiştirmek).
Önemli fikir: bir müdahale bir değişkenin alacağı değerin olağan sebeplerini kırar, bu yüzden gözlemlerden daha güvenilir şekilde nedensellik açığa çıkabilir.
Karşıt durum (counterfactual) sorar: bu özel vaka için, başka bir şey yapsaydık ne olurdu?
Kullanım alanları:
Olur, ancak bunun için bir nedensel modele ihtiyacınız vardır; aksi halde imkânsız senaryolar üretebilirsiniz.
Üretimde bir ML modeli başarısız olduğunda, sorun nadiren “algoritma bozuldu” olur. Genellikle sistemin bir yerinde veri, etiketleme ya da kullanıcı davranışı değişmiştir.
Nedensel düşünme sizi tahmin etmeyi bırakıp hangi değişikliğin bozulmaya neden olduğunu izole etmeye iter:
Hedefli müdahaleler (ablasyonlar, perturbasyonlar) deneyin; tesadüfi metrik hareketlerini kovalamayın.
Açıklanabilirlik araçları genellikle dar bir soruyu cevaplar: “Model bu skoru neden verdi?” Önemli olabilir—ama modelin oturduğu sistemi açıklamaz.
Bir tahmin açıklaması yereldir ve betimleyicidir. Nedensel bir açıklama ise operasyoneldir: “Doğrulanmış geliri artırırsak (ve bunu gerçek bir müdahaleyle yaparsak) karar değişir mi ve sonuçlar düzelir mi?”
Önemli olan, hangi değişkenlerin gerçekten müdahale edilebilir kaldığını ve hangi özelliklerin sadece proxy (tahmin için yararlı, eylem için tehlikeli) olduğunu açıkça göstermektir.
Rastgele atanmış A/B testleri mümkün olduğunda en güçlü yöntemdir: rastgelelik “do(variant = B)”’yi gerçek kılar ve grup farklarını değişikliğe bağlamayı güvenilir hale getirir.
Ancak her zaman rastgele test yapamazsınız:
Böyle durumlarda difference-in-differences, regression discontinuity, instrumental variables veya matching/weighting gibi yarı-deneysel yöntemlere başvurun—ancak varsayımları açıkça belirtin.
PRD'lere kısa bir bölüm ekleyin; bu analiz öncesi netlik sağlar:
Bu, ekibi bir nedensel soruda hizalar ve sonradan dashboard hikâyesi anlatmayı engeller.
