Ich habe immer wieder versucht, das Modell zu reparieren. Das Problem war das Licht.
Die erste Zahl, die ich für diesen Build an die Whiteboard-Wand schrieb, war 97 Prozent. Die zweite war 14.
Sie beschreiben dasselbe Modell. Im Stanzbeispiel aus unserer Research validiert ein Vision-Modell im Labor mit 97 % Genauigkeit, geht dann an eine 200-Tonnen-Progressivwerkzeugpresse mit 40 Hüben pro Minute und beginnt, 14 % der guten Teile falsch auszusondern. Im Modell selbst hat sich nichts geändert. Die Eingaben schon: Blendung durch Deckenbeleuchtung in der Halle, die mit dem Hubwinkel wandert, Schmierstoff, der sich auf warmen Werkzeugen anders sammelt als auf kalten, die ersten 50 Teile jeder Schicht, bevor die Presse das thermische Gleichgewicht erreicht. Die Physik der Linie hat die Bilder aus der Verteilung herausbewegt, auf der das Modell validiert wurde — und kein Modell, bei welcher Genauigkeit auch immer, ist dort draußen vertrauenswürdig.
Den letzten Abschnitt dieses Projekts habe ich damit verbracht, eine Demo zu bauen, die diesen Satz ernst nimmt. Sie heißt Inspection Trust Gate, und Sie können zusehen, wie sie Teil für Teil entscheidet, unter veriprajna.com/de/demos/edge-ai-qualitatsprufung-in-der-fertigung-das-inspection-trust-gate. Es ist kein besseres Defektmodell. Es ist die Runtime-Schicht zwischen dem Vision-Modell und dem SPS-Ausschussaktor, und ihre einzige Aufgabe ist zu entscheiden, für jedes einzelne Teil, ob das Verdict des Modells sicher betätigbar.
Was folgt, ist die Build-Story anhand der drei Momente, die verändert haben, wie ich über Inspection-KI denke: ein Drift-Ereignis um ein skriptiertes 06:00, eine Benchmark-Zahl, der ich nicht glauben wollte, und eine Regel, die ich fast gelöscht hätte.
Die Lösung ist kein besseres Modell
Ich habe mich länger gegen diesen Satz gewehrt, als ich sollte. Wenn ein Detektor sich falsch verhält, sagt jeder Instinkt in mir als Builder: neu trainieren, Backbone upgraden, mehr Labels kaufen. Die Research hat sich beharrlich geweigert mitzuspielen. Out-of-the-box-AOI-Systeme sondern 5 bis 15 % guter Teile falsch aus, gut abgestimmte kommen unter 2 % — was unsere Solution-Seite „ein Kalibrierungs- und Datenproblem, kein Architekturproblem des Modells“ nennt. Dieselbe Research berichtet, dass 84 % der Systemintegrationsprojekte scheitern oder teilweise scheitern, und dass in einem typischen Inspection-Deployment die Integrationsarbeit 60 % der Projektzeit ausmacht, während das Modelltraining 15 % beträgt. Die Zeile, die ich immer wieder las: „Die Hardware ist ein Bestellauftrag.“
Also tat ich etwas, das sich leicht ketzerisch anfühlte: Ich machte das Defektmodell der Demo absichtlich unspektakulär. Es ist eine kNN-Distanz zur Known-Good-Textur, ein PatchCore-lite-Platzhalter, und erreicht einen AUROC von 0,845 bei der Trennung sauberer guter Teile von defekten auf dem gehaltenen Test-Split von MVTec AD metal_nut (echte Fotos echter gefertigter Teile, öffentliche Labels). Ich verstecke diese Zahl nicht und verkaufe sie nicht. In der Produktion sitzt in diesem Slot Ihre NVIDIA-Metropolis-Pipeline, Ihr Cognex-System, Ihr Custom-Modell — hinter einer festen Schnittstelle. Das Produkt ist die Schicht um die Engine herum, nicht die Engine.
Die Schicht beginnt mit einer Frage, die keine Genauigkeitsmetrik beantwortet: Liegt dieses Bild innerhalb der Aufnahmebedingungen, auf denen das Modell validiert wurde? Der EnvelopeDetector der Demo berechnet eine Mahalanobis-Distanz im Raum physikalischer Signale (Belichtung, Kontrast, Dynamikumfang, ein Schärfe-Proxy, Hochfrequenzdetail, thermischer Farbstich, Sättigung, Blendanteil), gefittet ausschließlich auf den 220 Known-Good-Trainingsbildern. Liegt ein Teil außerhalb dieses validierten Envelope, stellt das Gate das Vertrauen in die Ausgabe des Modells vollständig ein — egal wie sicher sich das Modell fühlt.
Selbst ein perfektes Modell ist nur auf Eingaben innerhalb seines validierten Envelope gültig.
Das ist der Satz, an dem der gesamte Build hängt. Drift ist ein Eingabefehler, kein Modellfehler — und ein Eingabefehler erscheint nie in Ihrem Genauigkeits-Dashboard. Er erscheint in Ihrem Ausschussbehälter.
Was passiert um 06:00?
Der Moment, dem ich in der ganzen Demo am meisten vertraue, ist ein Zeitstempel. Die App spielt eine deterministisch skriptierte Schicht an der Station „Line 3 - metal_nut press“ ab und streamt echte MVTec-AD-metal_nut-Fotografien durch die volle Pipeline. Zwischendurch kreuzt ein Marker den Bildschirm: „SHIFT CHANGE 06:00 - cold dies, bay lights on.“ Dann kommen 12 gute Teile, korrumpiert mit Blendung, Defokus und thermischem Farbstich. Ich will präzise sein, was das ist: Die Fotografien sind echt, der Drift ist ehrliche Bildkorruption, die darauf angewendet wird, und die App kennzeichnet ihn als solchen. Ich hatte keine Stanzlinie zum Filmen, und etwas anderes vorzutäuschen würde den ganzen Punkt vergiften.
Was als Nächstes geschieht, ist der Grund, warum die Demo existiert. Der Envelope-Monitor wird rot. Das Gate liest jedes gedriftete Teil als außerhalb des validierten Envelope und lässt das Verdict des Modells den Aktor nicht berühren. Verdict um Verdict kommt zurück als HOLD, weitergeleitet in die Eskalationswarteschlange an einen Menschen, während das Panel daneben zeigt, was eine naive AOI ohne Envelope-Check mit demselben Bild gemacht hätte: REJECT.
Als ich zum ersten Mal zusah, wie sich die Warteschlange füllte, klickte ich in ein gehaltenes Teil und erwartete eine vage Ausrede wie „Anomalie erkannt“. Stattdessen zerlegte der Envelope-Monitor den Breach Signal für Signal — weil ich ihn aus physikalischen Messungen statt aus Embeddings gebaut hatte, und physikalische Messungen können sich selbst erklären. Bei einem gedrifteten Teil sitzt die Helligkeit 7,6 Sigma vom validierten Fit entfernt und trägt 87,1 % der quadrierten Mahalanobis-Distanz. Das ist kein Modell, das ein Gefühl hat. Das ist eine Instrumentenablesung.
Am Ende der Drift-Phase ist die Anzeigetafel gnadenlos. Die naive Baseline hat 12 gute Teile automatisch ausgesondert. Das Trust Gate hat automatisch ausgesondert: null — alle zur Prüfung gehalten. Dieselben Bilder, dasselbe Platzhalter-Defektmodell, dieselben Schwellen auf dem Defekt-Score. Der einzige Unterschied: Ein Pfad hat die Eingabe geprüft, bevor er der Ausgabe vertraut hat.
Die naive Baseline und das Gate sahen dieselben Teile und dasselbe Modell. Der einzige Unterschied war die Erlaubnis zu betätigen.
Zu dieser Dollarziffer, denn hier fangen Demos gewöhnlich an zu lügen: Das Panel extrapoliert die gemessene naive False-Reject-Rate auf eine volle Schicht (40 Hübe pro Minute über 8 Stunden sind 19.200 Teile) zu 2,42 $ pro ausgesondertem Teil. Die 2,42 $ sind eine belegte Größenordnung, verankert an einem veröffentlichten Fall eines Keksherstellers, bei dem eine Reduktion der Ausschussverschwendung um 8,7 % 94.000 $ pro Jahr und 38.800 kg Produkt sparte. Es ist keine Kundenzahl, und der Zähler ist überall, wo er erscheint, als Projektion gekennzeichnet. Ich habe die False Rejects gemessen; ich habe die Dollars projiziert; die UI sagt, was was ist.
Noch etwas habe ich geprüft, bevor ich meiner eigenen Drift-Story glaubte: Defekte Teile, die während der Drift-Phase eingeschleust werden, werden weiterhin erkannt oder eskaliert, nie automatisch durchgelassen. Über den gesamten gehaltenen Split liegt diese Zahl bei 93 von 93. Gute Teile zu halten ist wertlos, wenn schlechte Teile im Chaos durchrutschen.
Hat mein Envelope-Check seine eigene Hausaufgabe benotet?
Die Benchmark-Zahl, der ich am meisten misstraute, war meine eigene beste. Als ich das Bench-Skript zum ersten Mal laufen ließ, trennte der Envelope-Detektor gedriftete von sauberen Bildern im Wesentlichen perfekt. Meine sofortige Reaktion war kein Stolz. Es war Argwohn — weil ich beide Seiten der Prüfung gebaut hatte: Ich hatte die Blend-, Defokus- und Thermal-Cast-Korruptionen geschrieben und die physikalischen Signale gewählt, die der Detektor beobachtet. Natürlich fängt ein Blendungsdetektor Blendung. Ein Reviewer mit Biss würde das zirkulär nennen, und er hätte recht.
Also hielt ich eine Drift-Familie vollständig heraus. Der Detektor wurde nie gegen Unterbelichtung getunt, sah sie während der Entwicklung nie. Dann ließ ich erneut bench.py laufen (zuletzt am 2026-07-17) auf dem gehaltenen Test-Split von MVTec AD metal_nut: 22 gute Teile, 93 defekte, Trainings-Fit nur auf den 220 guten Bildern. Auf der gehaltenen Underexpose-Familie erzielte der Envelope-Detektor AUROC 1.000. Das ist die Zahl, die die These trägt — gerade weil sie an einem Fehlermodus verdient wurde, den ich nie dafür konstruiert hatte. Das Skript druckt „THESIS HOLDS“ nur, wenn die gemessenen Zahlen die Behauptung tatsächlich stützen; ich habe es so geschrieben, damit das Marketing nicht von der Messung abdriften kann.
Der Rest des Benchmarks verdient seinen exakten Scope, also hier ohne Rundung zu meinen Gunsten. Bei gedrifteten guten Teilen weist die naive Baseline ohne Envelope 95,5 bis 100 % je Drift-Familie falsch aus (Blendung 100 %, Defokus 100 %, Thermal Cast 100 %, Underexpose 95,5 %, im Schnitt 98,9 %). Das Trust Gate weist 0,0 % davon falsch aus und hält jedes zur Prüfung. Und der ehrliche Vorbehalt: Die Korruptionen sind in voller Stärke, daher ist der Kollaps der Baseline nahezu total konstruktionsbedingt. Die Behauptung, die ich verteidigen werde, ist die Richtung — dass ein sauber validiertes Modell kollabiert, sobald Eingaben seinen Envelope verlassen —, nicht der konkrete Prozentsatz. Das sind Messungen auf einem Research-Benchmark unter synthetischem Drift. Sie sind keine Open-World-Garantien, und wer sie als Produktionsleistung zitiert, missbraucht sie — mich eingeschlossen.
Die Regel, die ich fast gelöscht hätte
Die härteste Ehrlichkeit in diesem Build galt einer Regel, die kaum funktioniert. Früh fügte ich eine geometrische Zonenregel hinzu: die Anomalie auf einem groben 8-mal-8-Gitter lokalisieren und einen Defekt in der funktionalen Zone anders behandeln als einen Schönheitsfehler am kosmetischen Rand. Das klingt nach echter Metrologie. Dann habe ich gemessen, und die Messungen waren demütigend. Der Local-Roughness-Proxy lokalisiert eine Anomalie bei 33 von 93 gehaltenen Defekten, etwa 35 %. Er ändert das Outcome des Gates bei genau 1 von 93. Und 0 der 18 Auto-Rejects sind durch eine echte lokalisierte Anomalie gestützt; wenn nichts lokalisiert, fällt der Zentroid auf die Gittermitte zurück, die standardmäßig als in-zone gelesen wird.
Ich saß vor drei Optionen. Die Regel löschen und so tun, als hätte ich nie versucht. Sie behalten und die UI Präzisionsmetrologie implizieren lassen, die ich nicht habe. Oder sie behalten und das Interface gestehen lassen. Ich wählte das Geständnis. Wenn der Hero-Defekt der Demo automatisch aussondert (Teil test-flip-264, ein echter grober Strukturdefekt aus der MVTec-Flip-Klasse), stellt der Geometry-Drill-in klar, dass an diesem Teil nichts lokalisiert wurde und der Reject allein auf Textur-Konfidenz beruht.
Die Regel verdient sich genau einmal ihren Platz, und ich ließ die App das beweisen statt es zu inszenieren. Beim Start sucht die Demo alle 93 gehaltenen Defekte nach einem Teil mit einer echt lokalisierten Anomalie außerhalb der funktionalen Zone an einem sonst konfidenten Teil. Im ausgelieferten Split findet diese Suche test-flip-251, Zentroid bei Zeile 2, Spalte 6, und das Gate leitet es zu HOLD statt den Aktor zu feuern. Wenn sich die Daten änderten und kein Teil qualifizierte, würde dieser Beat einfach nicht erscheinen. Ich habe den Sigma-Schwellenwert der Regel sogar mit 5-facher Kreuzvalidierung A/B-getestet; der gefittete Wert zeigte keine Verbesserung gegenüber dem handgesetzten 2,5, also behielt ich 2,5 und dokumentierte das Negativresultat im Repo mit "shipped": false. In einem Produktionsengagement wird diese Regel durch pixelgenaue, CAD-gestützte Metrologie ersetzt. In der Demo ist sie ein ehrlicher Platzhalter, und die UI sagt das bei jedem Teil.
Eine Trust-Schicht, die sich selbst überverkauft, ist ein Widerspruch in sich.
Diese Zeile wurde zur Designregel. Wenn das gesamte Versprechen des Produkts ist zu wissen, wann man einem Modell nicht vertrauen darf, darf es gleichzeitig nicht über seine eigene schwächste Komponente bluffen.
Agents beraten, Code entscheidet
Die Entscheidung, die ich nicht delegiere, ist die, die Metall bewegt. Das Gate selbst ist schlichter deterministischer Code, außerhalb jedes LLM und auch außerhalb des Vision-Modells. Seine Schwellen sind aus den eigenen Daten der Demo gefittet, nicht aus der Luft gegriffen: Auto-Pass unter 0,948 und Auto-Reject über 1,30 auf der kalibrierten Konfidenzskala, alles dazwischen und alles außerhalb des Envelope geht auf HOLD. Es läuft gegen ein hartes 750-ms-Hubfenster-Budget, und im ausgelieferten Audit-Log landen die Entscheidungen in Zehnteln von Millisekunden: test-good-288 auto-passed in 37,7 ms, test-good-289 in 24,4 ms, und der Reject-Aktor-Log für test-flip-264 lautet „REJECT actuated in 25ms (budget 750ms).“
Ich sollte klar sagen, was betätigt: noch nichts. Der EtherNet/IP-Pfad zu einem Allen-Bradley-ControlLogix-Ausschussaktor ist ein Simulator, der genau protokolliert, was er getan hätte, und die MES-Senke ist ein Stub, der die Traceability-Zeile schreibt, die er geschrieben hätte. Beide sind in der App als Stubs gekennzeichnet. Sie sind wie die echten Adapter geformt, weil die OT-Realität (gemischte Siemens- und Allen-Bradley-Werke, ein Ausschussfenster gemessen in Millisekunden) die eigentliche Produktoberfläche ist — aber eine Demo, die eine Live-Linie suggerierte, würde ihren eigenen Trust-Test nicht bestehen.
Es gibt Agents im System, und ich habe sie absichtlich begrenzt. Wenn Teile sich in der Eskalationswarteschlange stapeln, geht ein Drift Triage-Paar an die Arbeit: Ein Diagnose-Agent liest die rangierten Abweichungen physikalischer Signale über die gehaltenen Teile und schlägt eine Root-Cause-Hypothese mit empfohlener Aktion vor, und ein Critic-Agent prüft diese Hypothese dann gegen die numerische Evidenz und stuft sie auf „manuelle Untersuchung“ herab, wenn das zitierte Signal nicht tatsächlich die dominante Abweichung ist. Sie sind auf Pydantic AI gebaut und Provider-austauschbar, und ohne konfigurierten API-Key degradiert das Ganze zu einer deterministischen Template-Triage, sodass die Demo voll offline läuft. Was die Agents konstruktionsbedingt nicht können: den Aktor berühren. Bis sie sprechen, hat das Gate bereits entschieden.
Agents beraten, Code entscheidet.
Jede dieser Entscheidungen hinterlässt eine Quittung. Jedes Teil schreibt einen JSONL-Lineage-Record: Teil-ID, Station, Modell-ID metalnut-defect-knn Version v7, Dataset-Hash ae95b5b533c8, Defekt-Konfidenz, OOD-Score, die physikalischen Signale, welche Gate-Regeln gefeuert haben, Latenz gegen das 750-ms-Budget, die Actuation- und MES-Logzeilen, was die naive Baseline getan hätte, und der Risk-Tag high-risk:quality-gate (EU AI Act Annex III, gelt. 2026-08-02). Ein Klick exportiert die Schicht als inspection_audit.jsonl.
Die regulatorische Uhr zählt hier. Die High-Risk-Pflichten des EU AI Act werden am 2. August 2026 voll anwendbar, sicherheitskritische Qualitätsentscheidungen sitzen in Annex III, und die Höchststrafen erreichen 35 Mio. € oder 7 % des weltweiten Umsatzes bei den schwersten Verstößen gegen verbotene Praktiken. Ich will vorsichtig mit meinen Worten sein, denn genau hier zählen vorsichtige Worte: Die Demo ist nicht EU-AI-Act-zertifiziert, und keine Demo kann es sein. Was sie zeigt, ist EU-AI-Act-bereite Lineage — ein Per-Decision-Record, ausgelegt als ablegbare Evidenz in einer High-Risk-Konformitätsakte, erzeugt in Liniengeschwindigkeit statt nach einem Vorfall rekonstruiert.
Was übersteht das nächste Modell-Upgrade?
Die Frage, die ich mir beim Bauen immer wieder stellte, war brutal für einen Demo-Macher: Wenn das nächste Defektmodell des Kunden dramatisch besser ist als mein Platzhalter — zählt davon dann noch etwas? Ich denke inzwischen, dass das genau rückwärts ist. Deloitte prognostiziert die Adoption von agentic AI in der Fertigung von 6 % auf 24 % im Jahr 2026 (Deloitte), was mehr Modelle und mehr Autonomie an mehr Aktoren bedeutet. Jedes dieser Modelle wird einen validierten Envelope haben, und die Physik einer Pressenlinie (Blendung, kalte Werkzeuge, thermisches Gleichgewicht) wird Eingaben weiter daraus herausbewegen. Ein perfektes Modell ändert daran nichts, denn der Fehler, den das Gate verhindert, ist ein Eingabefehler, und die Audit-Pflicht, der es dient, ist eine rechtliche, keine Modellierungsfrage. Drift-Gating, Provenance und gesteuerte Actuation halten bei jeder Modellgenauigkeit. Das ist die Eigenschaft, die mich überzeugte, dass diese Schicht — und nicht ein weiteres Modell — das war, was zu bauen sich lohnte; die skriptierte Schicht unter veriprajna.com/de/demos/edge-ai-qualitatsprufung-in-der-fertigung-das-inspection-trust-gate ist mein Versuch, Sie Teil für Teil zusehen zu lassen, wie sie diesen Anspruch verdient.
Und wenn Sie es lieber sehen als mich dabei beschreiben zu hören: Hier ist der Founder-Cut, von Anfang bis Ende.
Die Frage, die ich zu jedem Inspection-Modell an Ihrer Linie stellen würde, auch zu einem mit 97 %, lautet also nicht „wie genau ist es?“. Sondern: Für das Teil, das gerade die Kamera passiert hat — wissen Sie, ob dieses Bild innerhalb des Envelope lag, auf dem das Modell validiert wurde? Wenn Sie das nicht pro Teil, in Millisekunden, mit einem Record beantworten können, den Sie einem Auditor übergeben könnten, dann glaube ich nicht, dass Sie ein Genauigkeitsproblem haben. Ich glaube, Sie haben ein Envelope-Problem — und ich würde wirklich gerne wissen, welches Ihre Linie hat.
