En benchmark er en kontrakt med en nævner

Ydelsespålidelighed opstår, når arbejdsbyrde, omfang, hardware, kvalitetsbetingelse, baseline og usikkerhed følger med tallet.

En benchmark er en kontrakt med en nævner

Tallet, der glemmer sin nævner

Et benchmarkresultat kan være målt korrekt og stadig besvare det forkerte spørgsmål. Den sædvanlige synder er ikke en defekt timer eller en uærlig ingeniør. Det er nævneren, der forsvandt mellem testopsætningen og præsentationssiden. "Dobbelt så hurtigt" lyder som en sammenligning, men det siger ikke dobbelt så hurtigt ved hvilket arbejde, på hvilken maskine, med hvilken software, under hvilken kvalitetsbetingelse, mod hvilken baseline eller for hvilke brugere. Fjern disse betingelser, og et præstationstal bliver et poleret fragment. Det kan forblive numerisk sandt. Det fortæller ikke længere en køber eller en operatør, hvad de kan forvente.

Nævneren er det arbejde, som resultatet udtrykkes i forhold til. For gennemløb er det det fuldførte arbejde og den tid, hvori fuldførelsen tælles. For latenstid er det forespørgselsdefinitionen, den inkluderede sti og populationen af observationer. For nøjagtighed er det det mærkede sæt, mærkningsreglen og den enhed, der vurderes. For energi er det grænsen for det målte system og det arbejde, der leveres inden for denne grænse. For omkostninger er det omkostningsperioden, de inkluderede ressourcer og mængden af nyttigt arbejde. Et benchmark er ærligt, når dets tæller og nævner følges ad.

Derfor behandles et benchmark bedst som en kontrakt. Kontrakten navngiver spørgsmålet, arbejdsbelastningen, omfanget, hardwaren og softwaren, målingen, baselinen, usikkerheden og den metode, hvorved en anden part kunne kontrollere resultatet. En kontrakt kan være snæver. Den kan være undersøgende. Den kan kun være nyttig for én implementering. Hvad den ikke kan være, er et imponerende tal, hvis betingelser overlades til læseren at gætte. At gætte er en dårlig måde at allokere offentlige midler på og en endnu dårligere måde at designe en tjeneste, som en anden skal holde i live.

Den europæiske vane med at nedskrive definitioner bliver lejlighedsvis hånet som papirarbejde. I målearbejde er definitioner den del, der forhindrer papirarbejde i at blive til folklore. Benchmarktabellen er ikke et administrativt bilag til resultatet. Det er resultatets identitetskort.

Læs enheden, før du læser overskriften

Start med enheden, men stop ikke der. Forespørgsler pr. sekund, tokens pr. sekund, millisekunder, joule pr. forespørgsel, euro pr. tusinde poster og procentpoint fortæller dig noget. Ingen af dem fortæller dig, hvad systemet blev bedt om at gøre. Et resultat på 100 forespørgsler pr. sekund kan beskrive små cachelagrede forespørgsler eller store ikke-cachelagrede forespørgsler, der inkluderer hentning, validering og en menneskelig overdragelse. En latenstid på 20 millisekunder kan dække en enkelt kerne eller en hel beslutningssti. Enheden er en dør. Arbejdsbelastningen er rummet bag den.

Antag, at en indkøbspræsentation siger, at en ny tjeneste er 40 procent hurtigere end den eksisterende. Sætningen er endnu ikke bevis. Den kræver mindst den operation, der tidsmåles, inputstørrelsen og -fordelingen, det arbejde, der er udelukket fra uret, samtidigheden, opvarmningstilstanden, softwareversionerne, hardwaren og baselinekonfigurationen. Den kræver også kvalitetsbetingelsen. Hvis den hurtigere sti returnerer færre valide resultater, dropper lange input eller springer et dyrt verifikationstrin over, er tælleren blevet gjort mindre ved at ændre arbejdet.

Dette er ikke en anmodning om en enorm tabel, før nogen må tale. Det er en anmodning om at identificere de få felter, der ændrer betydningen af påstanden. Et lille parserbenchmark kan kræve postform, inputkilde, valideringspolitik, compiler og processor. Et inferensbenchmark kan kræve model, præcision, batch, scenarie, kvalitetsmål og strømgrænse. En offentlig sektor-kø kan kræve sagsdefinition, serviceur, routingregel og eskaleringssti. Felterne er forskellige. Forpligtelsen til at navngive dem er ikke.

Her er en nyttig disciplin: skriv resultatet som en sætning, der kan overleve en anden læser. "Under denne arbejdsbyrde og dette kvalitetskrav, på dette system og denne version, var den målte værdi dette, med denne variation." Hvis sætningen ikke kan fuldføres uden ord som typisk, bedste, produktionslignende eller repræsentativ, er metoden ikke færdig. De ord kan være gyldige, men de kræver en operationel definition, ikke en varm tone.

Et benchmark-kort er ikke pynt omkring et tal. Det er den mindste brugbare form for tallenes kontrakt.

Omfang er en del af resultatet

Omfang besvarer et enkelt spørgsmål: hvad dækker dette resultat, og hvad efterlader det uden for rammen? I maskinlæringsevaluering omfatter omfanget opgaven, datasættet, opdelingen, sproget, inputlængden, driftsscenariet og de tilladte implementeringsvalg. I en softwaretjeneste omfatter det ruten, datalagrene, netværket, cachen og det arbejde, et efterfølgende team udfører, efter at den målte slutpunkt returnerer. Et resultat målt på ét lag bør ikke stille og roligt blive til et løfte om hele tjenesten.

MLCommons gør dette synligt i sin MLPerf Inference-dokumentation. Indsendelsesguiden adskiller datacenter- og edge-systemtyper, oplister scenarier såsom offline, server, interaktiv, enkeltstrøm og flerstrøm, og adskiller en lukket division fra en åben division. Den lukkede division er beregnet til en æble-til-æble-sammenligning med samme model og referenceopsætning. Den åbne division tillader valg såsom genoptræning eller modelsubstitution. Ingen af dem er den universelt korrekte division. De besvarer forskellige spørgsmål. En overskrift, der blander dem, er ikke et bredt perspektiv. Det er en kategorifejl med fremragende typografi.

Den samme dokumentation viser, hvorfor et benchmark har brug for en eksplicit kvalitetsside. En oplistet ResNet50-post nævner ImageNet-2012-valideringssættet, dets datasæt- og forespørgselsprøvelistestørrelser, en referenceaccuracy og en serverlatensbegrænsning. For den oplistede ResNet50-post giver siden et valideringssæt på 50 000 billeder, en forespørgselsprøveliste på 1 024, en referenceaccuracy på 76,46 procent og en serverlatensbegrænsning på 15 ms. Disse felter er ikke trivialiteter for folk, der nyder at læse regler. De forklarer, hvad den rapporterede hastighed fik lov til at betyde. Skift datasættet, scenariet eller kvalitetskravet, og sammenligningen er ændret, selvom modelnavnet ser bekendt ud.

En europæisk køber bør være mistænksom over for omfang, der antydes af en produktlabel. "AI-platform", "accelerator" og "enterprise-grade" definerer ikke arbejdet. Et system, der er fremragende til en afgrænset operation, kan være præcis, hvad en tjeneste har brug for. Et system, der hævder at dække alt, har måske målt næsten intet, der ligner tjenesten. Snæver sandhed er sundere end universel tåge.

Dækning ændrer betydningen

Dækning er ikke en fodnote om, hvorvidt testsættet var stort. Det beskriver, hvis tilfælde og hvilke situationer der indgår i målingen. En benchmark kan dække mange eksempler fra én snæver fordeling og stadig sige lidt om de kanter, der betyder noget i drift. Omvendt kan et lille, nøje udvalgt sæt afsløre en vigtig fejltilstand uden at understøtte et generelt præstationskrav. Valget er en designbeslutning. Det skal angives som sådan.

OECD's ramme for karakterisering af AI-evalueringsinstrumenter er nyttig, fordi den nægter at reducere en evaluering til én score. Den foreslår 18 facetter, herunder dækning, formål, realisme, validitet, pålidelighed, transparens og de betingelser, hvorunder resultater kan fortolkes. Dækning spørger, om evalueringen repræsenterer det, den har til hensigt at måle. Formål adskiller en benchmark beregnet til forskning fra en beregnet til overensstemmelse eller en anden anvendelse. Realisme spørger, om rammen er et legetøjsproblem, et simuleret eller laboratoriemiljø, eller det virkelige liv. Disse skel gør ikke en benchmark svagere. De gør dens påstand læsbar.

Dækning omfatter også de tilfælde, en evaluering udelukker. En tjeneste kan rapportere gennemsnitlig latenstid efter at have fjernet timeouts. En klassifikator kan rapportere nøjagtighed efter at have droppet tvetydige etiketter. Et genfindingssystem kan kun tælle forespørgsler med mindst ét relevant dokument. En billedpipeline kan springe korrupte filer over. Hver udelukkelse kan være forsvarlig. Resultatet skal sige, hvad der blev fjernet, og hvorfor. Ellers bliver nævneren stille og roligt en liste over tilfælde, der var bekvemme at færdiggøre.

Det er her, nævneren bliver politisk, selv før nogen bruger ordet politik. Den inkluderede population får fordelen ved at blive målt. Den ekskluderede population får en fortælling om et system, der måske ikke beskriver dem. Europæiske offentlige institutioner kender allerede dette fra officiel statistik. Eurostats adfærdskodeks for europæisk statistik fastsætter 16 principper og 84 indikatorer for det institutionelle miljø, processer og output. Dets ramme for kvalitetssikring leverer metoder og værktøjer, mens kvalitetsrapporter fortæller brugerne, hvordan data blev indsamlet og valideret. Budskabet til AI er ikke, at hver model skal blive et statistisk kontor. Det er, at et tal beregnet til offentlige beslutninger har brug for en synlig produktions- og kvalitetsfortælling.

Nøjagtighed er ikke én port

Præstationspåstande parrer ofte hastighed med et enkelt kvalitetstal og behandler derefter parret som komplet. Kvalitet er normalt en familie af spørgsmål. Opfylder outputtet opgavedefinitionen? Bevarer det påkrævede begrænsninger? Fejler det sikkert, når beviser mangler? Opfører det sig acceptabelt på tværs af den relevante population? Forbliver det inden for kvalitetsgrænsen, mens systemet er belastet? Et hurtigt svar, der fejler opgaven, er ikke en hurtigere løsning. Det er en anden arbejdsbyrde, der bærer det samme navneord.

MLPerfs struktur er lærerig, fordi dens præstationskørsler står ved siden af nøjagtighedsvalidering og modelspecifikke krav. Indsendelsesguiden fortæller deltagerne at identificere divisionen, systemtypen og scenariet, køre den tilsigtede benchmark, validere nøjagtigheden mod tærskler og derefter forberede en kontrolleret indsendelse. Benchmarksiden lister reference-nøjagtighed og latenstids- eller gennemløbsbetingelser pr. opgave. Adskillelsen er praktisk. Den forhindrer et system i at vinde præstationskolonnen ved stille og roligt at tabe opgaven.

Nøjagtighed har selv brug for en nævner. "98 procent nøjagtig" kan betyde en procentdel af poster, tokens, billeder, forespørgsler eller beslutninger. Det kan bruge mikro- eller makro-gennemsnit. Det kan tælle en afholdenhed som en fejl, som en sikker afvisning eller som et umålt resultat. Det kan sammenligne med etiketter oprettet af én eller flere gennemgåere. Et benchmarkkort bør angive enheden, etikettereglen, aggregeringen, konfidens eller variation og enhver tærskel, der gør en måling til en udgivelsesbeslutning.

Brug ikke et kvalitetstal som et dekorativt tilladelsesstempel. En model kan opfylde en offentliggjort tærskel og stadig være uegnet til en bestemt tjeneste, fordi opgaven, befolkningsgruppen eller skadesprofilen er forskellig. Omvendt kan en lavere samlet score være acceptabel for et udkastværktøj, der beholder et menneske som forfatter, mens den samme score er uacceptabel for en automatisk port. Kvalitet er et forhold mellem output, formål og konsekvens.

Tid er ikke ét tal

Latens præsenteres ofte, som om et system har én hastighed. Reelle systemer har en fordeling. Den første anmodning kan betale opstartomkostninger. En cache kan ændre senere anmodninger. Samtidige brugere kan konkurrere om hukommelse eller en databaseforbindelse. En lang input kan tage en anden vej end en kort. Gennemsnittet kan forbedres, mens halen bliver værre. Hvis halen er der, hvor en tjeneste overskrider sin deadline, er gennemsnittet en distraktion med en enhed.

En nyttig latensrapport siger, hvad der blev målt, og hvordan observationerne blev opsummeret. Den kan indeholde en median, øvre percentiler, timeoutrate og antallet af anmodninger. Den bør angive, om opvarmningsanmodninger blev udelukket, om gentagelser blev inkluderet, og om kø- eller netværkstid hører til den målte sti. Disse valg er ikke udskiftelige. En komponentbenchmark kan være værdifuld, men den må ikke beskrives som ende-til-ende-adfærd.

Gennemstrømning har en lignende fælde. En høj rate kan opnås ved at batchbehandle arbejde, øge samtidigheden eller lempe et kvalitetskrav. Det kan være præcis rigtigt for et offlinejob. Det kan være ubrugeligt for en interaktiv tjeneste, der skal svare på hver anmodning inden for en deadline. Benchmarken bør angive scenariet og driftspunktet og derefter forklare, hvad der ville ske, når efterspørgslen bevæger sig væk fra det. Der er ingen skam i et snævert driftspunkt. Der er skam i at lade, som om det er hele kortet.

Tid har også en menneskelig side. En tjeneste, der returnerer hurtigt, men skaber mere gennemgang, korrektion eller appelarbejde, kan være langsommere set fra institutionens synspunkt. En benchmark, der stopper uret før overdragelsen, kan få det målte system til at se hurtigt ud, mens den faktiske tjeneste akkumulerer en kø. Nævneren bør følge arbejdet, indtil det stillede spørgsmål er besvaret. Ellers måler stopuret en ø.

Hardware og software er en del af tælleren

”På en server” er ikke et reproducerbart miljø. Processorgeneration, instruktionssæt, accelerator, hukommelse, lagring, termisk tilstand, strømgrænse, operativsystem, driver, compiler, runtime, bibliotek og konfiguration kan alle ændre et resultat. Det samme kan en modelformat, kvantiseringsindstilling, batchstørrelse, kernevalg eller trådpolitik. Benchmarken behøver ikke at liste hver eneste kabel. Den skal identificere de dele, der kan ændre målingen.

MLPerf kalder det komplette målte setup for systemet under test og organiserer resultater efter systemtype og tilgængelighedskategori. Denne ordforråd er nyttig ud over MLPerf. Et system under test har en grænse. Grænsen siger, hvilken hardware og software der er inkluderet, hvilke tjenester der er eksterne, og hvilket arbejde der udelades. Et strømforbrug målt ved stikkontakten har en anden betydning end et tal, der kun tæller en accelerator. En latens målt inde i en kerne har en anden betydning end en, der inkluderer anmodningsplanlægning.

Versioner betyder noget, fordi en benchmark er en sammenligning på tværs af tilstande, ikke en tidløs egenskab ved et produktnavn. Registrer model- eller applikationsversionen, afhængighedsversioner, compilerflag, driver og firmware, hvor de påvirker resultatet. Registrer den konfiguration, der valgte en backend eller en præcision. Hvis en runtime vælger en anden kerne på en anden maskine, er det en del af resultatet, ikke en implementeringsdetalje, der skal ryddes op senere.

Hardware-oplysninger er ikke en invitation til at forvandle et blogindlæg til en reservedelskatalog. Det er en måde at forhindre falsk ækvivalens på. En køber behøver ikke at forholde sig til hver eneste instruktion, hvis påstanden handler om en komplet service. De skal derimod vide, om sammenligningen omfatter det samme arbejde, den samme nøjagtighed, den samme inputsti og et system, der faktisk kan anskaffes og drives i den påtænkte europæiske kontekst.

Baselines er løfter

En baseline er den sammenligning, der giver et resultat en retning. Uden den kan et tal beskrive et system, men ikke en forbedring. Basen skal besvare det samme spørgsmål under sammenlignelige forhold. Hvis den nye sti bruger en nyere compiler, en anden inputfordeling eller et andet kvalitetsmål, kan resultatet stadig være interessant, men sammenligningen er ikke længere ren. Sig, hvad der ændrede sig. Læseren kan derefter selv vurdere, om forskellen er nyttig.

Valget af baseline er en fortolkning. Sammenligner man med den eksisterende løsning, som brugerne faktisk kører, med en referenceimplementering, med en tidligere udgivelse eller med en teoretisk grænse, lærer man forskellige ting. Et nyt system kan være bedre end referencen og dårligere end den service, det erstatter. Det kan være hurtigere på en ren test og langsommere, når validering og lagring medregnes. Benchmarken bør navngive basen og forklare, hvorfor den besvarer det operationelle spørgsmål.

Parvise kørsler er ofte mere informative end en enkelt sejrsrunde. Hold arbejdsbyrden og evalueringsdefinitionen fast, ændr én væsentlig faktor, og registrér forskellen. Hvis flere faktorer ændrer sig samtidig, så beskriv sammenligningen som en samlet pakke i stedet for at tilskrive hele effekten én komponent. Det lyder indlysende, indtil en opgradering, en dataopdatering og en ny cache-politik ankommer i samme udgivelse. Diagrammet har så én pil og tre mulige årsager, hvilket er et lille mysterium, ingen havde budgetteret med.

En baseline har også en holdbarhedsdato. En datafeed, leverandør, model, politik eller hardwareplatform kan ændre sig. Sammenligningen forbliver gyldig for de versioner og den periode, der blev testet. Den bør ikke genbruges som en aktuel garanti uden at kontrollere aftalen. Det er her, versionshistorikken tjener sin berettigelse. Et overhalet resultat er ikke en fiasko. Det er en historisk påstand, hvis betingelser bør forblive synlige.

Usikkerhed er ikke en undskyldning

Enhver måling indeholder variation. Noget variation kommer fra systemet, noget fra arbejdsbyrden og noget fra måleprocessen. Gentagne kørsler kan afsløre den, men gentagelse alene forklarer ikke årsagen. En varm cache kan være stabil. En støjende nabo er måske ikke. Et lille evalueringssæt kan producere et bredt spektrum af plausible resultater. Et større sæt kan reducere stikprøvestøj, mens en skæv population forbliver urørt. Usikkerhed fortæller læseren, hvor langt resultatet sikkert kan række.

Rapportér usikkerhed i en form, der passer til påstanden. Det kan være et interval på tværs af gentagne kørsler, et konfidensinterval, en standardfejl, en fordeling af latenstid, en følsomhedsanalyse eller en liste over kendte begrænsninger. Tilføj ikke et konfidensinterval, fordi tabellen ser ensom ud. Angiv, hvad der blev gentaget, hvad der blev holdt fast, og hvad intervallet både dækker og ikke dækker. Statistisk sprog er ikke en besværgelse. Det er en kontrakt om variation.

Der findes en anden slags usikkerhed, som tal ikke kan fjerne: usikkerhed om, hvorvidt målingen repræsenterer den påtænkte service. Et resultat kan have minimal kør-til-kør-variation og dårlig dækning i den virkelige verden. En benchmark kan være perfekt reproducerbar i et laboratorium, mens den overser de sprog, inputformater, skiftmønstre eller fejlkonsekvenser, der findes i driften. Lav måleusikkerhed skaber ikke validitet. Det gør blot, at det forkerte spørgsmål besvares mere konsekvent.

Usikkerhed bør derfor stå ved siden af påstanden, ikke i et forbehold nederst på siden. Hvis en tærskel ligger tæt på den målte grænse, betyder det noget. Hvis et resultat ændrer sig væsentligt ved en anden input-sammensætning, betyder det noget. Hvis energigrænsen udelukker køling eller dataflytning, betyder det noget. Den ærlige sætning er måske mindre triumferende, men den giver en beslutningstager noget bedre end optimisme: et sted at placere forsigtigheden.

Reproduktion er en kæde, ikke en download-knap

Reproducerbarhed reduceres ofte til at offentliggøre kode. Kode betyder noget. Det er kun et led i kæden. En anden part har også brug for arbejdsbelastningen eller en lovlig beskrivelse af den, dataversionen, konfigurationen, miljøet, kommandoen eller testrammen, politikken for tilfældighedstilstand, reglen for forventet output, resultatfilen og metoden, der bruges til at afgøre, om kørslen stemmer overens. Hvis et led mangler, kan den anden part reproducere et lignende eksperiment snarere end det rapporterede.

Kæden bør skelne mellem eksakt afspilning og uafhængig replikering. Eksakt afspilning bruger det fangede artefakt, tilstanden, input, konfigurationen og eksekveringsstien til at kontrollere, om den samme kørsel kan rekonstrueres. Uafhængig replikering bruger et separat forberedt miljø til at teste, om resultatet overlever uden for den oprindelige maskine eller det oprindelige team. Begge er værdifulde. De besvarer forskellige spørgsmål. Et byte-identisk resultat på et fanget input beviser en stærk identitetspåstand om den pågældende kørsel. Det beviser ikke, at den levende verden forbliver uændret.

OECDs evalueringsramme gør denne skelnen lettere at se ved at behandle formål, realisme, dækning og pålidelighed som separate facetter. En evaluering kan være fremragende til regressionstest og dårlig til at estimere live-serviceydelse. Den kan være nyttig til forskning og uegnet til overensstemmelse. Reproduktion sletter ikke formålet. Den hjælper læseren med at verificere den påstand, som metoden faktisk understøtter.

For data, der ikke kan frigives, skal du offentliggøre grænsen og ruten. Beskriv populationen, stikprøveprocessen, labelmetoden, eksklusionsreglerne og valideringskontrollerne. Lever en sikker reproduktionspakke, når det er muligt, og forklar, hvad der forbliver beskyttet. "Dataene er fortrolige" er en legitim grænse, ikke en færdig metode. En læser bør stadig kunne forstå, hvad der blev målt, og hvorfor resultatet bør eller ikke bør generaliseres.

Reproduktion er ikke en knap, der hedder kør igen. Det er en kæde af identiteter, der lader et andet team udfordre påstanden.

Offentlige institutioner bør afvise demo-teater

Offentlige institutioner behøver ikke at afvise benchmarks. De er nødt til at afvise benchmarks, der ikke kan redegøre for deres kontrakt. En poleret demonstration kan hjælpe et udvalg med at forstå en mulighed. Den kan ikke erstatte dokumentation for den service, institutionen skal drive, de mennesker, den betjener, og de fejl, den skal udbedre. Forskellen er vigtig, fordi en demo er optimeret til et kort møde, mens en offentlig service vurderes på tværs af sæsoner, personaleskift, klager, vedligeholdelse og lovgivning.

Før køb skal leverandøren bede om at få defineret arbejdsbyrden i servicens sprog. Hvad kommer ind i systemet? Hvad måles? Hvad er udeladt? Hvilken kvalitetsregel skal gælde? Hvilken menneskelig rolle gennemgår et resultat? Hvordan opdages drift? Hvordan kan institutionen eksportere sin dokumentation? Hvad sker der, når modellen, kilden, leverandøren eller politikken ændres? Hvilken version sammenlignes der med? Hvad er rollback-stien? En leverandør kan besvare nogle spørgsmål med en kontrakt, nogle med en test og nogle med en ærlig grænse. Den blanding er sundere end et svar, der udelukkende består af adjektiver.

EU's AI-forordning formulerer pointen i juridisk sprog for højrisikosystemer. Artikel 15 kræver et passende niveau af nøjagtighed, robusthed og cybersikkerhed med konsekvent ydeevne på disse områder gennem hele livscyklussen. En benchmark kan ikke alene etablere hele den juridiske forpligtelse. Den kan understøtte en del af dokumentationen, hvis dens omfang, kvalitetsbetingelser og livscyklusposition er klare. At behandle én score som overholdelse ville være endnu en nævnerfejl. Loven navngiver resultatet; ingeniørarbejdet skal vise vejen.

Indkøb bør også spørge, hvem der ejer benchmarken efter tildelingen. En testkørsel forberedt af en leverandør kan være nyttig, men institutionen har brug for tilstrækkelige oplysninger til at overvåge systemet i sin egen kontekst. Den har brug for en baseline, der kan køres igen, når en version ændres, en gennemgangssti, når resultater flytter sig, og en registrering af de beslutninger, der træffes om acceptabel ydeevne. Ellers er den første benchmark en adgangseksamen, og produktionssystemet får lov til at dimittere uden yderligere spørgsmål.

Gør benchmark-kortet lille nok til at bruge

Lange metoder kan være nødvendige. De er ikke altid det første, en læser har brug for. Et benchmark-kort er et kompakt indeks til kontrakten. Det kan ligge ved siden af et resultat i en rapport, et evalueringsregister eller en indkøbsfil. Kortet skal angive spørgsmålet, arbejdsbyrden, omfanget, systemet, målingen, kvalitetskravet, baselinen, usikkerheden, reproduktionsvejen, ejeren og udløb eller ændringsudløser. Den detaljerede metode kan ligge bagved. Kortet forhindrer, at påstanden rejser alene.

Gode kort er selektive frem for overfyldte. De fremhæver de felter, der kan ændre fortolkningen, og linker derefter til dokumentationspakken. Et latenstidskort kan fremhæve inputstørrelse, samtidighed, percentil, opvarmning, version og timeout-regel. Et energikort kan fremhæve systemgrænsen, arbejdsbyrden, måleinstrumentet, varigheden og udeladt infrastruktur. Et nøjagtighedskort kan fremhæve population, mærkningsregel, aggregering, behandling af afholdenhed og fejlsværhedsgrad. Den fælles form er ikke en fast skabelon. Det er et løfte om, at læseren kan finde nævneren.

Kortet skal markere epistemisk status. Er værdien målt, estimeret, forventet, foreslået eller illustrativ? Er baselinen aktuel? Er evalueringssuiten forberedt, men endnu ikke kørt? Er resultater beskyttet, fordi testmaterialet indeholder personoplysninger? Disse etiketter forhindrer, at en metode forveksles med et resultat. De lader også en organisation offentliggøre fremskridt uden at fremstille succes. En forberedt test er nyttig information. Det er ikke dokumentation for, at systemet bestod den.

Til sidst skal kortet have en ejer og en ændringsregel. Et resultat uden en ejer forfalder til et slide. Et resultat uden en ændringsregel bliver hængende på væggen, efter at arbejdsbyrden er flyttet videre. Ejeren skal ikke forsvare tallet for evigt. De skal dog sige, hvornår kravet skal køres igen, trækkes tilbage eller indsnævres. Måling bliver en del af driften, når nogen har autoritet til at holde den ærlig.

To ærlige måder at publicere et resultat på

Der er to almindelige publiceringsformer. Den første er en streng sammenligning. Den fastlægger opgaven, dataene, kvalitetsreglen, systemafgrænsningen og baseline, så en læser kan sammenligne alternativer. Den anden er en eksplorativ måling. Den undersøger, hvad der sker, når et design, en arbejdsbyrde eller et miljø ændres, og den rapporterer observationerne med deres begrænsninger. Eksplorativt arbejde kan være værdifuldt, før en streng benchmark eksisterer. Det skal ikke låne sproget fra et overensstemmelsesresultat.

Streng sammenligning er krævende, fordi den gør forskelle synlige. Hvis et team ændrer modellen og hardwaren samtidig, kan det være umuligt at tilskrive resultatet. Hvis en ny arbejdsbyrde er mere realistisk, men ikke længere matcher baseline, skal kravet omformuleres som en ny måling. Hvis en optimering forbedrer hastigheden, mens den ændrer outputkvaliteten, skal begge sider rapporteres. Disciplinen er ikke at forhindre fremskridt. Den er at forhindre, at en fremskridtshistorie sletter den betingelse, der gjorde den mulig.

Eksplorative målinger kræver deres egen ærlighed. Sig, at stikprøven er lille, at miljøet er foreløbigt, at arbejdsbyrden er syntetisk, at resultatet ikke er blevet uafhængigt replikeret, eller at kvalitetskontrollen er ufuldstændig. Det er ikke svagheder, der skal skjules, indtil en poleret udgivelse. Det er den information, der hjælper en læser med at beslutte, hvad der skal ske derefter. En europæisk ingeniørkultur behøver ikke at lade, som om hver test er en endelig dom. Den skal holde op med at kalde et spørgsmål for besvaret, før testen er blevet læst.

Begge former har gavn af et resultatarkiv. Hold gamle definitioner, konfigurationer og udfald identificerbare. Registrer overhaling i stedet for at slette fortiden. En ændret benchmark kan være den rigtige benchmark for en ændret tjeneste, men den kan ikke bruges til at omskrive betydningen af det gamle resultat. Versionshistorik er nævnerens hukommelse.

Vores lille note

Hos Dweve beskriver vi Core med en eksekveringscelle og en determinismekontrakt. Den nyttige del af det ordforråd er ikke produktnavnet. Det er insisteren på, at en operation bærer sin numeriske repræsentation, backend, instruktionssæt, dispatch-politik og replay-position som en del af den sti, der evalueres. Det er den samme vane, som en benchmark har brug for: hold betingelserne knyttet til resultatet i stedet for at beskrive ydeevne, som om den svævede over systemet.

Dette er en lille designnote, ikke et krav om en ekstern implementering eller et målt resultat. Den bredere lektion afhænger ikke af Dweve. Uanset om systemet er en offentlig statistiktjeneste, en industriel controller, et sprogværktøj eller en forskningsprototype, så fortjener et tal tillid ved at navngive sit arbejde og sine begrænsninger. Vores egen dokumentation er blot ét sted, hvor vi forsøger at gøre den grænse eksplicit.

Nævneren er den del, der rejser

En benchmark-overskrift er let at kopiere. Nævneren er sværere at bære, hvilket er grunden til, at den ofte efterlades. En køber kopierer et gennemløbstal ind i en business case. En regulator ser en nøjagtighedsscore i en dossier. En ingeniør sammenligner to diagrammer fra forskellige arbejdsbyrder. En journalist gentager en procentdel uden populationen. Hver læser modtager et tal, der har mistet den kontrakt, der gjorde det meningsfuldt.

Reparationen er ikke kompliceret, selvom den kræver disciplin. Navngiv spørgsmålet. Definér arbejdet. Angiv omfang og undtagelser. Identificér systemet og versionerne. Vælg en måling, der matcher tjenesten. Behold en baseline. Mål variationen. Offentliggør metoden og dokumentationen. Markér, hvad der stadig er ukendt. Giv påstanden en ejer og en grund til at blive kørt igen. Hvis resultatet ikke kan understøtte en bred udtalelse, så gør udtalelsen snævrere.

Sådan kan Europa modstå demo-teater uden at blive allergisk over for ambitioner. En offentlig institution kan købe ny kapacitet og stadig kræve en benchmark, der respekterer tjenesten. Et forskerhold kan offentliggøre et spændende resultat og stadig angive den arbejdsbyrde, der producerede det. En leverandør kan vise en hurtig vej og stadig sige, hvor vejen stopper. Ærligt omfang er ikke en bremse på innovation. Det er vejoverfladen, der lader alle andre køre.

Benchmarken er en kontrakt med en nævner, fordi nævneren fortæller os, hvad der faktisk blev gjort. Hold den ved siden af tallet. Resultatet bliver mindre magisk, mere sammenligneligt og meget mere brugbart. Det er en fair byttehandel. Systemer, som folk skal kunne stole på, fortjener tal, der kan overleve at blive læst langsomt.

Når en måling rejser mellem verdener

Benchmark-tal forlader ofte det team, der målte dem, og indgår i et andet beslutningssystem. En forsker offentliggør en tabel. Et produktteam gør én række til et mål. Indkøb gør målet til en kontrakt. Drift gør kontrakten til en forventning om serviceniveau. Hver flytning ændrer, hvad tallet bliver bedt om at gøre. Den oprindelige nævner kan stadig være til stede i artiklen eller repositoryet, men den er blevet socialt fjern fra beslutningen. En måling har brug for en oversættelsesnote, hver gang den krydser den grænse.

Oversættelsesnoten kan være enkel. Dette resultat handler om komponent-gennemstrømning, ikke afsluttede sager. Denne præcisionsværdi bruger et fastsat labelsæt, ikke live-resultater. Denne energiværdi ekskluderer datacenterets kølingsgrænse. Denne baseline er en referenceimplementering, ikke den nuværende tjeneste. Disse sætninger forhindrer en nyttig måling i at blive et vildledende løfte. De gør også uenighed lettere. En læser kan udfordre grænsen i stedet for at diskutere, om tallet føles imponerende.

Forskellige teams kan bevidst vælge forskellige nævnere. Et platformsteam kan bekymre sig om arbejde pr. joule. En tjenestejer kan bekymre sig om afsluttede beslutninger pr. bemandet time. En offentlig myndighed kan bekymre sig om korrekte, forklarlige resultater for en defineret befolkning og svartid. Disse er ikke konkurrerende sandheder, hvis hver enkelt er navngivet. Problemer begynder, når den nemmeste nævner får lov til at stå i stedet for missionen. Den hurtigste kerne gør ikke automatisk den bedste tjeneste, på samme måde som det største testsæt ikke automatisk gør det mest relevante.

Før en benchmark genbruges, så spørg, hvad der har flyttet sig: arbejdsbyrden, ejeren, konsekvensen eller tidshorisonten. Hvis nogen af dem har flyttet sig, så kør fortolkningen igen, selv når det underliggende tal er uændret. Måling er ikke en relikvie, der skal bæres mellem rum. Det er et forhold, der skal fornyes, når rummet ændrer sig.

Et resultat bør vide, hvornår det udløber

Resultater har en brugbar levetid. En benchmark knyttet til en modelversion, et kilde-snapshot eller en hardwarekonfiguration bliver historisk, når disse betingelser ændrer sig. Det gør ikke det gamle resultat falsk. Det ændrer det spørgsmål, det kan besvare. Rapporten bør sige, hvilken begivenhed der gør påstanden forældet: en ny model, en ændret compiler, en ny datafordeling, en revideret labelregel, en hardwareudskiftning, en politikændring eller et observeret driftsignal. En udløbsregel er et lille stykke institutionel hukommelse.

Uden en udløbsregel hober tal sig op som frakker på en stol. Hvert enkelt tal er teknisk set stadig der, og ingen ved, hvilket der hører til i dag. Et resultatregister kan bevare hele historikken, mens det markerer den aktuelle sammenligning, den erstattede definition og årsagen til at køre igen. Selve det at køre igen bliver så almindelig vedligeholdelse snarere end en krisereaktion. Det er især vigtigt for offentlige tjenester, hvor et resultat kan overleve det team, der producerede det.

Udløb beskytter også ærlig fremgang. Hvis en ny arbejdsbyrde afslører, at en tidligere benchmark var for snæver, kan organisationen offentliggøre ændringen, bevare den gamle metode og forklare den nye afgrænsning. Den behøver ikke at forsvare et forældet tal eller lade som om, at det gamle tal aldrig har eksisteret. En benchmark, der kan indsnævres, erstattes og forstås, er mere nyttig end en, der skal forblive imponerende for evigt.

En benchmark er en kontrakt med en nævner