Bir yapay zeka değerlendirmesi, genellikle insanların daha sonra o skora yüklediği anlamdan daha dar bir soruyu yanıtlar. Bir müşteri destek asistanı için soru çoğu zaman basittir: Yanıt, beklenen cevapla eşleşti mi? Operasyonel soru ise daha karmaşıktır. Müşteri problemini çözebildi mi? Öfkeli bir şekilde geri döndü mü? Bu yanıt daha sonra insan ekibe ek iş çıkardı mı?
Bunlar farklı sorulardır. Destek asistanı sık karşılaşılan parola sıfırlama sorularını iyi yanıtlayabilir, ama en çok uzman müdahalesi gerektiren karmaşık hesap problemlerinde başarısız olabilir. Değerlendirme bu iki hatayı aynı sayıyorsa aslında bunu açıkça söylemeden bir ürün kararı vermiştir.
Doğru bir değerlendirme bu şekilde yanıltıcı hâle gelir. Test, kendisine sorulan soruyu doğru yanıtlar. Sonra elde edilen skor üretime hazır olma, iş riski, müşteri etkisi veya operasyonel yük gibi çok daha geniş konularda kanıt olarak kullanılmaya başlanır.
Sorun ölçüm yapmak değildir. Sorun, her metriğin “iyi”yi kendi başına tanımladığını ve bu tanımın desteklemesi beklenen karardan çok daha dar olabileceğini unutmaktır.
Ölçmesi kolay olan, çoğu zaman önemli olan değildir
Her değerlendirme, ekibin asıl yanıtlaması gereken sorudan daha kolay bir soruyu yanıtlar. Bu, ekibin özensiz davrandığı anlamına gelmez. Ucuz soru yerel ve anlıktır: Bu örnekteki çıktı, referans yanıtla eşleşti mi? Zor soru ise daha sonra ortaya çıkar: Bu yanıt problemi çözdü mü, müşteriyi kaybetmeye yaklaştırdı mı, hatalar en fazla zarar verecek vakalarda mı yoğunlaştı?
Bu sorular aynı şeyi ölçmez. Ekip aynı değerlendirmeyi daha dikkatli çalıştırdığında aradaki fark kapanmaz. Fark, biri bu soruların birbirinin yerine kullanıldığını fark ettiğinde ve testin ne iddia edebileceğine sınır koyduğunda kapanır.
Destek asistanı örneğinde de olan budur. Yüzde 98 uydurma bir sonuç değildi. Yanlış soruya verilen dürüst bir yanıttı.
Neyi ölçeceğinize karar vermek, “iyi”nin ne olduğunu belirlemektir
Metrik, sistemi tarafsızca ölçen bir araç değildir. Başarının ne sayılacağını önceden sabitleyen bir tanımdır. O anda bir tercih gibi görünmese bile bu tanımı birileri seçmiştir.
“Yüzde 98 doğruluk” model hakkında nesnel bir gerçek gibi görünür. Ancak daha önce verilmiş bir karara dayanır: Değerlendirme veri kümesindeki her destek vakası eşit sayılır ve hangi iki vakanın yanlış yanıtlandığından bağımsız olarak yüz vakanın doksan sekizini doğru yanıtlamak “iyi” kabul edilir. Kimse oturup “kafası karışmış kurumsal bir müşteriyi yanlış yönlendirmekle rutin bir sık sorulan soruya biraz özensiz cevap vermeyi aynı sayıyoruz” dememiştir. Yine de değerlendirme her vakayı birbirinin yerine geçebilir kabul ederek bu takası yapmıştır.
Herhangi bir skor hesaplamadan önce “bir hata bize neye mal olur ve bu maliyet vakaya göre değişir mi?” diye soran ekip, farklı bir değerlendirme kurar. Aynı değerlendirmenin daha düzenli bir sürümünü değil, gerçekten farklı bir değerlendirmeyi.
Neyi ölçtüğünüz, neyin iyi görüneceğini belirler
Bir müşteri faturadaki mükerrer tahsilatı soruyor. Asistan standart iade politikası yanıtını veriyor ama mükerrer tahsilatı hiç ele almıyor. Aynı yanıtı iki farklı biçimde değerlendirebilirsiniz.
Ölçtükleri şey
Yanıt, onaylanmış cevapla eşleşti mi?
İfadeler iade politikası şablonuyla eşleştiği için yanıt testi geçer. Doğru görünür. Ama değerlendirme yalnızca kullanılan ifadeleri kontrol eder. Müşterinin gerçek probleminin çözülüp çözülmediğini sormadığı için aradaki fark görünmez kalır.
Önemli olan
Müşteri gerçekten problemini çözebildi mi?
Müşteri talebi yeniden açtı. Kurumsal hesapta çözülememiş bir fatura itirazı var. Yanıt, mükerrer tahsilatın nasıl geri alınacağını hiç açıklamadı. Problem çözülmedi. Rutin bir sık sorulan soruda bu unutulup gidebilirdi, ancak hesabında çözülememiş bir tahsilat bulunan yüksek değerli müşteri bambaşka bir vakadır.
Sistemi kuranların kör noktası
Bu ayrımın gözden kaçmasının bir nedeni daha vardır. Neyin “iyi” sayılacağına karar veren kişiler sistemi de kurduysa değerlendirme, sistemi sınamak yerine alınmış kararları doğrulamaya başlayabilir.
Bu dürüstlük sorunu değildir. Daha çok bir kör noktadır. İçerik moderasyonu için sınıflandırıcı geliştiren bir ekip, yüzlerce küçük uygulama kararı boyunca bir “hata”nın nasıl göründüğüne dair çalışma alışkanlığı edinir. Bu anlayış zamanla daralıp sistemin zaten iyi yönettiği vakalarla örtüşebilir. Kimse hatayı özellikle dar tanımlamaya çalışmaz. Ekip yalnızca aylar boyunca sisteme, sistemin kendilerine öğrettiği alışkanlıklarla bakar.
Sistemin geliştirildiği odada hiç bulunmamış birinin tasarladığı değerlendirme genellikle farklı bir soru sorar. Her zaman daha akıllıca bir soru değildir. Yalnızca daha az tanıdıktır. Bazen sistemin ihtiyaç duyduğu şey de tam olarak budur.
Aynı skor, farklı bakışlar
Geliştirici, inceleyen kişi ve istatistikçi aynı yüzde 98 etiket eşleşmesine bakıyor. Her biri farklı bir şey görüyor.
Ayrı tutulan değerlendirme seti
98%
etiket eşleşmesi
İnceleyenin bakışı
Hangi hatalar aynı nedene dayanıyor ve bunlardan herhangi biri pahalı mı?
Skor neyin yayınlanacağına karar vermek için kullanılmadan önce hataların dağılımına bakıyor.
Değerlendirme tasarlamak, deney tasarlamaktır
Geçerli bir değerlendirme tasarlamak, test paketi yazmaktan çok deney tasarlamaya benzer. Birçok mühendislik ekibi bunun için eğitim almamıştır, çünkü bu yalnızca bir mühendislik becerisi değildir.
Gerçek bir deney, sonucun anlamlı olabilmesi için nelerin doğru olması gerektiğini belirleyerek başlar. Hangi değişkenler sabit tutulacak? Sınanan varsayımın aleyhinde ne kanıt sayılacak? Sonuç geldiğinde hangi iddiaları destekleyebilecek? Örnekleri bir araya getirip başarı oranı hesaplamak bir sayı üretir. Hesabın yapılmış olması o sayıyı anlamlı kılmaz.
Bu nedenle daha fazla test vakası eklemek çoğu zaman problemi çözmez. Daha fazla vaka aynı soruyu daha yüksek hassasiyetle yanıtlar, ama soruyu iyileştirmez. Destek ekibi on kat fazla konuşmayı değerlendirebilir ve aynı dolaylı ölçüt için daha dar bir güven aralığıyla yine yüzde 98 sonucuna ulaşabilirdi.
Bu hatayı önceden görmek deneyim ister
Bu örüntüyü geriye dönüp bakınca anlatmak kolay, önceden görmek zordur. Onu tanımak, daha önce benzerini görmüş olmayı gerektirir. İlk değerlendirmesini tasarlayan bir ekibin elindeki temel veri noktası kendi sistemidir. Bu yüzden her hata biçimini ilk kez üretimde, maliyet ortaya çıktıktan sonra keşfeder.
Bir müşteri destek sistemi “yanıt beklenen cevapla eşleşti mi?” ölçümünde iyi skor alır, ama müşterileri hayal kırıklığı içinde bir yetkiliye başvurmak zorunda bırakır. Bir içerik moderasyonu sınıflandırıcısı precision (kesinlik) hedefine ulaşır, ancak kimsenin test etmeyi düşünmediği bir zarar kategorisini gözden kaçırır. Bir potansiyel müşteri yönlendirme modeli, değerli sınır vakalarını rutin taleplerle aynı kuyruğa yollar. Tek bir şirketin içinde bunlar birbirinden bağımsız sorunlar gibi görünür. Yeterince örnek gördüğünüzde ise aynı birkaç hatanın farklı kılıklara girdiğini fark edersiniz.
Tek seferlik hata mı, sistematik sorun mu?
Olayın tekil bir test sorunu mu, tekrarlanan bir değerlendirme hatasının parçası mı olduğunu işaretleyin.
1 / 4
Olay
Bir destek sistemi beklenen yanıtla eşleşti. Müşteriler yanıta göre harekete geçemedikleri için yine de yeni destek talepleri açtı.
Bu işin gerektirdiği yetkinlik tek bir rolde toplanmıyor
Son birkaç noktayı bir araya getirdiğinizde ortaya kolay tanımlanamayan bir rol çıkar. İyi bir değerlendirme için istatistik, ürün muhakemesi ve alan riskinin aynı konuşmada buluşması gerekir. Çoğu kariyer yolu insanları bunlardan yalnızca birinde yetiştirir. Bir mühendis istatistiksel açıdan sağlam bir test kurmayı bilebilir, ama vakaların hangi yüzde ikisinin gözden kaçması hâlinde işin zarar göreceğini bilmeyebilir. Bir ürün yöneticisi hatanın maliyetini çok iyi anlayabilir, ama bunu sınanabilir bir ölçüte dönüştürmekte zorlanabilir. Ölçüm uzmanı güven aralıklarında güçlü olabilir, ancak ürünü ve alanı yeterince tanımayabilir.
Bir alanda güçlü ekipler diğer alanlardaki kör noktaları yine de göremeyebilir. Bu boşluk çoğu zaman üretim onu görünür kılana kadar saklı kalır. Yani düzeltmenin en pahalı olduğu ana kadar.
Bir skora güvenmeden önce sorulması gereken soru
Bu, ölçüme karşı bir argüman değildir. Mesele skor geldikten sonra ne olduğudur. Bir değerlendirmeden çıkan sayı, belirli bir iddia için kanıttır. O iddianın ne olduğunu ve ihtiyaç duyduğunuz iddia olup olmadığını hâlâ bilmeniz gerekir.
Bir sonraki skor tartışmasız gerçek kabul edilmeden önce daha küçük bir soru sorun: Bu sayıya bu kadar güvenebilmemiz için ne anlama gelmesi gerekir ve bu anlama kim karar verdi?
Bu sorunun tek bir doğru cevabı yoktur. Ama her zaman bir cevabı vardır. Çoğu ekip onu hiç sormaz.