Bilgi merkezi

Risk Modelleme

Doğru hesap, doğru model demek değildir

Verification ile validation neden farklı? Statik kontroller, analitik referanslar, model card ve gerçeklik sınamasını ayırın.

Bir simülasyonun referans testleri geçmesi önemli bir başarıdır. Ancak doğru kod, her zaman doğru problem modeli değildir. Poisson sayısını hatasız üreten, birimleri tutarlı işleyen ve sonuçları tekrar üreten bir hesap; yanlış olay hızı veya eksik maliyet bileşeniyle yine yanıltıcı karar desteği verebilir.

Bu ayrımı anlatmak için verification ve validation kavramları kullanılır. Basitçe, ilk soru “tanımlanan hesabı doğru uyguladık mı?”, ikinci soru “bu model belirlenen amaç için yeterli mi?” olur. Tek bir yeşil onay işareti, ikisine birden yanıt vermez.

Verification: Uygulamanın matematiksel kontrolü

Verification, yazılımın ve hesap akışının tanımlanan matematiksel kurallara uygunluğunu inceleyebilir. Parametrelerin doğru okunması, birim dönüşümü, dağılım örneklemesi, toplama ve metrik hesabı bu kapsamdadır. Hangi şartlarda hangi kontrolün yapıldığı açık olmalıdır.

Bilinen analitik örnekler bu iş için yararlıdır. Bir Poisson değişkeninin ortalaması ve varyansı λ'dır. Uniform(a,b) değişkeninin beklenen değeri (a+b)/2 olur. Uygun bağımsızlık koşullarındaki bileşik kayıp, beklenen değer açısından E[N] × E[X] referansını sağlar.

Bu kontroller sayısal motorun hatalarını yakalamaya yardımcı olur. Fakat “Poisson örnekleyici test edildi” ile “tesisin olay sayısı Poisson dağılıyor” ayrı iddialardır. Birincisi aracın uygulanışı, ikincisi model seçiminin gerçek problemle ilişkisi hakkındadır.

Statik kontrol neyi yakalar?

Tipli compiler veya validator; eksik referans, yasak döngü, parametre alanı ve boyutsal tutarsızlık gibi hataları koşudan önce yakalayabilir. Bir düğüm saat, diğeri TL/saat ise çarpım TL olur. Saat ile TL'yi doğrudan toplamak ise modelin tanımında anlam sorunu yaratır.

Benzer biçimde sıfıra bölme veya negatif bir logaritma girdisi için uygun kontroller gerekir. Bazı alan hataları statik olarak saptanabilir, bazıları rastlantısal değerler veya koşullu dallar nedeniyle çalışma zamanında ortaya çıkar. Her hata için aynı tespit garantisi verilmemelidir.

Bir model bu aşamayı geçtiğinde “çalıştırılabilir” veya “yapısal kontrollerden geçti” denebilir. “İşletmenin gerçek riskini doğru ölçer” sonucuna henüz varılamaz. Kullanıcı arayüzünün etiketi bu farkı korumalıdır.

Rastlantısal testler neden dikkat ister?

Monte Carlo ortalamasını analitik değere bire bir eşitleyen test, doğal örnekleme değişkenliği nedeniyle kırılgan olabilir. Kabul kriteri yönteme uygun hata/toleransla kurulmalıdır. Örnek sayısı, varyans, dağılım koşulları ve yanlış alarm riski dikkate alınır.

Birden fazla istatistiksel testi tekrar tekrar yürütmek, bazı sonuçların tesadüfen eşik dışında kalmasına neden olabilir. Seed seçerek yalnızca “geçen” sonucu göstermek kalite kanıtı değildir. Test tasarımı ve geçme/kalmaya ilişkin mantık önceden tanımlanmalıdır.

Property-based testler farklı parametre aralıklarını araştırabilir: support'a uygunluk, monoton CDF ve birim invariant'ları gibi. Bağımsız referans araçla karşılaştırma başka tür hataları yakalayabilir. Bu katmanlar birbirini tamamlar; tek bir test türü her sorunu çözmez.

Validation: Model amaca uygun mu?

Validation, modelin kullanım amacına göre veri ve mekanizma incelemesidir. Bir model bütçe ortalaması için yeterli olabilirken büyük kayıpların kuyruğu için yetersiz kalabilir. “Doğru model” ifadesinin bağlamdan bağımsız tek bir anlamı yoktur.

Veri kapsamı, gözlem süresi, raporlanmayan olaylar ve işletme koşullarının değişmesi incelenmelidir. Dağılım ailesi, parametre belirsizliği ve bağımlılık yapısı sorgulanır. Uygun yerde posterior predictive checks veya backtesting yapılabilir; veri azsa hangi kontrolün yapılamadığı açıkça söylenir.

Geçmiş veriye iyi uyum da geleceği garanti etmez. Süreç değişmiş olabilir veya kuyrukta yeterli gözlem olmayabilir. Bir parametreyi tahmin etmek için kullanılan veriyle yapılan uygunluk testinin yorumu da yöntemsel ayrıntı gerektirir. Sırf küçük bir p-value veya tek bir grafikle model hakkında tüm karar verilemez.

Doğru hesapla yanlış sonuca örnek

Üretim arızası örneğinde yılda ortalama altı olay ve olay başına 50.000 TL beklenen tamir maliyeti varsayımı, yalnızca tamir için 300.000 TL/yıl beklenen değer verir. Bu hesabın aritmetiği doğrudur.

Ancak kullanıcı bunu “tesisin toplam yıllık arıza kaybı” olarak etiketlerse modelin kapsamı yanlış anlatılır. Duruş süresi ve saatlik üretim kaybı eksiktir. Solver ne kadar doğru çalışırsa çalışsın, olmayan bileşeni hesaplayamaz. Eksikliği sıfır kabul etmek ayrı bir varsayımdır ve açıkça yazılmalıdır.

Aynı şekilde tüm olayların bağımsız olduğu kabulü, ortak altyapı arızasında geçerli olmayabilir. Bu nedenle ortalama, kuyruk ve portföy çıktıları farklı varsayımlara duyarlı olabilir. Validation, bu bağlantıyı görünür kılar.

AI açıklaması neden kanıt değildir?

AI bir tutarsızlık önerebilir, kaynak bulabilir veya deney tasarlayabilir. İkna edici bir cümle, modelin doğrulandığı anlamına gelmez. “Bu dağılım uygundur” önerisi ile gözlenen veri ve uygun yöntemle elde edilen fitting bulgusu ayrı etiketlenmelidir.

Sayısal iddialar mevcut koşu çıktısına bağlanmalı; kalıcı model değişikliği onaydan geçmelidir. Bir açıklama hipotezse test önerisiyle birlikte sunulur. Risk Studio güven yaklaşımı bunları hedef ürün ilkeleri olarak tanımlar; bugün tamamlanmış ajan veya matematik motoru iddiası yapmaz.

Tek skor yerine model card

İnceleme kaydı şu soruları yanıtlamalı:

  • Modelin amacı ve kapsamı nedir?
  • Girdiler gözlem, tahmin veya uzman varsayımı mı?
  • Hangi yapısal ve sayısal testler yapıldı?
  • Hangi gerçeklik/uygunluk kontrolleri mümkün oldu?
  • Hangi varsayımlar sınanamadı veya hassas bulundu?
  • Sonuç hangi sürüm, veri ve ayarlardan üretildi?
  • Model hangi kararda kullanılmamalı?

Bu kayıt karar vereni riskten tamamen arındırmaz. Ancak belirsizliğin ve kanıtın nerede bulunduğunu gösterir. Tek bir “güven: %98” rozeti yerine somut kontroller ve sınırların görünmesi daha savunulabilir bir yaklaşım sağlar.

Kaynak ve yayın notu

AI desteğiyle hazırlanmıştır. Örnek hesaplar kontrol edilmiştir. Bu yazı bağımsız uzman onayı, sertifikasyon veya çalışan Risk Studio test raporu değildir.

Yöntem yazısı · Örnekler eğitim amaçlıdır. Risk Studio konseptine ait çalışan ürün sonuçları değildir.

Örnek modeli incele ↗