Im Inneren der Produktzuordnung: Die Architektur, die Millionen SKUs ohne Barcode zuordnet

Von Blocking über Embedding-Ähnlichkeit und LLM-gestützte Entscheidung bis zur Expertenprüfung — die Architektur der Produktzuordnung von Senkrondata.

Das schwierigste Problem der Wettbewerbspreisbeobachtung ist auf dem Bildschirm unsichtbar: Welcher SKU in Ihrem eigenen Katalog entspricht dieses Listing auf der Wettbewerberseite? Barcodes sind nicht immer da, Namen werden auf jeder Seite anders geschrieben, dasselbe Produkt verkauft sich in drei verschiedenen Packungsgrößen. Das ist die handelsspezifische Ausprägung eines klassischen, harten Problems, das in der Literatur Entity Resolution heißt.

Dieser Beitrag ist die technische Fortsetzung unserer Einführung dazu, warum Produktzuordnung so entscheidend ist. Hier geht es um das „Wie" statt um das „Was" — um die Architektur unter der Oberfläche.

Warum die Größenordnung naive Lösungen erledigt

Hunderte Vertriebskanäle, Millionen Produkte. Ein Ansatz nach dem Muster „jedes Produkt mit jedem vergleichen" ist über zwei Kataloge O(n×m) — bei je einer Million Artikeln sind das 10¹² Vergleiche. Das jeden Tag zu wiederholen ist physikalisch unmöglich.

Deshalb ist die Zuordnung kein einzelner Algorithmus, sondern ein Trichter: Jede Stufe beginnt günstig und tolerant und verkleinert den Kandidatenpool aggressiv; die teure, präzise Entscheidung bleibt ganz am Ende, beim kleinsten Pool. Die Ökonomie des Trichters ist simpel: Je früher günstig aussortiert wird, desto weniger Arbeit erreicht die teure Schicht.

Stufe 1 — Kandidatenerzeugung (Blocking)

Der Weg um die O(n×m)-Explosion herum führt darüber, je Produkt nur „plausible Kandidaten" zu bewerten. Diese Technik heißt Blocking: Jedes Produkt erhält einen oder mehrere Blocking-Schlüssel, die es grob beschreiben — etwa normalisierte Marke + Kategorie + Anfangsbuchstaben oder charakteristische Tokens aus dem Namen. Verglichen werden nur Produkte im selben Block.

Ein guter Blocking-Schlüssel balanciert zwei Dinge:

• Recall: Echte Treffer müssen im selben Block landen (sonst begegnen sie sich nie).
• Reduktionsrate: Der Block muss klein genug sein (sonst bringt das Aussortieren nichts).

In der Praxis reicht ein Schlüssel nicht; mehrere Blocking-Schemata laufen parallel (eines auf der Marke, eines auf einem Barcode-Präfix, eines auf Namens-Tokens), und die Ergebnisse werden vereinigt. Das macht das Verfahren robust gegen Rauschen in einem einzelnen Schlüssel.

Stufe 2 — Eindeutige Identität (deterministische Zuordnung)

Innerhalb eines Blocks wird zuerst das günstigste und sicherste Signal geprüft: der eindeutige Identifikator. Sind Barcode/GTIN auf beiden Seiten vorhanden und konsistent, wird die Zuordnung zum Lookup — Mehrdeutigkeit geht gegen null.

Im Produktivbetrieb bricht dieser Idealfall aber oft: Barcodes fehlen, werden an der Quelle vertippt oder wurden in variantenreichen Kategorien wie Bekleidung und Mode nie standardisiert. Ein Barcode allein kann auch in die Irre führen — dieselbe GTIN wird gelegentlich für eine andere Packung oder Charge wiederverwendet. Eindeutige Identität ist also die Schicht „großartig, wenn verfügbar", aber mit einem Prüfreflex obendrauf: Selbst bei passenden Barcodes wird die Zuordnung als verdächtig markiert, wenn Name und Marke einander vollständig widersprechen.

Stufe 3 — Probabilistische Ähnlichkeit (lexikalisch + semantisch)

Fehlt die eindeutige Identität, übernimmt die Ähnlichkeitsbewertung. Hier werden zwei Arten von Signal kombiniert:

• Lexikalische Ähnlichkeit: tokenbasierte Maße (Jaccard, TF-IDF-gewichteter Kosinus, Levenshtein-/Editierdistanz). Sie fangen Oberflächenvarianz wie „Herren Sportschuh Weiß 42" gegenüber „Sportschuh – Weiß/42" gut ab, verfehlen aber Synonyme („Sneaker" gegenüber „Sportschuh").
• Semantische Ähnlichkeit: Produktname und -beschreibung werden in einen Embedding-Vektor überführt, und im Vektorraum wird die Nähe gemessen (Kosinus-Ähnlichkeit). Das erfasst dieselbe Bedeutung in anderen Worten. In großem Maßstab wird das mit einem ANN-Index (Approximate Nearest Neighbor) beschleunigt.

Beide Signale fließen in einen gewichteten Score. Der entscheidende Punkt: Diese Stufe ist bewusst tolerant. Ihre Aufgabe ist nicht die endgültige Entscheidung, sondern die Eingrenzung auf eine Handvoll „wahrscheinlich gleicher" Produkte. Die Schwelle bleibt hier locker; die feine Entscheidung überlässt sie der nächsten, teureren Schicht.

Stufe 4 — Kontextuelle Entscheidung (LLM-as-a-Judge mit harten Bedingungen)

Der eingegrenzte Pool — jetzt vielleicht 1 bis 5 Kandidaten je Produkt — geht an die Schicht, die am nächsten an menschlichem Urteil argumentiert. Hier entscheidet ein Sprachmodell anhand des Kontexts, ob zwei Listings tatsächlich dasselbe Produkt sind. Wichtig ist, das Modell nicht frei laufen zu lassen; die Entscheidung wird von einigen harten Bedingungen gerahmt:

• Variantengleichheit ist Pflicht: Packungsanzahl (3er-Pack ≠ Einzelstück), Volumen/Gewicht, Größe, Farbe, Geschlecht — das ist nicht „nah dran", das sind andere Produkte. Widerspricht eines davon, wird die Zuordnung verworfen, unabhängig vom Score.
• Belege erforderlich: Das Modell muss seine Entscheidung auf die verglichenen Attribute stützen; „der Name sieht ähnlich aus" genügt nicht.
• Bei Unsicherheit ablehnen: Ist das Modell nicht sicher, ist „keine Zuordnung" der sichere Standard (siehe die Precision-Recall-Abwägung unten).

Genau hier zahlt sich die Ökonomie des Trichters aus: Die teure LLM-Entscheidung läuft nur wenige Male je Kandidat — ein winziger Anteil der Gesamtlast — weil die früheren Stufen bereits Millionen sinnloser Vergleiche entfernt haben.

Stufe 5 — Expertenprüfung (Human-in-the-Loop)

Zuordnungen mit niedriger Konfidenz, die die Automatisierung nicht auflösen kann, und besonders kritische Produkte landen in einer Expertenwarteschlange. Das ist kein „Notbehelf" — es ist der Kalibrierungsmechanismus des Systems: Expertenentscheidungen dienen zugleich als Feedbackdaten, um Schwellen und Regeln über die Zeit zu verbessern. Jede manuelle Entscheidung macht künftige automatische ein Stück genauer.

Entwurfsprinzipien: die Entscheidungen, die den Motor verlässlich machen

• Precision > Recall. Ein False Positive (falsche Zuordnung) wird stillschweigend zur falschen Preisentscheidung und fällt kaum auf; ein False Negative (verpasste Zuordnung) ist eine sichtbare Lücke, die sich später schließen lässt. Im Zweifel also nicht zuordnen. Wir kalibrieren den Motor auf Precision.
• Jede Zuordnung hat eine Herkunft. Welche Schicht sie erzeugt hat (deterministisch / probabilistisch / LLM / manuell) und mit welchem Konfidenzwert, wird festgehalten. „Worauf beruhte diese Zuordnung?" hat immer eine Antwort — unverzichtbar für Auditierbarkeit wie Fehlersuche.
• Eine Zuordnung ist nicht statisch. Kataloge ändern sich, Wettbewerberseiten bauen ihre Listings um, neue Produkte erscheinen. Zuordnung ist ein kontinuierlich neu laufender Prozess; eine Zuordnung kann „verfallen" und erneut geprüft werden müssen.

Größenordnung und Trennung der Leseschicht

Tägliche Preisvergleichsberichte über Millionen Zuordnungen lassen sich nicht direkt aus der operativen Datenbank erzeugen, in die die Crawler permanent schreiben — die Auswertungslast würde die Schreiblast ersticken. Zuordnungs- und Preisdaten werden deshalb in einen getrennten analytischen Speicher gespiegelt (eine spaltenorientierte, deduplizierungsfreundliche Engine). Schwere analytische Abfragen bleiben so schnell und aktuell, ohne die laufende Datenerhebung zu bremsen. (Diese Trennung behandeln wir in einem eigenen Beitrag ausführlicher.)

Das Wesentliche

Produktzuordnung ist nicht „ein Algorithmus" — sie ist eine Trichterarchitektur: Kandidaten per Blocking erzeugen, die einfachen Fälle deterministisch über die Identität lösen, mit probabilistischer Ähnlichkeit eingrenzen, den Kontext per LLM bewerten, die unsicheren Fälle durch einen Menschen abschließen — und auf jeder Stufe Precision vor Recall stellen und jede Entscheidung nachvollziehbar halten. Wie verlässlich Ihre Wettbewerbspreisdaten sind, hängt an der Qualität dieser Schichten, die Sie auf dem Bildschirm nie sehen.

Wenn Ihre Produktzuordnung mit dieser Sorgfalt gebaut sein soll, sprechen Sie mit dem Senkrondata-Team.