Kanıt incelemesi: geliştirici belgeleri ve yeterlilik
Bir belgenin bulunması, içindeki iddianın doğrulanmış olduğu anlamına gelmez. İddia, yöntem, veri, sonuç ve yeniden üretilebilirlik birbirine bağlanır.
kanıt merdiveni: her kanıt eşit doğmaz
Validasyonun hammaddesi kanıttır — ama "kanıt" kelimesi, birbirinden çok farklı güçte şeyleri kapsar. Review'a başlamadan önce zihnindeki merdiven net olmalı:
Zayıf
Beyan
"Test ettik, sorun yok." Toplantı notu, e-posta cümlesi, sunum slaytı. Tek başına hiçbir bulguyu kapatmaz, hiçbir onayı taşımaz.
Orta
Doküman
Metodoloji dokümanı, model card, tasarım kararları. Niyeti ve süreci gösterir — sonucu göstermez. "Nasıl test edeceğiz" ile "test ettik ve şu çıktı" farklıdır.
Güçlü
Sonuç
Test çıktıları: metrik tabloları, eval koşum sonuçları, log kayıtları. Gerçek kanıt burada başlar — ama üretilme koşulları (hangi veri, hangi versiyon, ne zaman) belgeliyse.
En güçlü
Yeniden üretilebilir sonuç
Test, yetkili bağımsız incelemeyle yeniden çalıştırılabilir; sonuç veya beklenen istatistiksel tutarlılık doğrulanabilir. Kod + veri + ortam erişimi. Evidence review'un altın standardı.
Evidence review'un tek cümlelik tanımı: geliştiricinin kanıtlarını merdivende yukarı itme süreci. Beyanla gelen her iddia için doküman, dokümanla gelen her iddia için sonuç, kritik her sonuç için yeniden üretim istersin. Nereye kadar? Tier'a kadar (Modül 09): Tier 1'de kritik iddialar 4. basamağa çıkmalı; Tier 3'te 2-3. basamak yetebilir. Bu eşleştirmenin kendisi de scoping kararının parçasıdır ve planda yazar.
AI'ın buraya eklediği özel zorluk: olasılıksal sistemlerde "aynı sonucu almak" birebir eşleşme değil, istatistiksel tutarlılık demektir (Modül 01). Yeniden üretim protokolü bunu baştan tanımlamalı: aynı test seti, sabitlenmiş versiyon/ayarlar, sonucun güven aralığı içinde kalması. Bunu tanımlamadan "sonucu tekrarlayamadık" tartışması çıkar ve haklı olan taraf belli olmaz.
ai evidence paketi: altı bileşene tıkla
Klasik model validasyonunda paket bellidir: geliştirme dokümanı, veri sözlüğü, test sonuçları. AI sistemi için paket genişler. Aşağıdaki altı bileşenin her biri için iki soruya bak: ne içermeli, hangi eksik en sık görülür?
Sistem/model kartı
Veri soyağacı (data lineage)
Eval tasarımı ve sonuçları
Kontrol testleri (guardrail, güvenlik, HITL)
Sınırlılıklar ve bilinen zayıflıklar
Operasyonel plan (izleme, değişiklik, geri çekilme)
Paketin en değerli ve en nadir bileşeni beşincisidir: sınırlılıklar. "Bu sistem nerede kötü?" sorusuna içerikli cevap veren geliştirme ekibi, işini bilen ekiptir. Sınırlılıklar bölümü boş veya jenerikse ("her modelin sınırları vardır"), bu tek başına bir bulgudur: ekip ya kendi sistemini yeterince test etmemiş ya da zayıflıklarını yazmaktan kaçınıyor. İkisi de review'un derinleşmesi gerektiğini söyler.
yeterlilik testi: dört soru
Önündeki her kanıt parçasına dört soruyu sor. Dördü de geçerse kanıt yeterlidir; herhangi biri düşerse eksiği talep edersin:
1 · İlgililik: Kanıt, iddia edilen şeyi mi gösteriyor? En yaygın kayma: genel benchmark sonucunun use-case iddiasına kanıt diye sunulması ("MMLU'da %89" → "mevzuat sorularında doğru" iddiasını göstermez). 2 · Güncellik: Kanıt, şu anki sistem versiyonu için mi üretildi? Üç prompt değişikliği önceki eval sonucu, bugünün sistemine tek başına yeterli kanıt değildir (Modül 02'nin değişiklik matrisi). 3 · Bağımsızlık ve bütünlük: Kanıtı kim üretti, seçilmiş mi? "En iyi 50 örnek" sunulmuş olabilir — örnekleme protokolünü sor: test seti nasıl seçildi, kaç koşumun sonucu, başarısız koşumlar nerede? 4 · Yeniden üretilebilirlik: Kritik iddiaysa: aynı testi koşabilir misin? Koşamıyorsan (erişim yok, veri yok), bu kanıt merdivenin 3. basamağında kalır ve raporda öyle etiketlenir.
Validasyon lensi: Yeterlilik değerlendirmesi ikili değil, kademelidir — ve raporda görünmelidir. İyi pratik, her kanıt kalemine bir etiket vermektir: yeterli / koşullu yeterli (şu eksikle) / yetersiz (şu talep edildi). Bu etiketleme, "evidence review yaptık" cümlesini denetlenebilir bir işleme çevirir — ve model sahibiyle pazarlığı kişisellikten çıkarıp kriter tartışmasına döndürür.
dosya incelemesi: yeterli mi, yetersiz mi?
Şimdi masanda bir onay dosyası var: "KrediAsist" — kredi tahsis ekibine politika sorularında cevap veren RAG'li asistan (Tier 1, müşteri kararlarına dolaylı etki). Geliştirme ekibinin paketinden altı kanıt kalemi aşağıda. Her biri için karar ver: Tier 1 dosyası için yeterli mi, yetersiz mi?
Bir belgenin bulunması, içindeki iddianın doğrulanmış olduğu anlamına gelmez. İddia, yöntem, veri, sonuç ve yeniden üretilebilirlik birbirine bağlanır.
Kanıt açığı ile kanıtlanmış başarısızlık farklı bulgulardır. Her ikisinin karar üzerindeki etkisi, kullanımın kritikliği ve alternatif kontrollerle birlikte açıklanır.
anahtar çıkarımlar
kanıtları merdivende yukarı it
Beyan < doküman < sonuç < yeniden üretilebilir sonuç. Evidence review, kanıtı iddianın kritikliğiyle orantılı basamağa taşıma sürecidir; hedef basamak tier'dan türer ve planda yazar.
dört soru: ilgili mi, güncel mi, bütün mü, tekrarlanabilir mi
Genel benchmark use-case iddiasını kanıtlamaz; eski versiyonun sonucu bugünü kanıtlamaz; seçilmiş örnekler dağılımı kanıtlamaz. Her kaleme etiket: yeterli / koşullu / yetersiz.
boş sınırlılıklar bölümü, başlı başına bulgudur
"Bu sistem nerede kötü?" sorusuna içerikli cevap veremeyen ekip, ya yeterince test etmemiştir ya yazmaktan kaçınmaktadır. İkisi de review'un derinleşme sinyalidir.
Senaryo: Dosyada model kartı, SOC 2, pazarlama benchmark’ı ve ekran görüntüleri var; ham sonuç, protokol, sürüm ve kurum bağlamında bağımsız koşum yok. İş birimi 200 sayfayı kanıt sayıyor.
Örnek değerlendirmeyi aç
DeğerlendirmeBelge hacmini yeterlilik sayma. SOC 2’yi yalnız kapsamındaki kontroller için kabul et; performans iddiasını ilgili, güncel, yeniden üretilebilir ve bağlama uygun kanıt gelene kadar açık bırak.
Gerekli kanıtRapor kapsamı/istisna; sürüm; örneklem; ham sonuç; protokol; başarısız vaka; bağımsızlık; kurum golden seti; önceden tanımlı eşik.
Karar kaydıEvidence gap log: iddia, mevcut kanıt, açık soru, minimum talep, sahip/termin, görüşe etki ve kapanış doğrulaması.