Exakte Artikelnummer und vage Anfrage in einer Suche

Ein Einkäufer im B2B-Shop hat die Artikelnummer aus einer alten Bestellung vor sich liegen. Er tippt 10-45-8892 in das Suchfeld und drückt Enter. Die Ergebnisseite bleibt leer, obwohl genau dieser Artikel im Katalog steht und lieferbar ist.

Am selben Vormittag sucht eine andere Besucherin nach einem leisen Ventilator für das Schlafzimmer. Sie kennt keine Nummer. Sie beschreibt, was sie braucht.

Zwei Menschen, ein Suchfeld, zwei komplett verschiedene Aufgaben. Die eine Anfrage verlangt einen exakten Treffer auf eine Zeichenkette. Die andere verlangt Verständnis für eine Absicht. Eine Suche, die für den einen Fall sauber eingerichtet ist, fällt beim anderen oft still auf null Treffer. Genau dieser Zielkonflikt ist das Thema dieses Beitrags, und er trifft Shops mit gepflegten Artikelnummern-Sortimenten besonders hart.

Zwei Anfragen, ein Suchfeld

Über dasselbe Feld nimmt eine Such-API (Search API) beide Anfragen entgegen. Für die Technik dahinter sind es aber zwei Welten.

Auf der einen Seite stehen die exakten Bezeichner. Dazu gehören die interne Artikelnummer (oft SKU genannt), die EAN und die international gebräuchliche GTIN. Solche Codes sind eindeutig. Der Nutzer erwartet den einen richtigen Artikel, sofort, ohne Alternativen. Ein zweitbestes Ergebnis ist bei einem Bezeichner wertlos. Im B2B ist das der Normalfall. Wer nachbestellt, kennt die Nummer aus dem letzten Lieferschein und möchte damit direkt in den Warenkorb.

Verpasst die Suche einen exakten Treffer, kostet das im B2B bares Geld. Findet der Einkäufer seine Nummer nicht, greift er zum Telefon oder zum Wettbewerb. Der Bestellvorgang bricht ab, bevor er beginnt. Das kostet direkt Umsatz. Deshalb wiegt eine leere Seite bei einem Bezeichner schwerer als eine mäßige Trefferliste bei einer Beschreibung.

Daneben steht die Welt der Beschreibung. "leiser ventilator schlafzimmer", "wasserdichte jacke herren blau", "kabel für alten beamer". Hier gibt es keine eindeutige Zeichenkette. Es gibt eine Absicht, den User Intent, und viele Produkte, die dazu passen könnten. Der Nutzer erwartet eine sinnvoll sortierte Auswahl, keinen einzelnen Treffer.

Der Fehler beginnt dort, wo man beide Welten mit einer einzigen Verarbeitungslogik bedient. Was den einen Fall gut macht, ruiniert den anderen. Das liegt selten an der Datenqualität oder am Budget und meistens an der Architektur der Suche.

Warum ein reiner Tokenizer an "5000g" und "5 kg" scheitert

Klassische Volltextsuchen wie Elasticsearch, OpenSearch oder Solr zerlegen jeden Text vor dem Speichern in einzelne Bausteine. Diesen Schritt übernimmt ein Tokenizer, eingebettet in einen sogenannten Analyzer. Der Standard-Tokenizer trennt an Wortgrenzen, die im Unicode-Standard für Textsegmentierung definiert sind (Quelle: Unicode UAX #29, abgerufen am 11.09.2026). Aus "wasserdichte jacke" werden die Token "wasserdichte" und "jacke". Für Fließtext ist das genau richtig.

Bei Maßangaben kippt das Verfahren. "5000g" bleibt je nach Regel ein einziges Token oder zerfällt in "5000" und "g". Die Eingabe "5 kg" erzeugt die Token "5" und "kg". "5kg" ergibt wieder etwas anderes. Auf Zeichenebene hat keine dieser Varianten mit den übrigen etwas gemeinsam, obwohl fünf Kilogramm und fünftausend Gramm dieselbe Menge sind. Die Suchmaschine vergleicht Zeichenketten, keine physikalischen Größen. Ein feiner Unterschied. Ohne eine Regel, die Einheiten vereinheitlicht, findet die Anfrage "5 kg" das Produkt mit "5000g" im Titel nicht, obwohl beide Angaben für jeden Menschen offensichtlich dasselbe Gewicht bezeichnen und der Kunde die Ware im Katalog sogar vor Augen hat.

Solch ein Analyzer besteht aus mehreren Stufen. Vor dem Tokenizer stehen Zeichenfilter, danach folgen Token-Filter für Kleinschreibung, Stammformen oder Synonyme. Die offizielle Referenz von Elasticsearch beschreibt die verfügbaren Tokenizer im Detail (Quelle: Elasticsearch, Analysis Tokenizers, abgerufen am 11.09.2026). Apache Solr dokumentiert dieselbe Bandbreite für sein Ökosystem (Quelle: Apache Solr, Tokenizers, abgerufen am 11.09.2026). Jede Stufe verbessert einen Anwendungsfall und kann einen anderen verschlechtern.

Kleinschreibung und Stammformen verschärfen das bei Codes zusätzlich. Ein Token-Filter, der "AB12" zu "ab12" senkt, bleibt für Fließtext harmlos. Bei einer Artikelnummer mit fester Schreibweise verändert er den Wert. Dasselbe gilt für das Stemming, das Wortenden abschneidet. Auf Sprache angewandt bringt das einen Gewinn. Bei einer SKU kann dagegen schon ein Zeichen zu viel oder zu wenig dazu führen, dass der passende Artikel im Ergebnis fehlt.

Einheiten sind kein Tippfehler

Häufig hält man das für ein Problem der Unschärfe und dreht an der Fehlertoleranz (Typo-Tolerance). Die korrigiert vertippte Buchstaben, etwa "venitlator" zu "ventilator". Eine Einheitenangabe ist aber kein Tippfehler. "5 kg" ist völlig korrekt geschrieben. Der Abstand zu "5000g" entsteht allein durch eine fehlende Umrechnung der Einheit. Wie Fehlertoleranz sauber arbeitet, zeigt der Beitrag zur Fehlertoleranz in der Shop-Suche. Das Einheitenproblem löst sie nicht.

Warum eine gültige Artikelnummer null Treffer bringt

Bezeichner leiden am selben Analyzer, nur in die andere Richtung. Eine Artikelnummer wie 10-45-8892 enthält Bindestriche. Der Standard-Analyzer wertet Bindestrich, Schrägstrich oder Punkt als Trennzeichen und macht daraus die Token "10", "45" und "8892". Sucht ein Kunde die vollständige Nummer, liegt im Index kein Token, das exakt so heißt. Das Ergebnis ist eine leere Seite trotz vorhandenem Artikel. Welche Trennzeichen eine Suche wie behandelt, vertieft der Beitrag zu Tokenseparatoren in der Shop-Suche.

Bei der EAN kommt die Ziffernlogik dazu. Eine EAN-13 besteht aus 13 Ziffern samt Prüfziffer und wird über die GS1-Organisation vergeben (Quelle: GS1 Germany, GTIN, abgerufen am 11.09.2026). Wird die Nummer aus einer Tabelle kopiert oder mit einem Scanner erfasst, hängt manchmal eine führende Null davor oder fehlt. Ein Analyzer, der Zahlen normalisiert und führende Nullen entfernt, macht aus "0040063…" und "40063…" je nach Konfiguration verschiedene oder identische Werte. Der Nutzer merkt davon nichts. Er sieht nur, dass sein Scan ins Leere läuft. Aus seiner Sicht ist das Produkt nicht vorhanden, obwohl es lagernd ist, einen sauberen Datensatz besitzt und über die richtige Nummer eindeutig auffindbar wäre, sofern die Suche die Ziffernfolge unverändert behandeln würde.

Der Kern ist eine echte Zwickmühle. Ist der Analyzer für flüssige Sprache optimiert, zerlegt er exakte Bezeichner. Behandelt er Bezeichner dagegen unangetastet, etwa über einen Keyword-Tokenizer, der die ganze Eingabe als ein Token behält, dann sinkt bei einer Beschreibung die Zahl der Treffer. Ein einzelnes Feld mit einer einzelnen Verarbeitungsregel kann beide Aufgaben nicht zugleich erfüllen. Dreht ein Team nur an dieser einen Stellschraube, verschiebt sich das Problem lediglich von der einen Anfrageart zur anderen.

Der hybride Ansatz mit zwei Schichten

Die Lösung besteht darin, beide Verarbeitungswege parallel zu betreiben und ihre Ergebnisse in einer Antwort zusammenzuführen. Dieser Aufbau heißt hybride Suche (Hybrid Search).

Eine exakte Schicht hält Bezeichner in einem eigenen, robusten Feld. Artikelnummer, EAN und GTIN liegen dort so, dass Trennzeichen, Groß- und Kleinschreibung sowie führende Nullen nach klaren Regeln behandelt werden. Diese Schicht ist deterministisch. Sie liefert entweder den einen richtigen Treffer oder gar keinen, und bei einem Code ist das genau das gewünschte Verhalten.

Eine semantische Schicht kümmert sich um die Beschreibung. Die semantische Suche (semantic search) ordnet eine Formulierung einem Produktkonzept zu, auch wenn kein Wort davon wörtlich im Titel steht. "leiser ventilator" trifft dann auch ein Gerät, das mit "geräuscharm" ausgezeichnet ist. Diese Schicht stützt sich auf Semantisches Verständnis und geht damit über den reinen Zeichenabgleich hinaus.

In der Hybrid LLM Search von BatteryIncluded laufen beide Schichten in einer einzigen Anfrage. Erkennt das System in der Eingabe einen Bezeichner, gewinnt die exakte Schicht und legt den passenden Artikel nach oben. Beschreibt die Eingabe eine Absicht, trägt die semantische Schicht das Ergebnis. Ein Moduswechsel durch den Nutzer entfällt. Das Produkt Volt Search® setzt diesen Ansatz als Infrastruktur um. Es aggregiert die Daten direkt aus ERP, PIM, CMS und Shopsystem und hält sie in einer entkoppelten Such-Infrastruktur vor.

Praktisch entscheidet eine Bewertung, welches Ergebnis oben landet. Ein exakter Bezeichner-Treffer bekommt das höchste Gewicht und lässt sich kaum überstimmen. Fehlt ein Bezeichner, zählt die semantische Nähe zwischen Anfrage und Produkt. So bleibt die Rangfolge nachvollziehbar, und die Suche verhält sich bei jedem Anfragetyp vorhersehbar. Codes und Beschreibungen führen zu einem einheitlichen Sucherlebnis. Für den Betreiber heißt das, dass er die Suche einmal sauber einrichtet und danach denselben Einstiegspunkt anbietet, den Stammkunden mit ihren Nummern ebenso nutzen wie Neukunden mit einer frei formulierten Frage oder der Einkauf mit einem gescannten Code.

Darüber liegen weitere Bausteine. Die Facettensuche (Faceted Search) grenzt eine große Trefferliste nach Marke, Größe oder Preis ein. Die Echtzeit-Synchronisation (Real-time Sync) hält den Index aktuell, sobald sich Bestand, Preis oder eine Artikelnummer im Vorsystem ändert. Weil dieser Aufbau ohne Cookies und ohne Nutzerprofile auskommt, bleibt er cookieless und als DSGVO-konforme KI einsetzbar.

Den ausführlichen Produktkontext dazu liefert der Beitrag Hybrid LLM Suche als letzte Stufe der Produktsuche. Für die Grundlagen der Bedeutungssuche steht der Beitrag Was ist semantische Suche bereit.

Vier Anfragen durch dieselbe Suche

Beide Schichten bearbeiten die vier Eingaben vom Anfang wie folgt. Keine davon braucht einen eigenen Suchmodus.

Am deutlichsten zeigt der gemischte Fall "akkuschrauber 18v 5 ah" das Zusammenspiel. "18v" und "5 ah" sind technische Angaben mit Einheiten. Sie profitieren von derselben Einheiten-Normalisierung, die "5 kg" und "5000g" zusammenbringt. Marke und Produktart steuert die semantische Schicht bei. Aus einer einzigen Eingabe wird so eine Trefferliste, die technische Filter und Verständnis verbindet.

Wichtig ist die Reihenfolge der Entscheidung. Die exakte Schicht prüft zuerst, ob überhaupt ein Bezeichner vorliegt. Findet sie einen, dominiert er das Ergebnis, weil ein Code selten ein Zufall ist. Findet sie keinen, bleibt die Bühne der semantischen Schicht. Genau diese Orchestrierung der beiden Schichten unterscheidet den Aufbau von einer Suche, die nur einen einzigen Weg kennt.

Zur Veranschaulichung ein Beispiel aus dem Alltag. Ein Kunde kopiert die dreizehnstellige EAN aus einer PDF-Rechnung und fügt sie mit einem versehentlichen Leerzeichen in der Mitte ein. Die exakte Schicht entfernt das Leerzeichen nach ihrer Regel und trifft den Artikel dennoch. Kurz darauf sucht ein Kollege nach "stapelbare kiste grau". Kein Code, keine Nummer. Die semantische Schicht übernimmt und liefert passende Behälter, obwohl das Wort "Behälter" in der Anfrage gar nicht auftaucht. Zwei sehr verschiedene Eingaben, dieselbe Suche, in beiden Fällen ein brauchbares Ergebnis.

Grenzen, wo weiterhin ein Mensch konfiguriert

Die hybride Suche nimmt niemandem die Fachentscheidungen ab. Sie führt die Regeln aus, die ein Mensch vorher festlegt. An mehreren Stellen liegt die Entscheidung beim Menschen.

Zuerst die Frage, welche Felder überhaupt Bezeichner sind. Ein Shop hat oft mehrere Zahlenspalten. Artikelnummer, EAN, Herstellernummer, dazu vielleicht eine interne Auftragsnummer. Welche davon als exakter Code gilt und in die exakte Schicht gehört, muss ein Mensch benennen. Das System rät es nicht.

Dann die Normalisierungsregeln. Ist der Bindestrich in 10-45-8892 Teil der Nummer, oder trennt er einen Bereich? Werden führende Nullen entfernt oder behalten? Soll "5000g" zu Kilogramm umgerechnet werden, oder bleibt Gramm die Basiseinheit? Solche Fragen sind betriebliche Entscheidungen, keine technischen Selbstläufer. Sind diese Regeln einmal mit den Fachabteilungen abgestimmt, verhindern sie genau die stillen Fehlschläge, bei denen ein vorhandener Artikel für den Kunden unsichtbar bleibt und der Umsatz unbemerkt an anderer Stelle verloren geht.

Ein kurzer Blick auf die Punkte, die typischerweise Handarbeit bleiben:

• Zuordnung der Bezeichnerfelder aus ERP und PIM zur exakten Schicht
• Einheiten-Wörterbücher für branchenspezifische Maße, etwa laufende Meter oder Gebindegrößen
• Fachvokabular, das kein Sprachmodell aus dem Training kennt, etwa interne Produktkürzel
• die Regel, wann ein Bezeichner-Treffer alle anderen Ergebnisse überstimmt

Auch die Ausnahmen gehören auf den Tisch. Manche Angaben sehen aus wie ein Code, meinen aber etwas anderes, etwa eine Jahreszahl im Produktnamen. Ob "2024" als Bezeichner oder als gewöhnliches Wort zählt, klärt eine Regel, die ein Mensch setzt. Solche Randfälle sind selten. Übersieht man sie, entsteht daraus die nächste leere Ergebnisseite für einen Kunden, der eigentlich gefunden hätte, was er suchte.

Diese Einrichtung ist einmalige Arbeit mit gelegentlicher Pflege, kein Dauerbetrieb von Hand. Sobald die Regeln stehen, laufen exakte und semantische Schicht ohne täglichen Eingriff. Der Mensch bleibt bei den Fragen von Bedeutung und Geschäftslogik im Prozess, während die Suche die Rechenarbeit übernimmt. Fachleute nennen dieses Zusammenspiel Human-in-the-Loop.

Häufige Fragen

Was ist der Unterschied zwischen einer Artikelnummer und einer EAN?
Die Artikelnummer, oft SKU genannt, ist ein interner Code des Shops und frei vergeben. Die EAN und die international gebräuchliche GTIN sind standardisierte Nummern, die über die GS1-Organisation zugeteilt werden. Ein Produkt kann beide tragen. Eine gute Suche findet es über jeden dieser Codes.

Warum liefert die Suche nach einer gültigen Artikelnummer keine Treffer?
Meist zerlegt ein Tokenizer die Nummer an Bindestrichen oder Schrägstrichen in Teile. Die vollständige Zeichenkette steht dann nicht im Index. Eine exakte Schicht mit eigener Behandlung von Trennzeichen behebt das.

Warum findet die Suche "5 kg" nicht, wenn im Titel "5000g" steht?
Beide Angaben meinen dieselbe Menge, bestehen aber aus verschiedenen Zeichen. Ohne eine Regel zur Umrechnung von Einheiten vergleicht die Suche nur Zeichen und erkennt keine Übereinstimmung. Fehlertoleranz greift hier nicht, weil kein Tippfehler vorliegt.

Muss die Suche zwischen einem SKU-Modus und einem Freitext-Modus umschalten?
Ein Moduswechsel durch den Nutzer ist überflüssig. Die hybride Suche prüft jede Eingabe zugleich auf einen Bezeichner und auf eine Beschreibung. Erkennt sie einen Code, gewinnt der exakte Treffer, andernfalls trägt die semantische Schicht.

Wie kombiniert man exakten Artikelnummern-Match mit einer unscharfen Anfrage?
Man betreibt zwei Schichten parallel und führt ihre Ergebnisse zusammen. Eine deterministische Schicht für Codes, eine semantische Schicht für Sprache. Die Orchestrierung entscheidet je Anfrage, welche der beiden Schichten das Ergebnis trägt, und sorgt dafür, dass ein erkannter Code seinen Vorrang vor der unscharfen Beschreibung behält.

Braucht eine hybride Suche einen eigenen Index oder reicht die Shop-Datenbank?
Sinnvoll ist ein eigener Suchindex, der aus ERP, PIM, CMS und Shopsystem gespeist wird. Er hält die Last von der Verkaufsdatenbank fern und erlaubt eine für die Suche optimierte Struktur. Eine Echtzeit-Synchronisation hält ihn aktuell.

Ist die hybride Suche DSGVO-konform?
Der beschriebene Aufbau kommt ohne Cookies und ohne Nutzerprofile aus. Damit bleibt er cookieless und als DSGVO-konforme KI einsetzbar, ganz ohne zusätzliches Consent-Banner.

Eine Anfrage, beide Aufgaben

Eine Suche, die exakte Artikelnummern und vage Beschreibungen zugleich bedient, ist kein Zufall der Konfiguration. Sie folgt aus einem Aufbau mit zwei abgestimmten Schichten und aus klaren Regeln für die Bezeichner.

Sehen Sie sich an, wie das mit Ihren echten Artikeldaten aussieht, von der Artikelnummer über die EAN bis zur frei formulierten Anfrage. Zu Ihrer kostenlosen Demo, oder schreiben Sie uns über die Kontaktseite.