Warum ein fertiges Modell nicht ausreicht: Eine praktische Lektion zur Feinabstimmung von Objekterkennungsmodellen auf realen Daten

JetBrains stellt ein praktisches Experiment vor, in dem drei moderne Objekterkennungsmodelle – YOLO12, YOLO26 und RF-DETR – getestet werden, und zwar nicht nur auf Standarddatensätzen, sondern auf Bildern, die realistischere Einsatzfälle abbilden: Kabelschäden, Knochenbrüche auf Röntgenbildern und dicht aneinandergereihte Getränkeflaschen. Die zentrale Schlussfolgerung ist eindeutig: Ein vortrainiertes Modell ist nicht zwangsläufig ein sofort einsatzbereites Modell.

Die Modelle basierten ursprünglich auf den COCO-Daten, die etwa 118.000 Trainingsbilder und 80 verbreitete Kategorien wie Personen, Autos, Hunde und Stühle umfassen. Einige praktische Ziele, etwa Knochenbrüche, gehören jedoch grundsätzlich nicht zum Vokabular dieser Kategorien. Zudem unterscheiden sich Röntgenbilder, Industrieaufnahmen und visuell überfüllte Szenen von den natürlichen Bildern, die die Modelle bisher gesehen haben.

Überprüfung der Ausgangsbasis vor dem Training

Vor dem Fine-Tuning bewertete JetBrains sechs Checkpoints, jeweils in zwei Größen pro Modellfamilie, auf dem COCO-Validierungsdatensatz val2017 mit 5.000 Bildern. RF-DETR Base erzielte mit 0,5325 den höchsten mAP50-95-Wert, während die beiden mittleren YOLO-Modelle mit 0,5259 beziehungsweise 0,5181 nahe an dieses Ergebnis herankamen – bei rund 10 Millionen weniger Parametern.

Der Vergleich zeigte auch praktische Unterschiede bei der Geschwindigkeit. YOLO26-N erreichte eine Zeit von 12,3 Millisekunden und einen mAP50-95-Wert nahe dem von YOLOv12-N, das trotz seiner geringsten Größe im Experiment 23,9 Millisekunden benötigte. RF-DETR Nano kam auf 12,4 Millisekunden, obwohl es fast 30 Millionen Parameter besitzt und damit YOLO26-M übertrifft.

Diese Zahlen stimmen nicht zwangsläufig mit den Angaben in den Modellpapieren überein, da das Experiment andere Hardware als die bei Vergleichen häufig verwendete NVIDIA-T4-Einheit nutzte und die Modelle innerhalb ihrer ursprünglichen Frameworks ausgeführt wurden, ohne sie in TensorRT umzuwandeln. JetBrains erklärt, dass TensorRT die Inferenzzeit durch das Zusammenfassen von Schichten und die Auswahl für die Hardware optimierter Kernel senken kann. Dafür ist jedoch ein zusätzlicher Build-Schritt erforderlich, und es entsteht eine Engine, die an eine bestimmte Grafikeinheit gebunden ist. Die Zahlen des Experiments spiegeln daher eine Leistung wider, die eher dem direkten Betrieb entspricht, nicht der maximal möglichen Leistung nach einer Optimierung.

Der Test außerhalb des Trainingsbereichs

Das Experiment verwendete drei Datensätze aus RF100-VL, einer Sammlung von 100 multimodalen Datensätzen, die seltene Ziele abdecken soll, die in den üblichen Trainingsdaten kaum vertreten sind. Ausgewählt wurden bone-fracture-7fylg, cable-damage und soda-bottles.

Beim direkten Ausführen der auf COCO trainierten Checkpoints auf diesen Daten war das Ergebnis nahezu null. JetBrains erklärt dies damit, dass es sich bei den verwendeten Modellen um Detektoren mit geschlossenem Vokabular handelt: Sie verfügen über eine festgelegte Anzahl von Kategorien und können keine Kategorie wie fracture ausgeben, wenn diese nicht im aus 80 Kategorien bestehenden Modellkopf enthalten ist. Ein mAP50-Wert von 0,72 auf COCO bedeutet daher nicht, dass ein Modell automatisch Knochenbrüche erkennt.

Was verändert das Fine-Tuning?

JetBrains passte alle drei Modelle auf jedem Datensatz über 10 Trainingsepochen hinweg mit einer einzigen A100-Einheit an und nutzte dabei die üblichen Trainingsabläufe von Ultralytics und RF-DETR. Nach dem Training verbesserten sich die Ergebnisse bei den Aufgaben Kabelschäden und Getränkeflaschen deutlich, während die schwierigere Aufgabe der Knochenbrüche weiterhin problematisch blieb.

Getränkeflaschen waren der einfachste Fall: Der mAP50-Wert aller Modelle lag zwischen 0,91 und 0,97, wobei YOLOv12-M mit 0,6422 den besten mAP50-95-Wert erzielte. JetBrains vermutet, dass der Grund in der Nähe der Produktbilder zu einigen in COCO vorhandenen Kategorien liegt. Dadurch ähnelt das Problem eher dem Hinzufügen neuer Vokabeln als einem vollständigen Wechsel zwischen zwei visuellen Bereichen.

Bei der Aufgabe Kabelschäden erreichte der mAP50-Wert 0,93, doch der höchste mAP50-95-Wert lag nur bei 0,446. Das bedeutet, dass die Modelle Schäden gut finden können, aber Schwierigkeiten haben, präzise Begrenzungsrahmen um dünne und langgezogene Defekte zu zeichnen. Bei den Bildern von Knochenbrüchen lag der beste mAP50-Wert, den RF-DETR Base erzielte, lediglich bei 0,447, wobei die Unterschiede zwischen den Modellen groß waren. Auch die visuelle Prüfung zeigte, dass bei einigen Ergebnissen weniger als die Hälfte der Bilder einen erkannten Bruch enthielt.

Was sollte das Entwicklungsteam überprüfen?

• Mit einer reproduzierbaren Ausgangsbasis beginnen: Überprüfen Sie die Leistung der Checkpoints in Ihrer eigenen Umgebung und auf Ihrer eigenen Hardware, bevor Sie die Ergebnisse mit veröffentlichten Zahlen vergleichen.
• Softwareumgebungen trennen: JetBrains verwendete drei isolierte uv-Umgebungen innerhalb eines einzigen PyCharm-Projekts, da die für die YOLO-Generationen erforderlichen Versionen der Bibliothek ultralytics nicht kompatibel sind. Die Verwendung des Remote-Interpreters in PyCharm erfordert die Professional-Version, während die Community Edition nur lokale Umgebungen unterstützt.
• Nicht auf eine einzige Kennzahl beschränken: Der Unterschied zwischen mAP50 und mAP50-95 bei Kabelschäden zeigt ein Problem bei der präzisen Positionierung, das beim alleinigen Blick auf mAP50 möglicherweise nicht sichtbar wird.
• Die Modellwahl an die Aufgabe knüpfen: RF-DETR Base zeigte eine höhere Konsistenz und gewann auf zwei von drei Datensätzen. Das macht es jedoch nicht für jeden Anwendungsfall zum besten Modell.
• Bei großen Verschiebungen die Datenplanung berücksichtigen: Die Ergebnisse mit Röntgenbildern deuten darauf hin, dass Fine-Tuning allein möglicherweise nicht ausreicht. Es könnten mehr Daten, ein längeres Training oder ein auf den jeweiligen Bereich spezialisiertes Vortraining erforderlich sein. Diese Optionen werden im Beitrag genannt, ohne dass eine davon in diesem Experiment als überlegen nachgewiesen wurde.

Das Experiment bestätigt, dass die Bezeichnungen „modern“ oder „vortrainiert“ nicht ausreichen, um die Eignung eines Objekterkennungsmodells für eine Einsatzumgebung zu bestimmen. Die praktische Entscheidung sollte Genauigkeit, Inferenzzeit, Modellgröße, Lizenzanforderungen und vor allem die Ähnlichkeit der Trainingsdaten mit dem Zielbereich gegeneinander abwägen. Zudem bleiben die Ergebnisse von JetBrains an die drei Datensätze und die verwendeten Trainingseinstellungen gebunden und sollten daher nicht als endgültige Rangfolge für alle Erkennungsaufgaben verallgemeinert werden.