Bozuk benchmark: testin kendisini denetlemek
Separating signal from noise in coding evaluations
Model yeteneklerini doğru ölçmek, dağıtım ve güvenlik kararları için kritik. Değerlendirmelerin kusurlu olması sadece bir sayıyı bozmaz — yetenekler hakkında yanlış bir anlayış yaratır, güvenlik gerekçelerini yanlış temsil eder ve araştırma önceliklerini saptırır.
OpenAI önce en yaygın kullanılan kodlama benchmark'larından SWE-bench Verified'ı incelemiş ve temel tasarım ile kontaminasyon sorunları bulmuş: benchmark artık yazılım geliştirme yetenekleri hakkında anlamlı sinyal vermiyordu. Topluluğu SWE-Bench Pro'ya geçmeye teşvik etmişler.
Sonra aynı denetimi SWE-Bench Pro'ya da yapmışlar — kendi önerdikleri alternatife. Yöntem şu: bir veri noktası analizi pipeline'ı, modelin görev denemelerini, görev metadata'sını ve başarısızlık izlerini inceleyip olası değerlendirme kusurlarını işaretliyor; işaretlenen her görev sonra elden geçiriliyor.
Bulunan sorunlar dört kategoriye ayrılmış. Birincisi ve en öğreticisi: overly strict test’ler — prompt'ta belirtilmeyen uygulama detaylarını dayatıyor ve işlevsel olarak doğru olan birçok çözümü geçersiz sayıyor.
Öne çıkanlar
- Kontaminasyon: test verisinin eğitim verisine sızması. Model "çözmüyor", hatırlıyor olabilir.
- Overly strict test, sadece benchmark'ların değil senin test paketinin de sorunu: davranışı değil uygulamayı test eden test, refactor'ı imkânsızlaştırır.
- Kendi önerdikleri alternatifi de denetlemişler — metodolojik dürüstlüğün iyi bir örneği.
- Kusurları bulmak için otomatik bir tarama + insan incelemesi birleşimi kullanılmış.
Neden önemli?
Bir sayıya bakıp karar veriyorsan, o sayının nasıl üretildiğini bilmek zorundasın. Bu, model benchmark'larından çok daha geniş bir ilke: test kapsamı yüzdesi, uptime oranı, müşteri memnuniyeti skoru — hepsi ölçüm tasarımının ürünüdür ve ölçüm bozuksa sayı yalan söyler, üstelik güvenle söyler.
Pratikte
Buradaki ‘overly strict test’ kategorisi her geliştiriciyi ilgilendiriyor. Test yazarken sor: bu test davranışı mı yoksa implementasyonu mu doğruluyor? assertEquals(3, service.getUsers().size()) davranışı test eder; verify(repository).findAllByStatusOrderByIdAsc() implementasyonu test eder ve o metodun adını değiştirdiğin anda, kod hâlâ doğru çalışırken test kırılır. Böyle testler refactor yapmaktan alıkoyar. İkinci ders: kendi evaluation setini periyodik olarak gözden geçir. Bir puanlama ya da filtre sistemi kuruyorsan üç ay sonra neyi elediğine bakıp işe yarayıp yaramadığını denetle.
Sözlük
- benchmark contamination
- Test verisinin modelin eğitim verisine karışması; model çözmek yerine hatırladığı için puan şişer.
- overly strict test
- İstenen davranış yerine belirli bir uygulama biçimini dayatan test; doğru çözümleri de reddeder.
- failure trace
- Bir denemenin nerede ve neden başarısız olduğunu gösteren adım adım kayıt.