Benchmark je smlouva se jmenovatelem
Číslo, které zapomnělo svůj jmenovatel
Výsledek benchmarku může být změřen správně, a přesto odpovídat na špatnou otázku. Obvyklým viníkem není vadný časovač ani nepoctivý inženýr. Je to jmenovatel, který se ztratil mezi testovacím prostředím a prezentačním snímkem. „Dvakrát rychlejší“ zní jako srovnání, ale neříká, dvakrát rychlejší při jaké práci, na kterém stroji, s jakým softwarem, za jaké kvalitativní podmínky, proti jaké základní linii nebo pro které uživatele. Odstraňte tyto podmínky a z výkonnostního čísla se stane vyleštěný úlomek. Může zůstat numericky pravdivé. Už ale kupujícímu ani provozovateli neřekne, co mohou očekávat.
Jmenovatel je práce, vůči níž je výsledek vyjádřen. U propustnosti je to dokončená práce a čas, za který se dokončení počítá. U latence je to definice požadavku, zahrnutá cesta a soubor pozorování. U přesnosti je to označená množina, pravidlo označování a hodnocená jednotka. U energie je to hranice měřeného systému a práce dodaná uvnitř této hranice. U nákladů je to období nákladů, zahrnuté zdroje a objem užitečné práce. Benchmark je poctivý, když jeho čitatel a jmenovatel cestují společně.
Proto je nejlepší zacházet s benchmarkem jako se smlouvou. Smlouva pojmenovává otázku, pracovní zátěž, rozsah, hardware a software, metriku, základní linii, nejistotu a metodu, kterou může jiná strana výsledek ověřit. Smlouva může být úzká. Může být průzkumná. Může být užitečná pouze pro jedno nasazení. Co být nemůže, je působivé číslo, jehož podmínky necháme na čtenářově hádání. Hádání je špatný způsob přidělování veřejných peněz a ještě horší způsob navrhování služby, kterou musí někdo jiný udržovat při životě.
Evropský zvyk zapisovat definice je občas zesměšňován jako papírování. V měřicí práci jsou definice tím, co brání tomu, aby se z papírování stala folklór. Tabulka benchmarku není administrativní přílohou výsledku. Je to jeho identifikační průkaz.
Přečtěte si jednotku dřív než titulek
Začněte jednotkou, ale nezůstávejte u ní. Požadavky za sekundu, tokeny za sekundu, milisekundy, jouly na dotaz, eura za tisíc záznamů a procentní body vám něco řeknou. Žádná z nich vám neřekne, co bylo po systému žádáno. Výsledek 100 požadavků za sekundu může popisovat malé požadavky z mezipaměti nebo velké požadavky bez mezipaměti, které zahrnují vyhledávání, validaci a lidské předání. Latence 20 milisekund může pokrývat jediné jádro nebo celou rozhodovací cestu. Jednotka jsou dveře. Pracovní zátěž je místnost za nimi.
Předpokládejme, že nákupní snímek říká, že nová služba je o 40 procent rychlejší než stávající. Tato věta ještě není důkaz. Potřebuje přinejmenším měřenou operaci, velikost a rozložení vstupu, práci vyloučenou z měření, souběžnost, stav zahřátí, verze softwaru, hardware a základní konfiguraci. Potřebuje také kvalitativní podmínku. Pokud rychlejší cesta vrací méně platných výsledků, zahazuje dlouhé vstupy nebo přeskočí nákladný ověřovací krok, byl čitatel zmenšen změnou práce.
Toto není žádost o obrovskou tabulku, než někdo promluví. Je to žádost o identifikaci několika polí, která mění význam tvrzení. Malý benchmark parseru může potřebovat tvar záznamu, zdroj vstupu, politiku validace, kompilátor a procesor. Benchmark inference může potřebovat model, přesnost, dávku, scénář, cílovou kvalitu a hranici napájení. Fronta ve veřejném sektoru může potřebovat definici případu, servisní hodiny, pravidlo směrování a cestu eskalace. Pole se liší. Povinnost je pojmenovat se neliší.
Je tu užitečná disciplína: zapsat výsledek jako větu, která přežije druhého čtenáře. „Při tomto pracovním zatížení a tomto požadavku na kvalitu, na tomto systému a verzi byla naměřená hodnota tato, s touto odchylkou.“ Pokud větu nelze dokončit bez slov jako typický, nejlepší, produkční nebo reprezentativní, metoda není hotová. Tato slova mohou být platná, ale potřebují operační definici, ne vřelý tón.
Rozsah je součástí výsledku
Rozsah odpovídá na prostou otázku: co tento výsledek pokrývá a co nechává mimo rámec? Při vyhodnocování strojového učení rozsah zahrnuje úlohu, datovou sadu, rozdělení, jazyk, délku vstupu, provozní scénář a povolené implementační volby. U softwarové služby zahrnuje trasu, datová úložiště, síť, mezipaměť a práci, kterou navazující tým vykoná poté, co měřený koncový bod vrátí odpověď. Výsledek naměřený na jedné vrstvě by se neměl tiše stát slibem o celé službě.
MLCommons to zviditelňuje ve své dokumentaci k MLPerf Inference. Průvodce podáváním výsledků odděluje typy systémů pro datacentra a pro okraj, uvádí scénáře jako offline, server, interaktivní, single-stream a multi-stream a rozlišuje uzavřenou divizi od otevřené. Uzavřená divize je určena pro srovnání jablek s jablky za použití stejného modelu a referenčního nastavení. Otevřená divize umožňuje volby jako přetrénování nebo náhradu modelu. Ani jedna není univerzálně správná divize. Odpovídají na různé otázky. Titulek, který je smíchá, není široký pohled. Je to kategoriální chyba s vynikající typografií.
Stejná dokumentace ukazuje, proč benchmark potřebuje explicitní stránku kvality. Uvedená položka ResNet50 jmenuje validační sadu ImageNet-2012, její velikost datové sady a seznamu vzorků dotazů, referenční přesnost a omezení latence serveru. U uvedené položky ResNet50 stránka uvádí validační sadu o 50 000 obrázcích, seznam vzorků dotazů o 1 024 položkách, referenční přesnost 76,46 procenta a omezení latence serveru 15 ms. Tato pole nejsou zajímavosti pro lidi, kteří si rádi čtou pravidla. Vysvětlují, co směla uváděná rychlost znamenat. Změňte datovou sadu, scénář nebo požadavek na kvalitu a srovnání se změnilo, i když název modelu vypadá povědomě.
Evropský kupující by měl být podezřívavý k rozsahu, který naznačuje štítek produktu. „AI platforma“, „akcelerátor“ a „enterprise-grade“ nedefinují práci. Systém, který je vynikající v ohraničené operaci, může být přesně to, co služba potřebuje. Systém, který tvrdí, že pokrývá vše, mohl naměřit téměř nic, co se službě podobá. Úzká pravda je zdravější než univerzální mlha.
Pokrytí mění význam
Pokrytí není poznámka pod čarou o tom, zda byla testovací sada dostatečně velká. Popisuje, čí případy a které situace vstupují do měření. Benchmark může pokrývat mnoho příkladů z jedné úzké distribuce a přesto říci málo o okrajových případech, které jsou v provozu důležité. Naopak malá, pečlivě vybraná sada může odhalit důležitý způsob selhání, aniž by podporovala obecné tvrzení o výkonu. Volba je rozhodnutím o návrhu. Musí být jako taková uvedena.
Rámec OECD pro charakterizaci nástrojů pro hodnocení umělé inteligence je užitečný, protože odmítá redukovat hodnocení na jedno skóre. Navrhuje 18 aspektů, včetně pokrytí, účelu, realističnosti, validity, spolehlivosti, transparentnosti a podmínek, za kterých lze výsledky interpretovat. Pokrytí se ptá, zda hodnocení představuje to, co má měřit. Účel rozlišuje benchmark určený pro výzkum od benchmarku určeného pro posuzování shody nebo jiné použití. Realističnost se ptá, zda se jedná o triviální problém, simulované či laboratorní prostředí, nebo reálný život. Tato rozlišení benchmark neoslabují. Činí jeho tvrzení čitelným.
Pokrytí zahrnuje také případy, které hodnocení vylučuje. Služba může vykazovat průměrnou latenci po odstranění časových limitů. Klasifikátor může vykazovat přesnost po vyřazení nejednoznačných štítků. Vyhledávací systém může počítat pouze dotazy s alespoň jedním relevantním dokumentem. Obrazová pipeline může přeskočit poškozené soubory. Každé vyloučení může být obhajitelné. Výsledek musí říci, co bylo odstraněno a proč. Jinak se jmenovatel tiše stane seznamem případů, které bylo vhodné dokončit.
Zde se jmenovatel stává politickým, ještě než někdo použije slovo politika. Zahrnutá populace získává výhodu toho, že je měřena. Vyloučená populace získává příběh o systému, který ji nemusí popisovat. Evropské veřejné instituce to již znají z oficiálních statistik. Kodex evropské statistiky Eurostatu stanoví 16 zásad a 84 ukazatelů pro institucionální prostředí, procesy a výstupy. Jeho Rámec zabezpečování kvality poskytuje metody a nástroje, zatímco zprávy o kvalitě uživatelům sdělují, jak byla data shromážděna a validována. Poselství pro umělou inteligenci není, že každý model se musí stát statistickým úřadem. Je jím, že číslo určené pro veřejná rozhodnutí potřebuje viditelný příběh o produkci a kvalitě.
Přesnost není jedna brána
Tvrzení o výkonu často spojují rychlost s jediným číslem kvality a pak tuto dvojici považují za úplnou. Kvalita je obvykle rodinou otázek. Splňuje výstup definici úkolu? Zachovává požadovaná omezení? Selže bezpečně, když chybí důkazy? Chová se přijatelně napříč relevantní populací? Zůstává v mezích kvality, zatímco je systém zatížen? Rychlá odpověď, která nesplní úkol, není rychlejším řešením. Je to jiná zátěž pod stejným názvem.
Struktura MLPerf je poučná, protože jeho měření výkonu stojí vedle validace přesnosti a požadavků specifických pro model. Průvodce pro podávání příspěvků říká účastníkům, aby identifikovali divizi, typ systému a scénář, spustili zamýšlený benchmark, validovali přesnost proti prahům a poté připravili zkontrolovaný příspěvek. Stránka benchmarku uvádí referenční přesnost a podmínky latence nebo propustnosti pro každý úkol. Toto oddělení je praktické. Zabraňuje tomu, aby systém vyhrál sloupec výkonu tím, že tiše prohrál úkol.
Přesnost sama o sobě potřebuje jmenovatele. „Devadesát osm procent přesnosti“ může znamenat procento záznamů, tokenů, obrázků, požadavků nebo rozhodnutí. Může používat mikro nebo makro průměrování. Může počítat zdržení se hlasování jako chybu, jako bezpečné odmítnutí nebo jako neměřený výsledek. Může porovnávat se štítky vytvořenými jedním nebo několika recenzenty. Karta benchmarku by měla uvést jednotku, pravidlo pro štítky, agregaci, spolehlivost nebo variabilitu a jakýkoli práh, který mění měření v rozhodnutí o vydání.
Nepoužívejte číslo kvality jako ozdobné potvrzení o způsobilosti. Model může splnit zveřejněnou hranici a přesto být nevhodný pro konkrétní službu, protože se liší úloha, populace nebo profil škod. Naopak nižší celkové skóre může být přijatelné pro nástroj pro tvorbu návrhů, kde zůstává autorem člověk, zatímco stejné skóre je nepřijatelné pro automatickou bránu. Kvalita je vztah mezi výstupem, účelem a důsledkem.
Čas není jedno číslo
Latence se často prezentuje, jako by systém měl jedinou rychlost. Skutečné systémy mají rozdělení. První požadavek může zaplatit náklady na spuštění. Mezipaměť může změnit pozdější požadavky. Souběžní uživatelé si mohou konkurovat o paměť nebo databázové připojení. Dlouhý vstup se může vydat jinou cestou než krátký. Průměr se může zlepšit, zatímco konec rozdělení se zhorší. Pokud je konec rozdělení místem, kde služba nestíhá svůj termín, je průměr rozptýlením s jednotkou.
Užitečná zpráva o latenci uvádí, co bylo měřeno a jak byla pozorování shrnuta. Může obsahovat medián, horní percentily, míru časových limitů a počet požadavků. Měla by uvést, zda byly vyloučeny zahřívací požadavky, zda byly zahrnuty opakované pokusy a zda čas čekání ve frontě nebo síťový čas patří do měřené cesty. Tyto volby nejsou zaměnitelné. Srovnávací test komponenty může být cenný, ale nesmí být vyprávěn jako chování celého systému od konce ke konci.
Propustnost má podobnou past. Vysoké rychlosti lze dosáhnout dávkováním práce, zvyšováním souběžnosti nebo uvolněním požadavku na kvalitu. To může být přesně správné pro offline úlohu. Může to být k ničemu pro interaktivní službu, která musí odpovědět na každý požadavek v rámci termínu. Srovnávací test by měl uvést scénář a provozní bod a poté vysvětlit, co by se stalo, kdyby se poptávka od něj vzdálila. Na úzkém provozním bodu není nic hanebného. Hanebné je předstírat, že je celou mapou.
Čas má také lidskou stránku. Služba, která odpovídá rychle, ale vytváří více práce na přezkoumání, opravu nebo odvolání, může být z pohledu instituce pomalejší. Srovnávací test, který zastaví hodiny před předáním, může způsobit, že měřený systém vypadá svižně, zatímco skutečná služba hromadí frontu. Jmenovatel by měl sledovat práci, dokud není zodpovězena položená otázka. Jinak stopky měří ostrov.
Hardware a software jsou součástí čitatele
„Na serveru“ není reprodukovatelné prostředí. Generace procesoru, sada instrukcí, akcelerátor, paměť, úložiště, tepelný stav, napájecí limit, operační systém, ovladač, kompilátor, běhové prostředí, knihovna a konfigurace mohou všechny změnit výsledek. Stejně tak formát modelu, nastavení kvantizace, velikost dávky, výběr jádra nebo politika vláken. Srovnávací test nemusí vyjmenovat každý kabel. Musí identifikovat části, které mohou změnit měření.
MLPerf nazývá kompletní měřené nastavení testovaným systémem a organizuje výsledky podle typu systému a kategorie dostupnosti. Tato slovní zásoba je užitečná i mimo MLPerf. Testovaný systém má hranici. Hranice říká, který hardware a software jsou zahrnuty, které služby jsou externí a která práce je vynechána. Hodnota výkonu měřená u zásuvky má jiný význam než hodnota, která počítá pouze akcelerátor. Latence měřená uvnitř jádra má jiný význam než ta, která zahrnuje plánování požadavků.
Verze jsou důležité, protože srovnávací test je srovnáním napříč stavy, nikoli nadčasovou vlastností názvu produktu. Zaznamenejte verzi modelu nebo aplikace, verze závislostí, příznaky kompilátoru, ovladač a firmware tam, kde ovlivňují výsledek. Zaznamenejte konfiguraci, která vybrala backend nebo přesnost. Pokud běhové prostředí zvolí na jiném počítači jiné jádro, je to součást výsledku, nikoli detail implementace, který se má později uklidit.
Zveřejnění informací o hardwaru není pozvánkou k tomu, aby se z příspěvku na blogu stal katalog součástek. Je to způsob, jak zabránit falešné ekvivalenci. Kupující se nemusí zajímat o každou instrukci, pokud se tvrzení týká kompletní služby. Musí ale vědět, zda srovnání zahrnuje stejnou práci, stejnou přesnost, stejnou vstupní cestu a systém, který lze skutečně získat a provozovat v zamýšleném evropském prostředí.
Baselines jsou sliby
Baseline je srovnání, které dává výsledku směr. Bez něj může číslo popisovat systém, ale ne zlepšení. Baseline musí odpovídat na stejnou otázku za srovnatelných podmínek. Pokud nová cesta používá novější kompilátor, jiné rozložení vstupů nebo jiný cíl kvality, výsledek může být stále zajímavý, ale srovnání už není čisté. Řekněte, co se změnilo. Čtenář se pak může rozhodnout, zda je rozdíl užitečný.
Volba baseline je akt interpretace. Srovnávejte se stávajícím řešením, které uživatelé skutečně používají, s referenční implementací, s předchozí verzí nebo s teoretickým limitem, a dozvíte se různé věci. Nový systém může být lepší než reference a horší než služba, kterou nahrazuje. Může být rychlejší v čistém testu a pomalejší, jakmile se započítá validace a úložiště. Benchmark by měl baseline pojmenovat a vysvětlit, proč odpovídá na provozní otázku.
Párové běhy jsou často informativnější než jediné vítězné kolo. Ponechte pracovní zátěž a definici vyhodnocení beze změny, změňte jeden podstatný faktor a zaznamenejte rozdíl. Pokud se mění několik faktorů najednou, popište srovnání jako celek, nepřipisujte celý efekt jedné součásti. To zní samozřejmě, dokud se ve stejné verzi neobjeví upgrade, obnovení dat a nová politika cache. Graf pak má jednu šipku a tři možné příčiny, což je malá záhada, na kterou nikdo nerozpočítal.
Baseline má také omezenou životnost. Datový zdroj, dodavatel, model, politika nebo hardwarová platforma se mohou změnit. Srovnání zůstává platné pro testované verze a období. Nemělo by být znovu používáno jako aktuální záruka bez kontroly smlouvy. Tady si verze historie zaslouží své místo. Překonaný výsledek není selhání. Je to historické tvrzení, jehož podmínky by měly zůstat viditelné.
Nejistota není omluva
Každé měření obsahuje variabilitu. Část variability pochází ze systému, část z pracovní zátěže a část z procesu měření. Opakované běhy ji mohou odhalit, ale samotné opakování nevysvětlí příčinu. Teplá cache může být stabilní. Hlučný soused nemusí. Malá vyhodnocovací sada může produkovat širokou škálu věrohodných výsledků. Větší sada může snížit vzorkovací šum, ale nechat nedotčenou zkreslenou populaci. Nejistota čtenáři říká, jak daleko lze výsledek bezpečně přenést.
Uvádějte nejistotu ve formě odpovídající tvrzení. Může to být rozsah napříč opakovanými běhy, interval spolehlivosti, standardní chyba, rozložení latence, analýza citlivosti nebo seznam známých omezení. Nepřidávejte interval spolehlivosti jen proto, že tabulka vypadá osaměle. Uveďte, co se opakovalo, co bylo drženo konstantní a co interval představuje a co nepředstavuje. Statistický jazyk není kouzlo. Je to smlouva o variabilitě.
Existuje druhý druh nejistoty, který čísla neodstraní: nejistota ohledně toho, zda měření představuje zamýšlenou službu. Výsledek může mít nepatrnou variabilitu mezi běhy a špatné pokrytí reálného světa. Benchmark může být dokonale reprodukovatelný v laboratoři, ale chybět mu jazyky, formáty vstupů, směny nebo důsledky selhání v nasazení. Nízký šum měření nevytváří platnost. Pouze činí špatnou otázku konzistentněji zodpovězenou.
Nejistota by proto měla stát vedle samotného tvrzení, ne v prohlášení v zápatí. Pokud je hranice blízko naměřené mezi, záleží na tom. Pokud se výsledek zásadně změní při jiném složení vstupů, záleží na tom. Pokud energetická hranice vylučuje chlazení nebo přesun dat, záleží na tom. Upřímná věta může být méně triumfální, ale dává tomu, kdo rozhoduje, něco lepšího než optimismus: místo pro opatrnost.
Reprodukce je řetěz, ne tlačítko ke stažení
Reprodukovatelnost se často redukuje na zveřejnění kódu. Kód je důležitý. Je ale jen jedním článkem řetězu. Druhá strana potřebuje také pracovní zátěž nebo její zákonný popis, verzi dat, konfiguraci, prostředí, příkaz nebo testovací rámec, pravidla pro náhodný stav, pravidlo pro očekávaný výstup, soubor s výsledky a metodu, podle které se rozhodne, zda se běh shoduje. Pokud jeden článek chybí, může druhá strana reprodukovat podobný experiment, ne ten vykázaný.
Řetěz by měl rozlišovat mezi přesným přehráním a nezávislou replikací. Přesné přehrání používá zachycený artefakt, stav, vstupy, konfiguraci a cestu provádění, aby ověřilo, zda lze stejný běh znovu sestavit. Nezávislá replikace používá samostatně připravené prostředí, aby otestovala, zda výsledek přežije mimo původní stroj nebo tým. Obojí je cenné. Odpovídají na různé otázky. Bitově identický výsledek na zachyceném vstupu dokazuje silné tvrzení o totožnosti daného běhu. Nedokazuje, že živý svět zůstane nezměněn.
Hodnotící rámec OECD toto rozlišení usnadňuje tím, že účel, realističnost, pokrytí a spolehlivost považuje za samostatné aspekty. Hodnocení může být vynikající pro regresní testování a špatné pro odhad výkonu živé služby. Může být užitečné pro výzkum a nevhodné pro posouzení shody. Reprodukce nevymaže účel. Pomáhá čtenáři ověřit tvrzení, které metoda skutečně podporuje.
U dat, která nelze zveřejnit, zveřejněte hranici a cestu. Popište populaci, proces vzorkování, metodu označování, pravidla vyloučení a validační kontroly. Pokud je to možné, poskytněte bezpečný balíček pro reprodukci a vysvětlete, co zůstává chráněno. „Data jsou důvěrná“ je legitimní hranice, ne hotová metoda. Čtenář by měl stále být schopen pochopit, co bylo měřeno a proč by se výsledek měl či neměl zobecňovat.
Veřejné instituce by měly odmítnout divadlo ukázek
Veřejné instituce nemusí benchmarky odmítat. Musí odmítat benchmarky, které nedokážou uvést svůj kontrakt. Pečlivě připravená demonstrace může výboru pomoci pochopit možnost. Nemůže ale nahradit důkazy o službě, kterou instituce musí provozovat, o lidech, kterým slouží, a o selháních, která musí napravovat. Tento rozdíl je důležitý, protože demo je optimalizováno na krátké setkání, zatímco veřejná služba je posuzována v průběhu ročních období, personálních změn, odvolání, údržby a práva.
Před nákupem požádejte dodavatele, aby definoval pracovní zátěž jazykem služby. Co do systému vstupuje? Co se měří? Co je vyloučeno? Které pravidlo kvality musí platit? Která lidská role přezkoumává výsledek? Jak se zjišťuje odchylka? Jak může instituce exportovat své důkazy? Co se stane, když se změní model, zdroj, dodavatel nebo politika? Ke které verzi se srovnání vztahuje? Jaká je cesta zpět? Dodavatel může na některé otázky odpovědět smlouvou, na některé testem a na některé upřímným vymezením hranic. Tato směs je zdravější než odpověď složená výhradně z přídavných jmen.
Nařízení EU o umělé inteligenci vyjadřuje tento bod právním jazykem pro systémy s vysokým rizikem. Článek 15 vyžaduje odpovídající úroveň přesnosti, robustnosti a kybernetické bezpečnosti s konzistentním výkonem v těchto ohledech po celou dobu životního cyklu. Benchmark sám o sobě nemůže prokázat celou právní povinnost. Může podpořit část důkazů, pokud jsou jasné jeho rozsah, podmínky kvality a pozice v životním cyklu. Považovat jedno skóre za soulad s předpisy by bylo další chybou ve jmenovateli. Právo pojmenovává výsledek; inženýrství musí ukázat cestu.
Zadávání veřejných zakázek by se také mělo ptát, kdo benchmark vlastní po udělení zakázky. Testovací běh připravený dodavatelem může být užitečný, ale instituce potřebuje dostatek informací, aby mohla systém sledovat ve vlastním kontextu. Potřebuje základní měření, které lze znovu spustit při změně verze, cestu přezkumu, když se výsledky pohybují, a záznam rozhodnutí o přijatelném výkonu. Jinak je první benchmark přijímací zkouškou a produkční systém smí absolvovat bez dalších otázek.
Udělejte kartu benchmarku dostatečně malou pro použití
Dlouhé metody mohou být nezbytné. Nejsou ale vždy první věcí, kterou čtenář potřebuje. Karta benchmarku je kompaktní rejstřík ke kontraktu. Může stát vedle výsledku ve zprávě, registru hodnocení nebo souboru k veřejné zakázce. Karta by měla uvádět otázku, pracovní zátěž, rozsah, systém, metriku, požadavek na kvalitu, základní měření, nejistotu, cestu reprodukce, vlastníka a spouštěč změny nebo expirace. Podrobná metoda může být za ní. Karta brání tomu, aby tvrzení cestovalo samo.
Dobré karty jsou selektivní, ne přeplněné. Vynášejí na povrch pole, která mohou změnit interpretaci, a pak odkazují na balíček důkazů. Karta latence může zdůraznit velikost vstupu, souběžnost, percentil, zahřívání, verzi a pravidlo časového limitu. Karta energie může zdůraznit hranici systému, pracovní zátěž, měřicí přístroj, dobu trvání a vyloučenou infrastrukturu. Karta přesnosti může zdůraznit populaci, pravidlo označování, agregaci, zacházení se zdržením se a závažnost chyb. Společný tvar není pevná šablona. Je to příslib, že čtenář najde jmenovatele.
Karta by měla označovat epistemický status. Je hodnota naměřená, odhadovaná, očekávaná, navrhovaná nebo ilustrativní? Je základní měření aktuální? Je sada hodnocení připravená, ale ještě nespuštěná? Jsou výsledky chráněné, protože testovací materiál obsahuje osobní údaje? Tyto štítky zabraňují tomu, aby byla metoda zaměněna za výsledek. Také organizaci umožňují zveřejňovat pokrok bez vytváření falešného úspěchu. Připravený test je užitečná informace. Není to důkaz, že jím systém prošel.
Nakonec kartě přidělte vlastníka a pravidlo pro změny. Výsledek bez vlastníka se rozpadne na snímek. Výsledek bez pravidla pro změny zůstane na nástěnce i poté, co se pracovní zátěž přesune. Vlastník nemusí číslo bránit navždy. Musí ale říct, kdy se má tvrzení znovu spustit, stáhnout nebo zúžit. Měření se stává součástí provozu, když má někdo pravomoc udržovat ho poctivé.
Dva poctivé způsoby zveřejnění výsledku
Existují dva běžné způsoby publikace. Prvním je přísné srovnání. Stanoví úlohu, data, pravidlo kvality, hranice systému a výchozí stav tak, aby čtenář mohl porovnat alternativy. Druhým je průzkumné měření. Ptá se, co se stane, když se změní návrh, pracovní zátěž nebo prostředí, a zaznamenává pozorování s jejich omezeními. Průzkumná práce může být cenná dříve, než existuje přísný benchmark. Neměla by si však vypůjčovat jazyk výsledku shody.
Přísná srovnání jsou náročná, protože zviditelňují rozdíly. Pokud tým změní model i hardware současně, může být nemožné výsledek přiřadit. Pokud je nová pracovní zátěž realističtější, ale už neodpovídá výchozímu stavu, mělo by být tvrzení přeformulováno jako nové měření. Pokud optimalizace zrychlí výkon, ale změní kvalitu výstupu, uveďte obě strany. Disciplína nemá bránit pokroku. Má zabránit tomu, aby příběh o pokroku vymazal podmínky, které ho umožnily.
Průzkumná měření potřebují vlastní poctivost. Řekněte, že je vzorek malý, že je prostředí provizorní, že je pracovní zátěž syntetická, že výsledek nebyl nezávisle zopakován nebo že kontrola kvality není úplná. To nejsou slabiny, které je třeba skrývat až do vyleštěného vydání. Jsou to informace, které čtenáři pomohou rozhodnout, co dělat dál. Evropská inženýrská kultura nemusí předstírat, že každý test je konečný verdikt. Musí přestat označovat otázku za zodpovězenou dřív, než byl test přečten.
Oběma režimům prospívá archiv výsledků. Uchovávejte staré definice, konfigurace a výsledky identifikovatelné. Zaznamenávejte nahrazení, místo abyste mazali minulost. Změněný benchmark může být správným benchmarkem pro změněnou službu, ale nelze ho použít k přepsání významu starého výsledku. Historie verzí je pamětí jmenovatele.
Naše krátká poznámka
Ve společnosti Dweve popisujeme Core pomocí prováděcí buňky a kontraktu determinismu. Užitečnou částí této slovní zásoby není název produktu. Je to důraz na to, že operace nese svou číselnou reprezentaci, backend, instrukční sadu, pravidla nasazení a postoj k přehrávání jako součást hodnocené cesty. To je stejný návyk, jaký benchmark potřebuje: ponechte podmínky připojené k výsledku, místo abyste popisovali výkon, jako by se vznášel nad systémem.
Toto je krátká designová poznámka, nikoli tvrzení o externím nasazení nebo naměřeném výsledku. Širší ponaučení nezávisí na Dweve. Ať už je systém veřejnou statistickou službou, průmyslovým regulátorem, jazykovým nástrojem nebo výzkumným prototypem, číslo si získává důvěru tím, že pojmenuje svou práci a své limity. Naše vlastní dokumentace je prostě jedním z míst, kde se snažíme tuto hranici učinit explicitní.
Jmenovatel je část, která cestuje
Titulek benchmarku se snadno kopíruje. Jmenovatel se nese hůř, a proto se často nechává za sebou. Kupující zkopíruje číslo propustnosti do obchodního případu. Regulátor vidí skóre přesnosti ve spisu. Inženýr porovnává dva grafy z různých pracovních zátěží. Novinář zopakuje procento bez populace. Každý čtenář dostane číslo, které ztratilo kontrakt, jenž mu dával smysl.
Oprava není složitá, i když vyžaduje disciplínu. Pojmenujte otázku. Definujte práci. Uveďte rozsah a výluky. Identifikujte systém a verze. Zvolte metriku, která odpovídá službě. Udržujte základní hodnotu. Měřte odchylky. Zveřejněte metodu i důkazy. Označte, co zůstává neznámé. Dejte tvrzení vlastníka a důvod, proč ho znovu spustit. Pokud výsledek neunese široké tvrzení, zúžte ho.
Takto může Evropa odolat divadelním ukázkám, aniž by se stala alergickou na ambice. Veřejná instituce může nakoupit nové schopnosti a přesto požadovat benchmark, který respektuje službu. Výzkumný tým může zveřejnit vzrušující výsledek a přesto uvést pracovní zátěž, která jej vytvořila. Dodavatel může ukázat rychlou cestu a přesto říci, kde cesta končí. Poctivě vymezený rozsah není brzdou inovace. Je to povrch vozovky, po kterém může jet kdokoli jiný.
Benchmark je smlouva se jmenovatelem, protože jmenovatel nám říká, co bylo skutečně provedeno. Držte ho vedle čísla. Výsledek bude méně kouzelný, srovnatelnější a mnohem užitečnější. To je spravedlivá výměna. Systémy, na které se lidé musí spolehnout, si zaslouží čísla, která přežijí pomalé čtení.
Když metrika cestuje mezi světy
Čísla z benchmarků často opustí tým, který je změřil, a vstoupí do jiného rozhodovacího systému. Výzkumník zveřejní tabulku. Produktový tým promění jeden řádek v cíl. Nákupní oddělení promění cíl ve smlouvu. Provoz promění smlouvu v očekávání úrovně služeb. Každý krok mění to, co se od čísla očekává. Původní jmenovatel může být stále přítomen v dokumentu nebo repozitáři, ale společensky se vzdálil od rozhodnutí. Metrika potřebuje překladovou poznámku vždy, když překročí tuto hranici.
Překladová poznámka může být prostá. Tento výsledek se týká propustnosti komponent, nikoli dokončených případů. Tento údaj o přesnosti používá pevnou sadu štítků, nikoli živé výsledky. Tato hodnota energie nezahrnuje chlazení datového centra. Tato základní hodnota je referenční implementace, nikoli stávající služba. Tyto věty zastaví proměnu užitečného měření v zavádějící slib. Také usnadňují nesouhlas. Čtenář může zpochybnit hranici, místo aby se dohadoval, zda číslo působí působivě.
Různé týmy mohou záměrně zvolit různé jmenovatele. Platformový tým může sledovat práci na joule. Vlastník služby může sledovat dokončená rozhodnutí za odpracovanou hodinu. Veřejný orgán může sledovat správné a vysvětlitelné výsledky pro definovanou populaci a dobu odezvy. Nejedná se o konkurenční pravdy, pokud je každá z nich pojmenována. Problémy začínají, když nejjednodušší jmenovatel smí zastoupit poslání. Nejrychlejší jádro automaticky nedělá nejlepší službu, stejně jako největší testovací sada automaticky nedělá tu nejrelevantnější.
Než benchmark znovu použijete, zeptejte se, co se změnilo: pracovní zátěž, vlastník, důsledek nebo časový horizont. Pokud se změnilo cokoli z toho, přehodnoťte interpretaci, i když se základní číslo nezměnilo. Měření není relikvie, kterou byste nosili mezi místnostmi. Je to vztah, který je třeba obnovit, když se místnost změní.
Výsledek by měl vědět, kdy vyprší
Výsledky mají omezenou životnost. Benchmark vázaný na verzi modelu, snímek zdroje nebo konfiguraci hardwaru se stává historickým, když se tyto podmínky změní. To nedělá starý výsledek nepravdivým. Mění to otázku, na kterou může odpovědět. Zpráva by měla říci, jaká událost činí tvrzení zastaralým: nový model, změněný kompilátor, nové rozdělení dat, revidované pravidlo štítků, výměna hardwaru, změna politiky nebo pozorovaný signál driftu. Pravidlo vypršení je malý kousek institucionální paměti.
Bez pravidla pro vypršení se čísla hromadí jako kabáty na židli. Každé z nich tam technicky stále je a nikdo neví, které patří dnešku. Registr výsledků může uchovat celou historii a zároveň označit aktuální srovnání, nahrazenou definici a důvod přepracování. Samotné přepracování je pak běžnou údržbou, nikoli reakcí na krizi. To je důležité zejména u veřejných služeb, kde výsledek může přežít tým, který jej vytvořil.
Vypršení také chrání poctivý pokrok. Pokud nová zátěž odhalí, že dřívější benchmark byl příliš úzký, může organizace změnu zveřejnit, zachovat starou metodu a vysvětlit nové hranice. Nemusí bránit zastaralé číslo ani předstírat, že staré číslo nikdy neexistovalo. Benchmark, který lze zúžit, nahradit a pochopit, je užitečnější než ten, který musí zůstat působivý navždy.
Zdroje
- Rámec pro charakterizaci hodnoticích nástrojů výkonnosti umělé inteligence, OECD, AI and the Future of Skills, Volume 2. Byl konzultován rámec kapitoly s 18 aspekty, včetně pokrytí, účelu, realističnosti, validity, spolehlivosti a transparentnosti.
- Konstrukce rámce pro měření schopností umělé inteligence, OECD, AI and the Future of Skills. Byly konzultovány důkazně podložený a obezřetný přístup k měření a omezení současného pokrytí benchmarků.
- Evropský statistický kodex, Eurostat. Bylo konzultováno 16 zásad a 84 ukazatelů pro Evropský statistický systém.
- Rámec zabezpečování kvality, Eurostat. Byly konzultovány metody, nástroje a osvědčené postupy rámce při provádění kodexu.
- Politika kvality Eurostatu, Eurostat. Byly konzultovány čtyři úrovně zabezpečování kvality a úloha zpráv o kvalitě a metadatech.
- Průvodce podáváním výsledků MLPerf Inference, MLCommons. Byly konzultovány typy systémů, scénáře, divize, kontrola přesnosti a kroky podávání.
- Dokumentace benchmarků MLPerf Inference, MLCommons. Byly konzultovány publikované parametry benchmarků a příklady, včetně podmínek pro datovou sadu, kvalitu a latenci.
- Pracovní skupina MLPerf Inference, MLCommons. Byl konzultován účel spravedlivých a reprezentativních inferenčních benchmarků a výzva reprodukovatelnosti napříč hardwarem a softwarem.
- Nařízení (EU) 2024/1689, Akt o umělé inteligenci, EUR-Lex. Byl konzultován článek 15 o přesnosti, robustnosti, kybernetické bezpečnosti a konzistenci v průběhu životního cyklu.
- Dweve Core, Dweve. Veřejné definice prováděcí buňky a smlouvy o determinismu podporují pouze stručnou, zveřejněnou poznámku Dweve.