LLM-gestützte Produktdatenanreicherung: Attribute, Belege und Prüfung

Die LLM-gestützte Produktdatenanreicherung bedeutet, dass ein Sprachmodell Stammdaten im PIM erzeugt oder verbessert: Attributwerte aus Lieferanten-PDFs und Datenblättern, Kurz- und Langbeschreibungen je Kanal, SEO-Titel sowie Ton- oder Sprachvarianten. Ohne Sorgfalt entsteht flüssiger Text, den niemand prüfen kann. Als Pipeline entstehen Werte, die jeweils auf den Satz zurückverweisen, aus dem sie stammen, dazu eine Prüfwarteschlange für den Rest.

Dieser Artikel beschreibt die Ingenieursicht: Verankerung im Beleg durch Konstruktion, schemabeschränkte Ausgabe, Konfidenzsteuerung, Herkunftsnachweis je Feld, Bewertung je Feld gegen ein Golden-SKU-Set sowie die Kosten- und Compliance-Grenzen, die entscheiden, ob sich die Pipeline lohnt. PIM-Datenqualität mit LLMs behandelt Klassifikation, Normalisierung und Dublettenerkennung, und Lieferantendaten-Onboarding den Weg von Preislisten und PDFs ins System. Dieser Beitrag beginnt nach dieser Aufnahme, dort, wo die Frage lautet, was im Produktdatensatz landet und wie jemand erkennt, ob es stimmt.

Was umfasst die LLM-gestützte Produktdatenanreicherung?

Sie umfasst Attribute und Texte, die im Katalog fehlen oder in unbrauchbarer Form vorliegen: technische Werte wie Maße, Spannung oder Werkstoff, die oft in einem PDF-Datenblatt stehen und nicht im ERP; Beschreibungen in mehreren Längen je Kanal; SEO-Titel; sowie Übersetzungs- und Tonvarianten. Preise, Bestand und alles, was das ERP besitzt, gehört nicht dazu. Diese Werte stammen aus einem führenden System, und ein Modell, das einen Preis in einen Produkttext schreibt, erzeugt einen zweiten, nicht maßgeblichen Preis.

• Attribute: aus gelieferten Dokumenten extrahierte Werte, jeweils mit Einheit und Quelle.
• Texte: Kurz- und Langbeschreibungen, Stichpunkte und SEO-Titel, erzeugt nur aus freigegebenen Attributen.
• Varianten: Übersetzungen und Tonanpassungen mit denselben Fakten. Die Mechanik der Übersetzung beschreibt die LLM-Übersetzungspipeline.

Vor jedem Modelllauf entscheidet ein Bereitschaftstor, welche SKUs sich lohnen. Ein SKU ist bereit, wenn er eine Herstellerartikelnummer, eine Kategorie aus der Klassifikation, mindestens ein Quelldokument mit den tatsächlichen Attributen und einen Kanal hat, der das Ergebnis anzeigt. Ohne dieses Tor entsteht Text, den niemand prüfen kann, und genau diese Art Text ist später am teuersten zu korrigieren.

Warum aus Belegen extrahieren statt erzeugen?

Extraktion ist nicht Generierung. Die Regel, die Anreicherung sicher macht, lautet: Jeder Wert, den die Pipeline schreibt, muss auf eine Textstelle im Quelldokument abbildbar sein; ein Wert ohne Stelle wird nicht geschrieben. Googles Open-Source-Bibliothek LangExtract macht genau das zu ihrer zentralen Garantie: Jede Extraktion wird auf ein exaktes Zeichenintervall im Quelltext abgebildet, sodass ein Prüfer sie an Ort und Stelle markiert sieht. Ihre README benennt den Fehlermodus offen, gegen den die Regel schützt: Modelle können gelegentlich Inhalte aus den Few-Shot-Beispielen statt aus dem Eingabetext extrahieren. Nicht verankerte Extraktionen erhalten ein leeres Intervall, und der dokumentierte Filter verwirft sie. Die Bibliothek steht unter Apache-2.0 und ist laut README kein offiziell unterstütztes Google-Produkt (LangExtract).

Anthropics Leitfaden zur Reduzierung von Halluzinationen verfolgt denselben Gedanken auf Prompt-Ebene. Erlauben Sie dem Modell, zu sagen, dass es etwas nicht weiß. Bei langen Dokumenten, laut Leitfaden über 20.000 Token, sollen zuerst wörtliche Zitate extrahiert und nur aus diesen Zitaten gearbeitet werden. Danach folgt ein Prüfschritt, in dem jede Aussage ein stützendes Zitat finden muss oder zurückgezogen wird (Anthropic-Dokumentation). Zitat-zuerst kostet Token, lohnt sich aber, weil ein Prüfer ein Zitat auf einen Blick kontrollieren kann. Eine richtige Antwort ist oft der leere Wert: Nennt das Dokument ein Attribut nicht, sollte die Ausgabe es fehlen lassen, nicht raten.

Wie ist die Anreicherungspipeline aufgebaut?

Die Pipeline hat fünf Schritte: Quelldokumente aufnehmen, Kandidatenwerte mit Textstellen extrahieren, die Ausgabe gegen ein Schema prüfen, jedes Feld nach Konfidenz einordnen und die akzeptierten Werte mit Herkunftsnachweis ins PIM schreiben. Ein erneuter Lauf auf denselben Eingaben soll dieselben Datensätze ergeben. Jeder Schreibvorgang ist deshalb an SKU, Attribut und Promptversion gebunden, und ein erneuter Lauf ersetzt den früheren Kandidaten, statt ihn zu ergänzen.

Das Ausgabeschema übernimmt den größten Teil der Kontrolle. Die strukturierte Ausgabe von OpenAI und Azure folgt einem übergebenen JSON-Schema im Strict-Modus und liefert ein refusal-Feld, wenn eine Anfrage nicht erfüllt werden kann. Die unterstützte Teilmenge ist enger als volles JSON-Schema: Sie verbietet Einschränkungen wie pattern, format, minimum, maximum, minItems und maxItems, verlangt, dass alle Eigenschaften aufgeführt sind, benötigt additionalProperties mit false und begrenzt ein Schema auf 100 Eigenschaften und fünf Verschachtelungsebenen (Microsoft Learn). Zahlenbereiche und Einheitenmuster prüfen Sie deshalb nach der Extraktion in einem eigenen Validator. Strukturierte Ausgaben funktionieren außerdem nicht mit Assistants-Werkzeugen oder Bring-your-own-data-Szenarien, und parallele Funktionsaufrufe müssen deaktiviert werden, wenn der Anreicherungsschritt auch Werkzeuge aufruft.

{
  "type": "object",
  "properties": {
    "attribute": { "type": "string", "enum": ["voltage", "ip_rating", "weight_kg"] },
    "value": { "type": "string" },
    "source_quote": { "type": "string" },
    "confidence": { "type": "string", "enum": ["high", "medium", "low"] }
  },
  "required": ["attribute", "value", "source_quote", "confidence"],
  "additionalProperties": false
}

Halten Sie jedes Attribut als eigenes kleines Objekt statt als breiten Datensatz je SKU. Ein fehlgeschlagenes Feld scheitert dann allein, und die Routing-Entscheidung lässt sich je Feld treffen.

Der Herkunftsnachweis hält fest, woher ein Wert stammt. Speichern Sie für jedes geschriebene Attribut den Wert, das Quelldokument, das Zeichenintervall des Zitats, das Modell und einen Hash des Prompts. Ein Prüfer oder Auditor kann dann von der Produktseite direkt zum exakten Satz im Datenblatt springen. Der folgende Datensatz ist illustrativ und enthält keine echten Produktdaten.

{
  "sku": "SKU-1001",
  "attribute": "max_pressure_bar",
  "value": "16 bar",
  "provenance": {
    "source_doc": "datasheet-rev3.pdf",
    "char_interval": [2184, 2199],
    "model": "<model-id>",
    "prompt_hash": "sha256:9c1e...",
    "confidence": "high"
  }
}

Wie entscheidet die Konfidenzsteuerung, was ein Mensch sieht?

Die Konfidenzsteuerung schickt jedes Feld in eines von drei Ergebnissen: Hohe Konfidenz mit prüfbarem Zitat wird automatisch freigegeben, mittlere Konfidenz landet in der Prüfwarteschlange, und niedrige oder nicht verankerte Werte werden verworfen oder mit Quelle einer Person vorgelegt. Die Entscheidung gehört zum Feld, nicht zur SKU. Ein Produkt kann zwölf automatisch freigegebene Attribute und eines zur Prüfung haben, und die Oberfläche sollte diese Aufteilung zeigen, statt den einen unsicheren Wert hinter einem Freigabe-Häkchen zu verbergen.

Die Zwei-Stufen-Variante hält die Kosten niedrig. Ein günstiges Batch-Modell läuft über den gesamten Katalog. Nur Felder mit niedriger oder mittlerer Konfidenz eskalieren an ein stärkeres Modell, und nur was danach noch unsicher ist, erreicht einen Menschen. Dieselbe Form nutze ich in meiner eigenen Arbeit: Der jev-decide-Skill, den ich verwende, liefert typisierte Entscheidungen mit Konfidenzwert und leitet Fälle mit niedriger Konfidenz an einen Menschen weiter, genau das Muster, das eine Attribut-Prüfwarteschlange braucht.

Wie gelangt die Anreicherung in Pimcore?

Der Schreibweg sollte über die API-Oberfläche des PIM führen, nicht über einen Datenbank-Abkürzungsweg. Pimcores Datahub ist die dokumentierte Integrationsschicht: standardmäßig eine GraphQL-API, mehrere Endpunkte je Anwendungsfall, Konfiguration zur Transformation der Daten und Workspace- und Schema-Definitionen, die einschränken, was jeder Endpunkt zeigt. Für einen Anreicherungsdienst ist diese Einschränkung nützlich, weil Sie damit genau die Attribute freigeben, die der Dienst schreiben darf, und keine anderen (Pimcore Datahub).

Pimcore liefert außerdem Automatisierung im PIM selbst. Seine Copilot-Aktionen laufen asynchron im Hintergrund, können mehrere Schritte und Nutzereingaben haben und werden manuell oder durch einen Scheduler gestartet. Eine Jobübersicht erlaubt, lange Läufe zu verfolgen, abzubrechen und neu zu starten (Pimcore Copilot). Bei einer Massennachpflege eines Katalogs ist diese Jobübersicht wichtiger als das Modell, denn ein Lauf, der auf halber Strecke scheitert, muss sich wieder anstoßen lassen.

Nutzen Sie Batch-APIs für den Massenlauf und asynchrone Jobs je Objekt für den laufenden Betrieb. Wo ein Batch-Tarif veröffentlicht ist, zeigt die Tabelle unten ihn mit der Hälfte des Standardtarifs; Batch-Jobs laufen aber asynchron, deshalb sollte ein neues SKU, das auf seine Beschreibung wartet, den Online-Pfad nehmen. Benennen Sie außerdem die Verantwortlichen: wer einen Prüfeintrag freigibt, welche Attribute nach der Freigabe gesperrt sind und was bei einem Wechsel der Promptversion erneut läuft. Das sind Workflow-Entscheidungen, und das PIM ist der Ort, an dem sie durchgesetzt werden.

Die Lesesicht, in der derselbe Katalog Kundenfragen beantwortet, behandelt RAG über Produktkatalogdaten, die ERP-Grenze Pimcore und ERP-Delta-Sync.

Was kostet die Anreicherung je 1.000 SKUs?

Die Token-Kosten sind die kleinste Position, aber die einzige, die sich exakt berechnen lässt. Angenommen, pro SKU fallen 2.500 Eingabe- und 500 Ausgabe-Token an, so sind 1.000 SKUs 2,5 Millionen Eingabe- und 0,5 Millionen Ausgabe-Token. Die Kosten ergeben sich aus Eingabe-Token mal Eingabepreis plus Ausgabe-Token mal Ausgabepreis, geteilt durch eine Million. Die Preise stehen Stand Oktober 2026: Die Google-Preise stammen von der Preisseite der Gemini-API, die Claude- und GPT-Sätze wie auf OpenRouter gelistet, nicht von den Anbieterseiten.

Rechenbeispiel: Gemini 3.5 Flash-Lite im Batch-Modus ergibt 2,5 × 0,15 $ plus 0,5 × 1,25 $, also 1,00 $. Derselbe Lauf auf Claude Haiku 5.5 zu Standardtarifen kostet 2,5 × 0,10 $ plus 0,5 × 0,50 $, also 0,50 $. Setzen Sie Ihre eigenen Token-Zahlen ein; sie sind die Annahme, die das Ergebnis am stärksten verschiebt. Ein Dreifach-Extraktionslauf über dasselbe Dokument vervielfacht die Eingabeseite ungefähr mit drei: Sendet jeder Durchgang die vollen 2.500 Eingabe-Token und bleibt die Ausgabe bei 500, steigt Claude Haiku 5.5 zu Standardtarifen von 0,50 auf 1,00 $ je 1.000 SKUs. Gemini 3.8 Flash kostet bis 31. Dezember 2026 0,75 $ und 3,75 $ je Million Token; ab 1. Januar 2027 nennt Google 1,50 $ und 7,50 $.

Die Token-Rechnung ist selten die eigentlichen Kosten, die Prüfzeit ist es. Ist r der Anteil der Felder, die zur Prüfung gehen, und t die Minuten, die eine Person je geprüftem Feld braucht, dann betragen die Arbeitskosten je 1.000 SKUs 1.000 × r × t Minuten, vor jeder Nacharbeit. Den Prüfanteil zu halbieren bringt meist mehr, als auf das billigste Modell zu wechseln; deshalb verdienen die Routing-Schwellen ebenso viel Feinabstimmung wie der Prompt.

Wie bewerten Sie die Anreicherung und betreiben die Prüfwarteschlange?

Bewerten Sie auf einem eingefrorenen Golden-Set von SKUs mit von Menschen geprüften Werten, und zwar je Feld: Precision, Recall und exakte Trefferquote je Attribut sowie die Kontrolle, dass jeder übernommene Wert ein Zitat hat, das sich auf die Quelle abbilden lässt. Durchschnittswerte verdecken Rückschritte bei einzelnen Attributen, deshalb berichten Sie je Attribut. Jede Prompt- oder Modelländerung läuft vor dem Livegang gegen das Golden-Set, und ein Rückschritt bei einem Attribut blockiert die Änderung. Die Dokumentextraktions-Forschung hilft bei der Terminologie: DocILE etwa umfasst 6.700 annotierte Geschäftsdokumente mit 55 Annotationsklassen sowie die Erkennung von Positionszeilen. Dessen Dokumente sind Rechnungen und Bestellungen, keine Industriedatenblätter, und ich habe keine überprüfbare veröffentlichte Genauigkeitsangabe zur LLM-Extraktion aus Datenblättern gefunden. Setzen Sie Ihre Ziele deshalb aus Ihrem eigenen Golden-Set, nicht aus einem Paper (DocILE).

• Die Quelle ist sichtbar: Das markierte Zitat steht neben dem vorgeschlagenen Wert, nicht hinter einem Link.
• Der Vergleich ist sichtbar: Aktueller PIM-Wert und vorgeschlagener Wert stehen nebeneinander.
• Ablehnung hat Gründe: ein Klick für „nicht in der Quelle“, „falsche Einheit“, „falsche Variante“ oder „mehrdeutig“, damit die Gründe in die nächste Bewertung einfließen.

Ablehnungen sind Bewertungsdaten für das Golden-Set und den Prompt, nicht nur geschlossene Tickets. Führen Sie jeden Ablehnungsgrund zurück in die Bewertung, damit derselbe Fehler nicht wiederkehrt.

Welche rechtlichen Regeln gelten für KI-geschriebene Katalogtexte?

Die kurze Antwort lautet: Das hängt davon ab, was der Text ist und wo er veröffentlicht wird. Dieser Beitrag ist keine Rechtsberatung. Für Katalogtexte in der EU sind drei Regelwerke relevant; die Einzelfragen klären Sie mit Ihrer Rechtsberatung.

Der EU AI Act, Artikel 50, gilt seit dem 2. August 2026. Die Offenlegungspflicht für Text in Absatz 4 betrifft KI-generierten Text, der veröffentlicht wird, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Sie entfällt, wenn der Inhalt einer menschlichen Prüfung oder redaktionellen Kontrolle unterlag und eine natürliche oder juristische Person die redaktionelle Verantwortung trägt; diese Ausnahme ist an Bedingungen geknüpft. Katalogtexte für den eigenen Shop sind nicht automatisch Text zur Information der Öffentlichkeit über Angelegenheiten von öffentlichem Interesse, aber diese Einordnung ist eine Frage für die Rechtsberatung und keine pauschale Schlussfolgerung (Artikel 50).

Die Richtlinie über unlautere Geschäftspraktiken, geändert durch die Richtlinie (EU) 2024/825, gilt ab dem 27. September 2026. Sie ergänzt Praktiken, die stets verboten sind, darunter generische Umweltaussagen ohne nachgewiesene anerkannte herausragende Umweltleistung und Aussagen, die auf der Kompensation von Treibhausgasen beruhen (EUR-Lex). Ein LLM, das eine Beschreibung durch „umweltfreundlich“ oder „klimaneutral“ aufwertet, schafft ein rechtliches Problem, keine bessere Formulierung. Verankern Sie das Verbot im Prompt und im Validator: Eine Liste verbotener Begriffe ist ein günstiger Schutz, und das Attributschema sollte kein Feld für Umweltaussagen enthalten, außer ein Quelldokument liefert eine.

Suchqualität ist der dritte Punkt. Googles Spam-Richtlinien nennen das Risiko beim Namen, skalierten Inhaltsmissbrauch: generative KI oder ähnliche Werkzeuge einsetzen, um viele Seiten ohne Mehrwert für Nutzer zu erzeugen, und Inhalte übersetzen oder umformulieren, um Seiten in Serie zu produzieren. Die Folge können eine Herabstufung der Website oder eine manuelle Maßnahme sein. Stand Oktober 2026 nennt die Richtlinie das Risiko direkt; prüfen Sie den aktuellen Wortlaut, bevor Sie in großem Umfang veröffentlichen (Google Search Central). Anreicherung, die geprüfte Attribute ergänzt, schafft Mehrwert; Anreicherung, die aus denselben Attributen dünne Seiten vervielfacht, nicht.

Wann sollten Sie keine LLM-Anreicherung einsetzen?

Verzichten Sie, wenn die Quelldokumente den Wert nicht enthalten. Das Modell kann nur verankern, was geschrieben steht; eine fehlende Angabe sollte eine Lücke im Bericht sein, keine erfundene Zahl. Meiden Sie es bei Sicherheits-, Medizin- oder Compliance-Spezifikationen, bei denen ein falscher Wert Folgen hat, die Sie nicht rechtzeitig prüfen können. Lassen Sie es bei sehr kleinen Katalogen weg, in denen eine Person den Text schneller schreibt, als sich die Pipeline aufbauen und bewerten lässt, und wenn eine sauberere ERP- oder Lieferantenschnittstelle das Problem zuerst löst. Das sind Abwägungen, keine Verbote; der Belegtest entscheidet die meisten davon.

Prüfen Sie vor dem Livegang diese Punkte:

1. Ein eingefrorenes Golden-Set mit Zielwerten je Attribut, abgestimmt mit den Verantwortlichen für den Katalog.
2. Eine Verankerungsprüfung: kein Schreibvorgang ohne Zitat, das sich auf ein Quellintervall abbilden lässt.
3. Schema- und Bereichsprüfung im eigenen Code, nicht nur im Ausgabemodus des Modells.
4. Routing-Schwellen je Feld, auf dem Golden-Set abgestimmt, mit einer Prüfoberfläche, die Quelle und Vergleich zeigt.
5. Herkunftsnachweis zu jedem geschriebenen Wert und eine Regel, was bei einer Prompt- oder Modelländerung erneut läuft.
6. Kosten je 1.000 SKUs mit Ihren Token-Zahlen berechnet und mit der Arbeitsformel oben abgeglichen.
7. Eine Compliance-Prüfung zu KI-Kennzeichnung, Umweltaussagen und Suchrichtlinien, vor dem ersten öffentlichen Lauf freigegeben.

Wenn Sie das für einen B2B-Katalog aufbauen, finden Sie meine Arbeit im Bereich B2B-E-Commerce. Ein Anreicherungsweg ist nur so verlässlich wie die Belege, die er liest; fangen Sie dort an.

Quellen

1. Google LangExtract, GitHub README (v1.6.0)
2. Anthropic: reduce hallucinations
3. Microsoft Learn: Azure OpenAI structured outputs (updated Aug 2026)
4. DocILE: document information localization and extraction (ICDAR 2023)
5. Pimcore docs: Datahub
6. Pimcore docs: Copilot
7. Google Search Central: spam policies
8. EU AI Act, Article 50 (artificialintelligenceact.eu)
9. EUR-Lex: Directive (EU) 2024/825 amending the Unfair Commercial Practices Directive
10. Google AI for Developers: Gemini API pricing
11. OpenRouter: models API (rates as listed, Oct 2026)