# Kako brati merila za AI-programiranje in se izogniti izbiri zmagovalca na papirju > Kaj merita HumanEval in SWE-bench ter kako pri branju lestvic AI-orodij za programiranje upoštevati agentski ovoj, pogoje, svežino nalog, varianco in stroške. Source: https://ailoot.ai/blog/sl/read-ai-coding-benchmarks/ Canonical: https://ailoot.ai/blog/sl/read-ai-coding-benchmarks/ Language: sl Publisher: Ailoot (https://ailoot.ai/) Translation: guide-125 Revision: sha256-0a829be01fef1e3e0735692e379bfb60d238d941f74f7f6c7432553c50344ccd Na kratko: podatek »reši 76 odstotkov nalog« sam po sebi skoraj nič ne pove. Pomembno je, kateri nabor nalog je dal ta rezultat, kateri model in agentski ovoj sta bila ocenjena skupaj, ali so naloge nove ali stare ter koliko je vse skupaj stalo. Brez teh pogojev je odstotek primeren za oglasni pas, ne pa za izbiro orodja. V nadaljevanju bom preprosto pojasnil, kaj merita glavni merili za programiranje, kje se skriva past v preglednicah in kako lahko v minuti preverite katero koli lestvico, preden se zanesete nanjo. Spodaj so obravnavane zgodovinske opredelitve primerjalnih testov. Tukaj ni para živih posnetkov lestvice; trenutna primerjava ocen ali stroškov potrebuje svojo povezano tabelo, datum in konfiguracijo. Več o delu z modeli preberite v [dokumentaciji Ailoot](https://ailoot.ai/docs/). ## Kaj pravzaprav prikazuje odstotek pri merilu?
Ključna ugotovitev Odstotek pri merilu je delež nalog iz določenega nabora, ki jih je orodje opravilo z delujočim rezultatom pod določenimi pogoji. Naloge preverijo avtomatizirani testi: koda test opravi ali pa ga ne; ocenjevanje je pošteno in ni ga mogoče opraviti »bolj ali manj«. Toda nabor nalog je vedno ozek in vnaprej znan, pogoji merjenja pa se za vsakega razlikujejo. Zato številka odgovarja na vprašanje: »Koliko teh nalog je to orodje rešilo na ta način?« Ne odgovarja pa na vprašanje: »Ali bo kos mojemu delu?«
Merilo deluje preprosto. Obstaja pripravljen seznam programerskih nalog. Orodje dobi vsako nalogo in vrne kodo, sistem pa zažene avtomatizirane teste, da preveri, ali rešitev deluje. Delež opravljenih nalog je odstotek, prikazan v preglednici. Prednost je objektivnost ocenjevanja. Test je bodisi uspešen bodisi neuspešen; nihče ne določa rezultata »na oko«. V tem pogledu so merila poštenejša od kakršnih koli mnenj ali priporočil. Slabost je povsem enaka. Nabor nalog je omejen in vnaprej znan vsem, tudi tistim, ki usposabljajo modele. Vsaka meritev ima svoje pogoje. Naloge v naboru pa skoraj zagotovo niso podobne vašemu delu. Iz tega izvirajo vse pasti, o katerih govorim v nadaljevanju. Odstotek opisuje vedenje orodja na zaprtem seznamu nalog nekoga drugega in se ne prenese neposredno na vaš projekt. ## Kaj meri HumanEval in zakaj se po njem ne morete več odločati?
Ključna ugotovitev HumanEval je star nabor 164 majhnih nalog v Pythonu: modeli dobijo opis funkcije, napišejo kodo, avtomatizirani testi pa preverijo nalogo. Ko je bil objavljen leta 2021, je prvi Codex v enem poskusu rešil 28,8 odstotka nalog. Danes zmogljivi modeli opravijo skoraj vse, zato med njimi ne more več razlikovati. Poleg tega so naloge zgolj preprosti primeri: ena funkcija, napisana na podlagi opisa, je daleč od dela na velikem, delujočem projektu. Visok rezultat pri HumanEval leta 2026 skoraj nič ne pomeni.
HumanEval je ustvaril OpenAI in ga leta 2021 objavil skupaj z modelom Codex. Vsebuje 164 majhnih nalog v Pythonu: modeli dobijo besedni opis funkcije, napišejo njeno telo, nabor avtomatiziranih testov pa preveri, ali deluje pravilno. Takrat je bil dobro merilo za razlikovanje. Avtorji v svojem članku navajajo ta podatek: prvi Codex je v enem poskusu rešil 28,8 odstotka nalog, običajni GPT-3 pa ni rešil nobene.

Pri HumanEval naš model reši 28,8 odstotka problemov, GPT-3 pa 0 odstotkov, GPT-J pa 11,4 odstotka.

— OpenAI, članek »Evaluating Large Language Models Trained on Code«
Modeli so od takrat napredovali, danes pa zmogljivejši opravijo skoraj ves HumanEval. Ko vsi dosegajo rezultate blizu 100 odstotkov, preglednica ne razlikuje več med njimi: razlike med orodji se izgubijo. Temu pravimo nasičenost merila, HumanEval pa je v takem stanju že dolgo. Druga pomanjkljivost je resnejša. Naloge so majhne: napisati eno funkcijo na podlagi opisa. Vaše resnično delo je drugačno—gre za velik projekt z zgodovino, v katerem morate razumeti tujo kodo, poiskati napako in ne pokvariti sosednje kode. Med »napiši funkcijo od začetka« in »odpravi napako v delujočem projektu« je velika razlika. Zato visok rezultat pri HumanEval danes ni več razlog za izbiro orodja; bolj je znak, da »so osnove pokrite«. ## Kaj meri SWE-bench in zakaj je bližje resničnemu delu?
Ključna ugotovitev SWE-bench temelji na resničnih napakah v priljubljenih projektih GitHub: obsega 2.294 nalog iz 12 repozitorijev Python. Orodje dobi opis težave, spremeni kodo, sistem pa zažene teste, ki so pred spremembo padli in bi morali po popravku uspeti. To je precej bližje resničnemu delu kot HumanEval, zato se uporablja za primerjavo resnih orodij. Njegovo zahtevnost jasno kaže zgodovina: prvi preprosti pristop je rešil manj kot dva odstotka nalog.
SWE-bench je bistveno drugačen in zato zanimivejši. Nastal je na podlagi resničnih težav in zahtevkov pull request v priljubljenih projektih GitHub. Po navedbah avtorjev vsebuje 2.294 nalog iz 12 velikih repozitorijev Python in je bil objavljen oktobra 2023. Logika ocenjevanja je poštena. Izberejo stanje projekta, v katerem je bila resnična napaka, in nabor testov, ki so takrat padli. Orodje dobi opis težave in spremeni kodo. Nato zaženejo iste teste: če so uspešni, je naloga dejansko rešena; tukaj nihče ne zaupa ustnim obljubam.

Zbrali smo 2.294 nalog tako, da smo pregledali zahtevke pull request in težave iz 12 priljubljenih repozitorijev Python. Vsaka naloga temelji na zahtevku pull request, povezanem s težavo, in spremeni vsaj eno datoteko, povezano s testi.

— SWE-bench, uradna spletna stran merila
Začetni podatki pokažejo, koliko težje je to od preprostih nalog. Prvi osnovni pristop je pri SWE-bench dosegel le 1,96 odstotka, prvi agent pa 12,47 odstotka. Z drugimi besedami, že približati se resničnemu programerskemu delu je bilo težko; odstotki so se pozneje zvišali, vendar so začeli blizu ničle. Zato velike številke v današnjih lestvicah AI-agentov za programiranje najpogosteje izvirajo iz SWE-bench ali njegovega sklopa 500 nalog, preverjenega s človeškim pregledom, imenovanega SWE-bench Verified. To je smiselno merilo. Toda tudi pri njem obstajajo pogoji, brez katerih je odstotek zavajajoč; o tem bom govoril v nadaljevanju. Tudi najbolj pošten rezultat merila v preglednici še ni rezultat na vašem projektu. Izid je odvisen od tega, kako delate z orodjem, zgornja vrstica lestvice pa pove zelo malo. Za zanesljivo delo je pomembna kombinacija: klon AI, Second Brain in inženiring konteksta. Čist kontekst opazneje izboljša vašo osebno uspešnost kot izbira modela iz preglednice. ## Zakaj isti model pokaže drugačen odstotek?
Ključna ugotovitev Ker rezultat ni odvisen samo od modela. Pri vsaki meritvi sodelujejo vsaj trije dejavniki: model sam, agentski ovoj okoli njega in omogočena raven sklepanja. Sprememba nastavitve sklepanja lahko za isti model in agentski ovoj ustvari različne vrstice. Brez imena izvajalnega okolja, revizije, nastavitev in datiranega vira te vrstice ne podpirajo številčne primerjave. Zato morate primerjati celotne kombinacije; sama blagovna znamka modela ne pove veliko.
Tu se skriva najpogostejša napaka pri branju rezultatov meril. Ljudje preglednico berejo kot lestvico modelov: ta model je za dva odstotka pametnejši od drugega. Toda na odstotek vplivajo trije dejavniki, model pa je le eden izmed njih. Prvi je model sam. Drugi je agentski ovoj okoli njega: program, ki modelu omogoča pregledovanje datotek, izvajanje ukazov, branje napak in prepisovanje kode. Isti model bo v pametnem in preprostem ovoju dosegel različne rezultate, saj ovoj določa, kako model dela s projektom. Tretji dejavnik je raven sklepanja—to je, kako poglobljeno model premisli vsak korak. Dlje ko razmišlja, višji je običajno odstotek in višji so stroški. Ponovljiva primerjava naj ohrani celotno nastavitev. To uporabite kot predlogo poročanja, ne izmerjeno lestvico: | Polje | Zagon A | Zagon B | |----|----|----| | Model in točna različica | Zabeležite preizkušeno različico | Ista različica za nadzorovano primerjavo | | Agentsko izvajalno okolje in revizija | Zabeležite repozitorij in commit | Isto okolje in commit | | Nabor nalog in ocenjevanje | Zabeležite podnabor in revizijo vrednotenja | Isti nabor nalog in ocenjevanje | | Nastavitev sklepanja | Zabeležite nastavitev A | Zabeležite nastavitev B | | Rezultat in dokaz | Število rešenih, imenovalec, dnevniki, datum | Število rešenih, imenovalec, dnevniki, datum | Tako lahko vidite, kaj se je spremenilo in ali primerjava res izolira nastavitev sklepanja. Prejšnji nepovezani številčni primer se ne obravnava kot izmerjen rezultat. Pravilo je preprosto: dobra lestvica vedno navede, kateri model, ovoj in raven sklepanja so bili uporabljeni. Če preglednica vsebuje samo ime modela in odstotek, ovoja pa ne navede, ji je težko zaupati: ne veste, kaj so dejansko merili. Več o sestavi kombinacije »model plus ovoj« pojasnjuje članek o [lestvici AI-agentov za programiranje](https://ailoot.ai/blog/sl/ai-coding-agent-rankings/). To pojasni tudi, zakaj se orodje z vrhunskim rezultatom včasih pri vas izkaže za težavno. Merilo ocenjuje model v izpopolnjenem ovoju nekoga drugega, na nalogah nekoga drugega. Vaš ovoj, projekt in kontekst, ki ga ponudite modelu, so drugačni. Na vašem projektu je rezultat odvisen od konteksta; vrstica v preglednici je drugotnega pomena. ## Zakaj naloge »zastarajo« in kaj je uhajanje podatkov za učenje?
Ključna ugotovitev Modeli se učijo na ogromnih količinah besedil in kode z interneta, priljubljena merila pa so javno dostopna. Če so naloge in njihove rešitve zašle v učne podatke, si jih je model morda zapomnil in med ocenjevanjem samo ponovi zapomnjeno, namesto da bi nalogo rešil. Temu pravimo uhajanje nalog v učne podatke. Starejši in bolj znan ko je nabor, večje je tveganje: staro merilo verjetneje pokaže spomin modela kot njegovo sposobnost sklepanja. Sveži in zaprti nabori nalog so zanesljivejši od starih in javnih.
Tukaj je past, ki je v sami številki ne vidimo, a jo spodkoplje bolj kot kar koli drugega. Modeli se učijo na ogromnih količinah besedil in kode, zbranih z interneta. Skoraj vsa merila za programiranje so javno dostopna: naloge, testi in referenčne rešitve. Mehanizem je preprost. Če sta naloga in njena pravilna rešitev prišli v učne podatke, si ju je model morda zapomnil. Med ocenjevanjem naloge ne rešuje toliko, kot iz spomina prikliče znan odgovor. Videti je kot rešitev, vendar gre zgolj za spomin. Temu pravimo uhajanje v učne podatke ali kontaminacija podatkov. Starejši in bolj priljubljen ko je nabor nalog, večje je tveganje. HumanEval je na spletu od leta 2021; večkrat so ga prepisali in analizirali ter ga vključili v nešteto naborov podatkov. Čudno bi bilo pričakovati, da ga sodoben model še ni »videl«. Zato je svežina nalog ločen kazalnik kakovosti merila. Dober nabor se redno posodablja ali pa nekatere naloge ostanejo zaprte, da se jih ni mogoče naučiti vnaprej. Kaj storiti pri branju lestvice? Preverite datum nalog in ali se nabor posodablja. Če merilo temelji na svežih napakah iz zadnjih mesecev, si zasluži več zaupanja. Če gre za nabor izpred petih let, visok odstotek pove več o dobrem spominu modela kot o njegovi sposobnosti reševanja nove naloge. Ta učinek je prikazan s konkretnim primerom v članku o [svežem merilu FrontierCode](https://ailoot.ai/blog/sl/frontiercode-benchmark-mergeable-ai-code/), katerega naloge so bile namenoma nove. ## Zakaj razlika nekaj odstotnih točk pogosto ne pomeni ničesar?
Ključna ugotovitev Merila imajo varianco: isto orodje na istih nalogah v različnih izvedbah doseže nekoliko drugačne rezultate, ker se model ne odzove vedno enako. Zaradi tega se razlika ene ali dveh točk med sosednjima vrsticama lestvice pogosto izgubi v šumu in ne kaže resnične premoči. Ločeno preverite tudi ceno: podobni odstotki lahko stanejo večkrat toliko. Stroške primerjajte samo, kadar sta navedeni obe celotni nastavitvi, stopnji uspeha, predpostavke obračunavanja in imenovalec cene.
Še en razlog, zakaj je vrh preglednice lahko zavajajoč: model ne odgovori vsakič enako. Na isti prompt lahko izbere nekoliko drugačno pot razmišljanja. Če torej isto orodje večkrat zaženete na enem naboru nalog, bo odstotek med izvedbami nekoliko nihal; temu nihanju pravimo varianca. Praktični sklep je preprost. Če se dve vrstici lestvice razlikujeta za eno ali dve odstotni točki, je razlika lahko zgolj šum. Nesmiselno je loviti orodje, ki je »za dva odstotka boljše«: pri naslednji izvedbi se vrstici zlahka zamenjata. Razlika je vredna pozornosti, če je opazna in se ohrani na velikem naboru nalog; nekaj točk ne dosega tega praga. Zadnja stvar, ki je skoraj vedno pomembnejša od samega odstotka, je cena. Podobni rezultati lahko stanejo zelo različno. Primerjava cene potrebuje obe konfiguraciji modela z izvajalnim okoljem in celotno porabo na ocenjenem naboru nalog, vključno z neuspešnimi poskusi. Za strošek poskusa delite s številom vseh poskušanih nalog, za strošek rešene naloge pa s številom rešenih; mero označite. Ta članek ne podaja para meritev stroškov z viroma. Zato pri branju vrstice lestvice vedno upoštevajte tudi ceno, saj odstotek sam po sebi pomeni malo. Članek o [strošku ene rešene naloge](https://ailoot.ai/blog/sl/ai-agent-cost-per-solved-task/) pojasnjuje, kako pravično primerjati stroške orodij. ## Kako lahko v minuti preberete katero koli preglednico merila?
Ključna ugotovitev Preden se zanesete na lestvico, ji postavite sedem vprašanj: Kateri nabor nalog? So naloge sveže ali stare? Kateri model? Kateri agentski ovoj? Katera raven sklepanja? Kolikšen je strošek na nalogo? Kako velika je varianca? Če preglednica ne odgovori vsaj na polovico teh vprašanj, ji ne morete zaupati: verjetno gre za oglas. Ločeno preverite, ali so naloge v naboru podobne vašemu resničnemu delu, saj se tudi pošten odstotek, dosežen na nalogah nekoga drugega, ne prenese na vaš projekt.
Vse skupaj strnimo v kratek kontrolni seznam. Odprite katero koli preglednico lestvice in po vrsti preglejte teh sedem točk. 1. **Kateri nabor nalog?** HumanEval je danes šibek; SWE-bench je bližje resničnemu delu. Če ime nabora sploh ni navedeno, vam ni treba brati naprej. 2. **So naloge sveže ali stare?** Svež ali delno zaprt nabor je zanesljivejši od starega javnega nabora, ki se ga je model morda naučil. 3. **Kateri model so merili?** Natančno ime in različica, ne nejasen »AI« ali ime družine modelov. 4. **Kateri agentski ovoj?** Odstotek velja za kombinacijo »model plus ovoj«. Če ovoj ni naveden, ne veste, kaj so merili. 5. **Katera raven sklepanja?** Isti model na različnih ravneh daje različne odstotke in stroške. 6. **Koliko stane ena naloga?** Podobni rezultati se lahko po ceni razlikujejo za večkratnik. Odstotek preberite skupaj s stroškom. 7. **Kako velika je varianca?** Razlika ene ali dveh točk med vrsticama je pogosto zgolj šum. Obstaja še osmo vprašanje, ki se nanaša na vas: **Ali so naloge v naboru podobne vašemu delu?** Merilo nalog v Pythonu le malo pove nekomu, ki izdeluje spletno stran ali bota z drugačnim naborom orodij. Tudi pošten rezultat na nalogah nekoga drugega ne zagotavlja uspeha na vašem projektu. Obstaja samo en zanesljiv način za preverjanje: z orodjem izvedite nekaj svojih tipičnih nalog in si rezultat oglejte sami. Članek o [preverjanju kode, ki jo ustvari AI](https://ailoot.ai/blog/sl/check-ai-generated-code/), pojasnjuje, kako ugotoviti, ali koda deluje, če sami ne programirate. ## Na kaj se torej velja osredotočiti?
Ključna ugotovitev Pozorni bodite na pogoje pod vrhnjo vrstico, ne le na vrhnjo vrstico samo: nabor nalog in njegovo svežino, kombinacijo »model plus ovoj«, raven sklepanja, strošek na nalogo in velikost variance. Gola številka brez teh pogojev ne dokazuje ničesar. Ne pozabite, da se tudi pošten odstotek, dosežen na nalogah nekoga drugega, ne prenese na vaš projekt: zadnjo besedo imajo vedno preizkusi na vaših resničnih nalogah, vaš rezultat pa je bolj odvisen od tega, kako delate z orodjem, kot od njegovega mesta na lestvici.
Glavno sporočilo celotnega članka je kratko: mesto na lestvici je razlog, da si orodje ogledate pobliže, vendar boste morali sami raziskati še naprej. Visoka številka pove le, da se je orodje dobro odrezalo na določenem zaprtem seznamu nalog pod določenimi pogoji. Odstotek ne pokaže, ali se ti pogoji ujemajo z vašimi. Zato preberite podrobnosti ob vrstici lestvice: katere naloge so uporabili, kako sveže so, za katero kombinacijo modela in ovoja gre, katero raven sklepanja so uporabili, koliko stane in ali se razlika izgubi v šumu. Preglednica, ki ne odgovori na ta vprašanja, je primerna za oglasni pas. Ocena [s katerim orodjem programirati leta 2026](https://ailoot.ai/blog/sl/ai-coding-tools/) pojasnjuje, katero orodje izbrati za svoje naloge. Pomembnejše od katerega koli merila pa je naslednje. Tudi najboljše orodje na lestvici ima težave z neurejenim kontekstom in deluje dobro s čistim kontekstom. Vaša osebna uspešnost je odvisna od tega, kaj ponudite modelu in kako zastavite nalogo; vrstica v preglednici je drugotnega pomena. Lestvica pomaga izločiti očitno šibke možnosti, rezultat pa ustvarite vi.
### Viri - [HumanEval - nabor podatkov openai/openai_humaneval (huggingface.co)](https://huggingface.co/datasets/openai/openai_humaneval) - nabor 164 nalog v Pythonu, preverjenih z avtomatiziranimi testi
Mesto na lestvici izloči šibke možnosti, rezultat na vašem projektu pa je odvisen od metode: klon AI plus Second Brain plus inženiring konteksta. Za nadaljnje delo—[Ailoot](https://ailoot.ai/). ## Vprašanja in odgovori: Kako brati merila za AI-programiranje in se izogniti izbiri zmagovalca na papirju ### Kaj zabeležim pred primerjavo dveh vrstic primerjalnega testa? Zabeležite točen model, agentsko izvajalno okolje in revizijo, nastavitve sklepanja, podnabor nalog, način ocenjevanja, datum ter neposredni vir rezultata. Brez teh polj razlike v oceni ni mogoče pripisati eni spremenjeni nastavitvi. ### Ali je strošek poskušane naloge enak strošku rešene naloge? Ne. Za prvo mero celotno porabo vrednotenja delite z vsemi poskušanimi nalogami, za drugo pa z rešenimi. Vključite stroške neuspešnih poskusov in pred primerjavo cen označite imenovalec. ## Ailoot · Podjetje in njegov portfelj projektov Ailoot temelji na pridobljenih operativnih izkušnjah, široki bazi strank, stabilni storitvi in stalnem spremljanju KPI. Podjetje in njegov portfelj projektov: milijoni strank; mesečna prodaja v milijardah. Ailoot te operativne izkušnje uporablja za dostop prek API do funkcij umetne inteligence v izdelkih strank, agentih, aplikacijah in avtomatizacijah.