Über eine Million Produkttexte in einem Jahr: Meine 5 wichtigsten Learnings

In einer aktuellen Folge unseres Podcasts Buzzsozial ging es um unsere Lieblingsautomatisierungen im E-Commerce. Raoul, Oguzhan und Seb sprachen über Prozesse, die bei uns und unseren Kunden wirklich fehlerfrei laufen, und nicht über die üblichen Tool-Listen.

Eine Automatisierung, mit der ich das Jahr über ziemlich viel Zeit verbracht habe, ist der Prozess für Produkttexte auf Skalierung. Inzwischen habe ich damit über eine Million Texte produziert, wenn man Übersetzungen mitzählt. Der letzte Lauf allein bestand aus 415 deutschen Texten, die danach direkt in sechs Sprachen übersetzt wurden. Das macht 2.905 Texte an nicht mal einem Nachmittag.

Ich hab also ein Jahr lang immer wieder an Prompts geschraubt und verschiedene Modelle getestet. Was für mich am Ende bei der Qualität wirklich den Unterschied gemacht hat, habe ich in fünf Learnings zusammengefasst. Das Überraschendste daran ist, dass fast alle davon absolut nichts mit dem Sprachmodell selbst zu tun haben.

1. Die Produktdaten waren da, nur nicht so, wie der Prozess sie erwartet hat

Dass Produktdaten die Grundlage für die Erstellung von Produkttexten sind, ist selbstverständlich. Ich hatte deshalb erwartet, dass die größten Probleme einfach aus fehlenden Daten kommen. Tatsächlich war aber etwas anderes der Fall. Die Daten waren da, aber nicht so, wie es vom Prozess vorgesehen wurde.

Der erste Fall war der Feed-Export einer Parfümerie. Hier war der Produktname auf mehrere Spalten verteilt. In der Spalte, die Titel hieß, stand nur „Eau de Parfum Spray“. Die Marke und der wirkliche Name des Duftes standen woanders. Unser Setup ging aber vom Normalfall aus, also dass der Name im Titel steht. Also suchte meine automatisierte Webrecherche vor dem eigentlichen Schreibprozess ganz blind nach Informationen zu „Eau de Parfum Spray“ und nicht zu dem korrekten Produktnamen. Dementsprechend wurde nur Humbug gefunden, der nicht zum Produkt passte, und der Text beschrieb danach einen völlig generischen Duft. Nachdem ich die Spalten dann zusammengeführt hatte, stieg die interne Prüfnote für den Text logischerweise direkt von 64,8 auf 96,9 Punkte. Und der Duft hatte plötzlich wieder seinen Namen.

Sobald die Daten stimmten, wurde das Sprachmodell fast zweitrangig. Ich hab danach Claude gegen Gemini an mehreren Produkten getestet. Dabei erreichte Claude 89,6 bis 96,9 Punkte und Gemini 89,5 bis 94,2. Der Unterschied war also minimal. Der wahre Qualitätssprung war hier die korrigierte Spaltenstruktur und keine Modellentscheidung.

Der zweite Fall war die Feed-Struktur eines Drogeriehändlers. Der Feed hatte 35 Spalten, aber die entscheidenden Daten fehlten trotzdem an der vorgesehenen Stelle. Das Feld „Lieferumfang“ war nämlich gerade mal bei 5 von 415 Produkten befüllt, obwohl 18 Titel das Wort „Set“ oder „Pack“ enthielten. Sets hatten für uns die Anforderung, dass alle Produkte, die darin enthalten sind, aufgelistet werden. Aus den Attributen ließ sich das aber wegen der fehlenden Daten nicht füllen. Die Bestandteile des Sets standen zwar im Input in der ursprünglichen Beschreibung, nur eben nicht isoliert dort, wo der Automatisierungsprozess sie gesucht hat.

Derselbe Feed hatte umgekehrt auch eine Spalte zu viel. „Warnhinweis“ war bei 48 Prozent der Produkte befüllt, mit Pflichttexten wie „Achtung! Nicht geeignet für Kinder unter 3 Jahren. Erstickungsgefahr durch Kleinteile.“, die im Produkttext aber nie auftauchen sollten. Dadurch, dass es jedoch im Input vorhanden war, hat das Modell gerne mal solch einen Hinweis in die Texte eingebaut. Mehr Daten machen die Texte daher nicht besser. Sie machen sie wackliger, wenn der Prozess nicht weiß, was er mit ihnen tun soll.

Gute Produktdaten zu haben heißt also nicht unbedingt, dass der Feed einfach nur lückenlos ist. Die Daten sollten an der richtigen Stelle stehen und auch tatsächlich beim Sprachmodell ankommen. Wenn du einen Lauf planst, schau dir also vorher an, was im Export tatsächlich in der Titelspalte steht, und geh nicht davon aus, dass dort steht, was dort stehen sollte.

2. Automatisierte Prüfungen und Kennzahlen sind nicht objektiv

Ich hab lange geglaubt, dass eine automatische Prüfung der erstellten Texte wenigstens objektiv ist. Sie war es aber bei mir auf drei Arten nicht.

Der Prüfer schreibt mit

Mein Workflow hat die Option, einen Text nach der Prüfung automatisch überarbeiten zu lassen, bis die Bewertungsnote stimmt. Ich habe das Ganze eine Weile laufen lassen. Dann ist mir aufgefallen, dass das Wort „unterstützt“ auf einmal in gefühlt jedem Text stand. Den Grund habe ich in den Prüfkriterien gefunden. Eines der Kriterien mit dem höchsten Gewicht hieß „Rechtliche Konformität“. Das heißt verboten sind Heilversprechen und stattdessen sollen weiche Formulierungen wie „unterstützt“ oder „trägt bei zu“ genutzt werden.

Bei jeder Überarbeitung bekam der Schreiber die Befunde des Prüfers vorgelegt und hat gelernt, welches Wort belohnt wird, nur ohne den eigentlichen Kontext. Dadurch kamen Sätze raus wie "Das Sockenpaar unterstützt einen angenehmen Sitz im Alltag" oder "Der Raumduft unterstützt ein gepflegtes Raumambiente". In den überarbeiteten Texten meiner beiden Testläufe stand das Wort zwölfmal, in den nicht überarbeiteten viermal. So ist die Präferenz des Prüfers Wort für Wort in die Texte gewandert. Als ich die Schleife dann abgeschaltet habe, wurden die Texte auf Anhieb besser. Sie enthielten wieder handfeste Produktinformationen statt weichgespülter Phrasen und kosteten in der Erstellung nur noch die Hälfte. Das heißt natürlich nicht, dass automatisierte Revisionen grundsätzlich ein Fehler sind. Ich hatte auch schon Fälle, in denen so eine Schleife absolut Sinn gemacht hat, wie bei sehr harten formalen Vorgaben. Aber gerade bei Tonalität und Stil wird es gefährlich. Wer den Text immer wieder an den Prüfer anpasst, optimiert am Ende nur noch für die Maschine, und nicht mehr für den eigentlichen Leser.

Die Note misst den Prüfer, nicht den Text

Eine Note sagt oft mehr über den automatischen Prüfer aus als über den Text selbst. Wer seinen Prompt oder das Sprachmodell aktualisiert, passt im Hintergrund oft auch die Regeln für die Qualitätskontrolle an. Vergleicht man danach einfach die Bewertung der alten Texte mit den neuen, tappt man direkt in eine Falle.

Bei einem unserer Modellwechsel hatten die alten Texte in ihrer ursprünglichen Prüfung glatte 100 Punkte bekommen. Das neue Setup gab den neu generierten Texten plötzlich nur noch 87 Punkte. Der erste Reflex ist dann natürlich zu glauben, dass die Qualität gesunken ist. Aber als ich die alten Texte nochmal zur Kontrolle durch den neuen Prüfer geschickt habe, fielen sie genauso durch.

Das Problem waren nämlich nicht die Texte, sondern der Prüfer, der völlig neue Macken entwickelt hatte. Ein „markantes Trinkgefäß“ galt für ihn plötzlich als unzulässige Werbeaussage und eine ganz normale Wattzahl als verbotene Inhaltsangabe. Von 22 Flags war am Ende ein einziger berechtigt. Ein anderer Text, der komplett nur aus dem Denkprotokoll des LLMs bestand, sogar mit „Let’s think“ anfing und inhaltlich nie beim Produkt ankam, bekam dagegen stolze 98,9 Punkte. Er verletzte nunmal zufällig keine der neuen Regeln. Daran sieht man, wie stark sich allein das Messgerät in der Zwischenzeit verändert hatte.

Wenn du zwei Durchläufe oder Modelle vergleichen willst, müssen unbedingt beide Versionen vom exakt selben Prüfer bewertet werden. Das ist im Nachhinein natürlich völlig logisch. Aber wenn man tief im Flow steckt und von Test zu Test sprintet, vergisst man das ganz schön schnell. Sonst vergleichst du am Ende keine Texte, sondern nur die Stimmungsschwankungen deines QA-Setups.

Could it be 3 bullets or 1 bullet?
Let's think: what if the test is:
"bei Sets so viele, wie Produkte enthalten sind"
If the set contains 3 pairs of socks:
Wait, could it be 3 bullets?
If you write:
<li>1x Paar Herren Kurzsocken in Dunkelblau</li>
<li>1x Paar Herren Kurzsocken in Dunkelblau</li>
<li>1x Paar Herren Kurzsocken in Dunkelblau</li>
VS
<li>3x Paar Herren Kurzsocken in Dunkelblau</li>
WAIT! What if a set has 3 pairs, why would anyone write 3 bullets?
[…]

Meine eigene Kennzahl hat Geschwätzigkeit belohnt

Auch die Kennzahlen, die ich mir selbst gebaut hatte, führten in die Irre. Beim Drogeriehändler musste ich das Modell tauschen, weil Google das alte abgeschaltet hatte. Beim Prompt Engineering für das neue Modell brauchte ich ein Maß für Fortschritt. Weil sich gute Textqualität nur schwer objektiv in einer einzelnen Zahl ausdrücken lässt, habe ich mich an das gehalten, was messbar war. Ich habe deshalb gemessen, wie viele der gelieferten Produktinformationen tatsächlich im Text ankommen.

Das neue Modell lag bei 71 Prozent, das alte bei 58 Prozent. Eigentlich klingt das ja nach einem klaren Sieg. Dann habe ich die Texte gelesen. Sie waren geschwätzig, austauschbar und enthielten teilweise komische Waschhinweise bei Texten über Plastikspielzeug. Das neue Modell hatte einfach stur jedes noch so irrelevante Detail aus dem Feed in den Text gepresst. Ich fand die alten Texte viel besser, war mir aber gleichzeitig nicht sicher, ob ich sie vielleicht nur deshalb vorzog, weil ich sie seit einem Jahr gewohnt war. Ein Blindtest mit zehn Produkten brachte mir dann aber Klarheit. Die Texte wurden per Zufall verteilt und der Schlüssel dazu lag gesichert in einer geschlossenen Datei. Das Ergebnis war ein 6 zu 4 für die alten Texte. Erst nach einem erneuten Umbau des Prompts stand es 4 zu 4 bei zwei Unentschieden. Meine Kennzahl hatte Geschwätzigkeit belohnt, weil sie nach dem definiert war, was sich leicht zählen lässt, nämlich der reinen Menge an verarbeiteten Fakten. Ohne den Blindtest hätte ich meiner Zahl oder meinem Gefühl geglaubt und beides wäre falsch gewesen.

3. Widersprüche im Prompt erzeugen keine Fehler, sondern Kosten

Unser Prompt für den Drogeriehändler ist über Monate mit immer wieder neuen Anforderungen gewachsen. Am Ende bestand er aus um die 15.000 Zeichen. Natürlich verliert man bei so einer Menge als Mensch auch mal irgendwann den Überblick darüber, wie sich einzelne Regeln gegenseitig beeinflussen.

In Version 22 verlangte die Set-Anweisung aus dem ersten Beispiel, die Liste der enthaltenen Teile inklusive Inhaltsmenge zu schreiben. Ein paar Absätze weiter stand jedoch die allgemeine Regel, dass im Text absolut keine Inhaltsangaben auftauchen dürfen. Beides ist für sich genommen sinnvoll, zusammen aber absolut unerfüllbar. Lange hat das kein Mensch bemerkt, weil niemand beide Absätze im selben Moment liest.

Das Sprachmodell liest aber beide im selben Moment. Es hat sich darüber nur nicht beschwert, es hat einfach angefangen nachzudenken. Bei einem Baby-Set rechnete die KI so lange hin und her, bis sie 31.996 von 32.000 erlaubten Token verbraucht hatte. Dann kam einfach nichts mehr, weil das Budget aufgebraucht war. Der Lauf stand trotzdem auf erfolgreich abgeschlossen und der automatische Prüfer gab dem komplett leeren Ergebnis verrückte 65,7 Punkte.

Aufgefallen ist das Ganze anschließend beim Blick in die Rohdaten des Laufs, wo die verbrauchte Tokenzahl pro Produkt steht. Normale Texte lagen bei 5.000 bis 11.000 Token, das Set lag am absoluten Limit bei 32.000. Das erklärte im Nachhinein auch zwei frühere Ausfälle bei Socken und einem Textilprodukt, die genau dieselbe Ursache hatten.

Ein Widerspruch im Prompt wirft also keinen Fehler. Er kostet bei jedem Lauf einfach nur Denkzeit und Geld, und bei manchen Produkten kostet er den kompletten Text, ohne dass jemand eine Warnung bekommt. Natürlich fällt ein leeres Ergebnis auf, wenn man den Text händisch gegenliest. Aber bei Tausenden von Produkten macht das niemand mehr. Auf Skalierung ist der Blick auf die verbrauchte Tokenzahl deshalb die einzige Möglichkeit, solche stillen Ausfälle systematisch aufzuspüren.

4. Ein einzelner Prompt reicht nicht für 61 Produkttypen

Der Feed des Drogeriehändlers hatte 61 verschiedene Produkttypen. Von Parfüms oder Schreibwaren bis hin zu Textilien war alles dabei. Ein einziger Prompt kann das nur sehr schwer abdecken. Das liegt aber nicht daran, dass bei Spielzeug etwas anderes im Fokus steht als bei Kosmetik. So etwas ließe sich in einem Prompt noch gut regeln. Der Grund ist, dass manche Kategorien völlig eigene Pflichten haben, die in jedem anderen Produkttext schlichtweg falsch wären.

Babynahrung ist hier das deutlichste Beispiel. Für Säuglingsanfangsnahrung gelten strenge gesetzliche Werbeeinschränkungen. Im Text darf kein „perfekt“ oder „liebevoller Start“ stehen und auch kein Vergleich mit Muttermilch gezogen werden. Selbst dann nicht, wenn der Hersteller genau das im Input mitliefert. Dafür müssen die Pflichtfakten zwingend nach vorne. Altersempfehlung, Allergene, Bio-Status, Lagerung und Dosierung haben hier Priorität. Bei Folgemilch ab dem sechsten Monat sind die Regeln dann wieder lockerer. Hier darf der Text leicht werblich sein, solange die reine Idealisierung verboten bleibt. Das hat lange nichts mehr mit einem Feinschliff an der Tonalität zu tun, sondern ist ein eigener Regelsatz, der in jedem anderen Produkttext falsch wäre.

Wer nun versucht, all diese Sonderregeln für Babymilch, Kosmetik und Textilien mit Wenn-Dann-Regeln in einen einzigen Mega-Prompt zu quetschen, provoziert oftmals genau die Widersprüche und Ausfälle, die wir im vorherigen Punkt gesehen haben. Gleichzeitig darf man aber nicht den Fehler machen, für 61 Produkttypen auch 61 Prompts zu schreiben, denn das wäre ein Albtraum in der Wartung. Die Lösung liegt in der Gruppierung nach Regelwerken. Am Ende waren es in dem Projekt ein Basisprompt und sechs Kategoriefassungen für die Ausnahmefälle.

Die Frage für dich als Händler lautet also nicht nur, welchen Prompt du brauchst, sondern auch wie viele. Und die Antwort darauf liefert dir nicht das Sprachmodell, sondern ein sauberer Blick auf deinen Feed.

5. Slop ist keine Eigenschaft eines einzelnen Textes

Wenn wir nach dem typischen KI-Einheitsbrei suchen, schauen wir fast immer auf den einzelnen Text. Wir suchen nach platten Phrasen oder unnatürlichen Satzbauten. Doch das ist bei Produkttexten oft genau der falsche Blickwinkel.

Bei einem Lauf für den Drogeriehändler sahen die neu generierten Texte auf den ersten Blick absolut fehlerfrei aus. Wenn man drei oder vier davon testgelesen hat, wirkten sie richtig gut und waren bereit für die Freigabe. Das Problem fiel mir erst auf, als ich den kompletten Batch hintereinander in ein Sheet legte und im Ganzen betrachtete. Fast alle neuen Texte fingen mit dem Produktnamen an, gefolgt von „bietet“, „dient“ oder „sorgt“. Sie hatten denselben Rhythmus, dieselbe Satzlänge und oft sogar denselben zweiten Satz. Jeder einzelne Text hätte auf einer Produktseite niemanden gestört. Alle zusammen ergaben aber etwas, das deutlich nach Maschine klang. Der Prüfer kann das nicht sehen, weil er jeden Text einzeln bekommt. Der Prompt kann es auch nicht lösen, denn jedes Produkt ist ein eigener Lauf und das Modell sieht die anderen Texte nie. Bei der Parfümerie hatte die Kundin genau das kommentiert. Sie schrieb, Begriffe wie „Fundament“ und „Nachklang“ habe sie bis jetzt fast bei jedem Duft gelesen. Als ich über die ganze Lieferung nachgezählt habe, hatte sie recht. Es waren immer dieselben Wörter und dieselben Überschriften, quer durch alle Marken und Produkte.

Die Dopplungsprüfung läuft deshalb nun erst ganz am Ende über den kompletten Batch und nicht mehr während der Erstellung. Ein Skript sucht dabei nach Überschriften, die mehrfach auftauchen, und nach Phrasen, die sich ständig wiederholen. Für die betroffenen Produkte gibt es dann einen zweiten Lauf. Diesmal bekommt das Modell die ganzen abgenutzten Formulierungen einfach als Blacklist mit. Zusätzlich lese ich vor jeder Freigabe immer noch einen ganzen Schwung Texte am Stück durch, einfach um sicherzugehen.

Zurück zur Ausgangsthese. Nach etwa einem Jahr, in dem ich Texte automatisiert, Daten bereinigt und Abläufe gemessen habe, fällt mein Fazit ziemlich eindeutig aus. Wenn man anfängt, solche Prozesse zu bauen, dreht sich die Diskussion um die Qualität meistens zuerst um das Sprachmodell. Dabei war das Modell am seltensten das eigentliche Problem. Die Qualität der Ergebnisse entschied sich am Ende immer durch die Vorbereitung der Daten, die Struktur der Prompts und die anschließende Kontrolle. Das Modell hat am Ende nur sichtbar gemacht, was in den Daten und Prozessen ohnehin schon stand.

Alle Zahlen stammen aus unseren Kundenprojekten 2025 und 2026.