Der EuroTech Hong Kong Hackathon fand in München statt, was das erste leicht verwirrende Detail ist. Die EuroTech Federation bringt Studierende von mehreren europäischen technischen Universitäten zusammen, gibt ihnen einen weit gefassten industriellen Auftrag und etwa einen Tag, um etwas daraus zu machen. Das konkrete Problem durften wir uns selbst aussuchen, und wir sind bei der Halbleiterinspektion gelandet. Keiner von uns hatte vor diesem Wochenende wirklich mit Wafer-Bildgebung zu tun gehabt.
Wir haben uns zu viert zusammengetan, alle von der TUM, und am Ende von rund 24 Stunden hatten wir eine funktionierende Defekterkennungs-Workbench und einen dritten Platz im Track AI & Robotics. Das ist die ehrliche Version dessen, was wir gebaut haben, inklusive der Teile, die saubere Ingenieursarbeit waren, und der Teile, die nur mit Klebeband zusammenhielten.
Ich gehe tiefer als der übliche Hackathon-Rückblick, denn das Interessante ist nicht der Pokal, sondern die Einschränkung, in die wir gezwängt waren, und der leicht schräge Weg, auf dem wir sie umgangen haben. Falls du dich je gefragt hast, wie man maschinelles Lernen betreibt, wenn dir niemand einen beschrifteten Trainingsdatensatz liefert, ist das hier ein ganz brauchbares Beispiel.
Die Einschränkung, die das Ganze schwer macht
Wenn man noch nie über Halbleiterinspektion nachgedacht hat, ist der naheliegende Schritt, einen Klassifikator zu trainieren: ein Stapel defekter Wafer, ein Stapel sauberer, das Modell lernt den Unterschied. Das Problem ist, überhaupt an diesen Stapel beschrifteter Defekte zu kommen. Gerade bei Siliziumkarbid sind die guten annotierten Datensätze kommerziell und werden so gut wie nie öffentlich freigegeben, man kann sie also nicht einfach herunterladen. Das haben wir am eigenen Leib gespürt: Der eine solide Satz annotierter SiC-Defekt-Wafer, den wir fanden, lag hinter einem Uni-Netzwerk, das so langsam war, dass es ständig in Timeouts lief, und mehrere andere Datensätze, nach denen wir suchten, waren schlicht verschwunden und nirgendwo mehr gehostet. Und selbst wo Daten existieren, muss noch jemand jeden Defekt finden, exakt markieren, wo er liegt, und bestätigen, um welche Art es sich handelt, und dieses Beschriften ist langsam, teuer und braucht einen Experten. Am Ende hat man Berge von Bildern und fast keine Labels zum Lernen.
Es ist schlimmer als bloße Knappheit. Die Defekte, die man hat, sind extrem ungleich verteilt. Manche Fehlertypen sind häufig genug, dass man eine Handvoll gesehen hat; von anderen hat man vielleicht ein einziges Beispiel oder gar keines, weil sie für diese Prozesslinie neu sind. Ein Klassifikator, der nur auf den Defekten trainiert ist, die man zufällig gesammelt hat, ist still und leise blind für einen neuen Fehlertyp, sobald er auftaucht. Das ist eine schlechte Eigenschaft für das, was zwischen einem Defekt und einem ausgelieferten Chip steht.
Also muss sich die Sichtweise ändern. Mit zu wenigen beschrifteten Beispielen für ein normales überwachtes Modell muss man sich auf das stützen, was man hat, nämlich ein ganz gutes Gefühl dafür, wie ein guter Wafer aussieht. Saubere Wafer gibt es im Überfluss; genau das ist der Sinn einer funktionierenden Linie. Die interessante Frage ist nicht mehr „wie sieht jeder Defekt aus", sondern „wie weit ist das hier vom Normalzustand entfernt". Diese Umdeutung ist das ganze Projekt.
Few-Shot, und im Grunde trainingsfrei
Die Idee kam von Damià, und ehrlich gesagt wusste keiner von uns genau, wie wir sie umsetzen sollten, als er sie vorschlug. Wir hatten Glück: Eine Computer-Vision-Konferenz zwei Tage zuvor war voll von Papern zu genau diesem Thema, wir hatten also einen frischen Stapel Referenzen zum Abkupfern. Der Ansatz nennt sich Few-Shot-Anomalieerkennung. Man nimmt einen eingefrorenen DINOv2-Encoder, eines von Metas vortrainierten Bildmodellen, und füttert ihn mit einer Handvoll sauberer Referenzbilder. DINOv2 wurde auf einem riesigen Berg allgemeiner Bilder trainiert, kennt also bereits den Trick, ein Bild in eine reichhaltige numerische Repräsentation zu verwandeln, in der ähnlich aussehende Dinge nah beieinander landen. Wir trainieren es nie neu. Wir leihen uns nur dieses Gespür für visuelle Struktur.
Aus nur diesen wenigen „normalen" Beispielen passt man ein kompaktes Modell davon an, wie normal in dieser Repräsentation aussieht, eine Art Unterraum, in dem alle sauberen Referenzen liegen. Dann bewertet man alles andere danach, wie weit es außerhalb dieses Unterraums fällt. Ein Bildausschnitt, der wie die Referenzen aussieht, bekommt einen niedrigen Wert; ein Kratzer, ein Partikel, ein gerissener Bereich bekommt einen hohen, weil der Encoder ihn dorthin legt, wo die sauberen Beispiele nie hinkommen. Weil die Bewertung Ausschnitt für Ausschnitt über das Bild läuft, bekommt man nicht nur eine Zahl, sondern eine Heatmap, die zeigt, wo auf dem Wafer das Modell unzufrieden ist.
Die wirklich schöne Eigenschaft: es wird schärfer, je mehr Referenzbilder man hineingibt, ganz ohne Training. Auf einem öffentlichen Benchmark, den wir als Platzhalter genutzt haben, stieg die Lokalisierungsqualität stetig mit der Zahl der Referenzaufnahmen, von grob bei einem einzigen Beispiel bis scharf bei vieren. Das ist betrieblich eine bequeme Lage: man braucht kein Beschriftungsprojekt, sondern ein paar weitere bekannt-gute Wafer, also genau das, wovon eine funktionierende Linie reichlich hat. Und es gibt keinen Checkpoint, auf den man aufpassen muss, kein Gradiententraining, kein Overfitting auf die Defekte, die man zufällig gesammelt hat. Die einzigen Gewichte im ganzen System sind die des eingefrorenen Encoders.
Was die Zahlen tatsächlich gesagt haben
Die Few-Shot-Bewertung ist der clevere Teil, aber wir wollten mindestens ein Ergebnis auf echten Zieldaten statt auf einem Proxy. Der eine solide annotierte SiC-Satz, der hinter diesem kriechend langsamen Uni-Netzwerk feststeckte, kam nach langem Ringen schließlich doch durch, und auf diesen echten 4H-SiC-Photolumineszenz-Scans hat das Team einen YOLO11-Detektor mit orientierten Boxen feinabgestimmt. Damit stieg die Präzision von 58,5 % auf 66,9 % und mAP50-95 von 36,2 % auf 39,9 % gegenüber der Baseline.
Das sind keine Schlagzeilenzahlen, und ich werde sie nicht schönreden. Sie sind bescheidener, ehrlicher Fortschritt für ein Wochenende, und wichtig: gemessen auf einem nach Aufnahmesitzung gruppierten Split statt einem zufälligen. Dieser Unterschied zählt mehr, als er klingt: Wenn Kacheln aus demselben Scan über Trainings- und Testdaten hinweg durchsickern, schmeicheln einem die Metriken und bedeuten nichts. Wir haben den härteren, ehrlicheren Split genommen, und eine Defektklasse blieb hartnäckig schwach.
Wir waren auch vorsichtig damit, was wir hatten und was nicht. Ein Teil der Live-Demo lief auf einem Halbleiter-SEM-Proxy-Datensatz statt auf validierten SiC-Produktionsdaten, und das haben wir ausdrücklich aufgeschrieben, im Repo, in einem Dokument darüber, was echt und was Platzhalter war. Diese Grenze zu ziehen, war glaube ich ein Grund, warum die Jury es ernst genommen hat. Es ist ein Track über industrielle Inspektion. Die Leute, die einen bewerten, kennen den Unterschied zwischen einem Ergebnis und einem Bauchgefühl, und ein Team, das seine eigenen Grenzen markiert, wirkt wie eines, mit dem man tatsächlich etwas pilotieren könnte.
Von einem Score zu einer Entscheidung
Ein Abweichungs-Score allein nützt einem müden Ingenieur am Ende der Schicht nichts. Eine rohe Zahl wie 0,73 bedeutet ohne Kontext gar nichts, also ist der letzte Schritt, Scores in eine Entscheidung zu verwandeln. Wir haben die Scores gegen die Verteilung der sauberen Referenzen kalibriert, sodass man statt eines willkürlichen Schwellenwerts ein Gefühl dafür bekommt, wie ungewöhnlich etwas im Vergleich zu bekannt-guten Wafern ist, und das Ergebnis in drei klare Ausgänge gebündelt:
- Pass. Sitzt bequem im Normalbereich. Niemand muss sich den Wafer ansehen.
- Review. Weit genug vom Normalzustand entfernt, um einen menschlichen Blick wert zu sein, wobei die Heatmap genau auf die Region zeigt, die das Flag ausgelöst hat.
- Hold. Eindeutig daneben, wird zur gründlichen Prüfung herausgezogen, bevor es weitergeht.
Der Sinn der drei Eimer ist, menschliche Aufmerksamkeit dort einzusetzen, wo sie sich tatsächlich lohnt. Die meisten Wafer sind in Ordnung, und ein Prüfer, der alle begutachten muss, übersieht den seltenen schlechten aus reiner Langeweile. Die offensichtlichen Passes von den wirklich verdächtigen zu trennen, ist eine kleine Idee, die aus einer Modellausgabe etwas macht, mit dem ein Mensch handeln kann, und das ist der Unterschied zwischen einer Demo und einem Werkzeug.
In etwas verpackt, das man wirklich benutzen kann
Eine Bewertungsfunktion in einem Notebook überzeugt niemanden, also ging ein großer Teil des Wochenendes in die Workbench drumherum: ein Next.js-Dashboard, in dem man einen Wafer lädt, die Heatmap sieht, einen Score und eine Triage-Entscheidung bekommt und vor allem den Weg zurück zu den Belegen hinter jeder Entscheidung verfolgen kann. Welche Referenzbilder normal definiert haben, welche Vorverarbeitung lief, welche Modellkonfiguration die Entscheidung erzeugt hat. Für ein Inspektionswerkzeug zählt das mehr als eine hübsche Oberfläche, denn ein Ingenieur vertraut keiner Zahl, die er nicht hinterfragen kann, und „die KI hat es gesagt" ist keine Antwort, die jemand abzeichnet.
Mein Teil, und die Leute, die es getragen haben
Ich will ehrlich sein, wer was gemacht hat, denn es war ein Team, und die ML-Tiefe war nicht meine. Mein Anteil war die Frontend- und Produktseite: die Workbench aufbauen, die Demo unter Druck zum Laufen bringen und das Repository in einer Form halten, aus der wir tatsächlich präsentieren konnten. Die tiefe Modellierungsarbeit, die DINOv2- und PCA-Pipeline, die Validierung, der echte SiC-Detektor, kam von Damià und Jakob zusammen auf der ML-Seite. Sparsh hat den Pitch und die geschäftliche Einordnung geformt, die einen Haufen Metriken in eine Geschichte verwandelt haben, der eine Jury in zwei Minuten folgen konnte.
Mit Leuten zu arbeiten, die in ihrem Teil des Problems wirklich besser sind als man selbst, ist die beste Art, ein Wochenende zu verbringen. Man kommt schneller voran, verwirft seine schlechtesten Ideen früher und nimmt eine Domäne nebenbei auf, für die man allein Wochen gebraucht hätte. Ein guter Teil dessen, was ich jetzt darüber weiß, wie Chips inspiziert werden, habe ich in vierundzwanzig Stunden gelernt, neben jemandem sitzend, der es erklärte, während wir beide auf einen Wafer-Scan starrten, der nicht mitspielen wollte.
Vierundzwanzig Stunden, und dann eine Bühne
Der Bau selbst war der übliche Hackathon-Verlauf, zusammengestaucht. Ein selbstbewusster Plan in den ersten Stunden, in denen alles offensichtlich scheint und die Architektur im Kopf sauber ist. Dann die lange Mitte, die stille Panik, in der die Daten nicht so laden, wie man angenommen hat, das Modell Müll bewertet und die Demo, die man auf eine Serviette gekritzelt hat, plötzlich drei Integrationsbugs davon entfernt ist, überhaupt zu existieren.
Und dann die Phase gegen Ende, in der es schneller zusammenfindet, als es auseinandergefallen ist, und man sich erinnert, warum man sich das immer wieder antut. Wir brachten die Heatmaps zum Rendern, die Triage-Entscheidungen sauber hin, die Belegspur zum Durchklicken und einen Pitch, der vom Problem über die Few-Shot-Idee bis zu den echten Zahlen führte, ohne irgendetwas davon zu übertreiben. Zwei Minuten auf der Bühne, eine Runde Fragen, auf die wir uns tatsächlich vorbereitet hatten, und dann das Warten.
Dritter Platz bei AI & Robotics. Für eine Domäne, die wir am selben Wochenende kennengelernt hatten, gegen Teams, die ihren Bereich offensichtlich aus dem Effeff kannten, nehme ich das gern. Mit einem Bildschirm voller Feuerwerk hinter einem grinsenden Team auf einer Bühne zu stehen, ist eine sehr spezifische Art von gut.
Was ich mitgenommen habe
Ein paar Dinge sind hängengeblieben. Das erste ist, wie vollständig Foundation-Modelle verändert haben, was ein kleines Team mit fast keinen beschrifteten Daten schaffen kann. Ein eingefrorener Encoder und eine Handvoll sauberer Bilder haben uns ein brauchbares Defektsignal in einer Domäne geliefert, die wir nicht kannten, was vor wenigen Jahren ein Forschungsprojekt gewesen wäre, kein Wochenende. Der Hebel, den einem diese Modelle in die Hand geben, ist wirklich seltsam, sobald man ihn direkt spürt.
Das zweite ist, dass Ehrlichkeit nicht das Gegenteil eines guten Pitches ist. Ich war halb darauf gefasst, dass es uns kostet, unsere Proxy-Daten und unsere schwache Klasse zuzugeben, und das Gegenteil passierte. Genau zu sein, was echt und was Platzhalter war, hat das Ganze überzeugender gemacht, weil es signalisierte, dass die Ergebnisse, die wir beanspruchten, solche waren, denen wir tatsächlich vertrauten. Sorgfalt liest sich für jeden, der das Feld kennt, als Selbstvertrauen, nicht als Schwäche.
Und das letzte ist einfach, dass ein gutes Team eine clevere Idee schlägt. Diesmal hatten wir beides, aber wenn ich wählen müsste, würde ich jedes Wochenende die vier Leute wählen, nicht die Architektur. Danke an die EuroTech Federation für die Veranstaltung und an Damià, Jakob und Sparsh dafür, dass sie vierundzwanzig Stunden wirklich vergnüglich gemacht haben.
