Synonyme und Stemming in Elasticsearch sauber konfigurieren

1. Warum Synonyme und Stemming über Trefferqualität entscheiden

Eine Volltextsuche, die nur exakte Wortformen abgleicht, scheitert an der Alltagssprache der Nutzer. Wer "Handy" eingibt, meint oft dasselbe wie jemand, der "Smartphone" tippt. Wer "laufen" sucht, erwartet Treffer, die "läuft", "lief" oder "gelaufen" enthalten. Genau hier setzen zwei unterschiedliche, aber komplementäre Mechanismen an: Synonyme verknüpfen Begriffe mit derselben Bedeutung, während Stemming Wortformen auf ihren gemeinsamen Wortstamm reduziert. Beide Mechanismen arbeiten im Analyzer, also in der Kette aus Tokenizer und Token-Filtern, die Text beim Indexieren und beim Suchen in vergleichbare Tokens zerlegt.

Der Effekt einer sauberen Konfiguration von Synonymen und Stemming ist messbar: Recall steigt, weil mehr relevante Dokumente gefunden werden, ohne dass Precision zwangsläufig leidet, sofern die Regeln präzise genug sind. Wird Stemming zu aggressiv eingesetzt oder werden Synonyme zu großzügig definiert, kippt der Effekt jedoch ins Gegenteil: Die Suche wird unscharf, liefert irrelevante Treffer und Nutzer verlieren Vertrauen in die Relevanz der Ergebnisse. Die folgenden Abschnitte zeigen, wie synonym Token Filter, synonym_graph und die richtige Stemmer-Wahl so konfiguriert werden, dass Synonyme und Stemming die Suchqualität verbessern, statt sie zu verwässern.

Ein wichtiger Grundsatz vorab: Synonyme und Stemming sind kein Ersatz für eine gute Relevanzstrategie, sondern eine Ergänzung. Wer beide Mechanismen isoliert betrachtet, ohne Analyzer-Reihenfolge, Sprache und Domänenvokabular zu berücksichtigen, produziert häufig Konfigurationen, die in Tests gut aussehen, aber in Produktion überraschende Treffer liefern.

2. Der synonym Token Filter: Grundlagen und Syntax

Der synonym Token Filter ersetzt oder ergänzt Tokens im Analyzer anhand einer Regelliste. Jede Regel folgt dem Format begriff1, begriff2 => zielbegriff für eine gerichtete Ersetzung oder begriff1, begriff2, begriff3 für eine ungerichtete Äquivalenzgruppe, bei der jeder Begriff durch alle anderen ersetzt beziehungsweise ergänzt wird. Die Regeln können direkt inline in der Analyzer-Definition stehen oder aus einer externen Datei im Konfigurationsverzeichnis des Clusters geladen werden, was bei umfangreichen Synonymlisten die bessere Wahl ist.

Wichtig ist der Unterschied zwischen expand: true und einer expliziten Ersetzungsregel. Bei einer ungerichteten Gruppe wie laptop, notebook, netbook mit aktivem Expand wird jedes dieser Wörter beim Indexieren durch alle drei Varianten ersetzt, sodass ein Dokument mit "Laptop" auch bei der Suche nach "Notebook" gefunden wird. Bei einer gerichteten Regel wie notebook => laptop wird "Notebook" ausschließlich durch "Laptop" ersetzt, die Rückrichtung funktioniert nicht automatisch. Diese Entscheidung hat direkten Einfluss auf Indexgröße und Suchverhalten und sollte bewusst getroffen werden, nicht als Standardeinstellung übernommen werden.

PUT /produkte
{
  "settings": {
    "analysis": {
      "filter": {
        "produkt_synonyms": {
          "type": "synonym",
          "synonyms": [
            "laptop, notebook, netbook",
            "handy, smartphone, mobiltelefon",
            "kopfhoerer => kopfhoerer, headset"
          ]
        }
      },
      "analyzer": {
        "produkt_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "produkt_synonyms"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "titel": { "type": "text", "analyzer": "produkt_analyzer" }
    }
  }
}

Der synonym Token Filter kann sowohl beim Indexieren als auch bei der Suchanfrage angewendet werden. Die gängige Praxis ist, Synonyme nur beim Indexieren zu expandieren, damit der Index alle Varianten enthält, während die Suchanfrage unverändert bleibt. Das reduziert die Rechenlast pro Query, weil die Expansion nicht bei jeder einzelnen Suche erneut erfolgt, sondern einmalig beim Indexieren stattfindet.

3. synonym_graph vs. synonym: Unterschiede im Detail

Der einfache synonym Filter stößt an Grenzen, sobald Mehrwort-Synonyme im Spiel sind, etwa "new york" als Synonym für "big apple". Weil der Standard-Token-Filter Tokens einzeln verarbeitet, entsteht bei solchen Fällen eine inkorrekte Positionierung im Token-Graph, was bei Phrasen-Queries zu falschen oder fehlenden Treffern führt. Genau für diesen Fall existiert der synonym_graph Filter: Er erzeugt einen korrekten Token-Graph mit Positionsinkrementen, der auch Mehrwort-Synonyme korrekt abbildet.

Die Regel in der Praxis: synonym_graph ist bei allen Analyzern zu verwenden, die zur Indexierungszeit laufen und Mehrwort-Synonyme enthalten könnten, während der einfache synonym Filter für Suchzeit-Analyzer ausreicht, sofern keine Graph-Queries wie match_phrase mit Synonym-Expansion beteiligt sind. Ein häufiger Fehler ist, synonym_graph pauschal überall einzusetzen: Der Filter ist rechenintensiver, und für reine Einwort-Synonyme bringt er keinen Mehrwert gegenüber dem einfachen synonym Filter.

PUT /produkte/_settings
{
  "index": {
    "analysis": {
      "filter": {
        "multiword_synonyms": {
          "type": "synonym_graph",
          "synonyms": [
            "new york, big apple",
            "usb typ c, usb-c, usb typ-c"
          ]
        }
      },
      "analyzer": {
        "index_time_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "multiword_synonyms"]
        }
      }
    }
  }
}

Ein weiterer Unterschied betrifft die Kombination mit Stemming. Wird ein synonym_graph Filter vor einem Stemmer platziert, kann es zu unerwarteten Ergebnissen kommen, weil der Stemmer die bereits expandierten Synonyme erneut verarbeitet und dabei Wortstämme erzeugt, die nicht mehr der ursprünglichen Absicht entsprechen. Die empfohlene Reihenfolge dafür wird im Abschnitt zur Analyzer-Kette im Detail erklärt.

4. Stemmer-Typen im Vergleich: Snowball vs. Light Stemmer

Stemming reduziert Wortformen auf einen gemeinsamen Stamm, damit "laufen", "läuft" und "gelaufen" beim Indexieren denselben Token erzeugen. Elasticsearch bietet dafür mehrere Algorithmen, wobei die zwei wichtigsten Familien der Snowball Stemmer und der Light Stemmer sind. Der Snowball Stemmer, basierend auf dem Porter-Algorithmus und seinen sprachspezifischen Ableitungen, reduziert Wörter aggressiv auf einen minimalen Stamm. Das erhöht den Recall spürbar, kann aber auch unterschiedliche Wörter mit ähnlichem Stamm fälschlich zusammenführen, ein Effekt, der in der Fachliteratur als Overstemming bezeichnet wird.

Der Light Stemmer verfolgt einen konservativeren Ansatz: Er entfernt nur die häufigsten Flexionsendungen wie Plural-s oder einfache Verbendungen, ohne tief in die Wortmorphologie einzugreifen. Das Ergebnis ist weniger aggressives Stemming mit geringerem Risiko für Overstemming, aber auch geringerem Recall bei komplexen Flexionsformen. Für deutsche Texte mit ihrer reichen Morphologie bedeutet das: Ein Snowball Stemmer für Deutsch fasst "Wanderung", "Wanderer" und "wandern" häufig unter demselben Stamm zusammen, was für breite Suchanfragen gewünscht sein kann, bei präzisen Fachbegriffen aber zu unerwünschten Treffern führt.

PUT /artikel
{
  "settings": {
    "analysis": {
      "filter": {
        "german_snowball": {
          "type": "stemmer",
          "language": "light_german"
        },
        "german_snowball_aggressive": {
          "type": "stemmer",
          "language": "german2"
        }
      },
      "analyzer": {
        "de_light": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "german_normalization", "german_snowball"]
        },
        "de_aggressive": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "german_normalization", "german_snowball_aggressive"]
        }
      }
    }
  }
}

In Elasticsearch heißt der leichtere Algorithmus für Deutsch light_german, während german2 die aggressivere Snowball-Variante mit erweiterter Regelbasis darstellt. Für E-Commerce-Suchen mit vielen Produktnamen und Fachbegriffen empfiehlt sich in der Regel light_german, weil Produktbezeichnungen selten stark flektiert werden und ein aggressiver Stemmer hier eher Rauschen erzeugt als Nutzen bringt. Für Volltextsuche in redaktionellen Inhalten mit natürlicher Fließtextsprache liefert der aggressivere Stemmer oft den besseren Recall.

5. Analyzer-Kette: Synonyme und Stemming richtig kombinieren

Die Reihenfolge der Filter in der Analyzer-Kette ist keine Formsache, sondern hat direkten Einfluss auf das Ergebnis. Die etablierte Best Practice lautet: Zuerst Normalisierung wie lowercase und german_normalization, dann der synonym Filter, danach erst der Stemmer. Der Grund: Synonyme werden meist in ihrer Grundform definiert, und wenn der Stemmer vor dem synonym Filter läuft, passt die bereits gestemmte Wortform häufig nicht mehr zur Synonymregel, wodurch die Synonym-Erkennung stillschweigend fehlschlägt.

Ein zweiter, oft übersehener Punkt: Wird Stemming vor dem synonym_graph Filter angewendet, muss die Synonymliste ebenfalls in gestemmter Form vorliegen, was die Pflege der Liste erheblich erschwert und fehleranfällig macht. Die empfohlene Kette lowercase → synonym_graph → stemmer vermeidet dieses Problem, weil Synonyme in ihrer natürlichen Schreibweise gepflegt werden können und der Stemmer erst danach beide Originalwörter und expandierte Synonyme gleichermaßen normalisiert.

PUT /wissensdatenbank
{
  "settings": {
    "analysis": {
      "filter": {
        "fach_synonyms": {
          "type": "synonym_graph",
          "synonyms": ["laptop, notebook", "server, rechenzentrum server"]
        },
        "de_stemmer": {
          "type": "stemmer",
          "language": "light_german"
        }
      },
      "analyzer": {
        "kombi_analyzer": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": [
            "lowercase",
            "german_normalization",
            "fach_synonyms",
            "de_stemmer"
          ]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "inhalt": { "type": "text", "analyzer": "kombi_analyzer" }
    }
  }
}

Ein häufiger Fehler in der Praxis ist, dieselbe Analyzer-Kette für Indexierung und Suche zu verwenden, ohne zu prüfen, ob das gewünschte Verhalten ist. Wird der synonym_graph Filter auch zur Suchzeit angewendet, expandiert jede Suchanfrage erneut, was bei umfangreichen Synonymlisten die Query-Latenz spürbar erhöhen kann. In vielen Fällen ist es performanter, Synonyme nur beim Indexieren zu expandieren und für die Suchanfrage einen separaten search_analyzer ohne Synonym-Filter zu definieren.

6. Mehrsprachigkeit: Stemming-Fallstricke bei Deutsch, Englisch & Co

Mehrsprachige Indizes sind eine der häufigsten Fehlerquellen bei Stemming-Konfigurationen. Wird ein einzelner Analyzer mit deutschem Stemmer auf einen Index angewendet, der auch englische oder französische Inhalte enthält, produziert der Stemmer für fremdsprachige Wörter falsche oder gar keine sinnvollen Stämme, weil die Regelbasis sprachspezifisch ist. Das Ergebnis ist eine Suche, die für eine Sprache gut funktioniert und für alle anderen Sprachen im selben Index spürbar schlechter performt.

Die robuste Lösung ist, pro Sprache ein eigenes Feld mit eigenem Analyzer anzulegen, etwa titel_de mit deutschem Stemmer und titel_en mit englischem Stemmer, und die Suchanfrage abhängig von der erkannten oder eingestellten Nutzersprache auf das passende Feld zu richten. Alternativ lässt sich mit separaten Indizes pro Sprache arbeiten, was bei stark unterschiedlichem Content-Volumen pro Sprache auch Vorteile beim Index-Management und Sharding bringt. Wichtig dabei: Auch Synonymlisten sind sprachspezifisch zu pflegen, ein deutsches Synonympaar wie "Rechner, Computer" hat im Englischen keine direkte Entsprechung und muss separat definiert werden.

PUT /mehrsprachig
{
  "mappings": {
    "properties": {
      "titel": {
        "type": "text",
        "fields": {
          "de": { "type": "text", "analyzer": "de_light" },
          "en": { "type": "text", "analyzer": "english" },
          "fr": { "type": "text", "analyzer": "french" }
        }
      }
    }
  }
}

GET /mehrsprachig/_search
{
  "query": {
    "match": {
      "titel.de": "laufschuhe fuer marathon"
    }
  }
}

Ein weiterer Fallstrick betrifft zusammengesetzte Wörter im Deutschen. "Laufschuh" ist ein einziges Token, während die englische Entsprechung "running shoe" aus zwei Tokens besteht. Ein Stemmer allein löst dieses Problem nicht, hier hilft ein Decompounder wie der hyphenation_decompounder, der zusammengesetzte deutsche Wörter in ihre Bestandteile zerlegt, bevor Stemming und Synonym-Erkennung greifen. Ohne Decompounder findet eine Suche nach "Schuh" kein Dokument, das nur "Laufschuh" enthält, obwohl das inhaltlich naheliegend wäre.

7. Synonyme dynamisch verwalten mit der synonym_set API

Klassisch wurden Synonymlisten in Dateien im Config-Verzeichnis jedes Cluster-Knotens gepflegt, was ein manuelles Kopieren der Datei auf jeden Knoten und einen Reload des Analyzers erforderte. Seit Elasticsearch 8.10 löst die synonym_set API dieses Problem strukturell: Synonyme werden zentral über die API verwaltet und automatisch an alle Knoten verteilt, ohne manuelles Datei-Handling.

Analyzer, die auf einen synonym_set verweisen, unterstützen zudem ein Reload ohne vollständige Index-Neuindexierung: Nach einer Aktualisierung der Synonymliste genügt ein POST /index/_reload_search_analyzers, damit neue Suchanfragen die aktualisierten Regeln nutzen, während bereits indexierte Dokumente unverändert bleiben. Für Anwendungsfälle, in denen sich Synonyme kontinuierlich ändern, etwa durch Feedback aus der Klickstatistik, ist das ein erheblicher operativer Vorteil gegenüber der dateibasierten Verwaltung.

PUT /_synonyms/produkt_synonyms
{
  "synonyms_set": [
    { "id": "syn-1", "synonyms": "laptop, notebook, netbook" },
    { "id": "syn-2", "synonyms": "kopfhoerer => kopfhoerer, headset" }
  ]
}

PUT /produkte/_settings
{
  "index": {
    "analysis": {
      "filter": {
        "produkt_synonyms": {
          "type": "synonym_graph",
          "synonyms_set": "produkt_synonyms",
          "updateable": true
        }
      }
    }
  }
}

POST /produkte/_reload_search_analyzers

8. Testing mit der Analyze API

Ohne systematisches Testen bleibt jede Synonym- und Stemming-Konfiguration Vermutung. Die _analyze API erlaubt, einen beliebigen Text durch einen definierten Analyzer zu schicken und exakt zu sehen, welche Tokens dabei entstehen. Das ist der schnellste Weg, um zu prüfen, ob eine Synonymregel tatsächlich greift und ob der gewählte Stemmer die erwarteten Wortstämme erzeugt, bevor die Konfiguration in Produktion geht.

POST /produkte/_analyze
{
  "analyzer": "produkt_analyzer",
  "text": "Ich suche ein gutes Notebook mit Kopfhoerer"
}

# Response zeigt jedes Token mit Position und Typ
# {
#   "tokens": [
#     { "token": "ich", "start_offset": 0, "end_offset": 3, ... },
#     { "token": "such", "start_offset": 4, "end_offset": 9, ... },
#     { "token": "gut", "start_offset": 15, "end_offset": 21, ... },
#     { "token": "laptop", "start_offset": 22, "end_offset": 30, ... },
#     { "token": "notebook", "start_offset": 22, "end_offset": 30, ... },
#     { "token": "netbook", "start_offset": 22, "end_offset": 30, ... },
#     { "token": "kopfhoerer", ... },
#     { "token": "headset", ... }
#   ]
# }

Ein bewährtes Vorgehen ist, für jede neue Synonymregel und jede Stemmer-Änderung eine kleine Testsuite mit repräsentativen Beispielsätzen aufzubauen und die Analyze API automatisiert gegen diese Suite laufen zu lassen. So werden Regressionen sichtbar, bevor sie in Produktion zu falschen Suchergebnissen führen. Gerade bei Stemming lohnt es sich, gezielt Wortpaare zu testen, die fälschlich zusammengeführt werden könnten, etwa Fachbegriffe mit ähnlichem Wortstamm, aber unterschiedlicher Bedeutung.

9. Performance- und Index-Größen-Auswirkungen

Synonyme und Stemming sind nicht kostenlos. Jede Synonymregel mit Expand-Verhalten erhöht die Anzahl der Tokens pro Dokument, was direkt die Größe des invertierten Index vergrößert. Bei umfangreichen Synonymlisten mit hunderten Einträgen kann sich die Index-Größe spürbar erhöhen, insbesondere wenn viele Begriffe in großen Äquivalenzgruppen zusammengefasst werden. Stemming hingegen reduziert tendenziell die Anzahl eindeutiger Terms im Index, weil mehrere Wortformen auf denselben Stamm abgebildet werden, was sich positiv auf die Index-Größe auswirkt.

Bei der Query-Performance gilt: Wird der synonym_graph Filter zur Suchzeit angewendet, kostet jede Anfrage zusätzliche Rechenzeit für die Expansion. Für hochfrequentierte Suchendpunkte ist es daher ratsam, Synonyme ausschließlich beim Indexieren zu expandieren und den Suchzeit-Analyzer schlank zu halten. Ein Benchmark mit realistischen Suchanfragen vor dem Produktivgang zeigt zuverlässig, ob eine gewählte Kombination aus Synonymen und Stemming die Latenzanforderungen noch erfüllt, besonders bei Autocomplete-Szenarien mit hoher Query-Frequenz.

Die Tabelle zeigt: Es gibt keinen universell richtigen Stemmer, sondern nur die passende Wahl für den jeweiligen Anwendungsfall. Wer unsicher ist, sollte mit dem Light Stemmer beginnen und den Recall anhand echter Suchanfragen und Klickdaten beobachten, bevor auf einen aggressiveren Snowball Stemmer gewechselt wird.

10. Zusammenfassung

Synonyme und Stemming lösen unterschiedliche Probleme, die zusammen die Suchqualität einer Elasticsearch-Suche entscheidend prägen. Der synonym Token Filter verknüpft bedeutungsgleiche Begriffe, wobei synonym_graph für Mehrwort-Synonyme unverzichtbar ist. Stemming reduziert Wortformen auf einen gemeinsamen Stamm, wobei die Wahl zwischen einem aggressiven Snowball Stemmer und einem konservativeren Light Stemmer direkten Einfluss auf Recall und Overstemming-Risiko hat. Die Reihenfolge in der Analyzer-Kette, erst Normalisierung, dann Synonyme, dann Stemming, ist entscheidend, damit beide Mechanismen korrekt zusammenspielen.

Mehrsprachige Indizes brauchen eigene Felder pro Sprache mit jeweils passendem Stemmer und passender Synonymliste, da ein einzelner Analyzer nie für alle Sprachen gleichermaßen funktioniert. Die synonym_set API vereinfacht die operative Pflege von Synonymen erheblich gegenüber dateibasierten Listen. Systematisches Testen mit der Analyze API und ein Blick auf Performance-Auswirkungen runden eine solide Konfiguration von Synonymen und Stemming ab, bevor sie in Produktion geht.

11. FAQ: Synonyme und Stemming konfigurieren