01
Keine ID-Spalte
Die Ausgabe verlangte eine Produkt-ID, der Export lieferte keine. Die Zeilennummer wäre der naheliegende Ersatz gewesen — und beim nächsten Import falsch. Die ID entsteht deshalb aus dem normalisierten Titel.
Case Study · Prototyp · E-Commerce ·
Freitext rein, exakte Variante raus —
auf 890 echten Varianten.
Ein echter Katalogexport einer D2C-Schuhmarke und eine klare Vorgabe: Kundinnen und Kunden tippen frei, das System findet die eindeutige Variante oder fragt gezielt nach. Entscheiden darf nur Code — ein Sprachmodell formuliert die Antwort, mehr nicht.
Ergebnis · am Prototyp gemessen
Vier Fälle, genau eine Entscheidung je Anfrage.
Jede Eingabe endet in genau einem Fall: Treffer, Größe fehlt, Farbe fehlt oder Modell mehrdeutig. Die Ausgabe ist JSON mit fester Form — das Sprachmodell bekommt sie fertig und formuliert daraus einen Satz.
{
"type": "question",
"question_key": "missing_size",
"options": ["46", "48", "50", "52", "54"],
"context": {
"model": "Zustieg Hose Herren",
"color": "Oliv",
"matched_candidates": [ … ]
}
}Die Aufgabe
Logik im Code, Sprache im Modell.
Gefordert war ein Workflow, der freie Eingaben einer Variante zuordnet — oder gezielt nachfragt, wenn Modell, Farbe oder Größe fehlen oder mehrere Modelle passen. Die Antwort sollte ein Sprachmodell formulieren, die Entscheidung aber nicht treffen dürfen.
Deshalb liegt die gesamte Logik — Matching, Entscheidung, Optionen — in einem einzigen Code-Baustein, deterministisch und reproduzierbar. Das Sprachmodell erhält ausschließlich das fertige Ergebnis und kann es nicht verändern. Dieselbe Datei läuft unverändert im Workflow und in den Tests: Getestet wird genau der Code, der antwortet.
Umsetzung
Was gebaut wurde.
Ein n8n-Workflow mit drei Code-Bausteinen, ein Sprachmodell nur für die Formulierung, Google Sheets als Verlauf und ein React-Dashboard, das Ergebnis, Bilder und Verlauf zeigt.
Katalog per Code zerlegt, nicht per Sprachmodell
Vorab geprüft: Das Titelformat „Modell – Farbe – Größe" hielt in allen 890 Zeilen ohne Ausnahme. Deshalb zerlegt Code den Titel beim Import — schneller, kostenlos und reproduzierbar.
Stabile IDs ohne ID-Spalte
Die geforderte Ausgabe verlangte eine Produkt-ID, der Export hatte keine. Die ID entsteht aus dem normalisierten Titel — nicht aus der Zeilennummer, die sich beim nächsten Import verschiebt.
Seltene Wörter zählen mehr
Jedes Wort eines Modellnamens wird nach seiner Seltenheit im Katalog gewichtet. Unter den gut belegten Modellen gewinnt das vollständigste; ein allgemeines Wort allein führt zur Rückfrage statt zu einem Zufallstreffer.
Tippfehler ohne Bibliotheken
Code-Bausteine im Workflow haben standardmäßig keine Pakete. Die Ähnlichkeit ist eine eigene Levenshtein-Funktion von rund 20 Zeilen mit Schwelle 0,75; zusammengezogene Schreibweisen werden über Wortpaare erkannt.
Mehrere Runden in einer Sitzung
Das Dashboard schickt die Sitzung und den bisher erkannten Kontext mit: Modell → Farbe → Größe. Nennt eine Eingabe unterwegs ein anderes Modell, gewinnt die Eingabe.
Vier Sprachen
Oberfläche in Deutsch, Englisch, Spanisch und Französisch; die Sprache geht an das Modell, das in ihr antwortet. Produktdaten bleiben unübersetzt — Farbnamen sind Eigennamen. Modellwörter aus allen vier Sprachen werden erkannt.
Prüfschicht statt Vertrauen
-
Der Produkttitel wird genannt.
match -
Modell und Farbe werden genannt; jede Zahl im Text ist eine erlaubte Größe.
missing_size -
Das Modell wird genannt.
missing_color -
Mindestens eine der angebotenen Modelloptionen wird genannt.
ambiguous_model -
Höchstens 600 Zeichen, und der Text endet mit einem Satzzeichen.
alle Fälle
Fällt eine Prüfung durch — oder antwortet das Modell gar nicht, etwa bei Ausfall, Timeout oder erschöpftem Kontingent —, antwortet eine feste Vorlage in der gewählten Sprache. Die Antwort ist nie leer, und im Dashboard ist sichtbar, welche Quelle geantwortet hat. Anlass für die Satzzeichen-Regel: Das eingesetzte Modell zählt seine Denk-Tokens zum Ausgabelimit; bei zu knappem Limit brach der Satz mitten im Wort ab.
Hürden
Was in den Daten steckte.
Echte Shop-Exporte sind selten so sauber, wie das Format verspricht. Diese acht Punkte haben die Umsetzung bestimmt — beschrieben ohne Namen aus dem Originalkatalog:
02
Leerzeichen am Ende zweier Modellnamen
Ohne Normalisierung wären daraus zwei Modelle geworden, wo eines gemeint ist — und jede Anfrage dazu mehrdeutig. Der Import glättet Leerraum, bevor er Modelle bildet.
03
Verwechselbare Modellnamen
Singular und Plural, Linien mit und ohne Jahreszahl, Damen-, Herren- und Kinderlinien mit gleichem Stamm. Gelöst über Seltenheitsgewichtung und die Regel „vollständigster Treffer gewinnt" — das Stammwort allein ist mehrdeutig und führt zur Rückfrage.
04
Ein sehr kurzes Modellwort
Ein Modell heißt wie ein kurzes, gängiges Wort, das in längeren Wörtern steckt. Eine einfache Teilstring-Suche hätte es überall gefunden. Lösung: wortweiser Vergleich, und Wörter bis vier Zeichen müssen exakt passen.
05
Zwei Größensysteme — und Artikel ohne Größe
Einzelgrößen neben Paargrößen wie „38/39", dazu Zubehör ohne Größe. Eine Einzelgröße trifft den passenden Paarbereich; gibt es nur eine Größe, entfällt die Rückfrage.
06
Farben deutsch und englisch gemischt
Grundfarben-Synonyme bringen beide Sprachen auf einen Nenner. Nennt jemand eine Farbfamilie, die es beim gewählten Modell nur in englisch benannten Tönen gibt, fragt der Prototyp gezielt nach genau diesen Tönen, statt zu raten.
07
Bilder nur je Modell und Farbe
Nicht jede Variante hat ein eigenes Bild. Das Dashboard zeigt Bilder deshalb schon, sobald Modell oder Farbe feststehen — nicht erst beim vollständigen Treffer.
08
Antworten dauerten bis über eine Minute
Die Ursache lag laut Workflow-Protokoll nicht beim Sprachmodell, sondern beim Mitschreiben in Google Sheets: Der Workflow schrieb erst ins Sheet und antwortete dann, und das Dashboard lud nach jeder Nachricht den ganzen Verlauf neu, bis Google drosselte. Seitdem antwortet der Workflow zuerst und protokolliert danach, der Verlauf lädt nur auf Anforderung, und geschrieben wird per Append, weil parallele Schreibvorgänge sich sonst gegenseitig überschrieben.
Messbar
Was sich belegen lässt — und was nicht.
Zahlen aus dem Prototyp, nicht aus einem Shop im Betrieb.
26
/26
Testfälle bestanden
gegen den echten Katalog
890
Varianten
aus dem echten Export
1,3–3,5
s
pro Antwort
nach dem Latenz-Fix
4
Entscheidungsfälle
eine Entscheidung je Anfrage
Die 26 Testfälle laufen gegen den echten Export: alle vier Entscheidungsfälle, Tippfehler, die Datenfallen oben, eine Sitzung über drei Runden und eine Schema-Prüfung jedes Ausgabetyps. Die Antwortzeit wurde über den ganzen Vorführ-Ablauf auf einer lokalen n8n-Instanz gemessen, nach dem Umbau „erst antworten, dann protokollieren"; davor lag sie bei bis über einer Minute.
Was hier nicht steht
Conversion, Umsatz, Retouren, Supportaufkommen: Der Prototyp war nie im Shop, also gibt es diese Werte nicht — und ohne Messung wären sie geraten. Ebenfalls nicht hier: der Name der Marke und alles, was ihren Katalog wiedererkennbar machen würde.
Selbst ausprobieren
Die Live-Demo auf der Angebotsseite nutzt denselben Matcher auf einem erfundenen Outdoor-Katalog mit eingebauten Fallen — komplett im Browser und mit festen Vorlagen statt Sprachmodell. Rechts daneben steht, was der Code entschieden hat.
Und Ihr Katalog?
Derselbe Ansatz, Ihr Sortiment.
Der Matcher ist nicht an Schuhe gebunden. Gebraucht wird ein Katalogexport mit Modell, Farbe und Größe — als Prototyp zum Festpreis, ohne Livebetrieb.
