Ett riktmärke är ett kontrakt med en nämnare

Prestandapåståenden blir användbara när arbetsbelastning, omfattning, hårdvara, kvalitetsvillkor, baslinje och osäkerhet hålls kopplade till siffran.

Ett riktmärke är ett kontrakt med en nämnare

The number that forgets its denominator

A benchmark result can be measured correctly and still answer the wrong question. The usual culprit is not a faulty timer or a dishonest engineer. It is the denominator that disappeared between the test harness and the presentation slide. “Twice as fast” sounds like a comparison, but it does not say twice as fast at what work, on which machine, with which software, under which quality condition, against which baseline, or for which users. Remove those conditions and a performance number becomes a polished fragment. It may remain numerically true. It no longer tells a buyer or an operator what they can expect.

The denominator is the work against which the result is expressed. For throughput, it is the work completed and the time over which completion is counted. For latency, it is the request definition, the path included, and the population of observations. For accuracy, it is the labelled set, the label rule, and the unit being judged. For energy, it is the boundary of the measured system and the work delivered inside that boundary. For cost, it is the cost period, the included resources, and the volume of useful work. A benchmark is honest when its numerator and denominator travel together.

That is why a benchmark is best treated as a contract. The contract names the question, the workload, the scope, the hardware and software, the metric, the baseline, the uncertainty and the method by which another party could check the result. A contract can be narrow. It can be exploratory. It can be useful only for one deployment. What it cannot be is an impressive number whose conditions are left for the reader to guess. Guessing is a poor way to allocate public money, and an even poorer way to design a service that somebody else must keep alive.

The European habit of writing down definitions is occasionally mocked as paperwork. In measurement work, definitions are the part that stops paperwork from becoming folklore. The benchmark table is not an administrative appendix to the result. It is the result’s identity card.

Read the unit before the headline

Start with the unit, but do not stop there. Requests per second, tokens per second, milliseconds, joules per query, euros per thousand records and percentage points all tell you something. None tells you what the system was asked to do. A result of 100 requests per second can describe tiny cached requests or large uncached requests that include retrieval, validation and a human hand-off. A latency of 20 milliseconds can cover a single kernel or an entire decision path. The unit is a door. The workload is the room behind it.

Suppose a procurement slide says that a new service is 40 per cent faster than the existing one. The sentence is not yet evidence. It needs at least the operation being timed, the input size and distribution, the work excluded from the clock, the concurrency, the warm-up state, the software versions, the hardware, and the baseline configuration. It also needs the quality condition. If the faster path returns fewer valid results, drops long inputs or skips an expensive verification step, the numerator has been made smaller by changing the work.

This is not a request for an enormous table before anyone may speak. It is a request to identify the few fields that change the meaning of the claim. A small parser benchmark may need record shape, input source, validation policy, compiler and processor. An inference benchmark may need model, precision, batch, scenario, quality target and power boundary. A public-sector queue may need the case definition, service clock, routing rule and escalation path. The fields differ. The obligation to name them does not.

Här finns en nyttig disciplin: formulera resultatet som en mening som skulle hålla för en andra läsare. ”Under denna arbetsbelastning och detta kvalitetskrav, på detta system och denna version, var det uppmätta värdet detta, med denna variation.” Om meningen inte kan fullbordas utan ord som typisk, bäst, produktionsliknande eller representativ, är metoden inte färdig. Dessa ord kan vara giltiga, men de kräver en operationell definition, inte en varm ton.

Ett benchmarkkort är inte dekoration runt en siffra. Det är den minsta användbara formen av siffrans kontrakt.

Scope är en del av resultatet

Scope besvarar en enkel fråga: vad täcker detta resultat, och vad lämnas utanför ramen? Vid utvärdering av maskininlärning inkluderar scope uppgiften, datasetet, uppdelningen, språket, indatalängden, driftsscenariot och de tillåtna implementeringsvalen. I en mjukvarutjänst inkluderar det rutten, datalagren, nätverket, cachen och det arbete som ett nedströms team utför efter att den uppmätta slutpunkten returnerar. Ett resultat uppmätt på ett lager ska inte tyst bli ett löfte om hela tjänsten.

MLCommons gör detta synligt i sin MLPerf Inference-dokumentation. Inlämningsguiden skiljer mellan datacenter- och edge-systemtyper, listar scenarier som offline, server, interaktiv, enkelström och flerström, och skiljer en sluten division från en öppen division. Den slutna divisionen är avsedd för en jämförelse mellan äpplen och äpplen med samma modell och referensuppsättning. Den öppna divisionen tillåter val som omskolning eller modellersättning. Ingen av dem är den universellt korrekta divisionen. De besvarar olika frågor. En rubrik som blandar dem är inte en bred vy. Det är ett kategorifel med utmärkt typografi.

Samma dokumentation visar varför ett benchmark behöver en explicit kvalitetssida. En listad ResNet50-post namnger ImageNet-2012-valideringssetet, dess dataset- och frågeprovlistestorlekar, en referensnoggrannhet och en serverlatensbegränsning. För den listade ResNet50-posten anger sidan ett valideringsset på 50 000 bilder, en frågeprovlista på 1 024, en referensnoggrannhet på 76,46 procent och en serverlatensbegränsning på 15 ms. Dessa fält är inte trivialiteter för människor som tycker om att läsa regler. De förklarar vad den rapporterade hastigheten tilläts betyda. Ändra datasetet, scenariot eller kvalitetskravet så har jämförelsen ändrats, även om modellnamnet ser bekant ut.

En europeisk köpare bör vara misstänksam mot scope som antyds av en produktetikett. ”AI-plattform”, ”accelerator” och ”enterprise-grade” definierar inte arbetet. Ett system som är utmärkt på en avgränsad operation kan vara precis vad en tjänst behöver. Ett system som hävdar att det täcker allt kan ha mätt nästan ingenting som liknar tjänsten. Snäv sanning är hälsosammare än universell dimma.

Coverage förändrar innebörden

Coverage är inte en fotnot om huruvida testmängden var stor. Den beskriver vilkas fall och vilka situationer som ingår i mätningen. En benchmark kan täcka många exempel från en enda smal fördelning och ändå säga lite om de gränsfall som spelar roll i drift. Omvänt kan en liten, omsorgsfullt vald mängd blotta en viktig felfunktion utan att stödja ett allmänt prestandapåstående. Valet är ett designbeslut. Det måste anges som sådant.

OECD:s ramverk för att karaktärisera AI-utvärderingsinstrument är användbart eftersom det vägrar att reducera en utvärdering till ett enda resultat. Det föreslår 18 aspekter, inklusive coverage, syfte, realism, validitet, reliabilitet, transparens och villkoren under vilka resultaten kan tolkas. Coverage ställer frågan om utvärderingen representerar det den avser att mäta. Syfte skiljer en benchmark avsedd för forskning från en avsedd för överensstämmelse eller något annat bruk. Realism ställer frågan om miljön är ett leksaksproblem, en simulerad eller laboratoriemiljö, eller verkligheten. Dessa distinktioner gör inte en benchmark svagare. De gör dess anspråk läsbart.

Coverage omfattar också de fall som en utvärdering utesluter. En tjänst kan rapportera genomsnittlig latens efter att ha tagit bort timeouts. En klassificerare kan rapportera noggrannhet efter att ha tagit bort tvetydiga etiketter. Ett hämtningssystem kan räkna endast frågor med minst ett relevant dokument. En bildpipeline kan hoppa över korrupta filer. Varje uteslutning kan vara försvarbar. Resultatet måste ange vad som togs bort och varför. Annars blir nämnaren tyst en lista över fall som var bekväma att slutföra.

Det är här nämnaren blir politisk, redan innan någon använder ordet politik. Den inkluderade populationen får fördelen av att bli mätt. Den exkluderade populationen får en berättelse om ett system som kanske inte beskriver dem. Europeiska offentliga institutioner känner redan till detta från officiell statistik. Eurostats uppförandekod för europeisk statistik fastställer 16 principer och 84 indikatorer för den institutionella miljön, processerna och resultaten. Dess kvalitetssäkringsramverk tillhandahåller metoder och verktyg, medan kvalitetsrapporter berättar för användarna hur data samlades in och validerades. Budskapet för AI är inte att varje modell måste bli ett statistikbyrå. Det är att en siffra avsedd för offentliga beslut behöver en synlig produktions- och kvalitetsberättelse.

Noggrannhet är inte en enda grind

Prestandapåståenden parar ofta hastighet med ett enda kvalitetstal och behandlar sedan paret som komplett. Kvalitet är vanligtvis en familj av frågor. Uppfyller resultatet uppgiftsdefinitionen? Bevarar det nödvändiga begränsningar? Misslyckas det säkert när bevis saknas? Beter det sig acceptabelt över den relevanta populationen? Håller det sig inom kvalitetsgränsen medan systemet är belastat? Ett snabbt svar som misslyckas med uppgiften är inte en snabbare lösning. Det är en annan arbetsbelastning som bär samma substantiv.

MLPerf:s struktur är lärorik eftersom dess prestandakörningar ligger bredvid noggrannhetsvalidering och modellspecifika krav. Inlämningsguiden säger till deltagarna att identifiera division, systemtyp och scenario, köra den avsedda benchmarken, validera noggrannhet mot tröskelvärden och sedan förbereda en kontrollerad inlämning. Benchmarksidan listar referensnoggrannhet och latens- eller genomströmningsvillkor per uppgift. Separationen är praktisk. Den hindrar ett system från att vinna prestandakolumnen genom att tyst förlora uppgiften.

Noggrannhet behöver själv en nämnare. "Nittioåtta procent noggrannhet" kan betyda en andel av poster, token, bilder, förfrågningar eller beslut. Det kan använda mikro- eller makrosammanvägning. Det kan räkna en avhållning som ett fel, som en säker vägran eller som ett omätt utfall. Det kan jämföra med etiketter skapade av en granskare eller flera. Ett benchmarkkort bör namnge enheten, etikettregeln, aggregeringen, konfidens eller variation, och eventuellt tröskelvärde som förvandlar en mätning till ett releasebeslut.

Använd inte ett kvalitetsnummer som ett dekorativt godkännandestämpel. En modell kan nå ett publicerat tröskelvärde och ändå vara olämplig för en viss tjänst, eftersom uppgiften, populationen eller skadeprofilen skiljer sig. Omvänt kan ett lägre sammanlagt resultat vara acceptabelt för ett utkastverktyg som behåller en människa som författare, medan samma resultat är oacceptabelt för en automatisk grind. Kvalitet är en relation mellan utdata, syfte och konsekvens.

Tid är inte ett enda tal

Latens presenteras ofta som om ett system har en enda hastighet. Verkliga system har en fördelning. Den första begäran kan kosta uppstartstid. En cache kan förändra senare begäranden. Samtidiga användare kan konkurrera om minne eller en databasanslutning. En lång indata kan ta en annan väg än en kort. Genomsnittet kan förbättras medan svansen blir värre. Om svansen är där en tjänst missar sin deadline, är genomsnittet en distraktion med en enhet.

En användbar latensrapport anger vad som tidsattes och hur observationerna sammanfattades. Den kan inkludera en median, övre percentiler, timeoutfrekvens och antalet begäranden. Den bör ange om uppvärmningsbegäranden exkluderades, om återförsök inkluderades, och om kötid eller nätverkstid tillhör den uppmätta vägen. Dessa val är inte utbytbara. Ett komponentriktmärke kan vara värdefullt, men det får inte beskrivas som hela förloppets beteende.

Genomströmning har en liknande fälla. En hög takt kan uppnås genom att batcha arbete, öka konkurrensen eller sänka ett kvalitetskrav. Det kan vara precis rätt för ett offlinejobb. Det kan vara värdelöst för en interaktiv tjänst som måste svara på varje begäran inom en deadline. Riktmärket bör ange scenariot och driftspunkten, och sedan förklara vad som skulle hända när efterfrågan rör sig bort från den. Det finns ingen skam i en smal driftspunkt. Det finns skam i att låtsas att den är hela kartan.

Tid har också en mänsklig sida. En tjänst som svarar snabbt men skapar mer gransknings-, korrigerings- eller överklagandearbete kan vara långsammare ur institutionens synvinkel. Ett riktmärke som stoppar klockan före överlämning kan få det uppmätta systemet att se snabbt ut medan den faktiska tjänsten ackumulerar en kö. Nämnaren bör följa arbetet tills den fråga som ställs är besvarad. Annars mäter stoppuret en ö.

Hårdvara och mjukvara är en del av täljaren

”På en server” är inte en reproducerbar miljö. Processorgeneration, instruktionsuppsättning, accelerator, minne, lagring, termiskt tillstånd, effektgräns, operativsystem, drivrutin, kompilator, runtime, bibliotek och konfiguration kan alla ändra ett resultat. Likaså kan ett modellformat, kvantiseringsinställning, batchstorlek, kärnval eller trådpolicy. Riktmärket behöver inte lista varje kabel. Det behöver identifiera de delar som kan ändra mätningen.

MLPerf kallar den fullständiga uppmätta konfigurationen för systemet under test och organiserar resultat efter systemtyp och tillgänglighetskategori. Den vokabulären är användbar bortom MLPerf. Ett system under test har en gräns. Gränsen anger vilken hårdvara och mjukvara som ingår, vilka tjänster som är externa, och vilket arbete som utelämnas. En effektsiffra mätt vid väggen har en annan betydelse än en siffra som bara räknar en accelerator. En latens mätt inuti en kärna har en annan betydelse än en som inkluderar schemaläggning av begäranden.

Versioner spelar roll eftersom ett riktmärke är en jämförelse mellan tillstånd, inte en tidlös egenskap hos ett produktnamn. Registrera modell- eller applikationsversionen, beroendeversioner, kompilatorflaggor, drivrutin och firmware där de påverkar resultatet. Registrera konfigurationen som valde en backend eller en precision. Om en runtime väljer en annan kärna på en annan maskin, är det en del av resultatet, inte en implementeringsdetalj som ska städas undan senare.

Att redovisa hårdvara är inte en inbjudan att förvandla ett blogginlägg till en komponentkatalog. Det är ett sätt att förhindra falska jämförelser. En köpare behöver inte bry sig om varje instruktion om påståendet gäller en komplett tjänst. Däremot behöver de veta om jämförelsen omfattar samma arbete, samma noggrannhet, samma inmatningsväg och ett system som faktiskt kan anskaffas och drivas i den avsedda europeiska miljön.

Baslinjer är löften

En baslinje är den jämförelse som ger ett resultat dess riktning. Utan den kan en siffra beskriva ett system men inte en förbättring. Baslinjen måste besvara samma fråga under jämförbara förhållanden. Om den nya vägen använder en nyare kompilator, en annan indatafördelning eller ett annat kvalitetsmål kan resultatet fortfarande vara intressant, men jämförelsen är inte längre ren. Säg vad som ändrades. Läsaren kan då avgöra om skillnaden är användbar.

Valet av baslinje är en tolkningsfråga. Jämför med den befintliga lösning som användarna faktiskt kör, med en referensimplementation, med en tidigare version eller med en teoretisk gräns, så lär du dig olika saker. Ett nytt system kan vara bättre än referensen och sämre än den tjänst det ersätter. Det kan vara snabbare i ett rent test och långsammare när validering och lagring räknas in. Riktmärket bör namnge baslinjen och förklara varför den besvarar den operativa frågan.

Parvisa körningar är ofta mer informativa än en enda segermarsch. Håll arbetsbelastningen och utvärderingsdefinitionen fasta, ändra en materiell faktor och notera skillnaden. Om flera faktorer ändras samtidigt, beskriv jämförelsen som ett paket i stället för att tillskriva hela effekten en enda komponent. Detta låter självklart tills en uppgradering, en datauppdatering och en ny cachepolicy anländer i samma version. Diagrammet får då en pil och tre möjliga orsaker, vilket är ett litet mysterium ingen budgeterat för.

En baslinje behöver också en hållbarhetstid. En datafeed, leverantör, modell, policy eller hårdvaruplattform kan förändras. Jämförelsen förblir giltig för de versioner och den period som testats. Den bör inte återanvändas som en aktuell garanti utan att avtalet kontrolleras. Det är här versionshistoriken gör nytta. Ett ersatt resultat är inte ett misslyckande. Det är ett historiskt påstående vars villkor bör förbli synliga.

Osäkerhet är inte en ursäkt

Varje mätning innehåller variation. En del variation kommer från systemet, en del från arbetsbelastningen och en del från mätprocessen. Upprepade körningar kan avslöja den, men upprepning i sig förklarar inte orsaken. En varm cache kan vara stabil. En stökig granne kanske inte är det. En liten utvärderingsuppsättning kan ge ett brett spektrum av rimliga utfall. En större uppsättning kan minska samplingbruset samtidigt som en snedvriden population lämnas orörd. Osäkerhet talar om för läsaren hur långt resultatet säkert kan färdas.

Rapportera osäkerhet i en form som passar påståendet. Det kan vara ett intervall över upprepade körningar, ett konfidensintervall, ett standardfel, en latensfördelning, en känslighetsanalys eller en lista över kända begränsningar. Lägg inte till ett konfidensintervall för att tabellen ser ensam ut. Ange vad som upprepades, vad som hölls fast och vad intervallet både representerar och inte representerar. Statistiskt språk är ingen besvärjelse. Det är ett avtal om variation.

Det finns en andra typ av osäkerhet som siffror inte kan ta bort: osäkerhet om huruvida mätningen representerar den avsedda tjänsten. Ett resultat kan ha mycket liten variation mellan körningar och dålig täckning i verkligheten. Ett riktmärke kan vara perfekt reproducerbart inom ett laboratorium samtidigt som det missar språken, inmatningsformaten, skiftmönstren eller konsekvenserna av fel i driftsättningen. Lågt mätbrus skapar inte validitet. Det gör bara att fel fråga besvaras mer konsekvent.

Osäkerhet bör därför stå i anslutning till påståendet, inte i en disclaimer längst ner. Om ett tröskelvärde ligger nära den uppmätta gränsen, spelar det roll. Om ett resultat förändras påtagligt vid en annan sammansättning av indata, spelar det roll. Om energigränsen exkluderar kylning eller dataöverföring, spelar det roll. Den ärliga meningen kanske är mindre triumferande, men den ger en beslutsfattare något bättre än optimism: en plats för försiktighet.

Reproduktion är en kedja, inte en nedladdningsknapp

Reproducerbarhet reduceras ofta till att publicera kod. Kod spelar roll. Men den är bara en länk i kedjan. En andra part behöver också arbetsbelastningen eller en laglig beskrivning av den, dataversionen, konfigurationen, miljön, kommandot eller testmiljön, policy för slumpmässigt tillstånd, regeln för förväntat utfall, resultatfilen och metoden som används för att avgöra om körningen stämmer överens. Om en länk saknas kan den andra parten reproducera ett liknande experiment snarare än det rapporterade.

Kedjan bör skilja mellan exakt återspelning och oberoende replikering. Exakt återspelning använder den fångade artefakten, tillståndet, indata, konfigurationen och exekveringsvägen för att kontrollera om samma körning kan rekonstrueras. Oberoende replikering använder en separat förberedd miljö för att testa om resultatet överlever utanför den ursprungliga maskinen eller teamet. Båda är värdefulla. De svarar på olika frågor. Ett byte-identiskt resultat på fångad indata bevisar ett starkt identitetsanspråk för just den körningen. Det bevisar inte att den levande världen förblir oförändrad.

OECD:s utvärderingsramverk gör denna distinktion lättare att se genom att behandla syfte, realism, täckning och tillförlitlighet som separata aspekter. En utvärdering kan vara utmärkt för regressionstestning och dålig för att uppskatta prestanda i en live-tjänst. Den kan vara användbar för forskning och olämplig för överensstämmelse. Reproduktion raderar inte syftet. Den hjälper läsaren att verifiera påståendet som metoden faktiskt stöder.

För data som inte kan släppas, publicera gränsen och vägen. Beskriv populationen, urvalsprocessen, märkningsmetoden, exkluderingsreglerna och valideringskontrollerna. Tillhandahåll ett säkert reproduktionspaket när det är möjligt, och förklara vad som förblir skyddat. ”Uppgifterna är konfidentiella” är en legitim gräns, inte en fullständig metod. En läsare bör fortfarande kunna förstå vad som mättes och varför resultatet bör eller inte bör generaliseras.

Reproduktion är inte en knapp märkt kör igen. Det är en kedja av identiteter som låter ett annat team utmana påståendet.

Offentliga institutioner bör vägra demoteater

Offentliga institutioner behöver inte avvisa riktmärken. De behöver avvisa riktmärken som inte kan redovisa sitt kontrakt. En polerad demonstration kan hjälpa en nämnd att förstå en möjlighet. Den kan inte ersätta bevis för den tjänst institutionen måste driva, de människor den betjänar och de fel den måste åtgärda. Skillnaden är viktig eftersom en demo är optimerad för ett kort möte medan en offentlig tjänst bedöms över årstider, personalbyten, överklaganden, underhåll och lagstiftning.

Fråga leverantören innan köp att definiera arbetsbelastningen på tjänstens språk. Vad kommer in i systemet? Vad mäts? Vad exkluderas? Vilken kvalitetsregel måste hållas? Vilken mänsklig roll granskar ett resultat? Hur upptäcks drift? Hur kan institutionen exportera sina bevis? Vad händer när modellen, källan, leverantören eller policyn ändras? Vilken version jämförs mot? Vad är återställningsvägen? En leverantör kan besvara vissa frågor med ett kontrakt, vissa med ett test och vissa med en ärlig gräns. Den blandningen är sundare än ett svar som helt består av adjektiv.

EU:s AI-förordning gör poängen i juridisk språkdräkt för högrisksystem. Artikel 15 kräver en lämplig nivå av noggrannhet, robusthet och cybersäkerhet, med konsekvent prestanda i dessa avseenden under hela livscykeln. Ett riktmärke kan inte fastställa hela den rättsliga skyldigheten på egen hand. Det kan stödja en del av bevisningen om dess omfattning, kvalitetsvillkor och livscykelposition är tydliga. Att behandla ett enda resultat som efterlevnad skulle vara ett annat nämnarfel. Lagen namnger resultatet; ingenjörskonsten måste visa vägen.

Upphandling bör också fråga vem som äger riktmärket efter tilldelningen. En testkörning som en leverantör förberett kan vara användbar, men institutionen behöver tillräckligt med information för att övervaka systemet i sin egen kontext. Den behöver en baslinje som kan köras om när en version ändras, en granskningsväg när resultat rör sig och en registrering av de beslut som fattats om acceptabel prestanda. Annars är det första riktmärket en inträdesprov och produktionssystemet får ta examen utan ytterligare frågor.

Gör riktmärkeskortet litet nog att använda

Långa metoder kan vara nödvändiga. De är inte alltid det första en läsare behöver. Ett riktmärkeskort är ett kompakt index till kontraktet. Det kan sitta bredvid ett resultat i en rapport, ett utvärderingsregister eller en upphandlingsfil. Kortet ska ange frågan, arbetsbelastningen, omfattningen, systemet, måttet, kvalitetskravet, baslinjen, osäkerheten, reproduktionsvägen, ägaren och utgångsdatum eller ändringsutlösare. Den detaljerade metoden kan ligga bakom. Kortet hindrar påståendet från att färdas ensamt.

Bra kort är selektiva snarare än överfulla. De lyfter fram de fält som kan ändra tolkningen och länkar sedan till bevispaketet. Ett latenskort kan lyfta fram indatastorlek, samtidighet, percentil, uppvärmning, version och timeout-regel. Ett energikort kan lyfta fram systemgränsen, arbetsbelastningen, mätinstrumentet, varaktigheten och exkluderad infrastruktur. Ett noggrannhetskort kan lyfta fram populationen, etikettregeln, aggregeringen, behandlingen av avstående och allvaretsgraden av fel. Den gemensamma formen är inte en fast mall. Det är ett löfte om att läsaren kan hitta nämnaren.

Kortet ska markera epistemisk status. Är värdet uppmätt, uppskattat, förväntat, föreslaget eller illustrativt? Är baslinjen aktuell? Är utvärderingssviten förberedd men ännu inte körbar? Är resultaten skyddade eftersom testmaterialet innehåller personuppgifter? Dessa etiketter hindrar en metod från att misstas för ett resultat. De låter också en organisation publicera framsteg utan att tillverka framgång. Ett förberett test är användbar information. Det är inte bevis för att systemet klarade det.

Ge kortet slutligen en ägare och en ändringsregel. Ett resultat utan ägare förfaller till en bild. Ett resultat utan ändringsregel blir kvar på väggen efter att arbetsbelastningen har flyttats. Ägaren behöver inte försvara siffran för alltid. Däremot måste de ange när påståendet ska köras om, dras tillbaka eller begränsas. Mätning blir en del av verksamheten när någon har befogenhet att hålla den ärlig.

Två ärliga sätt att publicera ett resultat

Det finns två vanliga publiceringssätt. Det första är en strikt jämförelse. Den fastställer uppgiften, datan, kvalitetsregeln, systemgränsen och baslinjen så att en läsare kan jämföra alternativ. Det andra är en utforskande mätning. Den undersöker vad som händer när en design, arbetsbelastning eller miljö förändras, och den rapporterar observationerna med sina begränsningar. Utforskande arbete kan vara värdefullt innan ett strikt riktmärke finns. Det bör inte låna språket från ett överensstämmelseresultat.

Strikta jämförelser är krävande eftersom de gör skillnader synliga. Om ett team ändrar modellen och hårdvaran samtidigt kan det vara omöjligt att härleda resultatet. Om en ny arbetsbelastning är mer realistisk men inte längre matchar baslinjen bör påståendet omformuleras som en ny mätning. Om en optimering förbättrar hastigheten samtidigt som den ändrar utdatakvaliteten ska båda sidorna rapporteras. Disciplinen handlar inte om att hindra framsteg. Den handlar om att förhindra att en framstegsberättelse raderar de villkor som gjorde den möjlig.

Utforskande mätningar kräver sin egen ärlighet. Säg att urvalet är litet, att miljön är provisorisk, att arbetsbelastningen är syntetisk, att resultatet inte har replikerats oberoende eller att kvalitetskontrollen är ofullständig. Detta är inte svagheter att dölja tills en polerad release. Det är information som hjälper en läsare att besluta vad som ska göras härnäst. En europeisk ingenjörskultur behöver inte låtsas att varje test är en slutgiltig dom. Den behöver sluta kalla en fråga besvarad innan testet har lästs.

Båda sätten gynnas av ett resultatarkiv. Håll gamla definitioner, konfigurationer och resultat identifierbara. Dokumentera ersättningar i stället för att radera det förflutna. Ett ändrat riktmärke kan vara rätt riktmärke för en ändrad tjänst, men det kan inte användas för att skriva om innebörden av det gamla resultatet. Versionshistoriken är nämnarens minne.

Vår lilla notis

På Dweve beskriver vi Core med en exekveringscell och ett determinismkontrakt. Den användbara delen av det ordförrådet är inte produktnamnet. Det är insisterandet på att en operation bär med sig sin numeriska representation, backend, instruktionsuppsättning, dispatchningspolicy och reprisposition som en del av den sökväg som utvärderas. Det är samma vana som ett riktmärke behöver: håll villkoren knutna till resultatet i stället för att beskriva prestanda som om den svävade ovanför systemet.

Detta är en liten designnotis, inte ett påstående om en extern driftsättning eller ett uppmätt resultat. Den bredare lärdomen är inte beroende av Dweve. Oavsett om systemet är en offentlig statistiktjänst, en industriell styrenhet, ett språkverktyg eller en forskningsprototyp förtjänar en siffra förtroende genom att namnge sitt arbete och sina begränsningar. Vår egen dokumentation är helt enkelt en plats där vi försöker göra den gränsen tydlig.

Nämnaren är den del som färdas

En rubriksiffra i ett riktmärke är lätt att kopiera. Nämnaren är svårare att bära med sig, vilket är varför den ofta lämnas kvar. En köpare kopierar en genomströmningssiffra till en affärsplan. En tillsynsmyndighet ser en noggrannhetspoäng i en dossier. En ingenjör jämför två diagram från olika arbetsbelastningar. En journalist upprepar en procentsats utan populationen. Varje läsare får en siffra som har förlorat det kontrakt som gjorde den meningsfull.

Reparationen är inte komplicerad, även om den kräver disciplin. Namnge frågan. Definiera arbetet. Ange omfattning och undantag. Identifiera systemet och versionerna. Välj ett mätetal som matchar tjänsten. Håll en baslinje. Mät variation. Publicera metoden och bevisen. Markera det som fortfarande är okänt. Ge påståendet en ägare och en anledning att köras igen. Om resultatet inte kan stödja ett brett påstående, gör påståendet snävare.

Så här kan Europa stå emot demoteater utan att bli allergiskt mot ambition. En offentlig institution kan köpa ny kapacitet och ändå kräva ett riktmärke som respekterar tjänsten. Ett forskningsteam kan publicera ett spännande resultat och ändå redovisa den arbetsbelastning som producerade det. En leverantör kan visa en snabb väg och ändå säga var vägen slutar. Ärlig omfattning är inte en broms för innovation. Det är vägbanan som låter alla andra köra.

Riktmärket är ett kontrakt med en nämnare, eftersom nämnaren berättar vad som faktiskt gjordes. Håll den intill siffran. Resultatet blir mindre magiskt, mer jämförbart och mycket mer användbart. Det är ett rättvist byte. System som människor måste kunna lita på förtjänar siffror som tål att läsas långsamt.

När ett mätetal färdas mellan världar

Riktmärkessiffror lämnar ofta teamet som mätte dem och hamnar i ett annat beslutsystem. En forskare publicerar en tabell. Ett produktteam gör om en rad till ett mål. Upphandlingen gör om målet till ett kontrakt. Driften gör om kontraktet till en förväntan på servicenivå. Varje steg förändrar vad siffran förväntas göra. Den ursprungliga nämnaren kan fortfarande finnas i rapporten eller arkivet, men den har blivit socialt avlägsen från beslutet. Ett mätetal behöver en översättningsnotis när det passerar den gränsen.

Översättningsnotisen kan vara enkel. Det här resultatet handlar om komponentgenomströmning, inte avslutade ärenden. Den här träffsäkerhetssiffran använder en fast etikettuppsättning, inte verkliga utfall. Det här energivärdet exkluderar datacentrets kylgräns. Den här baslinjen är en referensimplementation, inte den befintliga tjänsten. Dessa meningar hindrar en användbar mätning från att bli ett vilseledande löfte. De gör också oenighet lättare. En läsare kan ifrågasätta gränsen i stället för att argumentera om huruvida siffran känns imponerande.

Olika team kan medvetet välja olika nämnare. Ett plattformsteam kan bry sig om arbete per joule. En tjänsteägare kan bry sig om avslutade beslut per bemannad timme. En offentlig myndighet kan bry sig om korrekta, förklarbara utfall för en definierad population och svarstid. Dessa är inte konkurrerande sanningar om var och en namnges. Problem börjar när den enklaste nämnaren får stå i för uppdraget. Den snabbaste kärnan ger inte automatiskt den bästa tjänsten, på samma sätt som den största testuppsättningen inte automatiskt ger den mest relevanta.

Innan ett riktmärke återanvänds, fråga vad som har förändrats: arbetsbelastningen, ägaren, konsekvensen eller tidshorisonten. Om något av dem har förändrats, tolka om även om den underliggande siffran är oförändrad. Mätning är inte en relik att bära mellan rum. Det är en relation som måste förnyas när rummet förändras.

Ett resultat bör veta när det ska upphöra

Resultat har en användbar livslängd. Ett riktmärke kopplat till en modellversion, en källögonblicksbild eller en hårdvarukonfiguration blir historiskt när dessa villkor förändras. Det gör inte det gamla resultatet falskt. Det ändrar vilken fråga det kan besvara. Rapporten bör ange vilken händelse som gör påståendet inaktuellt: en ny modell, en ändrad kompilator, en ny datafördelning, en reviderad etikettregel, ett hårdvarubyte, en policyändring eller en observerad driftsavvikelsesignal. En utgångsregel är en liten bit institutionellt minne.

Utan en utgångsregel ackumuleras siffror som jackor på en stol. Varje siffra finns tekniskt sett kvar, och ingen vet vilken som hör till idag. Ett resultatregister kan behålla hela historiken samtidigt som det markerar den aktuella jämförelsen, den ersatta definitionen och orsaken till omkörningen. Själva omkörningen blir då rutinmässigt underhåll snarare än en krishantering. Detta är särskilt viktigt för offentliga tjänster, där ett resultat kan överleva det team som producerade det.

Utgångsregler skyddar också ärliga framsteg. Om en ny arbetsbelastning visar att en tidigare benchmark var för snäv, kan organisationen publicera förändringen, bevara den gamla metoden och förklara den nya gränsen. Den behöver inte försvara en inaktuell siffra eller låtsas att den gamla siffran aldrig funnits. En benchmark som kan snävas in, ersättas och förstås är mer användbar än en som måste förbli imponerande för alltid.

Källor