Poziomy stabilności

Poziomy obsługi eksportu

Poziom decydujący o powodzeniu wywołania. Dotyczy trójki (family, task, format), a każda kombinacja ma dokładnie jeden poziom.

Zarówno validated, jak i available przechodzą bez potwierdzenia ani ogólnego ostrzeżenia. Różnica dotyczy dowodów, a nie uprawnień: za wpisem validated stoi test zgodności i wydanie since, a available jeszcze ich nie ma. Na przykład konwersja CoreML bez przebiegu predykcji na macOS jest available, a nie validated.

Zablokowana kombinacja kończy się niepowodzeniem przed sprawdzaniem zależności, wczytywaniem kalibracji, śledzeniem lub utworzeniem artefaktu, więc nie jest zapisywany żaden niepełny wynik.

Każda komórka validated zawiera ograniczenie opisujące konfigurację, z której pochodzi wynik zgodności. Zwykle jest to stały obszar wejścia, batch 1, FP32 i nazwana wersja środowiska uruchomieniowego. Należy odczytywać je jako stwierdzenie o tej konfiguracji, a nie o całym formacie. Reguły wypełniające komórki bez jawnego wpisu opisano na stronie macierzy eksportu.

from libreyolo.models.registry import GROUPS, group_offrom libreyolo.export.support import get_support, validated_alternatives family = "yolo9" group = group_of(family)print(group, GROUPS[group]) print(get_support(family, "detect", "onnx").tier)print(validated_alternatives(family, "detect"))

Poziomy API

Poziom decydujący o postaci wywołania. Rodzina należy dokładnie do jednego poziomu wybranego według kontraktu wywołania, a nie architektury.

Trzy sąsiednie poziomy celowo nie rejestrują się w fabryce detektorów, dlatego LibreYOLO("some-alias") do nich nie prowadzi. Są wczytywane według aliasu rozmiaru i pobierane automatycznie, a nie rozpoznawane na podstawie checkpointu.

Wszystkie cztery zwracają ten sam Results, więc kod dalszego przetwarzania pozostaje bez zmian. Różnią się działającymi metodami: sąsiednie poziomy zgłaszają NotImplementedError dla train(), val() i export(), a poziomy SAM oraz otwartego słownika również dla track(). Strona każdego poziomu wymienia jego wykluczenia.

Grupy pokrycia

Ta klasyfikacja decyduje, które rodziny obejmuje przebieg testów przekrojowych, i jest najczęściej spotykana przez czytelnika na stronie modelu. Każda zarejestrowana rodzina jest przypisana dokładnie do jednej grupy, a test kończy się niepowodzeniem, gdy zarejestrowanej rodziny brakuje w przypisaniu. GROUPS w libreyolo/models/registry.py jest źródłem poniższej kolumny Znaczenie, MODEL_GROUPS w tym samym pliku przypisuje każdą rodzinę, a kolumna Rodziny zlicza bezpośrednio to przypisanie. Kolumna Etykieta jest krótszą nazwą używaną przez witrynę dla tej samej grupy w nagłówku strony modelu.

Łącznie jest to 87 rodzin w sześciu grupach. Samo g3 zawiera więcej rodzin niż wszystkie pozostałe grupy razem, ponieważ większość rejestru stanowią linie tylko do inferencji i pokrycie muzealne, a nie aktywnie trenowane detektory.

Dla osoby wybierającej model grupa wskazuje, gdzie można oczekiwać uwagi inżynieryjnej, a nie dokładność rodziny. g0 i g1 są miejscami projektowania i pierwszego wdrażania nowych funkcji. g2 jest utrzymywane w stanie poprawnym w CI, ale funkcja trafia tam zależnie od możliwości, a nie w tej samej fali wydania. g3 określa brak, a nie ograniczenie: predykcja, walidacja oraz eksport, jeśli rodzina go obsługuje, nadal działają. train() dla rodziny g3 lub g4 zgłasza NotImplementedError z przyczyną zamiast po cichu wykonywać część pracy. Rodziny s w ogóle nie podlegają temu kompromisowi, ponieważ są wczytywane przez własną fabrykę zamiast LibreYOLO(). Zobacz podstawowe pojęcia, aby dowiedzieć się, jak grupa współgra z zadaniem, rodziną i rozmiarem podczas odczytywania nazwy pliku checkpointu.

Grupa sama w sobie nie przyznaje ani nie ogranicza możliwości widocznej dla użytkownika. Obsługa wynika z zaimplementowanego API rodziny i kontroli możliwości właściwych dla formatu, nigdy wyłącznie z członkostwa w grupie. Grupy klasyfikują rodziny, a nie zadania, dlatego przebieg pokrycia ograniczony do zadania jawnie podaje jego nazwę, na przykład „g1 detect”.

Dwa miejsca odczytują grupę podczas działania, a nie tylko w testach. collect_model_inventory() w libreyolo/models/inventory.py dołącza grupę do każdego wpisu wyświetlanego przez inwentarz CLI, a pretrained=False uruchamia specjalną ścieżkę ponownej inicjalizacji od zera tylko dla rodzin w g0 i g1. Poza tymi dwiema grupami kontrola w libreyolo/models/base/model.py jest całkowicie pomijana, więc pretrained=False trafia do własnego train() rodziny jako zwykłe słowo kluczowe.

Trenowanie

Rodzina w g3 lub g4 nie ma implementacji trenowania, a wywołanie jej train() zgłasza błąd. Jest to właściwość kodu rodziny, a nie jej grupy. Grupa zapisuje ten fakt, zamiast go powodować.

Dla rodziny obsługującej trenowanie to, czy pojedynczy parametr augmentacji trafia do pipeline'u, jest osobną kwestią z własnym słownictwem trzech wartości: used, gated_by_mosaic i ignored. Zobacz macierz augmentacji.

Czego poziom nie określa

Poziom nie jest deklaracją dokładności. Zweryfikowany eksport oznacza, że artefakt odtwarza natywny model w określonym progu. Nie mówi nic o wyniku natywnego modelu na zbiorze danych. Wyniki benchmarków znajdują się na stronach modeli.

Poziom nie jest też deklaracją licencyjną. Licencje wag różnią się w obrębie rodziny, a repozytorium hostujące konkretny checkpoint jest źródłem rozstrzygającym. Obecność rodziny w fabryce detektorów nie mówi nic o tym, czy opublikowane wagi zezwalają na użycie komercyjne.