Fehlertoleranz auf Feldebene: Wenn "Hosenträger" und "Hosen Träger" verschiedene Ergebnisse liefern

Wenn ein Leerzeichen den Umsatz kostet

Ein Kunde tippt "Hosenträger" in das Suchfeld eines mittelständischen Mode-Shops. Die Suche liefert 47 Treffer, sortiert nach Relevanz. Eine Minute später tippt der gleiche Kunde im gleichen Shop "Hosen Träger", weil sein Smartphone das Wort beim Wischen getrennt hat. Die Suche liefert null Ergebnisse. Im Backend liegt im Produktkatalog der Artikel "Hosenträger Vintage Leder Schwarz" mit exakt der gewünschten Variante. Der Kunde geht. Die Conversion ist verloren.

Im nächsten Test sucht ein Service-Mitarbeiter nach "Schlüsselanhänger" und bekommt 23 Treffer. Eine Auszubildende, die das Wort phonetisch eintippt ("Schluesselanhaenger" ohne Umlaute), bekommt fünf Treffer und kein Wort von der Suchmaschine, dass es eine bessere Schreibweise gäbe. Drittes Beispiel: Ein Profi-Einkäufer tippt "Akkuschrauber" und findet 156 Produkte. Ein DIY-Kunde tippt "Akku Schrauber" und findet zwölf, weil im Index nur das Compound liegt, nicht die getrennte Variante.

Diese drei Fälle haben einen gemeinsamen Ursprung. Sie liegen weder am Produktkatalog noch am Frontend noch an der Indexierungsfrequenz. Sie liegen daran, dass die Shop-Suche auf Feldebene keine Fehlertoleranz konfiguriert hat. Genauer gesagt: an der Frage, ob Ihre Suchengine Schreibweisen normalisiert, Tippfehler korrigiert und phonetische Ähnlichkeit berechnet, bevor sie nach einem Token-Match sucht. Wer im deutschen E-Commerce mit Standard-Defaults arbeitet, lässt jede Woche Conversion liegen. Wir zeigen in diesem Artikel, woran das technisch liegt und welche Stellschrauben wirklich helfen.

Was Fehlertoleranz auf Feldebene tatsächlich bedeutet

Fehlertoleranz auf Feldebene beschreibt die Fähigkeit einer Shop-Suche, einzelne Felder im Produktindex (Titel, Beschreibung, Marke, Artikelnummer) mit unterschiedlich strengen Match-Regeln zu durchsuchen. Statt jede Suchanfrage stur gegen alle Felder mit identischer Logik zu vergleichen, prüft eine fehlertolerante Suche pro Feld, wie viel Abweichung zwischen Suchstring und indexiertem String erlaubt ist und welche Normalisierungen vorab angewendet werden.

In der Praxis kombiniert Fehlertoleranz drei Konzepte. Erstens: Tippfehler-Korrektur über die Edit-Distance (Damerau-Levenshtein), die misst, wie viele Zeichen verändert, eingefügt, gelöscht oder vertauscht werden müssen, um von Suchstring zu Treffer zu kommen. Zweitens: Normalisierung der Schreibweise (Lowercase, ASCII-Folding für Umlaute, Whitespace-Normalisierung, Compound-Splitting). Drittens: Phonetische Ähnlichkeit über Algorithmen wie die Kölner Phonetik, die für die deutsche Sprache spezifisch entwickelt wurde.

Der Begriff "Field-Level" ist dabei wichtig, weil die strikteste Tippfehler-Toleranz in einem Beschreibungstext anders aussieht als auf der Artikelnummer. Wer "BSH-2024-X1" sucht, will exakt diese SKU. Eine Edit-Distance von 2 darf hier nicht zu falschen Treffern führen. Wer hingegen "Edelstahlspülmaschine" sucht und versehentlich "Edelstahlspülmschine" tippt, erwartet trotzdem den richtigen Treffer.

Das ist der erste fundamentale Unterschied zwischen Standard-Konfigurationen und durchdachten Suchsystemen: die Fehlertoleranz muss pro Feld konfigurierbar sein, nicht pauschal für den ganzen Index. Wer diesen Hebel nicht hat, muss zwischen "zu viele falsche Treffer" und "zu viele Null-Treffer" entscheiden. Beides kostet Conversion.

Vier Failure-Modes, die in deutschen Shops täglich auftauchen

Die folgenden vier Konstellationen tauchen in fast jedem Audit auf, das wir bei BatteryIncluded für Mid-Enterprise-Shops im DACH-Raum durchführen. Sie sind keine Eckfälle, sie sind die operative Realität.

Fall 1: Compound-Nouns mit und ohne Leerzeichen

Das Deutsche bildet Hauptwörter durch Zusammensetzung. Was im Duden ein einziges Wort ist, wird in der Praxis oft getrennt oder mit Bindestrich getippt. "Hosenträger", "Hosen-Träger", "Hosen Träger". Alle drei Schreibweisen sind sprachlich plausibel, im Produktkatalog liegt aber meist nur eine Variante.

Eine Standard-Tokenisierung speichert "Hosenträger" als ein einziges Token im Index. Eine Suche nach "Hosen Träger" wird vom Analyzer in zwei Tokens zerlegt: "hosen" und "träger". Beide werden gegen den Index abgeglichen, finden aber keinen exakten Match, weil im Index das Compound-Token "hosenträger" liegt. Null Treffer. Wer im Backend zusätzlich einen hyphenation_decompounder Token Filter konfiguriert hat, löst einen Teil dieser Fälle. Aber Decompounder brauchen Wörterbücher, und Wörterbücher kennen weder neue Brand-Begriffe noch alle Mode-Trends noch alle Industrieproduktnamen.

Die Bandbreite dieses Problems zeigt sich an Beispielen wie "Akkuschrauber", "Edelstahlspülmaschine", "Wandhalterung", "Küchenarbeitsplatte" oder "Babyschale". Jeder dieser Begriffe wird in deutschen Suchanfragen mal zusammengeschrieben, mal getrennt, mal mit Bindestrich getippt. Eine Suche ohne Fehlertoleranz auf Schreibweisen verschenkt jeden vierten dieser Treffer.

Fall 2: Fehlende oder falsche Umlaute

Der zweite Klassiker betrifft ä, ö, ü, ß. Drei Konstellationen wiederholen sich. Erstens: ein Kunde tippt "Schluessel" statt "Schlüssel", weil seine Tastatur keine Umlaute hat oder er das Wort schnell tippt. Zweitens: ein Kunde tippt "Strasse" statt "Straße" in einem österreichischen oder schweizerischen Kontext, wo die ß-Schreibung weniger üblich ist. Drittens: Produktdaten aus internationalen ERP-Systemen kommen mit "ue", "ae", "oe" anstelle der Umlaute in den Shop-Index.

Eine Suche ohne ASCII-Folding Token Filter behandelt "Schlüssel" und "Schluessel" als zwei komplett verschiedene Strings. Im Index liegt eine Variante, der Kunde tippt die andere, null Treffer. Die saubere Lösung ist ein asciifolding Token Filter, der bei Indexierung und Anfrage gleichermaßen das ü zu u, das ä zu a und das ö zu o normalisiert. Zusätzlich braucht es ein deutsches Mapping, das ß zu ss und ue zu ü übersetzt (rückrichtig), damit beide Schreibweisen auf den gleichen normalisierten String zeigen.

Wer das nicht konfiguriert, sieht den Effekt direkt in Google Analytics: die internen Such-Reports zeigen für umlautlose Varianten ("Schluessel", "Akkuschrauber Ladegeraet") deutlich schlechtere Conversion-Raten als für die korrekt geschriebenen Anfragen. Das ist kein Zufall, das ist die Field-Level-Toleranz, die hier fehlt.

Fall 3: Brand-Misspellings und tippfehlerhafte Markennamen

Der dritte Failure-Mode betrifft Markennamen. "Birkenstock", "Bosch", "Vorwerk", "Miele". Diese Brand-Namen werden in Suchanfragen häufig mit Tippfehlern eingegeben: "Birkenstok", "Boch", "Vorwek", "Mielee". Eine Suche ohne Tippfehler-Toleranz auf dem Brand-Feld findet keine Treffer, weil keine exakte Übereinstimmung existiert.

Genau hier kommt die Edit-Distance ins Spiel. Eine Damerau-Levenshtein-Distanz von 1 bedeutet, dass ein einziger Buchstabenfehler (Vertauschung, Einfügung, Löschung) toleriert wird. Bei einer Distanz von 2 sind zwei Fehler erlaubt. Klingt unproblematisch, ist es aber nicht: auf dem Brand-Feld führt eine Distanz von 2 schnell zu falschen Treffern, weil viele Markennamen ähnlich sind. "Vorwerk" und "Vorlerk" haben Distanz 1, das ist plausibel. "Bosch" und "Bisch" haben ebenfalls Distanz 1, hier wäre die Toleranz fehl am Platz.

Die saubere Konfiguration unterscheidet zwischen kurzen Strings (≤ 4 Zeichen: keine Toleranz oder maximal Distanz 1) und längeren Strings (> 4 Zeichen: Distanz 1, > 8 Zeichen: Distanz 2). Elasticsearch nennt das prefix length und max edits beim fuzzy Query. Wer diese Parameter pauschal über den ganzen Index spannt, produziert entweder zu strenge oder zu lockere Treffer. Die Field-Level-Konfiguration ist die einzige saubere Antwort.

Fall 4: Plural-Singular und Adjektiv-Endungen

Das Deutsche kennt anders als das Englische ein reicheres Flexionssystem. "Schuh" und "Schuhe", "Rote Hose" und "Rotes Kleid" und "Roter Pullover". Eine Standard-Suche behandelt die Endungen wörtlich, ein Stemmer schneidet sie ab. Beide Ansätze produzieren Edge Cases.

Ein deutscher Stemmer, etwa der german_light_stemmer oder der aggressivere german_minimal_stemmer, reduziert "Schuhe" zu "schuh", "Roter" zu "rot" und "Pullover" zu "pullov" (was nicht mehr lesbar ist). Das hilft beim Match zwischen Suchanfrage und Index. Es führt aber auch zu falschen Treffern, etwa wenn "Garten" und "Gärtner" auf den gleichen Stamm reduziert werden, oder wenn "Lampe" und "Lampen" zu "lamp" werden und damit auch englische "lamp"-Tokens gefunden werden.

Der Hebel auf Feldebene: Stemming auf dem Beschreibungsfeld einschalten, auf dem Brand-Feld nicht. Auf dem Titel mit deutscher Light-Stemming arbeiten, weil der Titel kompakt sein muss. Auf der Kategorie keine Stemming-Toleranz, weil Kategorien klar abgegrenzt sein sollen. Diese Differenzierung ist nicht trivial im Setup, sie zahlt sich aber unmittelbar in der Treffergenauigkeit aus.

So fasst eine Kundin den praktischen Effekt zusammen:

"Ich bin äußerst zufrieden mit der Integration der Suchfunktion von BatteryIncluded GmbH. Seitdem wir diese Lösung nutzen, hat sich die Nutzererfahrung auf unserer Website deutlich verbessert. Unsere Kunden finden jetzt noch schneller und einfacher die gewünschten Produkte, was zu einer höheren Zufriedenheit und mehr Verkäufen führt. Die Suche ist präzise, zuverlässig und intuitiv, genau das, was wir für einen erfolgreichen Online-Shop brauchen."

Silkes Weinkeller GmbH (Hubert Burda Media)

Damerau-Levenshtein-Distanz: Was die Edit-Distance wirklich kann

Wer technisch tiefer einsteigt, landet zwangsläufig bei der Edit-Distance. Die Levenshtein-Distanz misst, wie viele Einzelzeichen-Operationen nötig sind, um einen String in einen anderen zu verwandeln. Drei Operationen sind erlaubt: Einfügen, Löschen, Ersetzen. Die Distanz zwischen "Schuh" und "Schuhe" ist 1 (ein Einfügen), zwischen "Bosch" und "Posch" ebenfalls 1 (ein Ersetzen), zwischen "Birkenstock" und "Birkenstrock" ebenfalls 1 (ein Einfügen).

Die Damerau-Levenshtein-Distanz erweitert das Konzept um eine vierte Operation: das Vertauschen zweier benachbarter Zeichen. "Brikenstock" und "Birkenstock" haben damit Distanz 1, nicht 2 wie bei reiner Levenshtein. Das ist relevant, weil Tippfehler in der Praxis sehr oft auf Buchstaben-Vertauschungen zurückgehen ("teh" statt "the", "Bikren" statt "Birken"). Wer Damerau-Levenshtein nicht aktiviert, verschenkt die häufigste Tippfehler-Klasse.

Im praktischen Setup steuern zwei Parameter die Toleranz. max_edits definiert die maximale Distanz. Bei Strings unter fünf Zeichen ist 1 plausibel, ab fünf Zeichen 1 oder 2, ab zwölf Zeichen kann auch 3 sinnvoll sein. prefix_length definiert, wie viele Anfangsbuchstaben exakt übereinstimmen müssen, bevor die Toleranz greift. Ein prefix_length von 2 sorgt dafür, dass "Bohrer" und "Bohrset" nicht denselben Match-Score bekommen wie "Bohrer" und "Bahrer".

Die Edit-Distance hat aber zwei strukturelle Grenzen, die in der Praxis oft übersehen werden.

Erstens: die Edit-Distance kennt keine semantische Bedeutung. "Schale" und "Schaden" haben Distanz 2, sind aber semantisch komplett unterschiedlich. Wer ohne semantische Schicht arbeitet, bekommt zwar tippfehlertolerante Treffer, aber auch falsche Vorschläge bei homophonen oder nahe gespellten Begriffen.

Zweitens: die Edit-Distance ist rechenintensiv bei langen Strings. Eine fuzzy query in Elasticsearch über einen 25-Zeichen-Brand-Namen mit Distanz 2 kann pro Anfrage mehrere Millisekunden zusätzlich kosten. Bei einer Suchanfrage mit Autocomplete-Latenz unter 50 Millisekunden ist das spürbar. Die Lösung ist ein zweistufiges Setup: schnelle exakte Suche zuerst, fuzzy als Fallback bei Null-Treffern. Genau diese Architektur haben wir in unserem Beitrag zu Tokenseparatoren in der Shop-Suche als notwendige Voraussetzung beschrieben.

Phonetische Algorithmen: Warum die Kölner Phonetik im Deutschen funktioniert

Die Edit-Distance reicht für viele Fälle, aber nicht für alle. Wer "Maier" und "Meier" und "Mayer" und "Mayr" als denselben Brand-Begriff erkennen will, kommt mit Distanz allein nicht weit. Hier helfen phonetische Algorithmen.

Der bekannteste Vertreter ist Soundex, ursprünglich für englische Nachnamen in US-Volkszählungen entwickelt. Soundex reduziert Wörter auf einen vierstelligen Code, indem Vokale und ähnlich klingende Konsonanten gleichgesetzt werden. "Maier" und "Meier" bekommen denselben Code, weil die Vokale ignoriert werden. Im Deutschen funktioniert Soundex aber schlecht, weil es englische Phonetik abbildet.

Die Kölner Phonetik (auch "Kölner Verfahren") wurde 1969 von Hans Joachim Postel speziell für die deutsche Sprache entwickelt. Sie berücksichtigt deutsche Aussprache-Regeln: das "sch" als ein Laut, das "ch" je nach Kontext als k- oder ch-Laut, das "z" als ts-Laut. "Mueller", "Müller" und "Müler" bekommen denselben Code. "Schmidt" und "Schmid" und "Schmit" auch. "Kanze" und "Ganz" werden separat gehalten, weil die Anlaute unterschiedlich sind.

Im Setup eines Shop-Suchindex ist die Kölner Phonetik als zusätzlicher Token Filter implementierbar. Elasticsearch liefert mit dem phonetic analysis plugin mehrere Algorithmen mit, darunter "koelnerphonetik". Der typische Setup-Aufwand: Plugin installieren, Custom Analyzer definieren, parallel zum normalen Text-Feld ein dediziertes phonetisches Feld indexieren, im Query-Layer die Suche gegen beide Felder ausführen und die Treffer-Scores kombinieren.

Der praktische Effekt ist signifikant. In einem Audit für einen Möbel-Shop mit 60.000 SKUs lag die Null-Treffer-Rate für Anfragen mit Markennamen vor der Phonetik-Einführung bei 14 Prozent. Nach Einbau lag sie bei 4 Prozent. Die zusätzlichen Treffer waren in 93 Prozent der Fälle die richtigen Produkte, gemessen an der Click-Through-Rate auf die Suchergebnisse.

Wer mit der Kölner Phonetik arbeitet, sollte aber wissen: sie ist eine Approximation. "Vier" und "Wir" bekommen denselben Code, was bei deutschen Markennamen nicht immer gewünscht ist. Das Tooling muss daher die Phonetik-Treffer mit einem niedrigeren Score versehen als exakte oder edit-distance-nahe Treffer. Die Reihenfolge der Score-Gewichtung ist im Field-Level-Setup explizit zu definieren.

Field-Level vs Index-Level: Warum Brand-Felder strenger matchen müssen

Eine der häufigsten architektonischen Entscheidungen im Shop-Suchindex lautet: eine globale Match-Logik oder differenzierte Logik pro Feld? Wer pauschal arbeitet, kommt schnell ans Limit. Field-Level-Konfiguration ist die einzige skalierbare Antwort.

Hier ist eine Faustregel-Tabelle, die wir in BatteryIncluded-Audits regelmäßig verwenden.

| Feld | Match-Strenge | Begründung |
|---|---|---|
| **Artikelnummer / SKU** | Exakt, keine Toleranz | Eindeutige Identifier, falsche Treffer wären gefährlich |
| **EAN** | Exakt, keine Toleranz | Standardisierter Code, Tippfehler-Toleranz produziert Mismatch |
| **Brand** | Edit-Distance 1, Phonetik aktiv | Kunden schreiben Markennamen oft mit Tippfehlern |
| **Produkttitel** | Edit-Distance 1-2, Synonyme, Compound-Split | Hauptsuchfeld, balancierte Toleranz |
| **Produktbeschreibung** | Edit-Distance 2, Stemming, Synonyme | Tolerant für Long-Tail-Queries |
| **Kategorie** | Exakt + Synonyme | Klar abgegrenzte Taxonomie |
| **Tags / Attribute** | Edit-Distance 1, Synonyme | Sekundärer Match-Boost |

Diese Differenzierung ist im Standard-Setup vieler Shop-Suchen nicht direkt sichtbar. Sie verbirgt sich hinter einem global konfigurierten Analyzer, der für alle Felder dieselben Token Filter durchläuft. Wer in den Index-Mapping-Daten genauer hinschaut, findet meist genau drei Varianten: ein "standard"-Field für die meisten Texte, ein "keyword"-Field für exakte Matches, und vielleicht ein "search_as_you_type"-Field für Autocomplete. Das reicht für einen Blog-Suchindex. Im E-Commerce reicht es nicht.

Die saubere Implementation in Elasticsearch nutzt sogenannte Multi-Fields. Ein Produktname wird parallel in mehreren Varianten indexiert: einmal als "standard" (tokenisiert), einmal als "phonetic" (über Kölner Phonetik), einmal als "raw" (Keyword, exakt). Der Query-Layer entscheidet pro Anfrage, welche Felder mit welcher Gewichtung berücksichtigt werden. Ein konkretes Beispiel: eine Suche nach "Bosch" matched primär auf "brand.raw" (exakt), sekundär auf "brand.phonetic" (für Tippfehler) und tertiär auf "title.standard" (für "Bosch Akkuschrauber" im Titel).

Wer diese Differenzierung nicht hat, muss zwischen zwei Welten wählen: zu streng (Conversion-Verlust durch Null-Treffer) oder zu locker (Conversion-Verlust durch irrelevante Treffer). Beide Welten sind teuer. Eine differenzierte Field-Level-Logik ist nicht optional, sie ist die operative Grundlage einer funktionierenden Shop-Suche.

Die zwei Tradeoffs: zu locker tötet Conversion, zu streng erzeugt Null-Treffer

Jede Fehlertoleranz-Entscheidung balanciert zwei Risiken. Ein zu lockeres Setup produziert falsche Treffer: ein Kunde sucht "Bosch Akkuschrauber" und bekommt 47 Treffer, davon 12 von anderen Marken, weil die Edit-Distance auf dem Brand-Feld zu hoch gesetzt ist. Der Kunde ist verwirrt, springt ab, kommt nicht wieder. Ein zu strenges Setup produziert Null-Treffer: ein Kunde sucht "Akku Schrauber" und bekommt keine Ergebnisse, weil das Compound nicht aufgelöst wird. Auch hier: Sprungseite, Abbruch.

Wir haben in BatteryIncluded-Audits ein einfaches Reporting eingeführt, das diese beiden Risiken sichtbar macht. Es trägt den Namen Match-Quality-Quotient (MQQ). Er berechnet sich aus drei Werten: dem Anteil Null-Treffer-Anfragen, dem Anteil Anfragen mit weniger als 5 Treffern und dem Anteil Anfragen mit mehr als 200 Treffern. Ein gesunder MQQ liegt bei unter 2 Prozent Null-Treffer und unter 5 Prozent Über-Treffer. Wer in einem dieser Korridore deutlich ausreißt, hat ein Konfigurationsproblem.

Die häufigsten Fallen in der Praxis:

Falle 1: Globale fuzziness auf "AUTO" stellen und hoffen. Elasticsearch erlaubt eine pauschale fuzziness-Einstellung pro Query, die je nach Token-Länge automatisch die Edit-Distance wählt. Klingt elegant, ist aber für E-Commerce zu grob. Brand-Felder brauchen striktere Werte, Beschreibungsfelder tolerantere. Eine pauschale AUTO-Einstellung führt entweder zu zu vielen falschen Treffern (häufiger) oder zu strengen Matches in falschen Feldern.

Falle 2: Stemming und Phonetik gleichzeitig auf alle Felder. Wer beide Filter aktiviert, ohne pro Feld zu differenzieren, bekommt Score-Inflation. Plötzlich matched jede Anfrage auf jedes Feld, die Treffermenge explodiert, das Ranking wird schwammig. Die saubere Lösung: Stemming auf Beschreibungsfelder, Phonetik auf Brand- und Personenfelder.

Falle 3: Synonym-Listen ohne Pflege. Synonyme sind ein mächtiges Toleranz-Werkzeug. "Geschirrspüler" und "Spülmaschine" als Synonym mappen löst viele Fälle. Aber Synonym-Listen veralten. Wer einmal eine 200-Begriffe-Liste eingespielt hat und ein Jahr nicht pflegt, wundert sich, warum neue Trend-Begriffe nicht erkannt werden. Detaillierte Empfehlungen zur Synonym-Pflege finden Sie in unserem Beitrag zu Keine Suchergebnisse vermeiden.

Falle 4: Did-you-mean ohne Stütze. Wer eine "Meinten Sie..."-Vorschlagsleiste über der Trefferliste anzeigt, ohne dass die zugrundeliegende Logik auf Edit-Distance, Phonetik und N-Gram basiert, bekommt entweder banale Vorschläge oder keine. Das Feature fühlt sich kaputt an, obwohl im Backend nur die Datengrundlage fehlt.

Die Architektur-Frage hinter all diesen Fallen lautet: bauen wir die Fehlertoleranz schrittweise selbst, oder kaufen wir eine Lösung, die diese Schichten bereits sauber kombiniert? Eine tiefere Betrachtung der Gesamtkosten finden Sie im Beitrag zu SaaS-Suche vs. Open Source.

So beschreibt ein Solit-Group-Verantwortlicher den operativen Effekt eines reifen Setups:

"Ein hervorragender Dienstleister mit einem wirklich starken Tool. Besonders überzeugt hat uns die leistungsstarke Suchfunktion, mit der sich Synonyme, Kampagnen und viele weitere Optionen flexibel einstellen lassen. So fühlt man sich als Kunde bestens betreut."

Solit Group AG

Wie Hybrid LLM Search Fehlertoleranz strukturell löst

Volt Search® von BatteryIncluded geht das Problem aus einer anderen Richtung an. Statt jeden Feldtyp einzeln über Edit-Distance, Phonetik und Synonym-Listen zu härten, kombiniert die Hybrid LLM Search drei Schichten in einer entkoppelten Infrastruktur:

1. Klassisches Token-Matching für exakte Treffer auf Artikelnummern, EANs und SKUs. Diese Schicht arbeitet wie ein gewohnter Suchindex und sorgt für millisekundenschnelle Antwortzeiten bei eindeutigen Anfragen.
2. Vektorsuche über Embeddings, die die semantische Nähe zwischen Suchanfrage und Produktbeschreibung berechnet. "Hosen Träger" und "Hosenträger" liegen im Embedding-Raum so nahe beieinander, dass die Trefferliste praktisch identisch ist. Tippfehler, fehlende Umlaute und Compound-Varianten werden hier strukturell aufgelöst, ohne dass eine Wörterbuch-Pflege nötig ist.
3. LLM-basierte Intent-Verarbeitung, die Anfragen wie "weiße Bluse für Sommerhochzeit" in konkrete Produktkategorien übersetzt. Das AI Data Discovery Framework stellt sicher, dass auch bei vager Eingabe relevante Produkte auftauchen, statt eine leere Trefferliste zu zeigen. Mehr Hintergrund zum Mechanismus liefert unser Beitrag Was ist semantische Suche.

Der fundamentale Unterschied zur klassischen Field-Level-Konfiguration: ein Token-basierter Index muss vorab wissen, welche Varianten existieren könnten. Bei jeder neuen Brand, jeder neuen Produktkategorie, jedem neuen Compound müssen Synonym-Listen erweitert, Decompounder-Wörterbücher aktualisiert und Phonetik-Felder neu indexiert werden. Die Vektorsuche braucht das nicht. Sie versteht semantische Nähe, unabhängig von der konkreten Schreibweise. Das Semantische Verständnis ist der eigentliche Hebel, nicht die Anzahl der Synonym-Einträge.

Ein konkretes Zahlenbeispiel aus einem Kundenprojekt. Ein Sortiment mit 42.000 SKUs hatte unter einer klassischen Elasticsearch-Konfiguration mit ausgereifter Field-Level-Toleranz und gepflegten Synonym-Listen eine Null-Treffer-Rate von 7 Prozent. Nach Umstellung auf Volt Search® lag die Rate bei 0,6 Prozent. Die verbleibenden 0,6 Prozent waren echte Anfragen außerhalb des Sortiments. Das AI Data Discovery Framework lieferte selbst bei diesen Fällen relevante Alternativen, statt eine leere Seite.

Ein weiterer struktureller Vorteil betrifft den Betrieb. Sie müssen keine Phonetik-Plugins mehr installieren, keine Decompound-Wörterbücher pflegen, keine fuzziness-Parameter pro Feld dokumentieren. Volt Search® läuft als entkoppelte Infrastruktur, die per API an Shopware, Magento, Custom-Frontends oder Headless-Setups angebunden wird. Suchanfragen kommen rein, semantisch relevante Treffer kommen raus, DSGVO-konform, cookieless, gehostet in Deutschland.

Wer einen breiteren Anbieter-Vergleich sucht, findet ihn im Beitrag zu E-Commerce Suchmaschinen im Vergleich. Wer konkret über einen Wechsel weg vom Eigenbetrieb nachdenkt, findet praktische Hinweise im Leitfaden zu Elasticsearch-Alternativen für E-Commerce.

Auch die Conversion-Effekte sind in Kundenprojekten dokumentiert:

"Seit wir BatteryIncluded einsetzen, sehen wir spürbare Verbesserungen: bereits nach zwei Monaten stieg unsere Conversion Rate um 10 Prozent, und nach vier Monaten konnten wir einen Zuwachs von 19 Prozent verzeichnen."

B&W Handelsgesellschaft mbH

Diese Werte sind kein Marketing-Versprechen. Sie sind die direkte Folge einer Architektur, die Fehlertoleranz nicht als nachträglich gepatchtes Feature behandelt, sondern als integralen Teil des Match-Prozesses.

Was Sie tun können, bevor Sie die Architektur wechseln

Nicht jeder Shop braucht sofort eine Hybrid LLM Search. Wenn Sie aktuell mit einem Standard-Suchindex arbeiten und die Fehlertoleranz auf Feldebene verbessern wollen, lohnt sich diese Reihenfolge.

Schritt 1: Null-Treffer-Logging einschalten. Aktivieren Sie ein systematisches Logging aller Such-Anfragen, die zu null Treffern führen. Werten Sie die Liste wöchentlich aus. Sie werden Muster sehen: Tippfehler-Cluster, Umlaut-Ausfälle, Compound-Varianten, vergessene Markennamen.

Schritt 2: ASCII-Folding und Whitespace-Normalisierung einbauen. Das ist die niedrigste hängende Frucht. Ein asciifolding Token Filter und ein deutsches Umlaut-Mapping (ue zu ü, ae zu ä, oe zu ö, ss zu ß) bereinigen die Hälfte der Schreibweisen-Edge-Cases.

Schritt 3: Edit-Distance auf Brand-Feldern aktivieren. Konfigurieren Sie eine fuzzy Query mit max_edits=1 und prefix_length=2 für das Brand-Feld. Testen Sie A/B vor und nach der Aktivierung mit den Top-100-Brand-Anfragen.

Schritt 4: Kölner Phonetik als Multi-Field einbauen. Installieren Sie das Phonetic-Analysis-Plugin, definieren Sie einen koelnerphonetik-Analyzer und indexieren Sie Brand und Titel parallel als phonetisches Feld. Achten Sie auf niedrigere Score-Gewichtung gegen exakte Treffer.

Schritt 5: Compound-Decompounder testen. Wenn Compound-Varianten ein dominantes Pattern sind, testen Sie den hyphenation_decompounder Token Filter mit einer bewährten Hyphenation Pattern Datei (z.B. der OpenOffice German Hyphenation). Messen Sie A/B vor und nach Einbau.

Schritt 6: MQQ-Reporting etablieren. Berechnen Sie wöchentlich den Match-Quality-Quotient. Wenn Null-Treffer über 5 Prozent oder Über-Treffer über 15 Prozent liegen, ist ein strukturelles Problem da, das einzelne Filter nicht mehr lösen.

Schritt 7: TCO ehrlich rechnen. Wenn die Pflege der Fehlertoleranz-Schichten mehr als 3 Personentage pro Monat verschlingt und die Null-Treffer-Rate trotzdem über 5 Prozent liegt, ist es Zeit für einen strukturellen Architekturvergleich. Einen praktischen Pfad zur Einordnung finden Sie im Beitrag zu Shopware Suche optimieren.

Diese sieben Schritte können Sie auch dann gehen, wenn Sie später auf eine Hybrid LLM Search wechseln. Die Erkenntnisse aus Null-Treffer-Logging und Edge-Case-Analyse helfen bei jeder Migration.

Häufige Fragen (FAQ)

Was bedeutet Fehlertoleranz in einer Shop-Suche?

Fehlertoleranz beschreibt die Fähigkeit einer Suchengine, auch dann passende Treffer zu liefern, wenn die Suchanfrage von der indexierten Schreibweise abweicht. Das umfasst Tippfehler ("Birkenstok" statt "Birkenstock"), fehlende Umlaute ("Schluessel" statt "Schlüssel"), Compound-Varianten ("Hosen Träger" statt "Hosenträger") und phonetisch ähnliche Schreibweisen ("Mueller" und "Müller"). Auf Feldebene bedeutet das, dass jedes Index-Feld (Brand, Titel, Beschreibung, Artikelnummer) mit unterschiedlich strengen Match-Regeln durchsucht werden kann. Eine Artikelnummer braucht Null Toleranz, ein Beschreibungsfeld kann großzügiger sein.

Was ist eine Fuzzy-Suche?

Eine Fuzzy-Suche (von engl. fuzzy, "unscharf") ist eine Suchtechnik, die nicht nur exakte Treffer liefert, sondern auch ähnliche Strings akzeptiert. Die Ähnlichkeit wird typischerweise über die Edit-Distance (Levenshtein oder Damerau-Levenshtein) berechnet, die misst, wie viele Zeichenänderungen nötig sind, um vom Suchstring zum Indexstring zu kommen. Im E-Commerce wird Fuzzy-Suche eingesetzt, um Tippfehler zu kompensieren, ohne dass der Kunde merkt, dass die Suchanfrage nicht exakt im Index liegt. Ein gutes Setup verwendet Fuzzy als zweite Stufe nach einer schnellen exakten Suche, um Latenz und Treffer-Qualität auszubalancieren.

Wie funktioniert die Damerau-Levenshtein-Distanz?

Die Damerau-Levenshtein-Distanz zählt vier Arten von Operationen: Einfügen, Löschen, Ersetzen und Vertauschen zweier benachbarter Zeichen. Sie liefert eine Zahl, die angibt, wie viele dieser Operationen mindestens nötig sind, um einen String in einen anderen zu verwandeln. "Bosch" und "Bsoch" haben Damerau-Levenshtein-Distanz 1 (eine Vertauschung), reine Levenshtein-Distanz hingegen 2. Im Shop-Suchindex steuern Sie typischerweise zwei Parameter: max_edits (maximale erlaubte Distanz) und prefix_length (wie viele Anfangsbuchstaben exakt stimmen müssen, bevor die Toleranz greift). Damerau-Levenshtein ist im E-Commerce die bessere Wahl als reine Levenshtein, weil Buchstaben-Vertauschungen der häufigste Tippfehler-Typ sind.

Warum bekomme ich bei "Hosenträger" andere Ergebnisse als bei "Hosen Träger"?

Das liegt an der Tokenisierung. Ein Standard-Tokenizer speichert "Hosenträger" als ein einziges Token im Index. Eine Suche nach "Hosen Träger" wird in zwei Tokens zerlegt: "hosen" und "träger". Beide finden keinen exakten Match, weil im Index nur das Compound-Token liegt. Die saubere Lösung kombiniert drei Ansätze: einen Compound-Decompounder, der "Hosenträger" während der Indexierung in seine Bestandteile zerlegt, eine fuzzy query auf dem Compound-Feld und im Idealfall eine semantische Vektorsuche, die "Hosen Träger" und "Hosenträger" unabhängig von der Schreibweise als denselben Begriff erkennt.

Was ist die Kölner Phonetik und wo wird sie eingesetzt?

Die Kölner Phonetik ist ein 1969 entwickelter phonetischer Algorithmus, der Wörter auf einen sprechbaren Code reduziert. Sie wurde speziell für die deutsche Sprache entwickelt, anders als Soundex, das auf englische Aussprache optimiert ist. Im Shop-Suchindex wird die Kölner Phonetik als zusätzlicher Token Filter eingesetzt, um ähnlich klingende Schreibweisen ("Maier", "Meier", "Mayer", "Mayr") demselben Code zuzuordnen. Sie eignet sich besonders für Brand-Felder und Personennamen-Suchen. Die Implementierung in Elasticsearch erfolgt über das phonetic-analysis-Plugin mit dem Algorithmus "koelnerphonetik".

Warum findet meine Shopware-Suche Tippfehler nicht?

Shopware liefert in der Standardkonfiguration eine simple Tokenisierung ohne Edit-Distance, ohne Phonetik und ohne Compound-Decompounder. Die Suche arbeitet primär auf exaktem Token-Match. Wer Fehlertoleranz nachrüsten will, muss in das zugrundeliegende Such-Backend (typischerweise Elasticsearch oder OpenSearch) eingreifen und einen Custom Analyzer mit den entsprechenden Filtern definieren. Das ist möglich, erfordert aber DevOps-Erfahrung und kontinuierliche Pflege. Eine kompaktere Übersicht der Stellschrauben finden Sie im Beitrag zu Shopware Suche funktioniert nicht.

Wie hoch sollte die Edit-Distance bei Markennamen sein?

Faustregel: bei Brand-Strings unter 4 Zeichen keine fuzzy-Toleranz (Distanz 0). Bei 4 bis 7 Zeichen Distanz 1. Bei 8 oder mehr Zeichen Distanz 2. Zusätzlich sollte die prefix_length bei mindestens 2 liegen, damit Anfangsbuchstaben exakt übereinstimmen müssen. Wer pauschal Distanz 2 auf alle Brand-Felder spannt, riskiert falsche Treffer ("Bosch" vs "Bisch") und damit unbrauchbare Suchergebnisse. Die saubere Lösung ist eine field-spezifische fuzziness-Konfiguration und idealerweise eine Kölner-Phonetik-Schicht für phonetische Match-Fälle, die die Edit-Distance allein nicht abdeckt.

Bereit für eine Suche, die Tippfehler und Compounds versteht?

Field-Level-Fehlertoleranz ist eine Disziplin für sich. Wer sie richtig konfiguriert, gewinnt einige Prozentpunkte Conversion. Wer sie jahrelang pflegt, baut sich einen kontinuierlich wachsenden Wartungs-Backlog aus Synonymen, Wörterbüchern und phonetischen Mappings. Volt Search® von BatteryIncluded löst das Problem auf der Architekturebene: Hybrid LLM Search kombiniert klassisches Token-Matching, Vektorsuche und Intent-Verarbeitung in einer entkoppelten Infrastruktur. Finden statt Suchen, cookieless, DSGVO-konforme KI, Made in Germany, ohne dass Sie selbst phonetische Plugins betreiben oder Compound-Wörterbücher pflegen müssen.

Zu Ihrer kostenlosen Demo und erleben Sie live an Ihren eigenen Produktdaten, wie Volt Search® "Hosenträger" und "Hosen Träger", "Schlüssel" und "Schluessel", "Bosch" und "Bsoch" zuverlässig auf dieselbe Trefferliste führt. Ohne fuzziness-Tuning, ohne Tracking, ohne lange Setup-Phase.