Açıklamanın körü körüne güven üretmesini önle

Finans ekibi gider raporlarını bir AI ön denetiminden geçiriyor. Asistan bir müşteri yemeğinin politikaya uygun olduğunu söylüyor ve altına uzun, akıcı bir gerekçe yazıyor. Kategori doğru, onaylayan doğru, fiş okunaklı, tarih iş günü, kişi başı tutar sınırın altında. Her cümle kararı destekliyor. Denetçi gerekçeyi okuyor, ikna oluyor ve onaylıyor.

Gerekçenin tek zayıf noktası kişi sayısı. Fişte yazmıyor. Asistan onu çalışanın açıklamasından almış ve kişi başı tutarı buna göre hesaplamış. Bu bilgi gerekçenin içinde öteki doğru cümlelerle aynı tonda duruyor. Denetçi doğru dört cümleyi okuyup beşinciyi de doğru sayıyor.

Açıklama kullanıcıya kararı kontrol etsin diye verildi. Uzun ve ikna edici olunca kontrolün yerine geçiyor. Kullanıcı açıklamanın varlığını kanıt sayıyor ve AI yanılırken de evet diyor. Doğru kararı savunan gerekçe ile yanlış kararı savunan gerekçe aynı ikna gücündeyse açıklama kullanıcıya hiçbir şey söylemez, yalnız onu ikna eder.

Açıklama ekleyen ekip kullanıcıların güveninin arttığını görür ve orada durur. Anketlerde açıklamalı sürüm daha çok beğenilir. Buçinca ve arkadaşlarının deneyinde aşırı güveni en çok azaltan tasarımlar, katılımcıların en az beğendiği tasarımlar oldu¹. Memnuniyete bakan ekip yanlış tasarımı seçer.

Model de ikna eden metne yatkın. Bansal ve arkadaşlarına göre birçok açıklama yöntemi en ikna edici açıklamayı üretmeyi hedefliyor ve bu hedef ekibin birlikte doğru karar vermesi için kötü bir seçim olabilir². Steyvers ve arkadaşları iki olası neden tartışıyor. İnsan tercihleriyle eğitilen modeller insanların sevdiği uzun ve ayrıntılı açıklamayı öğreniyor olabilir. Model bir cevaba bağlandıktan sonra o cevabı destekleyen metni yazıyor da olabilir. Ölçtükleri şey açık: daha uzun açıklama, ek uzunluk cevabı daha doğru yapmasa da kullanıcının güvenini artırdı³.

Üçüncü neden ölçümde. Ekipler açıklamanın etkisini ortalama doğrulukla ölçer. Bansal ve arkadaşlarının deneyinde açıklama, AI doğruyken ekibin doğruluğunu artırdı, AI yanılırken düşürdü ve net etki küçük kaldı². Ortalamaya bakan ekip açıklamanın zararsız olduğunu sanır. Zarar ancak AI'ın yanıldığı vakalar ayrı sayılınca görünür.

Açıklamanın işi kullanıcıya AI'ın nerede yanılıyor olabileceğini göstermek. Kararı savunan bir metin bu işi yapmaz.

1. Her adımı bir dayanağa bağla. Gerekçenin her adımı kullanıcının bakabileceği bir şeyi göstersin: kaynak cümle, veri satırı, yapılan hesap. Vasconcelos ve arkadaşlarına göre açıklamaların çoğu zaman işe yaramamasının bir nedeni, AI'ın cevabını doğrulamanın maliyetini yeterince düşürmemeleri⁴.
2. Doğrulanmamış adımı ayır. Varsayım, tahmin ya da birinin beyanından alınan bilgi gerekçede ayrı durur ve öyle adlandırılır. Kullanıcının gözü önce oraya gider.
3. Kararı neyin değiştireceğini yaz. Gerekçe cevabı savunmakla kalmaz, cevabın hangi koşulda yanlış olacağını da söyler. Güven düşükken karşı gerekçeyi de gösterir. Bansal ve arkadaşları bunu “uyarlanır açıklama” diye denedi: model emin değilken ikinci olası cevabı da açıklıyordu.
4. Kısa tut. Uzunluğu güvenle birlikte büyütme. Steyvers'ın deneyinde ek uzunluk güveni artırdı ama doğruyla yanlışı ayırmaya yardım etmedi. Kısa gerekçe görünür, ayrıntı açılır bir bölümde durur.
5. Düşünce dökümünü gerekçe diye sunma. Modelin akıl yürütme metni hata ayıklamaya yarar, ama kararın gerçek nedenini taşıdığı kanıtlanmış değil. Kullanıcıya gösterilen gerekçe dayanaklardan kurulur, döküm katlanmış ve adıyla durur.
6. Açıklamayı AI'ın yanıldığı vakalarda sına. Açıklamalı ve açıklamasız sürümü AI'ın yanlış olduğu örneklerde karşılaştır. Açıklama yanlış cevaba uymayı artırıyorsa açıklamayı değiştir.

Açıklamanın başarısını AI'ın yanıldığı vakalarda, kullanıcının hatayı ne sıklıkla yakaladığıyla ölç.

Aynı gider, aynı karar. Soldaki asistan uzun ve akıcı bir gerekçeyle kararı savunuyor, doğrulanmamış kişi sayısı öteki cümlelerin arasında kayboluyor. Sağdaki her adımı dayanağıyla yazıyor, doğrulanmamış adımı ayrı işaretliyor ve kararı neyin değiştireceğini söylüyor.

Microsoft'un ürün ekiplerine yazdığı aşırı güven çerçevesi, kaynak ve açıklama gibi doğrulama yardımlarının ayrıca sınanmasını istiyor. Gerekçesi açık. Açıklamalar yanlış olduklarında bile kullanıcının güvenini artırabiliyor⁵ ve kaynakların yalnızca orada durması da güveni yükseltebiliyor. Microsoft'un HAX araç setindeki AI eleştirisi örneği öteki yönü gösteriyor. Sistem kendi çıktısındaki belirli kusurlar için kanıt, açıklama ya da çözüm sunuyor⁶. Sayfanın notu da önlemin ters tepebileceğini ve gerçek kullanıcılarla sınanması gerektiğini yazıyor.

Anthropic, Claude'un düşünme sürecini görünür yaptığında bunu kullanıcının cevabı anlamasını ve kontrol etmesini kolaylaştırdığı⁷ için yaptığını yazdı. Aynı yazıda düşünce metninin modelin içinde olanı gerçekten temsil ettiğinden emin olmadıklarını da söyledi. Bir buçuk ay sonra yayımladıkları ölçüm bu çekincenin ne kadar yerinde olduğunu gösterdi.

Bansal ve arkadaşları 1.626 kullanıcıyla üç görevde deney yaptı: kitap ve bira yorumlarında duygu analizi ve mantık soruları. Görevleri, AI'ın doğruluğu insanınkine yakın olacak biçimde seçtiler. Açıklamalar ekibin başarısını yalnız güven puanı göstermekten öteye taşımadı. Bunun yerine insanların AI'ın önerisini doğru olsun yanlış olsun kabul etme olasılığını artırdı². Model emin değilken ikinci olası cevabı da açıklayan uyarlanır açıklama, kabul oranını doğru yöne itti, ama son doğrulukta anlamlı bir fark yaratmadı.

Si ve arkadaşları 80 kişiyle bir doğrulama görevinde LLM açıklamalarını arama sonuçlarıyla karşılaştırdı. Açıklama okuyanlar daha hızlı karar verdi. Açıklama yanlış olduğunda doğrulukları 0,35'te kaldı, hiçbir yardım almayan grupta 0,49, arama sonuçlarını okuyan grupta 0,54 idi⁸. Katılımcılar açıklamanın inandırıcı göründüğünü, özellikle kaynaktan alıntı içerdiğinde, alıntı ya da akıl yürütme yanlış olsa bile söyledi. Modelden iddianın neden doğru ve neden yanlış olabileceğini ayrı ayrı açıklamasını istemek ve iki tarafı yan yana göstermek, yanlış açıklamalı vakalarda doğruluğu 0,56'ya çıkardı⁸.

Gösterilen akıl yürütmenin kararın gerçek nedeni olduğu da varsayılamaz. Anthropic'in ölçümünde modeller cevabı kendilerine verilen bir ipucuna dayandırdığında, düşünce metninde bu ipucunu ortalamada Claude 3.7 Sonnet %25, DeepSeek R1 %39 oranında⁹ andı. İpucunu saklayan metinler ortalamada daha uzundu.

Hukuk da bu eğilimi tanıyor. AB'nin AI yasasının 14. maddesi, yüksek riskli sistemlerin denetimini üstlenen kişilerin çıktıya otomatik olarak güvenme eğiliminin farkında kalabilmesini¹⁰ istiyor ve buna otomasyon yanlılığı diyor.

Bu deneyler kitle kaynaklı katılımcılarla, kısa görevlerde yapıldı. Bansal ve arkadaşları sonuçların uzman kullanıcılı yüksek riskli alanlara aynen taşınmayabileceğini kendileri yazıyor.

Açıklamanın beğenilmesi bu desenin işe yaradığını söylemez. Bakılacak yer, AI yanıldığında açıklamanın kullanıcıyı uyarıp uyarmadığı.

• Yanlış cevapta kabul oranı. AI'ın yanıldığı örneklerde açıklamalı ve açıklamasız sürümün kabul oranını karşılaştır. Açıklamalı sürümde düşük olmalı.
• Doğru ve yanlış cevapta süre. Kullanıcı ikisinde aynı sürede karar veriyorsa açıklamayı okumuyor ya da ayırt edemiyor.
• Dayanağa bakma. Kullanıcılar doğrulanmamış diye işaretlenen adımın dayanağını açıyor mu? Açmıyorlarsa işaret görünmüyor.
• Uzunluk ve kabul. Uzun gerekçelerde kabul oranı kısa olanlardan yüksekse ve doğruluk farkı yoksa ikna eden şey uzunluk.
• Karşı koşulun isabeti. “Kararı ne değiştirir” bölümü, yanlış çıkan vakaların kaçında hatanın gerçek kaynağını gösterdi?

Üç metin var. Denetim promptu açıklamanın üretildiği ve gösterildiği kodu tarar, gerekçenin dayanağa bağlanıp bağlanmadığına, doğrulanmamış adımların ayrılıp ayrılmadığına ve açıklamanın AI'ın yanıldığı vakalarda sınanıp sınanmadığına bakar, yalnız rapor yazar. Uygulama promptu gerekçeyi dayanaklı adımlara böler, doğrulanmamış adımı işaretler ve “Kararı ne değiştirir” bölümünü ekler. Önce planı gösterir, onayınla uygular ve doğrulanmamış bir adımın gerekçede ayrı göründüğünü kanıtlayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Senin ajanın da raporunda kararını savunmak yerine nereye bakman gerektiğini göstersin.

Bu depoda kararını ya da cevabını bir açıklamayla (gerekçe, akıl yürütme, "neden bu sonuç" metni, vurgulanan özellikler) birlikte gösteren bir AI özelliği var. Görevin, bu açıklamaların kullanıcıyı olası hataya karşı uyarıp uyarmadığını, yoksa yalnız ikna edip etmediğini denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Açıklamanın üretildiği yeri bul: prompt şablonları ("gerekçesini açıkla", "adım adım düşün" gibi), açıklama üreten kod, modelin akıl yürütme çıktısını kullanıcıya taşıyan bileşen.
2. Açıklamanın adımları kontrol edilebilir bir dayanağa bağlı mı: kaynak cümle, veri satırı, hesap, belge sayfası? Kullanıcı dayanağı tek tıkla açabiliyor mu?
3. Doğrulanmamış adımlar (varsayım, tahmin, kullanıcının ya da üçüncü bir kişinin beyanından alınan bilgi) ayrı işaretleniyor mu, doğrulanmış adımlarla aynı biçimde mi yazılıyor?
4. Açıklama kararın hangi durumda değişeceğini ya da karşı gerekçeyi gösteriyor mu? Güven düşükken açıklama farklılaşıyor mu?
5. Açıklamanın uzunluğu nasıl belirleniyor? Bir sınır var mı, ayrıntı açılır bir bölümde mi duruyor?
6. Modelin ham akıl yürütme dökümü kullanıcıya gerekçe diye mi gösteriliyor? Gösteriliyorsa ne olduğu etiketleniyor mu?
7. Açıklamanın etkisi ölçülüyor mu? Özellikle AI'ın yanıldığı örneklerde açıklamalı ve açıklamasız sürümün kabul oranı karşılaştırılıyor mu?

Rapor biçimi: her bulgu için dosya ve satır, ne olduğu, hangi durumda açıklamanın yanlış bir cevabı kabul ettirebileceği (örnek: kullanıcı beyanından alınan bir sayı doğrulanmış gibi gerekçeye giriyor) ve önerdiğin düzeltme. Kullanıcının açıklamaya dayanarak onay verdiği yerlerden başla.

Bu depodaki AI özelliğine "açıklamanın körü körüne güven üretmesini önle" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Gerekçeyi serbest paragraf yerine adımlara böl. Her adım kullanıcının açabileceği bir dayanağa bağlansın: kaynak cümle, veri satırı, hesap.
2. Her adımın durumunu ayrı tut: doğrulandı ya da doğrulanmadı. Doğrulanmamış adım (varsayım, tahmin, beyandan alınan bilgi) ayrı görünsün ve nedenini söylesin.
3. Gerekçenin sonuna "Kararı ne değiştirir" bölümü ekle: cevap hangi koşulda tersine döner. Güven düşükken bu bölüm karşı gerekçeyi de göstersin.
4. Görünen gerekçeyi birkaç adımla sınırla, ayrıntıyı açılır bir bölüme koy. Gerekçenin uzunluğunu güvenle birlikte büyütme.
5. Modelin ham akıl yürütme dökümünü gerekçe diye gösterme. Göstereceksen katlanmış bir bölümde, ne olduğunu söyleyen bir etiketle göster.
6. Doğrulanmamış adım varken birincil eylem dayanağı açmak olsun, onay düğmesi öne çıkmasın.

Uygularken:
- Bir adımın doğrulanıp doğrulanmadığına kod karar versin: dayanak bulunduysa ve değer onunla eşleşiyorsa doğrulandı. Model yalnız adımın metnini yazsın.
- Gerekçenin yapısını (adımlar, dayanak, durum, karşı koşul) yapılandırılmış çıktı olarak al, serbest metinden ayrıştırmaya çalışma.
- Bir test ekle: dayanağı olmayan bir değer içeren örnekte gerekçenin bu adımı "doğrulanmadı" diye ayrı gösterdiğini ve "Kararı ne değiştirir" bölümünün geldiğini doğrula. AI'ın yanıldığı etiketli örneklerde açıklamalı sürümün kabul oranını raporlayan bir değerlendirme ekle.

## Gerekçeyle kontrol ettir
- Bir kararı ya da değişikliği anlatırken her iddianın dayanağını yaz: dosya ve satır, komut çıktısı, belge sayfası.
- Doğrulamadığın adımı doğruladıklarınla aynı tonda yazma. "Doğrulanmadı" diye ayır ve nedenini söyle.
- Raporun sonunda kararı neyin değiştireceğini yaz: hangi test başarısız olursa, hangi varsayım yanlışsa sonuç tersine döner.
- Gerekçeyi kısa tut. Uzunluk kararı daha doğru yapmaz, yalnız daha inandırıcı yapar.
- Düşünce sürecini kanıt diye sunma. Kanıt, kullanıcının açıp bakabileceği şeydir.

Kullanıcının karara dayanarak bir şey yapmadığı yerde (öneri sıralaması, otomatik tamamlama) ayrıntılı gerekçe gerekmez. Bu desen kullanıcının AI'ın kararını onayladığı ya da onu kullandığı yerler için.

Karşı gerekçenin bir bedeli var. Si'nin deneyinde iki taraflı açıklama, açıklamanın doğru olduğu vakalarda doğruluğu 0,87'den 0,73'e düşürdü⁸. Karşı tarafı güven düşükken göster.

Her adıma dayanak ve uyarı eklemek gerekçeyi kimsenin okumadığı bir rapora çevirebilir. Buçinca'nın deneyinin gösterdiği gibi kullanıcılar düşündüren tasarımı sevmez. Az adım, tek işaret ve tek tıkla açılan dayanak yükü taşınır tutar.

Bu desen gerekçenin sunuluşunu düzeltir. Dayanağın kendisi yanlışsa ya da kullanıcı dayanağa hiç bakmıyorsa hatayı yakalamaz. Kaynağın gerçekten cümleyi desteklediğini denetlemek ve kullanıcının AI'ı görmeden kendi kararını kurması ayrı önlemler.