Reddetmeyi kabul etmekten kolay yap

Kullanıcı bir müşteriye e-posta yazıyor. Cümlenin yarısında yazı asistanı devamını öneriyor. Öneri yazının üstüne açılan bir kartta geliyor ve kartın tek düğmesi “Ekle”. Kapatmanın yolu bir menünün içinde ve neden kapattığını soran bir form açıyor. Kullanıcı satırı bitirmek için Enter'a basıyor ve öneri e-postaya giriyor. İçinde kullanıcının vermediği bir söz var.

Kullanıcı bu anı bir kez yaşayınca dersini alıyor. Öneriyi kapatmak üç adım, kabul edip sonradan silmek tek adım ve biraz dikkat. Kullanıcı kabul ediyor, düzeltmeyi sonraya bırakıyor ve bazen unutuyor. Ürünün panosunda ise her biri başarılı bir öneri olarak duruyor.

Zarar iki yerde büyüyor. Kullanıcının metninde onun yazmadığı cümleler birikiyor. Ürün de bu kabulleri önerilerin iyi olduğuna kanıt sayıyor ve aynı türden daha çok öneri gösteriyor. Reddetmek zahmetliyse kabul oranı kullanıcının zahmetten kaçışını ölçer.

Öneri, AI özelliğinin vitrini. Ekip özelliği görünür kılmak ister, kabul düğmesini birincil renge boyar, reddi ikincil bir köşeye koyar. Asimetri tek tek küçük kararlarla birikir ve kimse onu bilerek tasarlamış olmaz. Fransa'nın veri koruma kurulu CNIL aynı asimetriyi çerez pencerelerinde gördü. Google ve Facebook'un sitelerinde kabul tek tık, ret birkaç tıktı. Kurul bunun kullanıcının seçimini kabulden yana etkilediğine¹ karar verdi.

Ölçüm bu asimetriyi ödüllendiriyor. GitHub'ın Copilot çalışmasında geliştiricilerin verimlilik algısını en iyi açıklayan sinyal gösterilen önerilerin kabul edilme oranı² çıktı. Microsoft Research'ten Mozannar ve arkadaşları bu sayının sınırını açıkça yazıyor. Goodhart yasasına göre hedef hâline gelen ölçüt iyi bir ölçü olmaktan çıkar ve kabul oranı da bunun dışında kalmıyor³. Kabulü kolaylaştıran, reddi zorlaştıran her tasarım değişikliği bu sayıyı yükseltir.

Model de reddi kendiliğinden hatırlamaz. Kullanıcının kapattığı öneri modelin bağlamına girmedikçe aynı öneri bir sonraki duraklamada yine gelir. Kullanıcı aynı şeyi her seferinde yeniden reddeder ya da bir noktada vazgeçip kabul eder.

Kabul de ret de birer karar. Kabul tek ve bilinçli bir hareketle verilir. Ret için hareket bile gerekmez, kullanıcı hiçbir şey yapmazsa öneri reddedilmiş sayılır.

1. Görmezden gelmek reddetmektir. Kullanıcı yazmaya devam ettiğinde öneri kendiliğinden kaybolur. Öneriden kurtulmak için tuşa, düğmeye ya da menüye gerek kalmaz.
2. Kabul ayrı bir hareket ister. Kabulü kullanıcının yazarken zaten bastığı tuşlara bağlama. Enter, boşluk ve noktalama öneri yokmuş gibi çalışır. Kabul ayrı bir tuşla ya da düğmeyle olur.
3. Ret kabulün yanında, aynı ağırlıkta durur. Kapat düğmesi ekle düğmesiyle aynı boyda ve aynı yerde. Klavyede tek tuş, çoğu zaman Esc. Ret için onay penceresi ya da neden formu açılmaz. Neden sormak istiyorsan reddettikten sonra ve isteğe bağlı sor.
4. Parçasını almaya izin ver. Kullanıcı önerinin yalnız sonraki kelimesini, satırını ya da cümlesini alabilir. İşine yarayan bir parça için bütün öneriyi kabul edip kalanını silmek zorunda kalmaz.
5. Reddi hatırla, kabulü geri aldır. Kapatılan öneri aynı belgede aynı yerde yeniden gelmez. Kabul edilen öneri tek adımda geri alınır ve kullanıcının yazdığı metin olduğu gibi döner.

Öneri yine görünür kalır. Değişen tek şey ondan kurtulmanın bedeli. Artık kabul etmenin bedelinden yüksek olmuyor.

Aynı e-posta, aynı öneri. Soldaki asistan öneriyi metnin üstüne bir kartla açıyor, tek düğmesi kabul ve Enter da öneriyi ekliyor. Sağdaki öneriyi soluk metin olarak gösteriyor, ekle ve kapat aynı ağırlıkta ve yazmaya devam eden kullanıcı öneriden kendiliğinden kurtuluyor.

Microsoft Word'ün metin tahminleri bu desenin en sade hâlini uyguluyor. Kabul için Tab ya da sağ ok tuşu gerekiyor. Reddetmek için bir şey yapmak gerekmiyor. Word'ün belgesi yazmaya devam edersen ya da Esc'e basarsan önerinin kaybolduğunu⁴ yazıyor ve özelliği kapatmanın yolunu aynı sayfada, durum çubuğunda gösteriyor.

GitHub'ın belgesi Copilot'un VS Code'daki önerilerinde Tab ile kabulü, Esc ile reddi ve yalnız sonraki kelimeyi alan⁵ ayrı bir kısayolu anlatıyor. Kısmi kabul, işine yarayan parçayı almak için bütün öneriyi kabul etme baskısını kaldırıyor.

Apple'ın iPhone klavyesi satır içi tahminlerde dengeyi başka bir yere koyuyor. Gri metinle gelen tahmini boşluk tuşu kabul ediyor, yazmaya devam etmek reddediyor⁶. Boşluk, kelimeler arasında zaten basılan tuş. Apple kabul edilen tahmini değiştirmek için ayrı bir yol ve satır içi tahminleri kapatan bir ayar da sunuyor. Kabul yazmanın akışına bu kadar yakın durunca geri alma yolu şart oluyor.

Uygulamayan örnek Microsoft'un kılavuz çalışmasında. Değerlendiricilerden biri bir otomatik tamamlama ürünü için “I didn’t see a dismiss button. I can dismiss it by dismiss the whole keyboard”⁷ yazdı. Öneriden kurtulmanın tek yolu bütün klavyeyi kapatmaktı.

Microsoft'un insan ve AI etkileşimi kılavuzları bu ilkeyi ayrı bir madde olarak koyuyor. Sekizinci kılavuz istenmeyen AI hizmetini kapatmayı ya da görmezden gelmeyi kolay kılmayı⁸ istiyor. Kılavuzların dayandığı CHI 2019 makalesinde 49 tasarımcı 18 kılavuzu 20 popüler AI ürününe karşı sınadı⁷. Makaleye göre çağırma, düzeltme ve kapatma ilk taslakta tek kılavuzdu, sonra üç ayrı kılavuza bölündü. Kapatma o günden beri kendi numarası olan bir kılavuz.

Fikrin kökü daha eski. Eric Horvitz 1999'da karma inisiyatifli arayüzler için yazdığı ilkelerde kötü tahminin maliyetini düşürmeyi ve bunun için hizmet girişimini reddetmeye yarayan doğal hareketleri⁹ sayıyor. Aynı makaledeki LookOut prototipi kullanıcı cevap vermeyince bir süre bekliyor, sonra özür diler gibi bir hareketle ekrandan çekiliyordu. Kullanıcıdan hiçbir şey istemeden.

Kodlama asistanı çalışmaları kabulün neden bu kadar ucuz olduğunu gösteriyor. Mozannar ve arkadaşlarının Copilot oturumlarını inceleyen çalışmasında programcılar bazen öneriyi hemen kabul edip incelemeyi sonraya bırakıyor¹⁰. Yazarlar buna doğrulama borcu diyor ve bu borcun çoğu zaman programcıya geri döndüğünü yazıyor. Kabul burada kararı veriyor gibi görünür, kararı erteler.

CNIL'in kararı aynı mekanizmayı yapay zekâ dışında belgeliyor. Kurul, ret kabul kadar kolay olmayınca kullanıcının seçiminin kabulden yana kaydığını¹ kayda geçirdi. Google'a 150, Facebook'a 60 milyon avro ceza kesti ve iki şirkete reddi kabul kadar basit kılmaları için üç ay verdi.

Bu kaynaklar ret zahmetinin AI önerilerinde istenmeyen kabulü ne kadar artırdığını doğrudan ölçmüyor. Çerez kararı başka bir alanda, kodlama çalışmaları küçük örneklemli ya da geriye dönük. Kendi ürünündeki etkiyi aşağıdaki sinyallerle ölç.

Kabul oranı bu desenin işe yarayıp yaramadığını söylemez, desen uygulanınca düşebilir de. Bakılacak yer, kabul edilenin kullanıcının istediği şey olup olmadığı.

• Kabulden sonra silme. Kabul edilen önerilerin kaçı aynı oturumda silindi ya da büyük ölçüde değiştirildi? Desen yerindeyse bu pay düşer.
• Kaza kabulü. Kabulün hemen ardından geri alma gelen öneriler. Bu sayı yüksekse kabul tuşu yazmayla çakışıyor.
• Ret yolu. Reddedilen önerilerin ne kadarı yazmaya devam edilerek, ne kadarı düğmeyle ya da menüyle kapatıldı? Düğme ve menü payı yüksekse görmezden gelme yolu çalışmıyor.
• Geri dönen öneri. Kapatılan bir önerinin aynı belgede aynı yerde yeniden gösterilme sayısı. Hedef sıfır.
• Kısmi kabul. Parça alma açıldıktan sonra bütün öneri kabullerinin bir kısmı buraya kayar. Kayma, kullanıcının önceden işine yarayan bir parça için bütün öneriyi aldığını gösterir.

Üç metin var. Denetim promptu ürünündeki AI önerilerinin kabul ve ret yollarını tarar. Hangi tuşun ne yaptığına, ret düğmesinin yerine ve kapatılan önerinin geri gelip gelmediğine bakar, yalnız rapor yazar ve hiçbir dosyayı değiştirmez. Uygulama promptu deseni koda geçirir. Önce planı gösterir, onayınla uygular ve kabul tuşunun yazmayla çakışmadığını sınayan bir test ekler. Kural kodlama ajanının kendi çalışması için. Senin ajanın da öneri arayüzü kurarken reddi kabulden zor yapmasın.

Bu depoda kullanıcıya kendiliğinden öneri getiren bir AI özelliği var (satır içi tamamlama, yeniden yazma kartı, hazır yanıt çipi, öneri bildirimi ya da ajanın önerdiği değişiklik). Görevin, bir öneriyi reddetmenin kabul etmekten zor olup olmadığını denetlemek. Hiçbir dosyayı değiştirme, yalnız rapor yaz.

1. Önerinin gösterildiği bileşenleri bul: ghost text, inline suggestion, öneri kartı, chip, toast, modal. Her biri için kabul ve ret yollarını çıkar.
2. Klavye eşleşmelerine bak. Kabul hangi tuşlara bağlı? Enter, boşluk, noktalama ya da ok tuşları gibi yazarken zaten basılan tuşlar öneriyi kabul ediyor mu? Esc öneriyi kapatıyor mu?
3. Öneri görünürken kullanıcı yazmaya devam ederse ne oluyor? Öneri kayboluyor mu, metnin üstünde mi kalıyor, odağı mı tutuyor?
4. Arayüzde kabul ve ret düğmelerini karşılaştır: boyut, renk, konum, kaç tıkla ulaşıldığı. Ret bir menüye, onay penceresine ya da zorunlu neden formuna gömülü mü?
5. Kısmi kabul var mı (kelime, satır, cümle)? Yoksa kullanıcı işine yarayan bir parça için bütün öneriyi almak zorunda mı?
6. Reddedilen öneri bir yerde tutuluyor mu? Aynı belgede, aynı konumda aynı öneri yeniden üretiliyor mu? Ret bilgisi öneri üreten tarafa ulaşıyor mu?
7. Kabul edilen öneri tek adımda geri alınabiliyor mu, geri alma kullanıcının metnini olduğu gibi döndürüyor mu?
8. Ölçüm koduna bak. Kabul olayı nasıl sayılıyor? Kabulden hemen sonra gelen geri alma ya da silme ayrıca kaydediliyor mu, yoksa her kabul başarı mı sayılıyor?

Rapor biçimi: her bulgu için dosya ve satır, kabul ile ret arasındaki fark (tuş, tık sayısı, görünürlük), kullanıcının bunu nasıl yaşayacağı (örnek: satırı bitirmek için Enter'a basan kullanıcı istemediği cümleyi metne ekler) ve önerdiğin düzeltme. Bulguları istenmeden kabul edilen öneriye en çok yol açandan başlayarak sırala.

Bu depodaki AI önerilerine "reddetmeyi kabul etmekten kolay yap" desenini uygula. Önce planı göster, onayımı aldıktan sonra kodu değiştir.

Hedef davranış:
1. Öneri görünürken kullanıcı yazmaya devam ederse öneri kendiliğinden kaybolur. Öneri metnin üstünü örtmez, odağı almaz.
2. Kabul yalnız ayrı bir tuşla ya da düğmeyle olur (örnek: Tab). Enter, boşluk, noktalama ve ok tuşları öneri yokmuş gibi çalışır.
3. Ret tek harekettir: Esc ya da kabul düğmesinin yanında, aynı boyda bir kapat düğmesi. Ret için onay penceresi ya da zorunlu neden formu açılmaz. Neden sormak istiyorsan reddettikten sonra ve isteğe bağlı sor.
4. Kullanıcı önerinin bir parçasını alabilir: sonraki kelime, satır ya da cümle.
5. Kapatılan öneri aynı belgede aynı konumda yeniden gösterilmez. Ret, öneri üreten tarafa sinyal olarak gider.
6. Kabul edilen öneri tek geri alma adımıyla kalkar ve kullanıcının metni olduğu gibi döner.

Uygularken:
- Klavye eşleşmelerini tek bir yerde topla. Kabul tuşunu metin girişinde kullanılan tuşlarla çakışmayacak biçimde tanımla.
- Ret olaylarını kabul olaylarıyla aynı ayrıntıda kaydet: nasıl reddedildi (yazmaya devam, Esc, düğme), kabulden sonra kaç saniye içinde geri alındı ya da silindi.
- Panoda kabul oranının yanına kabulden sonra silinen ve geri alınan önerilerin payını ekle.
- Ekran okuyucu kullanıcılarına önerinin geldiğini, kabul ve ret tuşlarını duyur.
- Bir test ekle: öneri görünürken Enter'a, boşluğa ve noktaya bas, önerinin metne girmediğini doğrula. Sonra yazmaya devam et, önerinin kaybolduğunu ve aynı konumda yeniden gelmediğini doğrula.

## Reddetmeyi kabul etmekten kolay yap
- Öneri arayüzünde görmezden gelmeyi ret say. Kullanıcı yazmaya devam edince öneri kaybolsun.
- Kabulü Enter, boşluk, noktalama ya da ok tuşlarına bağlama. Kabul ayrı ve bilinçli bir hareket olsun.
- Ret düğmesini kabul düğmesinin yanına, aynı boyda koy. Reddi menüye, onay penceresine ya da zorunlu neden formuna gömme.
- Önerinin bir parçasını almayı mümkün kıl: kelime, satır ya da cümle.
- Kapatılan öneriyi aynı yerde yeniden gösterme. Kabul edileni tek adımda geri aldır.
- Kabul oranını tek başına başarı sayma. Kabulden sonra silinen ve geri alınan önerileri de ölç.

Bazı uyarılar görmezden gelinmemeli. Güvenlik uyarısı, veri kaybı riski ya da yasal bir zorunluluk tek tuşla kaybolan bir öneri gibi sunulmaz. Bu desen kullanıcının işine yardım eden, isteğe bağlı öneriler için.

Ret kolaylaşınca kabul oranı düşebilir. Düşen kısım, eski sayıda zahmetten gelen kabullerdir. Panoyu desenden önce bu ayrıma hazırla, yoksa doğru yapılan değişiklik bir gerileme gibi okunur.

Reddi hatırlamak da abartılabilir. Bir kez kapatılan öneri türünü kalıcı olarak susturmak, kullanıcının başka bir bağlamda isteyeceği yardımı keser. Hatırlamayı aynı belge ve aynı yerle sınırla, kalıcı susturmayı kullanıcının açık seçimine bırak.

Desen önerinin kalitesini düzeltmez. Kötü öneriyi reddetmek kolaylaşır ama kötü öneri yine gelir. Bu desen yalnız kötü önerinin metne zahmet yüzünden girmesini önler.