Yeniden Üretilebilirlik ve Uçtan Uca Proje: Her Şeyi Birleştirmek

Kazanimlar:

• Yeniden üretilebilirliği dört sütunla (tohum sabitleme, veri sürümleme, ortam dondurma, deney izleme) sağlayabilme ve aynı koşuyu tekrarlayınca aynı sonucu üretebilme
• Modülün tüm duraklarını (metrik, veri, model, LLM bileşenleri, eval, adalet, güvenlik, dağıtım, izleme) uçtan uca bir zincirde birleştirebilme
• Her durakta kritik kararın insanda kaldığını doğrulayabilme ve projeyi denetlenebilir biçimde belgeleyebilme

Bir ML projesinin en sinsi başarısızlığı çökme değildir; "aynı sonucu bir daha alamamaktır." Üç ay önce üretime aldığınız modelin skorunu bugün yeniden üretemiyorsanız, o modeli gerçekten kontrol etmiyorsunuz demektir. Bu kapanış ünitesinde yeniden üretilebilirliği (reproducibility: aynı girdilerle aynı sonucu güvenilir biçimde elde edebilme) derinleştiriyor ve tüm modülü uçtan uca bir proje disiplininde birleştiriyoruz.

Yeniden üretilebilirlik neden zor

Sıradan yazılımda aynı kod aynı çıktıyı verir. ML'de sonucu belirleyen çok daha fazla değişken vardır:

• Rastgelelik: Veri karıştırma, ağırlık başlatma, veri bölme — hepsi rastgeleliğe dayanır.
• Veri: Aynı kod, farklı veri sürümüyle farklı model üretir.
• Ortam: Kütüphane sürümleri, donanım (CPU/GPU), hatta işletim sistemi sonucu değiştirebilir.
• Gizli durum: Kaydedilmeyen bir hiperparametre, elle yapılmış bir ön işleme adımı, not edilmemiş bir seçim.

Yeniden üretilebilirlik bir "iyi olsa hoş olur" değil, bilimsel ve mühendislik zorunluluğudur. Yeniden üretilemeyen bir sonuç, kanıtlanamayan bir iddiadır.

Yeniden üretilebilirliğin dört sütunu

1. Rastgeleliği sabitle. Tüm rastgelelik tohumlarını (random seed) tek bir yerden ayarlayın: veri bölme, model başlatma, veri karıştırma. Sabit tohum, "aynı koşuyu tekrarlayınca aynı sonuç" garantisinin temelidir.

2. Veriyi sürümle. Her deneyin hangi veri sürümüyle yapıldığını kaydedin (2. ünitedeki veri versiyonlama). "En son veri" belirsizdir; "veri sürümü v3, hash abc123" kesindir.

3. Ortamı dondur. Tüm bağımlılıkları kesin sürümleriyle sabitleyin (ör. requirements.txt içinde numpy==1.26.4 gibi kesin sürümler, veya bir konteyner imajı). "En son sürüm" bir gün her şeyi bozar.

4. Her şeyi izle (experiment tracking). Her deney için otomatik kaydedin: kod sürümü (git commit), veri sürümü, tüm hiperparametreler, metrikler ve çıktı yapıları. MLflow, Weights & Biases gibi deney izleme araçları bunu sistematik yapar. Kayıt olmadan "hangi ayar en iyiydi" sorusu cevapsız kalır.

Dikkat: "Sonra hatırlarım" en pahalı yanılgıdır. İki hafta sonra hangi tohumu, hangi veriyi, hangi hiperparametreyi kullandığınızı hatırlamazsınız. Otomatik izleme, hafızaya güvenmeyi ortadan kaldırır.

Zayıf yaklaşım / Güçlü yaklaşım

Zayıf: "En iyi modeli buldum, notebook'ta duruyor, skoru %89'du sanırım."

Güçlü: "Deney izleme aracında koşu #147: git commit a3f9c, veri sürümü v3 (hash abc123), seed 42, tüm hiperparametreler kayıtlı, test PR-AUC 0.887. Aynı komutu tekrar çalıştırdığımda bit-bit aynı sonucu alıyorum. Model registry'de bu koşuya bağlı."

Fark: güçlü yaklaşımda sonuç bir hafızaya değil, sabitlenmiş ve izlenen bir zincire dayanır. Herkes, her zaman aynı sonucu üretebilir.

Uçtan uca proje: modülün birleşimi

Şimdi tüm modülü tek bir proje akışında birleştirelim. Gerçek bir ML sistemi bu duraklardan geçer ve her durak bir öncekine dayanır:

1. Problem tanımı: Ne çözüyoruz, başarı nasıl ölçülür (3. ünite: doğru metrik, iş bağlamı). Metrik ve eşik baştan netleşir.
2. Veri hattı: Toplama, doğrulama, temizleme, sızıntısız bölme, sürümleme (2. ünite).
3. Model geliştirme: Eğitim, baseline karşılaştırması, çapraz doğrulama, sabit tohum (3. ünite + bu ünite).
4. LLM bileşenleri (varsa): RAG (4. ünite) ve/veya ajanlar (5. ünite); gerekiyorsa fine-tuning (6. ünite).
5. Değerlendirme: Kenar ve güvenlik vakalı eval kümesi, LLM sistemlerde çok katmanlı eval (8. ünite).
6. Adalet ve etik denetimi: Alt grup analizi, model kartı, açıklanabilirlik (10. ünite).
7. Güvenlik denetimi: Prompt injection, gizlilik, tedarik zinciri (9. ünite).
8. Dağıtım: Paketleme, kademeli dağıtım, geri alma, model registry (7. ünite).
9. İzleme: Üç katmanlı izleme, drift alarmları (8. ünite).
10. Yeniden üretilebilirlik: Tüm zincir boyunca tohum, veri sürümü, ortam ve deney izleme (bu ünite).

Bu akışta yapay zeka her durakta bir hızlandırıcı ve taslak üreticidir; ama metrik seçimi, veri kararları, adalet önceliği, dağıtım eşiği ve üretime alma onayı — kritik kararlar hep insanda kalır. Bu, modülün özüdür.

Belgeleme: geleceğin size teşekkürü

İyi bir ML projesi kendini belgeler. En az şunlar yazılı olmalı: problem ve başarı kriteri, veri kaynağı ve sürümü, model seçimleri ve gerekçeleri, değerlendirme sonuçları (alt gruplar dahil), bilinen sınırlar ve riskler, dağıtım ve geri alma prosedürü, izleme planı. Bu belge, altı ay sonra projeye dönen (belki de siz olan) kişinin en büyük dostudur.

Üç mini vaka

Vaka 1 - Kaybolan sonuç. Bir mühendis harika bir model eğitti ama tohumu sabitlememişti ve veri sürümünü kaydetmemişti. İşten ayrıldığında kimse o sonucu yeniden üretemedi; model bir "kara kutu efsanesine" dönüştü ve sonunda sıfırdan yapıldı. Haftalar boşa gitti. Ders: yeniden üretilemeyen sonuç, olmayan sonuçtur.

Vaka 2 - Ortam çöküşü. Bir ekip bağımlılıkları sabitlememişti. Bir kütüphane otomatik güncellenince model çıktıları sessizce değişti ve üretim bozuldu. Sorunu bulmak günler aldı. Bağımlılıklar kesin sürümlerle dondurulup konteynerlenince sorun bir daha yaşanmadı. Ders: ortamı dondur.

Vaka 3 - İzlemenin gücü. Bir ekip her deneyi otomatik izliyordu. Üç ay sonra bir regülasyon denetiminde "bu model hangi veriyle, hangi ayarlarla eğitildi, hangi gruplarda ne performans aldı" sorusuna dakikalar içinde tam kayıtla cevap verdiler. Denetim sorunsuz geçti. Ders: izleme, sadece mühendislik değil, uyumluluk aracıdır.

Kopyalanabilir şablonlar

Bu ML projesi için bir yeniden üretilebilirlik kontrolü yap.- Tüm rastgelelik tohumları sabitlenmiş mi (bölme, başlatma, karıştırma)?- Veri sürümü kaydediliyor mu?- Bağımlılıklar kesin sürümlerle donduruluş mu?- Her deney (kod commit, veri, hiperparametre, metrik) izleniyor mu?Eksik her sütun için nasıl düzelteceğimi somut adımlarla yaz.Proje yapısı: [açıklama]

Bu uçtan uca ML projesi için bir plan iskeleti üret.Problem: [açıklama]Şu durakları kapsa ve her durakta İNSAN kararının nerede olduğunu işaretle:problem/metrik, veri hattı, model, (RAG/ajan/fine-tune?), eval, adalet, güvenlik,dağıtım, izleme, reproducibility.Her durak için ana risk ve doğrulama adımını yaz.

Bu proje için bir teknik dokümantasyon şablonu üret.Bölümler: problem+başarı kriteri, veri (kaynak+sürüm), model seçimleri+gerekçe,değerlendirme (alt gruplar dahil), bilinen sınırlar+riskler, dağıtım+geri alma, izleme planı.Her bölüm için doldurulacak alanları soru olarak ver.

Deney izleme kurulumumu denetle:Her koşuda otomatik kaydediliyor mu: git commit, veri sürümü/hash, tüm hiperparametreler,tüm metrikler, çevre (kütüphane sürümleri)?Aynı koşuyu tekrar çalıştırınca aynı sonucu alıyor muyum?Kurulum: [açıklama]. Eksikleri ve düzeltmeyi listele.

Reproducibility sütunları tablosu

Sütun

Ne sabitlenir

Araç örneği

Rastgelelik

Tüm tohumlar

seed ayarı

Veri

Veri sürümü/hash

DVC

Ortam

Kütüphane sürümleri

requirements pin, Docker

İzleme

Kod+veri+ayar+metrik

MLflow, W&B

Sık yapılan hatalar

• Tohumu sabitlememek. Sonuç tekrarlanamaz.
• Veri sürümünü kaydetmemek. "Hangi veriyle?" cevapsız kalır.
• Bağımlılıkları dondurmamak. Bir güncelleme her şeyi sessizce bozar.
• Deneyleri hafızaya bırakmak. İki hafta sonra hiçbir şey hatırlanmaz.
• Kritik kararları yapay zekaya bırakmak. Metrik, adalet, dağıtım kararı insanda kalmalı.
• Belgelemeyi ertelemek. Gelecekteki ekip (ve siz) bedelini öder.

Ozetle

Yeniden üretilebilirlik, ciddi ML mühendisliğinin imzasıdır: yeniden üretilemeyen sonuç, kanıtlanamayan iddiadır. Dört sütunla sağlanır — rastgeleliği sabitle, veriyi sürümle, ortamı dondur, her deneyi izle. Uçtan uca bir proje, bu modülün tüm duraklarını (metrik, veri, model, LLM bileşenleri, eval, adalet, güvenlik, dağıtım, izleme) birbirine dayalı bir zincirde birleştirir; yapay zeka her durakta hızlandırıcıdır ama kritik kararlar insanda kalır. Her şeyi belgeleyin — gelecekteki ekip ve denetimler için. Bu disiplin, modül boyunca öğrendiğiniz her şeyi ayakta tutan çerçevedir.

Uygulama gorevi

Bir ML projeni dört reproducibility sütununa göre denetle: tohumlar sabit mi, veri sürümlü mü, ortam donduruldu mu, deneyler izleniyor mu? Eksik her sütunu düzelt ve aynı koşuyu iki kez çalıştırıp aynı sonucu aldığını kanıtla. Ardından projenin uçtan uca akışını (10 durak) tek sayfada çıkar ve her durakta "insan kararının nerede olduğunu" işaretle. Son olarak kısa bir teknik dokümantasyon taslağı yaz.

Kontrol listesi

• [ ] Tüm rastgelelik tohumları sabitlendi.
• [ ] Veri sürümü/hash her deneyde kaydediliyor.
• [ ] Bağımlılıklar kesin sürümlerle donduruldu (pin/konteyner).
• [ ] Her deney otomatik izleniyor (kod+veri+ayar+metrik).
• [ ] Aynı koşuyu tekrarlayınca aynı sonucu alıyorum.
• [ ] Uçtan uca akışta kritik kararların insanda olduğunu doğruladım ve belgeledim.

Modul Sinavi

1. Bir ML mühendisi olarak yapay zekayı iş akışında konumlandırırken en doğru yaklaşım hangisidir?

• A) Yapay zeka düşük riskli işlerde hızlandırıcıdır; metrik, veri ve üretime alma gibi kritik kararlar doğrulanarak insanda kalır ✔
• B) Yapay zeka çıktıları güzel göründüğü sürece doğrulamaya gerek yoktur
• C) Modeli üretime alma kararını da yapay zekaya bırakmak zamandan kazandırır
• D) Yapay zeka yalnızca metin yazmaya yarar, veri ve model işleriyle ilgisi yoktur

Aciklama: Yapay zeka kod, veri özeti ve doküman gibi düşük riskli, kolay doğrulanan işlerde güçlü bir hızlandırıcıdır; ancak metrik seçimi, hangi verinin eğitime gireceği ve modeli üretime alma gibi para, gizlilik ve yasal yükümlülük etkileyen kararların sorumluluğu yetkin mühendise ve ekibe aittir. Her çıktı doğrulanmadan kullanılmamalıdır.

2. Bir veri hattında şema doğrulaması (schema validation) neden hattın en başına konur?

• A) Modelin doğruluğunu doğrudan artırdığı için
• B) Veri sürümlemeyi gereksiz kıldığı için
• C) Bozuk veriyi en erken ve en ucuz noktada yakalayıp sonraki adımlara sızmasını engellediği için ✔
• D) Etiketleme ihtiyacını ortadan kaldırdığı için

Aciklama: Bozuk veri ne kadar erken yakalanırsa düzeltmesi o kadar ucuzdur. Şema doğrulaması hattın başında, beklenen tip ve aralık dışındaki veriyi (ör. birim değişimiyle 100 kat kayan fiyat) reddederek bozuk verinin eğitime veya üretime sessizce sızmasını engeller; üretimde yakalanan aynı hata katbekat pahalıdır.

3. Zaman içeren (zaman serisi) bir problemde veriyi eğitim ve test olarak bölerken doğru yaklaşım nedir?

• A) Rastgele bölme kullanmak, çünkü her zaman en adil yöntemdir
• B) Zamansal bölme kullanmak: geçmişle eğitip gelecekte test ederek sızıntıyı önlemek ✔
• C) Tüm veriyi hem eğitim hem test olarak kullanmak
• D) Test verisini eğitimden önce ölçekleme parametrelerine dahil etmek

Aciklama: Zaman serilerinde rastgele bölme, modele üretimde asla olmayacak bir 'geleceği görme' avantajı verir ve metrikleri yapay olarak şişirir (zamansal sızıntı). Doğrusu zamansal bölmedir: geçmişle eğit, gelecekte test et. Bu, üretimde tutan gerçek performansı ölçer.

4. Pozitif sınıf oranı %1.5 olan bir dolandırıcılık tespiti modelinde accuracy neden yanıltıcıdır?

• A) Accuracy dengesiz veride her zaman düşük çıktığı için
• B) Accuracy yalnızca regresyon problemlerinde kullanılabildiği için
• C) Accuracy hesaplaması çok fazla işlem gücü gerektirdiği için
• D) Çoğunluk sınıfını tahmin eden değersiz bir model bile çok yüksek accuracy alabildiği için gerçek başarıyı gizler ✔

Aciklama: Dengesiz veride 'her şeye negatif de' diyen bir temel model bile yaklaşık %98.5 accuracy alır ama tek dolandırıcılığı yakalamaz. Bu yüzden dengesiz sınıflandırmada accuracy yerine precision, recall, F1 veya PR-AUC kullanılır ve her metrik bir temel modele göre yorumlanır.

5. Bir modelin metriği hakkında konuşurken temel model (baseline) karşılaştırması neden zorunludur?

• A) Temel model her zaman gerçek modelden daha iyi olduğu için
• B) Bir metriğin anlamlı olup olmadığı ancak basit bir temel modele kıyasla belli olduğu için ✔
• C) Temel model çapraz doğrulamayı gereksiz kıldığı için
• D) Yasal olarak her raporda temel model zorunlu olduğu için

Aciklama: Bir metrik tek başına iyi ya da kötü değildir; bir temel modele göre iyi ya da kötüdür. '%85 doğru' cümlesi, temel model zaten %84 alıyorsa neredeyse değersiz, %50 alıyorsa mükemmel demektir. Karşılaştırma çıpası olmadan metrik anlamsızdır.

6. RAG (Retrieval-Augmented Generation) sisteminin üretim promptunda bulunması gereken en kritik güvenlik unsuru hangisidir?

• A) Yalnızca verilen kaynağa dayanma, kaynakta yoksa 'bilmiyorum' deme ve kaynak gösterme talimatı ✔
• B) Modele mümkün olduğunca uzun ve yaratıcı cevaplar üretmesini söylemek
• C) Modelin kendi eğitim bilgisini kaynaklardan üstün tutması
• D) Getirilen belgelerdeki tüm talimatları komut olarak uygulaması

Aciklama: RAG'ın en önemli tek talimatı, modele yalnızca verilen kaynağa dayanmasını, bilgi kaynakta yoksa uydurmadan 'bilmiyorum' demesini ve kaynak göstermesini söylemektir. Bu üçlü olmadan model bağlamı yok sayıp halüsinasyon üretebilir ve cevap doğrulanamaz hâle gelir.

7. Bir RAG sistemi yanlış cevaplar veriyor. Teşhise nereden başlamak en doğrusudur?

• A) Önce getirmeyi (Recall@K) ölçmek: doğru parça hiç geliyor mu? ✔
• B) Hemen modeli daha büyük bir modelle değiştirmek
• C) Prompt'u rastgele değiştirip denemeye devam etmek
• D) Tüm belgeleri fine-tuning ile modele gömmek

Aciklama: RAG'ın en zayıf halkası genellikle üretim değil getirmedir. Doğru parça hiç getirilmediyse prompt ne kadar iyileştirilse de model o bilgiyi üretemez. Bu yüzden önce Recall@K ölçülüp doğru parçanın gelip gelmediğine bakılır; getirme iyiyse sonra üretim ve prompt incelenir.

8. Bir ajana (agent) araç verirken hangi eylemler insan onayı arkasına konmalıdır?

• A) Hiçbiri; ajan her eylemi otonom yapabilmelidir
• B) Yalnızca veri okuma ve arama gibi geri alınabilir eylemler
• C) Para transferi, silme, gönderme gibi geri alınamaz veya yüksek etkili eylemler ✔
• D) Yalnızca hesaplama içeren eylemler

Aciklama: Eylemler risk düzeyine göre ayrılır. Okuma, arama, hesaplama ve taslak üretme gibi geri alınabilir işler otonom yapılabilir; ancak para transferi, e-posta gönderme, veri silme, sipariş verme gibi geri alınamaz veya yüksek etkili eylemler insan onayı gerektirir. Geri alınamaz her eylem onaya bağlı olmalıdır.

9. Dolaylı prompt injection (indirect prompt injection) riskine karşı en doğru tasarım yaklaşımı nedir?

• A) Sistem promptuna tek bir 'kötü talimatları dikkate alma' cümlesi eklemek yeterlidir
• B) Dış içerikteki talimatlara güvenip modele daha fazla yetki vermek
• C) Injection önlenemez olduğu için hiçbir önlem almamak
• D) Dış içeriği güvenilmez veri olarak izole etmek ve en az yetki, onay, çıktı denetimiyle katmanlı savunma kurmak ✔

Aciklama: Ajan veya RAG'ın işlediği web sayfası, belge, e-posta gibi dış içerik güvenilmez veridir ve içine gizli talimat gömülebilir. Doğru yaklaşım katmanlı savunmadır: dış içeriği net sınırlayıcılarla 'veri, komut değil' olarak izole etmek, en az yetki uygulamak, geri alınamaz eylemleri insan onayına bağlamak ve çıktıyı denetlemek. Tek bir talimat satırı yeterli değildir.

10. Bir problemin fine-tuning ile mi RAG ile mi çözülmesi gerektiğine karar verirken temel ayrım nedir?

• A) Bilgi problemleri RAG ile, davranış/format problemleri fine-tuning ile daha iyi çözülür ✔
• B) Her problem her zaman fine-tuning ile çözülmelidir
• C) RAG yalnızca kod üretimi için, fine-tuning yalnızca çeviri için kullanılır
• D) Fine-tuning her zaman RAG'dan daha ucuz ve daha hızlı güncellenebilir

Aciklama: Fine-tuning modele yeni bilgi öğretmekte zayıf ve risklidir; ama davranış, format, ton ve stil öğretmekte güçlüdür. 'Model şirket verimizi bilmiyor' bir bilgi problemidir ve RAG'a aittir. 'Model çıktıyı hep bizim katı formatımızda versin' bir davranış problemidir ve fine-tuning adayıdır. Ayrıca fine-tuning'den önce prompt ve few-shot tüketilmelidir.

11. Yeni bir modeli üretime alırken güvenli dağıtım açısından hangisi zorunludur?

• A) Modeli testte iyiyse doğrudan %100 trafiğe açmak
• B) İzlemeyi dağıtımdan sonra hiç kurmamak
• C) Kademeli dağıtım (gölge/kanarya) ve önceden test edilmiş bir geri alma planı ✔
• D) Değerlendirme eşiği tutmasa bile modeli yayınlamak

Aciklama: Yeni modeli doğrudan tüm trafiğe açmak risklidir; yanlışsa herkes etkilenir. Doğrusu kademeli dağıtımdır (gölge, kanarya) ve her dağıtımın test edilmiş bir geri alma (rollback) planı olmasıdır. Geri alma planı olmayan bir dağıtım tamamlanmış sayılmaz; model üretimde beklenmedik davrandığında dakikalar içinde eski sürüme dönebilmek kullanıcıyı korur.

12. Bir ML modeli üretimde 'sessizce' nasıl başarısız olabilir ve bunu yakalamanın yolu nedir?

• A) Model çökerek; bunu sunucu logları gösterir
• B) Hata vermeden yanlış tahmin üreterek; bunu operasyonel, girdi ve çıktı katmanlı izleme yakalar ✔
• C) Model asla sessizce başarısız olamaz, her zaman alarm verir
• D) Yalnızca gecikmeyi (latency) izlemek her tür bozulmayı yakalamaya yeter

Aciklama: Model, çökmeden ve hata vermeden sadece yanlış tahminler üreterek başarısız olabilir; bunun başlıca nedeni veri kayması (data drift) ve kavram kaymasıdır. Sadece operasyonel metrik (gecikme, hata oranı) izlemek yetmez; girdi dağılımı ve çıktı/tahmin dağılımı da izlenmelidir. Gerçek sonuç gecikmeliyse girdi kayması erken uyarı verir.

13. Bir LLM sistemini değerlendirmede LLM-hakem (LLM-as-judge) kullanırken hangi ilke şarttır?

• A) LLM-hakem her zaman doğrudur, insan doğrulaması gereksizdir
• B) Hakem yalnızca cevap uzunluğuna bakarak karar vermelidir
• C) Hakem kullanıldığında kural tabanlı kontroller ve insan değerlendirmesi tamamen atılmalıdır
• D) Hakem skorları, güvenilmeden önce insan etiketli bir örneklemle kalibre edilmeli ve yanlılığı ölçülmelidir ✔

Aciklama: LLM-hakem de bir modeldir; halüsinasyon yapar, taraflıdır (uzun ve kendinden emin cevapları kayırabilir) ve tutarsız olabilir. Bu yüzden hakem skorları üretim kararı yapılmadan önce mutlaka bir insan etiketli örneklemle kalibre edilmeli, sistematik yanlılığı ölçülmelidir. Doğrulanmamış hakem yanlış bir güven verir.

14. Model önyargısını (bias) değerlendirirken genel doğruluğa bakmak neden yetersizdir?

• A) Genel doğruluk her zaman en kötü grubun performansını yansıttığı için yeterlidir
• B) Genel doğruluk, alt gruplar arasındaki sistematik farkı (gizli ayrımcılığı) örtebildiği için tek başına yetersizdir ✔
• C) Doğruluk önyargıyla hiçbir ilişkisi olmayan bir metrik olduğu için
• D) Önyargı yalnızca modelden gelir, veriyle ilgisi olmadığı için

Aciklama: Genel doğruluk, alt gruplar arasındaki sistematik farkı gizleyebilir. Örneğin genel doğruluk %88 iken bir grupta recall %91, başka bir grupta %67 olabilir; model o grubu sistematik kaçırıyordur. Bu yüzden model alt gruplar (demografi/segment) bazında değerlendirilmeli ve hangi adalet tanımının önceleneceği paydaşlarla kararlaştırılmalıdır.

15. Bir ML sonucunun yeniden üretilebilir (reproducible) olması için hangi dört şey birlikte sabitlenmelidir?

• A) Yalnızca modelin adı, boyutu, fiyatı ve yayın tarihi
• B) Yalnızca GPU markası ve internet hızı
• C) Sadece modelin son doğruluk skoru; gerisi hafızada tutulabilir
• D) Rastgelelik tohumu, veri sürümü, ortam (bağımlılık sürümleri) ve deney izleme ✔

Aciklama: Yeniden üretilebilirlik dört sütunla sağlanır: rastgelelik tohumlarını sabitlemek, veriyi sürümlemek (versiyon/hash), ortamı dondurmak (kesin kütüphane sürümleri/konteyner) ve her deneyi izlemek (kod commit, veri, hiperparametre, metrik). Bu zincir olmadan aynı sonucu tekrar üretmek mümkün değildir; yeniden üretilemeyen sonuç kanıtlanamayan iddiadır.