Özel Yapay Zekâ Modeli Nasıl Geliştirilir? Veriden Üretime Uçtan Uca Süreç

Özel yapay zekâ modeli geliştirmek, belirli bir iş problemine ait verilerden öğrenen bir sistemi tasarlamak, sınamak ve gerçek iş akışında çalışır hâle getirmektir. Süreç; veri toplama ve hazırlama, model seçimi, eğitim, doğrulama ve test, açıklanabilirlik, API, entegrasyon ve üretim takibinden oluşur. Modelin değeri, bu zincirin sonunda daha iyi bir karar alınabildiğinde ortaya çıkar.

Buradaki “özel”, mutlaka sıfırdan büyük bir dil modeli eğitmek anlamına gelmez. Şirketin sipariş verileriyle eğitilen bir gecikme tahmin modeli de özeldir. Bazı ihtiyaçlarda hazır bir modeli uyarlamak yeterlidir; bazılarında ise model eğitmeden, mevcut bir modele doğru kaynakları sunmak sorunu çözer.

Bu yazıda, bir dağıtım şirketinin gecikme riski taşıyan siparişleri önceden belirlemek istediği temsili bir senaryoyu izleyeceğiz. Amaç, operasyon ekibinin müdahale edeceği siparişleri seçmesine yardımcı olmak. Verilen örnekler bir müşteri projesinin sonuçları veya başarı iddiası değildir.

Şema 1. Üretimde öğrenilenler, bir sonraki veri ve model sürümünün girdisidir.

1. Önce modelin hangi karara yardım edeceğini belirleyin

“Gecikmeyi tahmin edelim” tek başına yeterli bir problem tanımı değildir. Tahmin sipariş açıldığında mı, sevkiyattan bir gün önce mi yapılacak? Gecikme, müşteriye ilk bildirilen teslim tarihine göre mi hesaplanacak? Riskli bulunan sipariş için kim, ne yapacak?

Bu örnekte tahmin anını siparişin onaylandığı an, hedefi ise ilk taahhüt edilen teslim tarihinin aşılması olarak belirleyelim. Operasyon ekibi de riskli siparişleri inceleyerek stok ve sevkiyat planını kontrol etsin. Böylece hem kullanılabilecek veriler hem de model çıktısının işlevi netleşir.

Başarı ölçütünü de burada koyun: Ekibin günlük inceleme kapasitesi içinde ne kadar gecikmeli sipariş yakalanabiliyor? Yanlış alarmın ve kaçırılan gecikmenin maliyeti nedir? Bu cevaplar, ileride karar eşiğini seçmek için gereklidir.

2. Veri toplama ve hazırlama: Tahmin anında ne biliyorduk?

Sipariş kayıtları, stok hareketleri, depo iş yükü ve teslimat sonuçları farklı sistemlerde bulunabilir. Bunları birleştirirken yalnızca ortak sipariş numarası yetmez; kayıtların hangi zamanda geçerli olduğunu da korumak gerekir.

Örneğin bugünkü stok durumunu altı ay önceki siparişe eklemek, geçmişi yanlış temsil eder. Siparişten sonra oluşan kargo şikâyetini girdi yapmak ise gelecekte öğrenilecek bilgiyi modele vermektir. Bu durum veri sızıntısı olarak adlandırılır: Testte başarılı görünen model, gerçek kullanımda erişemeyeceği ipuçlarından yararlanmıştır.

Hazırlık sırasında şu noktaları somutlaştırın:

• Kaynak, zaman damgası ve alan tanımları: “Teslim tarihi” planlanan tarih mi, gerçekleşen tarih mi?
• Etiket: İptal edilmiş veya henüz teslim edilmemiş siparişler nasıl ele alınacak? Sonucu bilinmeyen siparişleri “zamanında teslim” saymayın.
• Kalite: Tekrarlanan kayıtlar, eksik alanlar, farklı birimler ve yanlış eşleşmeler nasıl işlenecek?
• Kapsam: Sezonlar, depolar ve az görülen sipariş türleri yeterince temsil ediliyor mu?
• Erişim: Hangi alanlar gerçekten gerekli, kimler erişebilir ve ne kadar süre saklanacak?

Veriyi eğitim, doğrulama ve test için ayırdıktan sonra ölçekleme, eksik değer doldurma ve özellik seçimi gibi öğrenilen dönüşümleri yalnızca eğitim verisine uydurun. Aynı dönüşümleri diğer kümelere uygulayın. Bu ayrım, scikit-learn veri sızıntısı rehberinin temel önerilerindendir.

3. Model seçimi: En karmaşığı değil, ihtiyacı karşılayanı bulun

Önce basit bir referans çözüm, yani baseline kurun. Örneğin stok açığı bulunan siparişleri incelemeye almak, mevcut operasyon kuralı olabilir. Makine öğrenmesi modelinin bu kurala göre ne kazandırdığını ölçmeden karmaşıklığını gerekçelendirmek zordur.

Tablolar hâlindeki sipariş verilerinde lojistik regresyon ve ağaç tabanlı modeller makul adaylardır. Görüntü veya metin problemlerinde önceden eğitilmiş bir modeli uyarlamak değerlendirilebilir. Seçimi doğruluk kadar veri miktarı, gecikme süresi, çalışma maliyeti ve bakım kapasitesi belirler.

Dil modeli projelerinde iki yaklaşımı ayırmak gerekir: RAG, yanıt sırasında ilgili belgeleri bulup modele bağlam olarak verir; modelin ağırlıklarını değiştirmez. Fine-tuning, örneklerle modelin ağırlıklarını günceller. Güncel şirket belgelerinden kaynaklı yanıt üretme ihtiyacı ile belirli bir çıktı biçimini veya görev davranışını öğretme ihtiyacı aynı değildir. Hangi yaklaşımın yeterli olduğunu, gerçek görev örnekleriyle sınayın.

4. Eğitim: Tekrarlanabilir bir deney oluşturun

Eğitim, modelin girdiler ile hedef arasındaki örüntüleri öğrenmesidir. Fakat teslim edilecek şey yalnızca bir model dosyası değildir. Kullanılan veri sürümü, hazırlama kodu, özellik listesi, parametreler ve çalışma ortamı da kaydedilmelidir.

Örneğin depo yoğunluğunu hesaplayan kod değiştiğinde, model dosyası aynı kalsa bile tahmin değişebilir. Bu nedenle ön işleme adımlarıyla modeli birlikte sürümleyin. Deney kayıtları, “Bu sonuç hangi veri ve kodla elde edildi?” sorusunu cevaplamalıdır.

Hiperparametreleri doğrulama verisiyle seçin. Eğitim sonucunu iyileştirmek için modelin karmaşıklığını artırırken doğrulama başarısı düşüyorsa, model geçmiş örnekleri fazla öğreniyor olabilir. Daha fazla eğitim her zaman daha iyi genelleme sağlamaz.

5. Validation ve test: Gelecekteki kullanımı taklit edin

Eğitim kümesi öğrenmek, doğrulama kümesi (validation) model ve karar eşiği seçmek, test kümesi ise seçimler tamamlandıktan sonra bağımsız değerlendirme yapmak içindir. Test sonucuna bakıp sürekli ayar değiştirirseniz o küme artık tarafsız bir son kontrol olmaktan çıkar.

Gecikme örneğinde geçmişten geleceğe doğru zaman bazlı ayırma, rastgele ayırmadan daha gerçekçi olabilir. Değerlendirme tarihinde eğitim etiketlerinin gerçekten oluşmuş olması da gerekir. Aynı siparişin satırlarını farklı kümelere dağıtmayın. Hedef yeni müşterilerde çalışmaksa müşteri bazlı ayrımı da ayrıca değerlendirin.

Siparişlerin yalnızca %5'inin geciktiği varsayımsal bir veri kümesinde her siparişe “gecikmez” diyen model %95 doğruluk elde eder; geciken tek bir siparişi bile yakalayamaz. Bu yüzden şu ölçümleri birlikte okuyun:

• Precision (kesinlik): Riskli işaretlenen siparişlerin ne kadarı gerçekten gecikmiş?
• Recall (duyarlılık): Gerçek gecikmelerin ne kadarı önceden yakalanmış?
• İnceleme yükü: Seçilen eşik, operasyon ekibine günde kaç sipariş gönderiyor?

Precision ve recall arasındaki değiş tokuş, scikit-learn precision-recall açıklamasında örneklenir. Eşiği otomatik olarak 0,5 almak yerine iş maliyetine ve kapasiteye göre doğrulama kümesinde seçin. Depo, sezon ve sipariş türü bazında sonuçları da inceleyin; genel ortalama sorunlu bir alt grubu gizleyebilir.

6. Explainability: Tahminin dayanağını görünür kılın

Açıklanabilirlik, modelin hangi girdilerden nasıl etkilendiğini incelemektir. Genel düzeyde modelin neye dayandığını, tek sipariş düzeyinde ise belirli bir tahmini hangi özelliklerin etkilediğini anlamaya yardımcı olur.

SHAP gibi yöntemlerle stok açığının veya depo yoğunluğunun tahmine katkısı incelenebilir. Ancak bir özelliğin tahmine katkısı, gecikmenin nedenini kanıtlamaz. “Model bu bilgiyi kullanıyor” ile “Bu alanı değiştirirsek gecikmeyi önleriz” farklı iddialardır. Bu sınır, SHAP'in nedensellik açıklamasında özellikle ele alınır.

Operasyon ekranında açıklamayı eylemle bağlayın: “Stok açığı ve depo yoğunluğu skoru yükseltiyor; sevkiyat planını kontrol edin.” Ayrıca bir skoru olasılık diye sunmadan önce kalibrasyonunu değerlendirin. Modelin 0,8 üretmesi, benzer vakaların gerçekten %80'inin gecikeceğini tek başına göstermez.

7. API: Modeli tanımlı bir hizmete dönüştürün

Çevrim içi tahmin gerekiyorsa modeli bir API üzerinden sunabilirsiniz. İstek sözleşmesi; alan adlarını, türlerini, birimleri, zorunlu alanları ve geçersiz girdilerdeki davranışı tanımlamalıdır. Eğitimdeki ön işleme ile API içindeki ön işleme aynı olmalıdır.

Yanıtta tahminle birlikte model sürümü, istek kimliği ve tahmin zamanı bulunsun. Eksik veri yüzünden tahmin üretilemediğinde bunu açıkça belirtin; “düşük risk” döndürmek operasyonu yanlış yönlendirir. Kimlik doğrulama, yetki denetimi, istek boyutu sınırı, zaman aşımı ve hassas veri içermeyen günlükler de hizmetin parçasıdır.

Her problem anlık API çağrısı gerektirmez. Operasyon yalnızca sabah bir liste kullanacaksa toplu tahmin işi daha uygun olabilir. Mimariyi kararın ne zaman alınacağı belirler.

Şema 2. Tahmin, karar kuralı ve insan müdahalesi ayrı sorumluluklardır.

8. Mevcut sisteme entegrasyon: Skorun ardından ne olacak?

ERP'ye bir risk alanı eklemek entegrasyonun başlangıcıdır. Riskli siparişi kimin göreceği, inceleme durumunun nasıl tutulacağı ve API yanıt vermediğinde akışın nasıl devam edeceği de tasarlanmalıdır.

İlk aşamada modeli gölge modunda çalıştırabilirsiniz: Gerçek siparişlere tahmin üretir, fakat iş akışını değiştirmez. Veri erişimi ve yanıt süreleri doğrulandıktan sonra sınırlı bir kullanıcı veya depo grubunda kullanıma geçilir. Önceki sürüme dönüş yolu hazır tutulur.

Tahminin bir iş emri açtığı durumda tekrar gönderilen isteğin ikinci bir iş emri oluşturmaması gerekir. Model çıktısı ile iş kuralını da ayırın: Risk skoru modelden, hangi skorun incelemeye alınacağı operasyon politikasından gelir.

9. Monitoring: Servis çalışıyor, peki model hâlâ işe yarıyor mu?

Üretim takibinde üç ayrı soruyu cevaplayın: Hizmet erişilebilir mi? Gelen veri değişti mi? Tahminler hâlâ faydalı mı? Hata oranı ve yanıt süresi ilkini; eksik alanlar ve veri dağılımı ikincisini; gerçekleşen sonuçlarla karşılaştırılan tahminler üçüncüsünü gösterir.

Veri dağılımının değişmesi data drift olarak adlandırılır. Veri ile hedef arasındaki ilişkinin değişmesi ise concept drift olabilir. Bir drift alarmı tek başına başarı düşüşünü kanıtlamaz; sorunun veri hattından mı, iş koşullarından mı kaynaklandığı incelenmelidir.

Gecikme etiketleri ancak teslimat sonucu belli olduğunda oluşur. Tahminleri bu sonuçlarla sonradan eşleştirin. Operasyon modelin uyarısıyla müdahale ettiyse bunu da kaydedin: Müdahaleyle önlenen gecikme, değerlendirmede kolayca “yanlış alarm” gibi görünebilir. Model başarısı ve müdahalenin etkisini ayrı incelemek gerekir.

İzleme, veri doğrulama ve kontrollü yeniden eğitim döngüsü, Google Cloud'un MLOps rehberinde anlatılan üretim yaklaşımının parçalarıdır. Alarm geldiğinde otomatik olarak yeni modeli yayınlamak yerine sorumluyu, inceleme adımını ve yeniden değerlendirme koşulunu belirleyin.

Üretime hazır olduğumuzu nasıl anlarız?

İlk sürüm; basit referans çözümle karşılaştırılmış, bağımsız testten geçmiş, hata durumları denenmiş ve gerçek sonuçları izlenebilir olmalıdır. Kullanıcı model önerisini anlayabilmeli; ekip hangi sürümün çalıştığını ve sorun çıktığında nasıl geri döneceğini bilmelidir.

Özel model geliştirmenin en değerli çıktısı, yüksek bir test skorundan daha kapsamlıdır: Hangi veriye dayanarak hangi kararı desteklediği bilinen, yanlış yaptığında fark edilen ve düzeltilebilen bir sistem.