Kırılan benchmark
Bir kamuya açık yazı, 27 açık ağırlıklı modeli benchmark'tan geçiren bir ekibin, hatanın kaynağının modeller değil değerlendirme harness'ının kendisi olduğunu keşfetmesini anlatıyor. İlk refleks bunu bir utanç olarak görmektir. Değil. Bu normal durumdur. Değerlendirme kodu model kodundan daha hızlı kayar, çünkü teslim tarihi baskısı altında yazılır, tuhaf çıktılara uyum sağlamak için yamalanır ve nadiren kendi başına bir sistem olarak incelenir.
Aşağı yönlü maliyet sessiz ve birikimlidir. Sıralamalar kimse fark etmeden haftalar arasında karşılaştırılamaz hale gelir. Mart'ta yüzde 71, Nisan'da yüzde 68 alan bir model illa gerilememiştir; çıkarıcı değişmiş olabilir, bir bağımlılık kaymış olabilir veya birkaç madde bir eğitim korpusuna sızmış olabilir. Sayı hareket eder, anlatı peşinden gelir ve alttaki ölçüm aygıtı hiç denetlenmez.
Üç harness kusuru sınıfı
Çoğu harness arızası üç kovaya düşer. Egzotik değiller. Yapılandırılmamış metni alıp bir skaler üreten herhangi bir veri hattının olağan arıza modlarıdır.
Ayrıştırma kusurları
Bozuk model çıktısını sessizce kabul eden bir çıkarıcı, geçme oranlarını şişirir. answer alanı olan bir JSON nesnesi bekleyen bir değerlendirici bir regex'e, sonra bir alt dize eşleşmesine, sonra True varsayılanına düşebilir. Her geri düşüş modele küçük bir iyilik ve okuyucuya küçük bir yalandır. Arıza görünmezdir çünkü bir istisna değil bir sayı üretir.
Mekanizmayı tam olarak adlandırmakta fayda var. Tipik bir çıkarıcı zinciri şöyle görünür:
def extract(text):
obj = try_json(text)
if obj is not None:
return obj.get("answer")
m = re.search(r"answer[:\s]+(.+)", text, re.I)
if m:
return m.group(1).strip()
return text.strip() # last resort
O son return text.strip() geçme oranlarının öldüğü yerdir. Ayrıştırılamayan bir yanıtı, tesadüfen referansla eşleşebilecek bir dizeye dönüştürür. Çözüm daha iyi bir regex değil; ayrıştırılamayan çıktıda hata fırlatan ve arızayı model hatasından ayrı bir değerlendirici hatası olarak kaydeden katı bir moddur.
Kontaminasyon
Eğitim verisine sızmış maddeler prompt mühendisliğiyle düzeltilemez. Bir modelin ön eğitim korpusunda birebir görünen bir benchmark maddesi yeteneği değil hatırlamayı ölçer. Kontaminasyonu tespit etmek zordur, ancak ilk adım prosedüreldir: özel bir bölünmüş küme ayırın, kamuya açık maddeleri hash'leyin ve inceleyebildiğiniz herhangi bir korpusa karşı yakın kopyaları kontrol edin. İnceleyemediğiniz yerde skoru değil riski raporlayın.
Ortam kayması
Tokeniser sürümleri, tool stub'ları ve timeout'lar çalışmalar arasında değişir. Bir tokeniser yama sürümü, bir prompt'un kaç token tükettiğini değiştirebilir; bu da kırpma davranışını, o da uzun bağlamlı maddelerdeki skorları değiştirir. Bir çalışmada hazır bir yanıt, sonrakinde canlı bir yanıt döndüren bir tool stub'ı görevi tamamen değiştirir. Ocak'ta 30 saniye, Mart'ta 10 saniye olan bir timeout, akıl yürütme ağırlıklı modelleri orantısız şekilde cezalandırır. Bunların hiçbiri model değişikliği değildir. Hepsi liderlik tablosunu hareket ettirir.
Bir harness'ın bilinen-cevap test setine ihtiyacı vardır
Çare, herhangi bir production servisi için kullanılanla aynıdır: her değerlendirmede çalışan, ara sıra değil, bir test seti.
Kasıtlı olarak bozuk ve başarısız olması gereken gönderimlerle birlikte, geçmesi gereken önemsiz olanları da dahil edin. Boş bir dize döndüren bir gönderim sıfır almalıdır. Referans yanıtı birebir döndüren bir gönderim bir almalıdır. Makul görünen ama yanlış bir yanıt döndüren bir gönderim sıfır almalıdır. Bu beklentilerden herhangi biri ters dönerse harness bozuktur ve çalışma geçersizdir. Bu, tam anlamıyla bir canary'dir: bilinen girdi, bilinen çıktı, gerçek iş yüküne güvenilmeden önce kontrol edilir.
Model, tokeniser, prompt şablonu ve tool stub sürümlerini tek bir manifestte sabitleyin. Tek dosya, depoya işlenmiş, her sonuç tarafından referans verilen. Manifest değişirse çalışma yeni bir çalışmadır ve sonuçlar öncekiyle karşılaştırılamaz. Bu, bir lockfile ile aynı disiplindir, değerlendirmeye uygulanmış hali.
Nokta tahminleri değil güven aralıkları yayınlayın. 200 madde üzerinde iki puanlık bir fark gürültüdür. Tek bir sayı raporlamak okuyucuları istatistiksel olarak ayırt edilemeyen modelleri sır
.
İncelemeye dayanan raporlama
Bir benchmark bir iddiadır ve iddialar denetlenebilir olmalıdır.
Kategori başına sonuçları örnek sayılarıyla raporlayın. Toplu skorlar ince dilimleri gizler. Genel olarak iyi puan alan ama bir okuyucunun kullanım durumuyla en ilgili kategoride 12 maddesi olan bir model, o kullanım durumu için kanıt değildir. Skorun yanında sayıyı gösterin ki okuyucu uygun şekilde iskonto edebilsin.
Ham transkriptleri ve değerlendirici çıktılarını saklayın. Bir skor tartışıldığında, tartışma yeniden çalıştırıp umut ederek değil, yeniden karara bağlanarak çözülebilmelidir. Tam transkripti, çıkarılan yanıtı, referansı ve değerlendiricinin kararını saklayın. Bu ayrıca tarihsel çalışmaları düzeltilmiş bir değerlendirici altında yeniden notlandırmayı mümkün kılar; bu da bir harness düzeltmesi boyunca karşılaştırmanın tek dürüst yoludur.
Eval setini kod gibi sürümleyin ve her sessiz düzenlemeyi kırıcı bir değişiklik olarak ele alın. Yeniden ifade edilen bir madde, düzeltilen bir referans, belirsiz olduğu için kaldırılan bir madde: bunların her biri kendisinden sonra hesaplanan her skorun anlamını değiştirir. Eval setini etiketleyin, etiketi manifestte kaydedin ve bir düzenleme gerekli olduğunda sessizce üzerine yazmak yerine öncesini ve sonrasını yayınlayın.
Dürüst ödünleşim
Katılık verimden çalar. Ayrıştırılamayan çıktıda hata fırlatan katı bir çıkarıcı daha fazla çalışmayı geçersiz kılar ve bilinen-cevap test seti her değerlendirmeye sabit bir ek yük getirir. Zaman baskısı altındaki ekipler gevşek modda çalışıp sonra temizlemeye meyledecektir. Karşı argüman şudur: gevşek bir çalışma güvenilmez sayılar üretir ve güvenilmez sayılar hiç sayı olmamasından daha kötüdür çünkü kararlara yayılır.
Pratik uzlaşma, varsayılan olarak katı çalıştırmak ve çıktıda açıkça etiketlenen gevşek bir moda izin vermektir. Etiket sonuçla birlikte yol alır. lenient: true gören bir okuyucu skoru iskonto etmesi gerektiğini bilir. lenient: false ve geçen bir bilinen-cevap test seti gören bir okuyucu aygıtın kontrol edildiğini bilir.
Bu neyi değiştirir
Harness'ı production yazılımı olarak ele almak üç şeyi değiştirir. Eval kodunu serving koduyla aynı inceleme standartlarıyla sürüm kontrolüne taşır. Bilinen-cevap test setini bir sonradan akla gelen değil bir kapı haline getirir. Ve yayınlanan her skorun kendi kökenini taşımasını sağlar: hangi manifest, hangi eval-set etiketi, hangi örnek sayıları, hangi aralık.
Bunların hiçbiri benchmark yapmayı kolaylaştırmaz. Benchmark yapmayı dürüst kılar. 27 modeli benchmark'tan geçiren ve sonra kendi benchmark'ını düzelten ekip, çoğu yayınlanmış liderlik tablosunun atladığı işi yaptı. Sonuç, savunulabilen bir sayıdır; yayınlamaya değer tek tür de budur.