AI Özelliği Eklemeden Önce: Hangi İş Kısalıyor?

Bir özelliği yapay zekayla kurmak, o özelliğin gerekli olduğunu göstermez. Kullanıcının zaten yapmakta olduğu bir işi kısaltan yapay zeka tutunuyor; kullanıcının istemediği bir işi arayüze ekleyen yapay zeka fazladan gürültü olarak kalıyor. Aradaki farkı yayına almadan önce görmenin yolları var ve hiçbiri özel bir araç gerektirmiyor.

Önce hangi işin kısaldığını yaz

Bir özelliği tarif etmenin en hızlı testi şu cümleyi tamamlamak: kullanıcı bugün şu işi şu kadar adımda yapıyor, bu özellikle şu kadar adımda yapacak. Cümle tamamlanamıyorsa özellik bir problemi çözmüyordur, çözüyormuş gibi anlatılıyordur.

Lightroom'un nesne kaldırma aracı cümleyi zorlanmadan tamamlar. Fotoğrafın arkasındaki tel direği silmek klonlama fırçasıyla dakikalar sürüyordu, seçip beklemekle saniyeler sürüyor. İşin kendisi değişmedi, süresi değişti; kullanıcı o direği zaten silmek istiyordu.

Instagram'ın arama kutusunu sohbet alanına çevirmesi aynı cümleyi tamamlayamaz. Oraya gelen kullanıcının niyeti baştan belliydi: bir hesabın adını yazmak ve o hesaba gitmek. Kısalan bir iş yok, alışılmış bir yol uzuyor. LinkedIn'in her gönderinin altına iliştirdiği genel geçer soru önerileri de aynı yerden hatalı; kimse o soruları sormak istediği için orada değil.

Flash'tan kalan ders teknolojiyle ilgili değildi

2000'lerin başında bir siteyi baştan sona Flash'la yapmak yetenek göstergesiydi. Flash'ı bitiren şey tek başına teknik kısıtları olmadı. Giriş animasyonunu izlemek zorunda kalan, aradığı telefon numarasını bulamayan kullanıcı bitirdi. Teknoloji kullanıcının niyetinin önüne geçtiğinde ne kadar etkileyici olduğu işe yaramıyor, çünkü kullanıcı gösteriyi izlemeye değil bir işi bitirmeye gelmişti. Bugün arayüzde "yapay zekayla güçlendirildi" rozetinin kapladığı alan, o giriş animasyonuyla aynı yeri kaplama riski taşıyor.

Özelliği niyetin arkasına koy

Yerleşim kararı çoğu ekipte metin yazımından sonra konuşuluyor, oysa ilk konuşulması gereken o. Bir model çağrısını arama kutusu gibi yüksek trafikli bir yola koyduğunda her gösterim sana bir istek maliyeti çıkarır ve her gösterim kullanıcıya bir bekleme ekler. Aynı çağrıyı açık bir düğmenin arkasına aldığında yalnızca niyetini belirtmiş kullanıcı için çalışır. Fatura ile kullanıcı memnuniyeti burada aynı yöne bakıyor: gösterim başına değil, talep başına çalıştır.

Deterministik olmayan bir özellik nasıl test edilir

Klasik kullanılabilirlik testinde beş kullanıcı aynı ekranı görür, bulguları toplarsın. Model çıktısı üreten bir özellikte beş kullanıcı beş farklı çıktı görür, dolayısıyla test ettiğin şey arayüz değil, o gün gelen örneklem olur. Ölçümü ikiye ayırmak bu yüzden gerekiyor.

• Arayüz katmanı: özelliğin nerede durduğu, ne zaman göründüğü, çıktının nasıl kabul veya reddedildiği. Çıktının içeriğinden bağımsız olduğu için az kullanıcıyla test edilebilir.
• Çıktı katmanı: gerçek isteklerin ve üretilen cevapların kaydı, sonra bunların sabit bir ölçütle puanlanması. Bu bir kullanılabilirlik testi değil, sürekli çalışan bir kalite ölçümü.

Bir projede öneri katmanını ölçüm koymadan yayına almıştık; üç ay sonra kayıtlara baktığımızda kutuya neredeyse hiç dokunulmadığını gördük. Ölçüm en baştan orada olsaydı üç ay değil üç gün kaybederdik.

Kullanıcıya modelin adını değil işini söyle

"Bir milyon token'lık bağlam penceresi" cümlesi kullanıcıya hiçbir şey vaat etmiyor. "Yüz sayfalık sözleşmeyi tek seferde okur, sorduğun maddeyi kaynağıyla birlikte gösterir" cümlesi aynı özelliği anlatıyor ve içinde doğrulanabilir bir iddia taşıyor. İkinci cümleyi yazamıyorsan sorun anlatımda değil özelliktedir.

Çıktıyı geri alınabilir bırak

Model yanılır. Bu bir kusur değil, çalışma biçimi, ve arayüzün buna göre kurulması gerekiyor: uygulanan değişiklik tek adımda geri alınabilmeli, üretilen metin gönderilmeden önce düzenlenebilmeli, kullanıcı adına yapılan seçim görünür olmalı. Lightroom örneğinin rahatsız etmemesinin nedeni de bu; beğenmediğin sonucu geri alıp yeniden deniyorsun ve kaybettiğin tek şey birkaç saniye oluyor.