Stabilitätsstufen

Export-Support-Stufen

Diese Stufe bestimmt, ob ein Aufruf gelingt. Sie gilt für das Tripel (family, task, format). Jede Kombination besitzt genau eine Stufe.

Sowohl „validated“ als auch „available“ werden ohne Bestätigung oder pauschale Warnung ausgeführt. Der Unterschied liegt in den Belegen und nicht in der Erlaubnis. Hinter einem validierten Eintrag stehen ein Paritätstest und ein since-Release, hinter einem verfügbaren noch nicht. Eine CoreML-Konvertierung ohne Vorhersagelauf unter macOS ist zum Beispiel verfügbar, aber nicht validiert.

Eine blockierte Kombination scheitert vor Abhängigkeitsprüfungen, Kalibrierungsladen, Tracing oder Artefakterstellung. Es wird daher nichts Unvollständiges geschrieben.

Jede validierte Zelle enthält eine Einschränkung mit der Konfiguration, aus der der Paritätswert stammt. Normalerweise sind dies eine feste Eingabe-Canvas, Batch-Größe 1, FP32 und eine benannte Runtime-Version. Betrachte sie als Aussage über diese Konfiguration und nicht über das Format insgesamt. Die Regeln für Zellen ohne expliziten Eintrag stehen auf der Seite zur Exportmatrix.

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"))

API-Stufen

Diese Stufe bestimmt die Form eines Aufrufs. Eine Familie gehört genau einer Stufe an, die anhand des Aufrufvertrags und nicht der Architektur gewählt wird.

Die drei benachbarten Stufen registrieren sich bewusst nicht in der Detektor-Factory. Deshalb kann LibreYOLO("some-alias") sie nicht erreichen. Sie werden über Größenaliasse geladen und automatisch heruntergeladen, statt durch Untersuchung eines Checkpoints.

Alle vier geben denselben Typ Results zurück. Nachgelagerter Code bleibt daher über die Stufen hinweg unverändert. Die verfügbaren Methoden unterscheiden sich. Die benachbarten Stufen lösen für train(), val() und export() einen NotImplementedError aus. Die SAM- und Open-Vocabulary-Stufen tun dies auch für track(). Jede Stufenseite führt ihre eigenen Ausschlüsse auf.

Abdeckungsgruppen

Diese Klassifizierung bestimmt, welche Familien ein familienübergreifender Testlauf umfasst. Leser sehen sie am häufigsten auf einer Modellseite. Jede registrierte Familie gehört genau einer Gruppe an. Ein Test schlägt fehl, wenn eine registrierte Familie keiner Gruppe zugeordnet ist. GROUPS in libreyolo/models/registry.py ist die Quelle der Spalte „Bedeutung“. MODEL_GROUPS in derselben Datei ordnet jede Familie zu, und die Spalte „Familien“ zählt diese Zuordnungen direkt. Die Spalte „Label“ enthält den kürzeren Namen, den die Website für dieselbe Gruppe im Kopf einer Modellseite verwendet.

Das sind 87 Familien in sechs Gruppen. Allein g3 enthält mehr Familien als alle anderen Gruppen zusammen, weil der Großteil des Registers aus Inferenzlinien und Museum-Abdeckung statt aktiv trainierten Detektoren besteht.

Bei der Modellauswahl beschreibt die Gruppe die zu erwartende technische Betreuung und nicht die Accuracy einer Familie. In g0 und g1 wird eine neue Funktion entwickelt und zuerst implementiert. g2 wird im CI-System grün gehalten, erhält eine Funktion aber nach Gelegenheit und nicht zwingend in derselben Release-Welle. g3 beschreibt eine fehlende Funktion und keine allgemeine Einschränkung. Vorhersage, Validierung und, sofern von der Familie unterstützt, Export funktionieren weiterhin. train() einer Familie aus g3 oder g4 löst einen NotImplementedError mit Begründung aus, statt stillschweigend einen unvollständigen Vorgang auszuführen. Familien aus s nehmen an diesem Kompromiss nicht teil, weil sie über ihre eigene Factory statt LibreYOLO() geladen werden. Unter Grundkonzepte erfährst du, wie eine Gruppe beim Lesen eines Checkpoint-Dateinamens neben Aufgabe, Familie und Größe einzuordnen ist.

Eine Gruppe gewährt oder beschränkt keine nutzerseitige Funktion. Der Support ergibt sich aus der implementierten API der Familie und formatspezifischen Funktionsprüfungen, nie allein aus der Gruppenzugehörigkeit. Gruppen klassifizieren Familien und keine Aufgaben. Ein aufgabenbezogener Abdeckungslauf nennt die Aufgabe daher ausdrücklich, zum Beispiel „g1 detect“.

An zwei Stellen wird die Gruppe zur Laufzeit und nicht nur in Tests gelesen. collect_model_inventory() in libreyolo/models/inventory.py ergänzt jeden vom CLI-Inventar ausgegebenen Eintrag um die Gruppe. pretrained=False löst den besonderen Pfad zur Neuinitialisierung von Grund auf nur für Familien aus g0 und g1 aus. Außerhalb dieser beiden Gruppen wird die Prüfung in libreyolo/models/base/model.py vollständig übersprungen. pretrained=False erreicht dort die familieneigene Methode train() als gewöhnliches Keyword.

Training

Eine Familie in g3 oder g4 besitzt keine Trainingsimplementierung. Ein Aufruf von train() löst einen Fehler aus. Dies ist eine Eigenschaft des Familiencodes und keine Wirkung der Gruppe. Die Gruppe dokumentiert den Umstand lediglich.

Bei einer trainierbaren Familie ist es eine getrennte Frage, ob ein bestimmter Augmentierungsparameter die Pipeline erreicht. Dafür gilt ein eigenes dreiwertiges Vokabular: used, gated_by_mosaic und ignored. Siehe Augmentierungsmatrix.

Grenzen einer Stufe

Eine Stufe ist keine Aussage zur Accuracy. Ein validierter Export besagt, dass das Artefakt das native Modell innerhalb eines angegebenen Schwellenwerts reproduziert. Daraus lässt sich nicht ableiten, wie gut das native Modell auf einem Datensatz abschneidet. Benchmark-Werte stehen auf den Modellseiten.

Eine Stufe ist auch keine Lizenzaussage. Gewichtslizenzen unterscheiden sich innerhalb einer Familie, und maßgeblich ist das Repository des konkreten Checkpoints. Die Zugehörigkeit einer Familie zur Detektor-Factory sagt nichts darüber aus, ob ihre veröffentlichten Gewichte kommerziell genutzt werden dürfen.