Bir arayüz önermek, işlem yapma yetkisi verir mi?

Yapay zekâ bir ekranın düzenini, gösterilecek bilgileri ve sunulabilecek eylemleri önerebilir. Bu önerinin uygulanması, verinin doğruluğu ve işlemin yetkisi ise ayrı kararlar gerektirir. Muhit’te bu sınırı nasıl ele alıyorum?

Bir araştırma notunu gözden geçirmek istediğimizi düşünelim. Sistemden, kaynakları bir araya getiren ve eksik noktaları gösteren bir görünüm istiyoruz.

Model bir özet, kaynak tablosu ve birkaç eylem öneriyor. Ekranda “Notu incele”, “Düzeltmeyi uygula” veya “Yayımla” gibi düğmeler bulunabilir.

Buraya kadar yapılan şey, bir çalışma ortamının önerilmesi. Ancak düğmeler görünür hâle geldiğinde başka sorular ortaya çıkıyor: Hangi kayıt değişecek? Değişikliği kim yapabilecek? Kullanıcının seçimi nasıl anlaşılacak? İşlem tamamlandığında bunu hangi bilgiye dayanarak söyleyeceğiz?

Muhit’in yapay zekâyla arayüz üretimi tarafında ilgilendiğim mesele, bu soruların ekranın arkasında belirsiz kalmaması.

Önerinin anlaşılabilir bir biçimi olmalı

Bir model, kullanıcının isteğinden hareketle hangi bilgilerin birlikte gösterilmesinin anlamlı olacağını önerebilir. Uzun bir yanıtı bölümlere ayırabilir, karşılaştırılacak kayıtları tabloya yerleştirebilir veya düzenlenmesi gereken alanlar için bir form tarif edebilir.

Bu, özellikle henüz nasıl gösterileceğine karar verilmemiş içeriklerde yararlı bir imkân. İhtiyaç değiştikçe görünüm de değişebilir.

Muhit’in JSON arayüz adaptörü, böyle bir öneriyi tanımlı bileşenlere dönüştüren katman olarak çalışıyor. Model bağlantısı uygulamaya ait; adaptörün içinde kendiliğinden çalışan bir model veya otonom işlem hizmeti bulunmuyor.

Gelen tanım önce doğrulanıyor. Bileşen türleri, gerekli alanlar ve desteklenen değerler kontrol ediliyor. Geçerli bir tanım, izin verilen bileşenlerle ekrana taşınıyor.

Böylece modelin önerdiği görünüm, uygulamanın önceden belirlediği bir ifade alanına giriyor. Tanımın içine keyfî kod veya işlem yetkisi yerleştirilemiyor.

Fakat bu doğrulamanın neyi söylediğini doğru anlamak gerekiyor.

Bir başlığın uygun biçimde yazılmış olması, başlığın altındaki iddianın doğru olduğunu göstermiyor. Bir tablonun geçerli satırlardan oluşması, içindeki kayıtların güncel olduğunu kanıtlamıyor. Bir eylemin tanımda bulunması da o eylemin yapılmasına izin verildiği anlamına gelmiyor.

Geçerli bir arayüz tanımı, içeriğin doğruluğu ve işlem yetkisi hakkında tek başına karar veremez.

Bu nedenle araştırma notu örneğinde kaynakların nereden geldiğini, hangi sürüme ait olduğunu ve hangi bilginin model yorumu olduğunu uygulamanın ayrıca belirginleştirmesi gerekir. Düzenli bir ekran, bu ayrımların yerine geçmemeli.

Düğmeden gerçek işleme giden yol

Muhit’te bir kart eylemi, uygulamaya bileşenin ve eylemin kimliğini taşıyan bir olay iletebilir. Uygulama bu olayı kendi tanıdığı davranışla eşleştirir.

Örneğin “Notu incele” eylemi, uygulamanın belirlediği kaydın ayrıntısını açabilir. Adaptör eylemin adını okuyup kendiliğinden bir adres üretmez, veri kaydetmez veya yayımlama işlemi başlatmaz.

Bu sınırın pratik bir sonucu var: Modelin bir düğmeye “Yayımla” yazması, uygulamaya yeni bir yayımlama yeteneği kazandırmaz. Uygulamanın o işlemi tanıması, hangi kayda uygulanacağını belirlemesi ve gerekli izinleri denetlemesi gerekir.

Bir yayın uygulamasında bu yol şöyle kurulabilir: Kullanıcı önerilen değişikliği inceler, uygulama değişecek kaydı ve kapsamı gösterir, sunucu işlem yetkisini ve kaydın güncel durumunu kontrol eder. Başarı bilgisi, gerçek işlemin sonucundan sonra verilir.

Bu akış, Muhit’in tek başına sağladığı bir yayın sistemi değildir. Muhit’in bileşenleriyle kurulabilecek uygulama davranışına bir örnektir.

Burada olay ile kullanıcı niyeti arasında da dikkat edilmesi gereken bir ayrım bulunuyor. Bir bileşenden olay gelmesi, tek başına yetkilendirilmiş bir insan komutunun kanıtı sayılamaz. Bazı durum olayları uygulama koduyla yapılan değişikliklerden de doğabilir. Bir olay işleyicisinin varlığı, kimlik ve izin denetiminin yerini tutmaz.

Bu yüzden işlem yetkisini ekrandaki düğmenin görünürlüğüne bağlamak yeterli olmaz. Yetki, işlemin gerçekleştirildiği katmanda da değerlendirilmelidir.

İkinci yazıda yerel onay ile kalıcı kayıt arasındaki ayrımı ele almıştım. Aynı ilke burada da geçerli: Arayüzün söylediği sonuç, gerçekten gerçekleşen işlemin kapsamını anlatmalı.

İnsanın kontrolü, anlayabildiği yerde başlar

Kontrolü yalnız bir onay düğmesine indirgemek kolay. Oysa kişi neyi onayladığını anlayamıyorsa, düğmenin bulunması yeterli olmuyor.

Araştırma notu örneğinde “Düzeltmeyi uygula” demeden önce önerilen değişikliğin görülebilmesi gerekir. Hangi cümle değişiyor? Bu değişiklik bir kaynağa mı dayanıyor, yoksa modelin yorumundan mı geliyor? Mevcut metnin hangi sürümü üzerinde çalışılıyor?

Bu bilgiler, kararın bağlamını oluşturuyor.

İnsanın kontrolünü koruyan bir arayüz; öneriyi inceleme, gerektiğinde değiştirme ve vazgeçme yollarını da açık tutmalı. Her işlem için aynı ağırlıkta onay istemek yerine, kontrolün biçimini işlemin etkisine göre düşünmek gerekiyor. Görünümü daraltan bir filtre ile yayımdaki metni değiştiren bir eylem farklı sonuçlar taşıyor.

Modelin yeni bir öneri üretmesi de bu sürekliliği bozmamalı. Kişi bir alanı düzenlerken ekran yeniden kurulursa, yazdığı şeyin ne olacağı baştan belirlenmeli.

Muhit’in adaptörü geçersiz bir güncellemede mevcut görünümü koruyor. Başarılı güncellemede ise görünüm yeniden kuruluyor; önceki tablonun filtre ve seçim durumu otomatik olarak taşınmıyor. Korunması gereken kullanıcı durumu varsa, uygulamanın bunu ayrıca yönetmesi gerekiyor.

Bu teknik ayrıntı, insanın kontrolüyle doğrudan ilgili. Kullanıcı kendi değişikliğini modelin yeni önerisinden ayırabilmeli ve başladığı işe dönebilmelidir.

Muhit’te kurmaya çalıştığım sınır bu: Modelin öneri alanı açıkça tanımlansın; uygulamanın sorumluluğu ve insanın kararı görünür kalsın.

Bir ekranın üretilebilmesi önemli bir imkân. O ekranın güvenle kullanılabilmesi ise öneriden gerçek sonuca uzanan yolun anlaşılır olmasına bağlı.

Kullanıcı, “Bunu sistem önerdi; şu kısmı ben değiştirdim; bu işlemi ben seçtim; şu sonuç gerçekten gerçekleşti” diyebildiğinde, arayüz hem üretime alan açıyor hem de kararın izini koruyor.

---

Kaynak: Muhit’in JSON arayüz sözleşmesi ve yerel geliştirme kaynağındaki tasarım ilkeleri. Araştırma notu ve yayın akışı, sorumluluk sınırlarını anlatmak için kullanılan örnek senaryolardır.

Önceki Muhit yazıları: Muhit: Bir arayüzü tutarlı yapan nedir? · Muhit: Bir tasarım kararı ekranda nasıl çalışır?

Atlas kavramları: Tasarım · Yazılım · Bağlam · Sistemler · Zekâ