Jeder, der schon einmal einen größeren Shop aufgebaut oder migriert hat, kennt das Bild: ein Ordner mit hunderten Hersteller-PDFs, dazu Excel-Listen mit Artikelnummern und das diffuse Gefühl, dass die nächsten zwei Wochen verloren sind. Produktnamen abtippen, Beschreibungen umformulieren, Kategorien zuordnen, Alt-Texte erfinden – alles wichtig, alles wiederholend.

Mit unserer Plattform Axon planen wir diesen Schritt anders. Datenblätter sollen künftig nicht mehr manuell erfasst, sondern an einen KI-Pipeline-Job übergeben werden, der über Nacht durchläuft. Das angestrebte Ergebnis am Morgen: vollständig befüllte Produkte mit Beschreibungen, SEO-Daten, Tags und Alt-Texten, eingecheckt im Magento- oder Hyvä-Shop. Diese Katalog-Pipeline befindet sich derzeit in Entwicklung – dieser Beitrag beschreibt, wie sie technisch funktionieren soll, wo ihre Stärken liegen und wo wir bewusst auf den Menschen setzen.

Der Schmerzpunkt: Kataloge wachsen, Teams nicht

Eine typische Migration von Magento 1 oder einem Altsystem auf Hyvä bringt zwei Probleme zusammen: die Daten sind schlecht (kurze, kopierte Beschreibungen ohne SEO-Wert), und es gibt viele davon (mehrere tausend SKUs). Wer die Migration als reine Datenübernahme behandelt, landet im neuen Shop mit dem alten Qualitätsproblem.

Die übliche Lösung – Texter beauftragen, Excel exportieren, manuell überarbeiten – kostet je nach Größe sechs- bis siebenstellig und dauert Monate. In dieser Zeit verkauft niemand mit besseren Texten.

Wie Axon das Problem zerlegt

Die geplante Pipeline soll aus vier Stufen bestehen, die jeweils auf ihrer eigenen Datenbasis arbeiten:

  1. Extraktion. Aus dem PDF werden strukturierte Felder geholt – Artikelnummer, Maße, Material, Gewicht, technische Eigenschaften. Dafür reicht heute kein klassisches PDF-Parsing mehr; wir nutzen Vision-Modelle, die auch Tabellen, schlecht gesetzte Spalten und Mischlayouts verstehen.
  2. Normalisierung. Die rohen Felder werden auf das Magento-Attribut-Set des Shops gemappt. Hier passieren die meisten Fehler: ein Hersteller schreibt „Farbe: kirschrot", der Shop kennt aber nur „rot". Die Mapping-Regeln pflegen wir pro Kund:in einmal und sie wachsen mit jedem Datenblatt mit.
  3. Generierung. Auf Basis der extrahierten Fakten erzeugt das LLM eine Produktbeschreibung in der Markentonalität, dazu SEO-Title, Meta-Description, Tags und Alt-Texte. Wichtig: die Generierung sieht nur die normalisierten Fakten, nicht das PDF. Damit halluziniert das Modell keine Eigenschaften.
  4. Validierung. Markenrechts-Check (Wortlisten), Plausibilitäts-Check (passt die Beschreibung zur Kategorie?), Konsistenz-Check (Tonalität, Längen). Was durchfällt, landet in einer Review-Queue für den Menschen.

Die Reihenfolge ist entscheidend. Wer einem Sprachmodell ein PDF vor die Nase wirft und „mach mir eine Produktbeschreibung" sagt, bekommt poetische Texte mit erfundenen Features. Das ist nicht das, was wir wollen.

Ein Rechenbeispiel (fiktiv)

Zur Veranschaulichung ein fiktives Beispiel – ein solches Projekt haben wir noch nicht ausgeliefert. Angenommen, ein Shop bringt rund 2 100 Produkte aus etwa 180 Hersteller-PDFs mit. Mögliches Eingangsmaterial:

So würde die Pipeline über Nacht durchlaufen. Am nächsten Morgen lägen im Shop:

Wichtig zu wissen

In so einem Lauf erwarten wir, dass ein Teil der Produkte in die Review-Queue fällt – etwa, weil ein Datenblatt eine Eigenschaft enthält, die wir markenrechtlich nicht ohne Prüfung beschreiben wollen („antibakteriell"). Die manuelle Sichtung dieser Fälle schätzen wir auf wenige Arbeitstage. Rein manuell rechnen wir bei dieser Menge mit Wochen statt Tagen.

Worauf es bei so einer Pipeline ankommt

1. Die Markentonalität ist die wichtigste Stellschraube

Drei bis fünf gut gewählte Beispiel-Beschreibungen reichen, damit das Modell den Ton trifft. Mehr Beispiele helfen wenig; das Modell überfittet eher. Wichtig ist, dass die Beispiele nicht die generische „Made by KI"-Mittellage haben, sondern erkennbar die Markenstimme.

2. Validierungs-Regeln sind keine Kür

Die kritischste Stelle sind weniger erfundene Fakten – ein Modell, das nur die normalisierten Felder sieht, hält sich gut daran –, sondern subtilere Probleme: doppelte Phrasen über mehrere Produkte hinweg, übertriebene Adjektive in Nischen, in denen sachlich besser verkauft. Solche Muster soll eine zweite, kritische LLM-Pass mit klaren Kriterien abfangen.

3. Menschen lesen am Ende trotzdem

Wir empfehlen, nach jeder Pipeline einen Stichproben-Review zu machen (5–10 % der Produkte). Nicht weil die KI typischerweise scheitert, sondern um Vertrauen ins System aufzubauen und Mapping-Regeln nachzuschärfen.

Wann das Sinn macht

So eine Pipeline rechnet sich, sobald mehr als ein paar hundert Produkte mit gleichem Schema in den Shop sollen – sei es bei einer Migration, einer Markenerweiterung oder einer neuen Kategorie. Bei 20 Produkten lohnt sich der Aufwand nicht; bei 2 000 schon deutlich.

Wer überlegt, ob das für den eigenen Katalog funktioniert: schicken Sie uns ein typisches Datenblatt und ein paar Wunsch-Beispieltexte. Wir spielen das einmal durch und zeigen Ihnen das Ergebnis – das sagt mehr als jede Beschreibung der Methode.