Produktdaten bereinigen, ohne zu raten

Liest die Rohdaten, wendet die Regeln an und schreibt zwei Ergebnisdateien. Bricht mit einer verständlichen Meldung ab, wenn die Datei fehlt, leer ist oder eine Pflichtspalte fehlt.

A1002,Wanderrucksack 35L Blau,rucksack,
  84.90,Blau,Nylon,

A1008,Regenjacke Damen wasserdicht,
  REGENBEKLEIDUNG,,rot,,https://…/a1008.jpg

A1010,Stirnlampe LED 300 Lumen,,
  19.90,schwarz,,

A1002,Wanderrucksack 35L Blau,Rucksäcke,
  84.90,Blau,Nylon,

A1008,Regenjacke Damen Wasserdicht,
  Regenbekleidung,,rot,,https://…/a1008.jpg

A1010,Stirnlampe LED 300 Lumen,,
  19.90,schwarz,,

Auszug aus 10 Zeilen, Umbrüche zur Lesbarkeit eingefügt. Die Kategorien sind vereinheitlicht, LED bleibt groß – und die leeren Felder sind unverändert leer geblieben.

Geprüfte Datensätze: 10

Kategorien automatisch vereinheitlicht: 3
Produkte mit mindestens einer fehlenden Pflichtangabe: 9/10

Dieses Skript hat KEINE fehlenden Werte erfunden oder geschätzt.
Alles unten Gelistete braucht eine menschliche Entscheidung.

- **A1002** (Wanderrucksack 35L Blau): fehlt Bild-URL
- **A1008** (Regenjacke Damen Wasserdicht): fehlt Preis, Material
- **A1010** (Stirnlampe LED 300 Lumen): fehlt Kategorie, Material, Bild-URL

# Abkürzungen, die in Produktnamen groß bleiben sollen. Bewusst eine kurze,
# explizite Liste: Das Skript rät nicht, welches Wort eine Abkürzung ist.
ABBREVIATIONS = {"LED", "UV", "XL", "XXL"}

# Kategorie-Mapping: verschiedene Schreibweisen -> eine kanonische Kategorie
CATEGORY_MAP = {
    "rucksäcke": "Rucksäcke",
    "rucksack": "Rucksäcke",
    "trinkflaschen": "Trinkflaschen",
    "zubehör": "Zubehör",
    "zelte": "Zelte",
    "schlafsäcke": "Schlafsäcke",
    "schuhe": "Schuhe",
    "regenbekleidung": "Regenbekleidung",
}

def normalize_name(raw: str) -> str:
    """Titelcase, aber Maßeinheiten/Zahlen und bekannte Abkürzungen unangetastet."""
    if not raw:
        return raw
    words = raw.strip().split()
    fixed = []
    for w in words:
        # Wörter mit Ziffern (30l, -5°C, 44) so lassen wie sie sind
        if any(ch.isdigit() for ch in w):
            fixed.append(w)
        elif w.upper() in ABBREVIATIONS:
            fixed.append(w.upper())
        else:
            fixed.append(w.capitalize())
    return " ".join(fixed)

Die Normalisierungsregeln sind durch neun kleine Tests abgesichert (python3 pim_cleanup.py --selftest). Dieselben Regeln laufen als JavaScript-Portierung im Browser – dort gegen 24 Testfälle, die Sie selbst ausführen können. Zusammen mit der Nachprüfung aus Version 3 sind es 87.

PIM-Cleanup-Demo öffnen →

Die Lückenliste als Arbeitsansicht statt als Textdatei. Diese Oberfläche ist gebaut und bedienbar: Das Regelwerk wurde nach JavaScript portiert und läuft im Browser des Besuchers. Für denselben Datensatz erzeugt sie zeichengleich denselben Report und dieselbe bereinigte CSV wie das Python-Skript oben – beide Dateien lassen sich in der Demo aufklappen und vergleichen.

Ein Klick auf eine Zeile öffnet den Vorher-Nachher-Vergleich: jedes Feld mit Rohwert, bereinigtem Wert und der Regel, die gegriffen hat. Dort steht auch, wo das Regelwerk bewusst nichts tut – etwa bei einer Kategorie, die es nicht kennt und deshalb unverändert stehen lässt.

Bereinigung in der Demo ausführen →

Standbild der laufenden Oberfläche, Auszug aus 10 Zeilen. Die Kachel „geschätzt: 0“ ist Absicht – sie hält fest, dass keine einzige Angabe automatisch ergänzt wurde, und sie bleibt auch dann auf null, wenn man im Eingabefeld Werte löscht.

Die Regeln finden die Lücke, füllen sie aber nicht. Genau zwei Felder bekommen einen Vorschlag, und aus verschiedenen Gründen. Für Beschreibungen formuliert ein Sprachmodell einen Satz – im Beispieldatensatz betrifft das vier der zehn Artikel: A1001, A1004, A1007 und A1009. Für Kategorien – im Beispiel nur A1010 – formuliert es nichts, sondern wählt aus: erlaubt ist nur, was im Kategoriebaum schon steht, und das wird zeichengleich geprüft. Passt keine bestehende Kategorie, erfindet das Modell keine, sondern schlägt bis zu drei neue vor – getrennt ausgewiesen, getrennt freizugeben und in der Datei mit einem eigenen Herkunftswert versehen.

Der interessante Teil dieser Stufe ist nicht der Vorschlag, sondern die Prüfung dahinter. Jede harte Angabe im Vorschlagstext wird gegen die Daten desselben Artikels gehalten: jede Zahl, jedes Material, jede Farbe, jede Eigenschaftsbehauptung. Was sich dort nicht findet, ist hinzuerfunden – und der Vorschlag lässt sich nicht übernehmen. Diese Prüfung läuft zweimal: einmal im Aufzeichnungsskript, bevor eine Antwort überhaupt gespeichert wird, und einmal im Browser des Besuchers gegen die Daten, die dort gerade im Feld stehen.

Vorschläge mit Nachprüfung ansehen →

Standbild der laufenden Oberfläche für den Beispieldatensatz, Auszug aus fünf Vorschlägen. In diesem Lauf hat kein Vorschlag die Nachprüfung verfehlt – das ist das Ergebnis, nicht die Zusage.

Interessanter als ein sauberer Lauf ist der Fall, in dem die Prüfung greift. Er lässt sich nicht bestellen, aber nachstellen – die beiden folgenden Sätze stehen als Testfälle im Regelwerk und lassen sich in der Demo unter „Selbsttest“ ausführen:

Der erste Satz klingt so plausibel wie jeder andere. Genau solche Sätze landen sonst im Shop, ohne dass jemand den Unterschied bemerkt.