Testarea viziunii computerizate în condiții reale

Definiți decizia înaintea setului de date

Operatorul vede mai multe semnalări și presupune că noua linie produce mai multe defecte. Un inginer vede o creștere a scorurilor nesigure și presupune că modelul trebuie reantrenat. Înainte să câștige vreuna dintre explicații, puneți câteva imagini originale lângă imaginile din pilot. Condițiile schimbate se pot vedea fără încă un experiment.

Porniți de la ce va face un om sau o mașină după predicție. Va respinge un articol, va prioritiza o coadă de verificare, va număra obiecte sau va cere o altă imagine? Consecința unui fals pozitiv diferă de cea a unui defect ratat. Aceste diferențe ar trebui să modeleze colectarea datelor și criteriile de lansare.

Într-o inspecție ilustrativă a ambalajelor, semnalarea fiecărei imagini nesigure poate proteja calitatea, dar poate copleși echipa de verificare. Acceptarea automată a unei predicții slabe poate micșora coada, dar poate lăsa să treacă un defect costisitor. Decizia operațională are nevoie de ambele rate de eroare și de capacitatea oamenilor care verifică rezultatele.

Evaluați condițiile pe care le vede camera de fapt

Strângeți exemple din toate camerele, schimburile, condițiile de iluminare, fundalurile și variantele de produs relevante. Păstrați evidența felului în care au fost puse etichetele și a felului în care au fost rezolvate dezacordurile. Un set de date cu imagini curate dintr-o singură instalație controlată poate să nu reprezinte locul în care va rula modelul.

WILDS adună schimbări de distribuție din lumea reală și măsoară cum se descurcă modelele în fața lor. Seturile lui de date fac tangibilă o problemă largă: datele de evaluare și cele din producție pot diferi în moduri care contează. Lecția potrivită pentru această instalație este să testați variațiile pe care le va întâlni cu adevărat.

Împărțiți datele de evaluare astfel încât imaginile aproape identice să nu treacă din setul de dezvoltare în evaluarea finală. Cadrele cu același obiect sau din aceeași secvență pot face performanța să pară mai bună decât va fi pe materiale necunoscute. Alegeți împărțirea în funcție de variația pe care trebuie s-o gestioneze sistemul din producție.

Raportați separat categoriile importante. O clasă comună și ușoară poate domina scorul general, în timp ce un defect rar, dar costisitor, rămâne slab detectat. Includeți exemple de ratări și de alarme false, ca echipa de operațiuni să le poată judeca sensul practic.

Verificați ce înseamnă scorurile de încredere în practică

Scorul unui model nu este automat o probabilitate demnă de încredere că răspunsul e corect. Guo și colegii săi studiază calibrarea rețelelor neuronale moderne și arată de ce încrederea și acuratețea se pot despărți. Un prag care pare liniștitor trebuie evaluat pe date reprezentative pentru folosirea dorită.

Alegeți pragurile împreună cu cel care răspunde de proces, folosind exemple ținute deoparte. Măsurați câte cazuri intră la verificare și ce erori rămân în afara ei. Capacitatea de verificare face parte din alegere: o coadă care crește mai repede decât o poate gestiona personalul este un eșec operațional, chiar dacă modelul e prudent.

Tratați explicit intrările necunoscute. O cameră nouă, un produs schimbat sau o imagine deteriorată pot ieși din ce a fost evaluat. Definiți când ar trebui sistemul să ceară o altă imagine, să rețină articolul sau să trimită cazul unui om.

Folosiți corecturile într-un proces controlat de îmbunătățire

Păstrați imaginea originală lângă predicție și zona sau dovezile de care are nevoie cel care verifică. Înregistrați corecturile după o regulă clară de etichetare. Evitați reantrenarea automată a unui sistem din producție la fiecare corectură; analizați datele noi și evaluați o versiune candidată înainte să înlocuiți modelul actual.

Aspectele legate de monitorizare din The ML Test Score sunt utile aici: pregătirea pentru producție include felul în care un sistem e verificat după ce a fost pus în funcțiune. Pe a doua linie din scenariul nostru, coada de verificare și condițiile de intrare ar trebui să poată fi inspectate alături de rezultatele modelului.

Monitorizați după lansare schimbările din materialele primite și volumul de verificare. Investigați o creștere a imaginilor nesigure înainte s-o tratați ca pe o problemă a modelului: poate s-a mutat o cameră, poate s-a ars un bec sau poate un furnizor a schimbat ambalajul.

Domeniul de funcționare ar trebui scris simplu: intrările acceptate, condițiile evaluate, pragurile, verificarea umană și varianta de rezervă. Extinderea acestui domeniu este o nouă decizie de inginerie, cu dovezi noi.

• Evaluați pe fiecare tip de defect și fiecare condiție de lucru.
• Nu împărțiți imagini înrudite între setul de dezvoltare și cel de test.
• Alegeți pragurile ținând cont de capacitatea de verificare.
• Versionați împreună datele, etichetele, modelul și instalarea.

Înapoi pe a doua linie

Notați condițiile schimbate și verificați dacă noua linie funcționează în condițiile acoperite de evaluare. Folosiți varianta de rezervă convenită cât timp investigați și desemnați persoana care decide când poate fi reluată funcționarea obișnuită.

Dacă noua instalație ajunge să fie acceptată, păstrați cazurile care au stabilit asta. Data viitoare când se mută o cameră sau un furnizor schimbă ambalajul, echipa ar trebui să știe ce limită trebuie revăzută. Sistemul devine mai de încredere atunci când această cunoaștere supraviețuiește oamenilor care l-au construit primii.