Redis als Vektordatenbank: Ähnlichkeitssuche für Embeddings nutzen

1. Warum klassische Filter für semantische Ähnlichkeit nicht ausreichen

Klassische Redis-Abfragen, auch mit RediSearch, filtern über exakte oder numerische Kriterien: eine Kategorie, ein Preisbereich, ein Schlagwort. Für die Frage, welche Produkte einem gegebenen Produkt inhaltlich ähnlich sind, etwa basierend auf Beschreibungstext, Bild oder Nutzerverhalten, reichen solche Filter nicht aus, weil semantische Ähnlichkeit sich nicht über exakte Attributübereinstimmung abbilden lässt.

Embedding-Modelle lösen dieses Problem, indem sie Text, Bilder oder andere Inhalte in hochdimensionale Vektoren überführen, bei denen inhaltlich ähnliche Elemente im Vektorraum nahe beieinander liegen. Redis Vector Search ermöglicht es, genau diese Nähe effizient zu berechnen, ohne die Vektoren in ein separates System auslagern zu müssen.

2. Embeddings als Grundlage der Ähnlichkeitssuche

Ein Embedding ist ein numerischer Vektor fester Länge, typischerweise mehrere hundert bis über tausend Dimensionen, der von einem Machine-Learning-Modell aus einem Inhalt erzeugt wird. Zwei Produkte mit ähnlichem Embedding-Vektor gelten als inhaltlich ähnlich, gemessen etwa über den Kosinus-Abstand oder die euklidische Distanz zwischen den beiden Vektoren.

Redis selbst erzeugt keine Embeddings, es speichert und durchsucht sie lediglich. Die eigentliche Embedding-Generierung erfolgt außerhalb, etwa über ein separates Machine-Learning-Modell, das Produktbeschreibungen oder Bilder in Vektoren umwandelt, die anschließend als zusätzliches Feld eines Hash- oder JSON-Dokuments in Redis abgelegt werden.

redis-cli HSET produkt:4711 name "Basic Shirt Blau" embedding "\x3f\x8c...binaer..."

3. HNSW-Index: Approximative Suche für große Datenmengen

HNSW, kurz für Hierarchical Navigable Small World, ist ein Graph-basierter Index, der Vektoren in mehreren Schichten mit unterschiedlicher Verbindungsdichte organisiert. Eine Suchanfrage navigiert von einer groben oberen Schicht schrittweise zu immer feineren unteren Schichten und findet so sehr schnell eine gute Näherung der tatsächlich nächstgelegenen Vektoren, ohne alle Vektoren im Index vergleichen zu müssen.

Der Vorteil liegt in der Skalierbarkeit: HNSW-Abfragen bleiben auch bei mehreren Millionen Vektoren im niedrigen Millisekundenbereich, weil die Suche logarithmisch statt linear mit der Datenmenge wächst. Der Preis dafür ist Approximation, HNSW garantiert nicht immer die mathematisch exakt nächsten Nachbarn, liefert aber in der Praxis eine sehr gute Annäherung bei konfigurierbarer Genauigkeit.

redis-cli FT.CREATE idx_produkte_vektor ON HASH PREFIX 1 produkt: \
  SCHEMA embedding VECTOR HNSW 6 TYPE FLOAT32 DIM 768 DISTANCE_METRIC COSINE

4. FLAT-Index: Exakte Suche für kleinere Datenmengen

Als Alternative zu HNSW bietet Redis Vector Search auch einen FLAT-Index, der eine erschöpfende, exakte Suche über alle gespeicherten Vektoren durchführt. Jede Abfrage vergleicht dabei tatsächlich mit jedem einzelnen Vektor im Index, was die mathematisch exakt nächsten Nachbarn garantiert, aber linear mit der Anzahl der Vektoren wächst.

FLAT eignet sich deshalb vor allem für kleinere Datenmengen im Bereich weniger tausend bis niedriger zehntausend Vektoren, oder für Anwendungsfälle, in denen absolute Genauigkeit wichtiger ist als maximale Geschwindigkeit, etwa bei einer sorgfältig kuratierten Produktauswahl. Bei größeren Katalogen mit hunderttausenden Artikeln wird HNSW aufgrund seiner besseren Skalierung meist die praktikablere Wahl.

5. Distanzmetriken: Kosinus, euklidisch und innerer Produktabstand

Redis Vector Search unterstützt mehrere Distanzmetriken, die je nach Embedding-Modell unterschiedlich gut passen. Der Kosinus-Abstand misst den Winkel zwischen zwei Vektoren und ignoriert deren absolute Länge, was ihn zur häufigsten Wahl für Text-Embeddings macht, bei denen die Richtung des Vektors die semantische Bedeutung trägt.

Die euklidische Distanz misst dagegen den tatsächlichen geometrischen Abstand im Vektorraum und eignet sich für Embedding-Modelle, bei denen auch die absolute Vektorlänge Bedeutung trägt. Der innere Produktabstand schließlich wird häufig für Empfehlungssysteme genutzt, bei denen sowohl Richtung als auch Stärke einer Übereinstimmung relevant sind. Welche Metrik passt, hängt vom konkreten Embedding-Modell ab und sollte dessen Dokumentation folgen, nicht einer pauschalen Standardwahl.

6. Praxisbeispiel: Semantische Produktempfehlungen

Ein naheliegender Anwendungsfall ist eine Empfehlungsfunktion auf einer Produktdetailseite: Statt Empfehlungen ausschließlich über dieselbe Kategorie oder gemeinsam gekaufte Artikel zu bilden, lässt sich mit Vektorsuche eine inhaltliche Ähnlichkeit über Produktbeschreibung, Bildmerkmale oder eine Kombination daraus berechnen. Ein Nutzer, der eine blaue Sommerjacke betrachtet, erhält so auch stilistisch ähnliche Jacken in anderen Farben als Empfehlung, selbst wenn diese in unterschiedlichen Kategorien einsortiert sind.

Technisch läuft das über eine KNN-Abfrage, kurz für K-Nearest-Neighbors, die zu einem gegebenen Vektor die K ähnlichsten Vektoren im Index zurückliefert. Diese Abfrage lässt sich zusätzlich mit klassischen RediSearch-Filtern kombinieren, etwa um nur Produkte innerhalb eines bestimmten Preisbereichs oder mit ausreichendem Lagerbestand als Empfehlung zuzulassen, statt reine Ähnlichkeit unabhängig von Verfügbarkeit anzuzeigen.

redis-cli FT.SEARCH idx_produkte_vektor \
  "(@preis:[10 100])=>[KNN 5 @embedding $vec AS score]" \
  PARAMS 2 vec "\x3f\x8c...binaer..." \
  SORTBY score ASC DIALECT 2

7. Hybride Suche: Vektorähnlichkeit mit klassischen Filtern kombinieren

Der eigentliche praktische Mehrwert von Redis Vector Search entsteht oft erst in Kombination mit den klassischen RediSearch-Fähigkeiten aus Textfiltern, numerischen Bereichen und Tags. Eine reine Vektorsuche ohne Filter liefert zwar ähnliche Produkte, aber möglicherweise auch ausverkaufte oder preislich unpassende Artikel, während eine hybride Abfrage semantische Ähnlichkeit und harte Geschäftsregeln in einem einzigen Schritt zusammenführt.

Diese Kombination reduziert die Notwendigkeit, Vektorsuche und klassische Filterlogik in getrennten Systemen zu betreiben und die Ergebnisse anschließend in der Anwendung zu verschneiden. Für viele mittelgroße Produktkataloge ist das ein spürbarer Architekturvorteil gegenüber einer separaten Vektordatenbank neben dem bestehenden Suchsystem.

8. Abgrenzung zu dedizierten Vektordatenbanken

Dedizierte Vektordatenbanken wie Milvus, Pinecone oder Weaviate sind ausschließlich für Vektorsuche gebaut und bieten dadurch teils ausgefeiltere Index-Varianten, bessere horizontale Skalierung über sehr große Vektormengen und spezialisierte Funktionen wie Quantisierung zur weiteren Speicherreduktion. Für Anwendungen mit vielen zehn Millionen oder mehr Vektoren und dediziertem Machine-Learning-Fokus sind diese Systeme häufig die technisch ausgereiftere Wahl.

Redis Vector Search punktet dagegen dort, wo Vektorsuche nur eine von mehreren Anforderungen ist und ohnehin bereits Redis-Infrastruktur für Cache, Session oder klassische Suche vorhanden ist. Statt ein zusätzliches System für einen Teilbereich der Anwendung zu betreiben, lässt sich die Vektorsuche direkt neben den übrigen Redis-Datentypen mit derselben operativen Erfahrung und denselben Betriebsprozessen integrieren.

9. Betrieb und Skalierung von Vektorindizes

Vektorindizes sind speicherintensiv: Ein einzelner Embedding-Vektor mit 768 Dimensionen in Float32-Genauigkeit belegt bereits über drei Kilobyte reine Vektordaten, zuzüglich des HNSW-Graph-Overheads für die Verbindungsstruktur zwischen den Knoten. Bei einem Katalog mit einer Million Produkten summiert sich das schnell auf mehrere Gigabyte, die vollständig im Arbeitsspeicher der Redis-Instanz vorgehalten werden müssen.

Für die Kapazitätsplanung lohnt sich deshalb eine realistische Vorabschätzung basierend auf Vektordimension, Anzahl der Produkte und den HNSW-Parametern für Verbindungsanzahl und Suchtiefe, die sich direkt auf Speicherverbrauch und Suchgenauigkeit auswirken. Wie bei den übrigen Redis-Stack-Modulen empfiehlt sich zudem eine dedizierte Instanz für vektorlastige Workloads, getrennt vom klassischen Cache- oder Session-Backend, um gegenseitige Beeinträchtigung bei Speicherdruck zu vermeiden.

10. Zusammenfassung

11. FAQ: Redis Vector Search: Das Wichtigste auf einen Blick