Shop-Suche, die findet: Katalogdaten mit KI anreichern

Ein Kunde tippt «Akkuschrauber 18V» in deine Shop-Suche und bekommt null Treffer. Nicht, weil deine Suchmaschine schlecht wäre: Das Attribut «Spannung» wurde in deinem Katalog schlicht nie gepflegt. Die beste Suchmaschine kann nur finden, was im Index steht. Fehlende Attribute, leere Beschreibungen und uneinheitliche Kategorien kompensiert kein Werkzeug der Welt.

Wie groß das Problem ist, zeigt das Baymard Institute: 56 Prozent der untersuchten E-Commerce-Sites unterstützen die Suchbedürfnisse ihrer Nutzer nicht angemessen (baymard.com, Abruf 04.09.2026). Auffällig ist, wo es hakt: 39 Prozent der Sites haben Probleme mit Feature-Suchen wie «wasserdicht», 43 Prozent mit Use-Case-Suchen wie «Bohrer für Beton», 54 Prozent mit Abkürzungs-Suchen. Das sind genau die Anfrage-Typen, die gepflegte Attribute und Synonyme brauchen.

Meine Beobachtung aus Projekten deckt sich damit: Wenn eine Shop-Suche enttäuscht, fällt der Verdacht zuerst auf die Suchmaschine. Ein Blick in den Index zeigt dann oft etwas anderes: Die Hälfte der Produkte hat keine Beschreibung, Attribute sind sporadisch gepflegt, Kategorien historisch gewachsen. Ein Werkzeugwechsel allein ändert daran nichts.

Hier setzt KI-Anreicherung an: Ein Sprachmodell liest deine vorhandenen Produkttexte und Datenblätter und füllt daraus strukturierte Attributfelder, Kategorien und Kurzbeschreibungen. Nicht als Selbstzweck, sondern damit Suche und Facetten Material zum Arbeiten haben.

Eine Abgrenzung vorab: Wie du Produktdaten technisch aus Hersteller-PDFs extrahierst, habe ich im Artikel KI-Extraktion von Produktdaten aus Hersteller-PDFs beschrieben. Hier geht es um die Such-Perspektive: welche Anreicherung deine Treffer konkret verbessert und wie du daraus einen messbaren Kreislauf machst.

Vorab: «Bessere Daten» ist zu abstrakt, um damit zu arbeiten. Für die Suche zählen vier konkrete Hebel: Attribute für Facetten, Synonyme, einheitliche Kategorien und durchsuchbare Kurzbeschreibungen. Ich zeige sie am Beispiel von Meilisearch; was das Werkzeug kann und wann es sich lohnt, steht im Grundlagen-Artikel Was ist Meilisearch?. Das Prinzip gilt für jede Suchmaschine.

In Meilisearch wird ein Feld erst dann zum Filter, wenn du es als filterableAttribute deklarierst (meilisearch.com/docs, Abruf 04.09.2026). Der Haken liegt eine Ebene tiefer: Deklarieren kannst du nur, was in den Daten existiert. Ohne gepflegtes Feld «Spannung» gibt es keine 18-Volt-Facette – egal, wie gut die Suchmaschine ist.

Sind die Felder befüllt, liefert die facetDistribution die Trefferzahl je Facettenwert: Dein Kunde sieht «18 V (42 Produkte)», klickt und filtert. Wichtig ist Vollständigkeit: Eine Facette, die nur bei der Hälfte der Produkte gepflegt ist, blendet die andere Hälfte des Sortiments faktisch aus. Genau diese Lücken füllt ein LLM aus vorhandenen Beschreibungstexten.

Ein Beispiel aus dem Werkzeughandel: Kunden filtern nach Spannung, Aufnahme und Gewicht. Stehen diese Werte nur irgendwo im Fließtext des Datenblatts, existieren sie für die Facetten-Navigation nicht. Die Anreicherung übersetzt Fließtext in Struktur – und erst Struktur macht filterbar.

Deine Kunden suchen nicht mit deinen Begriffen. Im B2B ist die Lücke am größten: Der Katalog sagt «Winkelschleifer», der Monteur sucht «Flex». Meilisearch kennt dafür einseitige Synonyme («Flex» findet Winkelschleifer, aber nicht umgekehrt) und wechselseitige, mit klaren Grenzen: höchstens 50 Synonyme pro Begriff, und Anfragen ab vier Wörtern matchen keine Synonyme mehr (meilisearch.com/docs, Abruf 04.09.2026).

Die Synonym-Liste selbst ist Anreicherungs-Arbeit: Ein LLM schlägt aus Produkttexten und Suchprotokollen Kandidaten vor, freigeben solltest du sie manuell. Wie tief die Sprachlücke zwischen Artikelnummer und Anwendungsbegriff im B2B reicht, habe ich im Artikel Semantische Produktsuche im B2B beschrieben.

Der dritte Hebel: einheitliche Kategorien. Wenn deine Kategorie-Facette in «Bohrmaschinen», «Bohrmaschine» und «Bohrer & Zubehör» zerfällt, ist sie für Kunden wertlos. Ein LLM klassifiziert Produkte gegen eine feste Kategorienliste – in unseren Projekten mit guter Trefferquote, solange die Liste eindeutig ist. Die Liste definierst du, nicht das Modell.

Der vierte Hebel: durchsuchbare Kurzbeschreibungen. Ein Produkt, das im Index nur aus Artikelnummer und Herstellernamen besteht, ist für Suchbegriffe wie «leise» oder «für den Außenbereich» unsichtbar. Zwei bis drei generierte Sätze aus dem Datenblatt geben der Volltextsuche Material – mehr braucht es oft nicht.

Falls du über semantische Suche nachdenkst, gilt das übrigens genauso: Auch Embeddings entstehen aus deinen Produkttexten, und ein leeres Beschreibungsfeld bleibt auch als Vektor leer – mehr dazu im Artikel Semantische Suche. Anreicherung zahlt also auf beide Welten ein.

Der häufigste Fehler, den ich in Anreicherungs-Projekten sehe: alles auf einmal anreichern zu wollen. Vierzig Attribute für den ganzen Katalog, bevor die erste Suchanfrage ausgewertet wurde. Besser funktioniert ein Kreislauf, der bei den echten Suchanfragen deiner Kunden beginnt – das ist ein Erfahrungswert aus unserer Projektarbeit, kein Naturgesetz.

Jede Suchanfrage ohne Treffer ist eine dokumentierte Enttäuschung – und dein präzisestes Anforderungsdokument. Meilisearch Cloud weist die No-Result-Rate direkt in den Analytics aus: den Anteil der Suchen mit null Ergebnissen, der Lücken in deinen Inhalten und Synonymen sichtbar macht. Wie lange diese Daten aufbewahrt werden, hängt von deinem Cloud-Plan ab (meilisearch.com/docs, Abruf 04.09.2026).

Ehrlicherweise: Beim Self-Hosting bekommst du diese Auswertung nicht geschenkt. Dann loggst du Suchanfragen und Trefferzahlen selbst mit. Das ist ein überschaubarer Aufwand von wenigen Stunden, und er lohnt sich ab dem ersten Tag.

Sortiere die Null-Treffer-Anfragen in drei Stapel. Synonym-Fall: Das Produkt existiert, dein Kunde nennt es nur anders – «Flex» statt «Winkelschleifer». Fehlendes-Attribut-Fall: Der Kunde sucht eine Eigenschaft wie «18V», die nie als Feld gepflegt wurde. Sortimentslücke: Das Produkt gibt es wirklich nicht; das ist eine wertvolle Information für den Einkauf, aber keine Suchaufgabe.

Die ersten beiden Stapel sind dein Arbeitsvorrat: Synonyme wandern in die Index-Einstellungen, fehlende Attribute füllt der LLM-Lauf. Als wiederkehrender Workflow aufgesetzt läuft das wöchentlich, ohne dass jemand daran denken muss – wie solche Abläufe aussehen, zeige ich unter Prozessautomatisierung.

Miss vor und nach jeder Anreicherungs-Runde dieselben Kennzahlen: No-Result-Rate, Klickrate auf Treffer, Facetten-Nutzung. Sinkt die No-Result-Rate nach einer Synonym-Runde nicht, war der Stapel falsch sortiert – auch das ist ein Ergebnis. Aus meiner Erfahrung reicht ein einfaches Dashboard mit Wochenwerten völlig aus.

Wichtig ist nur, dass du vor der ersten Runde misst: Ohne Ausgangswert kannst du später nicht belegen, was die Anreicherung gebracht hat. Weder dir selbst noch deiner Geschäftsführung.

So schließt sich der Kreislauf: Das Protokoll zeigt neue Lücken, der nächste Lauf füllt sie. Was jenseits der Daten zu einer guten Suche gehört (Platzierung, Geschwindigkeit, Fehlertoleranz), steht im Artikel Suchfunktion für deine Website.

Zur Einordnung: Eine feste Zahl für KI-Anreicherung wäre unseriös, weil die Kosten von Kataloggröße und Textmenge abhängen. Der Rechenweg ist dafür einfach: Tokens pro Produkt mal Anzahl der Produkte mal Modellpreis. Den kannst du für deinen Katalog in fünf Minuten selbst durchrechnen.

Ein Beispiel mit Preisen vom 04.09.2026: gpt-5-mini kostet 0,25 $ pro Million Input-Tokens und 2,00 $ pro Million Output-Tokens (developers.openai.com, Abruf 04.09.2026). Für 50.000 Produkte mit je rund 1.000 Input-Tokens (Produkttext plus Prompt) und 300 Output-Tokens (strukturierte Attribute) ergibt das etwa 12,50 $ für Input und 30 $ für Output: rund 42,50 $ für den kompletten Katalog.

Über die Batch-API halbiert sich das auf gut 21 $, denn OpenAI gewährt dort durchgehend 50 Prozent Rabatt. Anreicherung ist selten zeitkritisch, die längere Verarbeitungszeit stört also nicht. Das kleinere gpt-5-nano (0,05 $ Input, 0,40 $ Output je Million Tokens) drückt die Rechnung weiter – nach unserer Erfahrung taugt es für Kategorisierung, für Attribut-Extraktion greife ich zum größeren Modell.

Rechne mit deinen eigenen Faktoren: Ein langes Datenblatt kann 3.000 Tokens haben, ein knapper ERP-Datensatz 200. Der Rechenweg bleibt gleich, nur die Zahlen ändern sich. Deshalb nenne ich bewusst keine Pauschale.

Die ehrliche Pointe: Die API-Kosten sind der kleinste Posten des Projekts. Der echte Aufwand steckt im Attributmodell (welche Felder, welche Einheiten, welche Pflichtwerte) und in der Qualitätssicherung. Beides sind Personentage, keine API-Cents – auch das ein Erfahrungswert aus unseren Projekten.

Ein LLM, das eine Spannung im Quelltext nicht findet, kann trotzdem eine liefern: geratene 230 Volt bei einem 400-Volt-Gerät. Das ist schlimmer als ein leeres Feld. Das leere Feld macht das Produkt in einer Facette unsichtbar; der erfundene Wert macht es in der falschen Facette sichtbar. Dein Kunde filtert auf 230 V, bestellt – und die Retoure ist programmiert.

Das Risiko ist kein Randfall: Sprachmodelle sind darauf trainiert, plausible Antworten zu geben. Plausibel heißt bei Produktdaten: eine übliche Spannung, ein gängiges Gewicht, ein typisches Material. Genau deshalb fallen erfundene Werte oft erst beim Abgleich mit der Originalquelle auf.

Anders formuliert: Ein leeres Feld ist eine bekannte Lücke, ein erfundener Wert ist ein verstecktes falsches Versprechen. Facetten funktionieren nur, wenn deine Kunden ihnen vertrauen können.

Drei Regeln haben sich in unseren Projekten bewährt. Leerlassen erlauben: Der Prompt weist das Modell ausdrücklich an, ein Feld leer zu lassen, wenn der Wert nicht in der Quelle steht – Raten ist verboten. Confidence-Schwellen nutzen: Sichere Werte gehen automatisch in den Katalog, unsichere landen in einer Prüf-Warteschlange. Stichproben durch Fachleute: Pro Lauf prüft jemand mit Produktwissen eine Zufallsstichprobe gegen die Originalquelle.

Wie streng du die Schwellen setzt, hängt vom möglichen Schaden ab: Bei einer Farbangabe ist ein Fehler ärgerlich, bei einer elektrischen Kennzahl gefährlich. Setze die Automatik-Schwelle deshalb je Attribut, nicht global – sicherheitsrelevante Felder gehen immer durch die Prüf-Warteschlange.

Der letzte Punkt ist nicht verhandelbar: Ohne Stichproben trainierst du Fehler in den Katalog, und jeder spätere Lauf baut auf ihnen auf. Definiere außerdem Pflichtfelder je Kategorie – ein Akkuschrauber ohne Spannungsangabe gilt nicht als «angereichert», sondern bleibt auf der Nacharbeitsliste.

Für generierte Beschreibungstexte gilt Ähnliches: Auch deine Markensprache braucht definierte Grenzen, sonst klingt nach dem dritten Lauf jedes Produkt nach demselben generischen LLM-Deutsch. Das ist ein eigenes Thema im PIM-Umfeld – den Rahmen setzt du am besten vor dem ersten Lauf.

Du musst kein großes Projekt aufsetzen, um anzufangen. Mein Vorschlag für die erste Woche: Schneide dein Suchprotokoll mit und zieh die Null-Treffer-Anfragen. Sortiere die Top 20 in die drei Stapel Synonym, fehlendes Attribut, Sortimentslücke. Danach weißt du, ob dein Problem in den Daten liegt, im Sortiment oder in der Suchmaschine selbst – für Letzteres ist Was ist Meilisearch? dein Startpunkt. Das kostet dich nichts außer einer Woche Geduld.

Für den ersten Anreicherungs-Lauf gilt: klein anfangen. Ein Attribut, eine Kategorie, hundert Produkte – dann Stichprobe, dann messen. So bekommst du ein Gefühl für die Fehlerquote deines Setups, bevor du den ganzen Katalog durch das Modell schickst.

Wenn du dabei Unterstützung willst, vom Attributmodell über den LLM-Workflow bis zur Such-Integration: Ich schaue mir dein Suchprotokoll und deinen Katalog gern gemeinsam mit dir an. Buch dir ein kostenloses Erstgespräch – in 30 Minuten klären wir, welcher der drei Stapel bei dir der größte ist und ob sich ein Anreicherungs-Lauf rechnet.