Un benchmark este un contract cu un numitor.

Afirmațiile despre performanță devin utile când volumul de lucru, domeniul, hardware-ul, condiția de calitate, valoarea de referință și incertitudinea rămân...

Un benchmark este un contract cu un numitor.

Numărul care își uită numitorul

Un rezultat de benchmark poate fi măsurat corect și totuși să răspundă la o întrebare greșită. Vinovatul obișnuit nu este un cronometru defect sau un inginer necinstit. Este numitorul care a dispărut între mediul de testare și slide-ul de prezentare. „De două ori mai rapid” sună ca o comparație, dar nu spune de două ori mai rapid la ce muncă, pe ce mașină, cu ce software, în ce condiții de calitate, față de ce bază de referință sau pentru ce utilizatori. Elimină aceste condiții și un număr de performanță devine un fragment lustruit. Poate rămâne adevărat din punct de vedere numeric. Dar nu mai spune unui cumpărător sau unui operator la ce să se aștepte.

Numitorul este munca față de care este exprimat rezultatul. Pentru debit, este munca finalizată și timpul în care finalizarea este numărată. Pentru latență, este definiția cererii, calea inclusă și populația de observații. Pentru acuratețe, este setul etichetat, regula de etichetare și unitatea evaluată. Pentru energie, este granița sistemului măsurat și munca livrată în interiorul acelei granițe. Pentru cost, este perioada de cost, resursele incluse și volumul de muncă utilă. Un benchmark este onest atunci când numărătorul și numitorul său călătoresc împreună.

De aceea, un benchmark este cel mai bine tratat ca un contract. Contractul numește întrebarea, volumul de muncă, domeniul de aplicare, hardware-ul și software-ul, metrica, baza de referință, incertitudinea și metoda prin care o altă parte ar putea verifica rezultatul. Un contract poate fi restrâns. Poate fi exploratoriu. Poate fi util doar pentru o singură implementare. Ceea ce nu poate fi este un număr impresionant ale cărui condiții sunt lăsate cititorului să le ghicească. Ghicitul este o modalitate proastă de a aloca bani publici și o modalitate și mai proastă de a proiecta un serviciu pe care altcineva trebuie să îl mențină în viață.

Obiceiul european de a scrie definițiile este ocazional ridiculizat ca birocrație. În munca de măsurare, definițiile sunt partea care împiedică birocrația să devină folclor. Tabelul de benchmark nu este o anexă administrativă la rezultat. Este cartea de identitate a rezultatului.

Citește unitatea înainte de titlu

Începe cu unitatea, dar nu te opri acolo. Cereri pe secundă, tokeni pe secundă, milisecunde, jouli pe interogare, euro pe mie de înregistrări și puncte procentuale îți spun toate ceva. Niciuna nu îți spune ce i s-a cerut sistemului să facă. Un rezultat de 100 de cereri pe secundă poate descrie cereri mici stocate în cache sau cereri mari, fără cache, care includ regăsirea, validarea și o predare umană. O latență de 20 de milisecunde poate acoperi un singur nucleu sau o întreagă cale de decizie. Unitatea este o ușă. Volumul de muncă este camera din spatele ei.

Să presupunem că un slide de achiziții spune că un serviciu nou este cu 40 la sută mai rapid decât cel existent. Propoziția nu este încă o dovadă. Are nevoie cel puțin de operațiunea cronometrată, dimensiunea și distribuția intrării, munca exclusă din cronometrare, concurența, starea de încălzire, versiunile de software, hardware-ul și configurația de bază. Are nevoie și de condiția de calitate. Dacă calea mai rapidă returnează mai puține rezultate valide, elimină intrările lungi sau sare peste un pas costisitor de verificare, numărătorul a fost micșorat prin schimbarea muncii.

Aceasta nu este o cerere pentru un tabel enorm înainte ca cineva să poată vorbi. Este o cerere de a identifica puținele câmpuri care schimbă sensul afirmației. Un mic benchmark de parsare poate avea nevoie de forma înregistrării, sursa intrării, politica de validare, compilator și procesor. Un benchmark de inferență poate avea nevoie de model, precizie, lot, scenariu, țintă de calitate și graniță de putere. O coadă din sectorul public poate avea nevoie de definiția cazului, ceasul serviciului, regula de rutare și calea de escaladare. Câmpurile diferă. Obligația de a le numi nu diferă.

Există aici o disciplină utilă: scrieți rezultatul ca o propoziție care ar putea rezista unui al doilea cititor. „Sub această sarcină de lucru și această cerință de calitate, pe acest sistem și această versiune, valoarea măsurată a fost aceasta, cu această variație.” Dacă propoziția nu poate fi completată fără cuvinte precum tipic, optim, asemănător producției sau reprezentativ, metoda nu este finalizată. Aceste cuvinte pot fi valide, dar au nevoie de o definiție operațională, nu de un ton cald.

Un card de referință nu este un ornament în jurul unui număr. Este cea mai mică formă utilă a contractului numărului.

Domeniul de aplicare face parte din rezultat

Domeniul de aplicare răspunde la o întrebare simplă: ce acoperă acest rezultat și ce lasă în afara cadrului? În evaluarea învățării automate, domeniul de aplicare include sarcina, setul de date, împărțirea, limba, lungimea intrării, scenariul de operare și alegerile de implementare permise. Într-un serviciu software, acesta include ruta, stocările de date, rețeaua, memoria cache și munca pe care o echipă din aval o efectuează după ce punctul final măsurat răspunde. Un rezultat măsurat pe un singur strat nu ar trebui să devină în tăcere o promisiune despre întregul serviciu.

MLCommons face acest lucru vizibil în documentația sa MLPerf Inference. Ghidul de trimitere separă tipurile de sisteme pentru centre de date și pentru edge, listează scenarii precum offline, server, interactiv, flux unic și flux multiplu și distinge o diviziune închisă de una deschisă. Diviziunea închisă este destinată unei comparații directe folosind același model și aceeași configurație de referință. Diviziunea deschisă permite alegeri precum reantrenarea sau înlocuirea modelului. Niciuna nu este diviziunea universal corectă. Ele răspund la întrebări diferite. Un titlu care le amestecă nu este o viziune amplă. Este o eroare de categorie cu o tipografie excelentă.

Aceeași documentație arată de ce un criteriu de referință are nevoie de o latură explicită a calității. O intrare listată ResNet50 numește setul de validare ImageNet-2012, dimensiunile setului de date și ale listei de mostre de interogare, o precizie de referință și o constrângere de latență a serverului. Pentru intrarea listată ResNet50, pagina oferă un set de validare de 50 000 de imagini, o listă de mostre de interogare de 1 024, o precizie de referință de 76,46 la sută și o constrângere de latență a serverului de 15 ms. Aceste câmpuri nu sunt banalități pentru persoanele cărora le place să citească reguli. Ele explică ce i s-a permis să însemne viteza raportată. Schimbați setul de date, scenariul sau cerința de calitate, iar comparația s-a schimbat, chiar dacă numele modelului pare familiar.

Un cumpărător european ar trebui să fie suspicios față de un domeniu de aplicare implicat de o etichetă de produs. „Platformă de inteligență artificială”, „accelerator” și „de nivel enterprise” nu definesc munca. Un sistem excelent la o operațiune limitată poate fi exact ceea ce are nevoie un serviciu. Un sistem care pretinde că acoperă totul poate fi măsurat pe aproape nimic care să semene cu serviciul. Adevărul îngust este mai sănătos decât ceața universală.

Acoperirea schimbă sensul

Acoperirea nu este o notă de subsol despre cât de mare a fost setul de teste. Ea descrie ale cui cazuri și care situații intră în măsurare. Un benchmark poate acoperi multe exemple dintr-o singură distribuție îngustă și totuși să spună puțin despre marginile care contează în funcționare. Invers, un set mic, atent selecționat, poate expune un mod important de eșec fără să susțină o afirmație generală de performanță. Alegerea este o decizie de proiectare. Trebuie declarată ca atare.

Cadrul OECD pentru caracterizarea instrumentelor de evaluare AI este util pentru că refuză să reducă o evaluare la un singur scor. Propune 18 fațete, inclusiv acoperirea, scopul, realismul, validitatea, fiabilitatea, transparența și condițiile în care rezultatele pot fi interpretate. Acoperirea întreabă dacă evaluarea reprezintă ceea ce intenționează să măsoare. Scopul distinge un benchmark destinat cercetării de unul destinat conformității sau altui uz. Realismul întreabă dacă situația este o problemă-jucărie, un cadru simulat sau de laborator, sau viața reală. Aceste distincții nu slăbesc un benchmark. Ele fac inteligibilă afirmația acestuia.

Acoperirea include și cazurile pe care o evaluare le exclude. Un serviciu poate raporta latența medie după eliminarea timeout-urilor. Un clasificator poate raporta acuratețea după eliminarea etichetelor ambigue. Un sistem de regăsire poate număra doar interogările cu cel puțin un document relevant. O conductă de imagini poate sări peste fișierele corupte. Fiecare excludere poate fi justificabilă. Rezultatul trebuie să spună ce a fost eliminat și de ce. Altfel, numitorul devine în tăcere o listă de cazuri care au fost convenabile de finalizat.

Aici numitorul devine politic, chiar înainte ca cineva să folosească cuvântul politică. Populația inclusă primește beneficiul de a fi măsurată. Populația exclusă primește o poveste despre un sistem care poate să nu o descrie. Instituțiile publice europene știu deja acest lucru din statisticile oficiale. Codul de practică al statisticilor europene al Eurostat stabilește 16 principii și 84 de indicatori pentru mediul instituțional, procese și rezultate. Cadrul său de asigurare a calității oferă metode și instrumente, iar rapoartele de calitate le spun utilizatorilor cum au fost colectate și validate datele. Mesajul pentru AI nu este că fiecare model trebuie să devină un birou de statistică. Este că un număr destinat deciziilor publice are nevoie de o poveste vizibilă despre producție și calitate.

Acuratețea nu este o singură poartă

Afirmațiile de performanță asociază adesea viteza cu un singur număr de calitate, apoi tratează perechea ca fiind completă. Calitatea este de obicei o familie de întrebări. Îndeplinește rezultatul definiția sarcinii? Păstrează constrângerile cerute? Eșuează în siguranță când lipsesc dovezi? Se comportă acceptabil în populația relevantă? Rămâne în interiorul limitei de calitate în timp ce sistemul este încărcat? Un răspuns rapid care eșuează sarcina nu este o soluție mai rapidă. Este un volum de muncă diferit care poartă același substantiv.

Structura MLPerf este instructivă pentru că rulările sale de performanță stau alături de validarea acurateței și cerințele specifice modelului. Ghidul de trimitere le spune participanților să identifice diviziunea, tipul de sistem și scenariul, să ruleze benchmark-ul intenționat, să valideze acuratețea față de praguri și apoi să pregătească o trimitere verificată. Pagina benchmark-ului listează acuratețea de referință și condițiile de latență sau throughput pentru fiecare sarcină. Separarea este practică. Împiedică un sistem să câștige coloana de performanță pierzând în tăcere sarcina.

Acuratețea în sine are nevoie de un numitor. „98% acuratețe” poate însemna un procent de înregistrări, tokeni, imagini, cereri sau decizii. Poate folosi medierea micro sau macro. Poate număra o abținere ca eroare, ca refuz sigur sau ca rezultat nemăsurat. Poate compara cu etichete create de un singur recenzent sau de mai mulți. O fișă de benchmark ar trebui să numească unitatea, regula de etichetare, agregarea, încrederea sau variația și orice prag care transformă o măsurare într-o decizie de lansare.

Nu folosi un scor de calitate ca pe o scuză decorativă. Un model poate atinge un prag publicat și să rămână nepotrivit pentru un anumit serviciu, deoarece sarcina, populația sau profilul de risc diferă. Invers, un scor agregat mai mic poate fi acceptabil pentru un instrument de redactare care păstrează un om ca autor, în timp ce același scor este inacceptabil pentru o poartă automată. Calitatea este o relație între rezultat, scop și consecință.

Timpul nu este un singur număr

Latența este adesea prezentată ca și cum un sistem ar avea o singură viteză. Sistemele reale au o distribuție. Prima cerere poate suporta costul de pornire. Un cache poate schimba cererile ulterioare. Utilizatorii concurenți pot concura pentru memorie sau pentru o conexiune la baza de date. O intrare lungă poate urma o cale diferită față de una scurtă. Media se poate îmbunătăți în timp ce coada se înrăutățește. Dacă coada este locul unde un serviciu ratează termenul limită, media este o distragere a atenției cu o unitate de măsură.

Un raport util de latență spune ce a fost cronometrat și cum au fost rezumate observațiile. Poate include o mediană, percentile superioare, rata de timeout și numărul de cereri. Ar trebui să precizeze dacă cererile de încălzire au fost excluse, dacă reîncercările au fost incluse și dacă timpul de așteptare în coadă sau timpul de rețea aparține căii măsurate. Aceste alegeri nu sunt interschimbabile. Un benchmark de componentă poate fi valoros, dar nu trebuie prezentat ca un comportament de la un capăt la altul.

Debitul are o capcană similară. O rată mare poate fi obținută prin procesarea în loturi, creșterea concurenței sau relaxarea unei cerințe de calitate. Acest lucru poate fi exact ceea ce trebuie pentru o sarcină offline. Poate fi inutil pentru un serviciu interactiv care trebuie să răspundă la fiecare cerere într-un termen limită. Benchmark-ul ar trebui să precizeze scenariul și punctul de operare, apoi să explice ce s-ar întâmpla când cererea se îndepărtează de acesta. Nu este nicio rușine într-un punct de operare îngust. Este rușine să pretinzi că este întreaga hartă.

Timpul are și o latură umană. Un serviciu care răspunde rapid, dar creează mai multă muncă de revizuire, corectare sau contestație poate fi mai lent din punctul de vedere al instituției. Un benchmark care oprește cronometrul înainte de predare poate face sistemul măsurat să pară rapid, în timp ce serviciul real acumulează o coadă. Numitorul ar trebui să urmărească munca până când întrebarea adresată primește răspuns. În caz contrar, cronometrul măsoară o insulă.

Hardware-ul și software-ul fac parte din numărător

„Pe un server” nu este un mediu reproductibil. Generația procesorului, setul de instrucțiuni, acceleratorul, memoria, stocarea, starea termică, limita de putere, sistemul de operare, driverul, compilatorul, runtime-ul, biblioteca și configurația pot schimba toate un rezultat. La fel pot face un format de model, o setare de cuantizare, o dimensiune de lot, o selecție de kernel sau o politică de fire de execuție. Benchmark-ul nu trebuie să enumere fiecare cablu. Trebuie să identifice părțile care pot modifica măsurarea.

MLPerf numește configurația completă măsurată sistemul testat și organizează rezultatele după tipul de sistem și categoria de disponibilitate. Acest vocabular este util dincolo de MLPerf. Un sistem testat are o graniță. Granița spune ce hardware și software sunt incluse, ce servicii sunt externe și ce muncă este omisă. O cifră de putere măsurată la priză are o semnificație diferită de o cifră care numără doar un accelerator. O latență măsurată în interiorul unui kernel are o semnificație diferită de una care include programarea cererilor.

Versiunile contează pentru că un benchmark este o comparație între stări, nu o proprietate atemporală a unui nume de produs. Înregistrează versiunea modelului sau aplicației, versiunile dependențelor, flag-urile compilatorului, driverul și firmware-ul acolo unde afectează rezultatul. Înregistrează configurația care a selectat un backend sau o precizie. Dacă un runtime alege un kernel diferit pe altă mașină, aceasta face parte din rezultat, nu un detaliu de implementare care trebuie ascuns mai târziu.

Dezvăluirea componentelor hardware nu este o invitație de a transforma o postare de blog într-un catalog de piese. Este o modalitate de a preveni comparațiile false. Un cumpărător nu trebuie să îi pese de fiecare detaliu tehnic dacă afirmația vizează un serviciu complet. Dar trebuie să știe dacă comparația include aceeași muncă, aceeași precizie, același traseu de intrare și un sistem care poate fi efectiv obținut și operat în contextul european vizat.

Linia de bază este o promisiune

Linia de bază este comparația care dă o direcție rezultatului. Fără ea, un număr poate descrie un sistem, dar nu și o îmbunătățire. Linia de bază trebuie să răspundă la aceeași întrebare în condiții comparabile. Dacă noua cale folosește un compilator mai nou, o distribuție diferită a datelor de intrare sau o țintă diferită de calitate, rezultatul poate fi în continuare interesant, dar comparația nu mai este curată. Spuneți ce s-a schimbat. Cititorul poate decide atunci dacă diferența este utilă.

Alegerea liniei de bază este un act de interpretare. Comparați cu soluția consacrată pe care utilizatorii o rulează efectiv, cu o implementare de referință, cu o versiune anterioară sau cu o limită teoretică și veți afla lucruri diferite. Un sistem nou poate fi mai bun decât referința și mai slab decât serviciul pe care îl înlocuiește. Poate fi mai rapid într-un test curat și mai lent odată ce validarea și stocarea sunt incluse. Benchmark-ul ar trebui să numească linia de bază și să explice de ce răspunde întrebării operaționale.

Rulările pereche sunt adesea mai informative decât o singură victorie anunțată. Mențineți fixe volumul de lucru și definiția evaluării, schimbați un singur factor material și înregistrați diferența. Dacă mai mulți factori se schimbă simultan, descrieți comparația ca un pachet, nu atribuiți întregul efect unei singure componente. Acest lucru pare evident până când o actualizare, o reîmprospătare a datelor și o nouă politică de cache ajung în aceeași versiune. Graficul are atunci o singură săgeată și trei cauze posibile, un mic mister pentru care nimeni nu a bugetat.

O linie de bază are și un termen de valabilitate. Un flux de date, un furnizor, un model, o politică sau o platformă hardware se pot schimba. Comparația rămâne valabilă pentru versiunile și perioada testate. Nu ar trebui reutilizată ca o garanție actuală fără verificarea contractului. Aici istoricul versiunilor își dovedește utilitatea. Un rezultat depășit nu este un eșec. Este o afirmație istorică ale cărei condiții ar trebui să rămână vizibile.

Incertitudinea nu este o scuză

Fiecare măsurătoare conține variație. O parte din variație provine din sistem, o parte din volumul de lucru și o parte din procesul de măsurare. Rulările repetate o pot evidenția, dar repetiția singură nu explică cauza. Un cache încălzit poate fi stabil. Un vecin zgomotos poate să nu fie. Un set mic de evaluare poate produce o gamă largă de rezultate plauzibile. Un set mai mare poate reduce zgomotul de eșantionare, lăsând însă neatinsă o populație părtinitoare. Incertitudinea îi spune cititorului cât de departe poate călători în siguranță rezultatul.

Raportați incertitudinea într-o formă potrivită afirmației. Poate fi o gamă de valori din rulări repetate, un interval de încredere, o eroare standard, o distribuție a latenței, o analiză de sensibilitate sau o listă de limite cunoscute. Nu adăugați un interval de încredere doar pentru că tabelul pare gol. Precizați ce a fost repetat, ce a fost menținut fix și ce reprezintă și ce nu reprezintă intervalul. Limbajul statistic nu este o vrajă. Este un contract despre variație.

Există un al doilea tip de incertitudine pe care numerele nu îl pot elimina: incertitudinea dacă măsurătoarea reprezintă serviciul vizat. Un rezultat poate avea o variație minusculă de la o rulare la alta și o acoperire slabă în lumea reală. Un benchmark poate fi perfect reproductibil într-un laborator, dar poate rata limbile, formatele de intrare, modelele de schimburi sau consecințele defecțiunilor din implementare. Zgomotul mic de măsurare nu creează validitate. Face doar ca întrebarea greșită să primească un răspuns mai consecvent.

Incertitudinea ar trebui, așadar, să stea alături de afirmație, nu într-o notă de subsol. Dacă un prag este aproape de limita măsurată, acest lucru contează. Dacă un rezultat se schimbă semnificativ în funcție de amestecul de date de intrare, acest lucru contează. Dacă limita energetică exclude răcirea sau transferul de date, acest lucru contează. Propoziția onestă poate fi mai puțin triumfală, dar oferă celui care ia decizii ceva mai bun decât optimismul: un loc pentru prudență.

Reproducerea este un lanț, nu un buton de descărcare

Reproductibilitatea este adesea redusă la publicarea codului. Codul contează. Este doar o verigă din lanț. O a doua parte are nevoie și de volumul de lucru sau de o descriere legală a acestuia, de versiunea datelor, de configurație, de mediu, de comanda sau de cadrul de execuție, de politica privind starea aleatorie, de regula pentru rezultatul așteptat, de fișierul cu rezultate și de metoda folosită pentru a decide dacă execuția corespunde. Dacă lipsește o verigă, a doua parte poate reproduce un experiment similar, nu pe cel raportat.

Lanțul ar trebui să distingă reluarea exactă de replicarea independentă. Reluarea exactă folosește artefactul capturat, starea, datele de intrare, configurația și calea de execuție pentru a verifica dacă aceeași execuție poate fi reconstruită. Replicarea independentă folosește un mediu pregătit separat pentru a testa dacă rezultatul supraviețuiește în afara mașinii sau echipei originale. Ambele sunt valoroase. Ele răspund la întrebări diferite. Un rezultat identic byte cu byte pe o intrare capturată dovedește o afirmație puternică de identitate pentru acea execuție. Nu dovedește că lumea reală va rămâne neschimbată.

Cadrul de evaluare al OECD face această distincție mai ușor de văzut, tratând scopul, realismul, acoperirea și fiabilitatea ca fațete separate. O evaluare poate fi excelentă pentru testarea regresiei și slabă pentru estimarea performanței unui serviciu live. Poate fi utilă pentru cercetare și nepotrivită pentru conformitate. Reproducerea nu șterge scopul. Ea ajută cititorul să verifice afirmația pe care metoda o susține efectiv.

Pentru datele care nu pot fi publicate, publicați limita și traseul. Descrieți populația, procesul de eșantionare, metoda de etichetare, regulile de excludere și verificările de validare. Oferiți un pachet de reproducere sigur atunci când este posibil și explicați ce rămâne protejat. „Datele sunt confidențiale” este o limită legitimă, nu o metodă finalizată. Un cititor ar trebui să poată înțelege totuși ce a fost măsurat și de ce rezultatul ar trebui sau nu generalizat.

Reproducerea nu este un buton etichetat „rulează din nou”. Este un lanț de identități care permite altei echipe să conteste afirmația.

Instituțiile publice ar trebui să refuze teatrul demonstrativ

Instituțiile publice nu trebuie să respingă reperele de evaluare. Ele trebuie să refuze reperele care nu își pot preciza contractul. O demonstrație lustruită poate ajuta un comitet să înțeleagă o posibilitate. Nu poate înlocui dovezile despre serviciul pe care instituția trebuie să îl opereze, despre oamenii cărora li se adresează și despre eșecurile pe care trebuie să le repare. Distincția contează pentru că o demonstrație este optimizată pentru o întâlnire scurtă, în timp ce un serviciu public este judecat de-a lungul anotimpurilor, schimbărilor de personal, contestațiilor, mentenanței și legislației.

Înainte de achiziție, cereți furnizorului să definească volumul de lucru în limbajul serviciului. Ce intră în sistem? Ce se măsoară? Ce este exclus? Ce regulă de calitate trebuie respectată? Ce rol uman revizuiește un rezultat? Cum este depistată derivarea? Cum poate instituția să își exporte dovezile? Ce se întâmplă când se schimbă modelul, sursa, furnizorul sau politica? Față de ce versiune se face comparația? Care este calea de revenire? Un furnizor poate răspunde la unele întrebări printr-un contract, la altele printr-un test, iar la altele printr-o limită onestă. Acest amestec este mai sănătos decât un răspuns compus în întregime din adjective.

Regulamentul UE privind inteligența artificială exprimă acest punct în limbaj juridic pentru sistemele cu risc ridicat. Articolul 15 impune un nivel adecvat de acuratețe, robustețe și securitate cibernetică, cu performanță consecventă în aceste privințe pe tot parcursul ciclului de viață. Un reper de evaluare nu poate stabili singur întreaga obligație legală. Poate susține o parte din dovezi dacă scopul, condițiile de calitate și poziția în ciclul de viață sunt clare. Tratarea unui singur scor drept conformitate ar fi o altă eroare de numitor. Legea numește rezultatul; ingineria trebuie să arate calea.

Achiziția ar trebui să întrebe și cine deține reperul de evaluare după atribuire. Un test pregătit de un furnizor poate fi util, dar instituția are nevoie de suficiente informații pentru a monitoriza sistemul în propriul context. Are nevoie de o linie de bază care poate fi rulată din nou când se schimbă o versiune, de o cale de revizuire când rezultatele se modifică și de o evidență a deciziilor luate cu privire la performanța acceptabilă. Altfel, primul reper este un examen de admitere, iar sistemului de producție i se permite să absolve fără alte întrebări.

Faceți cardul de reper suficient de mic pentru a fi folosit

Metodele lungi pot fi necesare. Nu sunt întotdeauna primul lucru de care are nevoie un cititor. Un card de reper este un index compact al contractului. Poate sta lângă un rezultat într-un raport, un registru de evaluare sau un dosar de achiziție. Cardul ar trebui să numească întrebarea, volumul de lucru, domeniul de aplicare, sistemul, metrica, cerința de calitate, linia de bază, incertitudinea, calea de reproducere, deținătorul și declanșatorul de expirare sau modificare. Metoda detaliată poate sta în spatele lui. Cardul împiedică afirmația să călătorească singură.

Cardurile bune sunt selective, nu aglomerate. Ele scot în evidență câmpurile care pot schimba interpretarea, apoi fac legătura cu pachetul de dovezi. Un card de latență ar putea scoate în evidență dimensiunea intrării, concurența, percentila, încălzirea, versiunea și regula de timeout. Un card de energie ar putea scoate în evidență limita sistemului, volumul de lucru, instrumentul de măsurare, durata și infrastructura exclusă. Un card de acuratețe ar putea scoate în evidență populația, regula de etichetare, agregarea, tratamentul abținerii și severitatea erorii. Forma comună nu este un șablon fix. Este o promisiune că cititorul poate găsi numitorul.

Cardul ar trebui să marcheze statutul epistemic. Valoarea este măsurată, estimată, așteptată, propusă sau ilustrativă? Linia de bază este actuală? Suita de evaluare este pregătită, dar nu a fost încă rulată? Rezultatele sunt protejate pentru că materialul de test conține date personale? Aceste etichete împiedică o metodă să fie confundată cu un rezultat. Ele permit, de asemenea, unei organizații să publice progrese fără să fabrice succes. Un test pregătit este o informație utilă. Nu este o dovadă că sistemul l-a promovat.

În cele din urmă, dă cardului un proprietar și o regulă de modificare. Un rezultat fără proprietar decade într-un slide. Un rezultat fără regulă de modificare rămâne pe perete după ce volumul de lucru s-a mutat. Proprietarul nu trebuie să apere numărul la nesfârșit. Dar trebuie să spună când afirmația ar trebui rerulată, retrasă sau restrânsă. Măsurarea devine parte a operațiunilor atunci când cineva are autoritatea să o mențină onestă.

Două moduri oneste de a publica un rezultat

Există două moduri comune de publicare. Primul este o comparație strictă. Fixează sarcina, datele, regula de calitate, limita sistemului și linia de bază, astfel încât un cititor să poată compara alternativele. Al doilea este o măsurare exploratorie. Întreabă ce se întâmplă atunci când se schimbă un design, un volum de lucru sau un mediu și raportează observațiile cu limitele lor. Munca exploratorie poate fi valoroasă înainte de a exista un benchmark strict. Nu ar trebui să împrumute limbajul unui rezultat de conformitate.

Comparațiile stricte sunt exigente pentru că fac diferențele vizibile. Dacă o echipă schimbă modelul și hardware-ul împreună, poate fi imposibil să atribuie rezultatul. Dacă un nou volum de lucru este mai realist, dar nu se mai potrivește cu linia de bază, afirmația ar trebui reformulată ca o nouă măsurare. Dacă o optimizare îmbunătățește viteza, dar schimbă calitatea rezultatului, raportează ambele părți. Disciplina nu este de a împiedica progresul. Este de a împiedica o poveste despre progres să șteargă condiția care l-a făcut posibil.

Măsurările exploratorii au nevoie de propria lor onestitate. Spune că eșantionul este mic, că mediul este provizoriu, că volumul de lucru este sintetic, că rezultatul nu a fost replicat independent sau că verificarea calității este incompletă. Acestea nu sunt slăbiciuni de ascuns până la o lansare lustruită. Sunt informațiile care ajută un cititor să decidă ce să facă mai departe. O cultură inginerească europeană nu trebuie să pretindă că fiecare test este un verdict final. Trebuie să înceteze să numească o întrebare rezolvată înainte ca testul să fi fost citit.

Ambele moduri beneficiază de o arhivă de rezultate. Păstrează definițiile, configurațiile și rezultatele vechi identificabile. Înregistrează înlocuirea, nu șterge trecutul. Un benchmark schimbat poate fi benchmark-ul potrivit pentru un serviciu schimbat, dar nu poate fi folosit pentru a rescrie sensul rezultatului vechi. Istoricul versiunilor este memoria numitorului.

Nota noastră scurtă

La Dweve, descriem Core cu o celulă de execuție și un contract de determinism. Partea utilă a acestui vocabular nu este numele produsului. Este insistența că o operațiune își poartă reprezentarea numerică, backend-ul, setul de instrucțiuni, politica de dispatch și postura de replay ca parte a căii evaluate. Acesta este același obicei de care are nevoie un benchmark: păstrează condițiile atașate rezultatului, în loc să descrii performanța ca și cum ar pluti deasupra sistemului.

Aceasta este o notă de design scurtă, nu o afirmație despre o implementare externă sau un rezultat măsurat. Lecția mai largă nu depinde de Dweve. Fie că sistemul este un serviciu statistic public, un controler industrial, un instrument lingvistic sau un prototip de cercetare, un număr câștigă încredere numindu-și munca și limitele. Documentația noastră este pur și simplu un loc unde încercăm să facem acea graniță explicită.

Numitorul este partea care călătorește

Un titlu de benchmark este ușor de copiat. Numitorul este mai greu de transportat, motiv pentru care este adesea lăsat în urmă. Un cumpărător copiază o cifră de throughput într-un caz de afaceri. Un regulator vede un scor de acuratețe într-un dosar. Un inginer compară două grafice din volume de lucru diferite. Un jurnalist repetă un procent fără populația de referință. Fiecare cititor primește un număr care a pierdut contractul care îl făcea semnificativ.

Reparația nu este complicată, deși cere disciplină. Numește întrebarea. Definește munca. Precizează domeniul de aplicare și excluderile. Identifică sistemul și versiunile. Alege o metrică potrivită serviciului. Păstrează o valoare de referință. Măsoară variația. Publică metoda și dovezile. Marchează ce rămâne necunoscut. Atribuie o persoană responsabilă și un motiv de rerulare pentru afirmație. Dacă rezultatul nu poate susține o afirmație amplă, restrânge afirmația.

Astfel poate Europa rezista teatrului demonstrativ fără să devină alergică la ambiție. O instituție publică poate achiziționa noi capacități și totuși poate cere un benchmark care respectă serviciul. O echipă de cercetare poate publica un rezultat interesant și totuși poate preciza volumul de muncă ce l-a produs. Un furnizor poate arăta o cale rapidă și totuși poate spune unde se oprește acea cale. Un domeniu de aplicare onest nu este o frână pentru inovație. Este suprafața drumului care permite oricui altcuiva să conducă.

Benchmark-ul este un contract cu un numitor, deoarece numitorul ne spune ce s-a făcut efectiv. Ține-l lângă număr. Rezultatul va deveni mai puțin magic, mai comparabil și mult mai util. Acesta este un schimb echitabil. Sistemele de care oamenii trebuie să depindă merită numere care pot supraviețui unei lecturi atente.

Când o metrică călătorește între lumi

Numerele de benchmark părăsesc adesea echipa care le-a măsurat și intră într-un alt sistem decizional. Un cercetător publică un tabel. O echipă de produs transformă un rând într-o țintă. Achizițiile transformă ținta într-un contract. Operațiunile transformă contractul într-o așteptare privind nivelul serviciului. Fiecare mutare schimbă ceea ce i se cere numărului. Numitorul original poate fi încă prezent în lucrare sau în depozit, dar a devenit social distant de decizie. O metrică are nevoie de o notă de traducere ori de câte ori traversează această graniță.

Nota de traducere poate fi simplă. Acest rezultat se referă la debitul componentelor, nu la cazuri finalizate. Această cifră de acuratețe folosește un set fix de etichete, nu rezultate în timp real. Această valoare energetică exclude limita de răcire a centrului de date. Această valoare de referință este o implementare de referință, nu serviciul existent. Aceste propoziții împiedică o măsurătoare utilă să devină o promisiune înșelătoare. Ele fac și dezacordul mai ușor. Un cititor poate contesta granița, în loc să se certe dacă numărul pare impresionant.

Echipe diferite pot alege în mod deliberat numitori diferiți. O echipă de platformă poate fi interesată de munca per joule. Un proprietar de serviciu poate fi interesat de deciziile finalizate per oră de personal. O autoritate publică poate fi interesată de rezultate corecte și explicabile pentru o populație definită și de timpul de răspuns. Acestea nu sunt adevăruri concurente dacă fiecare este numit. Problemele încep când numitorul cel mai ușor este lăsat să reprezinte misiunea. Cel mai rapid nucleu nu face automat cel mai bun serviciu, la fel cum cel mai mare set de testare nu face automat cel mai relevant.

Înainte de a reutiliza un benchmark, întreabă ce s-a schimbat: volumul de muncă, proprietarul, consecința sau orizontul de timp. Dacă oricare dintre acestea s-a schimbat, refă interpretarea chiar dacă numărul de bază este neschimbat. Măsurarea nu este o relicvă de purtat între încăperi. Este o relație care trebuie reînnoită atunci când încăperea se schimbă.

Un rezultat ar trebui să știe când să expire

Rezultatele au o durată de viață utilă. Un benchmark legat de o versiune de model, un instantaneu al sursei sau o configurație hardware devine istoric atunci când aceste condiții se schimbă. Asta nu face vechiul rezultat fals. Schimbă întrebarea la care poate răspunde. Raportul ar trebui să spună ce eveniment face afirmația învechită: un model nou, un compilator modificat, o nouă distribuție a datelor, o regulă de etichetare revizuită, o înlocuire hardware, o schimbare de politică sau un semnal de derivă observat. O regulă de expirare este o mică piesă de memorie instituțională.

Fără o regulă de expirare, numerele se acumulează precum hainele pe un scaun. Fiecare este, tehnic vorbind, încă acolo, și nimeni nu știe care dintre ele aparține zilei de azi. Un registru de rezultate poate păstra istoricul complet, marcând în același timp comparația curentă, definiția înlocuită și motivul pentru care s-a reluat rularea. Actul de a relua rularea devine astfel o întreținere obișnuită, nu un răspuns la o criză. Acest lucru este deosebit de important pentru serviciile publice, unde un rezultat poate supraviețui echipei care l-a produs.

Expirarea protejează și progresul onest. Dacă o nouă sarcină de lucru relevă că un benchmark anterior era prea restrâns, organizația poate publica modificarea, păstra metoda veche și explica noua limită. Nu trebuie să apere un număr învechit sau să pretindă că numărul vechi nu a existat niciodată. Un benchmark care poate fi restrâns, înlocuit și înțeles este mai util decât unul care trebuie să rămână impresionant pentru totdeauna.

Surse