Bir Ürüne Yapay Zekâ Eklemek Gerçekten Gerekli mi?

Son birkaç yılda çoğu ürün ekibine aynı soru soruldu: biz nerede yapay zekâ kullanabiliriz?

Soru, kendi içinde bir sıra hatası taşır. Bir çözümle başlayıp ona uygun bir problem aramak, ürün geliştirmede nadiren iyi sonuç verir. Aynı yaklaşım daha önce mobil uygulamalar, sohbet arayüzleri ve blok zinciri için de denendi; sonuçların çoğu, kullanılmayan özellikler oldu.

Daha yararlı sıra terstir: elinizde hangi problem var ve o problem ne tür bir cevap gerektiriyor?

Problem hangi tür cevabı gerektiriyor?

Ürün problemleri kabaca ikiye ayrılır ve ayrım teknolojiden önce gelir.

Bir kısmının tek bir doğru cevabı vardır ve bu cevap hesaplanabilir. Bir faturanın toplamı, bir kullanıcının yetkisi olup olmadığı, bir stok seviyesinin eşiğin altına düşüp düşmediği. Bunlar kural işidir. Buraya bir dil modeli koymak, yalnızca kesin olanı olasılıklı hâle getirir.

Diğer kısmı ise yargı gerektirir ve girdi düzensizdir: serbest metinden niyet çıkarmak, uzun bir belgeyi özetlemek, benzer kayıtları eşleştirmek, bir talebi doğru ekibe yönlendirmek. Burada tek bir "doğru" yoktur; kabul edilebilir bir aralık vardır.

Bu ayrımı yapmadan yürütülen tartışmalar genellikle çözümsüz kalır, çünkü taraflar farklı türde problemlerden bahsetmektedir.

Belirleyici eksen: yanlış olma toleransı

Yargı gerektiren bir problem bile her zaman yapay zekâya uygun değildir. Asıl belirleyici, sonucun yanlış olması hâlinde ne olduğudur.

Bazı işlerde yanlış cevap ucuzdur. Bir öneri listesi isabetsizse kullanıcı görmezden gelir; bir özet eksikse kaynağa döner. Maliyet küçük ve geri alınabilirdir.

Bazı işlerde ise yanlış cevap pahalıdır: bir ödeme yönlendirmesi, bir sözleşme maddesinin yorumu, bir tıbbi veya hukuki bilginin sunumu, bir kullanıcının erişim yetkisinin belirlenmesi. Burada "çoğu zaman doğru" yeterli bir ölçüt değildir.

Bu eksen tek başına kararı büyük ölçüde verir. Yanlışın ucuz olduğu yerde olasılıklı bir çözüm rahatlıkla kullanılabilir. Yanlışın pahalı olduğu yerde ya deterministik bir yol seçilir ya da sonucun insan denetiminden geçmesi tasarımın parçası hâline gelir.

Deterministik çözümün daha iyi olduğu durumlar

Bir modelin yapabildiği bir işi, daha basit bir yöntem de yapabiliyorsa basit olan neredeyse her zaman doğrudur.

Bunun en yaygın örneği aramadır. Ürünlerde "yapay zekâ destekli arama" olarak konumlanan özelliklerin bir kısmı, aslında iyi kurulmuş bir filtreleme ve sıralama ile daha hızlı, daha ucuz ve daha öngörülebilir biçimde çözülebilir. Kullanıcı çoğu zaman akıllı bir cevap değil, doğru filtreyi aramaktadır.

İkinci örnek sınıflandırmadır. Kategori sayısı azsa ve kurallar açıksa, bir kural kümesi hem daha doğru hem de açıklanabilir çalışır. Kural yazılamayacak kadar bulanık bir alan varsa, model orada anlam kazanır.

Üçüncüsü üretimdir. Şablonla üretilebilecek bir metni modele yazdırmak, tutarlılığı azaltır ve maliyeti artırır. Metnin gerçekten değişken ve bağlama duyarlı olması gerekiyorsa durum değişir.

Görünmeyen üç maliyet

Yapay zekâ özelliklerinin maliyeti genellikle geliştirme süresiyle ölçülür. Asıl kalemler başka yerdedir.

Veri. Model tabanlı bir özellik, çalışması için bağlama ihtiyaç duyar. Bu bağlam ürününüzde yoksa — dağınıksa, eksikse veya erişilemiyorsa — özelliğin kalitesi baştan sınırlanır. Çoğu projede asıl iş modeli bağlamak değil, veriyi kullanılabilir hâle getirmektir.

Gecikme. Bir modelin cevabı, bir veritabanı sorgusundan belirgin biçimde yavaştır. Kullanıcının beklediği yer bir arama kutusuysa bu fark deneyimi doğrudan etkiler. Bu, performansın algılanan kaliteyi nasıl etkilediğiyle aynı konudur; yalnızca kaynağı farklıdır.

Değişkenlik. Aynı girdi her zaman aynı çıktıyı vermeyebilir. Bu, test etmeyi, hata ayıklamayı ve destek vermeyi zorlaştırır. "Bende çalışmıştı" cümlesi burada teknik bir gerçeğe dönüşür.

"Yeterince doğru" ne demek?

Yapay zekâ tartışmalarının çoğu, doğruluk hedefi konuşulmadan yürür. Bu, projenin sonunda kimsenin başarıyı ilan edememesine yol açar.

Hedefi belirlemenin en pratik yolu, mevcut durumla karşılaştırmaktır. Bugün bu iş elle yapılıyorsa, elle yapılırken ne kadar hata oluyor? Çoğu şirkette bu sayı bilinmez ve varsayılan olarak sıfır sanılır. Oysa yorgun bir insanın binlerce kaydı sınıflandırırken yaptığı hatalar da vardır; yalnızca ölçülmemiştir.

Karşılaştırma yapılmadığında model, kusursuzluk beklentisiyle sınanır ve her zaman kaybeder. Karşılaştırma yapıldığında soru daha dürüst hâle gelir: bu özellik, bugünkü sürecin ürettiği sonuçtan daha iyi mi, ve hata biçimi daha yönetilebilir mi?

İkinci nokta, hata türlerinin eşit olmamasıdır. Bir sınıflandırmada yanlış pozitif ile yanlış negatifin maliyeti genellikle farklıdır. Bir talebi yanlışlıkla acil işaretlemek ile acil bir talebi kaçırmak aynı şey değildir. Hedef tek bir yüzdeyle değil, hangi hatanın kabul edilebilir olduğu belirtilerek konmalıdır.

Üçüncüsü, doğruluğun bir kez ölçülüp bırakılmamasıdır. Gerçek kullanımdan gelen örneklerle küçük bir değerlendirme kümesi oluşturmak, sürüm değiştiğinde bir şeyin bozulup bozulmadığını görmenin tek pratik yoludur.

Maliyet bir kez değil, her kullanımda

Geleneksel özelliklerde maliyet ağırlıklı olarak geliştirme aşamasındadır; yayına alındıktan sonra çalıştırmak nispeten ucuzdur.

Model tabanlı özelliklerde bu ilişki değişir. Her çağrı bir bedel üretir ve bu bedel kullanımla birlikte büyür. Ürün başarılı olursa maliyet de büyür — ki bu, alışık olunan eğrinin tersidir.

Bunun pratik sonucu, özelliğin nerede ve ne sıklıkta çağrıldığının bir tasarım kararı hâline gelmesidir. Her tuş vuruşunda çalışan bir özellik ile yalnızca kullanıcı istediğinde çalışan bir özellik arasında işlev farkı küçük, maliyet farkı büyük olabilir.

Aynı soru önbellekleme için de geçerlidir: benzer girdiler için aynı işi tekrar tekrar yapmak gerekiyor mu?

Bu kalemin bütçelenmesi de farklıdır. Sabit bir geliştirme maliyeti onaylatmak kolaydır; kullanımla büyüyen bir işletme gideri, üst sınırı baştan konuşulmadığında sürpriz üretir.

Değer nerede oluşuyor?

Son ve genellikle en ayırt edici soru şudur: yapay zekâ, ürününüzün değerinin kendisi mi, yoksa değeri sunma biçimi mi?

Değerin kendisi olduğu ürünlerde model kalitesi rekabetin merkezindedir ve buna yatırım yapmak doğrudur.

Bu ayrım, nasıl inşa edileceğini de belirler. Değer modelin kendisindeyse, üzerinde çalışılan şey model olur. Değer sunumdaysa, hazır bir servis kullanmak neredeyse her zaman doğrudur — çünkü rekabet o katmanda değildir ve kendi modelini eğitmek, çözdüğünden çok daha fazla bakım yükü getirir.

Çoğu üründe ise durum böyle değildir. Yapay zekâ, mevcut bir işi biraz daha az sürtünmeli hâle getiren bir katmandır. Bu meşru ve değerlidir — ancak ürünün temel işi hâlâ iyi çalışmıyorsa, üzerine eklenen akıllı katman bunu telafi etmez. Bir MVP kapsamında olduğu gibi, temel akış tamamlanmadan eklenen özellik ölçümü de bozar: kullanıcı ürünü mü beğenmedi, özelliği mi?

Sonuç

Yapay zekâyı kullanmamak bir gerileme değildir; birçok problem için doğru mühendislik kararıdır. Aynı şekilde, uygun bir problemde kullanmamak da gereksiz bir inatçılıktır.

Ayrımı yapan şey teknolojiye dair bir görüş değil, problemin şeklidir: cevabın kesin olması gerekiyor mu, yanlış olmanın bedeli nedir, ve daha basit bir yol var mı?

Yapay zekâ entegrasyonu çalışmalarımızda konuşmayı genellikle modelle değil bu üç soruyla açıyoruz — çünkü cevapları, projenin geri kalanının ne kadar karmaşık olacağını da belirliyor.