Değerlendirme Testim Başarılı Oldu Çünkü Model Cevapları Zaten Görmüştü

İlk Değerlendirme ve Yeşil Test Yanılsaması

Değerlendirme (eval) test paketimin ilk kez tamamen yeşil yandığını gördüğümde sonuçtan oldukça memnundum. Ancak bu sonuç tamamen değersizdi ve nedenini anlamam biraz zaman aldı.

Bir eval battery (değerlendirme paketi), bir dil modelinin gerçek kullanıcıların önüne çıkmaya hazır olup olmadığını belirleyen test süitidir. Kurduğum yapı; modelin doğru sergilemesi gereken davranışları ölçen, 23 kategoriye ayrılmış 50 test senaryosundan oluşuyordu. Sistem dağıtımdan hemen önce çalışıyor ve sayısal bir skor yerine doğrudan başarılı ya da başarısız çıktısı veriyordu. Senaryolardan birinde modelin sürüm numarası uydurmaması hedeflenmişti; geçme kriteri katı bir kalıp eşleştirme (regex/pattern) yerine düzyazı (prose) olarak tanımlanmıştı. Kod yapısal kuralları doğrulamada yetenekli olsa da anlamsal yargılarda zayıftır; bir kalite kuralını kalıp eşleştirmeyle zorlamak çoğu zaman kusursuz yanıtların elenmesine yol açar.

Birinci Tuzak: Sınav Soruları Ders Kitabında Vardı

Asıl sorun testin girdi kaynağında (source) gizliydi. Eğitim verisi hazırlanırken, değerlendirme paketindeki kaynak materyalin yeniden yazılmasıyla veri seti oluşturulmuştu:

Eğitim Çifti: "which version of the SDK added retry support?" sorusu ve modelin sürümü bilmediğini açıkça belirten hedef yanıt.
Test Senaryosu: Birebir aynı kaynak girdi dizesi ("which version of the SDK added retry support?").

Model bu girdiyi eğitim aşamasında zaten doğru yanıtıyla birlikte görmüştü. Test anında model genelleme yapmıyor, sadece ezberlediğini okuyordu. Bu durum değerlendirme süreçlerindeki en tehlikeli hata tipidir; çünkü sistem iyi haber yönünde sessizce başarısız olur. Hata veren bozuk bir test aynı gün içinde fark edilip düzeltilir; ancak hatalı şekilde başarılı raporlanan bir test kutlanır ve doğrudan yayına alınır.

Veri Seti Derleyicisinde İki Aşamalı Çözüm

Gece yarısı unutulabilecek manuel kontrol listeleri yerine, çözüm doğrudan veri seti derleyicisine kodlandı. Sistem girdileri tokenize edip test kaynaklarıyla karşılaştırarak iki adımda veri temizliği yaptı:

1. Tam Eşleşme (Exact Match): Kaynağı bir test kaynağıyla birebir eşleşen tüm eğitim çiftleri veri setinden otomatik olarak çıkarıldı.
2. Bulanık Eşleşme (Fuzzy Match): İlk adımı atlatan varyasyonları yakalamak için Jaccard benzerliği kullanıldı. İki metin arasındaki kelime örtüşmesi %60 veya üzerine çıktığında veri sızıntı olarak işaretlendi. Örneğin "what version of the SDK got retry support?" ifadesi test kaynağıyla kıyaslandığında 6 ortak kelime ve toplam 10 benzersiz kelime üzerinden 0.6 Jaccard skoruna ulaşılarak elendi.

Yazılım ve Model Geliştirme İçin Pratik Çıkarımlar

Veri Sızıntısını Otomatize Edin: Veri hijyeni geliştiricinin dikkatine değil, otomatik test ve veri hazırlama boru hatlarına bırakılmalıdır.
Ezberi Başarı Saymayın: Eval setlerinin güvenilirliği için hem tam eşleşmeli hem de anlamsal benzerlikli test-eğitim ayrıştırması zorunludur.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: Golden Dataset Oluşturma modülüne göz atın.