Yapay zekanın bir üründe durması gereken yer

Bir yapay zeka özelliğinin işe yarayıp yaramayacağını belirleyen soru, bize yöneltilen soruyla neredeyse hiçbir zaman aynı değildir.

Müşteriler genellikle akıllarında belirli bir modelle gelirler. Ancak ürünün öncelikle, o modelin hatalı sonuç verdiği durumlarda ne yapacağına dair bir karara ihtiyacı vardır. İşin büyük kısmını bu karar oluşturur; istem (prompt), bilgi getirme (retrieval) ve değerlendirme seti gibi unsurlar hep bu kararın ardından şekillenir.

İşe yarayan üç temel yapı

Hayata geçirdiğimiz hemen hemen her özellik, şu üç yapıdan birine girer:

Birincisi, işletmenin halihazırda elinde bulunan materyallere (politika belgeleri, ürün kılavuzları, üç yıllık destek kayıtları vb.) dayanarak soruları yanıtlar. Model, iade politikanızı ezbere bilmez; yalnızca bu politikanın yer aldığı sayfayı nasıl okuyacağını bilir ki bu, çok daha küçük ve güvenilir bir iştir. Mühendislik süreci büyük ölçüde bilgi getirme (retrieval) üzerine kuruludur ve bu süreç denetlenebilir; dolayısıyla yanlış bir yanıt alındığında, bilginin hangi belgeden geldiği görülebilir. Genellikle düzeltilmesi gereken şey de o belgedir.

İkincisi, ürünün içinde yer alır ve tek bir dar kapsamlı işi yapar. Bir görüşme öncesinde uzun bir yazışma dizisini özetlemek, kullanıcının daha sonra düzenleyeceği bir mesaj taslağı hazırlamak veya fotoğrafı çekilen bir faturadaki verileri okuyup kullanıcının kontrolüne sunulacak alanlara aktarmak gibi. Kontrol yine insandadır; özellik öneride bulunur, son kararı kullanıcı verir.

Üçüncüsü ise baştan sona tekrarlanabilir bir süreci yürütür: bir dosyayı alır, kurallara göre kontrol eder, onaylananları kaydeder ve onaylanmayanları işaretler. Asıl kazanımlar buradadır ve bu süreç en büyük özeni gerektirir; çünkü model ile nihai sonuç arasında duran bir insan yoktur.

Bu üç yapıdan hiçbirine uymayan işler, genellikle ürün kılığına girmiş birer araştırma projesidir. Yine de yapmaya değer olabilirler; ancak bütçelendirilmeleri araştırma projesi olarak yapılmalıdır.

Önce hatalı yanıtı tasarlayın

On seferin dokuzunda doğru sonuç veren bir model, başarılı bir model sayılabilir; ancak onuncu yanıt da diğer dokuzuyla birebir aynı görünüyorsa, ortaya çıkan ürün zayıf bir üründür.

Bu nedenle, başarıdan önce başarısızlık durumu tasarlanmalıdır. Belirsizlik nerede görünür hale gelir? Kullanıcı bu konuda ne yapabilir? Bir insana ulaşma yolu var mı ve bu yol, kimsenin kendini tekrar etmek zorunda kalmaması için gerekli bağlamı (context) taşıyor mu? İşin içinde para söz konusuysa, işlem kesinleşmeden önce birinin onay verdiği bir aşama bulunuyor mu?

Arayüz tasarımında bu durum, birkaç temel alışkanlığa indirgenir. Kaynağı gösterin; böylece kullanıcı ekrandan ayrılmadan cevabı doğrulayabilir. Çıktıyı nihai bir sonuç olarak değil, düzenlenebilir bir biçimde sunun. Sistemin bir kullanıcı adına gerçekleştirdiği işlemlere dair görünür bir kayıt tutun. Ayrıca kullanıcılara, bir insana ulaşacak şekilde hatalı cevapları bildirme imkanı tanıyın; zira kaybolup giden şikayetler, kalite sorunlarının görünmez kalmasına neden olur.

Standartlar, özelliğin temas ettiği alana göre değişir. Destek taleplerinin geldiği bir gelen kutusunda özetleme yapan bir asistan zaman zaman hata yapsa da yine de varlığını haklı çıkarabilir. Ancak aynı toleransın bir ödeme gücü kontrolü veya hesap özetini besleyen bir işlem sınıflandırması için geçerli olması bambaşka bir durumdur. Günün birinde birisi neden böyle bir karar alındığını soracaktır; "model bunu önerdi" cevabı ise bu sorgulamada geçerli bir açıklama olmaz. Burada işe yarayan yaklaşım bellidir: Okuma ve taslak oluşturma işini modele bırakın; aritmetik işlemleri ve kural uygulamalarını standart koda yaptırın; ayrıca modelin ne ürettiğini, kuralların bu çıktıyı nasıl işlediğini ve sonucu kimin onayladığını gösteren kayıtlar tutun.

Bazen cevap "hayır"dır

Müşterilerimizi yapay zeka kullanmaktan vazgeçirdiğimiz durumlar olmuştur.

Eğer bir görevin kuralla hesaplanabilen doğru bir cevabı varsa, o kuralı yazın. KDV'yi çoğu zaman doğru hesaplayan bir model, her seferinde doğru hesaplayan basit bir aritmetik işlemden daha kötüdür ve işlem başına maliyeti daha yüksektir. Eğer girdi sekiz alanlı bir formsa, özellik de sekiz alanlı bir formdur.

Çıktı, kimsenin incelemediği, düzenlemeye tabi bir kayda işleniyorsa, mesele artık modelin yeterince iyi olup olmadığına değil, kararı sorma yetkisi olan birine daha sonra açıklayıp açıklayamayacağınıza dönüşür.

Çalıştırma maliyeti

Maliyet, sabit bir altyapı gideri değildir. Kullanım oranına göre değişir; kullanım oranı ise arayüzde yapılan tercihlere bağlıdır. Her sayfa yüklendiğinde çalışan bir asistanın maliyeti, bir butona basıldığında devreye girenden daha yüksektir. Her ziyarette yeniden oluşturulan bir özetin maliyeti, yazışma dizisi değişene kadar önbellekte tutulan bir özetinkinden fazladır. Küçük bir modelin halledebileceği bir görev için büyük bir model kullanmak, boşa harcanan para demektir.

Bu nedenle kullanım verileri özellik bazında raporlanır ve aylık tutar, fatura geldiğinde öğrenilen bir sürpriz değil, önceden üzerinde mutabık kalınan bir rakam olur. Kontrolden çıkma riski taşıyan özelliklere bir üst sınır getirilir ve bu sınıra ulaşıldığında ne yapılacağı da önceden belirlenir. Yoğun yük altında basit bir arama kutusuna dönüşen bir özellik, faturayı sessizce üçe katlayan bir özellikten daha iyi bir sonuçtur.

Herhangi bir şey müşteriye ulaşmadan önce, elimizde bilinen doğru yanıtlarıyla birlikte bir dizi gerçek örnek bulunur ve yapılan her değişiklik bu örnekler üzerinde test edilir. Gerçek gelen kutusundan alınan elli örnek, uydurulmuş bin tanesinden çok daha değerlidir. Bu süreç pek gösterişli sayılmasa da, gelişme kaydeden bir özellik ile amacından sapan bir özellik arasındaki temel farkı belirler. Bu süreç olmadan yapılan bir istem (prompt) değişikliği sadece bir tahminden ibaret kalır ve geriye kalan tek geri bildirim kanalı müşteri şikayetleri olur. Üstelik bu örnek seti zamanla büyür; çünkü birinin bildirdiği her hatalı yanıt, yeni bir örnek haline gelir. Bildirim kanalının önemli olmasının ikinci nedeni de budur.

İlk iş genellikle küçük bir iştir. Destek biriminizin gelen kutusuna düşen soruları ya da işe yeni başlayan birine ihtiyaç duyacağı belgelerle birlikte devredeceğiniz bir süreci inceleriz; ardından bir değerlendirme sunarız: Yapay zekanın burada fayda sağlayıp sağlamayacağı, çalıştırma maliyetinin kabaca ne olacağı ve hangi noktalarda zorlanacağı gibi hususları ele alırız.

Bazen bu değerlendirme olumsuz sonuçlanır. Bu da yararlı bir yanıttır; üstelik bütçe ayrıldıktan sonra durumu fark etmekten çok daha düşük maliyetli bir yoldur.