Kısa cevap: Yapay zeka modellerini iyi değerlendirmek için, öncelikle gerçek kullanıcı ve söz konusu karar için "iyi"nin ne anlama geldiğini tanımlayarak başlayın. Ardından, temsili veriler, sıkı sızıntı kontrolleri ve birden fazla ölçütle tekrarlanabilir değerlendirmeler oluşturun. Stres, önyargı ve güvenlik kontrolleri ekleyin ve herhangi bir şey değiştiğinde (veri, uyarılar, politika), test ortamını yeniden çalıştırın ve başlatıldıktan sonra izlemeye devam edin.
Önemli noktalar:
Başarı kriterleri : Ölçütleri seçmeden önce kullanıcıları, kararları, kısıtlamaları ve en kötü senaryo başarısızlıklarını tanımlayın.
Tekrarlanabilirlik : Her değişiklikte karşılaştırılabilir testleri yeniden çalıştıran bir değerlendirme ortamı oluşturun.
Veri hijyeni : İstikrarlı bölümlendirmeler sağlayın, tekrarları önleyin ve özellik sızıntısını erken aşamada engelleyin.
Güvenilirlik kontrolleri : Net ölçütlerle stres testi sağlamlığı, adalet dilimleri ve LLM güvenlik davranışları.
Yaşam döngüsü disiplini : Aşamalar halinde devreye alın, sapmaları ve olayları izleyin ve bilinen eksiklikleri belgeleyin.
Bu makaleden sonra okumak isteyebileceğiniz diğer makaleler:
🔗 Yapay zeka etiği nedir?
Sorumlu yapay zeka tasarımı, kullanımı ve yönetimine yön veren ilkeleri keşfedin.
🔗 Yapay zekâ önyargısı nedir?
Önyargılı verilerin yapay zeka kararlarını ve sonuçlarını nasıl çarpıttığını öğrenin.
🔗 Yapay zeka ölçeklenebilirliği nedir?
Yapay zekâ sistemlerinin performans, maliyet ve güvenilirlik açısından ölçeklendirilmesini anlayın.
🔗 Yapay zeka nedir?
Yapay zekânın, türlerinin ve gerçek dünyadaki kullanım alanlarının net bir özeti.
1) Öncelikle "iyi"nin gösterişsiz tanımıyla başlayalım
Ölçümlerden önce, gösterge tablolarından önce, herhangi bir kıyaslama gösterisinden önce - başarının neye benzediğine karar verin.
Açıklamak:
-
Kullanıcı: şirket içi analist, müşteri, klinisyen, şoför, öğleden sonra 4'te yorgun bir destek temsilcisi...
-
Karar: krediyi onaylamak, dolandırıcılığı tespit etmek, içerik önermek, notları özetlemek.
-
En önemli başarısızlıklar:
-
Yanlış pozitifler (can sıkıcı) ve yanlış negatifler (tehlikeli)
-
-
Kısıtlamalar: gecikme süresi, istek başına maliyet, gizlilik kuralları, açıklanabilirlik gereksinimleri, erişilebilirlik
İşte bu noktada ekipler, "anlamlı sonuç" yerine "güzel görünen ölçütler" için optimizasyon yapmaya kayıyorlar. Bu çok sık oluyor. Hem de çok sık.
Yapay Zeka Risk Yönetimi Çerçevesi'nde (AI RMF 1.0) [1] yaptığı gibi, testleri güvenilirlik ve yaşam döngüsü risk yönetimi etrafında çerçevelemektir
2) İyi bir “yapay zeka modellerini nasıl test edersiniz” kılavuzunu ne oluşturur? ✅
Sağlam bir test yaklaşımının olmazsa olmaz birkaç unsuru vardır:
-
Temsili veriler (sadece temiz laboratuvar verileri değil)
-
net çatlaklar (buna birazdan değineceğiz)
-
Temel modeller ( gereken - kukla tahminciler bir nedenden dolayı mevcuttur [4])
-
Birden fazla ölçüt (çünkü tek bir sayı size kibarca, yüzünüze karşı yalan söylüyor)
-
Stres testleri (uç durumlar, alışılmadık girdiler, düşmanca senaryolar)
-
İnsan inceleme döngüleri (özellikle üretken modeller için)
-
Lansmandan sonra izleme (çünkü dünya değişiyor, boru hatları bozuluyor ve kullanıcılar… yaratıcı [1])
Ayrıca: İyi bir yaklaşım, neyi test ettiğinizi, neyi test etmediğinizi ve neyden endişe duyduğunuzu belgelemeyi içerir. "Neyden endişe duyuyorum" bölümü biraz garip hissettiriyor - ve aynı zamanda güvenin oluşmaya başladığı yer de burası.
Ekiplerin dürüst kalmasına sürekli olarak yardımcı olan iki dokümantasyon modeli:
-
Model Kartları (modelin ne için olduğu, nasıl değerlendirildiği, nerede başarısız olduğu) [2]
-
Veri Kümeleri için Veri Sayfaları (verinin ne olduğu, nasıl toplandığı, ne için kullanılması gerektiği/gerekmediği) [3]
3) Araçların gerçekliği: İnsanların pratikte kullandıkları 🧰
Araçlar isteğe bağlıdır. İyi değerlendirme alışkanlıkları ise zorunlu değildir.
Eğer pratik bir kurulum istiyorsanız, çoğu ekip üç kategoriyle yetinir:
-
Deney takibi (çalışmalar, yapılandırmalar, çıktılar)
-
Değerlendirme aracı (tekrarlanabilir çevrimdışı testler + regresyon paketleri)
-
İzleme (sapma sinyalleri, performans göstergeleri, olay uyarıları)
Piyasada sıkça göreceğiniz örnekler (onay niteliğinde değildir ve evet, özellikler/fiyatlandırma değişebilir): MLflow, Weights & Biases, Great Expectations, Evidently, Deepchecks, OpenAI Evals, TruLens, LangSmith.
Bu bölümden fikir seçmeniz gerekirse tekrarlanabilir bir değerlendirme düzeneği oluşturun . İstediğiniz şey "düğmeye bas → karşılaştırılabilir sonuçlar al" olmalı, "not defterini tekrar çalıştır ve dua et" değil.
4) Doğru test setini oluşturun (ve veri sızıntısını durdurun) 🚧
Şaşırtıcı sayıda "muhteşem" modelin istemeden hile yaptığı ortaya çıktı.
Standart makine öğrenimi için
Kariyerleri kurtaran, pek de cazip olmayan birkaç kural:
-
Eğitim/doğrulama/test veri tutun (ve bölümleme mantığını yazın).
-
Bölümler arasında yinelenen kayıtları önleyin (aynı kullanıcı, aynı belge, aynı ürün, neredeyse aynı kayıtlar).
-
Özellik sızıntılarına dikkat edin (gelecekle ilgili bilgilerin "mevcut" özelliklere sızması).
-
Temel değerleri (kukla tahminciler) kullanın ki hiçbir şeyi yendiğinizi kutlamayın [4]
Sızıntı tanımı (kısa versiyon): Eğitim/değerlendirme aşamasında modelin karar verme anında sahip olamayacağı bilgilere erişmesini sağlayan her şey. Bu, açık ("gelecekteki etiket") veya gizli ("olay sonrası zaman damgası aralığı") olabilir.
LLM'ler ve üretken modeller için
Sadece bir "model" değil, bir uyarı ve politika sistemi kuruyorsunuz
-
(küçük, yüksek kaliteli, istikrarlı) bir dizi
-
Son gerçek örnekleri ekleyin (anonimleştirilmiş + gizlilik güvenli).
-
Olası istisnai durumlar için bir paket bulundurun : yazım hataları, argo, standart dışı biçimlendirme, boş giriş alanları, çok dilli sürprizler 🌍
Birden fazla kez şahit olduğum pratik bir durum: Bir ekip "güçlü" bir çevrimdışı puanla ürünü piyasaya sürüyor, ardından müşteri desteği "Harika. Önemli olan tek cümleyi kesinlikle kaçırmış." diyor. Çözüm "daha büyük model" değildi. Daha iyi test soruları , daha net değerlendirme kriterleri ve tam olarak bu hata modunu cezalandıran bir regresyon test paketiydi. Basit. Etkili.
5) Çevrimdışı değerlendirme: Anlam ifade eden ölçütler 📏
Ölçütler iyidir. Ancak ölçütlere dayalı tek kültürlülük iyi değildir.
Sınıflandırma (istenmeyen e-posta, dolandırıcılık, niyet, önceliklendirme)
Sadece doğruluktan fazlasını kullanın.
-
Hassasiyet, geri çağırma, F1
-
Eşik ayarı (varsayılan eşiğiniz maliyetleriniz için nadiren "doğru"dur) [4]
-
Segmentlere göre karışıklık matrisleri (bölge, cihaz türü, kullanıcı grubu)
Regresyon (tahmin, fiyatlandırma, puanlama)
-
MAE / RMSE (hataları nasıl cezalandırmak istediğinize göre seçin)
-
Çıktılar "puan" olarak kullanıldığında kalibrasyon benzeri kontroller (puanlar gerçeklikle örtüşüyor mu?)
Sıralama / tavsiye sistemleri
-
NDCG, MAP, MRR
-
Sorgu türüne göre dilimleme (başlangıç vs. son)
Bilgisayar görüşü
-
mAP, IoU
-
Sınıf bazında performans (nadiren de olsa bazı sınıflarda modeller sizi utandırabilir)
Üretken modeller (LLM'ler)
İşte burada insanlar felsefi düşüncelere dalıyor... 😵💫
Gerçek takımlarda işe yarayan pratik seçenekler:
-
İnsan değerlendirmesi (en iyi sinyal, en yavaş döngü)
-
İkili tercih / kazanma oranı (A ile B arasındaki karşılaştırma, mutlak puanlamadan daha kolaydır)
-
Otomatik metin ölçümleri (bazı görevler için kullanışlı, diğerleri için yanıltıcı)
-
Görev tabanlı kontroller: “Doğru alanları çıkardı mı?”, “Politikaya uydu mu?”, “Gerektiğinde kaynakları belirtti mi?”
Yapılandırılmış bir “çoklu ölçüt, çoklu senaryo” referans noktası istiyorsanız, HELM iyi bir dayanak noktasıdır: değerlendirmeyi doğruluktan öteye, kalibrasyon, sağlamlık, sapma/toksisite ve verimlilik takasları gibi konulara açıkça iter [5].
Küçük bir sapma: Yazı kalitesini ölçmek için kullanılan otomatik metrikler bazen bir sandviçi tartarak değerlendirmeye benziyor. Önemsiz bir şey değil ama... hadi ama 🥪
6) Dayanıklılık testi: biraz terletin onu 🥵🧪
Modeliniz yalnızca düzgün girdilerle çalışıyorsa, temelde bir cam vazo gibidir. Güzel, kırılgan, pahalı.
Test:
-
Gürültü: yazım hataları, eksik değerler, standart dışı Unicode, biçimlendirme hataları
-
Dağıtım değişikliği: yeni ürün kategorileri, yeni argo, yeni sensörler
-
Aşırı değerler: aralık dışı sayılar, devasa veri yükleri, boş dizeler
-
Eğitim veri setinize benzemeyen ancak kullanıcılara benzeyen "
LLM programları için şunları ekleyin:
-
İstemli enjeksiyon girişimleri (kullanıcı içeriğine gizlenmiş talimatlar)
-
“Önceki talimatları dikkate alma” kalıpları
-
Araç kullanımında karşılaşılan uç durumlar (hatalı URL'ler, zaman aşımı, kısmi çıktılar)
Sağlamlık, olaylar yaşanana kadar soyut gibi görünen güvenilirlik özelliklerinden biridir. Olaylar yaşandıktan sonra ise… çok somut hale gelir [1].
7) Önyargı, adalet ve bunun kimin işine yaradığı ⚖️
Bir model genel olarak "doğru" olabilirken, belirli gruplar için sürekli olarak daha kötü sonuçlar verebilir. Bu küçük bir hata değil. Bu bir ürün ve güven sorunu.
Pratik adımlar:
-
anlamlı segmentler üzerinden değerlendirin (ölçülmesi yasal/etik açıdan uygun olan segmentler).
-
Gruplar arasında hata oranlarını ve kalibrasyonu karşılaştırın
-
Hassas bilgileri kodlayabilecek proxy özelliklerini (posta kodu, cihaz türü, dil) test edin
Eğer bunu bir yerde belgelemiyorsanız, temelde gelecekteki kendinizden bir güven krizini haritasız bir şekilde gidermesini istiyorsunuz demektir. Model Kartları bunu koymak için sağlam bir yerdir [2] ve NIST'in güvenilirlik çerçevesi, "iyi"nin neleri içermesi gerektiğine dair güçlü bir kontrol listesi sunar [1].
8) Güvenlik ve emniyet testleri (özellikle LLM'ler için) 🛡️
Modeliniz içerik üretebiliyorsa, yalnızca doğruluğu değil, davranışı da test ediyorsunuz demektir.
Aşağıdakiler için testler ekleyin:
-
İçerik oluşturmaya izin verilmemesi (politika ihlali)
-
Gizlilik ihlali (sırları yankılıyor mu?)
-
Yüksek riskli alanlarda halüsinasyonlar
-
Aşırı reddetme (model normal istekleri reddediyor)
-
Toksisite ve taciz çıktıları
-
Hızlı enjeksiyon yoluyla veri sızdırma girişimleri
Temel bir yaklaşım şöyledir: politika kurallarını tanımlayın → test istemleri oluşturun → çıktıları insan ve otomatik kontrollerle puanlayın → herhangi bir şey değiştiğinde her seferinde çalıştırın. Bu "her seferinde" kısmı ise kira bedelidir.
Bu, yaşam döngüsü risk zihniyetine tam olarak uyuyor: yönet, bağlamı haritala, ölç, yönet, tekrarla [1].
9) Çevrimiçi test: aşamalı dağıtımlar (gerçeğin ortaya çıktığı yer) 🚀
Çevrimdışı testler gereklidir. Gerçeklik, ancak çevrimiçi ortamda çamurlu ayakkabılarla ortaya çıkar.
Şık olmanıza gerek yok. Sadece disiplinli olmanız yeterli:
-
Gölge modunda çalıştır (model çalışır, kullanıcıları etkilemez)
-
Aşamalı devreye alma (önce düşük trafik, olumlu sonuç alınırsa genişletilecek)
-
ve takibi (şikayetler, sorunların üst kademelere iletilmesi, politika ihlalleri)
Hemen etiket alamasanız bile, proxy sinyallerini ve operasyonel sağlığı (gecikme, arıza oranları, maliyet) izleyebilirsiniz. Asıl önemli nokta: tüm kullanıcı tabanınızdan önce
10) Dağıtımdan sonra izleme: sapma, bozulma ve sessiz arıza 📉👀
Test ettiğiniz model, sonunda kullanacağınız model olmayacak. Veriler değişir. Kullanıcılar değişir. Dünya değişir. Gece saat 2'de veri akışı bozulur. Biliyorsunuz işte..
Monitör:
-
Giriş verilerindeki sapmalar (şema değişiklikleri, eksiklikler, dağılım kaymaları)
-
Çıktı kayması (sınıf dengesi kaymaları, puan kaymaları)
-
Performans göstergeleri (çünkü etiket gecikmeleri gerçektir)
-
Geri bildirim sinyalleri (beğenmeme, yeniden düzenlemeler, şikayetlerin iletilmesi)
-
Segment düzeyindeki regresyonlar (sessiz katiller)
Ve çok hassas olmayan uyarı eşikleri belirleyin. Sürekli bağıran bir monitör, şehirdeki bir araba alarmı gibi, görmezden gelinir.
Güvenilirliğe önem veriyorsanız, bu “zaman içinde izleme + iyileştirme” döngüsü isteğe bağlı değildir [1].
11) Kopyalayabileceğiniz pratik bir iş akışı 🧩
İşte ölçeklenebilir basit bir döngü:
-
Başarı + başarısızlık modlarını tanımlayın (maliyet/gecikme/güvenlik dahil) [1]
-
Veri kümeleri oluşturun:
-
altın set
-
kenar durum paketi
-
Son gerçek örnekler (gizlilik açısından güvenli)
-
-
Ölçütleri seçin:
-
görev metrikleri (F1, MAE, kazanma oranı) [4][5]
-
güvenlik ölçütleri (politika geçme oranı) [1][5]
-
operasyonel metrikler (gecikme süresi, maliyet)
-
-
Bir değerlendirme düzeneği oluşturun (her model/komut değişikliğinde çalışır) [4][5]
-
Stres testleri + düşmanca testler ekleyin [1][5]
-
Örneklem için insan incelemesi (özellikle LLM çıktıları için) [5]
-
Gölge yoluyla gönder + aşamalı dağıtım [1]
-
Disiplinli bir şekilde izleme + uyarı + yeniden eğitim [1]
-
Belge sonuçları model kart tarzında bir yazıyla sonuçlanır [2][3]
Eğitim göz alıcıdır. Testler ise kira ödemek içindir.
12) Kapanış notları + kısa özet 🧠✨
Yapay zeka modellerini test etme konusunda sadece birkaç şeyi hatırlarsanız :
-
Temsili test verilerini kullanın ve sızıntıdan kaçının [4]
-
Gerçek sonuçlara bağlı birden fazla ölçüt seçin
-
insan incelemesine + kazanma oranı tarzı karşılaştırmalara güvenin [5]
-
Test sağlamlığı - olağandışı girdiler kılık değiştirmiş normal girdilerdir [1]
-
Modeller sapma gösterdiğinden ve boru hatları bozulduğundan, güvenli bir şekilde devreye alın ve izleyin [1]
-
Neleri test ettiğinizi ve neleri test etmediğinizi belgeleyin (rahatsız edici ama güçlü) [2][3]
Test etmek sadece "çalıştığını kanıtla" demek değildir. "Kullanıcılarınız fark etmeden önce nasıl başarısız olduğunu bul" demektir. Ve evet, bu daha az çekici - ama işler sallantıya girdiğinde sisteminizi ayakta tutan kısım bu... 🧱🙂
SSS
Yapay zeka modellerinin gerçek kullanıcı ihtiyaçlarına uygun olmasını sağlamanın en iyi yolu
Öncelikle, "iyi" kavramını sadece bir sıralama ölçütü olarak değil, gerçek kullanıcı ve modelin desteklediği karar açısından tanımlayın. En yüksek maliyetli hata modlarını (yanlış pozitifler ve yanlış negatifler) belirleyin ve gecikme, maliyet, gizlilik ve açıklanabilirlik gibi katı kısıtlamaları açıkça belirtin. Ardından, bu sonuçları yansıtan ölçütler ve test senaryoları seçin. Bu, daha iyi bir ürüne asla dönüşmeyen "güzel bir ölçütü" optimize etmenizi engeller.
Değerlendirme ölçütlerini seçmeden önce başarı kriterlerini tanımlamak
Kullanıcının kim olduğunu, modelin hangi kararı desteklemesi gerektiğini ve üretimde "en kötü durum hatasının" nasıl göründüğünü yazın. Kabul edilebilir gecikme süresi ve istek başına maliyet gibi operasyonel kısıtlamaları ve gizlilik kuralları ve güvenlik politikaları gibi yönetimsel ihtiyaçları ekleyin. Bunlar netleştikten sonra, ölçümler doğru şeyi ölçmenin bir yolu haline gelir. Bu çerçeve olmadan, ekipler ölçülmesi en kolay olan neyse onu optimize etmeye yönelme eğilimindedir.
Model değerlendirmesinde veri sızıntısını ve kazara hile yapılmasını önleme
Eğitim/doğrulama/test bölmelerini sabit tutun ve sonuçların tekrarlanabilir kalması için bölme mantığını belgeleyin. Bölmeler arasında tekrarlanan ve neredeyse tekrarlanan kayıtları (aynı kullanıcı, belge, ürün veya tekrarlanan kalıplar) aktif olarak engelleyin. Zaman damgaları veya olay sonrası alanlar aracılığıyla "gelecek" bilgilerinin girdilere sızdığı özellik sızıntısına dikkat edin. Güçlü bir temel (hatta kukla tahminciler bile) gürültüyü kutladığınızı fark etmenize yardımcı olur.
Bir değerlendirme düzeneğinin, testlerin değişiklikler karşısında tekrarlanabilirliğini koruması için neleri içermesi gerekir?
Pratik bir test ortamı, aynı veri kümelerini ve puanlama kurallarını kullanarak her model, komut istemi veya politika değişikliği üzerinde karşılaştırılabilir testleri yeniden çalıştırır. Tipik olarak bir regresyon paketi, net ölçüm panoları ve izlenebilirlik için saklanmış yapılandırmalar ve yapılar içerir. LLM sistemleri için ayrıca istikrarlı bir "altın küme" komut istemi ve bir uç durum paketi de gereklidir. Amaç "düğmeye bas → karşılaştırılabilir sonuçlar" elde etmek, "not defterini yeniden çalıştır ve dua et" değil
Doğruluktan öte yapay zeka modellerini test etmek için kullanılan ölçütler
Birden fazla ölçüt kullanın, çünkü tek bir sayı önemli ödünleşmeleri gizleyebilir. Sınıflandırma için, hassasiyet/geri çağırma/F1 puanlarını eşik ayarlaması ve segmente göre karışıklık matrisleriyle eşleştirin. Regresyon için, hataları nasıl cezalandırmak istediğinize bağlı olarak MAE veya RMSE'yi seçin ve çıktılar puanlar gibi işlev gördüğünde kalibrasyon tarzı kontroller ekleyin. Sıralama için, NDCG/MAP/MRR kullanın ve eşit olmayan performansı yakalamak için baş ve son sorgulara göre dilimleme yapın.
Otomatik ölçümlerin yetersiz kaldığı durumlarda LLM çıktılarının değerlendirilmesi
Bunu bir uyarı ve politika sistemi olarak ele alın ve yalnızca metin benzerliğine değil, davranışa göre puanlayın. Birçok ekip, insan değerlendirmesini ikili tercih (A/B kazanma oranı) ve "doğru alanları çıkardı mı" veya "politikaya uydu mu" gibi görev tabanlı kontrollerle birleştirir. Otomatik metin ölçümleri bazı durumlarda yardımcı olabilir, ancak genellikle kullanıcıların önemsediği şeyleri gözden kaçırırlar. Açık değerlendirme kriterleri ve bir regresyon paketi genellikle tek bir puandan daha önemlidir.
Modelin gürültülü girdilerde bozulmaması için çalıştırılacak sağlamlık testleri
Modelinizi yazım hataları, eksik değerler, garip biçimlendirme ve standart dışı Unicode ile stres testine tabi tutun, çünkü gerçek kullanıcılar nadiren düzenlidir. Yeni kategoriler, argo, sensörler veya dil kalıpları gibi dağıtım kayması durumlarını ekleyin. Kırılgan davranışları ortaya çıkarmak için aşırı değerleri (boş dizeler, büyük veri yükleri, aralık dışı sayılar) dahil edin. LLM'ler için ayrıca komut istemi enjeksiyon kalıplarını ve zaman aşımı veya kısmi çıktılar gibi araç kullanım hatalarını da test edin.
Teoriye fazla takılmadan önyargı ve adalet sorunlarını kontrol etmek
Anlamlı dilimler üzerinde performansı değerlendirin ve yasal ve etik olarak ölçülmesi uygun olan gruplar arasında hata oranlarını ve kalibrasyonu karşılaştırın. Hassas özellikleri dolaylı olarak kodlayabilen vekil özellikler (posta kodu, cihaz türü veya dil gibi) arayın. Bir model, belirli gruplar için sürekli olarak başarısız olurken "genel olarak doğru" görünebilir. Ne ölçtüğünüzü ve ne ölçmediğinizi belgeleyin, böylece gelecekteki değişiklikler sessizce regresyonları yeniden ortaya çıkarmaz.
Üretken yapay zeka ve LLM sistemleri için güvenlik ve emniyet testleri de dahil edilmelidir
Yasaklanmış içerik oluşturma, gizlilik ihlali, yüksek riskli alanlarda yanılsamalar ve modelin normal istekleri engellediği durumlarda aşırı reddetme gibi durumları test edin. Özellikle sistem araçlar kullandığında veya içerik aldığında, istem enjeksiyonu ve veri sızdırma girişimlerini de dahil edin. Temel bir iş akışı şöyledir: politika kurallarını tanımlayın, bir test istemi kümesi oluşturun, insan ve otomatik kontrollerle puanlayın ve istemler, veriler veya politikalar değiştiğinde yeniden çalıştırın. Tutarlılık ödediğiniz kiradır.
Yapay zekâ modellerinin devreye alınması ve lansmandan sonra izlenmesi, sapmaları ve olayları tespit etmek için yapılır
Aşamalı dağıtım modelleri (örneğin gölge modu ve kademeli trafik artışı) kullanarak, tüm kullanıcı tabanınız hataları tespit etmeden önce sorunları bulun. Giriş kaymalarını (şema değişiklikleri, eksiklikler, dağıtım kaymaları) ve çıkış kaymalarını (puan kaymaları, sınıf dengesi kaymaları) izleyin, ayrıca gecikme ve maliyet gibi operasyonel sağlık göstergelerini de takip edin. Düzenlemeler, yükseltmeler ve şikayetler gibi geri bildirim sinyallerini izleyin ve segment düzeyindeki gerilemeleri gözlemleyin. Herhangi bir değişiklik olduğunda, aynı test ortamını yeniden çalıştırın ve sürekli olarak izlemeye devam edin.
Referanslar
[1] NIST - Yapay Zeka Risk Yönetimi Çerçevesi (AI RMF 1.0) (PDF)
[2] Mitchell vd. - “Model Raporlaması için Model Kartları” (arXiv:1810.03993)
[3] Gebru vd. - “Veri Kümeleri için Veri Sayfaları” (arXiv:1803.09010)
[4] scikit-learn - “Model seçimi ve değerlendirmesi” dokümantasyonu
[5] Liang vd. - “Dil Modellerinin Bütünsel Değerlendirilmesi” (arXiv:2211.09110)