A benchmark is a contract with a denominator

Teljesítményadatok csak akkor használhatók, ha a munkaterhelés, a hatókör, a hardver, a minőségi feltétel, az alapérték és a bizonytalanság a számhoz kötve...

A benchmark is a contract with a denominator

A szám, amely elfelejti a nevezőjét

Egy benchmarkeredmény mérhető pontosan, és mégis rossz kérdésre válaszolhat. A szokásos bűnös nem a hibás időmérő vagy a becstelen mérnök. Hanem a nevező, amely eltűnt a teszthálózat és a prezentációs dia között. A „kétszer gyorsabb” összehasonlításnak hangzik, de nem mondja meg, hogy milyen munka esetén, melyik gépen, milyen szoftverrel, milyen minőségi feltétel mellett, milyen alapvonalhoz képest, vagy mely felhasználók számára kétszer gyorsabb. Ha ezeket a feltételeket eltávolítjuk, a teljesítményadat csiszolt töredékké válik. Lehet, hogy számszerűen igaz marad. De többé nem mondja meg a vásárlónak vagy az üzemeltetőnek, hogy mire számíthat.

A nevező az a munka, amelyhez képest az eredményt kifejezzük. Az átbocsátóképesség esetében ez az elvégzett munka és az az idő, amely alatt az elvégzést számoljuk. A késleltetés esetében ez a kérés definíciója, a bevont út és a megfigyelések sokasága. A pontosság esetében ez a címkézett halmaz, a címkézési szabály és a mért egység. Az energia esetében ez a mért rendszer határa és az ezen a határon belül szállított munka. A költség esetében ez a költségidőszak, a bevont erőforrások és a hasznos munka mennyisége. Egy benchmark akkor becsületes, ha a számlálója és a nevezője együtt utazik.

Ezért érdemes a benchmarkot szerződésként kezelni. A szerződés megnevezi a kérdést, a munkaterhelést, a hatókört, a hardvert és a szoftvert, a mérőszámot, az alapvonalat, a bizonytalanságot és azt a módszert, amellyel egy másik fél ellenőrizheti az eredményt. Egy szerződés lehet szűk. Lehet feltáró jellegű. Lehet, hogy csak egyetlen telepítéshez hasznos. Ami nem lehet, az egy lenyűgöző szám, amelynek feltételeit az olvasóra hagyjuk kitalálni. A találgatás rossz módja a közpénzek elosztásának, és még rosszabb módja egy olyan szolgáltatás tervezésének, amelyet valaki másnak kell életben tartania.

Az európai szokást, hogy leírják a definíciókat, néha adminisztratív bürokráciaként gúnyolják. A mérési munkában a definíciók azok, amelyek megakadályozzák, hogy a bürokrácia folklórrá váljon. A benchmarktáblázat nem adminisztratív függeléke az eredménynek. Ez az eredmény személyazonossági igazolványa.

Olvassa el az egységet a címsor előtt

Kezdje az egységgel, de ne álljon meg ott. A kérések másodpercenként, a tokenek másodpercenként, a ezredmásodpercek, a joule-ok lekérdezésenként, az eurók ezer rekordonként és a százalékpontok mind mondanak valamit. Egyik sem mondja meg, hogy mit kértek a rendszertől. A 100 kérés másodpercenkénti eredmény leírhat apró, gyorsítótárazott kéréseket vagy nagy, gyorsítótárazatlan kéréseket, amelyek lekérdezést, érvényesítést és emberi átadást tartalmaznak. A 20 ezredmásodperces késleltetés lefedhet egyetlen kernelt vagy egy teljes döntési utat. Az egység egy ajtó. A munkaterhelés a mögötte lévő szoba.

Tegyük fel, hogy egy beszerzési dián az áll, hogy egy új szolgáltatás 40 százalékkal gyorsabb, mint a meglévő. Ez a mondat még nem bizonyíték. Szüksége van legalább a mért műveletre, a bemenet méretére és eloszlására, az órából kizárt munkára, az egyidejűségre, a bemelegítési állapotra, a szoftververziókra, a hardverre és az alapkonfigurációra. Szüksége van a minőségi feltételre is. Ha a gyorsabb út kevesebb érvényes eredményt ad vissza, eldobja a hosszú bemeneteket, vagy kihagy egy költséges ellenőrzési lépést, akkor a számlálót a munka megváltoztatásával tették kisebbé.

Ez nem kérés egy hatalmas táblázatra, mielőtt bárki megszólalhatna. Ez egy kérés arra, hogy azonosítsuk azt a néhány mezőt, amely megváltoztatja az állítás jelentését. Egy kis elemző benchmarknak szüksége lehet a rekordformára, a bemeneti forrásra, az érvényesítési szabályzatra, a fordítóra és a processzorra. Egy következtetési benchmarknak szüksége lehet a modellre, a pontosságra, a kötegre, a forgatókönyvre, a minőségi célra és az energiakorlátra. Egy közszférabeli várólistának szüksége lehet az esetdefinícióra, a szolgáltatási órára, az útválasztási szabályra és az eszkalációs útra. A mezők eltérnek. A kötelezettség, hogy megnevezzük őket, nem.

Van itt egy hasznos fegyelem: írjuk le az eredményt egy olyan mondatban, amely egy második olvasót is megáll. „Ezen a terhelésen és ezen minőségi követelmény mellett, ezen a rendszeren és verzión a mért érték ez volt, ekkora szórással.” Ha a mondat nem fejezhető be olyan szavak nélkül, mint tipikus, legjobb, éles környezethez hasonló vagy reprezentatív, akkor a módszer nincs kész. Ezek a szavak lehetnek helytállóak, de operatív definícióra van szükségük, nem meleg hangvételre.

A benchmarkkártya nem dísz egy szám körül. Ez a szám szerződésének legkisebb hasznos formája.

A hatókör a részeredmény része

A hatókör egy egyszerű kérdésre válaszol: mire terjed ki ez az eredmény, és mi marad a kereten kívül? A gépi tanulási kiértékelésben a hatókör magában foglalja a feladatot, az adatkészletet, a felosztást, a nyelvet, a bemenet hosszát, az üzemeltetési forgatókönyvet és a megengedett implementációs választásokat. Egy szoftverszolgáltatás esetében magában foglalja az útvonalat, az adattárakat, a hálózatot, a gyorsítótárat és azt a munkát, amelyet egy downstream csapat végez a mért végpont visszatérése után. Az egyik rétegen mért eredmény nem válhat csendben az egész szolgáltatásra vonatkozó ígéretté.

Az MLCommons ezt láthatóvá teszi MLPerf Inference dokumentációjában. A benyújtási útmutató megkülönbözteti az adatközponti és az edge rendszertípusokat, felsorol olyan forgatókönyveket, mint az offline, a szerver, az interaktív, az egyfolyamú és a többfolyamú, és megkülönbözteti a zárt és a nyílt divíziót. A zárt divízió az azonos modellt és referencia-beállítást használó, almát az almával összehasonlító összevetésre szolgál. A nyílt divízió olyan választásokat tesz lehetővé, mint az újratanítás vagy a modellcsere. Egyik sem az egyetemesen helyes divízió. Különböző kérdésekre válaszolnak. Egy olyan címsor, amely összekeveri őket, nem tág látókör. Ez kategóriahiba, kiváló tipográfiával.

Ugyanez a dokumentáció megmutatja, miért van szüksége egy benchmarknak explicit minőségi oldalra. Egy felsorolt ResNet50-bejegyzés megnevezi az ImageNet-2012 validációs készletet, annak adatkészlet- és lekérdezésiminta-lista-méreteit, egy referencia-pontosságot és egy szerver-késleltetési korlátot. A felsorolt ResNet50-bejegyzéshez az oldal 50 000 képből álló validációs készletet, 1 024-es lekérdezésiminta-listát, 76,46 százalékos referencia-pontosságot és 15 ms-os szerver-késleltetési korlátot ad meg. Ezek a mezők nem apróságok azoknak, akik élvezik a szabályok olvasását. Megmagyarázzák, hogy a jelentett sebesség mit jelenthetett. Változtassa meg az adatkészletet, a forgatókönyvet vagy a minőségi követelményt, és az összehasonlítás megváltozott, még akkor is, ha a modell neve ismerősnek tűnik.

Egy európai vásárlónak gyanakvóan kellene kezelnie a termékcímke által sugallt hatókört. Az „AI-platform”, a „gyorsító” és a „vállalati szintű” nem határozza meg a munkát. Egy rendszer, amely egy behatárolt műveletben kiváló, pontosan az lehet, amire egy szolgáltatásnak szüksége van. Egy rendszer, amely azt állítja, hogy mindent lefed, lehet, hogy szinte semmit sem mért, ami a szolgáltatáshoz hasonlít. A szűk igazság egészségesebb, mint az egyetemes köd.

Coverage changes the meaning

Coverage is not a footnote about whether the test set was large. It describes whose cases and which situations enter the measurement. A benchmark can cover many examples from one narrow distribution and still say little about the edges that matter in operation. Conversely, a small, carefully selected set can expose an important failure mode without supporting a general performance claim. The choice is a design decision. It must be stated as such.

The OECD’s framework for characterising AI evaluation instruments is useful because it refuses to reduce an evaluation to one score. It proposes 18 facets, including coverage, purpose, realism, validity, reliability, transparency and the conditions under which results can be interpreted. Coverage asks whether the evaluation represents what it intends to measure. Purpose distinguishes a benchmark intended for research from one intended for conformity or another use. Realism asks whether the setting is a toy problem, a simulated or laboratory setting, or real life. These distinctions do not make a benchmark weaker. They make its claim legible.

Coverage also includes the cases an evaluation excludes. A service may report average latency after removing timeouts. A classifier may report accuracy after dropping ambiguous labels. A retrieval system may count only queries with at least one relevant document. An image pipeline may skip corrupt files. Each exclusion can be defensible. The result must say what was removed and why. Otherwise the denominator quietly becomes a list of cases that were convenient to finish.

This is where the denominator becomes political, even before anyone uses the word politics. The included population receives the benefit of being measured. The excluded population receives a story about a system that may not describe them. European public institutions already know this from official statistics. Eurostat’s European Statistics Code of Practice sets 16 principles and 84 indicators for the institutional environment, processes and outputs. Its Quality Assurance Framework supplies methods and tools, while quality reports tell users how data was collected and validated. The message for AI is not that every model must become a statistical office. It is that a number intended for public decisions needs a visible production and quality story.

Accuracy is not one gate

Performance claims often pair speed with a single quality number, then treat the pair as complete. Quality is usually a family of questions. Does the output meet the task definition? Does it preserve required constraints? Does it fail safely when evidence is missing? Does it behave acceptably across the relevant population? Does it remain within the quality boundary while the system is loaded? A fast answer that fails the task is not a faster solution. It is a different workload wearing the same noun.

MLPerf’s structure is instructive because its performance runs sit beside accuracy validation and model-specific requirements. The submission guide tells participants to identify the division, system type and scenario, run the intended benchmark, validate accuracy against thresholds and then prepare a checked submission. The benchmark page lists reference accuracy and latency or throughput conditions per task. The separation is practical. It keeps a system from winning the performance column by quietly losing the task.

Accuracy itself needs a denominator. “Ninety-eight per cent accurate” can mean a percentage of records, tokens, images, requests, or decisions. It can use micro or macro averaging. It can count an abstention as an error, as a safe refusal, or as an unmeasured outcome. It can compare to labels created by one reviewer or several. A benchmark card should name the unit, label rule, aggregation, confidence or variation, and any threshold that turns a measurement into a release decision.

Ne használj minőségi számot díszes felmentésként. Egy modell megfelelhet egy közzétett küszöbértéknek, és mégis alkalmatlan lehet egy adott szolgáltatásra, mert a feladat, a populáció vagy a kárprofil eltér. Fordítva, egy alacsonyabb összesített pontszám elfogadható lehet egy olyan tervezőeszköznél, amely megtartja az embert szerzőként, míg ugyanez a pontszám elfogadhatatlan egy automatikus kapunál. A minőség a kimenet, a cél és a következmény közötti kapcsolat.

Az idő nem egyetlen szám

A késleltetést gyakran úgy mutatják be, mintha a rendszernek egyetlen sebessége lenne. A valódi rendszereknek eloszlásuk van. Az első kérés fizethet a rendszerindítási költségért. Egy gyorsítótár megváltoztathatja a későbbi kéréseket. Az egyidejű felhasználók versenghetnek a memóriáért vagy egy adatbázis-kapcsolatért. Egy hosszú bemenet más úton járhat, mint egy rövid. Az átlag javulhat, miközben a farok rosszabbodik. Ha a farok az, ahol egy szolgáltatás elvéti a határidejét, az átlag csak egy mértékegységgel ellátott zavaró tényező.

Egy hasznos késleltetési jelentés megmondja, mit mértek, és hogyan foglalták össze a megfigyeléseket. Tartalmazhat mediánt, felső percentiliseket, időtúllépési arányt és a kérések számát. Meg kell mondania, hogy kizárták-e a bemelegítő kéréseket, hogy beleszámították-e az újrapróbálkozásokat, és hogy a várakozási vagy hálózati idő a mért útvonalhoz tartozik-e. Ezek a választások nem felcserélhetők. Egy összetevő-benchmark értékes lehet, de nem szabad végponttól végpontig terjedő viselkedésként elmesélni.

Az átbocsátóképesség hasonló csapdát rejt. Magas arány érhető el a munka kötegelésével, a párhuzamosság növelésével vagy egy minőségi követelmény lazításával. Ez pontosan megfelelő lehet egy offline feladathoz. Használhatatlan lehet egy interaktív szolgáltatásnál, amelynek minden kérésre határidőn belül kell válaszolnia. A benchmarknak meg kell adnia a forgatókönyvet és a működési pontot, majd el kell magyaráznia, mi történne, ha a kereslet eltávolodik tőle. Nincs szégyen a szűk működési pontban. Szégyen van abban, ha úgy teszünk, mintha az egész térkép lenne.

Az időnek emberi oldala is van. Egy szolgáltatás, amely gyorsan válaszol, de több felülvizsgálati, javítási vagy fellebbezési munkát hoz létre, lassabb lehet az intézmény szempontjából. Egy benchmark, amely az átadás előtt megállítja az órát, élénknek mutathatja a mért rendszert, miközben a tényleges szolgáltatásnál sor halmozódik fel. A nevezőnek követnie kell a munkát, amíg a feltett kérdésre választ nem kapunk. Ellenkező esetben a stopper egy szigetet mér.

A hardver és a szoftver a számláló része

„Egy szerveren” nem reprodukálható környezet. A processzorgeneráció, az utasításkészlet, a gyorsító, a memória, a tárhely, a termikus állapot, a teljesítménykorlát, az operációs rendszer, az illesztőprogram, a fordító, a futási idő, a könyvtár és a konfiguráció mind megváltoztathatja az eredményt. Ugyanígy egy modellformátum, egy kvantálási beállítás, egy kötegméret, egy kernelválasztás vagy egy szálkezelési szabályzat. A benchmarknak nem kell felsorolnia minden kábelt. Azonosítania kell azokat a részeket, amelyek megváltoztathatják a mérést.

Az MLPerf a teljes mért összeállítást tesztelendő rendszernek nevezi, és az eredményeket rendszertípus és elérhetőségi kategória szerint rendezi. Ez a szókincs az MLPerfen túl is hasznos. A tesztelendő rendszernek határa van. A határ megmondja, mely hardver és szoftver tartozik bele, mely szolgáltatások külsőek, és mely munka marad ki. A fali konnektornál mért teljesítményérték más jelentéssel bír, mint egy olyan érték, amely csak egy gyorsítót számol. A kernelen belül mért késleltetés más jelentéssel bír, mint az, amely a kérések ütemezését is tartalmazza.

A verziók számítanak, mert a benchmark állapotok közötti összehasonlítás, nem pedig egy terméknév időtlen tulajdonsága. Rögzítsd a modell vagy alkalmazás verzióját, a függőségek verzióit, a fordítói jelzőket, az illesztőprogramot és a firmware-t, ahol azok befolyásolják az eredményt. Rögzítsd a konfigurációt, amely egy háttérrendszert vagy egy pontosságot választott ki. Ha egy futási idő másik kernelt választ egy másik gépen, az az eredmény része, nem pedig egy később eltakarítandó megvalósítási részlet.

Hardware disclosure is not an invitation to turn a blog post into a parts catalogue. It is a way to prevent false equivalence. A buyer does not need to care about every instruction if the claim is about a complete service. They do need to know whether the comparison includes the same work, the same accuracy, the same input path and a system that can actually be obtained and operated in the intended European setting.

Baselines are promises

A baseline is the comparison that gives a result direction. Without it, a number may describe a system but not an improvement. The baseline must answer the same question under comparable conditions. If the new path uses a newer compiler, a different input distribution or a different quality target, the result may still be interesting, but the comparison is no longer clean. Say what changed. The reader can then decide whether the difference is useful.

Baseline choice is an act of interpretation. Compare with the incumbent that users actually run, with a reference implementation, with a previous release, or with a theoretical limit, and you will learn different things. A new system can be better than the reference and worse than the service it is replacing. It can be faster on a clean test and slower once validation and storage are included. The benchmark should name the baseline and explain why it answers the operational question.

Paired runs are often more informative than a single victory lap. Keep the workload and evaluation definition fixed, change one material factor, and record the difference. If several factors change together, describe the comparison as a package rather than attributing the whole effect to one component. This sounds obvious until an upgrade, a data refresh and a new cache policy arrive in the same release. The chart then has one arrow and three possible causes, which is a small mystery no one budgeted for.

A baseline also needs a shelf life. A data feed, supplier, model, policy or hardware platform can move. The comparison remains valid for the versions and period tested. It should not be reused as a current guarantee without checking the contract. This is where version history earns its keep. A superseded result is not a failure. It is a historical claim whose conditions should remain visible.

Uncertainty is not an apology

Every measurement contains variation. Some variation comes from the system, some from the workload and some from the measurement process. Repeated runs can reveal it, but repetition alone does not explain the cause. A warm cache may be stable. A noisy neighbour may not be. A small evaluation set may produce a wide range of plausible outcomes. A larger set may reduce sampling noise while leaving a biased population untouched. Uncertainty tells the reader how far the result can safely travel.

Report uncertainty in a form suited to the claim. It might be a range across repeated runs, a confidence interval, a standard error, a distribution of latency, a sensitivity analysis or a list of known limits. Do not add a confidence interval because the table looks lonely. State what was repeated, what was held fixed, and what the interval does and does not represent. Statistical language is not a spell. It is a contract about variation.

There is a second kind of uncertainty that numbers cannot remove: uncertainty about whether the measurement represents the intended service. A result may have tiny run-to-run variation and poor real-world coverage. A benchmark may be perfectly reproducible within a laboratory while missing the languages, input formats, shift patterns or failure consequences of the deployment. Low measurement noise does not create validity. It merely makes the wrong question more consistently answered.

Ezért a bizonytalanságnak az állítás mellett kell helyet kapnia, nem pedig egy apró betűs lábjegyzetben. Ha egy küszöbérték közel van a mért határhoz, az számít. Ha egy eredmény jelentősen változik más bemeneti összetétel mellett, az számít. Ha az energiahatár nem foglalja magában a hűtést vagy az adatmozgatást, az számít. Az őszinte mondat kevésbé diadalmas lehet, de többet ad a döntéshozónak, mint az optimizmus: egy helyet, ahová az óvatosságot teheti.

A reprodukció lánc, nem pedig letöltés gomb

A reprodukálhatóságot gyakran a kód közzétételére szűkítik. A kód számít. De ez csak egy láncszem. A másik félnek szüksége van a munkaterhelésre vagy annak jogszerű leírására, az adatverzióra, a konfigurációra, a környezetre, a parancsra vagy a futtató keretrendszerre, a véletlenszerűség kezelésének szabályaira, a várt kimenet szabályára, az eredményfájlra és arra a módszerre, amellyel eldöntik, hogy a futtatás egyezik-e. Ha egy láncszem hiányzik, a másik fél egy hasonló kísérletet reprodukálhat, nem pedig a jelentettet.

A láncnak meg kell különböztetnie a pontos visszajátszást a független megismétléstől. A pontos visszajátszás a rögzített artefaktumot, állapotot, bemeneteket, konfigurációt és végrehajtási útvonalat használja annak ellenőrzésére, hogy ugyanaz a futtatás rekonstruálható-e. A független megismétlés külön előkészített környezetet használ annak tesztelésére, hogy az eredmény fennmarad-e az eredeti gépen vagy csapaton kívül. Mindkettő értékes. Más kérdésekre válaszolnak. A bájtra azonos eredmény egy rögzített bemeneten erős azonosságot igazol az adott futtatásra. Nem bizonyítja, hogy az élő világ változatlan marad.

Az OECD értékelési keretrendszere könnyebben láthatóvá teszi ezt a különbséget azzal, hogy a célt, a valósághűséget, a lefedettséget és a megbízhatóságot külön szempontként kezeli. Egy értékelés kiváló lehet regressziós tesztelésre, de gyenge az élő szolgáltatás teljesítményének becslésére. Hasznos lehet kutatáshoz, de alkalmatlan megfelelőségvizsgálatra. A reprodukció nem törli el a célt. Segít az olvasónak ellenőrizni azt az állítást, amelyet a módszer valóban alátámaszt.

Azoknál az adatoknál, amelyeket nem lehet közzétenni, tegye közzé a határt és az utat. Írja le a populációt, a mintavételi folyamatot, a címkézési módszert, a kizárási szabályokat és az ellenőrzési lépéseket. Adjon biztonságos reprodukciós csomagot, ha lehetséges, és magyarázza el, mi marad védett. „Az adat bizalmas” legitim határ, nem pedig kész módszer. Az olvasónak továbbra is értenie kell, hogy mit mértek, és miért lehet vagy nem lehet általánosítani az eredményt.

A reprodukció nem egy „futtatás újra” gomb. Az azonosságok lánca, amely lehetővé teszi egy másik csapatnak, hogy megkérdőjelezze az állítást.

A közintézményeknek vissza kell utasítaniuk a demonstrációs színházat

Public institutions do not need to reject benchmarks. They need to refuse benchmarks that cannot state their contract. A polished demonstration can help a committee understand a possibility. It cannot substitute for evidence about the service the institution must run, the people it serves and the failures it must repair. The distinction matters because a demo is optimised for a short encounter while a public service is judged across seasons, staff changes, appeals, maintenance and law.

Before buying, ask the supplier to define the workload in the language of the service. What enters the system? What is measured? What is excluded? Which quality rule must hold? Which human role reviews a result? How is drift found? How can the institution export its evidence? What happens when the model, source, supplier or policy changes? Which version is the comparison against? What is the rollback path? A supplier may answer some questions with a contract, some with a test and some with an honest boundary. That mixture is healthier than an answer made entirely of adjectives.

The EU AI Act makes the point in legal language for high-risk systems. Article 15 requires an appropriate level of accuracy, robustness and cybersecurity, with consistent performance in those respects throughout the lifecycle. A benchmark cannot establish the whole legal obligation by itself. It can support a part of the evidence if its scope, quality conditions and lifecycle position are clear. Treating one score as compliance would be another denominator error. The law names the outcome; engineering has to show the path.

Procurement should also ask who owns the benchmark after the award. A test run prepared by a supplier may be useful, but the institution needs enough information to monitor the system in its own context. It needs a baseline that can be rerun when a version changes, a review path when results move and a record of the decisions made about acceptable performance. Otherwise the first benchmark is an entrance exam and the production system is allowed to graduate without further questions.

Make the benchmark card small enough to use

Long methods can be necessary. They are not always the first thing a reader needs. A benchmark card is a compact index to the contract. It can sit next to a result in a report, an evaluation register or a procurement file. The card should name the question, workload, scope, system, metric, quality requirement, baseline, uncertainty, reproduction route, owner and expiry or change trigger. The detailed method can live behind it. The card keeps the claim from travelling alone.

Good cards are selective rather than crowded. They surface the fields that can change interpretation, then link to the evidence package. A latency card might foreground input size, concurrency, percentile, warm-up, version and timeout rule. An energy card might foreground the system boundary, workload, measurement instrument, duration and excluded infrastructure. An accuracy card might foreground population, label rule, aggregation, abstention treatment and error severity. The common shape is not a fixed template. It is a promise that the reader can find the denominator.

The card should mark epistemic status. Is the value measured, estimated, expected, proposed or illustrative? Is the baseline current? Is the evaluation suite prepared but not yet run? Are results protected because the test material contains personal data? These labels prevent a method from being mistaken for a result. They also let an organisation publish progress without manufacturing success. A prepared test is useful information. It is not evidence that the system passed it.

Végül adj a kártyának egy tulajdonost és egy módosítási szabályt. Az eredmény tulajdonos nélkül diákká silányul. Az eredmény módosítási szabály nélkül a falon marad, miután a munkaterhelés továbbállt. A tulajdonosnak nem kell örökre megvédenie a számot. Neki kell megmondania, hogy az állítást mikor kell újrafuttatni, visszavonni vagy szűkíteni. A mérés a működés részévé válik, amikor valakinek hatalmában áll megőrizni annak hitelességét.

Két becsületes mód az eredmény közzétételére

Két gyakori közzétételi mód létezik. Az első a szigorú összehasonlítás. Rögzíti a feladatot, az adatokat, a minőségi szabályt, a rendszerhatárt és az alapvonalat, hogy az olvasó összehasonlíthassa a változatokat. A második a feltáró jellegű mérés. Azt kérdezi, mi történik, ha a tervezés, a munkaterhelés vagy a környezet változik, és beszámol a megfigyelésekről azok korlátaival együtt. A feltáró munka értékes lehet, mielőtt szigorú benchmark létezne. Nem szabad azonban a megfelelőségi eredmény nyelvét kölcsönöznie.

A szigorú összehasonlítások igényesek, mert láthatóvá teszik a különbségeket. Ha egy csapat egyszerre változtatja meg a modellt és a hardvert, lehet, hogy nem lehet az eredményt hozzárendelni. Ha egy új munkaterhelés valósághűbb, de már nem egyezik az alapvonallal, az állítást új mérésként kell megfogalmazni. Ha egy optimalizálás javítja a sebességet, miközben megváltoztatja a kimenet minőségét, mindkét oldalt jelenteni kell. A fegyelem nem a haladás megakadályozására való. Arra való, hogy megakadályozza, hogy egy haladásról szóló történet eltörölje azokat a feltételeket, amelyek lehetővé tették.

A feltáró méréseknek megvan a maguk becsületessége. Mondd ki, hogy a minta kicsi, hogy a környezet ideiglenes, hogy a munkaterhelés szintetikus, hogy az eredményt nem replikálták függetlenül, vagy hogy a minőségi ellenőrzés hiányos. Ezek nem gyengeségek, amelyeket el kell rejteni egy csiszolt kiadásig. Ezek azok az információk, amelyek segítenek az olvasónak eldönteni, mit tegyen legközelebb. Egy európai mérnöki kultúrának nem kell úgy tennie, mintha minden teszt végleges ítélet lenne. Abba kell hagynia, hogy egy kérdést megválaszoltnak nevezzen, mielőtt a tesztet elolvasták volna.

Mindkét módnak hasznára válik egy eredményarchívum. Tartsd azonosíthatóan a régi definíciókat, konfigurációkat és eredményeket. Rögzítsd a felülírást ahelyett, hogy törölnéd a múltat. A megváltoztatott benchmark lehet a megfelelő benchmark egy megváltoztatott szolgáltatáshoz, de nem használható a régi eredmény jelentésének átírására. A verziótörténet a nevező emlékezete.

A mi kis jegyzetünk

A Dweve-nél a Core-t egy végrehajtási cellával és egy determinizmus-szerződéssel írjuk le. Ennek a szókincsnek a hasznos része nem a terméknév. Hanem az a ragaszkodás, hogy egy művelet magában hordozza a numerikus reprezentációját, a háttérrendszerét, az utasításkészletét, a diszpécselési szabályzatát és a visszajátszási állapotát az értékelt út részeként. Ez ugyanaz a szokás, amelyre a benchmarknak szüksége van: tartsd a feltételeket az eredményhez kötve, ahelyett, hogy úgy írnád le a teljesítményt, mintha a rendszer fölött lebegne.

Ez egy kis tervezési jegyzet, nem állítás egy külső telepítésről vagy egy mért eredményről. A tágabb tanulság nem függ a Dweve-től. Legyen a rendszer nyilvános statisztikai szolgáltatás, ipari vezérlő, nyelvi eszköz vagy kutatási prototípus, egy szám azáltal érdemel bizalmat, hogy megnevezi a munkáját és a korlátait. A saját dokumentációnk egyszerűen az egyik hely, ahol megpróbáljuk ezt a határt egyértelművé tenni.

A nevező az a rész, amely utazik

A benchmark címsorát könnyű másolni. A nevezőt nehezebb magunkkal vinni, ezért gyakran hátrahagyják. Egy vásárló bemásol egy átviteli sebesség számot egy üzleti tervbe. Egy szabályozó pontossági pontszámot lát egy dossziéban. Egy mérnök két különböző munkaterhelésből származó diagramot hasonlít össze. Egy újságíró megismétel egy százalékot a populáció nélkül. Minden olvasó olyan számot kap, amely elveszítette azt a szerződést, amely értelmet adott neki.

A javítás nem bonyolult, bár fegyelmet igényel. Nevezd meg a kérdést. Határozd meg a munkát. Add meg a terjedelmet és a kizárásokat. Azonosítsd a rendszert és a verziókat. Válassz olyan mérőszámot, amely illeszkedik a szolgáltatáshoz. Vezess kiindulási alapot. Mérd az eltéréseket. Tedd közzé a módszert és a bizonyítékokat. Jelöld, mi marad ismeretlen. Rendelj gazdát az állításhoz, és adj okot az újrafuttatásra. Ha az eredmény nem támaszt alá egy tág állítást, szűkítsd az állítást.

Így tud Európa ellenállni a demószínháznak anélkül, hogy elveszítené az ambíció iránti fogékonyságát. Egy közintézmény vásárolhat új képességet, és mégis elvárhat olyan benchmarkot, amely tiszteletben tartja a szolgáltatást. Egy kutatócsoport publikálhat izgalmas eredményt, és mégis megadhatja a munkaterhelést, amely azt létrehozta. Egy szállító mutathat gyors utat, és mégis elmondhatja, hol ér véget az út. A becsületes terjedelem nem fék az innováción. Ez az az útfelület, amelyen bárki más is vezethet.

A benchmark szerződés nevezővel, mert a nevező megmondja, mit végeztek el ténylegesen. Tartsd a szám mellett. Az eredmény kevésbé lesz varázslatos, jobban összehasonlítható és sokkal hasznosabb lesz. Ez korrekt csere. Azok a rendszerek, amelyekre az embereknek támaszkodniuk kell, olyan számokat érdemelnek, amelyek túlélik, ha lassan olvassák el őket.

Amikor egy mérőszám világok között utazik

A benchmark számok gyakran elhagyják a csapatot, amely mérte őket, és más döntési rendszerbe kerülnek. Egy kutató publikál egy táblázatot. Egy termékcsapat egy sort céllá alakít. A beszerzés a célt szerződéssé alakítja. Az üzemeltetés a szerződést szolgáltatási szintű elvárássá alakítja. Minden lépés megváltoztatja, mit kérnek a számtól. Az eredeti nevező még jelen lehet a cikkben vagy a tárhelyen, de társadalmilag távol került a döntéstől. Egy mérőszámnak fordítási megjegyzésre van szüksége, amikor átlépi ezt a határt.

A fordítási megjegyzés lehet egyszerű. Ez az eredmény az összetevők átviteli sebességéről szól, nem a befejezett esetekről. Ez a pontossági érték rögzített címkekészletet használ, nem valós idejű eredményeket. Ez az energiaérték kizárja az adatközpont hűtési határát. Ez a kiindulási alap referencia-megvalósítás, nem a jelenlegi szolgáltatás. Ezek a mondatok megakadályozzák, hogy egy hasznos mérés félrevezető ígéretté váljon. Megkönnyítik az egyet nem értést is. Az olvasó megkérdőjelezheti a határt, ahelyett hogy azon vitatkozna, lenyűgözőnek tűnik-e a szám.

A különböző csapatok szándékosan választhatnak különböző nevezőket. Egy platformcsapatot érdekelhet a joule-onkénti munka. Egy szolgáltatásgazdát érdekelhetnek a befejezett döntések munkaóránként. Egy hatóságot érdekelhetnek a helyes, magyarázható eredmények egy meghatározott populációra és a válaszidő. Ezek nem versengő igazságok, ha mindegyiket megnevezik. A baj akkor kezdődik, amikor a legkönnyebb nevezőt hagyják a küldetés helyett állni. A leggyorsabb kernel nem automatikusan teszi a legjobb szolgáltatást, ugyanúgy, ahogy a legnagyobb tesztkészlet sem automatikusan teszi a legrelevánsabbat.

Mielőtt egy benchmarkot újra felhasználnának, kérdezd meg, mi mozdult el: a munkaterhelés, a gazda, a következmény vagy az időhorizont. Ha bármelyik elmozdult, futtasd újra az értelmezést, még akkor is, ha a mögöttes szám változatlan. A mérés nem ereklye, amelyet szobák között hordoznak. Ez egy kapcsolat, amelyet meg kell újítani, amikor a szoba változik.

Egy eredménynek tudnia kell, mikor jár le

Az eredményeknek van hasznos élettartamuk. Egy modellverzióhoz, forrás-pillanatképhez vagy hardverkonfigurációhoz kötött benchmark történelmivé válik, amikor ezek a feltételek változnak. Ez nem teszi hamissá a régi eredményt. Megváltoztatja a kérdést, amelyre válaszolhat. A jelentésnek meg kell mondania, milyen esemény teszi elavulttá az állítást: új modell, módosított fordító, új adateloszlás, módosított címkeszabály, hardvercsere, szakpolitikai változás vagy megfigyelt eltérésjel. A lejárati szabály az intézményi emlékezet egy kis darabja.

Lejárati szabály nélkül a számok úgy halmozódnak fel, mint a kabátok a széken. Mindegyik technikailag még ott van, és senki sem tudja, melyik tartozik a mai naphoz. Egy eredményregiszter megőrizheti a teljes előzményt, miközben jelöli az aktuális összehasonlítást, a felülírt definíciót és az újrafuttatás okát. Az újrafuttatás így hétköznapi karbantartássá válik, nem pedig válságkezeléssé. Ez különösen fontos a közszolgáltatásoknál, ahol egy eredmény túlélheti az azt előállító csapatot.

A lejárat a becsületes haladást is védi. Ha egy új munkaterhelésből kiderül, hogy egy korábbi benchmark túl szűk volt, a szervezet közzéteheti a változást, megőrizheti a régi módszert, és elmagyarázhatja az új határt. Nem kell megvédenie egy elavult számot, sem pedig úgy tennie, mintha a régi szám soha nem létezett volna. Egy benchmark, amely szűkíthető, lecserélhető és megérthető, hasznosabb, mint az, amelynek örökre lenyűgözőnek kell maradnia.

Források