BT’yi yönettiğim yıllarda ekibin yapısı oldukça belirgindi: altyapı, ağ, sistem, veritabanı, uygulama, destek. Her yeni teknoloji bu yapıya bir uzmanlık ekliyordu; bulut geldiğinde bulut mimarı, güvenlik büyüdüğünde güvenlik uzmanı. Yapay zekâ bu kalıba tam uymuyor. Çünkü yapay zekâ projesi bir sistemi kurup bırakmakla bitmiyor; model sahada değişen veriyle sürekli bozuluyor ve sürekli bakım istiyor.
Bugün CX Teknoloji’de müşterilerimizin BT ekipleriyle birlikte çalışırken en sık gördüğüm sorun şu: şirket bir veri bilimci işe alıyor, bir pilot yapıyor, pilot iyi sonuç veriyor, sonra canlıya alma aşamasında proje duruyor. Çünkü eksik olan veri bilimci değildi.
Gerçekten gereken roller
| Rol | Ne yapar | Sık yapılan hata |
|---|---|---|
| Ürün sahibi | İş problemini tanımlar, başarı ölçütünü koyar, önceliklendirir | Bu rolün BT’de değil iş biriminde olması gerektiğini unutmak |
| Veri mühendisi | Veriyi toplar, temizler, veri hattını kurar ve izler | Bu işi veri bilimciye bırakmak |
| ML mühendisi / veri bilimci | Modeli geliştirir, dener, iyileştirir | Tek kişiden hem modeli hem altyapıyı beklemek |
| MLOps mühendisi | Modeli canlıya alır, izler, günceller, gerektiğinde geri alır | Bu rolü hiç tanımlamamak |
| Entegrasyon geliştiricisi | Modeli ERP, CRM, MES gibi sistemlere bağlar | Entegrasyonu projenin son haftasına bırakmak |
| Değerlendirme sorumlusu | Çıktının kalitesini ölçer, test setini korur, hata örneklerini toplar | Kaliteyi yalnızca pilot sonunda bir kez ölçmek |
Küçük ekiplerde bu roller birkaç kişide birleşebilir. Önemli olan her sorumluluğun birine ait olması. En kritik iki rol ürün sahibi ve MLOps; biri projenin başında, diğeri sonunda eksik kaldığında proje sahipsiz kalıyor. Canlıdaki modelin bozulmasıyla nasıl başa çıktığımızı tespit modellerini sahada ayakta tutmak yazımda anlattım; o işin her gün birinin masasında olması gerekiyor.
Mevcut ekip dönüşümün temeli
Yapay zekâ projeleri için dışarıdan bütün bir ekip almak hem pahalı hem yavaş. Daha önemlisi, dışarıdan gelen ekip şirketin sistemlerini, verisini ve süreçlerini tanımıyor. Mevcut BT ekibi ise tam olarak bunları biliyor. Doğru eğitimle:
- Sistem yöneticisi, GPU altyapısını, konteynerleri ve model servislemeyi işleten kişiye dönüşebilir. Docker ve Kubernetes ile GPU servislerini ölçekleme yazım bu geçiş için iyi bir başlangıç.
- Veritabanı uzmanı, veri hattının ve veri kalitesinin sahibi olabilir. ERP’nin verisini en iyi bilen kişi zaten o.
- Yazılımcı, entegrasyonu ve değerlendirme otomasyonunu üstlenebilir.
- Destek ekibi, kullanıcıdan gelen yanlış sonuç bildirimlerini toplayan ilk halka olabilir; bu bildirimler modelin iyileştirilmesi için en değerli veri.
Eğitim teorik bir kursla değil, gerçek bir proje üzerinde uygulamalı yapıldığında en hızlı sonucu veriyor.
Yapay zekâ ekibi nerede durmalı?
Sık gördüğüm bir model, yapay zekâ ekibini BT’den ayrı bir “inovasyon birimi” olarak kurmak. Bu model hızlı deneme için iyi; ama canlıya alma ve işletim aşamasında kopukluk yaratıyor. İnovasyon birimi pilotu bitirip BT’ye devretmek istiyor, BT tanımadığı bir sistemi işletmek istemiyor.
Daha sağlıklı yapı şu: yapay zekâ yetkinliği BT ile aynı yönetişim, değişiklik ve işletim süreçlerinin içinde olur; iş birimlerine ise her projenin ürün sahibi üzerinden bağlanır. Böylece deneme hızı korunurken canlıdaki sistem sahipsiz kalmaz. Yönetişim tarafını 90 günlük yol haritası yazımda COBIT ve ITIL ile eşleştirdim.
İçeride mi kurmalı, dışarıdan mı almalı?
Her yetkinliği içeride kurmak gerekmiyor. Şöyle bir ayrım işe yarıyor:
- İçeride kurun: Şirketin rekabet avantajını oluşturan alanlar; ürün sahipliği; veri sahipliği; canlı işletim ve değerlendirme.
- Ortaklıkla alın: Uzmanlık gerektiren ama rekabet avantajı olmayan alanlar; örneğin bir fabrikada görüntü işleme modelleri ya da özel bir donanım entegrasyonu.
Ortaklık kurarken iki şey içeride kalmalı: iş sahipliği ve öğrenilen bilgi. Tedarikçi gittiğinde verinin, modelin ve işletim bilgisinin şirkette kalması sözleşmeyle güvence altına alınmalı; bunu yapay zekâ tedarikçi sözleşmesi yazımda ayrıntılı ele aldım.
CIO için bir yıllık dönüşüm sırası
- İlk proje için iş biriminden bir ürün sahibi belirleyin; adı ve zamanı ayrılmış olsun.
- Mevcut ekipten bir veri mühendisi ve bir işletim sorumlusu seçin, gerçek proje üzerinde eğitin.
- Modeli geliştirme kısmını gerekirse bir ortakla yapın, ama işletimi baştan içeride kurun.
- Değerlendirme yöntemini ve test setini şirkette tutun; tedarikçi değişse de kalite ölçümü sürsün.
- İkinci projede ortaklığın payını azaltın, öğrenilen bilgiyi içeride çoğaltın.
Yapay zekâ ekibi kurmak, birkaç uzman işe almaktan çok, mevcut BT organizasyonunun nasıl çalıştığını değiştirmek. Bu değişiklik doğru yapıldığında yapay zekâ ayrı bir proje olmaktan çıkıp BT’nin sunduğu hizmetlerden biri hâline geliyor.
Sık sorulan sorular
Yapay zekâ projesi için hangi roller gerekir?
İş problemini sahiplenen ürün sahibi, veriyi toplayıp güvenilir hâle getiren veri mühendisi, modeli geliştiren makine öğrenmesi mühendisi ya da veri bilimci, modeli canlıda işleten MLOps mühendisi, sistemlere bağlayan entegrasyon geliştiricisi ve çıktının kalitesini ölçen değerlendirme sorumlusu. Küçük ekiplerde bu roller birkaç kişide birleşebilir.
Yapay zekâ ekibi BT'nin içinde mi kurulmalı, ayrı mı?
Ayrı bir inovasyon birimi hızlı deneme yapabilir, ama canlıya alma ve işletim aşamasında BT ile kopukluk en sık başarısızlık nedenidir. Daha sağlıklı yapı, yapay zekâ yetkinliğinin BT ile aynı yönetişim, değişiklik ve işletim süreçleri içinde olması, iş birimleriyle ise ürün sahibi üzerinden bağlanmasıdır.
Mevcut BT ekibi yapay zekâ projelerine nasıl hazırlanır?
Sistem yöneticileri GPU altyapısı, konteyner ve model servisleme; veritabanı uzmanları veri hattı ve veri kalitesi; yazılımcılar entegrasyon ve değerlendirme otomasyonu konusunda eğitilebilir. Eğitim, gerçek bir proje üzerinde uygulamalı yapıldığında en hızlı sonucu verir.
Yapay zekâ uzmanlığı içeride mi kurulmalı, dışarıdan mı alınmalı?
Şirketin rekabet avantajını oluşturan yetkinlikler içeride kurulmalıdır. Standart ya da uzmanlık gerektiren ama rekabet avantajı olmayan alanlarda ortaklık daha hızlıdır. Her durumda iş sahipliği, veri ve öğrenilen bilgi şirkette kalmalıdır.