Der Kassenzettel als Datenquelle, und was der erste Praxistest kaputt machte

Wer einen Haushalt automatisieren will, braucht irgendwann eine Antwort auf die Frage: Was ist vorrätig, und was nicht? Die naheliegende Antwort ist, die Kassenbons zu lesen. Die ehrliche Antwort ist, dass das klingt als wäre es einfach.

Wir haben für eine Vorrats-App gebaut, was dafür nötig ist: Packungen scannen, Kassenbons aus PDF auslesen, Rezepte vorschlagen. Und wir haben gelernt, dass die erste Version des Systems und der erste echte Einkauf kaum miteinander vereinbar waren.

Was das System tut

Der Ablauf: Ein Kassenbon kommt als PDF. Ein Filter liest ihn durch und entfernt alles, was nichts über den Einkauf aussagt: Kundennummern, Kartendaten, Transaktionskennungen, Bon-IDs. Was übrig bleibt, geht an ein Sprachmodell, das die Zeilen strukturiert. Artikel, Menge, Gewicht.

Erst danach kommt der Vorrat in die Datenbank. Der Filter vor dem Modell ist kein Detail. Ein Sprachmodell, das rohe Kassenbons mit Kartendaten sieht, ist kein gutes Arbeitsgerät für etwas, das täglich genutzt wird.

Was der erste Praxistest kaputt machte

Drei Probleme, alle beim ersten echten Test aufgetreten.

Das erste: Inventur-Scans zählten als Käufe. Wer vor dem Einkauf den Vorrat einscannt, um zu wissen, was fehlt, landet mit diesen Scans im selben Eingang wie die Bons. Das System behandelte sie identisch. Resultat: Produkte, die noch da waren, erschienen als frisch gekauft und wurden nicht als fehlend markiert. Die Einkaufsvorschläge lagen danach daneben.

Das zweite: Gewichtsware kam als Dezimalzahl an. Auf dem Bon steht 0,170 für 170 Gramm Käse. Das Modell strukturierte das korrekt, aber die Datenbank speicherte es als Menge 0.170, was das System als Bruchteil einer Packung interpretierte, nicht als eine Packung Käse. Wer dann nachsieht, ob noch Käse da ist, bekommt die Antwort: kaum.

Das dritte: Die Einkaufsvorschläge drängten sich auf. Das System bemerkte, dass bestimmte Produkte regelmässig auftauchen und erinnerte daran, bevor die tatsächliche Menge bekannt war. Das führte zu Vorschlägen für Produkte, die noch im Schrank standen.

Was wir geändert haben

Inventur-Scans bekamen einen eigenen Eingang. Sie gehen nicht durch denselben Filter wie Bons, sondern durch einen separaten Pfad, der den Vorstand aktualisiert, ohne einen Kauf zu erfassen.

Gewichtsware bekommt beim Auslesen einen eigenen Typ. Das Modell liefert nicht nur eine Zahl, sondern auch, ob es sich um eine Gewichtsangabe handelt. Die Datenbank speichert dann "eine Packung Käse, 170 Gramm" und nicht "0.170 Einheiten".

Die Einkaufsvorschläge laufen jetzt erst, nachdem der aktuelle Vorstand vollständig eingelesen ist. Kein Vorschlag auf Basis von Schätzungen.

Was bleibt

Die Screenshots der App zeigen, wie das heute aussieht. Die Liste ist sauber. Die Vorschläge kommen dann, wenn sie stimmen.

Was der Test gezeigt hat, ist weniger ein Fehler im Modell als eine falsche Annahme davor: dass ein Kassenbon eindeutig ist. Er ist es nicht. Gewicht, Menge, Inventur, Kauf: Das muss das System unterscheiden können, bevor es ein Modell befragt.