Kodlama değerlendirmelerinde sinyali gürültüden ayırmak

 (openai.com)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Yapay zeka modellerinin kodlama becerisini değerlendirmek, dağıtım ve güvenlik kararlarıyla doğrudan bağlantılı; ancak OpenAI’nin denetiminde SWE-Bench Pro görevlerinin yaklaşık %30’unun bozuk durumda olduğu tahmin ediliyor
  • SWE-Bench Pro daha uzun görev kapsamı ve daha gerçekçi problemleri hedefliyordu; ancak 731 herkese açık görevde başarı oranının 8 ayda %23,3’ten %80,3’e yükselmesi artık olduğu gibi güvenilir görünmüyor
  • Kusurlar; aşırı katı testler, eksik belirtilmiş istemler, düşük kapsama sahip testler ve yanıltıcı istemler olarak ayrılıyor; doğru gönderimler başarısız olabilir veya eksik düzeltmeler geçebilir
  • Denetim, model denemeleri, görev metaverileri ve hata takibine dayanarak 286 potansiyel sorunlu görevi işaretledikten sonra bir araştırma ajanı ve 5 deneyimli mühendisin bağımsız incelemesinden geçirdi
  • OpenAI, SWE-Bench Pro’nun benimsenmesine yönelik tavsiyesini geri çekti; değerlendirme benchmark’ları, model becerisi ve güvenlik kararlarını çarpıtmayan anlamlı sinyaller sağlamalı

SWE-Bench Pro denetiminde ortaya çıkan sorunlar

  • OpenAI, SWE-Bench Pro’yu denetlemesinin sonucunda tüm görevlerin yaklaşık %30’unun bozuk durumda olduğunu tahmin ediyor
  • Model becerisini doğru ölçmek, Preparedness Framework kapsamındaki dağıtım ve güvenlik kararlarını da etkiliyor
  • Kusurlu değerlendirmeler, model becerisinin olduğundan farklı anlaşılmasına yol açabilir ve güvenlik kararlarını ile araştırma önceliklerini sarsabilir

SWE-Bench Pro’nun amacı ve başarı oranındaki değişim

  • OpenAI, daha önce yaygın kullanılan SWE-bench Verified’da tasarım ve kontaminasyon sorunları tespit etmiş ve bu değerlendirmenin yazılım geliştirme becerisine dair artık anlamlı bir sinyal vermediğine karar vermişti
  • O dönemde OpenAI, topluluğa SWE-Bench Pro’ya geçmesini önermişti
  • SWE-Bench Pro, SWE-bench Verified’ı geliştirerek daha uzun görev kapsamı ve daha gerçekçi kodlama problemleriyle ajan türü kodlama becerisini izlemek üzere tasarlandı
  • Görevler, herkese açık ve özel depolardaki özellik değişikliği geçmişlerinden programatik olarak çıkarıldı
    • Modelin, mevcut işlevleri bozmadan yeni özellik testlerini geçen bir çözüm uygulaması gerekiyor
    • 731 görevlik herkese açık bölümde frontier modellerin başarı oranı 8 ay boyunca %23,3’ten %80,3’e yükseldi

Kalite güvence hattı

  • OpenAI, her veri noktasının gerçek model becerisini yansıtıp yansıtmadığını doğrulamak için bir kalite güvence hattı oluşturdu
  • İlk otomatik filtre; modele verilen talimatları, modelin çözüm denemelerini ve puanlama testlerini inceleyerek bozuk veya sorunlu olduğundan şüphelenilen örnekleri işaretledi
  • Bu süreçte 286 potansiyel sorunlu görev işaretlendi
  • İşaretlenen alt küme iki yoldan daha derinlemesine incelendi
    • İnsan denetimli ajan incelemesi: Araştırma ajanı ayrıntılı doğrulama yaptı ve son insan kararından geçti
    • İnsan anotasyon kampanyası: Deneyimli yazılım geliştiriciler görevleri doğrudan inceledi

Ajan incelemesi ve insan incelemesi yöntemi

  • İşaretlenen sorunlar Codex tabanlı araştırma ajanı tarafından denetlendi
    • Ajan, görev deposuna ve çalıştırma ortamına erişti
    • Test çalıştırma, depo dosyalarını inceleme, model denemelerini ve yaygın hata modlarını araştırma yapabiliyordu
    • Çevre kod ve depo gelenekleriyle çözülebilecek makul belirsizlikleri gerçek eksik belirtimden ayırmak için kullanıldı
  • Birkaç tur bağımsız derin denetimin ardından araştırmacı özetleri inceledi ve nihai karar ile sorun etiketini belirledi
  • Paralel yürütülen insan anotasyon kampanyasında deneyimli yazılım mühendisleri, benchmark hedefleri, sorun sınıflandırması ve sınır durumları konusunda eğitim aldıktan sonra görevleri inceledi
  • Her görevi 5 mühendis inceledi
    • İnceleyenler, görünen problem açıklamasına, test case’lerine ve doğru referans çözüm olan gold patch’e dayanarak önce bağımsız karar verdi
    • Ardından hat analizi veya kayıtları yardımcı bağlam olarak kullandı
    • Somut gerekçelere göre etiket ve önem derecesi atadı; görüş ayrılıkları veya düşük güvenli örnekler ek incelemeye yükseltildi

Dört hata türü

  • Denetimde belirlenen sorunlar başlıca dört kategoriye ayrıldı
    • Aşırı katı testler: İstemde yer almayan belirli uygulama ayrıntılarını zorunlu kılarak işlevsel olarak doğru gönderimleri geçersiz sayar
    • Eksik belirtilmiş istemler: Gizli testlerin gerektirdiği ancak makul biçimde çıkarılması zor olan gereksinimleri atlar
    • Düşük kapsama sahip testler: İstenen işlevi yeterince doğrulamaz; bu nedenle eksik düzeltmeler de geçebilir
    • Yanıltıcı istemler: Modeli yanlış davranışa yönlendirir veya test gereksinimleriyle çelişir
  • Bazı görevlerde istem belirli bir uygulama istediği halde gizli test case’leri farklı bir davranış bekliyordu

İnsan incelemesi ile ajan incelemesi arasındaki fark

  • İnsan inceleyicilerin bir görevi bozuk olarak işaretleme olasılığı, araştırma ajanına göre daha yüksekti
  • İki inceleme yolu arasında kategori kararı farkları vardı; ancak işaretlenen görevler içinde insan etiketlerinde “bozuk değil”in en çok verilen etiket olduğu bir durum yoktu
  • Ajan hattının işaretlediği kategori ile insan inceleyicilerin kararı vakaların %74’ünde örtüştü
  • İnsan inceleyiciler bir görev için birden fazla etiket seçmeye de daha yatkındı
    • Bu, görevin birden fazla şekilde bozuk olduğuna veya tek bir kategoriye temiz biçimde uymadığına işaret ediyor
    • Ajan ve inceleyicileri birlikte kullanan hat, insanların bulduğu geniş hata modlarını yakaladı; ancak ek ve örtüşen sorunları temkinli biçimde daha az saydı
  • En büyük fark düşük kapsama sahip testlerde görüldü
    • İnsanlar bunu benchmark’ın %9,4’ünde en yaygın sorun olarak seçti
    • Ajan hattı ise %4,1 olarak işaretledi

Benchmark oluşturmanın zor olmasının nedenleri

  • SWE-Bench Pro ve SWE-bench Verified örnekleri, benchmark’ların sıkı biçimde doğrulanması gerektiğini gösteriyor
  • Açık kaynak depolardaki issue’lar ve pull request’ler aslında model değerlendirmesi için değil, insan iş birliği için oluşturulur
  • Bakımcılar ve katkıda bulunanlar arasında uzun gidip gelmelerin olduğu ortamlarda problem açıklaması, birleştirilen kod ve birim testleri, model değerlendirmesi için her zaman temiz ve bağımsız görevler oluşturmaz
  • Pull request’lerde yer alan testler belirli bir değişikliği doğrulamak için yazılabildiğinden, uygulama yönteminden bağımsız çözüm kriterlerinden ziyade belirli bir uygulamayı zorunlu kılabilir

Gelecekteki değerlendirme yönü

  • Model becerileri geliştikçe değerlendirme kusurlarını bulmak da eskisine göre daha kolay hale geliyor
  • Gelişmiş modeller; istemleri, testleri, yamaları, çalıştırma izlerini ve sınır durumlarını daha derin ve tutarlı biçimde inceleyerek, eskiden büyük ölçekte bulunması zor veya maliyetli olan benchmark sorunlarını ortaya çıkarabilir
  • OpenAI, daha geniş değerlendirme topluluğunun, deneyimli yazılım geliştiriciler tarafından doğrudan model becerisini test etme amacıyla hazırlanan yeni benchmark’lar geliştirmesini bekliyor
  • Bu yaklaşım, ölçülmek istenen yüksek zorluk ve gerçekçiliği korurken süreç boyunca daha iyi insan denetimini mümkün kılar
  • OpenAI, bu analizde ortaya çıkan sorunlar nedeniyle SWE-Bench Pro’nun benimsenmesine yönelik önceki tavsiyesini geri çekiyor
  • Değerlendirmeler manipüle edilmesi zor, güvenmesi kolay olmalı ve model becerisini ya da hizalanma durumunu gerçekten yansıtan anlamlı sinyaller sağlamalı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Hacker News görüşleri
  • Yeni bir benchmark gerekli. 100 dolarlık API maliyeti ile bir modelin benchmark paketinde ne kadarını yapabildiğini ölçen bir yaklaşım iyi olurdu
    Verimlilik ve zekayı birlikte ölçmek gerekir. Küçük modeller, bilgisayar kullanarak sonuçları test etme ya da sorunla daha uzun süre uğraşıp çıktıyı doğrulama gibi stratejiler kullanabilir; büyük modellerin ise kendi test bütçesi yetersiz kalabilir, bu da ilginç taktik farkları doğurabilir
  • Terminal Bench 2'de çeşitli nedenlerle epey sahte sonuç var. Ryan/Alex gibi harika ekipler son dönemde şüpheli gönderimlerin çoğunu temizledi, ancak birçok laboratuvar süre sınırlarını ya da donanım ayarlarını değiştirip belirli görevlerde aslında ölçülmek isteneni baypas eden sonuçlar yayımlıyor
    Buna yürütme harness’i seviyesinde hile, modelin ödül hack’lemesi gibi şeyler de dahil. Aylar geçmesine rağmen aklımı kurcalayan şey gpt-5.5'in resmî gönderimi, özellikle de şu görev: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
    Görevin süre sınırı https://github.com/harbor-framework/terminal-bench-2/blob/ma... uyarınca verifier için 1200 saniye, agent için 1200 saniye, environment build için 600 saniye; yani hiçbir agent 3000 saniyeyi aşmamalı. Ama yukarıdaki bağlantıdaki 5 denemenin 2'si 3000 saniyeyi çok aşıp sırasıyla 75 ve 80 dakika sürmüş. Başarısız olmuş olsalar bile bu kadar uzun çalışmaları şüpheli. Goodhart yasasının iş başında olduğu bir örnek
    • Birisi belirli bir “hile” tanımına göre hile yapmamış olsa bile, benchmark zaten devasa bir yapısal gradient descent sürecinin bir yerine girmiş durumda. Modeller her seviyede benchmark puanını maksimize eden makineler; bu yüzden benchmark’ın kendisi özünde biraz işe yaramaz görünüyor
      İnsanları benchmark’lamak da pek iyi işlemiyor. Kodlama yeteneği, biriyle doğrudan etkileşime girmeden düzgünce ölçülemiyor. Eğer model aslında bir insan simülatörüyse, simülasyon daha doğru hale geldikçe benchmark’ların hâlâ faydalı olmasını beklemek başlı başına tuhaf. Sonuçta bu, yukarıda söylenen “Goodhart yasası”nın daha uzun anlatılmış hali ve gerçekten de yasa gibi işliyor
  • Temelde sonuç, yazılım geliştiricilere verilen görevlerin insan için de model için de çoğu zaman eksik ya da kendi içinde çelişkili hatta daha da kötü durumda olduğu değil mi? Bu araç tam da böyle bir dünyada çalışmak zorunda, o yüzden pek sempati duymuyorum
    • Katılıyorum. Yetersiz promptları aracın başarısızlığı olarak listelemek pek ikna edici değil. Bir stajyer bile biraz yardımla belirsiz istekleri anlayabilir ve sürekli zorlamak yerine durup ne zaman soru sorması gerektiğini bilir. Staj bitmeden önce bile çoğu zaman belirsiz görevleri oldukça bağımsız şekilde ele alabilir
      O halde mantık şu mu: son teknoloji modeller, junior mühendis bile değil; hatta o seviyeyi aşma becerisi olmayan ilk ayındaki bir stajyer mi?
    • Gerçek işte başarısız test vakalarına bakıp kodu düzeltebilir ya da daha büyük ihtimalle berbat yazılmış testleri düzeltebilirsin. Güncel LLM’lere yalnızca o ilk adım izin verilse bile bu spesifik benchmark’ta ezici derecede iyi performans gösterirler
      İlginç olan, LLM’lerin böyle benchmark’larda nasıl %70’in üstüne çıktığı ya da kötü kurgulanmış soruların bir kısmını nasıl doğru yaptığı. Test yazarlarının stilini örtük olarak mı öğrenmişler? Çözümler eğitim verisine sızmış olabilir mi?
      Yine de Fable’ın bile, OpenAI'ın bu analizi çalıştırmadığı gizli sette yaklaşık %72'de kalması biraz iç rahatlatıcı. Benchmark’ın kendisini, çok dolaylı yollar dışında doğrudan öğrenmiş gibi görünmüyor
      Küçük açık modeller bu tuhaf alışkanlıkları asla öğrenemeyeceğine göre, modelleri adil değerlendirecek iyi bir yöntemin gerçekten önemli olduğu açık. Ayrıca OpenAI biraz suyu bulandırıyor; agent’a haksızlık edecek biçimde bozuk problemler yalnızca yaklaşık %20, buna karşılık %4-10 kadarı agent lehine bozuk, dolayısıyla benchmark tavanı muhtemelen %80-85 civarında
    • Daha incelikli mesele, görev ile doğrulama arasındaki boşluk. Örneğin açık uçlu ya da yetersiz tanımlanmış bir prompt varsa, verifier’ın mümkün olan tüm çözümleri ele alabilmesi gerekir
      Bu yüzden çok dar görev prompt’larını doğrulamak kolaydır ama meydan okuma olarak fazla basit kalabilirler. Tersine, daha gerçekçi görev prompt’larını doğrulamak çok daha zordur ve sağlam verifier’lar yazıp bunları düşük maliyetle çalıştırmak da zordur
    • Ben de aynı şeyi düşünüyordum; özellikle başta açıkça belirtilmeyip yalnızca testlerde yer alan görünmez gereksinimler için bu çok doğru. Kimsenin söylemediği gereksinimleri karşılamak için çözümü yeniden elden geçirmek mi gerekiyor? Ben de fiilen bunu yapıyorum
      Elbette bu, benchmark’ın iddia ettiğinden farklı bir şeyi test etmek anlamına geliyor; ama temiz bir benchmark’tan ziyade gerçeğe daha yakın bir şeyi kazara test ediyor olması da onu bir bakıma anlamlı kılıyor
      Tabii bu, agent’ın başarısız testleri görüp yineleme yapabildiği durumda geçerli. Aksi halde bu sadece bir sorun. Bir de belirli bir çözümün uygulama ayrıntılarını testlerin içine gömüp tamamen keyfi bir iç yapı dayatmaları var; bu daha da kötü. Gerçek hayatta böyle bir durumla karşılaşmazsın
  • Buradaki sayılara bakınca tüm benchmark’ın 800'den az görevden oluştuğu görülüyor. Birkaç mühendisin bir haftada gözden geçirebileceği bir ölçek ve OpenAI’nin sonunda burada yaptığı şey de buydu

Bir yandan bunu gerçekten yapmış olmaları övgüye değer. Öte yandan, “garbage in, garbage out” sözünün tam karşılığı. Asıl yazarların bunu gerçekten doğrulamamış olması da biraz utanç verici, aşağı akıştaki hiç kimsenin doğrulamamış olması da utanç verici. Yazıya bakınca, LLM sorunları bulmuş olsa da profesyonel yazılım mühendislerinin bulduğu sorunları küçümseme eğilimi olduğu da görülüyor

  • Benchmark’lar içlerine bakınca genelde epey kötü çıkıyor
    Arka plan olarak, Codex/Claude Code kullanırken gereken çeşitli zahmetli adımları yerine koymak için denetleyici ajanı yinelemeli olarak geliştiriyordum ve yakın zamanda bu ajanı Terminal Bench 2.1 üzerinde çalıştırdım
    İlk başta sevinmiştim. Çünkü spesifikasyona dayalı denetleyici, birçok görevde temel Codex’ten daha iyi sonuç verdi. Ama daha yakından bakınca görevlerin kendisinde çok fazla sorun olduğu ortaya çıktı
    Esas mesele, talimatların sık sık muğlak olmasına karşılık test vakalarının aşırı derecede spesifik olması. Örneğin configure-git-webserver, “so that I can run” gibi bir ifade yüzünden ajanın neyi sağlaması, neyi kaldırması gerektiği sınırını belirsizleştiriyor. Fazla düşünen bir ajan, sunucuyu yapılandırdıktan sonra kullanıcının aynı komutu çalıştırması halinde çakışma olacağını varsayıp doğrulayıcının kontrol ettiği tam dosyaları siliyor
    make-mips-interpreter, “I will check that you booted doom correctly” ifadesi yüzünden denetleyicinin, kullanıcının Doom’un bağımsız olarak açıldığını kontrol ettiğini değil, ajanın başlattığı sonucu kontrol ettiğini yorumlamasına yol açıp oluşturulmuş /tmp/frame.bmp dosyasını bırakıyor. Doğrulayıcı mevcut bir /tmp/frame.bmp varsa çıkıyor, bu yüzden Doom’u başlatamıyor ve önyükleme sürecinde dosyanın yeniden oluşturulup oluşturulmadığını da kontrol etmiyor[0]
    mcmc-sampling-stan içinde denetleyici ajan çoğu zaman doğru değere ulaşıyordu, ama basit ondalık yerine alana özgü sayısal çıktıyı bilimsel gösterimle veriyordu. Doğrulayıcı sonucu yanlış parse edip başarısız oluyordu[1]
    Bu tür uyuşmazlıklar sadece bunlarla sınırlı değil; bu yüzden Terminal Bench 2.1’in zaten doygunluğa ulaştığını ve GPT-5.6 ile Mythos sonuçlarının sırasıyla %88.8 ve %88 ile beklenebilir üst sınıra neredeyse dayandığını düşünüyorum. En büyük sorun, benchmark’ların çoğunun tek seferlik çalıştırma olması ve gerçek kullanıcıların araçları kullanırken başlıca biçimi olan uzun, yinelemeli çalışmalarda model+harness’ı neredeyse hiç test etmemesi
    [0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
    [1] https://github.com/harbor-framework/terminal-bench-2-1/issue...

  • SWE-Bench’in tamamının baştan beri kusurlu olduğunu herkes zaten bilmiyor muydu? Yazarlar bile sınırlamaları kabul etti ve uzun zaman önce bir sonraki aşamaya geçti

    • SWE-Bench Pro, SWE-Bench’in yerini almak ve bu sorunları düzeltmek için yapıldı

  • Bunun neden kötü bir benchmark olabileceğini anlıyorum, ama eğer mesele; aşırı katı testlerin prompt’ta açıkça belirtilmeyen belirli uygulama ayrıntılarını dayatıp işlevsel olarak doğru gönderimleri geçersiz kılması, yetersiz prompt’ların gizli testlerin dayattığı ama makul biçimde çıkarılamayacak gereksinimleri atlaması, düşük kapsamlı testlerin istenen işlevi daha az doğrulayıp eksik düzeltmelerin geçmesine izin vermesi ve yanıltıcı prompt’ların modeli yanlış davranışa yönlendirmesi ya da test gereksinimleriyle çelişmesi ise, amaç gerçek yazılım mühendisleriyle modelleri karşılaştırmak olduğunda bu aslında oldukça gerçekçi bir durum
    Bu, bir hemşirelik sınavı hazırlayıp sonra bazı soruları, çizelgede olmayan ek bilgilerin sorumlu doktordan istenmesi gerektiği ya da hastanın ailesinin yaşlı büyükannenin tıbbi geçmişini yeterince anlatmadığı gerekçesiyle işaretlemeye benziyor. Daha titiz bir benchmark isteyebilirsiniz, ama OpenAI modelleri gerçek çalışanların yerine geçebilecek araçlar olarak vaat ediyorsa bu iyi bir tablo değil. Hatta tam tersine, bunları test etmek istemeniz gerekir

  • “Benchmark’ı düzeltmek için gereken tüm işi yapıp sonunda benchmark’ı bırakmaya karar verdiler” gibi okunuyor. Temel veri gerçekten bu kadar kıt da yamalanamıyor mu? Sonunda benchmark üretiminde biraz daha seçici bir yaklaşım öneriyorlar ama gerçek dünyadan gelen dağınık ve kusurlu testleri adil biçimde yamama yöntemi de bence oldukça sağlam bir yol

    • Bana, SWE Bench Pro’dan uzaklaşmak için başka sebepler varmış da onları söylemek istemiyorlarmış gibi geliyor. Yazının başında “görevlerin yaklaşık %30’u bozuktu” deniyor ama bu, yaklaşık %70’inin bozuk olmadığı anlamına geliyor ve bu da gayet iyi görünüyor
      “Bozuk instance listesi burada” ya da “bundan sonra kullanacağımız SWE Bench Pro alt kümesi şu” gibi bir şey de söylenebilirdi. Mükemmelin iyinin önünü kesmesine izin veriliyor
    • Sorunu işaret etmek, örneğin gizli testlerin dar uygulama ayrıntılarını varsaydığını söylemek, hangi uygulama tercihi olursa olsun çalışan testler hazırlamaktan çok daha kolay
    • Bunu düzeltirlerse artık SWE-Bench Pro olmaz, değil mi? “SWE-Bench-Pro-Fixed-OpenAI” olur. Benchmark’ın bağımsız görünümü düşünülürse, OpenAI ekibinin doğrudan düzeltmesindense üçüncü bir tarafın düzenleyip iyileştirilmiş bir sürüm çıkarması daha iyi görünüyor
      Gerçi OpenAI, SWE-Bench Verified’ı çıkarırken tam da bunu yaptı; dolayısıyla ben saçmalıyor olabilirim

  • Şu anda SWE benchmark’larında state of the art olarak neyi görmek gerekir?

    • Kişinin hedeflerine ve gereksinimlerine göre DeepSWE[0] ya da FrontierCode[1] derim. İkincisi bana kişisel olarak daha ilginç geliyor, çünkü verilen çıktının incelenmesinin kolay olup olmadığını, ciddi bir geliştiricinin bunu kolayca anlayıp birleştirmeye istekli olup olmayacağını ifade eden mergeability kavramını güçlü biçimde değerlendirecek şekilde tasarlanmış
      Benim düşünceme ve kişisel değerlendirmeme göre, bir modelin potansiyel üst sınırı daha yüksek olsa bile o koda gerçekten onay vereceğimden emin değilsem değeri uzun zamandır sınırlı
      [0] https://deepswe.datacurve.ai/
      [1] https://cognition.com/blog/frontier-code-1.1
    • Genel olarak DeepSWE[0]’nin gerçek dünyayla oldukça iyi örtüştüğünü düşündüm
      [0]: https://deepswe.datacurve.ai/

  • https://cognition.ai/blog/frontier-code var. Açık söylemek gerekirse ilgili ekipteydim, ama burada swebench pro/deepswe sorunları da ele alınmıştı

    • FrontierBench

  • AGI'ye ulaşmak, tüm benchmark'ları geçmekten daha fazlası olmalı ve bilinmeyen problemleri de hesaba katmalı

    • Eğer laboratuvarın içinde mevcut üründen büyük ölçüde kopuk bir şey yoksa, AGI tartışma konusu değildir ve neredeyse tamamen pazarlama amaçlı bir abartıya yakındır
    • AGI'ye daha çok var. Benim bilmediğim, LLM pazarlama terimleri arasında buna “AGI” diyen başka bir saçmalık varsa bilemem ama yapay genel amaçlı zeka, LLM ya da görüntü yapay zekasından o kadar farklı ki, ikisinin de yapay olması dışında aralarında karşılaştırma bile yapılamaz. AGI, token tahmininden çok daha fazlasını yapmak zorunda
    • Bu, LLM olmayan modeller yapılırken sık görülen bias-variance tradeoff(https://en.wikipedia.org/wiki/Bias%E2%80%93variance_tradeoff) ile bağlantılıdır
      Çözüm ya a) LLM'i benzer performansla daha küçük hale getirip ezber yapmasını veya benchmark'ı hedeflemesini engellemek, ya da b) gerçek dünya verisinin tamamını kapsayan bir benchmark oluşturmaktır; ancak ikincisi pratikte imkansızdır