Keşif Ne İçindir? Cevabı Makine Bulursa, Soruyu Kim Öğrenir?

Mike Walsh geçen hafta LinkedIn'de kısa ama rahatsız edici bir soru sordu: Keşif ne içindir?

Yazının arka planı matematik dünyasındaki bir tartışma. Walsh'un aktardığına göre OpenAI, Navier-Stokes denklemleriyle ilgili Milenyum Problemi'ni yaklaşık 10.000 yapay zekâ ajanını elli saatten fazla çalıştırarak çözdüğünü açıkladı. Terence Tao ve 25 Fields Madalyası sahibi ise buna "ciddi bir uyumsuzluk" diye itiraz etti. İtirazları cevabın doğruluğuna değil, bir şeyin eksik kalmasınaydı: Bir problemi insanlar çözdüğünde yalnızca cevap çıkmaz, öğretilebilir fikirler de çıkar. Makine cevabı verip geçtiğinde o fikirler hiç doğmayabilir.

Walsh bunu Poincaré'nin eski bir gözlemine bağlıyor: Bizden üstün bir zihin olsa bile onu kullanamayız, yalnızca kendi zihnimizi kullanabiliriz. Yüz yıl boyunca doğru olan bu cümle artık doğru değil. Üstün zihni kullanabiliyoruz. Bu yüzden anlamak kendiliğinden olan bir şey olmaktan çıktı; artık bir tercih.

Bu yazıyı okurken matematik aklıma gelmedi. Aklıma ERP projeleri geldi.

Sahada keşfin adı "analiz"dir

1996'dan bu yana ERP ve üretim projelerinde çalışıyorum. Bu sürede şunu defalarca gördüm: Bir ERP projesini en pahalıya mal eden hata, yanlış yazılmış kod değildir. Yanlış problemin doğru çözülmesidir.

Başarısız ERP projelerinin nedenlerini sıraladığımda en pahalısı hep aynıdır: ihtiyaçların ve amaçların yanlış tespit edilmesi. Süreç danışmanlığında "yazılım almadan önce süreci anlamak gerekir" dememizin sebebi bu. Analiz aşaması, bir projenin keşif aşamasıdır. Çıktısı bir doküman gibi görünür ama asıl çıktısı, müşterinin ve danışmanın kafasında oluşan ortak anlayıştır.

İyi bir analiz toplantısında kimse cevabı bilmez. Planlamacı stok neden şişiyor bilmez, satış neden teslim tarihi tutmuyor bilmez, finans maliyetin neden sapıyor bilmez. Soru sora sora, bir Ishikawa diyagramının kılçıklarını doldura doldura, "beş neden"in beşincisine vara vara bir yere gelinir. O yolculuğun sonunda odadaki herkes işini biraz daha iyi anlamış olur. Proje ondan sonra yürür.

Şimdi bu yolculuğu kısaltan bir makinemiz var.

Makine cevabı veriyor; soru hâlâ bizde

Kai'yi geliştirirken bunu her gün yaşıyorum. Kullanıcı "bu ay en çok satan on ürün hangisi?" diye yazıyor, Kai SQL'i üretiyor, sonuç saniyeler içinde ekranda. Bir raporun hazırlanmasını haftalarca bekleyen biri için bu gerçekten büyük bir kolaylık.

Ama asıl kıymetli soru ondan sonra geliyor: Bu listede geçen ay olan ürün neden yok? Bu soruyu makine sormuyor. Soran kişi ya satış kanalını biliyordur, ya bir müşterinin sipariş alışkanlığını, ya da geçen ay üretimde yaşanan bir duruşu. Cevap makineden gelebilir. Neyi soracağını bilmek, işi bilen insandan gelir.

Walsh'un yazısında gözümden kaçmayan bir ayrıntı var. O on bin ajanlık çalışmada bile hangi yola kaynak ayrılacağına insan araştırmacılar karar vermiş. Yani en büyük hesaplama gücünün başında bile bir muhakeme duruyor. Bu muhakemeyi besleyen şey de geçmişte bizzat çözülmüş problemler.

Scrum'da keşfin bir adı var: Spike

Çevik proje yönetimini anlattığım notta Spike'tan bahsetmiştim. Spike, belirsizliği azaltmak için ayrılmış, süresi sınırlı bir araştırmadır. En önemli özelliği şudur: Çıktısı çalışan bir yazılım değil, öğrenmedir. Ekip sprint sonunda "şunu denedik, şu yüzden olmuyor, şu yol daha doğru" diyebiliyorsa Spike başarılıdır.

Yapay zekâ Spike'ı kısaltabilir. Bir entegrasyonun nasıl yapılacağını, bir API'nin nasıl davrandığını saatler yerine dakikalarda gösterebilir. Tehlike şurada başlıyor: Spike kısalırken öğrenme de kısalıyorsa, kazandığımızı sandığımız zamanı aslında kaybediyoruz. Ekip bir sonraki benzer problemde yine sıfırdan başlıyor, çünkü ilkinde hiçbir şey öğrenmedi. Sadece cevabı kopyaladı.

DMAIC'te de aynı disiplin var. Ölç'ten önce Tanımla gelir; CTQ'yu belirlemeden veri toplamaya başlarsanız, doğru ölçtüğünüz yanlış bir şeyle baş başa kalırsınız. Makine ölçmeyi bizden iyi yapıyor. Neyin ölçülmeye değer olduğuna karar vermek hâlâ bizim işimiz.

KaiDraw'de "mühendis onaylar" dememizin sebebi

KaiDraw, SOLIDWORKS parçalarını analiz edip firmanın kendi standardına göre tanım ve sınıf öneriyor. Teknik olarak bu önerileri doğrudan PDM'e yazmak mümkün. Bunu bilerek yapmıyoruz. Öneri makineden gelir, onay mühendisten.

Bunun sebebi yalnızca hata riski değil. Mühendis her onayda, her düzeltmede kendi standardını biraz daha iyi tanıyor. Neyin "cıvata" neyin "saplama" olduğunu, hangi parçanın gerçekten yeni hangisinin eskinin kopyası olduğunu görüyor. Onayı kaldırırsak makine yine doğru cevap verir ama mühendis kendi ürün ağacına yabancılaşır. Beş yıl sonra o firmada standardı savunabilecek kimse kalmaz.

Walsh'un liderlere önerdiği tasarım sorusu tam olarak bu: İnsan ile makine arasındaki işbirliğini, muhakemeyi aşındıracak şekilde değil, geliştirecek şekilde kurmak.

Sahaya çevirince: beş alışkanlık

Walsh'un çerçevesini ERP projelerine ve üretim işletmelerine uyarlarsam, önereceğim alışkanlıklar şunlar:

1. Yapay zekâya sormadan önce hipotezini yaz. "Sanırım stok fazlası şu üç üründen kaynaklanıyor" diye bir satır yazmak bile yeterli. Cevap geldiğinde kendi tahmininle karşılaştır. Aradaki fark, senin öğrendiğin şeydir.
2. Makine ile insan ayrıştığında bunu hata değil, veri say. Kai bir rakam verdi, planlamacı "olamaz" dedi. Ya sorgu yanlıştır ya planlamacının zihnindeki model. İkisinden biri düzelecek; ikisi de değerli.
3. Yanlış problemi yakalayanı ödüllendir. Toplantıda "aslında sorun bu değil" diyen kişi, projeye en çok para kazandıran kişidir. Bunu görünür kılın.
4. Cevabı değil, gerekçesini sakla. Bir kararın neden alındığını yazmayan bir organizasyon, aynı keşfi her beş yılda bir yeniden yapar. Makine cevabı yeniden üretebilir; o günkü bağlamı üretemez.
5. Genç danışmanlara "nasıl"ı değil, "neden"i öğret. Nasıl yapılacağını artık makine de gösterebiliyor. Neden öyle yapıldığını bilen danışman, makinenin önerisini değerlendirebilen tek kişidir.

Rönesansı ıskalayanlar

Bir süre önce "Rönesansı ıskalayanlar, İnsan 2.0'ı da ıskalıyor" diye yazmıştım. Orada tehlikeyi teknolojiye ayak uyduramamak olarak görüyordum. Walsh'un yazısı bana bu tehlikenin bir de öteki yüzü olduğunu hatırlattı: Teknolojiye tam ayak uydurup düşünmeyi ona devretmek.

Rönesans'ı Rönesans yapan, cevapların çoğalması değildi. İnsanların sorabildiği soruların çoğalmasıydı. Yapay zekâ bize eşi görülmemiş bir cevap bolluğu getiriyor. Bu bolluğun bir sonraki Rönesans'a mı, yoksa konforlu bir unutuşa mı dönüşeceği, cevapları nasıl kullandığımıza bağlı.

Kendi işimde ölçütüm basit: Bir sistemi devreye aldıktan sonra müşterinin ekibi, işini devreye almadan önceki hâlinden daha iyi anlıyorsa proje başarılıdır. Sadece daha hızlı yapıyorsa, yarı yoldayız.

Keşif ne içindir? Bence cevabı bulmak için değil, bir sonraki soruyu sorabilecek insanı yetiştirmek için.

Siz ekibinizde bu dengeyi nasıl kuruyorsunuz? Yapay zekâ geldikten sonra ekibiniz işini daha iyi mi anlıyor, yoksa sadece daha hızlı mı yapıyor?

Bu yazı, Mike Walsh'un What Is Discovery For? başlıklı yazısından yola çıkıyor.