Yorumlanabilirlik ile açıklanabilirlik aynı şey değil; karıştırmak pahalıya çıkıyor

Tez#

"Açıklanabilir yapay zekâ" ifadesi iki farklı ihtiyacı aynı sepete koyuyor ve bu, kurumsal kararlarda somut hatalara yol açıyor. İhtiyaçların birincisi bilimsel: bir modelin belirli bir davranışı nasıl ürettiğini mekanizma düzeyinde anlamak. İkincisi kurumsal: bir kararın neden verildiğini kullanıcıya, müşteriye ya da denetleyiciye anlatmak.

İkisi arasındaki fark, bir açıklamanın doğru olmasının ne anlama geldiğinde. Mekanizma açıklaması doğrulanabilir: bir bileşenin devre dışı bırakılması davranışı değiştiriyorsa iddia destekleniyor. Gerekçe açıklaması ise ikna edici olmakla yetinebiliyor ve tam bu yüzden risk taşıyor. Model kendi kararı için bir gerekçe ürettiğinde, o gerekçe makul ve tutarlı görünüyor ama kararı gerçekten üreten hesaplamayla ilişkisi kurulmamış oluyor. Kurumsal bağlamda bu, sahte bir denetlenebilirlik üretiyor: belge var, doğruluğu yok.

Bağlam: iki işin ayrı ayrı gerektirdikleri#

Tablo iki işi yan yana koyuyor. Amaç, hangi soruya cevap arıyorsanız hangi yöntemin uygun olduğunu netleştirmek.

Beşinci satır teknik ekiplerin sık yaptığı bir hataya işaret ediyor. Bir yorumlanabilirlik bulgusu — örneğin belirli bir davranışın belirli bir bileşen grubuyla ilişkili olduğu — genel bir mekanizma ifadesi. Bu bulgu tek bir kullanıcı kararını açıklamak için kullanılamıyor; o karar farklı bir girdide farklı bir yol izlemiş olabiliyor. Genel mekanizmadan tek vakaya geçiş, doğrulanması ayrıca gereken bir adım.

Kanıt: kurumsal ihtiyacın gerçek hâli#

Kurumlar genellikle mekanizma açıklamasına ihtiyaç duymuyor. İhtiyaç duydukları şey daha somut ve karşılanması daha kolay — ama farklı bir yöntem kümesi gerektiriyor.

• Girdi izlenebilirliği: karar hangi verilere dayandı? Bu, modelin içini açmadan cevaplanabiliyor ve denetimde ilk sorulan şey.
• Kaynak gösterimi: bilgi hangi belgeden geldi? Geri getirmeli sistemlerde bu doğrulanabilir bir açıklama.
• Karşı olgusal bilgi: girdi şu yönde değişseydi sonuç değişir miydi? Ölçülebilir ve kullanıcıya anlamlı.
• Karar kuralının kaydı: modelin çıktısı hangi eşikle hangi karara dönüştü? Bu kural sizin ve tümüyle açıklanabilir.
• İtiraz yolu: kullanıcı kararla aynı fikirde değilse ne yapabilir? Açıklamanın yerini bir bölümüyle bu tutuyor.
• İnsan incelemesinin kaydı: kim inceledi, neye baktı, ne değiştirdi? Modelin içinden çok bu kayıt denetleniyor.

Üçüncü madde kullanıcıya en anlamlı gelen ve en az sunulan açıklama biçimi. "Kredi başvurunuz reddedildi" cümlesinden sonra kullanıcının gerçekten ihtiyaç duyduğu şey modelin iç yapısı değil, neyin değişmesi hâlinde sonucun değişeceği. Bu, karşı olgusal bir açıklama ve ölçülebilir: girdi değiştirilip model yeniden çalıştırılıyor, sonuç karşılaştırılıyor. Doğruluğu doğrulanabilir olduğu için de ikna ediciliğe kaymıyor.

Mekanizma: modelin kendi gerekçesi neden delil değil#

En yaygın kısayol, modele kararının gerekçesini sormak. Bu ucuz, hızlı ve okunabilir bir çıktı üretiyor — ve ürettiği şey bir açıklama değil, bir açıklama metni.

Sorun şu: model, gerekçeyi üreten hesaplamaya erişerek yazmıyor; gerekçeyi de bir metin üretim görevi olarak üretiyor. Dolayısıyla gerekçe, karara etki eden faktörlerle tutarlı olmak zorunda değil. Araştırmada bu tutarsızlık gösterildi: bir modele kararını etkileyen bir ipucu verildiğinde, modelin ürettiği gerekçe o ipucundan hiç söz etmeyebiliyor ve tümüyle başka faktörleri sayabiliyor. Kurumsal sonucu ağır: bir uyum dosyasına konan model gerekçesi, doğrulanmamış bir beyan. Denetleyici o gerekçenin doğruluğunu sorduğunda gösterilecek bir kanıt bulunmuyor. Bu yüzden model gerekçesi bir arayüz unsuru olarak kullanılabilir — kullanıcıya bağlam verir — ama bir denetim kaydı olarak kullanılamıyor.

Karşı görüş#

Üç itiraz var. Birincisi: kullanıcılar model gerekçesini yararlı buluyor ve memnuniyet artıyor; pratik fayda teorik doğruluktan önemli. İkincisi: mükemmel açıklama beklemek ilerlemeyi engelliyor, yaklaşık açıklama hiç açıklamamaktan iyi. Üçüncüsü: yorumlanabilirlik araştırması hızla ilerliyor ve bu ayrım zamanla kapanacak.

Model gerekçelerini uyum dosyasına koyuyorduk. Denetçi tek soru sordu: bu gerekçenin kararı gerçekten yansıttığını nasıl biliyorsunuz? Cevabımız yoktu. Karşı olgusal teste geçtik.

Birinci itiraz kısmen doğru ve tez ona karşı değil: model gerekçesi arayüzde bağlam sağlayabilir. Ayrım, o metnin bir denetim kaydı olarak kullanılıp kullanılamayacağında ve alıntının gösterdiği yer tam burası. İkinci itiraz bir varsayımı taşıyor: yaklaşık açıklamanın nötr olduğu. Değil — yanlış bir açıklama, hiç açıklama olmamasından daha fazla güven üretiyor ve o güvenin dayanağı yok. Üçüncü itiraz izlenmeye değer ama bugünkü kararı belirleyemez; ayrıca yorumlanabilirlik ilerlese bile iki işin muhatabı ve zaman ölçeği farklı kalıyor, yani ayrım tümüyle kapanmıyor.

Sınırlar ve belirsizlik#

Bu analiz yorumlanabilirlik araştırmasının değerini tartışmıyor; iki işin karıştırılmasının sonucunu tartışıyor.

• Araştırma hızlı ilerliyor: mekanizma düzeyinde açıklama yetenekleri artıyor ve bu tablo değişebilir.
• Karşı olgusal açıklamaların maliyeti var: her karar için ek model çağrıları gerekiyor.
• Gerekçe tutarsızlığının sıklığı modele ve göreve bağlı: tek bir oran verilemiyor.
• Hukuki yeterlilik belirsiz: hangi açıklama biçiminin denetim için yeterli sayılacağı henüz yerleşmemiş.

Sonuç#

Yorumlanabilirlik bir araştırma programı, açıklanabilirlik bir ürün gerekliliği. Karıştırıldığında iki yönde hata üretiliyor: araştırma bulguları tek vaka açıklamasına dönüştürülüyor ve model gerekçeleri denetim kaydı sayılıyor. İkinci hata daha pahalı çünkü bir uyum dosyasında doğrulanmamış bir beyan bırakıyor.

Kurumların gerçek ihtiyacı çoğu zaman modelin içini açmak değil: girdi izlenebilirliği, kaynak gösterimi, karşı olgusal bilgi, karar kuralının kaydı, itiraz yolu ve insan incelemesinin kaydı. Altısı da modelin içine girmeden karşılanıyor ve altısı da doğrulanabilir. Model gerekçesi bunların yerine değil, yanına konabilir — arayüzde bağlam olarak, denetim kaydı olarak değil.

Ne yapmalı?#

1. 1İhtiyacı ayırın

   Mekanizmayı mı anlamak istiyorsunuz, bir kararı mı gerekçelendirmek? Yöntem bu ayrımdan çıkıyor.

2. 2Model gerekçesini denetim kaydı saymayın

   Gerekçe, karara etki eden faktörlerle tutarlı olmak zorunda değil ve doğruluğu gösterilemiyor.

3. 3Karşı olgusal açıklamaya geçin

   Girdi şu yönde değişseydi sonuç değişir miydi? Ölçülebilir, doğrulanabilir ve kullanıcıya anlamlı.

4. 4Karar kuralını ayrı kaydedin

   Model çıktısının hangi eşikle hangi karara dönüştüğü sizin kuralınız ve tümüyle açıklanabilir.

5. 5İtiraz yolunu kurun

   Açıklamanın işlevinin bir bölümünü itiraz mekanizması karşılıyor ve uygulanması daha kolay.

6. 6İnsan incelemesini kaydedin

   Kim inceledi, neye baktı, ne değiştirdi? Denetimde modelin içinden çok bu kayıt inceleniyor.