Kurumsal Yapay Zeka Projeleri Neden Pilotta Kalıyor?

Kurumların yapay zeka ile ilk teması genellikle başarılıdır. Bir demo hazırlanır, seçilmiş örneklerde etkileyici sonuçlar verir, yönetim ikna olur. Sonra proje aylarca aynı yerde durur ve sessizce rafa kalkar.

Bu tablo o kadar yaygındır ki bir kalıp haline gelmiştir: pilot tuzağı. Sebebi neredeyse hiçbir zaman modelin yetersizliği değildir. Modeller iyidir. Eksik olan, o modelin etrafında kurulması gereken sistemdir.

Birinci sebep: demo ile üretim aynı problemi çözmez

Demo, kontrollü koşullarda çalışır. Girdi temizdir, uç durumlar elenmiştir, hata olduğunda kimse zarar görmez. Üretimde bunların üçü de geçerli değildir.

Üretimde girdi eksik, tutarsız ve beklenmedik biçimlerde gelir. Uç durumlar hacmin küçük bir yüzdesidir ama mutlak sayı olarak günde yüzlerce vakadır. Ve hata olduğunda birileri zarar görür: yanlış yönlendirilen bir müşteri, yanlış onaylanan bir işlem, yanlış hesaplanan bir tutar.

Bu yüzden "demo çalışıyor, artık ölçekleyelim" cümlesi yanıltıcıdır. Ölçeklenecek olan şey henüz kurulmamıştır.

İkinci sebep: başarı ölçütü tanımlanmamıştır

Pek çok yapay zeka projesi "doğruluk yüzde şu kadar" hedefiyle başlar. Bu, teknik bir metriktir ve tek başına iş kararı vermeye yetmez. Kritik olan soru şudur: hangi hata ne kadar pahalı?

Bir fatura sınıflandırma sisteminde yanlış kategori atamak düzeltilebilir bir hatadır. Aynı sistemde bir faturayı hiç görmemek ise mali bir risktir. İkisinin maliyeti aynı değildir, dolayısıyla model bu ikisi arasında bilinçli bir tercih yapacak şekilde ayarlanmalıdır.

Başarı ölçütü iş biriminden gelmelidir ve şu forma yakın olmalıdır: "Şu anda bu işi elle yapan üç kişi haftada on iki saat harcıyor; sistem bu süreyi yarıya indirir ve gözden kaçan vaka oranı yüzde biri geçmezse başarılıdır." Bu tanım hem ölçülebilir hem de üretime geçme kararını verilebilir kılar.

Üçüncü sebep: veri hazır değildir

Yapay zeka projelerinde harcanan zamanın büyük bölümü modelde değil veride geçer ve bu, kötü yönetim işareti değil, işin doğasıdır. Kurumların çoğunda veri şu üç sorundan en az birini taşır:

• Dağınıklık. Aynı bilgi üç farklı sistemde farklı biçimde tutulur ve hangisinin doğru olduğu tanımlı değildir.
• Etiket eksikliği. Geçmiş kararlar kayıt altında değildir. Sistem neyi doğru sayacağını öğrenemez, çünkü doğrunun ne olduğu hiçbir yerde yazmaz.
• Bağlam kaybı. Veri vardır ama neden o şekilde girildiği bilinmez. İstisnalar kural gibi görünür.

Bu sorunlar model seçimiyle çözülmez. Çözümleri sıkıcıdır: veri sözlüğü çıkarmak, tek doğru kaynağı belirlemek, geçmiş kararları örneklem üzerinden etiketlemek. Bu adımları atlayan projeler, atlamadıkları takdirde harcayacakları süreden daha fazlasını sonradan kaybeder.

Dördüncü sebep: sorumluluk sınırı çizilmemiştir

Bir sistem karar üretmeye başladığında kaçınılmaz bir soru doğar: bu kararın sorumlusu kim? Sınırı baştan çizilmemiş projeler, ilk ciddi hatada durur.

Pratikte işleyen model, kararları etkilerine göre üç kademeye ayırmaktır:

• Otomatik. Düşük etkili, geri alınabilir kararlar. Sistem uygular, insan sonradan örneklem üzerinden denetler.
• Onaylı. Orta etkili kararlar. Sistem önerir, yetkili kişi onaylar. Onay ekranı, öneriye gerekçe de gösterir.
• Yalnızca destek. Yüksek etkili kararlar. Sistem bilgi ve analiz sunar, kararı tamamen insan verir.

Bu kademelendirme aynı zamanda mevzuat açısından da gereklidir; kişisel veriye dayanan ve kişi üzerinde hukuki sonuç doğuran otomatik kararlar, KVKK kapsamında ayrı yükümlülükler üretir.

Beşinci sebep: entegrasyon sonraya bırakılmıştır

Bir yapay zeka bileşeni, ancak insanların zaten çalıştığı ekranın içinde işe yarar. Ayrı bir arayüzde duran, kullanıcının ek sekme açıp veri kopyalamasını gerektiren bir çözüm, teknik olarak kusursuz olsa bile kullanılmaz.

Bu yüzden "önce modeli bitirelim, entegrasyonu sonra düşünürüz" sırası yanlıştır. Doğru sıra, en baştan sınırlı bir kapsamda uçtan uca çalışan bir hat kurmaktır: veri girer, model çalışır, sonuç kullanıcının mevcut ekranında görünür, kullanıcının verdiği tepki kayda geçer. Bu hat kurulduktan sonra modeli iyileştirmek nispeten kolaydır.

Altıncı sebep: ekip yanlış kurulmuştur

Yapay zeka projeleri sıklıkla teknik bir ekibe devredilir ve iş birimi yalnızca gereksinim veren taraf olarak konumlanır. Bu kurgu, veriyi en iyi bilen kişileri sürecin dışında bırakır.

Üretime ulaşan projelerde tekrar eden bir ekip yapısı vardır:

• Süreç sahibi. İşi bugün fiilen yürüten kişi. Hangi istisnanın neden var olduğunu yalnızca o bilir ve bu bilgi hiçbir dokümanda yazmaz.
• Veri sorumlusu. Verinin nerede doğduğunu, hangi alanın ne zamandan beri güvenilir olduğunu bilen kişi.
• Geliştirme. Modeli ve etrafındaki hattı kuran ekip.
• Karar verici. Üretime geçiş kararını verebilecek yetkide, projeye düzenli zaman ayıran bir yönetici. Bu rol boşsa proje teknik olarak bitse bile açılamaz.

Dördüncü rolün eksikliği, pilotta kalan projelerin en sessiz ama en yaygın sebebidir. Teknik ekip işini bitirir, sonuç kimsenin gündeminde olmadığı için bekler ve zamanla güncelliğini yitirir.

Model seçimi ne zaman önemli hale gelir?

Projelerin başında en çok tartışılan konu genellikle hangi modelin kullanılacağıdır. Oysa bu, sıralamada geç gelmesi gereken bir karardır.

Erken aşamada belirleyici olan şey model değil, problemin doğru tanımlanmasıdır. Aynı işi yapan iki modelden hangisinin seçildiği, çıktı doğruluğunu birkaç puan değiştirir; problemin yanlış tanımlanması ise sonucu tamamen kullanılamaz kılar.

Model seçimi asıl olarak dört kısıt netleştikten sonra anlam kazanır: verinin kurum dışına çıkıp çıkamayacağı, yanıt süresinin ne olması gerektiği, birim işlem maliyeti ve çıktının açıklanabilir olma zorunluluğu. Bu dördü belirlendiğinde seçenek kümesi zaten belirgin biçimde daralır.

Model performansı zamanla neden düşer?

Üretime alınan bir sistemin ilk aydaki performansını koruyacağını varsaymak yaygın bir hatadır. Gerçek dünyada girdi dağılımı değişir: yeni ürünler eklenir, müşteri profili kayar, mevzuat farklı alanların doldurulmasını zorunlu kılar. Model aynı kalır ama beslendiği dünya değişir.

Bunun önüne geçmenin yolu, üretime alırken üç ölçümü de birlikte kurmaktır:

• Girdi izleme. Gelen verinin dağılımı eğitim verisinden ne kadar uzaklaştı?
• Çıktı izleme. Sistem kararlarının dağılımı zamanla kaydı mı?
• İnsan geri bildirimi. Onaylı kararlarda kullanıcı ne sıklıkla sistemin önerisini değiştiriyor? Bu oran, model kalitesinin en erken uyarı sinyalidir.

Üçüncü ölçüm çoğu zaman en ucuz ve en bilgilendirici olanıdır, çünkü zaten var olan onay ekranından bedelsiz toplanır.

Örnek: bir sınıflandırma hattı

Gelen belgeleri kategorilere ayıran bir sistem düşünelim. Pilot aşamasında yüzde doksan iki doğrulukla çalışıyor ve ekip bunu başarı sayıyor.

Üretim penceresinden bakıldığında tablo değişir. Günde bin belge geliyorsa, yüzde sekiz hata seksen belge demektir. Bu seksen belgenin ne olacağı tanımlanmadan sistem devreye alınamaz. Eğer yanlış kategori kolayca fark edilip düzeltilebiliyorsa, sistem otomatik çalışabilir. Eğer yanlış kategori belgeyi kimsenin bakmadığı bir kuyruğa düşürüyorsa, sistem ancak öneri modunda çalışabilir.

Aynı model, aynı doğruluk oranı; iki tamamen farklı devreye alma kararı. Farkı yaratan şey modelin kalitesi değil, hatanın süreç içindeki sonucudur. Pilot tuzağından çıkmak, tam olarak bu soruyu sormakla başlar.

Pilottan üretime geçiş için kontrol listesi

1. İş biriminden gelen, para veya zaman cinsinden ifade edilmiş bir başarı ölçütü var mı?
2. Hangi hatanın ne kadar pahalı olduğu tanımlandı mı?
3. Verinin tek doğru kaynağı belirlendi mi?
4. Kararlar otomatik / onaylı / destek olarak kademelendirildi mi?
5. Sonuç, kullanıcının hâlihazırda kullandığı ekranda görünüyor mu?
6. Kullanıcı geri bildirimi kayda geçiyor ve modeli iyileştirmek için kullanılabiliyor mu?
7. Model performansının zamanla düşmesi izleniyor mu?
8. Sistem devre dışı kaldığında sürecin nasıl yürüyeceği tanımlı mı?

Bu sekiz sorunun tamamına cevabı olan bir pilot, üretime geçebilir. Cevabı olmayan bir pilot, ne kadar etkileyici görünürse görünsün pilot olarak kalır.

Küçük başlamak neden daha hızlıdır?

Kurumsal yapay zeka projelerinde en yaygın stratejik hata, ilk projeyi en görünür ve en karmaşık sürece uygulamaya çalışmaktır. Görünürlük baskısı, öğrenme için gereken deneme alanını yok eder.

Daha verimli yol, düşük riskli ve ölçülebilir tek bir süreçle başlamaktır. Bu ilk proje kurum için asıl olarak bir öğrenme aracıdır: veri gerçekte ne kadar temiz, kullanıcılar nasıl tepki veriyor, hangi hata tipleri ortaya çıkıyor. Bu bilgiyle yapılan ikinci proje, ilkine göre belirgin biçimde hızlı ilerler.

YES.Tools olarak kurumlarla yürüttüğümüz yapay zeka çalışmalarında izlediğimiz sıra budur: önce ölçülebilir küçük bir hat, sonra o hattın öğrettikleriyle genişleme.

Sık sorulan sorular

Yapay zeka projesine başlamak için ne kadar veri gerekir?

Sabit bir sayı yoktur; belirleyici olan miktar değil etiket kalitesidir. Geçmiş kararların doğru/yanlış olarak kayıtlı olduğu birkaç bin örnek, etiketsiz milyonlarca kayıttan daha kullanışlıdır. Veriniz etiketsizse ilk adım model değil, örneklem üzerinden etiketleme çalışmasıdır.

Hazır bir yapay zeka servisi mi kullanmalı, kendi modelimizi mi eğitmeliyiz?

Karar dört kısıta bakar: verinin kurum dışına çıkıp çıkamayacağı, gereken yanıt süresi, birim işlem maliyeti ve çıktının açıklanabilir olma zorunluluğu. Bu dördü netleştiğinde seçenekler genellikle kendiliğinden daralır.

Pilot ne kadar sürmeli?

Pilotun süresi değil, bitiş ölçütü önemlidir. Başlarken "şu ölçüt sağlanırsa üretime geçeriz, sağlanmazsa durdururuz" tanımı yapılmamışsa pilot süresiz uzar. Ölçütü baştan yazmak, pilotun en kritik adımıdır.

Yapay zeka kararları KVKK açısından risk oluşturur mu?

Kişisel veriye dayanan ve kişi üzerinde hukuki sonuç doğuran tamamen otomatik kararlar ek yükümlülükler üretir. Kararları otomatik / onaylı / yalnızca destek olarak kademelendirmek, hem operasyonel hem hukuki riski yönetmenin en pratik yoludur.