"Buraya Yapay Zekâ Koyalım" Demeden Önce Sorulacak Altı Soru

Son yıllarda hemen her sistem gereksinimi listesine bir madde eklendi: yapay zekâ tabanlı tespit, sınıflandırma, takip, otonom karar.

Bu talep çoğu zaman meşru. Görüntü işleme ve öğrenme tabanlı yöntemler, klasik yaklaşımların çözemediği problemleri gerçekten çözüyor.

Ama sahada gördüğüm şu: projelerin bir kısmında yapay zekâ bir çözüm olarak değil, tanımlanmamış bir problem olarak ekleniyor. Karar veriliyor, sonra ne yapacağı düşünülüyor.

Aşağıdaki altı soru, o kararı vermeden önce cevaplanırsa çok pahalı sürprizleri önlüyor. Hiçbiri teknik derinlik gerektirmiyor; hepsi program yöneticisinin sorabileceği sorular.

1. Veri nereden gelecek?

En temel ve en sık atlanan soru.

Öğrenme tabanlı bir sistem, üzerinde eğitildiği veriden daha iyi olamaz. Ve gerçek projelerde veri genellikle yoktur.

Alt sorular:

• Bu veri hâlihazırda mevcut mu, yoksa toplanacak mı?
• Toplanacaksa kim, nasıl, ne kadar sürede toplayacak? Bu bir iş paketi mi, yoksa "yaparız" mı?
• Etiketleme kim tarafından yapılacak? Etiketleme, veri toplamaktan pahalı olabilir ve uzman gerektirebilir.
• Verinin dağılımı, sistemin karşılaşacağı gerçek dağılıma benziyor mu?

Son madde en kritiği. Yaz aylarında, açık havada, belirli bir coğrafyada toplanmış veriyle eğitilen bir sistem; kışın, sisli havada, farklı bir arazide çalışmaz. Bu bir hata değil, öğrenme tabanlı sistemlerin doğasıdır.

Program yönetimi karşılığı: veri toplama ve etiketleme, ayrı bir iş paketi olarak, süresi ve bütçesiyle plana girmelidir. Girmemişse proje "model geliştirme" fazında değil, "veri bekleme" fazında olacaktır.

2. Kabul kriteri ne?

"Yüksek doğrulukla tespit edecektir" bir gereksinim değildir.

Cevaplanması gerekenler:

• Hangi metrik? Doğruluk, kesinlik, duyarlılık, F1, ortalama kesinlik?
• Hangi sayısal eşik?
• Hangi veri kümesi üzerinde? (Eğitim verisi üzerindeki başarı bir sonuç değildir.)
• Hangi koşullarda? Gündüz/gece, hava durumu, mesafe, açı.

Ve en önemlisi: hangi hata türü kabul edilebilir?

Yanlış pozitif ile yanlış negatifin maliyeti neredeyse hiçbir uygulamada eşit değildir. Bir tespit sisteminde bir hedefi kaçırmakla, olmayan bir hedefi bildirmek çok farklı sonuçlar doğurur. Sistemin çalışma noktası bu takasa göre seçilir ve bu, teknik değil operasyonel bir karardır. Kullanıcının vermesi gerekir.

Bunu şartnameye yazdırmayan proje, kabul aşamasında tanımsız bir tartışmaya girer.

3. Klasik yöntem gerçekten yetmiyor mu?

Bu soru sorulmadan geçilen çok proje gördüm.

Öğrenme tabanlı yaklaşımlar güçlüdür ama bedelleri vardır: veri ihtiyacı, doğrulama zorluğu, açıklanabilirlik problemi, hesaplama yükü.

Bazı problemler klasik görüntü işleme, eşikleme, şablon eşleştirme, sinyal işleme veya basit bir durum makinesiyle daha az riskle çözülür. Ve bu çözümler doğrulanabilir: davranışları deterministiktir, kalifikasyon dosyasına girmesi kolaydır.

Sorulacak soru: "Bu problemi klasik yöntemlerle çözmeyi denedik mi, yoksa doğrudan mı atladık?"

Cevap "denemedik" ise, önce denemenin maliyeti neredeyse her zaman düşüktür.

4. Nerede çalışacak? Hesaplama bütçesi ne?

Bir modelin masaüstü ekran kartında çalışması, gömülü bir platformda çalışacağı anlamına gelmez.

Alt sorular:

• Model gerçek zamanlı mı çalışacak? Kaç kare/saniye?
• Hangi donanımda? Güç bütçesi ne kadar?
• Isı problemi var mı? (Küçük bir hava aracında bu ciddi bir kısıttır.)
• Model sıkıştırma/nicemleme yapılacaksa, doğruluk kaybı kabul edilebilir mi?

Bu soruların geç sorulması, tipik bir başarısızlık senaryosu üretir: model geliştirilir, laboratuvarda mükemmel çalışır, hedef donanıma taşınınca ya sığmaz ya yeterince hızlı çalışmaz. O noktada ya donanım değişir (maliyet, ağırlık, güç) ya model küçültülür (doğruluk kaybı); ikisi de geç ve pahalı kararlardır.

Kural: hedef donanımda çalışabilirlik, model seçiminin girdisi olmalıdır; sonucu değil.

5. Nasıl doğrulanacak ve kalifiye edilecek?

Bu, savunma ve emniyet-kritik uygulamalarda en zor sorudur ve dürüst cevap şudur: standartlar bu konuda hâlâ olgunlaşıyor.

Klasik yazılımda doğrulama, kod yolunun izlenmesiyle yapılır. Öğrenme tabanlı bir modelde böyle bir yol yoktur; model, eğitim verisinden türemiş bir istatistiksel yaklaşımdır.

Bunun pratik sonuçları:

• Test kümesi, kalifikasyon kanıtının kendisidir. Nasıl seçildiği, ne kadar temsil ettiği ve eğitim verisinden tamamen ayrı olduğu belgelenmelidir.
• Kenar durum kataloğu gerekir. Sistemin zorlandığı koşullar açıkça listelenmeli ve performansı ayrıca raporlanmalıdır.
• Sınırların bilinmesi, sınırların olmamasından daha değerlidir. "Bu sistem şu koşullarda güvenilir değildir" cümlesi bir kusur itirafı değil, kalifikasyonun parçasıdır.
• İnsan denetimi mimarisi. Kritik uygulamalarda modelin çıktısının nihai karar mı yoksa öneri mi olduğu, mimari bir tercihtir ve baştan belirlenmelidir.

6. Kim bakacak?

Bir model teslim edilip bitmez.

• Saha koşulları değiştikçe performans düşer. Bu bir arıza değil, beklenen davranıştır.
• Yeniden eğitim gerekecektir. Kim yapacak, hangi veriyle, hangi sıklıkta?
• Yeni model versiyonu nasıl doğrulanacak ve sahaya nasıl gidecek?
• Konfigürasyon yönetimi: hangi araçta hangi model versiyonu çalışıyor?

Son madde savunma projelerinde özellikle önemli. Model versiyonu, tıpkı yazılım versiyonu gibi konfigürasyon kontrolü altında olmalıdır. Ve modeli üreten veri kümesinin versiyonu da öyle. Aynı kodla aynı veriyi kullanarak aynı modeli yeniden üretemiyorsanız, izlenebilirlik zinciriniz kopuktur.

Özet: karar öncesi kontrol listesi

• Veri var mı, yoksa toplama planı ve bütçesi var mı?
• Kabul kriteri sayısal, koşullu ve hata türü ayrımlı mı?
• Klasik yöntem denendi mi?
• Hedef donanımda çalışabilirlik doğrulandı mı?
• Doğrulama ve kalifikasyon yaklaşımı belli mi?
• Saha sonrası bakım ve yeniden eğitim planlandı mı?

Altısına da "evet" diyebiliyorsanız, yapay zekâ muhtemelen doğru karar.

Altısından biri boşsa, karar henüz verilmemiş demektir, sadece verilmiş gibi yapılıyor.

Kapanış

Bu yazı yapay zekâya karşı değil. Görüntü işleme ve öğrenme tabanlı otonomi, önümüzdeki dönemin en belirleyici yetenek alanı ve bu konuda geride kalmak seçenek değil.

İtirazım, teknolojinin kendisine değil, karar verilme biçimine. Bir teknoloji, çözdüğü problem tanımlanmadan seçildiğinde, ne kadar güçlü olduğu fark etmez.

Program yöneticisinin işi, o problemi tanımlatmak.

---

Bu yazıdaki görüşler şahsıma aittir, çalıştığım kurumları bağlamaz.