Hugging Face resmî benchmark veri kümelerini işaretliyor ve kendinden bildirilen puanları sıralıyor

Bir dev.to gönderisine göre Hugging Face, seçili benchmark veri kümelerini resmî olarak işaretliyor ve lider tablolarını model yayınlayanların kendi depolarına yüklediği değerlendirme dosyalarından oluşturuyor. Her kayıt kendi kendine bildirildiği için, ön plandaki sayı hikâyenin ancak yarısı: örneklemeye dair kurulum, oylama şeması ve düşünme bütçesi, iki kaydın hiç karşılaştırılıp karşılaştırılamayacağını belirliyor.

Resmî tablolar nasıl oluşturuluyor

Gönderinin anlattığına göre mekanizma üç parçadan oluşuyor. Bir benchmark veri kümesi benchmark:official etiketi taşır ve görevlerini tanımlayan bir eval.yaml dosyasıyla gelir. Model yayınlayan kişi daha sonra model deposuna, veri kümesi kimliği, görev kimliği, değer ve tarih bilgilerini içeren .eval_results/gpqa_diamond.yaml gibi bir dosya ekler. Veri kümesi sayfası bu dosyaları sıralı bir lider tablosunda birleştirir ve her tablo, Hugging Face'in datasets API'si üzerinden doğrudan sorgulanabilir.

İşin püf noktası şu: tablo değeri gösteriyor ama nasıl elde edildiğini zorunlu olarak göstermiyor. Protokol ayrıntıları, varsa bile, eval dosyasının notes alanında ve model kartında duruyor ve bunları aramak okuyucunun işi.

Beş birincilik puanının ardındaki protokol

Örnek vermek gerekirse, gönderi, FINAL-Bench organizasyonu altında barındırılan ve bu resmî tabloların beşinde birinci sıradaydıığı söylenen Darwin-180B-RSI modelini inceliyor. Çalışmalar ortak bir yapılandırmayı paylaşıyor: örnek başına 131.072 token düşünme bütçesi, temperature 1.0, top_p 0.95, top_k 20, bf16 hassasiyeti ve tensor ile expert paralelliğiyle vLLM servisidir.

Benchmark başına ayarlar ve bildirilen sonuçlar:

Benchmark	Örnek sayısı	Bildirilen puan	Değer
AIME 2026	16	çoğunluk oyu (ortalama 98.75)	100.0
HMMT Feb 2026	16	çoğunluk oyu (ortalama 96.59)	100.0
GPQA Diamond	16'ya kadar	çoğunluk oyu	94.44
MMLU-Pro	1	tek örnek	88.12
MMMU-Pro (vision)	3	çoğunluk oyu	79.48

Sayıları karşılaştırmadan önce üç kontrol

Gönderi, iki lider tablosu kaydını karşılaştırılabilir saymadan önce doğrulanacakları listeliyor:

• Örnek sayısı ve oylama. 16 yönlü çoğunluk oyuyla oluşturulan bir puan, tek bir model denemesini değil, örnekleme ve oylama kurulumunun bütününü ölçer; dolayısıyla tek örnekli sayılarla yan yana konmamalıdır. Her iki sayının da eval dosyasında görünür olması gerekir.
• Düşünme bütçesi. Akıl yürüten modeller bütçe küçük olduğunda kesinti yüzünden puan kaybeder ve token sınırı nedeniyle yarıda kesilmiş bir cevap, modelin yanlış cevap verdiği bir cevapla aynı şey değildir.
• Bulaşma (contamination). Eğitim verisi, bir yayıncının rapor verdiği her test kümesine göre filtrelenmelidir; gönderi, VIDRAFT'a listediği benchmark'lara uygulanan bir 8-gram örtüşme filtresini atfediyor.

Çalışmaların yeniden üretilmesi

Beş benchmark da herkese açık veri kümeleri ve Darwin-180B-RSI'nin ağırlıkları Hugging Face'te açıkça erişilebilir durumda. Gönderiye göre modeli bf16 ile servis etmek, dörtlü pratik alt sınırıyla sekiz B200 sınıfı GPU gerektiriyor; tensor paralelliği, expert paralelliği, 135.168 token maksimum bağlam uzunluğu ve trust-remote-code etkin şekilde vLLM üzerinden başlatılıyor.

Neden önemli

Resmî etiket, benchmark sonuçlarını keşfetmeyi çok kolaylaştırıyor ama onları tek biçimli hale getirmiyor. Her kayıt kendi kendine bildirildiği için bir tablodaki sıralama, protokolleri sessizce harmanlıyor: tek örnekli puanlar çoğunluk oyu puanlarının yanında duruyor ve cömert bir düşünme bütçesiyle değerlendirilen bir model, akıl yürütmesi akış ortasında kesilmiş olabilecek bir modelle yarışıyor. Doğrulama işi, merkezi bir operatörden tabloyu okuyana geçti. Model seçen ekipler için pratik adım, bir sıralamaya güvenmeden önce eval dosyasını ve model kartını açmak; yayınlayanlar için ise bu biçim, her sayının tam olarak nasıl üretildiğini belgeleme beklentisini yükseltiyor. Bu örnekteki gibi açık ağırlıklar, bir iddianın kontrol edilmesi gerektiğinde en azından bağımsız yeniden üretimi mümkün kılıyor.