Konuşma Tabanlı Yapay Zekâda Sorgu, Keşif ve Düzeltme
Konuşma tabanlı bir arayüz arama kutusunu diyaloğa çevirdiğinde tasarım problemi de yer değiştirir: artık sonuç listesini değil, konuşmanın gidişatını kurarsınız. Sorgunun oluşması, sonuçların taranması ve talebin yol boyunca değişmesi birbirinden farklı üç problem. Üçü de ayrı yerde tıkanıyor.
Sorgu: kullanıcı ne istediğini bilmiyorsa
“Yaz tatili için öneri isterim” cümlesinde tarih yok, bütçe yok, kaç kişi olduğu yok. Bilinen çözüm, ajanın soru sorması. Ama tasarım kılavuzları iki şeyi aynı nefeste söylüyor: belirsizliği gidermek için soru sor, çok soru sorup kullanıcıyı yorma. Eşiğin nerede olduğunu söyleyen yok. Eşik zaten sorunun kendisinde değil, faturasında: her ek soru bir tur daha demek ve kullanıcı ilk işe yarar cevabı görmeden önce ödediği bedel büyüyor.
Belirsiz bir sorguyu genelde tek yönlendirici soruyla açar, kalan alanları makul varsayılanlarla doldururum; varsayılanları da kullanıcıya görünür kılarım ki yanlışsa tek hamlede değiştirsin. Sormak yerine tahmin edip düzeltilebilir bırakmak tur sayısını sabit tutar.
Peki ya kullanıcı ne soracağını hiç bilmiyorsa? Orada soru işe yaramaz, örnek yarar. Hazır sorgu örnekleri aynı anda iki şey öğretir: hangi kelimelerle konuşulacağını, ve sistemin nereye kadar gittiğini.
Bütçe aralığını cümleyle anlatmak kaydırıcıyı sürüklemekten pahalıdır. Sohbetin içine gömülen kaydırıcı, onay kutusu ya da tarih seçici metinle yarışmaz, metnin yükünü alır.
Keşif: kullanıcı okumaz, tarar
Sonuçlar geldiğinde kimse baştan sona okumuyor. Kart, özet, karşılaştırma tablosu gibi formatların hepsi aynı işi yapıyor: gözün atlayabileceği bir yüzey kurmak.
“İkinci seçeneği detaylandır” gibi komutlar doğal görünür, uygulamada referans çözümlemesi ister; sistemin “ikinci”nin ne olduğunu ve sıralamanın o an ne olduğunu bilmesi gerekir. Peki ya kullanıcı üç tur sonra “ilkine dön” derse? Kalıcı kimliği olan, numaralandırılmış kartlar tutmuyorsanız bu cümlenin karşılığı yoktur.
Filtre ve sıralama sohbete taşınabilir, ama liste uzadıkça sohbet kötü bir arayüze dönüşür. Beş sonucu konuşarak elemek mümkün, elli sonucu değil. Sayı büyüdüğünde ekrana geri dönmek yenilgi değil, doğru karar.
Düzeltme: hatırlamanın faturası
“Sistem tercihleri hatırlasın” ile “her adımda geri bildirim topla” yan yana istendiğinde oturum durumu her turda büyür. Bağlam penceresi ise sabit. Bu yüzden hatırlama pratikte özetleme demektir, özetleme de kayıp demektir. İş, neyin özetlenemez olduğunu seçmekle başlar: bütçe, tarih ve elenen seçenekler yapılandırılmış alanda tutulup her turda aynen taşınır, gerisi özete gidebilir.
Kullanıcı “aslında masaüstü istiyorum” dediğinde sistemin yapması gereken tek şey, diğer kısıtları silmeden birini değiştirmek. En sık görülen hata, düzeltmenin bütün bağlamı sıfırlaması.
Yanlış cevap ve geri bildirim
Dış veri kaynağına bağlamak halüsinasyon riskini azaltır, sıfırlamaz. Getirme katmanı yanlış belgeyi döndürürse model o belgeye dayanır ve aynı özgüvenle yanlış cevap üretir. Ölçülmesi gereken şey bu yüzden yalnızca cevabın kalitesi değil, getirmenin isabeti; ikisi ayrı loglanmazsa hatanın hangi katmanda olduğu bilinemez.
“Bu doğru değil” düğmesi ucuzdur ve ham veri verir. Kullanıcının cümlenin hangi bölümünü işaretlediğini alabiliyorsanız geri bildirim gruplanabilir bir sinyale dönüşür.
Neyi ölçmeli
Tek bir memnuniyet puanı konuşma bittikten sonra gelir ve nerede bozulduğunu göstermez. Görev başarısı, cevaba kadar geçen tur sayısı ve düzeltme sıklığı daha çok şey söyler. Düzeltme sıklığı bunların en ucuzu, çünkü kullanıcıya hiçbir şey sormadan zaten logda duruyor: aynı adımda tekrarlanan düzeltmeler o adımın sorusunun yanlış sorulduğunu söyler.
Kaynaklar