Yapay Zekâ ve Entegrasyon5 dk okuma
Yapay Zekâ Özelliklerinde İnsan Denetimi Neden Önemlidir?
Karar desteği ile otomatik karar arasındaki fark, riskin nerede durduğunu belirler. Denetim noktası tasarımın parçasıdır.
Norvane Ekibi
"İnsan denetimi var" cümlesi, çoğu üründe tek bir şeyi anlatır: sonucun uygulanmadan önce gösterildiği bir onay ekranı.
Ekranın varlığı denetimin var olduğunu göstermez. Gösterdiği şey, denetim için bir yer ayrıldığıdır. Bu yerin gerçekten denetim üretip üretmediği, oradaki kişinin ne kadar zamanı olduğuna, ne gördüğüne ve reddetmenin ne kadar kolay olduğuna bağlıdır.
Bu ayrım, yapay zekâ özelliklerinde güvenin nerede kurulup nerede kaybolduğunu belirler.
Karar desteği ile otomatik karar
Bir özelliğin riski, ne kadar doğru çalıştığından çok, sonucun ne yaptığından gelir.
Karar desteği, kullanıcıya bir öneri sunar; kararı kullanıcı verir. Model yanılırsa kullanıcı görmezden gelir ve süreç normal biçimde devam eder. Buradaki hata maliyeti düşüktür.
Otomatik karar, sonucu doğrudan uygular: bir talebi kapatır, bir ödemeyi yönlendirir, bir kaydı günceller. Model yanılırsa, hatanın fark edilmesi için birinin sonradan bakması gerekir.
Aynı model, aynı doğrulukla, bu iki kurgudan birinde makul diğerinde riskli olabilir. Bu yüzden "modelimiz yeterince iyi mi" sorusu tek başına eksiktir; asıl soru, çıktının hangi yetkiyle hareket ettiğidir.
Aradaki geçiş genellikle sessiz olur. Bir özellik öneri olarak başlar, iyi çalıştığı görülür ve bir süre sonra "zaten hep kabul ediyoruz" denerek otomatik hâle getirilir. Bu meşru bir karardır — ancak bilinçli verilmesi gerekir, çünkü riski değiştirir.
Denetim, sonuca göre ölçeklenmeli
Her yapay zekâ özelliğine aynı denetim uygulanamaz; uygulanırsa ya sistem kullanılamaz hâle gelir ya da denetim biçimsel kalır.
İşe yarayan yaklaşım, denetimi sonucun ağırlığına göre kademelendirmektir.
Sonucu geri alınabilir ve düşük etkili olan işlerde denetim gerekmez; kullanıcı zaten çıktıyı görür ve beğenmezse kullanmaz. Bir metin önerisi veya bir sıralama bu gruptadır.
Sonucu görünür ama düzeltilebilir olan işlerde denetim, sonradan yapılabilir: işlem uygulanır, kayıt tutulur, düzenli olarak örneklem üzerinden kontrol edilir.
Sonucu geri alınamayan veya dışarıya yansıyan işlerde ise denetim önce gelmelidir. Para hareketi, kalıcı silme, müşteriye giden bir mesaj veya bir hesabın kapatılması bu gruptadır.
Bu kademelendirme yapılmadığında iki hatadan biri kaçınılmazdır: ya önemsiz işler onay bekler ve sistem yavaşlar, ya da önemli işler kimsenin bakmadığı bir akıştan geçer.
Kademeyi seçerken güvenli yön bellidir: sıkı başlayıp veriyle gevşetmek, gevşek başlayıp bir olaydan sonra sıkılaştırmaktan daha ucuzdur. İlk haftalarda her vakanın incelenmesi, hem hata biçimlerini öğretir hem de hangi durumların otomatikleştirilebileceğini gösterir. Gevşetme kararı o zaman tahmine değil kayda dayanır.
Uygulanamayan denetim, denetim değildir
Denetim tasarımının en çok atlanan kısmı dikkat bütçesidir.
Bir kişinin saatte dört yüz öneriyi incelemesi bekleniyorsa, o kişi dört yüzünü de onaylar. Bu bir disiplin sorunu değildir; makul bir insan davranışıdır. Sonuç, kâğıt üzerinde denetlenen ama pratikte denetlenmeyen bir sistemdir — ki bu, hiç denetim olmamasından daha tehlikelidir, çünkü kurum kendini korunuyor sanır.
Bunu düzeltmenin yolu genellikle onay sayısını azaltmaktan geçer. Modelin güvenli olduğu durumlar otomatik ilerler, yalnızca belirsiz kalan veya eşiği aşan durumlar insana gelir. Böylece gelen az sayıdaki vaka gerçekten incelenir.
İkinci yol, incelemeyi kolaylaştırmaktır. İnceleyen kişinin kararı verebilmesi için gereken bağlamın aynı ekranda olması gerekir: model neye dayanarak bu sonucu üretti, hangi kayıtlara baktı, benzer vakalarda ne olmuştu. Bağlam yoksa inceleme, tahmin etmeye dönüşür.
Denetimi anlamlı kılan üç şey
Pratikte fark yaratan üç tasarım kararı vardır.
Gerekçe göstermek. Çıktının yanında dayanağının bulunması, hem incelemeyi hızlandırır hem de kullanıcının ne zaman güvenmesi gerektiğini öğrenmesini sağlar. Kaynak gösterilebilen durumlarda kaynağa bağlantı vermek, güveni açıklamadan daha iyi kurar.
Reddetmeyi kolaylaştırmak. Kabul etmek tek tıkla, reddetmek beş adımla yapılıyorsa sistem kabule doğru eğilir. İki yolun maliyeti benzer olmalıdır.
Geri bildirimi kaydetmek. Reddedilen çıktılar, sistemin en değerli verisidir. Nerede ve neden yanıldığını gösterirler. Bu kayıt tutulmadığında aynı hata sınıfı fark edilmeden tekrar eder.
Güven ne fazla ne az olmalı
Denetimin işe yaraması, denetleyen kişinin sisteme ne kadar güvendiğine bağlıdır — ve bu güvenin iki yönlü bozulma biçimi vardır.
Birincisi aşırı güvendir. Bir sistem uzun süre doğru çalıştığında, inceleme yavaş yavaş göz gezdirmeye dönüşür. Bu, dikkatsizlik değil öğrenilmiş bir davranıştır: her seferinde doğru çıkan bir çıktıyı kontrol etmek, zamanla anlamsız bir iş gibi hissettirir. Sorun, sistemin nadiren ama ciddi biçimde yanıldığı anda ortaya çıkar; çünkü tam olarak o an, kimsenin bakmadığı andır.
İkincisi yetersiz güvendir. Çıktı gerekçesiz sunulduğunda veya birkaç kez belirgin biçimde yanıldığında, kullanıcı özelliği tamamen kullanmayı bırakır. Bu durumda ürün teknik olarak çalışır ve pratik olarak yoktur.
İkisinin de çaresi aynı yerdedir: çıktının ne kadar emin olduğunu göstermek. Modelin belirsiz kaldığı durumları belirsiz olarak işaretlemek, kullanıcının dikkatini doğru yere yönlendirir. Her çıktıyı aynı kesinlikte sunan bir arayüz, kullanıcıya nerede dikkatli olması gerektiğini öğretemez.
Bu, arayüzün ne olacağını söylemesi ilkesinin aynısıdır; burada söylenmesi gereken şey, sistemin kendi sınırıdır.
Denetimi kim yapıyor?
Tasarımda sık atlanan bir soru da denetimin kime düştüğüdür.
Denetim çoğu zaman mevcut bir ekibin üzerine, ek bir görev olarak eklenir. Bu ekip zaten kendi işini yapmaktadır; yeni gelen inceleme yükü için ne zaman ne de yetki tanımı vardır. Sonuç öngörülebilirdir: inceleme, günün en yoğun anında yapılan ve en hızlı bitirilmek istenen iş hâline gelir.
İkinci sorun yetkidir. İnceleyen kişi çıktıyı reddettiğinde ne olacağı tanımlı değilse, reddetmek bir sorumluluk üstlenmek anlamına gelir ve insanlar bundan kaçınır. Reddedilen vakanın nereye gideceği baştan belli olmalıdır.
Üçüncüsü bilgidir. İnceleyen kişi, sistemin nerede güçlü nerede zayıf olduğunu bilmiyorsa, denetimi rastgele yapar. Ekibe "bu özellik şu durumlarda yanılabiliyor" demek, uzun bir eğitimden daha etkilidir.
Bu üçü sağlanmadığında denetim, ekibin üzerine yıkılmış bir yük olarak kalır ve zamanla sessizce boşalır — kimse kaldırdığını söylemez, yalnızca herkes onaylamaya başlar.
Sonradan sorulacak sorular
Bir yapay zekâ özelliği yayına girdikten sonra, er ya da geç şu sorulur: bu sonuç neden böyle çıktı?
Cevap verebilmek için birkaç şeyin kaydedilmiş olması gerekir: hangi girdiyle çalışıldı, hangi sürüm kullanıldı, sonuç neydi ve insan ne yaptı. Bunlar ağır bir altyapı gerektirmez; ancak sonradan eklenmesi zordur, çünkü geçmiş kayıt geriye dönük üretilemez.
Bu kayıt yalnızca hata ayıklama için değildir. Bir müşteri "bana bu neden gönderildi" diye sorduğunda, cevabın "bilmiyoruz" olmaması gerekir.
İnsan denetimi tasarımı
- Bu çıktı öneri mi, yoksa doğrudan uygulanan bir karar mı?
- Sonuç geri alınabilir mi, dışarıya yansıyor mu?
- Denetim, sonucun ağırlığına göre kademelendirildi mi?
- İnceleyen kişinin vaka başına ne kadar zamanı var?
- Karar için gereken bağlam aynı ekranda mı?
- Reddetmek, kabul etmek kadar kolay mı?
- Reddedilen çıktılar kaydediliyor ve gözden geçiriliyor mu?
- Bir sonucun neden üretildiği sonradan cevaplanabilir mi?
Sonuç
İnsan denetimi, yapay zekâ özelliklerine eklenen bir güvenlik katmanı değil, o özelliğin tasarımının bir parçasıdır. Nerede duracağı, ne göstereceği ve kime ne kadar zaman bırakacağı, özelliğin kendisi kadar belirleyicidir.
En sık yapılan hata, denetimi bir onay ekranına indirgemektir. En sık göz ardı edilen gerçek ise şudur: onaylayan kişi hayır diyemiyorsa, sistemde denetim yoktur — yalnızca sorumluluğun devredildiği bir adım vardır.
Bu ayrımı yapay zekânın gerçekten gerekli olup olmadığı sorusuyla birlikte ele almak, yapay zekâ entegrasyonu çalışmalarımızda kapsamı belirleyen ilk adımlardan biri.