Model ma w raporcie wynik bliski ideału, a na linii przepuszcza wady albo odrzuca dobre sztuki. Najczęstsza przyczyna nie leży w samym modelu, tylko w danych: zbiór testowy był zbyt podobny do treningowego. To tak zwany przeciek — informacja z treningu przenika do testu, a test zamiast zdolności radzenia sobie z nową sztuką mierzy pamięć modelu.
W artykule Ile zdjęć potrzeba, żeby wytrenować inspekcję AI? pisaliśmy, że zbiór testowy musi być niezależny. Tutaj o tym, jak tę niezależność traci się po cichu — nawet wtedy, gdy obrazy są formalnie rozdzielone, a nikt niczego nie robił źle.
Przeciek pierwszy: to samo ujęcie w dwóch zbiorach
Najprostszy przypadek to ten sam plik zaimportowany dwa razy — na przykład raz z folderu z linii, a drugi raz z kopii na dysku sieciowym, pod inną nazwą. Jeden trafia do treningu, drugi do testu, a model w teście „rozpoznaje” obraz, który już widział. Dlatego Trainer liczy przy imporcie sumę SHA-256 każdego pliku i pomija duplikaty, nawet gdy pliki mają różne nazwy.
Przeciek drugi: klatki jednego nagrania i ujęcia jednej sztuki
Znacznie częstszy i trudniejszy do zauważenia jest przypadek nagrania wideo rozbitego na klatki. Sąsiednie klatki różnią się minimalnie — to w praktyce ten sam obraz. Jeśli losowy podział wyśle część z nich do treningu, a część do testu, model w teście ocenia sztukę, którą widział ułamek sekundy wcześniej. Wynik wygląda świetnie, ale o zachowaniu na nowej sztuce mówi niewiele.
To samo dotyczy kilku zdjęć jednego egzemplarza: z różnych stron, przy innym ustawieniu, w kolejnych podejściach. W Trainerze ujęcia tego samego detalu i klatki jednego nagrania tworzą grupy produktu i sesji, a cała grupa zawsze trafia do jednego zbioru. Podział odbywa się na poziomie sztuk i sesji, a nie pojedynczych plików.
Przeciek trzeci: test z tej samej godziny co trening
Nawet bez powtórzonych sztuk zbiór testowy może być zbyt jednorodny: wszystkie obrazy z jednej zmiany, jednej partii surowca i jednego ustawienia oświetlenia. Model zdaje test, bo test wygląda dokładnie jak trening. Na linii spotka inną partię, innego operatora i optykę, która przez tydzień zdążyła się zabrudzić.
Zbioru testowego nie warto więc dobierać na końcu, „z tego, co zostało”. Lepiej od początku zaplanować, że obejmie inne partie, zmiany i dni niż trening. Dodatkowym sprawdzianem jest test na nagraniu z docelowej kamery: co najmniej 10 minut obejmujących dobre produkty, każdy znany defekt, kilka produktów naraz i częściowe przesłonięcia — tą samą ścieżką inferencji, której użyje stanowisko na linii.
Obraz „bez wad” też trzeba obejrzeć
Zbiór obrazów bez defektów łatwo zapełnić automatycznie: wszystko, czego nikt nie oznaczył, uznać za dobre. To pułapka. Wśród nieoznaczonych obrazów prawie zawsze są wady, których nikt nie zauważył. Model uczy się wtedy, że taka wada jest normalna, a test z tymi samymi błędami w etykietach tego nie wykaże — oba zbiory mylą się w ten sam sposób.
Dlatego w Trainerze obraz bez defektu trzeba świadomie potwierdzić jako negatywny. Model nie uczy się na obrazach, których nikt nie obejrzał.
Kontrola zbioru, zanim ruszy trening
Część problemów z danymi widać, zanim zostanie zużyta pierwsza godzina pracy karty graficznej. Trainer sprawdza zbiór przed treningiem:
- rozkład klas — z ostrzeżeniem, gdy któryś defekt jest niedoreprezentowany,
- bardzo małe ramki, które zwykle oznaczają pomyłkę przy anotacji,
- obrazy bez produktu w kadrze,
- gotowe zbiory w formatach Pascal VOC, YOLO, COCO, LabelMe i VIA — przy błędzie import zatrzymuje się i pokazuje problematyczny obraz, zamiast po cichu przyjąć złe ramki.
Zamrożony zbiór: wynik, który się nie zmienia
Ostatni rodzaj przecieku jest organizacyjny: dane zmieniają się po treningu. Ktoś poprawia anotacje, dokłada obrazy, przenosi plik między zbiorami — a raport sprzed tygodnia nadal opisuje model, choć dotyczy już innych danych. Gorzej, gdy poprawki robi się „pod wynik testu”, aż test zacznie wyglądać dobrze. Wtedy zbiór testowy przestaje być testem i staje się drugim zbiorem treningowym, tyle że dopasowywanym ręcznie.
Trening w Trainerze zawsze korzysta z zamrożonej wersji zbioru. Późniejsze poprawki nie zmieniają wyników, które już widziałeś — po zmianach przygotowujesz nową wersję. A przy tworzeniu pakietu na linię Trainer sprawdza odcisk zbioru danych: jeśli obrazy lub anotacje zmieniły się po treningu, pakiet nie powstanie.
Walidacja wybiera, test tylko raportuje
Automatyczny trening wykonuje kolejne próby i zostawia najlepszy model — ale wybiera go wyłącznie na zbiorze walidacyjnym. Zbiór testowy nie bierze udziału w żadnej decyzji, tylko raportuje wynik na obrazach, których model nie widział. Gdyby najlepszą próbę wybierać według testu, test stałby się częścią treningu: ten sam przeciek, tylko o krok dalej.
Dopiero liczby z niezależnego testu — czułość, precyzja, błędne akceptacje i błędne odrzucenia — nadają się do ustawienia progu decyzji. Jak to zrobić, opisujemy w artykule Błędna akceptacja czy błędne odrzucenie?.
Sześć pytań, zanim zaufasz wynikowi
- Czy ten sam egzemplarz albo to samo nagranie może być jednocześnie w treningu i w teście?
- Czy zbiór testowy obejmuje inne partie, zmiany i dni niż treningowy?
- Czy każdy obraz „bez wad” ktoś naprawdę obejrzał?
- Czy wynik pochodzi z zamrożonej wersji danych, która od treningu się nie zmieniła?
- Czy najlepszy model wybrano na walidacji, a test tylko raportuje?
- Czy wynik sprawdzono także na nagraniu z docelowej kamery?
Te zabezpieczenia są wbudowane w AIVQC Trainer, ale żadne narzędzie nie zastąpi dobrze zaplanowanego zbierania obrazów. Jeśli chcesz sprawdzić, czy Twoje dane dadzą wiarygodny wynik, zacznij od pilota: 30 dni, jedna stacja Trainer, jedno stanowisko i do trzech klas defektów. Napisz do nas — pomożemy zaplanować zbieranie obrazów tak, żeby test mówił prawdę.