Kazanimlar:
- Modelin sessiz bozulma nedenlerini (veri kayması, kavram kayması, yukarı akış hatası) tanıyıp üç katmanlı (operasyonel, girdi, çıktı) izleme kurabilme
- LLM sistemlerini kural kontrolleri, LLM-hakem ve insan değerlendirmesiyle çok katmanlı değerlendirebilme ve LLM-hakemi insan çıpasıyla kalibre edebilme
- Kenar ve güvenlik vakaları içeren bir eval kümesi tasarlayıp yakalanan her hatayı kalıcı test vakasına dönüştürebilme
Bir model üretime çıktığı an, işiniz bitmez; asıl sorumluluk yeni başlar. Çünkü model, kimse bakmıyorken sessizce bozulabilir. Bu ünitede iki birbirini tamamlayan disiplini işliyoruz: değerlendirme (evaluation/eval: modelin kalitesini sistematik ölçme) ve izleme (monitoring: üretimdeki modeli sürekli gözetme). Özellikle LLM sistemlerinde eval, klasik ML'den daha zordur ve daha çok özen ister.
Neden üretim modeli sessizce bozulur
Bir yazılım hatası çöker, log basar, alarm çalar. Bir ML modeli ise hata vermeden yanlış olur. Üç ana bozulma nedeni:
- Veri kayması (data drift): Girdi verisinin dağılımı zamanla değişir (yeni ürünler, değişen kullanıcı davranışı, mevsimsellik). Model aynı kalır ama dünya değişir.
- Kavram kayması (concept drift): Girdi-çıktı ilişkisi değişir. Dolandırıcılık taktikleri, spam kalıpları evrilir; dünkü doğru bugün yanlış olur.
- Yukarı akış bozulması: Bir veri kaynağı format değiştirir, bir alan boşalır; model bozuk girdiyle sessizce saçmalar.
İzleme, bu sessiz bozulmaları sesli hâle getirmektir.
Ne izlenir: üç katman
İyi bir izleme üç katmanı kapsar:
- Operasyonel metrikler: Gecikme (latency), hata oranı, istek hacmi, kaynak kullanımı. "Sistem ayakta mı?"
- Veri/girdi metrikleri: Girdi dağılımı eğitimdekine benziyor mu? Eksik değer oranı arttı mı? Yeni kategoriler mi geldi? "Model tanıdık veri mi görüyor?"
- Model/çıktı metrikleri: Tahmin dağılımı kaydı mı? Güven skorları düştü mü? Ve mümkünse gerçek sonuçla (ground truth) karşılaştırıldığında doğruluk ne? "Model hâlâ doğru mu?"
Üçüncü katman en değerli ama en zorudur; çünkü gerçek sonuç genelde gecikmeli gelir (bir kredinin geri ödenip ödenmeyeceği aylar sonra belli olur).
Ipucu: Gerçek sonuç gecikmeliyse, önce girdi ve tahmin dağılımını izleyin. Girdi dağılımının kayması, doğruluk düşüşünün erken habercisidir ve gerçek sonucu beklemeden alarm verebilir.
LLM sistemlerini değerlendirmek: özel zorluk
Klasik ML'de "doğru cevap" nettir (sınıf 0 mı 1 mi). LLM çıktısı ise açık uçludur: aynı soruya birçok doğru cevap olabilir, "doğruluk" tek sayıya sığmaz. LLM eval yaklaşımları:
- Referanslı metrikler: Çıktıyı ideal cevapla karşılaştırma. Kısıtlı; çünkü farklı ifade edilmiş doğru cevabı "yanlış" sayabilir.
- Kural tabanlı kontroller: Çıktı geçerli JSON mu? Yasaklı kelime var mı? İstenen alanları içeriyor mu? Ucuz, güvenilir, dar.
- LLM-hakem (LLM-as-judge): Bir modele "bu cevap şu kritere göre iyi mi" diye sordurma. Ölçeklenir ama hakemin kendisi doğrulanmalıdır.
- İnsan değerlendirmesi: Altın standart ama pahalı ve yavaş. Örneklem üzerinde kullanılır.
Pratikte bunlar birlikte kullanılır: ucuz kural kontrolleri her çıktıda, LLM-hakem geniş örneklemde, insan değerlendirmesi küçük ama titiz bir örneklemde.
Zayıf yaklaşım / Güçlü yaklaşım
Zayıf: "LLM-hakeme sordum, cevaplarımızın %92'si iyiymiş. Sistem harika."
Güçlü: "Önce 100 çıktıyı insanla etiketledik. LLM-hakemi aynı 100 çıktıda çalıştırıp insan-hakem uyumunu ölçtük — %85 uyum, kabul edilebilir. Hakemin sistematik olarak nerede yanıldığını (uzun cevapları haksız yere iyi bulma eğilimi) belgeledik ve prompt'unu düzelttik. Ancak ondan sonra hakem skorlarına güvendik."
Fark: güçlü yaklaşım hakemi körü körüne değil, insan çıpasıyla doğrular. Doğrulanmamış bir LLM-hakem, güzel görünen ama yanlış bir güven verir.
Dikkat: LLM-hakem de bir modeldir; halüsinasyon yapar, taraflıdır (uzun/kendinden emin cevapları kayırır), tutarsız olabilir. Hakem skorlarını üretim kararı yapmadan önce insan etiketleriyle kalibre edin.
Değerlendirme kümesi: dikkatle tasarlanır
İyi bir eval kümesi, gerçek kullanımın çeşitliliğini ve zor durumları temsil eder. Sadece kolay örneklerle dolu bir eval, sizi yanlış güvende bırakır. Eval kümesine mutlaka koyun:
- Kenar durumlar: Boş girdi, çok uzun girdi, alışılmadık format.
- Bilinen zor vakalar: Modelin geçmişte hata yaptığı örnekler (regresyon testi olarak).
- Güvenlik vakaları: Prompt injection denemeleri, zararlı istekler, gizlilik ihlali tuzakları.
Eval kümesi zamanla büyür: üretimde yakaladığınız her yeni hata, bir sonraki değerlendirmenin test vakası olur.
Alarm ve müdahale
İzleme, alarm olmadan yarım kalır. Her önemli metrik için bir eşik ve bir müdahale planı olmalı: "Girdi kayması X'i aşarsa mühendise bildir", "Hata oranı Y'yi geçerse otomatik geri al". Alarmları anlamlı tutun — çok fazla yanlış alarm, ekibi duyarsızlaştırır ve gerçek alarmı kaçırtır.
Üç mini vaka
Vaka 1 - Erken uyarı. Bir talep tahmin modelinin gerçek doğruluğu ancak hafta sonunda belli oluyordu. Ekip girdi dağılımını izliyordu ve bir salı günü yeni bir ürün kategorisinin ani yükselişini gördü — model bunu hiç görmemişti. Doğruluk düşüşünü beklemeden modeli güncellediler. Girdi izleme, günler kazandırdı.
Vaka 2 - Doğrulanmamış hakem. Bir ekip LLM-hakeme dayanarak "kalitemiz mükemmel" raporladı. Müşteri şikayetleri artınca insan denetimi yapıldı: hakem, kendinden emin ama yanlış cevapları "iyi" sayıyordu. Hakem insan etiketleriyle kalibre edilince gerçek kalite ortaya çıktı ve çok daha düşüktü. Ders: hakemi doğrulamadan güvenme.
Vaka 3 - Regresyon testi. Bir prompt değişikliği bir sorunu çözerken sessizce başka bir vakayı bozdu. Ama ekip, geçmiş hataları eval kümesinde tutuyordu; yeni değişiklik bu kümede test edilince kırılan vaka hemen yakalandı ve değişiklik düzeltildi. Ders: her düzeltilen hata, kalıcı bir test vakasına dönüşmeli.
Kopyalanabilir şablonlar
Bu üretim modeli için bir izleme planı üret. Üç katmanı kapsa:1) Operasyonel (gecikme, hata oranı, hacim)2) Girdi/veri (dağılım kayması, eksik değer, yeni kategori)3) Model/çıktı (tahmin dağılımı, güven, mümkünse doğruluk)Model: [açıklama]. Gerçek sonuç ne kadar gecikmeli geliyor: [süre]Her metrik için eşik ve müdahale önerisi ekle.
Bu LLM sistemi için bir değerlendirme (eval) stratejisi öner.Görev: [açıklama]Katmanları belirle:- Hangi kural tabanlı kontroller her çıktıda çalışmalı?- LLM-hakem hangi kriterleri değerlendirmeli ve nasıl doğrulanmalı (insan çıpası)?- İnsan değerlendirmesi hangi örneklemde yapılmalı?Eval kümesine koymam gereken kenar ve güvenlik vakalarını listele.
Bu LLM-hakem prompt'unu denetle:- Değerlendirme kriteri net mi, öznel mi?- Uzunluk/kendine güven yanlılığına açık mı?- Hakemi insan etiketleriyle nasıl kalibre ederim?Hakem prompt'u: [prompt]
Bu izleme alarmı için bir müdahale runbook'u yaz.Alarm: [ör. girdi kayması eşiği aşıldı]İçermeli: ilk kontrol adımları, olası nedenler, geri alma kriteri, kimin bilgilendirileceği.
Bozulma nedeni tablosu
Bozulma
Belirti
Erken tespit yolu
Veri kayması
Girdi dağılımı değişir
Girdi dağılım izleme
Kavram kayması
Doğruluk sessizce düşer
Tahmin + gerçek karşılaştırma
Yukarı akış hatası
Alanlar boşalır/format değişir
Şema doğrulama + eksik oranı
Model tutarsızlığı
Çıktı dağılımı kayar
Çıktı dağılım izleme
Sık yapılan hatalar
- İzleme kurmamak. Model sessizce bozulur, kimse görmez.
- Sadece operasyonel metrik izlemek. Sistem ayakta ama tahminler yanlış olabilir.
- LLM-hakemi doğrulamadan kullanmak. Yanlış bir güven verir.
- Kolay örneklerle eval yapmak. Gerçek zorluğu göstermez.
- Geçmiş hataları eval'e katmamak. Aynı hata tekrar döner.
- Gürültülü alarmlar. Ekip duyarsızlaşır, gerçek alarmı kaçırır.
Ozetle
Model üretimde hata vermeden yanlış olabilir; bu yüzden eval ve izleme, geliştirme kadar önemlidir. İzlemeyi üç katmanda (operasyonel, girdi, çıktı) kurun; gerçek sonuç gecikmeliyse girdi kaymasını erken uyarı olarak kullanın. LLM sistemlerinde eval açık uçludur; kural kontrolleri, LLM-hakem ve insan değerlendirmesini birlikte kullanın — ama LLM-hakemi mutlaka insan çıpasıyla doğrulayın. Eval kümenizi kenar ve güvenlik vakalarıyla zenginleştirin ve her yakalanan hatayı kalıcı bir test vakasına çevirin.
Uygulama gorevi
Bir üretim (veya üretime yakın) modelin için üç katmanlı bir izleme planı yaz ve en az bir girdi-dağılım metriği için eşik + alarm tanımla. Bir LLM sistemin varsa: 30 çıktıyı insanla etiketle, aynı çıktılarda bir LLM-hakem çalıştır ve insan-hakem uyumunu ölç; hakemin sistematik yanlılığını not et. Eval kümene en az 3 kenar ve 2 güvenlik vakası ekle.
Kontrol listesi
- [ ] İzleme üç katmanı da kapsıyor (operasyonel, girdi, çıktı).
- [ ] Gerçek sonuç gecikmeliyse girdi kaymasını erken uyarı olarak kullanıyorum.
- [ ] LLM-hakemi insan etiketleriyle kalibre ettim.
- [ ] Eval kümesi kenar ve güvenlik vakaları içeriyor.
- [ ] Yakaladığım her hatayı kalıcı test vakasına çevirdim.
- [ ] Her önemli metriğin eşiği ve müdahale planı var.