Bir model ailesi için iki MMLU puanı, benchmark adlarının uygulama farklarını nasıl gizlediğini gösteriyor

İki sayı, tek benchmark adı

Hacker News ana sayfasında öne çıkan Dmitrii Zatona'nın blog yazısı, aldatıcı derecede sıradan bir tabloyu ele alıyor: yan yana duran iki değerlendirme kaydı; biri bir model ailesinin 42 numaralı sürümü için 0.781 MMLU doğruluğu bildiriyor, diğeri aynı ailenin 44 numaralı sürümü için 0.79. Her iki iddia da aynı sağlayıcıyı, benchmark tanımlayıcısını, metriği ve birimi bildiriyor ve aritmetik fark +0.009. Bu çift, bir doğrulama crate'inin test vektörlerinden alınmış olsa da, içerdiği her öğe model leaderboard'larını takip eden herkese tanıdık gelecektir.

Her iki kayıt da yapısal olarak geçerli. Ancak her biri, ölçümün nasıl yapıldığını açıklayan hash'lenmiş bir nesne olan bir değerlendirme "frame"ine işaret ediyor ve iki frame birbiriyle uyuşmuyor. Farklı runner, grader ve dataset split'leri bildiriyorlar. Zatona, apl-ai-eval crate'inden bir doğrulayıcıya iki puan arasındaki deltayı hesaplamasını istediğinde, doğrulayıcı "incomparable" (karşılaştırılamaz) yanıtı döndürüyor.

MMLU etiketinin belirsiz bıraktıkları

Yazıya göre benchmark tanımlayıcısı bir adı sabitliyor ve bundan başka neredeyse hiçbir şeyi. Beş değişken açık kalıyor ve yayımlanmış ölçümlerin bulunduğu yerlerde her biri binde bir değil, tam puanlar değerinde.

İlk değişken dataset split'i. Hendrycks ve arkadaşlarının özgün MMLU makalesi, 57 konu genelinde konu başına 5 soruluk bir geliştirme seti, 1.540 soruluk bir doğrulama seti ve 14.079 soruluk bir test seti tanımlıyor. Çoğu runner'ın gerçekte yüklediği Hugging Face cais/mmlu veri seti ise 14.042 soruluk bir test seti, 1.531 soruluk doğrulama seti ve 285 soruluk bir geliştirme seti bildiriyor. "MMLU test seti" ifadesi bu nedenle iki farklı boyutta nesneye işaret ediyor ve Zatona bu farkı açıklayan hakemli bir belge bulamadı. Onun örneği daha da çarpıcı: frame A, 285 soruluk geliştirme seti üzerinde puanlama yapıyor — ki makale bu seti few-shot örneklerinin kaynağı olarak tanımlıyor — frame B ise "test-lite" etiketli bir split üzerinde puanlama yapıyor; Zatona bu adı hiçbir yayımlanmış artifact'e izleyemedi ve bu tinyMMLU de değil. Etiket, özel bir dilim kullanıldığına işaret ediyor; hangi sorular olduğunu söylemiyor.

İkincisi uygulama. Haziran 2023 tarihli bir Hugging Face yazısı, Open LLM Leaderboard üzerinde bu maliyeti doğrudan ölçtü. Üç harness — HELM, Eleuther harness'i ve özgün kod — aynı veri setini, tamamı 5-shot olacak şekilde çalıştırdı ve llama-65b'yi 0.637, 0.488 ve 0.636 ile, falcon-40b'yi ise 0.571, 0.527 ve 0.558 ile puanladı. Mekanizma puanlama: bir harness dört cevap harfinin olasılıklarını karşılaştırıyor, bir diğeri bir sonraki token'ı üretip beklenen metinle karşılaştırıyor, üçüncüsü tam cevap dizisini puanlıyor. Sıralama da bununla birlikte değişiyor; falcon-40b bir harness altında llama-65b'nin üstüne çıkarken diğer ikisinde altında kalıyor. Zatona, lm-evaluation-harness'in mmlu, mmlu_continuation ve mmlu_generative'i aynı veri üzerinde üç ayrı görev olarak ele aldığını ve "5-shot MMLU"nın görevin bir özelliği değil bir komut satırı bayrağı olduğunu ekliyor; çünkü few-shot varsayılanı sıfır.

Üçüncüsü prompt formatı. Anthropic 2023'te, yalnızca biçimlendirmenin — seçenek etiketleri, parantezler, cevaptan önce fazladan bir boşluk — MMLU doğruluğunu yaklaşık %5 oynattığını bildirdi. Cevap konumu daha da fazla oynatıyor: Zheng ve arkadaşlarının bir çalışmasında doğru cevapların D konumuna kaydırılması gpt-3.5-turbo'yu 67,2'den 60,9'a düşürürken, A konumuna kaydırılması llama-30b'yi 15,2 puan artırarak 68,2'ye çıkardı; bu, gpt-3.5-turbo'nun 65,3'ünün üzerine geçmek ve 53,1 ile 67,2 arasındaki özgün sıralamayı tersine çevirmek anlamına geliyor. Zatona'nın örneğinde iki frame aynı prompt protokolünü, zero-shot-mcq-v1'i bildiriyor — tutulan bir değişken, ama yalnızca yazıldığı için görünür şekilde tutuluyor.

Dördüncüsü grader. Frame A exact-match-v1 ile; frame B ise llm-judge-v3 ile puanlıyor. Bunlar tek bir işlevin iki uygulaması değil. Zheng ve arkadaşları, judge modellerinin güçlü konum yanlılığı sergilediğini buldu; vakaların %60'ından fazlasında tutarlı olan yalnızca GPT-4'tü — %65,0; buna karşılık GPT-3.5 için %46,2 ve Claude-v1 için %23,8 — ve iki yanıt yer değiştirdiğinde ters dönen kararları da belgelediler.

Yazının yayımlanmış bir ölçüm olmadan listelediği beşinci açık değişken ise runner'ın ağ erişimi.

Karşılaştırılabilirlik sayıda değil, referansta yaşar

Zatona'nın merkezî argümanı, karşılaştırılabilirliğin bir sonucun izlenebileceği referansın bir özelliği olduğu, sayının kendisinin değil. APL AI-Eval profili altında frame içerik adresli bir nesnedir ve her iddia kendi hash'ini taşır; buradaki iki iddia farklı hash'lere işaret ediyor ve kanonik serileştirme altında "all" değerinin bir alt kümesi ile atlanmış bir anahtar bile farklı kapsam olarak sayılıyor. Yapısal geçerlilik hükmünün, not ettiği gibi, iki puanın gerçekte doğru olup olmadığı hakkında hiçbir şey söylemediğini belirtiyor.

Neden önemli

Makaleler, leaderboard'lar veya model kartları arasında benchmark puanlarını çıkaran herkes, çoğunlukla farklı split'ler, harness'ler, prompt protokolleri ve grader'lar altında üretilmiş sayıları karşılaştırıyor — ve yukarıda alıntılanan yayımlanmış kanıtlar bu farkların tam puanlarla ölçüldüğünü söylüyor. Yazıdaki +0.009 delta, altta yatan kayıtların desteklemediği bir hassasiyet ima ediyor: geliştirme seti üzerinde exact-match puanlamasını, bir LLM judge tarafından puanlanan özel bir dilimle karşı karşıya getiriyor. Zatona'nın işaret ettiği çözüm köken (provenance): split'i, uygulamayı, prompt protokolünü, grader'ı ve kod commit'ini hash'lenmiş, çözümlenebilir bir frame'e sabitlemek; böylece "aynı benchmark" iddiasının varsayılmak yerine denetlenebilmesini sağlamak.