Ein Getränkeautomat klingt nach dem Gegenteil von KI. Für uns war er eines der lehrreichsten Projekte, weil er nichts verzeiht.
Ein Automat ist kein Server
Wenn wir ein Modell in der Cloud betreiben, haben wir alles: Rechenleistung, Speicher, Logs, die Möglichkeit, jederzeit eine neue Version einzuspielen. Wenn etwas schiefgeht, sieht man es und repariert es.
Ein Automat steht irgendwo in einem Gebäude. Er hat einen kleinen Rechner, wenig Speicher, manchmal Netz, manchmal nicht. Niemand schaut auf seine Logs. Wenn er etwas falsch erkennt, merkt man es Wochen später an den Zahlen, oder gar nicht.
Was der Automat erkennen muss
Bei Smart Vending geht es darum, dass der Automat versteht, was passiert. Was entnommen wurde, was nachgefüllt werden muss, ob etwas nicht stimmt. Das heisst: Bilder erkennen, unter schlechtem Licht, mit Spiegelungen, mit Produkten, die sich ähnlich sehen, und mit Menschen, die Dinge nicht so zurückstellen, wie sie sollten.
Meine Erfahrung: Ein Modell, das im Labor 99 Prozent erkennt, erkennt im Feld vielleicht 90. Die fehlenden neun Prozent sind die Fälle, die man im Labor nicht hatte: das Licht am Nachmittag, die neue Verpackung, der Fingerabdruck auf der Kamera.
KI am Rand
Das Modell muss auf dem Automaten laufen, nicht in der Cloud. Weil das Netz nicht immer da ist, weil die Antwort sofort kommen muss, und weil man nicht für jeden Griff in den Automaten einen API-Aufruf bezahlen will.
Das bringt dieselben Fragen wie damals beim 80-MB-Modell für Apple. Wie klein kann das Modell sein, ohne schlechter zu werden? Was lässt man weg? Und wie bringt man eine neue Version auf hundert Automaten, die alle irgendwo stehen?
Die letzte Frage hat uns am meisten beschäftigt. Ein Modell nachzutrainieren ist einfach. Es sicher auf Geräte zu verteilen, die man nicht sieht, ohne dass eines davon danach nicht mehr geht, ist Betrieb. Und Betrieb ist immer die grössere Arbeit.
Was wir mitgenommen haben
Drei Dinge, die heute in jedem Projekt gelten.
Erstens: Daten aus dem Feld sind mehr wert als Daten aus dem Labor. Wir sammeln heute vom ersten Tag an, was das System in der Realität sieht, und trainieren damit nach.
Zweitens: Ein Modell, das nicht weiss, wann es unsicher ist, ist gefährlich. Der Automat muss sagen können „ich bin mir nicht sicher, was das war", statt zu raten. Das war eine Trainingsentscheidung, keine technische.
Drittens: Update-Prozesse gehören zum Produkt, nicht dahinter. Wer sie später baut, baut sie unter Druck.
Ein Automat ist die härteste Prüfung für ein Modell, weil niemand daneben steht. Wer dort ein System zum Laufen bringt, hat verstanden, was Betrieb heisst. Das hilft auch, wenn das nächste System in der Cloud läuft.
Geschrieben von mir. Die Gedanken, die Werte, die Learnings, die Fehler: alles meins. Grammatik und Rechtschreibung korrigiert ein eigenes Twin-Modell, das auf meinen Texten trainiert ist. Manchmal wird daraus ein Mix. Ich lese natürlich alles nochmal, aber niemand ist unfehlbar. Was drin bleibt, ist dann auch von mir.