İnsan Müdahalesi Oranı: yapay zeka devreye alımınızın gerçekten işe yarayıp yaramadığını söyleyen tek metrik
Üretimde yapay zeka ajanı çalıştıran çoğu şirket, bu ajanların bir insana ne sıklıkta ihtiyaç duyduğunu söyleyemez. İnsan Müdahalesi Oranı bu soruyu yanıtlayan sayıdır — ve bu yazının sonunda, hâlihazırda yürüttüğünüz bir iş akışı için onu hesaplayabilmelisiniz.
FabricLoop’un yapay zeka örgütleri için kendi çerçevesi, İnsan Müdahalesi Oranı’nı açıkça tanımlar: otomatik işin bir insana ne sıklıkta ihtiyaç duyduğunu sorar. Tanım budur ve bu yazı ondan sapmaz. Bundan sonrası, kavram sayfasının tam olarak yazmadığı kısımdır: gerçek aritmetik, tek bir gerçek iş akışına uygulanmış, fikri dilekten çıkarıp somutlaştıran sayılarla.
Sayının gerçekte neyi ölçtüğü
İnsan Müdahalesi Oranı (İMO), bir ajanın, tek bir tanımlanmış iş akışı ve tek bir dönem içinde yaptığı eylemlerden, sonuç bitmiş sayılmadan önce bir insanın devreye girmesini gerektirenlerin payıdır. Burada «devreye girmek» belirli bir anlama gelir: bir kişi çıktıyı düzeltti, ajanın verdiği bir kararı geçersiz kıldı ya da ajan devam etmeden önce açıkça sorduğu bir soruyu yanıtladı — FabricLoop’un Loop Agent’ının ask_human anı dediği şey. Bu eylemlerin sayısını, ajanın aynı dönemde yaptığı toplam eylem sayısına bölün; İMO budur.
Bu metriğin çalışma süresi ve doğruluğun altında değil yanında durmasının nedeni, o sayıların göremediği bir şeyi ölçmesidir. Bir ajan dahili bir benchmark’ta %95 doğruluk yazıp, yanlış yaptığı %5 sessizce geçerken emin olmadığı %20 her seferinde işaretleniyorsa, %80 puan alan bir devreye alımdan daha kötü olabilir. İMO ajanın iyi olup olmadığını sormaz. Sistemin ne zaman bir insana ihtiyaç duyduğunu bilip bilmediğini ve o anda bir insanın gerçekten gelip gelmediğini sorar. Bir devreye alımın genişletilmesinin güvenli olup olmadığını belirleyen ikinci sorudur.
İMO’yu tek bir gerçek iş akışı için hesaplamak
Bir BT ya da operasyon ekibinin bugün gerçekten yürütebileceği bir iş akışını alın: gelen destek taleplerini önceliklendiren, sınıflandıran (faturalama, hata bildirimi, iade, hesap erişimi ve benzeri) ve ilk yanıt taslağını yazan bir ajan. Her taslak müşteriye ulaşmadan önce bir inceleme kuyruğuna düşer — hiçbir şey kendi kendine gitmez. Bu inceleme adımı tek başına müdahale değildir. Değişiklik gerekmeyen bir taslakta inceleyenin «gönder»e basması, iş akışının tasarlandığı gibi çalışmasıdır. Müdahale, taslağın iş gerektirmesidir: inceleyen yeniden yazdı, sınıflandırmayı düzeltti, talebi başka bir kuyruğa yönlendirdi ya da ajanın kendisi görev ortasında durup bir şey yazmadan önce soru sordu.
Aşağıdaki sayılar gerçek bir şirketin verisi değil, açıklayıcı bir örnektir — ama hikâyenin biçimi ve arkasındaki aritmetik, kendi kayıtlarınızdan kuracağınız şeyin ta kendisidir.
Pilot ayda ajan 640 talebe dokunur. Bunların 415’i müdahale ister — yeniden yazım, yeniden sınıflandırma ya da yeniden yönlendirme — ve bu 415’in yalnızca 75’i, ajanın bir şey yazmadan önce kendisinin işaretlediği anlardır. Gerisi, inceleyenin sonradan yakaladığı hatalardır. Bu, %64,8 İMO ve yalnızca %18 eskalasyon payıdır: ajan, yanıldığı zamanların çoğunda kendinden emin biçimde yanılır; bu sorunun en kötü hâlidir.
Ekip düzeltme kaydını çeker ve her müdahaleye bir neden etiketler. İki kategori baskındır: tutar geçtiği anda ajan iade politikasını yanlış okur ve görünür biçimde öfkeli müşterilere sakin, prosedürel yanıtlar yazar. İkisi de modele dokunmadan düzeltilebilir — $50 üzerindeki bir iadeden söz eden ya da bir duygu eşiğinin üstüne çıkan her talebin taslak yerine ask_human eskalasyonu tetiklemesi için açık bir kural ekleyin. Geri kalan her şey eskisi gibi taslaklanır ve incelenir.
| Ay | İşlenen talep | Müdahale | İMO | Eskalasyon payı |
|---|---|---|---|---|
| 1 — Pilot | 640 | 415 | %64,8 | %18 |
| 2 — Kurallar eklendikten sonra | 810 | 224 | %27,7 | %58 |
| 3 — Kurallar yeniden ayarlandı | 940 | 101 | %10,7 | %79 |
Üçüncü aya gelindiğinde İMO %80’den fazla düşmüştür, ama daha bilgi veren sayı eskalasyon payıdır: %18’den %79’a çıkmıştır. Kalanın çoğu, ajanın yanlışken yakalanması değildir — gerçekten belirsiz bir durumu (bir VIP hesap, bir politika istisnası, tam eşiğe denk gelen bir iade) doğru tanıyıp harekete geçmeden önce sormasıdır. Düşüş gerçektir ve hak edilmiştir: her düzeltme turu açık kurallara geri beslendi, böylece onları üreten belirli hatalar yinelenmeyi bıraktı; hâlâ yargı gerektiren kategoriler ise etrafından taslakla dolaşılmak yerine işaretlenmeye devam etti.
Önemli olan düşüş, ajanın bilmediğini daha iyi bildiği düşüştür — birinin sessizce kontrol etmeyi bıraktığı düşüş değil.
Hata: sıfırı hedef sanmak
Bir ekip İMO’nun ay ay düştüğünü izlemeye başlayınca sıradaki bariz soru, ne kadar aşağı inebileceğidir. İçgüdü, sıfırı bitiş çizgisi saymaktır — ajanın nihayet denetimsiz çalışacak kadar iyi olduğunun kanıtı. Bu içgüdü terstir ve bu metriğin en yaygın yanlış okunuşudur.
Haftalarca %0 müdahale gösteren bir iş akışı, neredeyse hiçbir zaman ajanın hata yapmayı bıraktığı anlamına gelmez. Bunun yerine iki şeyden biri olmuştur: inceleyenler onaylamadan önce taslakları gerçekten okumayı bırakmıştır ya da eskalasyon yolu sessizce bozulmuştur — eşikler gevşetilmiş, bir yönlendirme kuralı sessizce başarısız olmuş ya da ask_human tetikleyicisi ateşlemeyi kesmiştir. Her iki durumda da sıfır, sistemin artık insana ihtiyaç duymadığını söylemez. Bir insana artık sorulmadığını ya da kimsenin artık bakmadığını söyler.
Asıl hedef hiçbir zaman soyut olarak daha az müdahale olmadı. İnsanın yargısını gerektiren belirli anların — ve yalnızca o anların — yüzeye çıktığı, böylece dikkatin her şeye eşit bölünmek ya da tamamen kaybolmak yerine gerçekten gereken yere gittiği bir sistemdir. %12 İMO’da duran ve bu %12’nin neredeyse tamamı ajanın gerçekten belirsiz ya da yüksek riskli vakaları doğru işaretlemesi olan bir akış, %2’de duran ve bu %2’nin çoğu inceleyenin ajanın hiç işaretlemediği bir hataya rastlaması olan akıştan daha sağlıklıdır. Daha düşük sayı, daha kötü sistemi gizleyebilir.
Eskalasyon payı tam olarak bunun içindir. İMO’nun yanında izlendiğinde hangi hikâyede olduğunuzu söyler:
İMO düşerken eskalasyon payı düz kalıyor ya da o da düşüyorsa, bunu henüz kazanım diye kaydetmeyin. «Müdahale gerekmedi» diye kaydedilen eylemlerden rastgele bir örnek çekin ve birinin, örneğin temiz işaretlendiğini söylemeden, soğukkanlılıkla incelemesini isteyin. Aşağı akış sinyallerinin — yeniden açılan talepler, şikâyetler, iade geri almaları, CSAT — aynı anda yukarı kayıp kaymadığına bakın. Düşen bir İMO ile yükselen aşağı akış sorunları, daha hızlı öğrenmiş bir sistem değildir. Zamanında yakalanmamış bir sistemdir.
Bunu bugün ölçmek istiyorsanız neyi kaydetmelisiniz
Bunların hiçbiri yeni araçtan çok, doğru şeyi kaydetmeyi gerektirir. Ajan çalıştıran çoğu ekip hacmi zaten izler — kaç talebe dokunduğunu, kaç görev taslağı yazdığını. Neredeyse hiçbiri sonucu izlemez; İMO’nun gerçekten ihtiyaç duyduğu tek şey de budur.
- Her eylem için bir sonuç kaydedin, yalnızca bir etkinlik sayacı değil. Olduğu gibi gönderildi, göndermeden önce düzenlendi, reddedilip yeniden yazıldı ya da ajanın kendisi tarafından eskalasyon edildi. Sonuç düzeyinde kayıt yoksa İMO hiç hesaplanamaz — ajanın bir şey yaptığını bilirsiniz, düzeltilmesi gerekip gerekmediğini değil.
- Payı düzeltmeden önce paydayı sabitleyin. Bu iş akışı için bir eylemin ne sayılacağına karar verin — dokunulan bir talep, taslaklanan bir görev — ve dönemler arasında bu tanımı sabit tutun; böylece İMO’daki değişim, sayma biçiminizdeki bir değişikliği değil, ajanın yargısını yansıtsın.
- Her müdahaleyi bir nedenle etiketleyin. «Düzenlendi» neredeyse hiçbir şey söylemez. «Düzenlendi: $50 üzerindeki iade politikası yanlış uygulandı» sırada neyi düzelteceğinizi tam olarak söyler. Kısa, tutarlı bir sınıflandırma, düzeltme kaydını skor tabelası olmaktan çıkarıp iş listesine çevirir.
- Eskalasyon payını İMO’nun yerine değil, yanında izleyin. İki sayı birlikte, bir düşüşün hak edilmiş mi yoksa ödünç mü olduğunu söyler — yukarıdaki eğilim tablosuna bakın.
- Sıfır hedefi değil, bir taban koyun. İş akışı başına, içindeki gerçek belirsizliğe göre makul ve sıfır olmayan bir İMO’nun neye benzediğine karar verin ve bu tabanın belirgin biçimde altına düşen bir oranı kutlanacak bir şey değil, araştırılacak bir şey olarak görün.
- İMO’yu iş akışı başına raporlayın, tek bir şirket geneli karışık sayı olarak asla. Tek bir ortalama, hangi akışın gerçekten daha az gözetimi hak ettiğini ve hangisinin iyi görünen bir manşet sayının altında sessizce risk biriktirdiğini gizler.
- «Temiz» örneği bir takvimle yeniden kontrol edin. Müdahale gerekmedi diye kaydedilen eylemleri belirli aralıklarla çekin ve birinin, temiz işaretlendiklerini bilmeden incelemesini isteyin. İnceleyenlerin hâlâ okuyup okumadığının tek doğrudan kontrolü budur.
Loop Agent bu yüzden sessiz özerklik yerine ask_human, devam ettirme ve kanal uygulaması üzerinden eskalasyon etrafında kuruludur — sormak için duran bir ajan, İMO payına bilerek düşer; kazara yakalanan bir ajan değildir. Eskalasyonlar ve taslaklar, ekibin zaten çalıştığı Groups içinde, görevlerin ve notların yanında belirir; böylece insana ihtiyaç duyan an, kimsenin bakmadığı ayrı bir ajan konsolunda gömülü değil, işin zaten yaşadığı yerde görünür. Enterprise’ta denetim kayıtları, BT ve operasyonun ajanların ne yaptığını ve bir insanın tam olarak ne zaman devreye girdiğini görmesini sağlar; İMO’nun en baştan kurulduğu hammadde budur.
Bunu, yetki ve erişimin de görünür olmasını sağlayan eşlikçi kavram Okunabilirlik ile eşleyin; her yapay zeka devreye alımının genişlemeden önce yanıtlayabilmesi gereken iki soruyu elde edersiniz: bir ajanın ne yaptığını kim görebilir ve bir insanın ne sıklıkta gerçekten devreye girmesi gerekir.