🤖 AI

Towards Evaluation Engineering: An Empirical Study of ML Evaluation Harnesses in the Wild

Dit artikel presenteert een empirische studie van 57 machine learning-evaluatieharnassen die de specificatiefase als primaire bron van operationele uitdagingen identificeert, 16.560 problemen naar oorzaak categoriseert om te onthullen dat niet-geïmplementeerde functies, documentatiehiaten en ontbrekende inputvalidatie meer dan 60% van de problemen verklaren, en een fundament legt voor het behandelen van evaluatie-engineering als een afzonderlijke software-engineeringdiscipline.

Oorspronkelijke auteurs: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

Gepubliceerd 2026-05-26

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Zhimin Zhao, Zehao Wang, Abdul Ali Bangash, Bram Adams, Ahmed E. Hassan

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een chef bent die een nieuw recept moet beoordelen. Je hebt de ingrediënten (de data), het receptkaartje (het model) en een lijst met regels voor wat een gerecht "goed" maakt (de metrieken). Maar voordat je het eten kunt proeven, heb je een keuken nodig om in te koken, een timer om de kooktijd bij te houden en een scorebord om de resultaten op te schrijven.

In de wereld van Kunstmatige Intelligentie (KI) wordt deze "keuken" een Evaluatie-Harnas genoemd. Het is het softwarehulpmiddel dat de tests daadwerkelijk uitvoert, de data laadt, de scores berekent en je vertelt of het KI-model het goed doet.

Dit artikel is als een enorme inspectie van 57 verschillende "KI-keukens" om te zien hoe ze werken, waar ze stukgaan en waarom mensen er gefrustreerd van raken. De onderzoekers noemen dit nieuwe veld "Evaluatie-Engineering".

Hier is de uiteenzetting van hun bevindingen met eenvoudige analogieën:

1. De Vijf-Fasen Keukenworkflow

De onderzoekers ontdekten dat elke KI-evaluatiekeuken vijf specifieke fasen doorloopt, zoals een productielijn:

Provisioning (De keuken opzetten): De fornuizen, potten en ingrediënten klaarzetten. Dit omvat het installeren van software en inloggen op accounts.
Specificatie (Het recept schrijven): Beslissen wat je precies gaat koken en welke ingrediënten je gebruikt. Dit is waar je het KI-model en de testdata laadt.
Executie (Het eten koken): Het KI-model daadwerkelijk laten draaien om antwoorden te genereren.
Beoordeling (Proeven en scoren): De antwoorden controleren tegen de juiste antwoorden en een score berekenen.
Rapportage (Het menu serveren): De uiteindelijke resultaten tonen in een grafiek of een rapport.

De grote verrassing: De meeste van deze keukens zijn geweldig in "koken" (Executie), maar vreselijk in "serveren" (Rapportage). Weinigen hebben automatische alarmen om je te vertellen of het eten vandaag slechter smaakt dan gisteren.

2. Waar dingen misgaan (De oorzaken)

Het team keek naar meer dan 16.000 klachten (genaamd "issues") van gebruikers. Ze ontdekten dat de problemen meestal niet liggen aan verkeerde wiskunde of code die op dramatische wijze crasht. In plaats daarvan zijn de problemen voornamelijk bureaucratisch en ontbrekende onderdelen.

Denk eraan als het proberen om een Lego-set te bouwen waarbij de instructies ontbreken of de doos zegt "bevat een rode steen" maar je krijgt alleen een blauwe steen.

De top drie redenen waarom keukens falen zijn:

Ontbrekende functies (24%): Het hulpmiddel beloofde iets te doen (zoals een specifiek type data verwerken), maar de ontwikkelaars hebben dat deel nooit echt gebouwd. Het is als een auto met een stuurwiel maar zonder motor.
Slechte instructies (20%): Het hulpmiddel werkt, maar de handleiding ontbreekt, is verouderd of verwarrend. Gebruikers kunnen niet uitzoeken hoe ze het moeten gebruiken.
Geen veiligheidscontroles (17%): Het hulpmiddel controleert niet of de ingrediënten vers zijn. Als je het slechte data voert, stopt het niet; het kookt gewoon afval en geeft je een afvalscore.

3. De verschillende soorten keukens

De onderzoekers groepeerden de 57 keukens in vier "archetypen" (typen), en elk type heeft zijn eigen specifieke hoofdpijndilemma's:

De gestandaardiseerde testkeuken (40%): Dit zijn de grote, beroemde keukens die veel modellen testen tegen standaardexamens (zoals de SAT's voor KI).
- Hun grootste hoofdpijndilemma: Afhankelijkheidsbreuk. Ze vertrouwen op externe ingrediënten (datasets) die zonder waarschuwing veranderen of verdwijnen. Als de leverancier de verpakking verandert, stopt de hele keuken met werken.
Het gespecialiseerde hulpmiddel (21%): Dit zijn kleine tools die precies één ding perfect doen (zoals controleren of een robot kan lopen).
- Hun grootste hoofdpijndilemma: Slechte instructies. Omdat ze zo simpel zijn, vergeten ontwikkelaars duidelijke instructies te schrijven over hoe ze ze moeten opzetten.
De aangepaste sonde (21%): Deze testen specifieke vaardigheden (zoals coderen of wiskunde).
- Hun grootste hoofdpijndilemma: Wiskundefouten. Omdat ze hun eigen scoreformules bedenken, maken ze vaak rekenfouten, wat leidt tot stille fouten waarbij de score er goed uitziet maar eigenlijk verkeerd is.
Het full-service restaurant (17%): Dit zijn de chique, alles-in-één platformen die alles doen.
- Hun grootste hoofdpijndilemma: Contractmismatches. Omdat ze zoveel verschillende onderdelen verbinden (zoals een externe rechter en een lokaal model), spreken de onderdelen vaak geen dezelfde taal, wat leidt tot communicatieproblemen.

4. De "Stille Moordenaar"

Het gevaarlijkste probleem dat het artikel vond, zijn Stille Scorefouten.

Stel je voor dat een rechter een soep proeft en er een 5-sterrenbeoordeling aan geeft. De rechter is zelfverzekerd, de score wordt afgedrukt en iedereen is blij. Maar de rechter is vergeten zout toe te voegen en de soep smaakt vreselijk. Het hulpmiddel is niet gecrasht; het gaf gewoon een verkeerde score.

Het artikel vond dat veel tools scores onjuist berekenen (Algoritmische Fouten) of niet controleren of de data zinvol is (Validatiegaten), en omdat er geen "tweede mening" in het systeem is ingebouwd, merkt niemand het tot veel later.

5. Wat dit betekent voor de toekomst

Het artikel concludeert dat we deze tools niet alleen als "scripts" moeten behandelen, maar als serieuze engineeringproducten.

Ontwikkelaars moeten stoppen met aannemen dat de wiskunde perfect is en beginnen met het bouwen van "veiligheidsnetten" (zoals controleren of de score logisch is voordat deze wordt afgedrukt).
Gebruikers moeten stoppen met blind vertrouwen op de score. Alleen omdat het hulpmiddel zegt "95% nauwkeurigheid", betekent dat niet dat het waar is; je moet het werk dubbelchecken.
Onderzoekers moeten nieuwe manieren bedenken om deze tools te testen, omdat de oude manieren van software testen niet werken wanneer de "test" zelf een KI is die mogelijk hallucineert.

Kortom: We hebben geweldige machines gebouwd om andere machines te testen, maar de machines die testen doen, missen vaak instructies, hebben gaten in hun logica en ontberen het vermogen om ons te vertellen wanneer ze in de war zijn. Het repareren van deze "keukens" is net zo belangrijk als het bouwen van betere "chefs" (KI-modellen).

Technische Samenvatting: Naar Evaluatie-engineering: Een Empirische Studie van ML-evaluatieharnassen in de Praktijk

1. Probleemstelling

Machine Learning (ML)-evaluatie vormt de basis voor AI-vooruitgang, maar de software-infrastructuur die deze evaluaties uitvoert – bekend als evaluatieharnassen – heeft beperkte aandacht gekregen vanuit het perspectief van software-engineering (SE). Waar de bestaande literatuur zich richt op wat er geëvalueerd moet worden (metrieken, benchmarks, capaciteiten), behandelt zij de harnassen zelf als transparante hulpmiddelen in plaats van als ontworpen softwareproducten met specifieke operationele workflows, faalmodi en ontwerpafwegingen.

Deze lacune leidt tot een gebrek aan begrip van Evaluatie-engineering (EvalEng): de SE-problematiek die voortvloeit uit het operationeel maken van evaluatie, waaronder harnasontwerp, afhankelijkheidsbeheer, correctheid van scoring en integriteit van resultaten. Zonder dit inzicht wordt de betrouwbaarheid van ML-evaluatie ondermijnd door problemen zoals benchmarkverontreiniging, niet-reproduceerbare resultaten en stille scoringfouten die moeilijk te detecteren zijn in complexe infrastructuur.

2. Methodologie

De auteurs voerden een grootschalige empirische studie uit van 57 open-source evaluatieharnassen en 19.638 GitHub-issues (bugrapporten, functieverzoeken en gebruiksgerelateerde vragen) verzameld tot en met 6 januari 2026. De studie hanteerde een vierfasige methodologie:

Verzameling van Harnassen: Onderzoekers identificeerden 57 harnassen uit gecureerde bronnen (bijvoorbeeld de Awesome Production ML-lijst) en breidden de dekking uit via zoekopdrachten op GitHub op basis van trefwoorden. Opnamecriteria vereisten expliciete evaluatie-/benchmarkfunctionaliteit, modelinvoering en actief onderhoud (500+ sterren, activiteit in de laatste 12 maanden).
Extractie van Workflows: Met behulp van iteratieve open kaartsortering en constante vergelijking op documentatie en lokale uitvoering, ontwikkelde het team een hiërarchisch workflowmodel. Dit proces bereikte theoretische verzadiging bij het 51e harnas.
Mining van Issues: Het team haalde 19.638 issues op van de 57 harnassen (verspreid over 59 repositories).
Classificatie: Een hybride aanpak combineerde handmatige annotatie met classificatie door Large Language Models (LLM's).
- Handmatige Annotatie: Een statistisch significante steekproef van 377 issues werd handmatig gelabeld door twee auteurs om een taxonomie voor workflowfasen en oorzaken vast te stellen. De onderlinge betrouwbaarheid was hoog (Cohen's $\kappa > 0,87$ ).
- LLM-calibratie: Een classifier gebaseerd op Claude Haiku 4.5 werd gekalibreerd tegen menselijke consensuslabels en toegepast op het volledige corpus om issues af te beelden op workflowfasen en categorieën van oorzaken.

3. Belangrijkste Bijdragen

Het paper legt een empirische basis voor EvalEng via vier primaire bijdragen:

Een Gecombineerd Workflowmodel: Een model met vijf fasen, negen stappen en 34 strategieën dat de operationele levenscyclus van ML-evaluatie beschrijft (Provisioning $\to$ Specificatie $\to$ Uitvoering $\to$ Beoordeling $\to$ Rapportage).
Empirische Issue-afbeelding: Een classificatie van 16.560 workflow-gerelateerde GitHub-issues over de 57 harnassen, waarmee wordt geïdentificeerd waar operationele wrijving optreedt.
Taxonomie van Oorzaken: Een taxonomie met tien categorieën van operationele uitdagingen, die onderscheid maakt tussen softwarefouten (bijvoorbeeld algoritmische fouten) en capaciteitsgaten (bijvoorbeeld niet-geïmplementeerde functies).
Identificatie van Aannameslacunes: Een analyse die significante gaten blootlegt in productie-gerichte capaciteiten, zoals kwantificering van onzekerheid en alarmering bij regressie.

4. Belangrijkste Resultaten

RQ1: Operationele Workflow

De studie identificeerde een workflow met vijf fasen:

Provisioning: Inrichten van de omgeving en configureren van referenties.
Specificatie: Definieren van invoer (modellen, datasets) en scorende beoordelaars.
Uitvoering: Uitvoeren van het System-under-Test (SUT).
Beoordeling: Berekenen van metrieken en aggregeren van scores.
Rapportage: Visualiseren van resultaten en alarmeren bij regressies.

Vondsten:

Dominantie van Offline-werk: De meeste harnassen (40,4% Gestandaardiseerde LLM-suites, 21,1% Specifiek domein-bibliotheken) zijn beperkt tot statische, offline workflows. Slechts 17,5% (Full-stack LLM-platforms) beslaat alle vijf fasen.
Strategiegaten: Hoewel installatie (git clone, Python-pakketten) bijna universeel is, is containerized deployment zeldzaam (21,1%). Productieverkeersampling wordt slechts door 7,0% van de harnassen ondersteund.
Tekortkomingen in Rapportage: Rapportage is de minst ondersteunde fase. Slechts 22,8% van de harnassen kwantificeert onzekerheid, en slechts 8,8% biedt alarmering bij regressie.

RQ2: Oorzaken van Operationele Uitdagingen

De studie classificeerde 16.560 issues in tien oorzaken. De top drie oorzaken zijn verantwoordelijk voor 61,7% van alle issues:

Gat in niet-geïmplementeerde functionaliteit (24,3%): Vereiste functionaliteit ontbreekt.
Tekortkoming in documentatie (20,3%): Ontbrekende of verouderde instructies.
Gat in validatie (17,2%): Ontbrekende input/output-validatie.

Patronen per Archetype:

Gestandaardiseerde LLM-suites: Hoog volume aan issues; secundaire oorzaak is Breuk in externe afhankelijkheden (8,9%) door afhankelijkheid van veranderende upstream-datasets.
Opdracht-specifieke probes: Secundaire oorzaak is Algoritmische fout (11,9%), aangezien domeinspecifieke scoring ontbreekt aan referentie-implementaties.
Full-stack platforms: Secundaire oorzaak is Mismatch in interfacecontracten (10,6%) door complexe integratie van meerdere componenten.
Bibliotheken voor specifieke domeinen: Tekortkoming in documentatie (31,8%) is de primaire oorzaak, en overtreft hierbij de gaten in functionaliteit.

RQ3: Distributie van Oorzaken over Fasen

Oorzaken zijn niet uniform verdeeld; ze concentreren zich in specifieke fasen:

Provisioning: Gedomineerd door Incompatibiliteit van omgeving (16,1%) en Breuk in externe afhankelijkheden (20,1%).
Specificatie: Geconcentreerd op Gat in niet-geïmplementeerde functionaliteit (32,8%) en Tekortkoming in documentatie (27,1%).
Beoordeling: Gedomineerd door Algoritmische fout (25,9%) en Gat in validatie (22,5%).
Cross-cutting: Gat in validatie is de enige oorzaak die in alle vijf fasen boven de 10% uitkomt, wat wijst op een systemische behoefte aan betere semantische validatie.

Workflowverschuiving: Uitdagingen verschuiven van omgevingsgerelateerde problemen in de vroege fasen naar scoring-gerelateerde problemen in de latere fasen.

5. Betekenis en Implicaties

Het paper betoogt dat evaluatiebetrouwbaarheid een distincte software-engineering-problematiek is die aandacht vereist die verder gaat dan het ontwerpen van metrieken.

Voor Ontwikkelaars:
- Ga verder dan schema-validatie naar semantische API-contracten om stille fouten te voorkomen (bijvoorbeeld geldige typen maar incorrecte semantiek).
- Implementeer oracle-onafhankelijke verificatie (bijvoorbeeld metamorfe testing, differentiaal testing) voor scoringpijplijnen, aangezien harnasuitvoer vaak geen onafhankelijke grondwaarheid heeft.
- Pas onderhoud toe op archetype-specifieke faalmodi (bijvoorbeeld afhankelijkheden vastpinnen voor benchmarksuites, contracttesting voor full-stack platforms).
- Lever machine-leesbare specificatiedocumenten (vergelijkbaar met modelkaarten) die workflowdekking, afhankelijkheden en bekende uitdagingpatronen declareren.
Voor Gebruikers:
- Behandel harnasuitvoer niet als grondwaarheid zonder onafhankelijke verificatie, vooral bij afwijkingen van de ontworpen benchmarkconfiguraties.
- Herken dat de meeste harnassen geen kwantificering van onzekerheid bieden, wat het moeilijk maakt om echte capaciteitsgaten te onderscheiden van harnasartefacten.
Voor Onderzoekers:
- Behandel evaluatie-engineering als een SE-onderzoeksonderwerp. Bestaande MLOps- en testframeworks vereisen structurele aanpassing om de unieke beperkingen van evaluatieharnassen aan te kunnen (bijvoorbeeld promptgevoeligheid, verschuivende baselines en verschuivingen in de distributie van statisch versus productieverkeer).
- Onderzoek hoe regressiedrempels en statistische significantie gedefinieerd kunnen worden in omgevingen waar baselines niet stabiel zijn.

De studie concludeert dat het verbeteren van evaluatiebetrouwbaarheid een holistische aanpak van workflowontwerp over alle fasen vereist, in plaats van geïsoleerde verbeteringen van metrieken of benchmarks. Het geboden workflowmodel en de taxonomie van oorzaken bieden een basislijn voor longitudinaal onderzoek om de rijping van evaluatie-infrastructuur te volgen.