Autocomplete und Suggest-Funktionen in Elasticsearch implementieren

1. Warum Autocomplete kein einfaches Prefix-Match ist

Auf den ersten Blick wirkt Autocomplete wie eine triviale Funktion: Der Nutzer tippt "wander" und die Anwendung soll "Wanderschuhe" vorschlagen. In der Praxis steckt dahinter jedoch eine anspruchsvolle Anforderung an Latenz, Relevanz-Ranking und Fehlertoleranz. Ein naiver wildcard Query mit angehängtem Sternchen funktioniert zwar für kleine Datenmengen, skaliert aber katastrophal, weil Wildcard-Queries auf großen Indizes praktisch jeden Term durchsuchen müssen, statt effizient über eine vorbereitete Datenstruktur zu navigieren.

Elasticsearch bietet für Autocomplete drei grundverschiedene Ansätze, die jeweils eigene Kompromisse zwischen Latenz, Speicherbedarf, Flexibilität und Implementierungsaufwand eingehen: den Completion Suggester mit einer dedizierten In-Memory-Datenstruktur, den Edge N-Gram Ansatz mit vorab generierten Präfix-Tokens im invertierten Index, und den neueren Feldtyp search_as_you_type, der Edge N-Gram-Logik in ein einfacheres Mapping-Konstrukt verpackt. Diese drei Ansätze für Suggest-Funktionen unterscheiden sich fundamental in ihrer internen Arbeitsweise, obwohl sie an der Oberfläche ähnliche Ergebnisse liefern.

Die Wahl des richtigen Ansatzes hängt stark vom Anwendungsfall ab: Braucht die Autocomplete-Funktion Fuzzy-Matching für Tippfehler, muss sie kontextabhängig gefiltert werden können, etwa nach Kategorie oder Sprache, und wie hoch ist das erwartete Suchvolumen? Die folgenden Abschnitte geben eine fundierte Entscheidungsgrundlage für Autocomplete und Suggest in Elasticsearch.

2. Der Completion Suggester: Aufbau und Mapping

Der Completion Suggester ist die für Autocomplete spezialisierteste Lösung in Elasticsearch. Er basiert auf einer speziellen Datenstruktur, einem Finite State Transducer (FST), der vollständig im Speicher gehalten wird und dadurch extrem niedrige Latenzen für Präfix-Abfragen liefert, typischerweise im niedrigen einstelligen Millisekundenbereich. Der Feldtyp im Mapping heißt completion und erfordert eine eigene, dedizierte Struktur mit input-Array und optionalem weight-Feld für Ranking.

Der Completion Suggester wird nicht über die normale query Struktur abgefragt, sondern über den separaten suggest Endpoint, der eine eigene Syntax mit prefix und field nutzt. Dieses separate API-Konzept ist ein wichtiger Unterschied zu den anderen beiden Ansätzen, die als normale Query-Klauseln funktionieren.

PUT /produkte
{
  "mappings": {
    "properties": {
      "titel_suggest": {
        "type": "completion",
        "analyzer": "simple",
        "preserve_separators": true,
        "preserve_position_increments": true,
        "max_input_length": 50
      }
    }
  }
}

PUT /produkte/_doc/1
{
  "titel_suggest": {
    "input": ["Wanderschuhe", "Trekkingschuhe", "Outdoor Schuhe"],
    "weight": 34
  }
}

POST /produkte/_search
{
  "suggest": {
    "titel-suggest": {
      "prefix": "wander",
      "completion": {
        "field": "titel_suggest",
        "size": 5
      }
    }
  }
}

Ein wichtiger Nachteil des Completion Suggester: Die zugrunde liegende FST-Struktur unterstützt ausschließlich Präfix-Matching am Wortanfang des jeweiligen Input-Eintrags, keine Suche mitten im Wort oder in beliebiger Reihenfolge. Wer "schuhe" eingibt und "Wanderschuhe" finden möchte, muss "Schuhe" als eigenen Eintrag im input-Array hinterlegen, weil das Suffix allein nicht automatisch matcht.

3. Der Edge N-Gram Ansatz als Alternative

Der Edge N-Gram Ansatz verfolgt eine grundlegend andere Strategie: Statt einer dedizierten In-Memory-Struktur werden beim Indexieren alle Präfixe eines Wortes als separate Tokens im regulären invertierten Index gespeichert. Aus "Wanderschuhe" entstehen so die Tokens "W", "Wa", "Wan", "Wand" und so weiter bis zur konfigurierten Maximallänge. Eine Suchanfrage nach "wander" findet dann direkt das vorab generierte Token "wander" im Index, was eine normale, sehr schnelle Term-Suche ermöglicht.

Der entscheidende Vorteil des Edge N-Gram Ansatzes: Er funktioniert mit der ganz normalen _search Query-Syntax und lässt sich beliebig mit anderen Filtern, Aggregationen und Bool-Klauseln kombinieren, was beim Completion Suggester mit seiner separaten API nicht möglich ist. Der Nachteil ist ein höherer Speicherbedarf im Index, weil für jedes Wort mehrere Tokens statt eines einzigen gespeichert werden, sowie eine tendenziell etwas höhere Latenz gegenüber der spezialisierten FST-Struktur des Completion Suggester.

PUT /produkte_edgengram
{
  "settings": {
    "analysis": {
      "filter": {
        "edge_ngram_filter": {
          "type": "edge_ngram",
          "min_gram": 2,
          "max_gram": 15
        }
      },
      "analyzer": {
        "autocomplete_index": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase", "edge_ngram_filter"]
        },
        "autocomplete_search": {
          "type": "custom",
          "tokenizer": "standard",
          "filter": ["lowercase"]
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "titel": {
        "type": "text",
        "analyzer": "autocomplete_index",
        "search_analyzer": "autocomplete_search"
      }
    }
  }
}

GET /produkte_edgengram/_search
{
  "query": { "match": { "titel": "wander" } }
}

Entscheidend ist hier die getrennte Konfiguration von Index- und Suchzeit-Analyzer: Der Index-Analyzer generiert die Edge N-Gram Tokens, während der Suchzeit-Analyzer den Suchbegriff unverändert lässt. Würde derselbe Analyzer für beide Fälle verwendet, würden aus dem Suchbegriff selbst wieder N-Gramme erzeugt, was zu falschen, viel zu breiten Treffern führen würde.

4. Completion Suggester vs. Edge N-Gram im Direktvergleich

Beide Ansätze lösen dieselbe Grundaufgabe mit unterschiedlichen Kompromissen. Der Completion Suggester punktet bei reiner Geschwindigkeit und niedrigerem Speicherbedarf für die reine Autocomplete-Funktion, verliert aber an Flexibilität, weil er nicht mit regulären Filtern kombinierbar ist und Matching ausschließlich am Wortanfang unterstützt. Der Edge N-Gram Ansatz ist flexibler und in die normale Such-Infrastruktur integriert, kostet aber mehr Indexspeicher und produziert bei falscher Konfiguration leicht irreführende Teiltreffer.

Ein praktisches Entscheidungskriterium: Wenn Autocomplete kontextabhängig gefiltert werden muss, etwa nur Produkte einer bestimmten Kategorie oder eines bestimmten Lagers vorschlagen soll, ist der Edge N-Gram Ansatz oder search_as_you_type meist die praktikablere Wahl, weil sich normale bool Filter direkt in dieselbe Query einbauen lassen. Der Completion Suggester unterstützt zwar mit contexts eine eigene Filterlogik, diese ist aber weniger flexibel als reguläre Filter-Queries und muss bereits beim Indexieren als separates Kontextfeld angelegt werden.

5. Fuzzy-Suggestions und Kontext-Filterung

Tippfehler sind bei Autocomplete unvermeidlich, und beide Hauptansätze bieten dafür unterschiedliche Lösungen. Der Completion Suggester unterstützt eine eingebaute fuzzy Option direkt in der suggest-Query, die eine konfigurierbare Editierdistanz erlaubt. Der Edge N-Gram Ansatz kann Fuzzy-Matching über eine separate fuzzy oder match Query mit fuzziness: AUTO ergänzen, was allerdings eine zusätzliche Anfrage oder eine kombinierte Bool-Query mit should-Klauseln erfordert.

Kontext-Filterung mit dem Completion Suggester erfolgt über contexts, ein deklariertes Feld im Mapping vom Typ category oder geo, das beim Indexieren mit dem passenden Kontextwert befüllt wird, etwa der Produktkategorie. Bei der Suchanfrage wird dieser Kontext im completion-Block mitgegeben, wodurch nur Vorschläge mit passendem Kontext zurückgegeben werden, ohne dass eine separate Filter-Query nötig ist.

PUT /produkte
{
  "mappings": {
    "properties": {
      "titel_suggest": {
        "type": "completion",
        "contexts": [
          { "name": "kategorie", "type": "category" }
        ]
      }
    }
  }
}

PUT /produkte/_doc/2
{
  "titel_suggest": {
    "input": ["Wanderschuhe Herren"],
    "contexts": { "kategorie": ["schuhe", "outdoor"] }
  }
}

POST /produkte/_search
{
  "suggest": {
    "titel-suggest": {
      "prefix": "wander",
      "completion": {
        "field": "titel_suggest",
        "fuzzy": { "fuzziness": 1 },
        "contexts": { "kategorie": ["outdoor"] }
      }
    }
  }
}

6. search_as_you_type als dritte Option

Seit Elasticsearch 7.2 gibt es mit dem Feldtyp search_as_you_type eine dritte, vereinfachte Möglichkeit für Autocomplete. Statt manuell einen Edge N-Gram Analyzer zu konfigurieren, generiert dieser Feldtyp beim Indexieren automatisch mehrere interne Sub-Felder mit unterschiedlichen N-Gram-Auflösungen, etwa feld._2gram und feld._3gram, und übernimmt damit einen Großteil der manuellen Konfigurationsarbeit, die beim klassischen Edge N-Gram Ansatz nötig ist.

Die Abfrage erfolgt über die spezielle Query-Art multi_match mit type: bool_prefix, die automatisch das passende Sub-Feld für die aktuelle Eingabelänge wählt. Dieser Ansatz vereint die Integration in die normale Query-Syntax des Edge N-Gram Ansatzes mit deutlich reduziertem Konfigurationsaufwand, was ihn für viele neue Projekte zur pragmatischen Standardwahl macht. Ein tieferer Vergleich zwischen search_as_you_type und dem klassischen Completion Suggester in Bezug auf Performance-Details folgt in einem eigenen, spezialisierten Artikel zu diesem Feldtyp.

PUT /produkte_sayt
{
  "mappings": {
    "properties": {
      "titel": {
        "type": "search_as_you_type"
      }
    }
  }
}

GET /produkte_sayt/_search
{
  "query": {
    "multi_match": {
      "query": "wander sch",
      "type": "bool_prefix",
      "fields": ["titel", "titel._2gram", "titel._3gram"]
    }
  }
}

7. Gewichtung und Ranking von Vorschlägen

Autocomplete-Vorschläge ohne sinnvolles Ranking sind wenig hilfreich, wenn mehrere Einträge auf dieselbe Eingabe passen. Der Completion Suggester bietet dafür das eingebaute weight-Feld, ein Integer-Wert, der direkt die Sortierreihenfolge der zurückgegebenen Vorschläge bestimmt. In der Praxis wird dieser Wert häufig aus Business-Metriken wie Verkaufszahlen, Popularität oder Klickrate abgeleitet und regelmäßig aktualisiert, damit beliebte Produkte in der Autocomplete-Liste weiter oben erscheinen.

Beim Edge N-Gram Ansatz und bei search_as_you_type erfolgt Ranking über den regulären BM25-Score der zugrunde liegenden Query, ergänzt um optionale Function-Score-Boosts für Popularität oder Aktualität, genau wie bei einer normalen Suche. Das bietet mehr Flexibilität als das starre weight-Feld des Completion Suggester, erfordert aber auch mehr Konfigurationsaufwand, um ein vergleichbar gutes Ranking-Ergebnis zu erzielen.

8. Mehrsprachige Autocomplete-Strategien

Mehrsprachiger Autocomplete stellt eine besondere Herausforderung dar, weil Sprachbesonderheiten wie Umlaute, Akzente und unterschiedliche Wortsegmentierung berücksichtigt werden müssen. Ein bewährter Ansatz ist, sowohl beim Completion Suggester als auch beim Edge N-Gram Ansatz eigene Felder pro Sprache anzulegen, ähnlich wie bei mehrsprachigem Stemming, und die Suchanfrage abhängig von der Nutzersprache auf das passende Feld zu richten.

Ein zusätzlicher Aspekt für deutsche Autocomplete-Implementierungen ist die Normalisierung von Umlauten: Eine Eingabe "ae" sollte idealerweise auch Treffer mit "ä" finden und umgekehrt. Der asciifolding Token Filter oder der spezialisiertere german_normalization Filter lösen dieses Problem, indem sie beide Schreibweisen beim Indexieren auf eine gemeinsame Normalform reduzieren, unabhängig davon, welcher der drei Autocomplete-Ansätze zum Einsatz kommt.

9. Autocomplete-Index-Pflege: Updates ohne Downtime

Autocomplete-Daten ändern sich häufig, etwa wenn neue Produkte hinzukommen oder Verkaufszahlen sich ändern und das Ranking-Gewicht neu berechnet werden muss. Bei kleineren Änderungsvolumen genügt ein einfaches partielles Update einzelner Dokumente über die reguläre Update API. Bei umfangreicheren Umstrukturierungen, etwa einer Änderung der Analyzer-Konfiguration für den Edge N-Gram Ansatz, ist ein Mapping-Update auf einem bestehenden Index meist nicht möglich, weil Analyzer-Einstellungen nach dem initialen Anlegen des Index unveränderlich sind.

Die robuste Lösung dafür ist das etablierte Alias-Pattern: Ein neuer Index mit der geänderten Konfiguration wird parallel aufgebaut, die Daten werden über die Reindex API vollständig übertragen, und erst nach erfolgreicher Validierung wird der Such-Alias atomar auf den neuen Index umgeschaltet. Dieses Verfahren garantiert, dass Autocomplete-Anfragen während der gesamten Migration unterbrechungsfrei funktionieren, weil der alte Index bis zum letzten Moment aktiv bleibt.

10. Zusammenfassung

Elasticsearch bietet drei unterschiedliche Wege, um Autocomplete und Suggest-Funktionen umzusetzen. Der Completion Suggester punktet mit minimaler Latenz über eine dedizierte In-Memory-Struktur, ist aber weniger flexibel bei Filterung und Kombination mit anderen Queries. Der Edge N-Gram Ansatz integriert sich vollständig in die normale Query-Syntax und erlaubt beliebige Filter-Kombinationen, kostet dafür mehr Indexspeicher. search_as_you_type vereint die Vorteile des Edge N-Gram Ansatzes mit deutlich reduziertem Konfigurationsaufwand und ist für viele neue Projekte die pragmatische Standardwahl.

Fuzzy-Matching, Kontext-Filterung und mehrsprachige Unterstützung sind bei allen drei Ansätzen möglich, unterscheiden sich aber in Implementierungsaufwand und Flexibilität. Für Index-Updates an der Autocomplete-Konfiguration hat sich das Alias-Pattern mit Reindex API als robuster Weg für Migrationen ohne Downtime etabliert. Die Wahl des richtigen Ansatzes sollte immer auf Basis des konkreten Anwendungsfalls erfolgen, nicht nach pauschaler Präferenz.

11. FAQ: Autocomplete und Suggest implementieren