Elasticsearch mit kNN: Hybrid Keyword und Vektor-Suche in einer Anfrage

Was ist Elasticsearch mit kNN?

Elasticsearch ist eine etablierte Such- und Analyse-Engine, seit 2010 von Elastic NV entwickelt. Sie basiert auf Apache Lucene und ist in Java geschrieben. Stand Mai 2026 ist Version 9.x aktuell – Version 8.0 (2022) brachte die native kNN-Vektor-Suche, Version 9 (Anfang 2026) ergänzte verbesserte Skalar- und Binary-Quantisierung und bessere Hybrid-Suche.

Die Lizenz-Situation ist seit 2021 dual: Elastic License v2 (ELv2) und Server Side Public License (SSPL). Beide Lizenzen sind source-available, aber nicht OSI-konform. Praktisch heisst das: Self-Hosting in einer Anwaltskanzlei, Treuhand oder einer eigenen Plattform ist erlaubt; das Repackaging von Elasticsearch als Managed-SaaS-Dienst unter eigenem Brand ist es nicht. Für typische CH-KMU-Setups ist das kein Hindernis; für SaaS-Anbieter, die Elasticsearch weiterverkaufen, ist es eines.

Der Open-Source-Fork OpenSearch (Amazon, 2021) folgt unter Apache 2.0 und ist API-kompatibel zu Elasticsearch 7.10. Stand Mai 2026 hat OpenSearch 2.18+ ebenfalls native kNN-Suche, allerdings mit einer separaten Code-Basis und etwas anderen Performance-Profilen.

Elasticsearchs kNN-Suche basiert auf Lucenes HNSW-Implementation. Eine dense_vector-Feldtyp speichert Float32-, Float16-, Byte- oder Bit-Vektoren mit konfigurierbarer Dimension. Der HNSW-Index wird automatisch pro Segment gebaut; Suche per knn-Query-Klausel liefert ANN-Ergebnisse. Die Hybrid-Suche kombiniert BM25-Volltext und kNN-Vektor-Score per RRF (Reciprocal Rank Fusion) – Elasticsearchs Standardmethode seit 8.8 für Hybrid-Score.

Die Cloud-Variante Elastic Cloud ist auf AWS, GCP und Azure verfügbar, mit mehreren EU-Regionen (eu-central-1, eu-west-1, eu-west-2). Self-Hosted läuft als Java-Service, Docker-Container oder via Helm-Chart auf Kubernetes.

Für CH-Treuhand- und KMU-Setups ist Elasticsearch die richtige Wahl, wenn Volltext-Suche bereits produktiv genutzt wird oder Hybrid Keyword-Vektor-Suche zentraler Anwendungsfall ist.

Warum es wichtig ist

Viele Schweizer Treuhand- und Anwaltsbüros nutzen Elasticsearch bereits – für Dokumenten-Suche, Log-Analyse, Compliance-Recherche oder als Backend einer eigenen Wissensbasis. Wenn der Vektor-Use-Case auftaucht (RAG, semantische Suche), liegt der Gedanke nahe, Elasticsearch für beides zu nutzen. Drei Konsequenzen sind dabei relevant.

Erstens: Hybrid-Suche ist Elasticsearchs Stärke. Eine juristische Recherche nach „Art. 957a OR Aufbewahrung Belege" ist ein Mischfall – wortwörtliche Treffer auf „Art. 957a OR" zählen, semantisch verwandte Begriffe wie „Buchführungspflicht" auch. BM25 alleine verfehlt die semantischen Treffer; reine Vektor-Suche kann den genauen Paragraph übersehen. RRF kombiniert beide Scores aus den unabhängigen Suchergebnissen. In Elasticsearch ist das eine Query-Klausel; in Qdrant oder Weaviate erfordert es eine eigene Pipeline-Stufe.

Zweitens: bestehende Infrastruktur und Wissen. Wer Elasticsearch produktiv betreibt, hat Backup, Monitoring, RBAC, Kibana-Dashboards bereits eingerichtet. Eine zweite DB (Qdrant, Weaviate, pgvector) bedeutet eine zweite Lernkurve und einen zweiten Betriebsstack. Wenn der Vektor-Use-Case in dieselbe Elasticsearch-Instanz passt, ist die Marginalkosten-Rechnung klar zugunsten Elasticsearch.

Drittens: Lizenz. Elasticsearch unter ELv2/SSPL erlaubt interne Nutzung in jeder Grösse. Eine Treuhand mit eigenem Elasticsearch-Setup hat keine Lizenz-Probleme. Wer aber ein SaaS-Produkt für mehrere Kunden bauen will, das Elasticsearch als Bestandteil weiterverkauft, muss zu OpenSearch wechseln oder eine Elastic-Lizenz erwerben.

Die Schwäche im Vektor-Fokus: Elasticsearch ist primär Volltext-Engine. Pure Vektor-Suche mit komplexer Filter-Logik im HNSW-Graph ist in Qdrant ausgereifter; Multi-Modal mit Text-Bild-Embeddings im selben Index ist in Weaviate ergonomischer; pgvector ist einfacher zu betreiben für kleine Setups. Elasticsearch lohnt, wenn Volltext-Suche substantieller Anteil des Use-Cases ist.

Wie es funktioniert

Setup: Elasticsearch läuft als Java-Service oder Docker-Container. Single-Node-Setup via docker run elasticsearch:9.0.0, Cluster-Setup mit elastic/elasticsearch-Helm-Chart. Elastic Cloud bietet Managed-Service ab USD 95/Monat.

Index-Mapping mit dense_vector-Feld: PUT /docs { "mappings": { "properties": { "title": { "type": "text" }, "content": { "type": "text" }, "client_id": { "type": "integer" }, "embedding": { "type": "dense_vector", "dims": 1536, "index": true, "similarity": "cosine", "index_options": { "type": "int8_hnsw", "m": 16, "ef_construction": 100 } } } } }

Das mapping definiert ein Volltext-Feld, ein Integer-Filter-Feld und ein dense_vector-Feld mit HNSW-Index. index_options steuert Quantisierung (int8_hnsw für 4x weniger Speicher) und HNSW-Parameter.

Indexing per POST /docs/_doc oder _bulk: POST /docs/_bulk { "index": { "_id": "doc1" } } { "title": "Rechnung Müller", "content": "...", "client_id": 42, "embedding": [0.1, 0.2, ...] }

Reine Vektor-Suche per knn-Klausel: POST /docs/_search { "knn": { "field": "embedding", "query_vector": [0.1, 0.2, ...], "k": 10, "num_candidates": 100, "filter": { "term": { "client_id": 42 } } } }

Der filter wird in der HNSW-Suche berücksichtigt (filtered HNSW). Quantisierte Vektoren werden automatisch genutzt, wenn int8_hnsw oder bbq_hnsw konfiguriert ist.

Hybrid-Suche per RRF: POST /docs/_search { "retriever": { "rrf": { "retrievers": [ { "standard": { "query": { "match": { "content": "Art. 957a OR Aufbewahrung" } } } }, { "knn": { "field": "embedding", "query_vector_builder": { "text_embedding": { "model_id": "multilingual-e5-small", "model_text": "Art. 957a OR Aufbewahrung" } }, "k": 50, "num_candidates": 100 } } ], "rank_window_size": 50, "rank_constant": 20 } } }

RRF fusioniert die Ergebnisse beider Retriever via Reciprocal Rank Fusion. Der query_vector_builder erlaubt es, das Embedding direkt vom Elasticsearch-eigenen Inference-Cluster berechnen zu lassen – kein externer Embedding-Call nötig.

Multi-Tenant-Trennung über Document-Level-Security (DLS, Enterprise-Tier), index-pro-Tenant oder filter-basiert via client_id. Backup via Snapshot-API in S3-kompatiblen Speicher. Monitoring via Kibana und Elastic Stack-Metriken.

Elasticsearch kNN in 5 Schritten produktiv

1. 01Cluster-Architektur planen: Single-Node für < 1 Mio. Vektoren, Multi-Node mit 3 Master-Eligible-Nodes ab Production. JVM-Heap auf 50% des verfügbaren RAM, max 32 GB.
2. 02Index-Mapping anlegen: dense_vector mit dims, similarity (cosine/dot_product/l2_norm), index_options (int8_hnsw für 4x Speicher-Reduktion).
3. 03Embedding-Strategie: extern (OpenAI, Cohere) oder intern (Elastic Inference mit Multilingual-E5). Bei interner Variante das Modell deployen, dann query_vector_builder nutzen.
4. 04Ingestion: _bulk-Endpoint mit Batches von 1000 Dokumenten. Bei grossen Mengen Refresh-Interval temporaer deaktivieren (refresh: false).
5. 05Backup und Monitoring: Snapshots in S3-kompatiblen Storage via Repository-Konfiguration; Cluster-Health via /_cluster/health; Kibana-Dashboards für Index-Wachstum.

Wann Elasticsearch kNN einsetzen

Elasticsearch mit kNN ist die richtige Wahl, wenn (a) Volltext-Suche bereits zentraler Use-Case ist, (b) Hybrid Keyword-Vektor-Suche in einer Anfrage wertvoll ist, (c) Elasticsearch bereits im Stack läuft, oder (d) Multi-Index-Verwaltung und Aggregations-Fähigkeiten gebraucht werden.

Konkrete Fälle: eine juristische Plattform mit Präzedenz-Suche, in der „Art. 957a OR" wortwörtlich getroffen werden muss und semantisch verwandte Konzepte ergänzt werden. Eine Treuhand-Wissensbasis mit MwSt-Wegleitungen und intern dokumentierten Fällen, in der Stichworte und semantische Ähnlichkeit gleichwertig zählen. Ein Compliance-System über News-Streams und Sanktions-Listen mit Hybrid-Aggregationen.

Für Setups, die ohnehin Kibana-Dashboards betreiben, ist die Integration einfach: Vektor-Felder ergänzen bestehende Indizes, Kibana-Visualisierungen erweitern sich. Elastic Stack mit Logstash, Beats und Kibana ist ein bewährtes Bundle für mittelständische CH-IT-Setups.

Elastic Cloud bietet EU-Regionen Frankfurt (eu-central-1) und Ireland (eu-west-1). Für DACH-Kunden mit moderaten Anforderungen ist Frankfurt eine Option ohne TIA-Aufwand. Self-Hosted in Hetzner Helsinki/Falkenstein bleibt für strikte CH-Hosting-Anforderungen.

Für ML-nähe Use-Cases bietet Elasticsearch seit Version 8.4 native Inference-Cluster – vortrainierte Sentence-Transformer-Modelle laufen direkt in Elasticsearch, Embeddings werden serverseitig berechnet. Multilingual-E5-small (384 Dim), Multilingual-E5-large (1024 Dim), oder eigene HuggingFace-Modelle sind unterstützt. Das spart einen externen Embedding-Service.

Wann NICHT

Für reine Vektor-Suche ohne Volltext-Komponente ist Elasticsearch überdimensioniert. Qdrant oder pgvector sind einfacher, leichter, schneller in der Reinen-Vektor-Performance.

Wenn der Stack noch kein Elasticsearch enthält, ist die Einführung allein für Vektor-Suche aufwendig. Elasticsearch braucht JVM-Tuning, Heap-Konfiguration, Cluster-Setup; ein Qdrant-Container ist in 5 Minuten produktiv. Faustregel: ohne bestehenden Elastic-Stack ist ein anderer Vektor-DB der schnellere Weg.

Die ELv2/SSPL-Lizenz blockiert SaaS-Repackaging. Wer ein vertikales SaaS-Produkt (z.B. „Treuhand-AI-Search as a Service") für mehrere Kunden bauen will und Elasticsearch als Backend nutzt, braucht eine Elastic-Lizenz oder muss zu OpenSearch wechseln. Für interne Treuhand-Nutzung kein Problem; für Plattform-Builder relevant.

Für Multi-Modal mit Text-und-Bild-Embeddings in einer einzigen Suche fehlen Elasticsearch die Module wie bei Weaviate. Multiple-Vektor-Felder im selben Document sind möglich, aber das Tooling ist weniger ausgereift.

Für extremes Skalierungs-Profil (1 Mrd.+ Vektoren mit GPU-Indizes) ist Milvus oder Vespa besser geeignet. Elasticsearch skaliert auf hundert Mio. Vektoren via Sharding, aber die GPU-Acceleration ist nicht der Fokus.

Für minimale Hardware-Footprints unter 4 GB RAM ist Elasticsearch unpraktikabel – JVM-Overhead beginnt bei 2-3 GB. Auf einem Edge-Gerät oder einem kleinen Hetzner CX21 ist Qdrant oder pgvector die bessere Wahl.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. Elasticsearch documentation – dense_vector field type and kNN search · 2026-05
2. Elastic blog – kNN improvements and BBQ in Elasticsearch 9 · 2026-04
3. Elastic Cloud pricing and EU regions · 2026-05
4. OpenSearch documentation – kNN plugin and HNSW · 2026-05
5. Elastic License v2 and SSPL – license terms · 2026-03