Benchmark to kontrakt z mianownikiem

Użyteczność danych o wydajności zależy od tego, czy przy liczbie pozostają informacje o obciążeniu, zakresie, sprzęcie, warunkach jakości, punkcie...

Benchmark to kontrakt z mianownikiem

Liczba, która zapomina o swoim mianowniku

Wynik benchmarku może być poprawnie zmierzony i nadal odpowiadać na niewłaściwe pytanie. Zwykle winowajcą nie jest wadliwy licznik czasu ani nieuczciwy inżynier. To mianownik, który zniknął między środowiskiem testowym a slajdem prezentacji. „Dwa razy szybszy” brzmi jak porównanie, ale nie mówi, dwa razy szybszy w jakiej pracy, na której maszynie, z którym oprogramowaniem, w jakich warunkach jakościowych, względem jakiej linii bazowej ani dla których użytkowników. Usuń te warunki, a liczba wydajności stanie się wypolerowanym fragmentem. Może pozostać liczbowo prawdziwa. Przestaje jednak mówić kupującemu lub operatorowi, czego mogą się spodziewać.

Mianownik to praca, względem której wyrażany jest wynik. Dla przepustowości jest to ukończona praca i czas, w którym ukończenie jest liczone. Dla opóźnienia jest to definicja żądania, uwzględniona ścieżka i populacja obserwacji. Dla dokładności jest to oznaczony zbiór, reguła etykietowania i oceniana jednostka. Dla energii jest to granica mierzonego systemu i praca dostarczona w jej obrębie. Dla kosztu jest to okres rozliczeniowy, uwzględnione zasoby i wolumen użytecznej pracy. Benchmark jest uczciwy, gdy jego licznik i mianownik podróżują razem.

Dlatego najlepiej traktować benchmark jak umowę. Umowa określa pytanie, obciążenie, zakres, sprzęt i oprogramowanie, metrykę, linię bazową, niepewność oraz metodę, dzięki której inna strona mogłaby zweryfikować wynik. Umowa może być wąska. Może mieć charakter eksploracyjny. Może być użyteczna tylko dla jednego wdrożenia. Czego nie może być, to imponująca liczba, której warunki pozostawiono czytelnikowi do zgadnięcia. Zgadywanie to słaby sposób alokacji publicznych pieniędzy i jeszcze gorszy sposób projektowania usługi, którą ktoś inny musi utrzymywać przy życiu.

Europejski zwyczaj spisywania definicji bywa czasem wyśmiewany jako biurokracja. W pracy pomiarowej definicje są tym, co powstrzymuje biurokrację przed przekształceniem się w folklor. Tabela benchmarku nie jest administracyjnym dodatkiem do wyniku. Jest dowodem tożsamości wyniku.

Przeczytaj jednostkę, zanim przeczytasz nagłówek

Zacznij od jednostki, ale na tym nie poprzestawaj. Żądania na sekundę, tokeny na sekundę, milisekundy, dżule na zapytanie, euro za tysiąc rekordów i punkty procentowe mówią ci coś. Żadna z nich nie mówi, o co poproszono system. Wynik 100 żądań na sekundę może opisywać małe buforowane żądania lub duże niebuforowane żądania obejmujące wyszukiwanie, walidację i przekazanie człowiekowi. Opóźnienie 20 milisekund może obejmować pojedyncze jądro lub całą ścieżkę decyzyjną. Jednostka to drzwi. Obciążenie to pomieszczenie za nimi.

Zakładając, że slajd przetargowy mówi, że nowa usługa jest o 40 procent szybsza niż istniejąca. To zdanie nie jest jeszcze dowodem. Potrzebuje co najmniej operacji, która jest mierzona, rozmiaru i rozkładu danych wejściowych, pracy wykluczonej z pomiaru czasu, współbieżności, stanu rozgrzania, wersji oprogramowania, sprzętu i konfiguracji linii bazowej. Potrzebuje również warunku jakości. Jeśli szybsza ścieżka zwraca mniej poprawnych wyników, odrzuca długie dane wejściowe lub pomija kosztowny krok weryfikacji, licznik został zmniejszony przez zmianę pracy.

To nie jest prośba o ogromną tabelę, zanim ktokolwiek będzie mógł się wypowiedzieć. To prośba o wskazanie kilku pól, które zmieniają znaczenie twierdzenia. Mały benchmark parsera może wymagać kształtu rekordu, źródła danych wejściowych, polityki walidacji, kompilatora i procesora. Benchmark wnioskowania może wymagać modelu, precyzji, partii, scenariusza, celu jakości i granicy mocy. Kolejka sektora publicznego może wymagać definicji sprawy, zegara usługi, reguły routingu i ścieżki eskalacji. Pola się różnią. Obowiązek ich nazwania nie.

Jest tu przydatna dyscyplina: zapisać wynik jako zdanie, które przetrwa spojrzenie drugiego czytelnika. „Przy tym obciążeniu i tym wymaganiu jakościowym, na tym systemie i w tej wersji, zmierzona wartość wyniosła tyle, z takim odchyleniem.” Jeśli zdania nie da się dokończyć bez słów takich jak typowy, najlepszy, zbliżony do produkcyjnego czy reprezentatywny, metoda nie jest gotowa. Te słowa mogą być zasadne, ale potrzebują definicji operacyjnej, a nie ciepłego tonu.

Karta benchmarku to nie ozdoba wokół liczby. To najmniejsza użyteczna forma umowy, jaką zawiera ta liczba.

Zakres jest częścią wyniku

Zakres odpowiada na proste pytanie: co obejmuje ten wynik, a co zostaje poza kadrem? W ewaluacji uczenia maszynowego zakres obejmuje zadanie, zbiór danych, podział, język, długość wejścia, scenariusz działania i dozwolone wybory implementacyjne. W usłudze programowej obejmuje ścieżkę, magazyny danych, sieć, pamięć podręczną i pracę, którą zespół downstream wykonuje po zwróceniu wyniku przez mierzony punkt końcowy. Wynik zmierzony na jednej warstwie nie powinien po cichu stać się obietnicą dotyczącą całej usługi.

MLCommons uwidacznia to w swojej dokumentacji MLPerf Inference. Przewodnik składania zgłoszeń rozdziela typy systemów centrum danych i brzegowych, wymienia scenariusze takie jak offline, server, interactive, single-stream i multi-stream oraz odróżnia dywizję zamkniętą od otwartej. Dywizja zamknięta służy porównaniu jeden do jednego z użyciem tego samego modelu i referencyjnej konfiguracji. Dywizja otwarta dopuszcza wybory takie jak ponowne trenowanie czy podmiana modelu. Żadna z nich nie jest uniwersalnie poprawna. Odpowiadają na różne pytania. Nagłówek, który je miesza, to nie szerokie spojrzenie. To błąd kategoryczny z doskonałą typografią.

Ta sama dokumentacja pokazuje, dlaczego benchmark potrzebuje jawnej strony jakościowej. Wymieniony wpis ResNet50 podaje zbiór walidacyjny ImageNet-2012, jego rozmiary zbioru danych i listy próbek zapytań, referencyjną dokładność i ograniczenie opóźnienia serwera. Dla wymienionego wpisu ResNet50 strona podaje zbiór walidacyjny liczący 50 000 obrazów, listę próbek zapytań liczącą 1 024 pozycje, referencyjną dokładność 76,46 procenta i ograniczenie opóźnienia serwera wynoszące 15 ms. Te pola to nie ciekawostki dla ludzi, którzy lubią czytać regulaminy. Wyjaśniają, co zgłoszonej szybkości wolno było znaczyć. Zmień zbiór danych, scenariusz lub wymaganie jakościowe, a porównanie się zmieni, nawet jeśli nazwa modelu wygląda znajomo.

Europejski nabywca powinien podejrzliwie patrzeć na zakres sugerowany przez etykietę produktu. „Platforma AI”, „akcelerator” i „klasa korporacyjna” nie definiują pracy. System, który doskonale radzi sobie z ograniczoną operacją, może być dokładnie tym, czego potrzebuje usługa. System, który twierdzi, że obejmuje wszystko, mógł zmierzyć niewiele przypominającego tę usługę. Wąska prawda jest zdrowsza niż uniwersalna mgła.

Pokrycie zmienia znaczenie

Pokrycie nie jest przypisem o tym, czy zestaw testowy był duży. Opisuje, czyje przypadki i jakie sytuacje wchodzą w skład pomiaru. Benchmark może obejmować wiele przykładów z jednej wąskiej dystrybucji i wciąż niewiele mówić o skrajnych przypadkach istotnych w praktyce. Odwrotnie, mały, starannie dobrany zestaw może ujawnić ważny tryb awarii, nie wspierając ogólnego twierdzenia o wydajności. Ten wybór jest decyzją projektową. Trzeba go tak przedstawić.

Ramy OECD do charakteryzowania instrumentów oceny AI są przydatne, ponieważ odmawiają sprowadzenia oceny do jednego wyniku. Proponują 18 aspektów, w tym pokrycie, cel, realizm, trafność, rzetelność, przejrzystość oraz warunki, w jakich można interpretować wyniki. Pokrycie pyta, czy ocena reprezentuje to, co zamierza mierzyć. Cel odróżnia benchmark przeznaczony do badań od tego przeznaczonego do oceny zgodności lub innego zastosowania. Realizm pyta, czy środowisko to problem zabawkowy, środowisko symulowane lub laboratoryjne, czy prawdziwe życie. Te rozróżnienia nie osłabiają benchmarku. Czynią jego twierdzenie czytelnym.

Pokrycie obejmuje także przypadki wykluczone z oceny. Usługa może raportować średnie opóźnienie po usunięciu przekroczeń limitu czasu. Klasyfikator może raportować dokładność po odrzuceniu niejednoznacznych etykiet. System wyszukiwania może liczyć tylko zapytania z co najmniej jednym istotnym dokumentem. Potok przetwarzania obrazów może pomijać uszkodzone pliki. Każde wykluczenie może być uzasadnione. Wynik musi podawać, co usunięto i dlaczego. W przeciwnym razie mianownik po cichu staje się listą przypadków, które wygodnie było ukończyć.

W tym miejscu mianownik staje się polityczny, zanim ktokolwiek użyje słowa „polityka”. Populacja uwzględniona otrzymuje korzyść bycia zmierzoną. Populacja wykluczona otrzymuje opowieść o systemie, który może jej nie opisywać. Europejskie instytucje publiczne już to znają ze statystyk oficjalnych. Europejski kodeks praktyk statystycznych Eurostatu określa 16 zasad i 84 wskaźniki dla środowiska instytucjonalnego, procesów i wyników. Jego ramy zapewniania jakości dostarczają metod i narzędzi, a raporty jakości informują użytkowników, jak dane zostały zebrane i zwalidowane. Przesłanie dla AI nie jest takie, że każdy model musi stać się urzędem statystycznym. Jest takie, że liczba przeznaczona do decyzji publicznych potrzebuje widocznej historii produkcji i jakości.

Dokładność to nie jedna brama

Twierdzenia o wydajności często łączą szybkość z pojedynczą liczbą jakości, a następnie traktują tę parę jako kompletną. Jakość to zwykle rodzina pytań. Czy wynik spełnia definicję zadania? Czy zachowuje wymagane ograniczenia? Czy zawodzi bezpiecznie, gdy brakuje dowodów? Czy zachowuje się akceptowalnie w całej istotnej populacji? Czy pozostaje w granicach jakości, gdy system jest obciążony? Szybka odpowiedź, która nie spełnia zadania, nie jest szybszym rozwiązaniem. To inny rodzaj obciążenia noszący to samo miano.

Struktura MLPerf jest pouczająca, ponieważ przebiegi wydajnościowe stoją obok walidacji dokładności i wymagań specyficznych dla modelu. Przewodnik zgłoszeniowy mówi uczestnikom, aby określili dywizję, typ systemu i scenariusz, uruchomili zamierzony benchmark, zwalidowali dokładność względem progów, a następnie przygotowali sprawdzone zgłoszenie. Strona benchmarku podaje referencyjną dokładność oraz warunki opóźnienia lub przepustowości dla każdego zadania. To rozdzielenie jest praktyczne. Zapobiega wygrywaniu kolumny wydajności przez system, który po cichu przegrywa zadanie.

Dokładność sama potrzebuje mianownika. „Dokładność na poziomie dziewięćdziesięciu ośmiu procent” może oznaczać odsetek rekordów, tokenów, obrazów, żądań lub decyzji. Może używać uśredniania mikro lub makro. Może liczyć wstrzymanie się jako błąd, jako bezpieczną odmowę lub jako niemierzony wynik. Może porównywać z etykietami utworzonymi przez jednego lub kilku recenzentów. Karta benchmarku powinna podawać jednostkę, regułę etykietowania, agregację, poziom ufności lub zmienności oraz każdy próg, który zamienia pomiar w decyzję o wydaniu.

Nie traktuj liczby jakościowej jako ozdobnej przepustki. Model może spełniać opublikowany próg i nadal nie nadawać się do konkretnej usługi, ponieważ zadanie, populacja lub profil szkód są inne. I odwrotnie, niższy wynik zagregowany może być akceptowalny dla narzędzia do tworzenia szkiców, w którym człowiek pozostaje autorem, podczas gdy ten sam wynik jest niedopuszczalny dla automatycznej bramki. Jakość to relacja między wynikiem, celem i konsekwencją.

Czas to nie jedna liczba

Opóźnienie jest często przedstawiane tak, jakby system miał jedną prędkość. Prawdziwe systemy mają rozkład. Pierwsze żądanie może wiązać się z kosztem uruchomienia. Pamięć podręczna może zmienić późniejsze żądania. Równocześni użytkownicy mogą rywalizować o pamięć lub połączenie z bazą danych. Długie wejście może obrać inną ścieżkę niż krótkie. Średnia może się poprawić, podczas gdy ogon się pogarsza. Jeśli ogon to miejsce, w którym usługa nie dotrzymuje terminu, średnia jest rozproszeniem z jednostką.

Przydatny raport o opóźnieniach mówi, co było mierzone i jak podsumowano obserwacje. Może zawierać medianę, górne percentyle, wskaźnik przekroczenia limitu czasu i liczbę żądań. Powinien określać, czy wykluczono żądania rozgrzewkowe, czy uwzględniono ponowienia oraz czy kolejkowanie lub czas sieci należy do mierzonej ścieżki. Te wybory nie są wymienne. Benchmark komponentu może być cenny, ale nie może być opisywany jako zachowanie end-to-end.

Przepustowość ma podobną pułapkę. Wysoki wskaźnik można osiągnąć przez grupowanie pracy, zwiększenie współbieżności lub poluzowanie wymogu jakościowego. To może być dokładnie właściwe dla zadania offline. Może być bezużyteczne dla usługi interaktywnej, która musi odpowiedzieć na każde żądanie w ramach terminu. Benchmark powinien określać scenariusz i punkt pracy, a następnie wyjaśniać, co się stanie, gdy zapotrzebowanie się od niego oddali. Nie ma wstydu w wąskim punkcie pracy. Jest wstyd w udawaniu, że to cała mapa.

Czas ma też ludzką stronę. Usługa, która odpowiada szybko, ale tworzy więcej pracy związanej z przeglądem, korektą lub odwołaniami, może być wolniejsza z punktu widzenia instytucji. Benchmark, który zatrzymuje stoper przed przekazaniem, może sprawić, że mierzony system będzie wyglądał na sprawny, podczas gdy rzeczywista usługa gromadzi kolejkę. Mianownik powinien podążać za pracą, dopóki pytanie, na które szukano odpowiedzi, nie zostanie udzielone. W przeciwnym razie stoper mierzy wyspę.

Sprzęt i oprogramowanie są częścią licznika

„Na serwerze” to nie jest odtwarzalne środowisko. Generacja procesora, zestaw instrukcji, akcelerator, pamięć, pamięć masowa, stan termiczny, limit mocy, system operacyjny, sterownik, kompilator, środowisko uruchomieniowe, biblioteka i konfiguracja mogą zmienić wynik. Podobnie format modelu, ustawienie kwantyzacji, rozmiar partii, wybór jądra lub polityka wątków. Benchmark nie musi wymieniać każdego kabla. Musi zidentyfikować części, które mogą zmienić pomiar.

MLPerf nazywa kompletną mierzoną konfigurację systemem badanym i organizuje wyniki według typu systemu i kategorii dostępności. To słownictwo jest przydatne poza MLPerf. System badany ma granicę. Granica określa, który sprzęt i oprogramowanie są uwzględnione, które usługi są zewnętrzne i która praca jest pominięta. Wartość mocy zmierzona przy gniazdku ma inne znaczenie niż wartość licząca tylko akcelerator. Opóźnienie zmierzone wewnątrz jądra ma inne znaczenie niż to obejmujące planowanie żądań.

Wersje mają znaczenie, ponieważ benchmark jest porównaniem między stanami, a nie ponadczasową właściwością nazwy produktu. Zapisz wersję modelu lub aplikacji, wersje zależności, flagi kompilatora, sterownik i oprogramowanie układowe, jeśli wpływają na wynik. Zapisz konfigurację, która wybrała backend lub precyzję. Jeśli środowisko uruchomieniowe wybiera inne jądro na innej maszynie, to część wyniku, a nie szczegół implementacji, który można później uporządkować.

Ujawnienie informacji o sprzęcie nie jest zaproszeniem do zamiany wpisu na blogu w katalog części. To sposób na zapobieganie fałszywym porównaniom. Kupujący nie musi przejmować się każdą instrukcją, jeśli twierdzenie dotyczy kompletnej usługi. Musi jednak wiedzieć, czy porównanie obejmuje tę samą pracę, tę samą dokładność, tę samą ścieżkę wejścia oraz system, który rzeczywiście można zdobyć i obsługiwać w zamierzonym środowisku europejskim.

Punkt odniesienia to obietnica

Punkt odniesienia to porównanie, które nadaje wynikowi kierunek. Bez niego liczba może opisywać system, ale nie poprawę. Punkt odniesienia musi odpowiadać na to samo pytanie w porównywalnych warunkach. Jeśli nowa ścieżka korzysta z nowszego kompilatora, innego rozkładu danych wejściowych lub innego celu jakościowego, wynik może być nadal interesujący, ale porównanie nie jest już czyste. Powiedz, co się zmieniło. Czytelnik może wtedy zdecydować, czy różnica jest użyteczna.

Wybór punktu odniesienia jest aktem interpretacji. Porównanie z obecnie używanym rozwiązaniem, z implementacją referencyjną, z poprzednią wersją lub z limitem teoretycznym pozwala dowiedzieć się różnych rzeczy. Nowy system może być lepszy od referencji, a gorszy od usługi, którą zastępuje. Może być szybszy w czystym teście, a wolniejszy, gdy uwzględni się walidację i przechowywanie. Benchmark powinien wskazywać punkt odniesienia i wyjaśniać, dlaczego odpowiada on na pytanie operacyjne.

Pary pomiarów są często bardziej pouczające niż pojedyncze zwycięskie okrążenie. Utrzymuj stałe obciążenie i definicję oceny, zmień jeden istotny czynnik i zapisz różnicę. Jeśli kilka czynników zmienia się jednocześnie, opisz porównanie jako całość, zamiast przypisywać cały efekt jednemu składnikowi. To brzmi oczywiście, dopóki aktualizacja, odświeżenie danych i nowa polityka pamięci podręcznej nie trafią do tej samej wersji. Wykres ma wtedy jedną strzałkę i trzy możliwe przyczyny, co jest małą zagadką, na którą nikt nie zaplanował budżetu.

Punkt odniesienia ma też termin przydatności. Kanał danych, dostawca, model, polityka lub platforma sprzętowa mogą się zmienić. Porównanie pozostaje ważne dla przetestowanych wersji i okresu. Nie należy go ponownie wykorzystywać jako bieżącej gwarancji bez sprawdzenia umowy. W tym miejscu historia wersji pokazuje swoją wartość. Wynik zastąpiony nowszym nie jest porażką. To historyczne twierdzenie, którego warunki powinny pozostać widoczne.

Niepewność nie jest przeprosinami

Każdy pomiar zawiera zmienność. Część zmienności pochodzi z systemu, część z obciążenia, a część z procesu pomiarowego. Powtarzane pomiary mogą ją ujawnić, ale samo powtarzanie nie wyjaśnia przyczyny. Ciepła pamięć podręczna może być stabilna. Hałaśliwy sąsiad może nie być. Mały zestaw ewaluacyjny może dawać szeroki zakres prawdopodobnych wyników. Większy zestaw może zmniejszyć szum próbkowania, pozostawiając obciążoną populację bez zmian. Niepewność mówi czytelnikowi, jak daleko wynik może bezpiecznie podróżować.

Przedstaw niepewność w formie odpowiedniej do twierdzenia. Może to być zakres z powtarzanych pomiarów, przedział ufności, błąd standardowy, rozkład opóźnień, analiza wrażliwości lub lista znanych ograniczeń. Nie dodawaj przedziału ufności, bo tabela wygląda samotnie. Opisz, co było powtarzane, co było stałe oraz co przedział oznacza, a czego nie oznacza. Język statystyczny nie jest zaklęciem. To umowa dotycząca zmienności.

Istnieje drugi rodzaj niepewności, którego liczby nie usuną: niepewność co do tego, czy pomiar odzwierciedla zamierzoną usługę. Wynik może mieć niewielkie różnice między pomiarami i słabe pokrycie rzeczywistego świata. Benchmark może być w pełni powtarzalny w laboratorium, a jednocześnie pomijać języki, formaty wejściowe, wzorce zmian lub skutki awarii wdrożenia. Niski szum pomiarowy nie tworzy trafności. Sprawia jedynie, że błędne pytanie otrzymuje bardziej spójną odpowiedź.

Niepewność powinna zatem znajdować się obok twierdzenia, a nie w zastrzeżeniu na dole. Jeśli próg jest blisko zmierzonej granicy, to ma znaczenie. Jeśli wynik zmienia się istotnie przy innym zestawie danych wejściowych, to ma znaczenie. Jeśli granica energetyczna wyklucza chłodzenie lub przesył danych, to ma znaczenie. Uczciwe zdanie może być mniej triumfalne, ale daje decydentowi coś lepszego niż optymizm: miejsce na ostrożność.

Odtwarzalność to łańcuch, nie przycisk pobierania

Odtwarzalność często sprowadza się do publikowania kodu. Kod ma znaczenie. Jest tylko jednym ogniwem łańcucha. Druga strona potrzebuje również obciążenia lub jego zgodnego z prawem opisu, wersji danych, konfiguracji, środowiska, polecenia lub środowiska testowego, polityki dotyczącej stanu losowego, reguły oczekiwanego wyniku, pliku z wynikami oraz metody stosowanej do ustalenia, czy przebieg jest zgodny. Jeśli brakuje jednego ogniwa, druga strona może odtworzyć podobny eksperyment, a nie ten opisany.

Łańcuch powinien odróżniać dokładne odtworzenie od niezależnej replikacji. Dokładne odtworzenie wykorzystuje przechwycony artefakt, stan, dane wejściowe, konfigurację i ścieżkę wykonania, aby sprawdzić, czy ten sam przebieg można zrekonstruować. Niezależna replikacja wykorzystuje osobno przygotowane środowisko, aby sprawdzić, czy wynik przetrwa poza oryginalną maszyną lub zespołem. Obie metody są cenne. Odpowiadają na różne pytania. Wynik identyczny co do bajtu na przechwyconych danych wejściowych potwierdza silne twierdzenie o tożsamości tego przebiegu. Nie dowodzi jednak, że świat rzeczywisty pozostanie niezmieniony.

Ramy ewaluacyjne OECD ułatwiają dostrzeżenie tego rozróżnienia, traktując cel, realizm, pokrycie i wiarygodność jako osobne aspekty. Ewaluacja może być doskonała do testów regresyjnych i słaba do szacowania wydajności usługi w czasie rzeczywistym. Może być przydatna do badań i nieodpowiednia do oceny zgodności. Odtwarzalność nie usuwa celu. Pomaga czytelnikowi zweryfikować twierdzenie, które metoda faktycznie wspiera.

W przypadku danych, których nie można udostępnić, opublikuj granicę i drogę dostępu. Opisz populację, proces próbkowania, metodę etykietowania, reguły wykluczania i kontrole walidacyjne. Zapewnij bezpieczny pakiet odtwarzalności, jeśli to możliwe, i wyjaśnij, co pozostaje chronione. „Dane są poufne” to uzasadniona granica, a nie ukończona metoda. Czytelnik powinien nadal być w stanie zrozumieć, co zostało zmierzone i dlaczego wynik powinien lub nie powinien być uogólniany.

Odtwarzalność to nie przycisk oznaczony „uruchom ponownie”. To łańcuch tożsamości, który pozwala innemu zespołowi zakwestionować twierdzenie.

Instytucje publiczne powinny odmówić teatru demonstracyjnego

Instytucje publiczne nie muszą odrzucać benchmarków. Muszą odrzucać benchmarki, które nie potrafią określić swojego kontraktu. Dopracowana demonstracja może pomóc komitetowi zrozumieć możliwość. Nie może zastąpić dowodów dotyczących usługi, którą instytucja musi prowadzić, ludzi, którym służy, oraz awarii, które musi naprawić. To rozróżnienie ma znaczenie, ponieważ demo jest optymalizowane pod kątem krótkiego spotkania, podczas gdy usługa publiczna jest oceniana przez pory roku, zmiany personelu, odwołania, utrzymanie i prawo.

Przed zakupem poproś dostawcę o zdefiniowanie obciążenia w języku usługi. Co wchodzi do systemu? Co jest mierzone? Co jest wykluczone? Która reguła jakości musi obowiązywać? Która rola ludzka weryfikuje wynik? Jak wykrywane jest dryfowanie? Jak instytucja może wyeksportować swoje dowody? Co się dzieje, gdy zmienia się model, źródło, dostawca lub polityka? Z którą wersją porównywany jest wynik? Jaka jest ścieżka wycofania? Dostawca może odpowiedzieć na niektóre pytania kontraktem, na inne testem, a na jeszcze inne uczciwym ograniczeniem. Taka mieszanka jest zdrowsza niż odpowiedź złożona wyłącznie z przymiotników.

Akt o sztucznej inteligencji UE wyraża tę kwestię językiem prawnym w odniesieniu do systemów wysokiego ryzyka. Artykuł 15 wymaga odpowiedniego poziomu dokładności, odporności i cyberbezpieczeństwa, z konsekwentną wydajnością w tych zakresach przez cały cykl życia. Benchmark nie może samodzielnie ustanowić całego obowiązku prawnego. Może wesprzeć część dowodów, jeśli jego zakres, warunki jakościowe i pozycja w cyklu życia są jasne. Traktowanie jednego wyniku jako zgodności byłoby kolejnym błędem mianownika. Prawo określa wynik; inżynieria musi pokazać ścieżkę.

Zamówienia publiczne powinny również pytać, kto jest właścicielem benchmarku po przyznaniu kontraktu. Test przygotowany przez dostawcę może być przydatny, ale instytucja potrzebuje wystarczających informacji, aby monitorować system we własnym kontekście. Potrzebuje punktu odniesienia, który można uruchomić ponownie po zmianie wersji, ścieżki przeglądu, gdy wyniki się zmieniają, oraz rejestru decyzji podjętych w sprawie akceptowalnej wydajności. W przeciwnym razie pierwszy benchmark jest egzaminem wstępnym, a system produkcyjny może ukończyć naukę bez dalszych pytań.

Spraw, aby karta benchmarku była na tyle mała, by można było z niej korzystać

Długie metody mogą być konieczne. Nie zawsze są pierwszą rzeczą, której potrzebuje czytelnik. Karta benchmarku to zwarty indeks kontraktu. Może znajdować się obok wyniku w raporcie, rejestrze ocen lub dokumentacji przetargowej. Karta powinna określać pytanie, obciążenie, zakres, system, metrykę, wymóg jakościowy, punkt odniesienia, niepewność, ścieżkę reprodukcji, właściciela oraz termin ważności lub wyzwalacz zmiany. Szczegółowa metoda może znajdować się za nią. Karta zapobiega podróżowaniu twierdzenia w pojedynkę.

Dobre karty są selektywne, a nie przeładowane. Wysuwają na pierwszy plan pola, które mogą zmienić interpretację, a następnie prowadzą do pakietu dowodów. Karta opóźnienia może wysunąć na pierwszy plan rozmiar wejścia, współbieżność, percentyl, rozgrzewanie, wersję i regułę limitu czasu. Karta energii może wysunąć na pierwszy plan granicę systemu, obciążenie, przyrząd pomiarowy, czas trwania i wykluczoną infrastrukturę. Karta dokładności może wysunąć na pierwszy plan populację, regułę etykietowania, agregację, sposób traktowania wstrzymania się od odpowiedzi i dotkliwość błędów. Wspólny kształt nie jest stałym szablonem. To obietnica, że czytelnik może znaleźć mianownik.

Karta powinna oznaczać status epistemiczny. Czy wartość jest zmierzona, oszacowana, oczekiwana, proponowana czy ilustracyjna? Czy punkt odniesienia jest aktualny? Czy zestaw ewaluacyjny jest przygotowany, ale jeszcze nieuruchomiony? Czy wyniki są chronione, ponieważ materiał testowy zawiera dane osobowe? Te etykiety zapobiegają pomyleniu metody z wynikiem. Pozwalają również organizacji publikować postępy bez tworzenia pozorów sukcesu. Przygotowany test jest użyteczną informacją. Nie jest dowodem na to, że system go zdał.

Na koniec przypisz karcie właściciela i regułę zmian. Wynik bez właściciela rozpada się w slajd. Wynik bez reguły zmian zostaje na ścianie po tym, jak obciążenie się przesunie. Właściciel nie musi bronić liczby w nieskończoność. Musi jednak powiedzieć, kiedy roszczenie należy uruchomić ponownie, wycofać lub zawęzić. Pomiar staje się częścią operacji, gdy ktoś ma uprawnienia, by utrzymywać go w uczciwości.

Dwa uczciwe sposoby publikowania wyniku

Istnieją dwa powszechne tryby publikacji. Pierwszy to ścisłe porównanie. Ustala zadanie, dane, regułę jakości, granicę systemu i punkt odniesienia, aby czytelnik mógł porównać alternatywy. Drugi to pomiar eksploracyjny. Pyta, co się dzieje, gdy zmienia się projekt, obciążenie lub środowisko, i raportuje obserwacje wraz z ich ograniczeniami. Praca eksploracyjna może być cenna, zanim powstanie ścisły benchmark. Nie powinna jednak zapożyczać języka wyniku zgodności.

Ścisłe porównania są wymagające, bo uwidaczniają różnice. Jeśli zespół zmienia model i sprzęt jednocześnie, przypisanie wyniku może być niemożliwe. Jeśli nowe obciążenie jest bardziej realistyczne, ale nie odpowiada już punktowi odniesienia, roszczenie należy przeformułować jako nowy pomiar. Jeśli optymalizacja poprawia szybkość, zmieniając jednocześnie jakość wyjścia, należy raportować obie strony. Dyscyplina nie polega na blokowaniu postępu. Polega na tym, by historia postępu nie wymazywała warunku, który go umożliwił.

Pomiary eksploracyjne wymagają własnej uczciwości. Powiedz, że próbka jest mała, że środowisko jest tymczasowe, że obciążenie jest syntetyczne, że wynik nie został niezależnie powtórzony albo że kontrola jakości jest niekompletna. To nie są słabości do ukrycia aż do dopracowanej publikacji. To informacje, które pomagają czytelnikowi zdecydować, co zrobić dalej. Europejska kultura inżynierska nie musi udawać, że każdy test jest ostatecznym werdyktem. Musi przestać nazywać pytanie rozstrzygniętym, zanim test zostanie przeczytany.

Oba tryby korzystają z archiwum wyników. Zachowuj identyfikowalne dawne definicje, konfiguracje i wyniki. Zapisuj zastąpienie zamiast usuwać przeszłość. Zmieniony benchmark może być właściwym benchmarkiem dla zmienionej usługi, ale nie może służyć do przepisania znaczenia dawnego wyniku. Historia wersji to pamięć mianownika.

Nasza krótka notatka

W Dweve opisujemy Core za pomocą komórki wykonawczej i kontraktu determinizmu. Użyteczna część tego słownictwa to nie nazwa produktu. To upór, że operacja niesie swoją reprezentację numeryczną, backend, zestaw instrukcji, politykę dyspozytorską i postawę replay jako część ocenianej ścieżki. To ten sam nawyk, którego potrzebuje benchmark: trzymaj warunki przy wyniku zamiast opisywać wydajność, jakby unosiła się ponad systemem.

To krótka notatka projektowa, a nie roszczenie dotyczące zewnętrznego wdrożenia ani zmierzonego wyniku. Szersza lekcja nie zależy od Dweve. Czy system jest publiczną usługą statystyczną, sterownikiem przemysłowym, narzędziem językowym czy prototypem badawczym, liczba zdobywa zaufanie, nazywając swoją pracę i swoje ograniczenia. Nasza własna dokumentacja to po prostu jedno z miejsc, gdzie staramy się tę granicę uczynić jawną.

Mianownik to część, która podróżuje

Nagłówek benchmarku łatwo skopiować. Mianownik trudniej przenieść, dlatego często zostaje w tyle. Kupujący kopiuje liczbę przepustowości do biznesplanu. Regulator widzi wynik dokładności w teczce. Inżynier porównuje dwa wykresy z różnych obciążeń. Dziennikarz powtarza procent bez populacji. Każdy czytelnik otrzymuje liczbę, która straciła kontrakt czyniący ją znaczącą.

Naprawa nie jest skomplikowana, choć wymaga dyscypliny. Nazwij pytanie. Zdefiniuj pracę. Określ zakres i wyłączenia. Zidentyfikuj system i wersje. Wybierz metrykę, która odpowiada usłudze. Prowadź linię bazową. Mierz zmienność. Opublikuj metodę i dowody. Zaznacz, co pozostaje nieznane. Przypisz właściciela do twierdzenia i powód, dla którego należy je powtórzyć. Jeśli wynik nie może potwierdzić szerokiego stwierdzenia, zawęź to stwierdzenie.

W ten sposób Europa może opierać się teatrowi demonstracji, nie stając się przy tym niechętna ambicjom. Instytucja publiczna może kupić nowe możliwości i nadal wymagać benchmarku, który respektuje usługę. Zespół badawczy może opublikować ekscytujący wynik i nadal podać obciążenie, które go wygenerowało. Dostawca może pokazać szybką ścieżkę i nadal powiedzieć, gdzie ta ścieżka się kończy. Uczciwy zakres nie jest hamulcem dla innowacji. Jest nawierzchnią drogi, po której może pojechać każdy inny.

Benchmark to kontrakt z mianownikiem, ponieważ mianownik mówi nam, co faktycznie zostało zrobione. Trzymaj go obok liczby. Wynik stanie się mniej magiczny, bardziej porównywalny i znacznie bardziej użyteczny. To uczciwa wymiana. Systemy, na których ludzie muszą polegać, zasługują na liczby, które przetrwają powolne czytanie.

Gdy metryka podróżuje między światami

Liczby z benchmarków często opuszczają zespół, który je zmierzył, i trafiają do innego systemu decyzyjnego. Badacz publikuje tabelę. Zespół produktowy zamienia jeden wiersz w cel. Zamówienia publiczne zamieniają cel w kontrakt. Operacje zamieniają kontrakt w oczekiwanie dotyczące poziomu usług. Każde takie przejście zmienia to, czego oczekuje się od liczby. Oryginalny mianownik może nadal być obecny w artykule lub repozytorium, ale stał się społecznie odległy od decyzji. Metryka potrzebuje noty tłumaczeniowej za każdym razem, gdy przekracza tę granicę.

Nota tłumaczeniowa może być prosta. Ten wynik dotyczy przepustowości komponentów, a nie ukończonych przypadków. Ta wartość dokładności używa stałego zestawu etykiet, a nie rzeczywistych wyników. Ta wartość energii wyklucza granicę chłodzenia centrum danych. Ta linia bazowa to implementacja referencyjna, a nie dotychczasowa usługa. Te zdania powstrzymują użyteczny pomiar przed przekształceniem się w mylącą obietnicę. Ułatwiają też spory. Czytelnik może zakwestionować granicę, zamiast spierać się o to, czy liczba robi wrażenie.

Różne zespoły mogą świadomie wybierać różne mianowniki. Zespół platformowy może dbać o pracę na dżul. Właściciel usługi może dbać o ukończone decyzje na przepracowaną godzinę. Instytucja publiczna może dbać o poprawne i wyjaśnialne wyniki dla określonej populacji oraz czas odpowiedzi. To nie są sprzeczne prawdy, jeśli każda z nich jest nazwana. Kłopoty zaczynają się, gdy najłatwiejszy mianownik może zastąpić misję. Najszybsze jądro nie automatycznie tworzy najlepszą usługę, tak samo jak największy zestaw testowy nie automatycznie tworzy najbardziej odpowiedni.

Zanim ponownie użyjesz benchmarku, zapytaj, co się zmieniło: obciążenie, właściciel, konsekwencja czy horyzont czasowy. Jeśli którekolwiek z nich się zmieniło, powtórz interpretację, nawet jeśli podstawowa liczba jest niezmieniona. Pomiar nie jest reliktem do przenoszenia między pokojami. To relacja, którą trzeba odnawiać, gdy zmienia się pomieszczenie.

Wynik powinien wiedzieć, kiedy wygasa

Wyniki mają określony okres przydatności. Benchmark powiązany z wersją modelu, migawką źródła lub konfiguracją sprzętu staje się historyczny, gdy te warunki się zmieniają. Nie czyni to starego wyniku fałszywym. Zmienia to pytanie, na które może odpowiedzieć. Raport powinien określać, jakie zdarzenie czyni twierdzenie nieaktualnym: nowy model, zmieniony kompilator, nowy rozkład danych, zmieniona reguła etykietowania, wymiana sprzętu, zmiana polityki lub zaobserwowany sygnał dryfu. Reguła wygaśnięcia to mały element instytucjonalnej pamięci.

Bez reguły wygasania liczby gromadzą się jak płaszcze na krześle. Każda z nich jest technicznie wciąż obecna i nikt nie wie, która należy do dzisiaj. Rejestr wyników może zachować pełną historię, jednocześnie oznaczając bieżące porównanie, zastąpioną definicję i powód ponownego uruchomienia. Ponowne uruchomienie staje się wtedy zwykłą konserwacją, a nie reakcją kryzysową. Jest to szczególnie istotne w usługach publicznych, gdzie wynik może przetrwać zespół, który go opracował.

Wygasanie chroni również uczciwy postęp. Jeśli nowe obciążenie ujawni, że wcześniejszy benchmark był zbyt wąski, organizacja może opublikować zmianę, zachować starą metodę i wyjaśnić nową granicę. Nie musi bronić nieaktualnej liczby ani udawać, że stara liczba nigdy nie istniała. Benchmark, który można zawęzić, zastąpić i zrozumieć, jest bardziej użyteczny niż taki, który musi pozostać imponujący na zawsze.

Źródła