Bir yapay zeka projesinin gerçekten çalıştığını nasıl ölçersiniz?
AI projelerini iş sonuçlarına göre değerlendirmek için pratik bir çerçeve - temel değerler, gerçek ölçütler, tam maliyetler ve lansman sonrası izlenmesi gerekenler.
Yapay Zeka Projelerini Ölçme
Çoğu yapay zeka (YZ) projesi bir demo ve alkışla sona erer. Azı ise belirli bir rakamla sonuçlanır. Altı ay sonra kimse projenin para tasarrufu sağladığını, müşteriler kazandığını ya da sadece bakım için başka bir araç eklediğini söyleyemez. Sorun genellikle teknoloji değil, başarı kriterlerinin önceden tanımlanmamasında yatmaktadır.
YZ projesini ölçmek karmaşık değildir. İşin başlamadan önce işin nasıl görünmesi gerektiğine karar vermeniz ve daha sonra bu hedefe göre kontrol etmeniz gerekir.
"Çalıştı" Demeden Kod Yazılmadan Önce Tanımlayın
YZ projesi, mevcut bir iş rakamınızı değiştirtiğinde çalışır; doğruluk, yanıt kalitesi veya soyut "benimseme" değil. Bir sayı: el ile yapılan çalışma saatleri azaltılanları, süreçten kesilen günleri, faturalandırmada hata oranlarını, her bir elemanın işlediği bilet başına maliyeti veya temsilci başına geliri içerir.
Projenin başlamadan önce bu rakamı ve hedefi yazın. "Sistem alıntı hazırlama süresini üç günden bir güne indirecek" iddiasını doğrulayabilirsiniz. "Sistem verimliliği artacak" iddiası ise yalnızca kabul edebileceğiniz bir iddia. Ekip projenin ilerlemesi için hangi rakamı belirtemiyorsa, proje finanse etmeye hazır değildir.
Temel Verileri Öncelikle Ölçün
Temel verileri kaydedilmemişse, ilerleme hakkında konuşmak imkansızdır. Sistem canlı hale gelmeden önce, süreç bugün nasıl performans gösterdiğini iki hafta boyunca ölçün: görevlerin ne kadar sürdüğünü, sık sık yanlış gittiğini, maliyetini ve kimlerin ona dokunduğunu kaydedin. Bu, görkemli olmayan bir iştir ve YZ benimseme sürecinde en çok atlanan adımdır.
Temel veriler mükemmel olmaya gerek duymaz. Güncel süreç için on örnek zamanlama, sıfırdan başlamaktan daha iyidir. Daha sonra elde edilen değer hakkında her konuşmada görüş ve görüşe dayanmak yerine, somut verilere dayanabilirsiniz.
Sonuçları Model Performansından Ayırın
Teknik ekipler teknik ölçümler raporlayacaktır; doğruluk, gecikme ve benchmark puanları bunlara dahildir. Bu ölçümler onlara önem verirken, sizin için çok önemli olmamalıdır. Bir model %95 doğru olabilir ama yine de proje olarak başarısız olabilir çünkü yanlış olduğu %5'lik kısım en önemli müşterilerinize denk gelir ya da personel sessizce Mart ayında onu kullanmayı bırakır.
Liderlik seviyesinde gözden geçirilmesi gereken ölçümler dört gruba ayrılır:
- Çıktı: İşin ölçülebilir şekilde daha hızlı, daha ucuz veya daha iyi olup olmadığı
- Benimseme: Gerçek iş hacminin sistem aracılığıyla ne kadar akıp gittiği ve bu payın artıp azaldığı
- İstisnalar: Bir insanın müdahale etmesi, düzeltmesi ya da geçersiz kılmasının ne sıklıkta olduğu ve bu durumun ne kadar nadir hale geldiği
- Güven: Sistemi kullananların onu kaybetmekten rahatsız olup olmadığı
Benimseme sayısı özel bir dikkat gerektirir. Eligibiliteye sahip vakaların %8'inde sistem kullanılmamışsa, ne doğruluk ne de gecikme süresi ne kadar iyi olursa olsun, proje başarısız olmuştur. Kullanım düşüşü, her zaman dürüst bir işaret verir ve şikayetler gelmeden çok önce ortaya çıkar.
Tüm Maliyetleri Hesaplayın
İnşaat maliyeti görünür parçadır. Gerçek toplam, devam eden maliyetleri içerir: abonelik ve hesaplama ücretleri, personelin çıktıları gözden geçirmesi için harcadığı zaman ve satıcı bir API'yi değiştirdiğinde ya da sistemin inşa edildiği süreçte değişiklik olduğunda bakım. Haftada yirmi saat tasarruf sağlayan ancak gözden geçirme ve bakımda on saat tüketen bir proje, gerçek getirisinin sadece yarısını sunar.
Lansmanın üç ve altı ay sonrası için bir inceleme planlayın ve tam işletme maliyetini ölçülen kazançla karşılaştırın. Başlangıçta marginal görünen birçok proje, altı ayda açıkça pozitif olurken, bazı projeler harika demo gösterilerine rağmen açıkça negatif olabilir. Hangi tür projeniz olduğunu bilmek için henüz zaman var, onu düzeltin ya da durdurun.
Çürüme Durumunu İzleyin
YZ sistemi bir köprü değildir; inşa edildikten sonra da kalmaz. Veriler, işler ve API'lerin arkasında yatan model değişir. Ocak'ta çalışan bir sistem, Temmuz'da sessizce çürüebilir ve çıktıları hala mantıklı görünmesi nedeniyle kimse fark etmeyebilir, müşteri bunu yapana kadar.
Çözüm basittir: bilinen doğru cevaplara sahip küçük bir vaka seti oluşturun ve sistemi aylık olarak bu vaka setinden geçirin. Sonuçlar değişirse, kendi kontrollerinizle değil, pazardaki değişikliklerle öğrenirsiniz. Bu sorumluluğu bir kişiye verin. Kimsenin fark etmediği çürüme, tespit edilmeyecektir.
Tek Sayfa Testi
YZ projesi başarılı olsaydı, bunu tek bir sayfada ifade edebilirsiniz: temel, hedef, ölçülen sonuç, tam maliyet ve lansmandan bu yana trend. Bu sayfa yazılamıyorsa dürüst sonuç projenin başarısız olduğu değil, kimsenin ne olduğunu söyleyemediği olabilir. Bu, iş için aynı anlama gelir.
Bu ölçüm disiplini çoğu ekip beklediğinden daha ağırdır, ancak taşıması gereken ağırlık budur - YZ'nin sadece iyi bir demo göstermesi değil, para kazanması arasında ayrım yapan şeydir. Ayrıca, bu benimseme disiplinini Hercules A'dan itibaren inşa eder, böylece "başarılı mıydı?" sorusunun cevabı her zaman bir rakamla olacaktır.