Status i Roadmapa

Aktualny status projektu

Easy-RT-DETR jest dzialajacym research prototype / strong MVP dla hybrydowej detekcji obiektow CNN-Transformer.

Projekt ma:

  • dzialajacy model w PyTorch,
  • trening lokalny i zdalny,
  • DDP na Kaggle 2x Tesla T4,
  • integracje z MinIO dla datasetow i artefaktow,
  • ewaluacje AP50, AP75, mAP@0.50:0.95 oraz metryki proxy,
  • wizualizacje obrazow i benchmark wideo.

Nazewnictwo

Klasy publiczne w paczce easy_rtdetr zostaly przemianowane na neutralne wzgledem zrodla:

  • RTDETRv3 -> EasyRTDETR
  • RTDETRv3Config -> EasyRTDETRConfig
  • RTDETRDecoder(Layer) -> EasyDecoder(Layer)
  • RTDETRPostProcessor -> DetectionPostProcessor
  • PPYOLOEAuxHead -> AuxiliaryDenseHead
  • PPHGNetV2Backbone -> HGNetV2Backbone
  • presety rtdetrv3_* -> easy_*

Sama architektura nie zostala zmieniona, ale nazwy nie zdradzaja juz konkretnych implementacji z PaddleDetection.

Co jest mocne

  • pipeline end-to-end od danych do checkpointu i wizualizacji,
  • modularny config system oparty o YAML i --set,
  • wspolny solver z AMP, DDP, EMA, schedulerem, warmupem i checkpointingiem,
  • backbone ResNet18/34/50/101 oraz opcjonalny HGNet-V2-S,
  • RT-DETR-like komponenty: HybridEncoder, query selection, denoising, decoder z refinementem boxow,
  • auxiliary dense head w stylu PP-YOLOE,
  • dobre wyniki na Penn-Fudan i sensowny formalny baseline VOC car,
  • sprawdzony remote runner, ktory nie wysyla .venv, data, artifacts, runs.

Najwazniejsza poprawka techniczna

Znaleziono i naprawiono krytyczny blad w AuxiliaryDenseCriterion.forward():

  • loss_dfl mial ksztalt [num_pos],
  • bbox_weight.unsqueeze(-1) mial ksztalt [num_pos, 1],
  • PyTorch broadcastowal to do [num_pos, num_pos],
  • auxiliary DFL byl sztucznie zawyzony.

Po poprawce na probce:

  • loss_total spadl z okolo 364.3 do 71.6,
  • loss_dfl_aux_o2m spadl z okolo 293.2 do 1.42.

Dodano test regresyjny:

tests/test_engine_utils.py::test_auxiliary_dense_dfl_loss_does_not_broadcast_weights

Konsekwencja: stare wyniki BDD/COCO/vehicles sprzed tej poprawki sa wartosciowe infrastrukturalnie, ale nie powinny byc uzywane jako ostateczny wniosek o jakosci architektury.

Aktualny dataset roboczy

Aktywnym datasetem roboczym jest teraz vehicles3:

  • zrodlo: data/vehicles.v2-release.coco.zip,
  • format zrodlowy: Roboflow COCO,
  • klasy po mapowaniu: car, bus, truck,
  • lokalny root: data/vehicles3,
  • config: configs/vehicles3/resnet50.yaml,
  • MinIO: datasets/vehicles3/roboflow-v2-release/vehicles3-roboflow-v2-release.tar.gz.

Historyczne datasety BDD vehicle-3 oraz COCO traffic-5 zostaly usuniete z MinIO i lokalnie, zeby zwolnic miejsce. Ich opis zostaje w dokumentacji jako historia eksperymentow, nie jako aktualny stan storage.

Aktualny najlepszy wynik

Po przesuniecu na nowy recipe (pretrenowany backbone + class reweighting) uzyskano znaczacy zysk w 5 epokach:

  • konfiguracja: vehicles3 + HGNet-V2-B0 z PPHGNetV2_B0_ssld_stage1_pretrained.pdparams,
  • class reweighting w VarifocalLoss: [0.47 car, 1.93 bus, 0.60 truck],
  • artifact: artifacts/remote_pretrain_reweight/custom/artifacts/vehicles3_hgnetv2_b0_pretrain_reweight_5e.pt,
  • AP50 = 0.758, AP75 = 0.490, mAP@0.50:0.95 = 0.458,
  • gt_recall@0.50 = 0.917, pred_precision@0.50 = 0.506,
  • bus AP50 = 0.662 (z baseline 0.294 - wzrost 125%),
  • throughput 6.96 img/s na 2x T4, peak memory 10.2GB.

Wczesniejszy baseline (HGNet-V2-S, no pretrain, no reweight, 5 epok): AP50 = 0.560. Pelne porownanie w experiments.md sekcja 12.

Co potwierdzilo sie eksperymentalnie

  • Architektura nie byla glownym waskim gardlem dla detekcji vehicles3 w 5 epokach. Najwiekszy zysk dal recipe (pretrain + class reweight).
  • Pelny P2 (4 poziomy feature maps) bez wystarczajacego treningu pogorszyl wyniki ~1000x (experiments.md sekcja 11). Kod-level wsparcie zostawione jako opt-in.
  • Class reweighting w VarifocalLoss z cls_class_weights skutecznie naprawia bus collapse (nadprodukcja klasy rzadkiej).

Co nadal jest otwarte

  • dlugi trening 25-30 epok z obecnym recipe (B0 + pretrain + reweight) - oczekiwany AP50 ~0.85+,
  • domain shift: model jest mocno wyspecjalizowany pod kamery z vehicles3 (CCTV/dashcam z kilku sesji). Generalizacja na inne kamery wymaga mocniejszej augmentacji (mosaic, perspective) lub mixu datasetow,
  • przygotowano pipeline openimages_traffic4 dla szerszego subsetu Open Images: person, car, bus, truck; to dobry kandydat do testu generalizacji zamiast kolejnych waskich datasetow Roboflow,
  • import pretrenowanych wag B3 lub wyzszych (najblizej naszego "S" 23M params),
  • ewentualny powrot do P2 dopiero po sukcesie dlugiego treningu z B0,
  • score calibration dla detekcji powyzej progu 0.75: obecnie mean_score klas to ~0.07-0.21, do progu 0.75+ trzeba dluzszego treningu zeby score'y sie stratyfikowaly.

Rekomendowana kolejna kolejnosc

  1. 30-epokowy bieg na Kaggle z obecnym recipe B0 + pretrain + reweight (~6-8h).
  2. Wizualizacja kilku obrazow i pomiar precision @ score thresholds 0.3/0.5/0.7.
  3. Jezeli domain shift bedzie problemem dla docelowego use case: dodanie mosaic i random_scale_crop do train_transforms.
  4. Ewentualny upgrade backbone'u do B3 (jezeli zdobyte zostana pretrenowane wagi B3 z PaddleClas).

Licencje i zewnetrzne zaleznosci

  • Pretrenowane wagi: PaddleClas (PPHGNetV2_B0_ssld_stage1), Apache 2.0.
  • Dataset: Roboflow Vehicles v2 Release, CC BY 4.0.
  • Inspiracje architektury: RT-DETR, D-FINE, PP-YOLOE, wszystkie Apache 2.0.

Wytrenowany model jest legalnie dostepny do uzytku komercyjnego pod warunkiem zachowania atrybucji do zrodel danych i pretrenowanych wag.