Model Monitoring, Drift ve Feedback Loop Tasarımı: Üretimde AI Sistemleri Nasıl Ayakta Kalır?

Bir yapay zekâ modelini üretime almak çoğu ekip için büyük bir eşiktir. Ancak gerçek dünyada asıl zorluk, modeli canlıya çıkarmakta değil; onu canlıda doğru, tutarlı, güvenilir ve sürdürülebilir biçimde çalıştırmakta başlar. Çünkü üretim ortamındaki AI sistemleri statik değildir. Veri değişir, kullanıcı davranışı değişir, iş süreçleri evrilir, dış dünya dönüşür ve modelin bir zamanlar başarılı olduğu dağılım zamanla anlamını yitirebilir.

Bu nedenle üretimde AI başarısı, yalnızca başlangıçtaki model metrikleriyle değil; zaman içinde kaliteyi koruma kapasitesiyle ölçülmelidir. İşte bu noktada model monitoring, drift analizi ve feedback loop tasarımı kritik hale gelir.

Birçok organizasyon model izlemeyi hâlâ yüzeysel bir sağlık kontrolü gibi ele alır. Sistem cevap veriyorsa veya servis ayaktaysa her şey yolunda sanılır. Oysa gerçek risk çoğu zaman sessizdir. Model teknik olarak çalışıyor olabilir; fakat belirli segmentlerde zayıflamış, bazı veri alanlarında bozulmuş, tahmin dağılımı kaymış veya iş çıktısına katkısı görünmez şekilde düşmüş olabilir. Üstelik bu bozulmalar çoğu zaman kullanıcı şikâyeti artana veya gelir/operasyon etkisi hissedilene kadar fark edilmez.

Bu yazıda, üretimde AI sistemlerinin neden zamanla zayıfladığını, model monitoring katmanının nasıl kurulması gerektiğini, drift türlerini nasıl ayırt edeceğimizi ve güçlü bir feedback loop mimarisinin nasıl tasarlanacağını kapsamlı biçimde ele alacağım.

Model monitoring, üretimde çalışan bir yapay zekâ sisteminin davranışını, performansını, veri kalitesini, çıktı kalitesini, operasyonel sağlığını ve iş etkisini düzenli olarak izleme disiplinidir. Bu tanım özellikle önemlidir; çünkü model monitoring yalnızca modelin accuracy veya error rate değerine bakmaktan ibaret değildir. Gerçekte izlenmesi gereken şey, modelin etrafındaki tüm üretim sistemi ve bu sistemin zaman içindeki davranışıdır.

Olgun bir monitoring yaklaşımı şu sorulara cevap verir:

• Model şu anda beklenen hacimde ve hızda çalışıyor mu?
• Üretime gelen verinin dağılımı eğitim döneminden sapıyor mu?
• Tahminlerin dağılımında alışılmadık bir kayma var mı?
• Gerçek etiket geldikçe performans düşüşü görünüyor mu?
• Belirli müşteri gruplarında veya kullanım segmentlerinde kalite bozuluyor mu?
• İş metriği açısından sistem hâlâ değer üretiyor mu?
• Bir bozulma varsa bunun kaynağı veri mi, model mi, süreç mi, kullanıcı davranışı mı?

Kısacası model monitoring, modelin hayatta olup olmadığını değil; sağlıklı yaşayıp yaşamadığını anlamaya çalışır.

AI sistemlerinin doğasında zamanla bozulma riski vardır. Çünkü model, geçmişten öğrenilmiş bir fonksiyondur; ancak üretimde gelecek ile karşı karşıya kalır. Gelecek ise nadiren geçmişin birebir tekrarıdır.

Bu bozulmanın temel nedenleri genellikle şunlardır:

• Kaynak verilerin yapısının değişmesi
• Kullanıcı davranışlarının evrilmesi
• İş kurallarının değişmesi
• Yeni ürün, kampanya veya süreçlerin devreye girmesi
• Üst sistemlerden gelen veri formatı bozulmaları
• Ekonomik, mevsimsel veya sosyolojik dış etkenler
• Hedef değişkenin anlamının zamanla kayması

Bir modelin üretimde bozulması çoğu zaman tek bir büyük kırılmayla değil; küçük ama sürekli sapmaların birikmesiyle gerçekleşir. Bu yüzden monitoring yaklaşımı yalnızca “büyük arıza” odaklı değil; “yavaş kalite erozyonu” odaklı da olmalıdır.

"

Kritik gerçek: Üretimde en tehlikeli AI sistemi, tamamen çöken değil; sessizce zayıflayan sistemdir.

İyi bir monitoring mimarisi tek boyutlu değildir. Sadece servis metriklerini izlemek de, sadece model doğruluğuna bakmak da yeterli olmaz. Üretim sınıfında monitoring en az beş temel katmandan oluşmalıdır.

1. Operasyonel Monitoring

Bu katman sistemin teknik olarak ayakta olup olmadığını ve servis kalitesini takip eder. Burada bakılan metrikler genellikle şunlardır:

• Latency
• Throughput
• Error rate
• Timeout oranı
• Queue length
• Service availability
• Resource utilization

Bu metrikler kritik önemdedir; ancak tek başına yeterli değildir. Çünkü sistem hızlı cevap veriyor olabilir ama yanlış veya düşük kaliteli cevaplar üretiyor olabilir.

2. Veri Monitoring

Veri monitoring, üretime gelen girdilerin beklenen yapıda, kapsamda ve dağılımda olup olmadığını izler. Bu katmanda genellikle şu başlıklar takip edilir:

• Eksik değer oranları
• Beklenmeyen kategori sayısı
• Outlier artışı
• Dağılım kayması
• Schema değişimleri
• Feature correlation kaymaları
• Segment dağılım farklılıkları

Veri katmanındaki bozulmalar, model performansının en sık kaynağıdır. Üstelik bu bozulmalar çoğu zaman uygulama loglarında doğrudan görünmez.

3. Tahmin ve Çıktı Monitoring

Modelin ürettiği skorlar, sınıf dağılımları, confidence pattern’leri veya cevap tipleri zamanla değişebilir. Bu değişim tek başına kötü olmak zorunda değildir; fakat beklenmedik kaymalar erken alarm sinyali olabilir.

Örnekler:

• Bir sınıflandırma modelinin pozitif tahmin oranının aniden artması
• Risk skorlarının belirli aralıklarda yoğunlaşması
• LLM sistemlerinde çok daha uzun veya çok daha kısa yanıtlar
• Belirli kalıp cevapların artması
• Model confidence seviyelerinin olağandışı düşmesi

4. Kalite Monitoring

Burada asıl soru şudur: Model gerçekten doğru mu çalışıyor? Ancak bu sorunun yanıtı her zaman anlık olarak elde edilemez. Çünkü birçok sistemde gerçek etiketler gecikmeli gelir. Bu nedenle kalite monitoring iki seviyede düşünülmelidir:

• Doğrudan kalite: Etiket geldikten sonra hesaplanan accuracy, precision, recall, MAE, task success gibi metrikler
• Dolaylı kalite sinyalleri: İnsan geri bildirimi, manuel düzeltme oranı, kullanıcı memnuniyetsizliği, downstream hata artışı

5. İş Etkisi Monitoring

En kritik ama en az kurulan katman çoğu zaman budur. Bir model teknik olarak başarılı görünebilir ama iş etkisi düşmüş olabilir. Bu nedenle model monitoring iş hedeflerinden kopuk olmamalıdır.

Örnek iş metrikleri:

• Dönüşüm oranı
• Operasyon süresindeki azalma
• İnsan müdahalesi gereksinimi
• Hata oranı düşüşü
• Gelir katkısı
• Çağrı çözümleme süresi
• Destek ticket çözüm başarısı

Drift, en basit anlamıyla, modelin eğitim dönemindeki koşulları ile üretimde karşılaştığı koşullar arasındaki farkın zamanla büyümesidir. Ancak drift tek bir tip değildir. Üretimde doğru teşhis koyabilmek için drift’in farklı türlerini birbirinden ayırmak gerekir.

1. Data Drift

Data drift, üretim verisinin dağılımının eğitim veya referans dağılımdan sapmasıdır. Örneğin yaş, gelir, cihaz tipi, başvuru yoğunluğu, işlem tutarı veya kullanıcı davranışı dağılımlarının değişmesi buna örnek olabilir.

Bu durumda model hâlâ teknik olarak aynı fonksiyonu uyguluyordur; ancak artık tanımadığı veya yeterince temsil edilmemiş bir veri alanında çalışıyor olabilir.

2. Concept Drift

Concept drift, girdiler ile hedef arasındaki ilişkinin değişmesidir. Bu daha derin bir problemdir. Çünkü veri dağılımı benzer görünse bile, aynı veri artık farklı sonuçlar doğuruyor olabilir.

Örneğin kredi riski modeli için ekonomik koşullar değişmiş olabilir. Müşteri profili aynı gibi görünür, ama temerrüt davranışı farklılaşır. Ya da kullanıcı arama niyeti aynı kelimelerle ifade edilir, fakat artık farklı içerik beklentisi taşır.

3. Prediction Drift

Tahmin veya skor dağılımlarının zamanla değişmesi, üretim davranışının sessiz bozulduğunu gösterebilir. Bu bazen veri drift’ten, bazen de modelin hassasiyet yapısındaki değişimden kaynaklanabilir.

4. Upstream Drift

Bazen problem doğrudan modelde değildir; modeli besleyen upstream sistemler değişmiştir. ETL mantığı, veri alanı isimleri, normalizasyon yöntemi veya business rule değişimi, model davranışını dolaylı olarak bozabilir.

5. Segment-Level Drift

En tehlikeli drift türlerinden biri budur. Genel metrikler stabil görünürken belirli müşteri gruplarında, lokasyonlarda, cihaz tiplerinde veya ürün segmentlerinde kalite ciddi biçimde bozulabilir. Bu yüzden yalnızca global ortalamalara bakmak yanıltıcıdır.

Bu iki drift türü çoğu zaman karıştırılır; oysa çözüm stratejileri farklıdır.

Data drift durumunda çoğu zaman veri kaynakları, feature engineering, örnekleme stratejisi veya yeniden eğitim yaklaşımı gözden geçirilir. Problem, modele gelen dünyanın değişmesidir.

Concept drift durumunda ise modelin dünyayı yorumlama biçimi eskimiştir. Burada sadece yeni veri toplamak yetmeyebilir; hedef tanımı, eğitim stratejisi, feature set veya hatta problem formülasyonu yeniden ele alınmalıdır.

Yanlış teşhis, yanlış müdahale doğurur. Örneğin concept drift yaşanan bir sistemi sadece eski veri mantığıyla yeniden eğitmek çoğu zaman kalıcı çözüm üretmez.

Drift tespiti tek bir yöntemle yapılmaz. En doğru yaklaşım, istatistiksel testler, dağılım karşılaştırmaları, kalite metrikleri ve iş sinyallerini birlikte değerlendirmektir.

İstatistiksel Yaklaşımlar

• Population Stability Index (PSI)
• Kolmogorov-Smirnov testi
• Jensen-Shannon divergence
• Wasserstein distance
• Category proportion shift

Davranışsal Yaklaşımlar

• Skor dağılımı değişimi
• Sınıf oranı değişimi
• Confidence shift
• Segment bazlı performans farkı

İş Sinyalleri

• Destek taleplerinde artış
• Manuel override oranı yükselmesi
• İnsan düzeltme ihtiyacı
• Downstream hata oranları
• Dönüşüm veya verimlilik düşüşü

Buradaki temel prensip şudur: Drift tespiti yalnızca istatistiksel bir alarm sistemi değil, operasyonel yorumlama kabiliyeti gerektiren bir disiplindir.

Birçok üretim sisteminde gerçek etiketler anında gelmez. Kredi temerrüdü aylar sonra ortaya çıkar. Kullanıcının bir öneriyi gerçekten faydalı bulup bulmadığı belirli bir davranış sonrasında anlaşılır. Destek yanıtının doğruluğu bazen manuel inceleme gerektirir.

Bu gecikme, monitoring mimarisinde çok önemli bir soruna yol açar: Anlık kalite görünmezliği. Bu nedenle iyi bir sistemde yalnızca gerçek etiketlere değil, proxy metriklere de ihtiyaç vardır.

Örnek proxy sinyaller:

• Kullanıcı geri bildirimi
• Yanıt sonrası yeni soru sayısı
• İnsan müdahalesi gereksinimi
• Düzeltme oranı
• Session abandonment
• Override pattern’leri

Gerçek kalite metriği gecikmeli geliyorsa, bu ara sinyaller sistemin erken uyarı mekanizması haline gelir.

Feedback loop, üretimde çalışan sistemin davranışından öğrenerek kendini iyileştirebilmesini sağlayan geri besleme mekanizmasıdır. Ancak burada çok kritik bir ayrım vardır: Her geri besleme faydalı değildir. Kötü tasarlanmış feedback loop’lar sistemi iyileştirmek yerine yanlış yöne sürükleyebilir.

İyi bir feedback loop şu sorulara cevap verir:

• Hangi sinyal geri besleme olarak kabul edilecek?
• Bu sinyal güvenilir mi?
• İnsan doğrulaması gerekiyor mu?
• Bu sinyal etiketleme sürecine mi girecek, alarm mı üretecek, yeniden eğitimi mi tetikleyecek?
• Yanıltıcı geri beslemeler nasıl filtrelenecek?

1. Açık Geri Bildirim

Kullanıcının doğrudan verdiği puan, thumbs up/down, etiketleme veya yorum gibi sinyallerdir. Anlamlıdır; ancak düşük katılım veya yanlı örnekleme riski taşır.

2. Dolaylı Geri Bildirim

Kullanıcının davranışından çıkarılan sinyallerdir. Tıklama, terk etme, tekrar soru sorma, manuel düzeltme gibi davranışlar bu gruptadır. Daha ölçeklenebilirdir; ancak doğru yorum gerektirir.

3. İnsan Değerlendirmesi

Özellikle yüksek riskli sistemlerde uzman veya operasyon ekibi tarafından yapılan değerlendirmeler çok kıymetlidir. Daha pahalıdır ama daha güvenilir olabilir.

4. Sistem İçi Geri Besleme

Downstream süreçlerden gelen sinyaller de geri besleme olabilir. Örneğin yanlış sınıflandırılan ticket’lar, başarısız workflow’lar veya başarısız dönüşümler model kalitesi için önemli işaretler üretir.

Feedback loop tasarımında en sık yapılan hata, her kullanıcı sinyalini doğrudan doğru kabul etmektir. Oysa üretim verisi gürültülüdür. Bu yüzden güçlü bir tasarım şu ilkeleri içermelidir:

1. Sinyal güvenilirliğini sınıflandır

Her geri bildirim aynı değerde değildir. Açık geri bildirim, manuel etiket, davranışsal sinyal ve sistem logu farklı güven seviyelerine sahiptir.

2. Geri beslemeyi amaç bazlı ayır

Bazı sinyaller anlık alarm üretmek içindir, bazıları veri setine eklenir, bazıları ise sadece analiz amaçlı tutulur. Her sinyalin aynı akışa sokulması doğru değildir.

3. İnsan doğrulaması gereken alanları belirle

Özellikle etiket kalitesinin kritik olduğu durumlarda doğrudan otomatik yeniden eğitim riskli olabilir.

4. Döngüyü ölçülebilir yap

Feedback loop’un kendisi de izlenmelidir. Kaç geri bildirim geldi, kaçı anlamlıydı, kaçı modele etki etti, ne kadar iyileşme sağladı?

5. Yanlış pekiştirme riskini yönet

Bazı sistemlerde kullanıcı davranışı her zaman “doğru etiketi” temsil etmez. Yanlış sinyalleri doğrudan modele beslemek, hatalı davranışı güçlendirebilir.

Monitoring ve drift tespiti her zaman otomatik yeniden eğitim anlamına gelmez. Bu çok kritik bir noktadır. Çünkü her kalite düşüşü yeniden eğitimle çözülmez. Bazen problem upstream veri yapısındadır, bazen iş kuralı değişmiştir, bazen de kullanıcı arayüzü kaynaklıdır.

Yeniden eğitim kararı genellikle şu koşullar birlikte değerlendirildiğinde verilmelidir:

• Kalite metriğinde anlamlı düşüş
• Drift sinyalinin kalıcı hale gelmesi
• İş metriği etkisinin doğrulanması
• Yeni verinin temsil gücü
• Mevcut modelin hata türlerinin analizi
• Alternatif çözüm yollarının dışlanması

Başka bir deyişle, retraining bir refleks değil; kontrollü bir karar süreci olmalıdır.

Genel ortalamalar çoğu zaman gerçeği gizler. Bir model tüm kullanıcılar üzerinde %92 doğruluk veriyor olabilir; ancak yeni kullanıcılar, belirli şehirler, belirli ürün grupları veya mobil cihaz kullanan segmentlerde çok daha kötü performans gösterebilir.

Bu nedenle monitoring şu kırılımları içermelidir:

• Müşteri tipi
• Coğrafya
• Cihaz / kanal
• Zaman dilimi
• İşlem tipi
• Ürün segmenti
• Risk grubu

Segment bazlı izleme, yalnızca adalet ve kalite açısından değil; erken bozulma tespiti açısından da vazgeçilmezdir.

Evet. LLM sistemlerinde klasik model izlemeye ek olarak şu katmanlar da kritik hale gelir:

• Prompt versiyonu bazlı kalite farkları
• Retrieval hit kalitesi
• Faithfulness ve groundedness sinyalleri
• Token maliyeti ve context boyutu
• Conversation abandonment
• Yanlış güven üreten cevaplar
• İnsan eskalasyon oranı

Bu nedenle LLM monitoring, klasik accuracy takibinden çok daha fazla bağlamsal ve davranışsal sinyal gerektirir.

Olgun bir dashboard sadece sayı göstermez; karar desteği sunar. İyi bir üretim panelinde en az şu bloklar bulunmalıdır:

• Latency, throughput, error rate
• Veri kalite ve drift sinyalleri
• Tahmin dağılımı veya yanıt davranışı
• Kalite metriği trendi
• Segment bazlı performans
• İş metriği bağlantısı
• Alarm geçmişi
• En sık hata türleri
• Feedback loop giriş hacmi
• Retraining / rollback karar geçmişi

Dashboard tasarımında amaç rapor üretmek değil; operasyonel karar süresini kısaltmaktır.

Alarm tasarımında en büyük hata, ya çok fazla alarm üreterek ekipleri duyarsızlaştırmak ya da çok dar eşikler yüzünden gerçek problemi kaçırmaktır. Sağlıklı bir strateji için alarm seviyeleri katmanlı düşünülmelidir:

• Warning: Erken sinyal, izleme gerektirir
• Critical: Acil müdahale gerektirir
• Business-critical: İş çıktısını etkileyen bozulma

Ayrıca tek bir metriğe dayalı alarm yerine, çoklu sinyal kombinasyonları daha doğru sonuç verir. Örneğin sadece drift değil; drift + kalite düşüşü + iş metriği etkisi bir araya geldiğinde daha güçlü alarm üretilmelidir.

1. Sadece sistem metriklerini izlemek
2. Veri katmanını görünmez bırakmak
3. Global ortalamalara güvenmek
4. Geciken etiket problemini hesaba katmamak
5. Feedback loop’u kalitesiz sinyallerle kurmak
6. Her drift sinyalini otomatik retraining ile çözmeye çalışmak
7. İş metriklerini monitoring’den ayırmak
8. Alarm eşiklerini rastgele belirlemek
9. Dashboard’u karar aracı yerine rapor panosu gibi tasarlamak
10. Monitoring sahipliğini net tanımlamamak

Rol	Sorumluluk
ML Engineer	Model servisleme, monitoring entegrasyonu, kalite sinyalleri
Data Engineer	Veri kalite akışları, şema kontrolleri, upstream görünürlük
Data Scientist	Drift analizi, performans yorumu, retraining stratejisi
Platform / DevOps	Operasyonel metrikler, dashboard altyapısı, alarm sistemi
Product / Business Owner	İş metriği etkisi, kullanım senaryosu başarımı
Risk / Governance	Kritik bozulmalarda kontrol, onay ve müdahale çerçevesi

Monitoring’in başarısı teknik olduğu kadar organizasyonel bir problemdir. Metriği üretmek kadar, o metriğe kim bakacak ve hangi kararı alacak sorusu da net olmalıdır.

İlk 30 Gün: Görünürlüğü Kur

• Mevcut canlı sistemde hangi metriklerin izlendiğini haritala
• Eksik veri, kalite ve iş metriği alanlarını belirle
• İlk referans dashboard’u oluştur
• En kritik segmentleri tanımla
• Etiket gecikmesi olan alanlarda proxy sinyalleri belirle

31-60 Gün: Alarm ve Drift Katmanını Güçlendir

• Veri drift testlerini devreye al
• Tahmin dağılımı ve kalite trendlerini ekle
• Warning ve critical alarm eşiklerini tanımla
• Segment bazlı monitoring’i başlat
• İlk feedback loop veri akışını kur

61-90 Gün: Sürekli İyileştirme Mekanizmasını Oluştur

• Feedback sinyallerinin güvenilirliğini sınıflandır
• Retraining karar ağacını oluştur
• Rollback ve müdahale prosedürlerini resmileştir
• İş ve teknik metrikleri tek görünümde birleştir
• İlk referans monitoring standardını kurumsallaştır

Bir yapay zekâ sistemini üretime almak, modelin yolculuğunu bitirmez; tam tersine gerçek yaşam döngüsünü başlatır. Üretimde dayanıklılık, başlangıçtaki accuracy değerinden değil; sistemin bozulmayı ne kadar erken fark edebildiğinden, bu bozulmayı ne kadar doğru yorumladığından ve ne kadar kontrollü şekilde yanıt verebildiğinden gelir.

Bu nedenle model monitoring, drift analizi ve feedback loop tasarımı; “ekstra operasyonel detaylar” değil, üretim sınıfı AI mimarisinin çekirdeğidir. Güçlü ekipler yalnızca model kurmaz; modelin zaman içindeki davranışını görünür, yönetilebilir ve iyileştirilebilir hale getirir.

Uzun vadede ayakta kalan AI sistemleri, en yüksek ilk metriğe sahip olanlar değil; değişen dünyaya karşı en iyi izleme ve uyum mekanizmasını kuran sistemlerdir.

Model monitoring ile model evaluation aynı şey mi?

Hayır. Evaluation genellikle modelin kalite ölçümünü ifade eder. Monitoring ise kaliteye ek olarak veri sağlığı, operasyonel performans, tahmin davranışı ve iş etkisini de izler.

Her drift kötü müdür?

Hayır. Bazı drift türleri doğal mevsimsellik veya iş büyümesi nedeniyle oluşabilir. Önemli olan drift’in iş ve kalite üzerindeki etkisini doğru yorumlamaktır.

Drift gördüğümüzde hemen retraining yapmalı mıyız?

Hayır. Önce drift’in tipi, kalıcılığı, kalite etkisi ve kök nedeni anlaşılmalıdır. Her drift otomatik yeniden eğitim gerektirmez.

Etiketler çok geç geliyorsa kaliteyi nasıl izleriz?

Proxy metrikler, kullanıcı geri bildirimi, insan düzeltme oranı ve downstream iş sinyalleri kullanılarak erken uyarı mekanizması kurulabilir.

Monitoring yalnızca veri bilimi ekibinin sorumluluğu mudur?

Hayır. Üretim sınıfı monitoring; ML engineering, data engineering, platform, iş birimi ve governance ekiplerinin ortak sorumluluğudur.