Ik bleef het model repareren. Het probleem was het licht.
Het eerste getal dat ik voor deze build op het whiteboard zette, was 97 procent. Het tweede was 14.
Ze beschrijven hetzelfde model. In het stampvoorbeeld uit ons onderzoek gaat een visionmodel dat in het lab is gevalideerd op 97% nauwkeurigheid de lijn op bij een progressieve matrijspers van 200 ton die 40 slagen per minuut draait, en begint het 14% van de goede onderdelen onterecht af te keuren. Binnenin het model is niets veranderd. De inputs wel: schittering van de bovenliggende hallverlichting die mee verschuift met de slaghoek, smeermiddel dat anders plassen vormt op warme matrijzen dan op koude, de eerste 50 onderdelen van elke ploegendienst die worden gemaakt voordat de pers thermisch evenwicht bereikt. De fysica van de lijn duwde de beelden uit de distributie waarop het model was gevalideerd, en geen enkel model, bij welke nauwkeurigheid dan ook, is daar buiten betrouwbaar.
Ik heb de laatste fase van dit project besteed aan het bouwen van een demo die die zin serieus neemt. Hij heet de Inspection Trust Gate, en je kunt hem onderdeel voor onderdeel laten beslissen op veriprajna.com/nl/demos/edge-ai-kwaliteitsinspectie-in-de-productie-de-inspection-trust-gate. Het is geen beter defectmodel. Het is de runtime-laag tussen het visionmodel en de PLC-afkeuractuator, en zijn enige taak is om voor elk afzonderlijk onderdeel te beslissen of het oordeel van het model is veilig om te actueren.
Wat volgt is het bouwverhaal via de drie momenten die veranderden hoe ik over inspectie-AI denk: een driftgebeurtenis op een gescripte 06:00, een benchmarkcijfer dat ik weigerde te geloven, en een regel die ik bijna verwijderde.
De oplossing is geen beter model
Ik heb die zin langer weerstaan dan nodig was. Als een detector zich misdraagt, zegt elk instinct dat ik als bouwer heb: train hem opnieuw, upgrade de backbone, koop meer labels. Het onderzoek bleef weigeren mee te werken. Kant-en-klare AOI-systemen keuren 5 tot 15% van de goede onderdelen onterecht af, en goed afgestemde systemen komen onder de 2%, wat onze oplossingspagina "een kalibratie- en dataprobleem, geen modelarchitectuurprobleem" noemt. Hetzelfde onderzoek meldt dat 84% van de systeemintegratieprojecten mislukt of gedeeltelijk mislukt, en dat in een typische inspectie-uitrol het integratiewerk 60% van de projecttijdlijn is terwijl modeltraining 15% is. De regel die ik bleef herlezen: "De hardware is een inkooporder."
Dus deed ik iets dat mild ketters voelde: ik maakte het defectmodel van de demo bewust onopvallend. Het is een kNN-afstand tot bekende-goede textuur, een PatchCore-lite-plaatsvervanger, en het scoort een AUROC van 0,845 bij het scheiden van schone goede onderdelen van defecte op de MVTec AD metal_nut held-out testsplit (echte foto's van echt gefabriceerde onderdelen, openbare labels). Ik verberg dat getal niet en ik verkoop het niet. In productie staat in dat slot jouw NVIDIA Metropolis-pijplijn, jouw Cognex-systeem, jouw custom model, achter een vaste interface. Het product is de laag rond de engine, niet de engine.
De laag begint met een vraag die geen nauwkeurigheidsmetriek beantwoordt: zit dit beeld binnen de opnamecondities waarop het model is gevalideerd? De EnvelopeDetector van de demo berekent een Mahalanobis-afstand in fysisch-signaalruimte (belichting, contrast, dynamisch bereik, een scherpteproxy, hoogfrequent detail, thermische kleurcast, saturatie, schitteringsfractie), gefit op de 220 bekende-goede trainingsbeelden en niets anders. Wanneer een onderdeel landt buiten die gevalideerde envelop, stopt de gate volledig met het vertrouwen van de modeluitvoer, hoe zelfverzekerd het model er ook over is.
Zelfs een perfect model is alleen geldig op inputs binnen zijn gevalideerde envelop.
Dat is de zin waar de hele build op hangt. Drift is een inputfout, geen modelfout, en een inputfout verschijnt nooit in je nauwkeurigheidsdashboard. Hij verschijnt in je schrootbak.
Wat gebeurt er om 06:00?
Het moment dat ik het meest vertrouw in de hele demo is een tijdstempel. De app speelt een deterministische gescripte ploegendienst af op het station "Line 3 - metal_nut press," en streamt echte MVTec AD metal_nut-foto's door de volledige pijplijn. Halverwege kruist een marker het scherm: "SHIFT CHANGE 06:00 - cold dies, bay lights on." Daarna arriveren 12 goede onderdelen, corrupt met schittering, defocus en thermische cast. Ik wil precies zijn over wat dat is: de foto's zijn echt, de drift is eerlijke beeldcorruptie die erop is toegepast, en de app labelt het als zodanig. Ik had geen stamplijn om te filmen, en anders doen alsof zou het hele punt vergiftigen.
Wat daarna gebeurt, is de reden dat de demo bestaat. De envelopmonitor gaat rood. De gate leest elk gedrift onderdeel als buiten de gevalideerde envelop en weigert het oordeel van het model de actuator te laten raken. Oordeel na oordeel komt terug als HOLD, gerouteerd naar de escalatiewachtrij voor een mens, terwijl het paneel ernaast laat zien wat een naïeve AOI zonder envelopcheck met hetzelfde beeld zou hebben gedaan: REJECT.
De eerste keer dat ik de wachtrij zag vollopen, klikte ik in een aangehouden onderdeel in de verwachting een vage "anomalie gedetecteerd"-excuus te zien. In plaats daarvan ontleedde de envelopmonitor de breach signaal voor signaal, omdat ik hem had gebouwd uit fysische metingen in plaats van embeddings, en fysische metingen kunnen zichzelf uitleggen. Op één gedrift onderdeel zit helderheid 7,6 sigma van de gevalideerde fit en draagt 87,1% van de gekwadrateerde Mahalanobis-afstand. Dat is geen model dat een gevoel heeft. Dat is een instrumentaflezing.
Aan het einde van de driftfase is het scorebord hard. De naïeve baseline heeft 12 goede onderdelen automatisch geschroot. De Trust Gate heeft nul automatisch geschroot, en houdt ze allemaal vast voor review. Dezelfde beelden, hetzelfde plaatsvervangende defectmodel, dezelfde drempels op de defectscores. Het enige verschil is dat het ene pad de input checkte voordat het de output vertrouwde.
De naïeve baseline en de gate zagen dezelfde onderdelen en hetzelfde model. Het enige verschil was toestemming om te actueren.
Over dat dollargetal, want hier beginnen demo's meestal te liegen: het paneel extrapoleert het gemeten naïeve onterechte-afkeurpercentage naar een volle ploegendienst (40 slagen per minuut gedurende 8 uur is 19.200 onderdelen) tegen $2,42 per geschroot onderdeel. De $2,42 is een gesourcete orde van grootte, verankerd aan een gepubliceerde casus van een koekjesfabrikant waarbij een schrootafvalreductie van 8,7% $94K per jaar en 38.800 kg product bespaarde. Het is geen klantcijfer, en de teller is overal waar hij verschijnt als projectie gelabeld. Ik mat de onterechte afkeuringen; ik projecteerde de dollars; de UI zegt wat wat is.
Nog één ding dat ik checkte voordat ik mijn eigen driftverhaal geloofde: defecte onderdelen die tijdens de driftfase worden geïnjecteerd, worden nog steeds gevangen of geëscaleerd, nooit automatisch doorgelaten. Over de hele held-out split is dat cijfer 93 van 93. Goede onderdelen vasthouden is niets waard als slechte onderdelen in de chaos doorglippen.
Was mijn envelopcheck aan het nakijken van zijn eigen huiswerk?
Het benchmarkcijfer dat ik het meest wantrouwde, was mijn eigen beste. Toen ik het bench-script voor het eerst draaide, scheidde de envelopdetector gedrifte van schone beelden in wezen perfect. Mijn onmiddellijke reactie was geen trots. Het was achterdocht, omdat ik beide kanten van het examen had gebouwd: ik schreef de schitterings-, defocus- en thermische-cast-corrupties, en ik koos de fysische signalen waarop de detector let. Natuurlijk vangt een schitteringsdetector schittering. Een reviewer met enige tanden zou dat circulair noemen, en ze zouden gelijk hebben.
Dus hield ik één driftfamilie volledig buiten. De detector is nooit afgestemd tegen onderbelichting, heeft die tijdens ontwikkeling nooit gezien. Daarna draaide ik bench.py opnieuw (meest recent op 2026-07-17) op de MVTec AD metal_nut held-out testsplit: 22 goede onderdelen, 93 defecte, train-fit alleen op de 220 goede beelden. Op de held-out underexpose-familie scoorde de envelopdetector AUROC 1.000. Dat is het getal dat de these draagt, juist omdat het is verdiend op een faalmodus waarvoor ik nooit heb geëngineerd. Het script print "THESIS HOLDS" alleen als de gemeten cijfers de claim daadwerkelijk ondersteunen; ik schreef het zo zodat de marketing niet kon wegdrijven van de meting.
De rest van de benchmark verdient zijn exacte scope, dus hier is hij zonder afronden in mijn voordeel. Op gedrifte goede onderdelen keurt de naïeve baseline zonder envelop 95,5 tot 100% per driftfamilie onterecht af (schittering 100%, defocus 100%, thermische cast 100%, underexpose 95,5%, gemiddeld 98,9%). De Trust Gate keurt 0,0% ervan onterecht af en houdt elk vast voor review. En de eerlijke kanttekening: de corrupties zijn op volle sterkte, dus de ineenstorting van de baseline is bijna totaal per constructie. De claim die ik zal verdedigen is de richting, dat een schoon gevalideerd model instort zodra inputs zijn envelop verlaten, niet het specifieke percentage. Dit zijn metingen op een onderzoeksbenchmark onder synthetische drift. Het zijn geen open-world-garanties, en wie ze citeert als productieprestatie misbruikt ze, ikzelf inbegrepen.
De regel die ik bijna verwijderde
De moeilijkste eerlijkheidskeuze die ik in deze build maakte, ging over een regel die nauwelijks werkt. Vroeg in het traject voegde ik een geometrische zoneregel toe: lokaliseer de anomalie op een grof 8-bij-8-raster, en behandel een defect binnen de functionele zone anders dan een vlek buiten aan de cosmetische rand. Het klinkt als echte metrologie. Toen mat ik het, en de metingen waren vernederend. De lokale-ruwheidsproxy lokaliseert een anomalie op 33 van 93 held-out defecten, ongeveer 35%. Hij verandert de uitkomst van de gate op precies 1 van 93. En 0 van de 18 automatische afkeuringen worden gedragen door een echte gelokaliseerde anomalie; wanneer niets lokaliseert, valt de centroid terug naar het rastercentrum, dat standaard als in-zone leest.
Ik zat met drie opties. Verwijder de regel en doe alsof ik het nooit heb geprobeerd. Houd hem en laat de UI precisie-metrologie suggereren die ik niet heb. Of houd hem en laat de interface bekennen. Ik koos de bekentenis. Wanneer het hero-defect van de demo automatisch afkeurt (onderdeel test-flip-264, een echt grof structureel defect uit de MVTec flip-klasse), stelt de geometry drill-in ronduit dat er op dit onderdeel niets is gelokaliseerd en dat de afkeuring alleen op textuurconfidence rust.
De regel verdient precies één keer zijn plek, en ik liet de app dat bewijzen in plaats van het in scène te zetten. Bij opstarten zoekt de demo alle 93 held-out defecten af naar een onderdeel met een echt gelokaliseerde anomalie buiten de functionele zone op een verder confident onderdeel. In de geleverde split vindt die zoektocht test-flip-251, centroid op rij 2, kolom 6, en de gate routeert het naar HOLD in plaats van de actuator af te vuren. Als de data veranderde en geen onderdeel kwalificeerde, zou die beat simpelweg niet verschijnen. Ik A/B-testte zelfs de sigma-drempel van de regel met 5-voudige kruisvalidatie; de gefitte waarde toonde geen verbetering ten opzichte van de handmatig gezette 2,5, dus hield ik 2,5 en legde het negatieve resultaat vast in de repo met "shipped": false. In een productie-engagement wordt deze regel vervangen door pixel-accurate, CAD-gegronde metrologie. In de demo is het een eerlijke plaatsvervanger, en de UI zegt dat op elk onderdeel.
Een trust-laag die zichzelf oververkoopt is een tegenspraak in termen.
Die regel werd een ontwerpregel. Als de hele belofte van het product is te weten wanneer je een model niet moet vertrouwen, kan het niet tegelijk bluffen over zijn eigen zwakste component.
Agents adviseren, code beslist
De beslissing die ik weiger te delegeren, is degene die metaal beweegt. De gate zelf is gewoon deterministische code, buiten elke LLM en ook buiten het visionmodel. Zijn drempels zijn gefit uit de eigen data van de demo, niet met de hand gewuifd: auto-pass onder 0,948 en auto-reject boven 1,30 op de gekalibreerde confidence-schaal, met alles ertussen, en alles buiten de envelop, naar HOLD. Hij draait tegen een hard slagvensterbudget van 750 ms, en in het geleverde auditlog landen de beslissingen in tientallen milliseconden: test-good-288 auto-passed in 37,7 ms, test-good-289 in 24,4 ms, en het reject-actuatorlog voor test-flip-264 leest "REJECT actuated in 25ms (budget 750ms)."
Ik moet duidelijk zijn over wat actueert: nog niets. Het EtherNet/IP-pad naar een Allen-Bradley ControlLogix-afkeuractuator is een simulator die precies logt wat hij zou hebben gedaan, en de MES-sink is een stub die de traceerbaarheidsregel schrijft die hij zou hebben geschreven. Beide zijn in de app als stubs gelabeld. Ze zijn gevormd als de echte adapters omdat de OT-realiteit (gemengde Siemens- en Allen-Bradley-fabrieken, een afkeurvenster gemeten in milliseconden) het daadwerkelijke productoppervlak is, maar een demo die een live lijn zou suggereren, zou zijn eigen trust-test niet doorstaan.
Er zitten agents in het systeem, en ik heb ze bewust begrensd. Wanneer onderdelen zich opstapelen in de escalatiewachtrij, gaat een Drift Triage-paar aan het werk: een diagnosis-agent leest de gerangschikte fysische-signaalafwijkingen over de aangehouden onderdelen en stelt een root-cause-hypothese voor met een aanbevolen actie, en een critic-agent checkt die hypothese vervolgens tegen het numerieke bewijs en degradeert hem tot "handmatig onderzoek" als het geciteerde signaal niet daadwerkelijk de dominante afwijking is. Ze zijn gebouwd op Pydantic AI en provider-verwisselbaar, en zonder geconfigureerde API-sleutel degradeert het geheel tot een deterministische getemplated triage, zodat de demo volledig offline draait. Wat de agents niet kunnen, per constructie, is de actuator aanraken. Tegen de tijd dat ze spreken, heeft de gate al beslist.
Agents adviseren, code beslist.
Elk van die beslissingen laat een ontvangstbewijs achter. Elk onderdeel schrijft een JSONL-lineage-record: part id, station, model id metalnut-defect-knn version v7, dataset hash ae95b5b533c8, defect confidence, OOD score, de fysische signalen, welke gate-regels afvuurden, latency tegen het 750 ms-budget, de actuatie- en MES-logregels, wat de naïeve baseline zou hebben gedaan, en de risicotag high-risk:quality-gate (EU AI Act Annex III, eff. 2026-08-02). Eén klik exporteert de ploegendienst als inspection_audit.jsonl.
De regelgevende klok doet er hiertoe. De high-risk-verplichtingen van de EU AI Act worden volledig van toepassing op 2 augustus 2026, veiligheidskritische kwaliteitsbeslissingen zitten in Annex III, en de maximale boetes reiken tot €35M of 7% van de wereldwijde omzet voor de ernstigste verboden-praktijk-overtredingen. Ik wil voorzichtig zijn met mijn woorden, want precies hier doen zorgvuldige woorden ertoe: de demo is niet EU AI Act-gecertificeerd, en geen enkele demo kan dat zijn. Wat hij toont is EU-AI-Act-ready lineage, een per-beslissing-record ontworpen om als archiveerbaar bewijs te dienen in een high-risk-conformiteitsdossier, gegenereerd op lijnsnelheid in plaats van gereconstrueerd na een incident.
Wat overleeft de volgende modelupgrade?
De vraag die ik mezelf bleef stellen tijdens het bouwen was bruut voor een demomaker: als het volgende defectmodel van de klant dramatisch beter is dan mijn plaatsvervanger, doet dit alles er dan nog toe? Ik denk nu dat dat precies omgekeerd is. Deloitte voorspelt dat de adoptie van agentic AI in de maakindustrie stijgt van 6% naar 24% in 2026 (Deloitte), wat betekent dat meer modellen en meer autonomie bij meer actuatoren aankomen. Elk van die modellen zal een gevalideerde envelop hebben, en de fysica van een perslijn (schittering, koude matrijzen, thermisch evenwicht) zal inputs eruit blijven duwen. Een perfect model verandert daar niets aan, omdat de fout die de gate voorkomt een inputfout is, en de auditverplichting die hij dient is een juridische, geen modelleringsverplichting. Drift-gating, provenance en governed actuatie houden stand bij elke modelnauwkeurigheid. Dat is de eigenschap die mij overtuigde dat deze laag, en niet nóg een model, het ding was dat de moeite waard was om te bouwen; de gescripte ploegendienst op veriprajna.com/nl/demos/edge-ai-kwaliteitsinspectie-in-de-productie-de-inspection-trust-gate is mijn poging om je te laten zien hoe hij die claim onderdeel voor onderdeel verdient.
En als je het liever ziet dan mij het te laten beschrijven, hier is de founder cut, van begin tot eind.
Dus de vraag die ik zou stellen over elk inspectiemodel op jouw lijn, inclusief een van 97%, is niet "hoe nauwkeurig is het?" Het is: voor het onderdeel dat zojuist de camera passeerde, weet je of dat beeld binnen de envelop lag waarop het model is gevalideerd? Als je dat niet per onderdeel kunt beantwoorden, in milliseconden, met een record dat je aan een auditor zou kunnen overhandigen, dan denk ik niet dat je een nauwkeurigheidsprobleem hebt. Ik denk dat je een envelopprobleem hebt, en ik zou oprecht willen weten welke van de twee jouw lijn heeft.
