Warum KI im Live-Betrieb ein Evaluation-Framework braucht

Ein Modell kann im Demo-Fall überzeugend wirken aber im Betrieb trotzdem systematisch falsch liegen. Erst eine belastbare Evaluation zeigt, ob der Ansatz wirklich funktioniert.

Bei der Verwaltung von Verkaufsautomaten entsteht regelmäßig ein bekanntes Problem: Das System meldet Bestand, vor Ort ist das Fach aber leer.

Solche Phantombestände entstehen durch Fehlausgaben, nicht erfasste Entnahmen, Umkonfigurationen oder andere Abweichungen zwischen realem und gebuchtem Bestand. Die Folgen reichen von falscher Kommissionierung bis zu leeren Fächern, die das System weiterhin als gefüllt behandelt.

Unsere Lösung beginnt mit einem einfachen Schritt:

Der Servicemitarbeiter fotografiert die Automatenfront bei geöffneter Tür.

Ein Vision-Modell bewertet anschließend jedes Fach mit genau einem von drei Ergebnissen:

• PRODUCT_VISIBLE
• EMPTY
• UNCLEAR

Erst danach vergleicht deterministischer Anwendungscode das das Ergebnis mit dem Systembestand.

• Modell meldet EMPTY, Systembestand ist größer als null: Phantombestand
• Modell meldet PRODUCT_VISIBLE, Systembestand ist null: unerwarteter Bestand

Wichtig ist: Das Modell sieht die aktuellen Bestandszahlen nicht. Es soll unabhängig beschreiben, was auf dem Bild zu erkennen ist, statt eine vorhandene Systemannahme zu bestätigen.

Das eigentliche Problem ist die Zuordnung

Ob ein Fach leer oder belegt ist, ist meist nicht die schwierigste Frage für ein Vision-Modell.

Schwieriger ist:

Welches Fach wird aktuell betrachtet?

Die Automatenkonfiguration hilft dabei nur begrenzt. Sie kennt Fachbezeichnungen und logische Spannweiten, aber keine belastbare Bildgeometrie.

Drei konfigurierte Fächer mit einer Spannweite von jeweils drei ergeben beispielsweise neun logische Spalten. Physisch sichtbar können aber sechs Spiralen und nur drei tatsächliche Produktpositionen sein.

Wir testeten deshalb zunächst einen geometrischen Ansatz: Das Modell sollte Fachgrenzen als Koordinaten liefern, der Code sollte diese Bereiche anschließend dem Planogramm zuordnen und erst dann die Bestandsanalyse durchführen.

Der Prototyp scheiterte schnell.

Das Modell erzeugte gleichmäßige Raster, deren Zahlen plausibel aussahen, deren Boxen aber nicht auf den tatsächlichen Produktpositionen lagen. Zwischen zwei Läufen verschoben sich die geschätzten Regalgrenzen deutlich. Perspektive und reale Mechanik wurden durch ein idealisiertes Gitter ersetzt.

Die wichtigste Erkenntnis daraus:

Plausible Struktur ist noch keine korrekte Messung.

Seitdem geben wir dem Modell nur die Anzahl der tatsächlichen Positionen pro Regalbrett vor. Kann es eine Reihe nicht sicher in diese Anzahl zerlegen, wird sie vollständig als UNCLEAR bewertet.

Unsicherheit ist ein gültiges Ergebnis

Jedes Foto wird dreimal mit demselben Prompt analysiert.

Nur wenn zwei Läufe dasselbe Urteil liefern, wird dieses übernommen. Strittige Fälle fallen auf UNCLEAR zurück und erzeugen keinen Befund.

Das hilft gegen zufällige Schwankungen, aber nicht gegen systematische Fehler. Wenn ein Modell in allen drei Läufen denselben Bias zeigt, kann eine Mehrheitsentscheidung diesen Bias sogar verstärken.

Deshalb reicht es nicht, einzelne Beispiele anzusehen.

Man braucht eine Evaluation.

Wie die Ground Truth im Betrieb entsteht

Für jedes Foto beantwortet der Servicemitarbeiter drei kurze Kontrollfragen zu ausgewählten Fächern.

Diese Fächer werden ausgewählt, bevor die Modellanalyse startet. Das Modell kann die Auswahl und die Antworten also nicht beeinflussen.

So entsteht eine fortlaufende, unabhängige Referenzstichprobe aus dem realen Betrieb.

Zusätzlich bewertet der Mitarbeiter jeden tatsächlichen Befund:

• bestätigen
• verwerfen

Damit entstehen zwei Arten von Ground Truth:

1. Spot-Checks, auch für Fächer ohne Modellbefund
2. bestätigte oder verworfene reale Abweichungen

Der Datensatz wächst automatisch mit jeder Tour. Niemand muss separat Fotos für ein Testprojekt annotieren.

Der erste Modellvergleich

Die ersten Produktionsdaten zeigten eine deutliche Asymmetrie.

Phantombestände wurden bereits robust erkannt. Beim unerwarteten Bestand lag das Modell dagegen häufig falsch.

Der erste Verdacht war, dass sich diese Richtung anhand eines Frontfotos grundsätzlich nicht zuverlässig erkennen lässt.

Der Schattenbetrieb widerlegte diese Annahme.

Andere Modelle bewerteten dieselben Fotos deutlich besser. Die Information war also vorhanden. Nicht die Kamera war das Problem, sondern die Modellwahl.

Damit wurde aus einer Vermutung eine messbare Frage.

Die Evaluation: sechs Modelle, dieselben Fotos

Aus dem Schattenbetrieb entstand eine interne Testbench.

Sie besteht aus:

• einem festen, gelabelten Datensatz
• identischen Prompts
• demselben Drei-Läufe-Verfahren
• derselben Befundlogik
• klar definierten Metriken
• reproduzierbaren Kampagnen

Der erste größere Lauf umfasste:

• 50 Audits
• 217 Fächer mit Ground Truth
• sechs Modelle
• je eine günstigere und eine leistungsstärkere Variante pro Anbieter

Die Evaluation bestätigte zunächst die Messwerte aus dem Schattenbetrieb. Das war entscheidend: Zwei unterschiedliche Messwege führten zu demselben Bild.

Erst dadurch wurde die Testbench vertrauenswürdig genug, um Modellentscheidungen darauf zu stützen.

Das günstigere Modell war in der wichtigen Richtung genauso gut

Die wichtigste betriebliche Erkenntnis war nicht, welches Modell insgesamt die höchste Genauigkeit erreichte.

Sie lautete:

Beim Phantombestand war das günstige GPT-Modell genauso gut wie das deutlich teurere Flaggschiff.

Beide erreichten:

• 97 Prozent Präzision
• 89 Prozent Trefferquote
• 34 korrekte Befunde bei 35 Meldungen

Der Aufpreis brachte in der wirtschaftlich wichtigsten Richtung keinen Vorteil.

Er half nur beim selteneren unerwarteten Bestand. Daraus ergibt sich eine bessere Architektur als „immer das teuerste Modell verwenden“:

• günstiges Modell für den regulären Durchsatz
• stärkeres Modell nur als zweite Instanz für wenige schwierige Fälle

Evaluation optimiert damit nicht nur Qualität, sondern auch Kosten und Architektur.

Mehrheitsentscheidung schützt nicht vor systematischem Bias

Ein besonders aufschlussreiches Ergebnis lieferte das kleine Claude-Modell.

Es meldete in 217 bewerteten Fächern fast nie ein leeres Fach.

Die gespeicherten Begründungen zeigten warum: Bei einem tatsächlich leeren Fach beschrieb das Modell mehrfach das Produkt, das laut Planogramm dort liegen sollte.

Es hatte die Erwartung aus dem Prompt in eine Beobachtung verwandelt.

Einzelne Läufe erkannten das leere Fach korrekt. Zwei halluzinierende Läufe überstimmten jedoch das richtige Ergebnis.

Das zeigt:

Mehrheitsabstimmungen helfen gegen zufällige Instabilität. Gegen systematischen Bias können sie ihn zementieren.

Ohne Evaluation wäre dieser Fehler schwer zu erkennen gewesen. Das System hätte stabil gewirkt, weil sich die drei Läufe einig waren.

Das Modell bucht nicht selbst

Auch ein gut evaluiertes Modell darf in diesem Prozess nicht eigenständig Bestände verändern.

Ein Befund erscheint zunächst im Backoffice mit:

• Foto
• Fach
• Produkt
• Systembestand
• Modellurteil
• Begründung

Erst nach menschlicher Bestätigung entsteht eine reguläre Bestandskorrektur im Stock-Ledger.

Dabei werden nur Chargen berücksichtigt, die bereits zum Zeitpunkt der Fotoaufnahme im Fach lagen. Produkte, die beim späteren Restock neu eingeräumt wurden, bleiben unberührt.

Auch beim unerwarteten Bestand wird nichts automatisch eingebucht. Ohne bekannte Charge, Haltbarkeit und Einkaufspreis wäre eine solche Buchung fachlich falsch.

Evaluation ersetzt also keine Geschäftsregeln und keine Freigaben. Sie beantwortet nur eine andere Frage:

Wie verlässlich ist das Modell innerhalb dieses kontrollierten Prozesses?

Aus dem Vergleich wird eine Regressions-Evaluation

Die Testbench ist inzwischen kein einmaliger Modellvergleich mehr.

Jede relevante Änderung erhält eine eigene Kampagne:

• neuer Prompt
• neues Modell
• andere Bildvorverarbeitung
• geändertes Mehrheitsverfahren
• neue Geschäftsregel

Alle Varianten laufen gegen dieselben gespeicherten Fotos und dieselben Metriken.

Was früher mehrere Wochen Schattenbetrieb benötigt hätte, lässt sich dadurch innerhalb eines Nachmittags prüfen.

Der Datensatz wächst gleichzeitig mit neuen, zuvor ungesehenen Bildern aus dem laufenden Betrieb. Das reduziert das Risiko, den Prompt immer stärker auf einen statischen Testsatz zu optimieren.

Was wir daraus mitnehmen

Die wichtigste Komponente dieses Features ist nicht das Vision-Modell.

Es ist der Evaluation-Loop:

1. unabhängige Referenzdaten im Betrieb sammeln
2. Fehlerarten getrennt betrachten
3. Kandidatenmodelle unter identischen Bedingungen vergleichen
4. gespeicherte Begründungen für die Fehleranalyse nutzen
5. Modellwechsel reproduzierbar testen
6. Qualität, Kosten und Risiken gemeinsam bewerten

Ohne diese Evaluation hätten wir mehrere falsche Annahmen behalten:

• Die Frontkamera könne unerwarteten Bestand grundsätzlich nicht erkennen.
• Das größere Modell sei automatisch besser.
• Drei übereinstimmende Läufe seien ein Zeichen für Verlässlichkeit.
• Die konfigurierte Spaltenstruktur entspreche der sichtbaren Geometrie.

Keine dieser Annahmen hielt der Messung stand.

Für den operativen Betrieb bedeutet das heute:

Bestandsabweichungen können aus einem Foto erkannt werden, dessen Aufnahme etwa 40 Sekunden dauert. Jede tatsächliche Korrektur bleibt menschlich bestätigt, dokumentiert und im Ledger nachvollziehbar.