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: aşırı katı testler — 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.
- Aşırı katı 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.
Sende karşılığı
Buradaki "aşırı katı test" kategorisi seni doğrudan ilgilendiriyor. Kendi projelerinde test yazarken sor: bu test davranışı mı yoksa uygulamayı mı doğruluyor? assertEquals(3, service.getUsers().size()) davranışı test eder; verify(repository).findAllByStatusOrderByIdAsc() uygulamayı test eder — ve o metodun adını değiştirdiğin anda, kod hâlâ doğru çalışırken testin kırılır. Böyle testler seni refactor yapmaktan alıkoyar. İkinci ders: kendi değerlendirme setini periyodik olarak gözden geçir. Bu gazetenin küratörlük puanlaması da bir değerlendirmedir — üç ay sonra hangi yazıları elediğine bakıp puanlamanın işe yarayıp yaramadığını denetlemelisin.
Sözlük
- benchmark contamination benchmark kontaminasyonu
- Test verisinin modelin eğitim verisine karışması; model çözmek yerine hatırladığı için puan şişer.
- overly strict test aşırı katı test
- İstenen davranış yerine belirli bir uygulama biçimini dayatan test; doğru çözümleri de reddeder.
- failure trace başarısızlık izi
- Bir denemenin nerede ve neden başarısız olduğunu gösteren adım adım kayıt.