Semantische Vektorsuche und andere Themen, um Freunde und Liebste zu gewinnen

Die gesamte Suchlandschaft: exakt, unscharf, semantisch, hybrid – und wann man alle kombiniert.

Suche ist nicht nur eine Sache – und semantische Suche ist kein Ersatz für den Rest davon.

„Finde den Benutzer mit der E-Mail dan@example.com” und „finde mir Artikel über Debugging als Berufseinsteiger” werden beide als Suche bezeichnet, haben aber als technische Probleme fast nichts gemeinsam. Ersteres hat eine korrekte Antwort und einen O(log n)-Indexzugriff. Letzteres hat keine korrekte Antwort – nur Relevanz – und erfordert Verständnis von Sprache, Absicht und Bedeutung.

Die Ingenieure, die bei Suchentscheidungen am überzeugendsten sind – diejenigen, die die Argumente gewinnen und das richtige System ausliefern – verstehen die gesamte Landschaft. Sie wissen, zu welchem Werkzeug sie greifen müssen und warum, und können es klar erklären.

Dieser Artikel behandelt die semantische Ebene: Was Vektorsuche tatsächlich bewirkt, wann sie gewinnt und wo sie sich nicht in den Weg stellen sollte. Die nützliche Version ist nicht „embedde alles”. Es ist das Wissen, wann Vektoren in einer hybriden Architektur neben lexikalischer, unscharfer und exakter Suche stehen sollten.

Die lexikalische und unscharfe Hälfte des Bildes – tsvector, pg_trgm, pg_search – findet sich im Postgres Textsuche-Leitfaden 2026.

Begriffe auf einen Blick

Embedding – Eine dichte Liste von Gleitkommazahlen, die von einem Modell erzeugt wird und ein Textstück (oder Bild, Audio usw.) als Punkt in einem hochdimensionalen Raum repräsentiert. Semantisch verwandte Inhalte landen nahe beieinander; nicht verwandte Inhalte landen weit entfernt.

Lexikalische Suche – Suche basierend auf exakter Wort- und Token-Übereinstimmung. Schnell, deterministisch und korrekt für bekannte Begriffe. Versteht keine Synonyme, Paraphrasen oder sprachübergreifende Entsprechungen.

Semantische Suche – Suche basierend auf Bedeutung statt auf Token. Eine Abfrage wie „wie gehe ich mit Timeouts um” kann ein Dokument mit dem Titel „Konfiguration von Wiederholungsrichtlinien” finden, ohne gemeinsame Wörter, weil ihre Embeddings geometrisch nahe beieinander liegen.

Vektor – Eine Liste von Zahlen. In Suchkontexten die Ausgabe eines Embedding-Modells. „Vektorsuche” findet die Vektoren, die einem Abfragevektor durch geometrische Distanz am nächsten sind.

FTS (Full-Text-Suche) – Die integrierte lexikalische Suche von Postgres, basierend auf tsvector / tsquery. Tokenisiert, lemmatisiert und indexiert Text für Schlüsselwortabfragen. Stark bei Prosa und exakter Begriffssuche; blind für Bedeutung.

BM25 – Ein Ranking-Algorithmus für lexikalische Suche (verwendet von Elasticsearch, Qdrant u. a.). Bewertet Ergebnisse nach Termhäufigkeit, gewichtet mit der Seltenheit des Begriffs im Korpus. Besser als rohe Schlüsselwortsuche; immer noch lexikalisch.

HNSW (Hierarchical Navigable Small World) – Der Standardindex für approximative nächste Nachbarn bei der Vektorsuche. Baut einen geschichteten Proximity-Graphen für schnelle Ähnlichkeitsabfragen mit hohem Recall. pgvector, Qdrant, Weaviate und die meisten anderen verwenden ihn.

RRF (Reciprocal Rank Fusion) – Ein Algorithmus zum Zusammenführen von Ranglistenergebnissen aus mehreren Retrieval-Systemen. Verwendet nur die Rangposition – keine Score-Normalisierung erforderlich. Ein Ergebnis, das sowohl in der FTS- als auch in der Vektorliste weit oben steht, erhält eine stärkere kombinierte Punktzahl als eines, das nur in einer Liste dominiert.

Was semantische Suche tatsächlich bewirkt

Vektor-Embeddings wandeln Text (oder Bilder, Audio usw.) in eine Liste von Zahlen um – einen Punkt in einem hochdimensionalen Raum. Ein Embedding-Modell ist so trainiert, dass semantisch verwandte Texte in diesem Raum nahe beieinander liegen. „Hund” und „canide” landen nahe beieinander. „Einen Marathon laufen” und „ein Python-Skript ausführen” landen weit voneinander entfernt, obwohl sie ein Wort teilen.

Die Ähnlichkeitssuche in diesem Raum findet Dokumente, deren Bedeutung der Bedeutung der Abfrage am nächsten kommt, unabhängig von der exakten Wortüberlappung.

Das bedeutet:

• „Wie konfiguriere ich Anfrage-Timeouts?” kann einen Artikel mit dem Titel „Verbindungslimits und Wiederholungsrichtlinien einstellen” finden – keine überlappenden Schlüsselwörter, hohe konzeptionelle Relevanz
• „Etwas Leichtes für einen Sommerabend” kann eine Weinempfehlung finden, ohne dass Schlüsselwörter in der Produktbeschreibung vorkommen
• Eine Abfrage auf Englisch kann relevante Dokumente auf Französisch, Spanisch oder Japanisch finden, wenn das Embedding-Modell mehrsprachig trainiert wurde

Lexikalische Suche (tsvector, pg_trgm) kann nichts davon. Sie arbeitet mit Wörtern und Zeichen, nicht mit Bedeutung. Die Werkzeuge sind nicht austauschbar – sie lösen unterschiedliche Probleme.

Wann pgvector gewinnt

RAG aufbauen. Retrieval-Augmented Generation ruft die Dokumentabschnitte ab, deren Bedeutung der Frage des Benutzers am nächsten kommt, und übergibt sie einem Sprachmodell als Kontext. Dieser Retrieval-Schritt ist eine Vektoroperation. FTS übersieht Paraphrasen, Synonyme und konzeptionelle Übereinstimmungen, die ein relevanter Abschnitt möglicherweise anders ausdrückt. Der Vorteil von pgvector gegenüber einem eigenständigen Vektor-Store: Es läuft in Ihrer bestehenden Postgres-Instanz – kein separater Dienst zum Bereitstellen, Betreiben oder Synchronisieren von Daten.

Benutzer beschreiben, was sie wollen, nicht wonach sie suchen sollen. „Artikel über den Aufbau von Selbstvertrauen als neue Führungskraft” enthält keine Schlüsselwörter, die zuverlässig in den relevanten Beiträgen vorkommen. „Ein leichtgewichtiges Framework zur Behandlung von Seiteneffekten” verwendet diese genauen Wörter möglicherweise nicht in der Dokumentation. Vektorsuche trifft die Absicht, nicht die Schreibweise.

Ähnliche Elemente finden. Verwandte Produkte, ähnliche Support-Tickets, doppelte Fehlerberichte, Artikel, die Ihnen auch gefallen könnten. „Finde Probleme ähnlich zu diesem” ist eine Nächste-Nachbarn-Suche – betten Sie das Element ein, finden Sie seine geometrischen Nachbarn. Ein wichtiger Vorbehalt: Die Vektorsuche gibt immer Ergebnisse zurück, selbst wenn nichts wirklich ähnlich ist. Für Deduplizierungs- und Empfehlungsfälle filtern Sie nach einem minimalen Ähnlichkeitsschwellenwert (z. B. Kosinus-Ähnlichkeit ≥ 0,80), um Übereinstimmungen mit geringem Vertrauen nicht als bedeutungsvoll auszugeben.

Semantische Deduplizierung. Bevor Sie Inhalte für RAG oder Suche indexieren, müssen Sie oft nahe Duplikate im Korpus identifizieren – mehrfach überarbeitete Artikel, doppelt eingereichte Support-Tickets, sich stark überschneidende Wissensdatenbankeinträge. Betten Sie die Dokumente ein und filtern Sie nach Kosinus-Ähnlichkeit, um nahe Duplikate zu markieren oder zusammenzuführen, bevor sie Ihren Index verunreinigen. Dies verhindert, dass das Retrieval mehrere nahezu identische Abschnitte zurückgibt und das Kontextfenster verwässert.

Mehrsprachige Suche. Mehrsprachige Embedding-Modelle ordnen semantisch äquivalente Inhalte sprachübergreifend in nahe Vektoren ein. Eine Abfrage auf Spanisch nach „perder peso” kann einem englischen Artikel über „nachhaltige Gewohnheiten zur Gewichtsabnahme” entsprechen – keine gemeinsamen Token, gleiche zugrundeliegende Bedeutung. FTS erfordert sprachspezifische Wörterbuchkonfiguration und verarbeitet sprachübergreifende Abfragen schlecht. pg_trgm ist sprachunabhängig, aber orthografisch, nicht semantisch.

pgvector einrichten

Von der Erweiterungsinstallation bis zur Ähnlichkeitsabfrage ist die Einrichtung eine Handvoll SQL-Anweisungen:

CREATE EXTENSION IF NOT EXISTS vector;

ALTER TABLE documents ADD COLUMN embedding vector(1536);

-- HNSW ist normalerweise der erste Index, den man für mittelgroße Datensätze ausprobiert
CREATE INDEX documents_embedding_idx
  ON documents USING hnsw (embedding vector_cosine_ops);

-- Semantische Suchabfrage
SELECT id, title, 1 - (embedding <=> $1::vector) AS similarity
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

<=> ist die Kosinus-Distanz. 1 - cosine_distance ergibt die Kosinus-Ähnlichkeit (1,0 = identisch, 0,0 = orthogonal). Für ivfflat (die ältere, schneller zu erstellende Alternative) verwenden Sie lists = sqrt(Zeilenanzahl) als Ausgangspunkt.

Was pgvector nicht gut kann

• Exakte Token-Übereinstimmung – Produkt-SKUs, Fehlercodes, Funktionsnamen. ORD-12345 ist nichts semantisch ähnlich. Eine embeddingsbasierte Suche gibt möglicherweise ORD-12344 oder nichts Relevantes zurück. Verwenden Sie FTS oder einen B-Tree-Index.
• Namen und Eigennamen. Der Embedding-Raum organisiert nach Bedeutung, nicht nach Schreibweise. Der Benutzereintrag „Micheal Jordan” liegt nicht unbedingt in der Nähe von „Michael Jordan” im Vektorraum.
• Kurze Zeichenfolgen, bei denen zeichenbasierte Ähnlichkeit wichtiger ist als Bedeutung. pg_trgm erledigt dies.
• Abfragen, bei denen der exakte Begriff vorkommen muss. BM25 und FTS sind zuverlässiger für die Suche nach bekannten Begriffen.

Hybride Suche: Das Argument für beides

Technische Dokumentation ist das klarste Beispiel, bei dem keines der Werkzeuge allein ausreicht.

Benutzer, die nach „Wie konfiguriere ich Timeouts” suchen, benötigen konzeptionelle Übereinstimmung: Ein Artikel mit dem Titel „Wiederholungsrichtlinien und Verbindungslimits einstellen” hat keine überlappenden Schlüsselwörter, ist aber genau das, was sie brauchen.

Dieselben Benutzer suchen auch nach withRetry(), ECONNRESET und ERR_SOCKET_TIMEOUT. Diese exakten Zeichenfolgen müssen vorkommen – semantische Übereinstimmung findet sie möglicherweise nicht zuverlässig, und ein falsch positives Ergebnis (konzeptionell ähnlich, aber nicht die richtige API) ist aktiv irreführend.

Die Vektorsuche erledigt die konzeptionellen Abfragen. FTS erledigt die exakten Begriffe. Keines von beiden beides gut allein.

Die Lösung ist eine hybride Suche: Beide ausführen und die Ergebnisse zusammenführen.

Reciprocal Rank Fusion

Reciprocal Rank Fusion (RRF) ist der Standardalgorithmus zum Kombinieren von Ranglisten aus verschiedenen Retrieval-Systemen. Er erfordert keine Normalisierung von Punktzahlen zwischen Systemen – er verwendet nur Rangpositionen. Ein Ergebnis, das in beiden Listen weit oben erscheint, erhält eine stärkere kombinierte Punktzahl als eines, das nur in einer dominiert.

WITH fts_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY ts_rank(search_vector, query) DESC) AS rank
  FROM documents, to_tsquery('english', $1) query
  WHERE search_vector @@ query
  LIMIT 50
),
vector_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY embedding <=> $2::vector) AS rank
  FROM documents
  ORDER BY embedding <=> $2::vector
  LIMIT 50
),
rrf AS (
  SELECT
    COALESCE(f.id, v.id) AS id,
    COALESCE(1.0 / (60 + f.rank), 0) +
    COALESCE(1.0 / (60 + v.rank), 0) AS rrf_score
  FROM fts_results f
  FULL OUTER JOIN vector_results v ON f.id = v.id
)
SELECT d.id, d.title, rrf.rrf_score
FROM rrf
JOIN documents d ON d.id = rrf.id
ORDER BY rrf_score DESC
LIMIT 10;

Die 60 im Nenner ist die RRF-Konstante. Höhere Werte dämpfen Rangpositionsunterschiede; niedrigere Werte verstärken sie. Der Standardwert von 60 funktioniert gut für die meisten Inhaltstypen.

RRF vermeidet das schwierigere Problem der Normalisierung von ts_rank (einem Log-Häufigkeits-Score) gegenüber der Kosinus-Distanz (einem geometrischen Maß). Sie sind nicht vergleichbar. RRF fragt nur: „Wie weit oben erschien dieses Ergebnis in jeder Liste?”

Hybride Suche mit Trigrammen

Für die benutzerseitige Suche über gemischte Inhalte – bei der Benutzer in derselben Sitzung nach einem Personennamen, einem Konzept oder einem exakten Begriff suchen können – bewältigt die Drei-Wege-Fusion alle:

WITH trgm_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY similarity(title, $1) DESC) AS rank
  FROM documents
  WHERE title % $1
  LIMIT 50
),
fts_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY ts_rank(search_vector, to_tsquery('english', $1)) DESC) AS rank
  FROM documents
  WHERE search_vector @@ to_tsquery('english', $1)
  LIMIT 50
),
vector_results AS (
  SELECT id,
    ROW_NUMBER() OVER (ORDER BY embedding <=> $2::vector) AS rank
  FROM documents
  ORDER BY embedding <=> $2::vector
  LIMIT 50
),
rrf AS (
  SELECT
    COALESCE(t.id, f.id, v.id) AS id,
    COALESCE(1.0 / (60 + t.rank), 0) +
    COALESCE(1.0 / (60 + f.rank), 0) +
    COALESCE(1.0 / (60 + v.rank), 0) AS rrf_score
  FROM trgm_results t
  FULL OUTER JOIN fts_results f ON t.id = f.id
  FULL OUTER JOIN vector_results v ON COALESCE(t.id, f.id) = v.id
)
SELECT d.id, d.title, rrf.rrf_score
FROM rrf
JOIN documents d ON d.id = rrf.id
ORDER BY rrf_score DESC
LIMIT 10;

Dies bewältigt: unscharfe Namensübereinstimmungen (Trigrams), exakte Schlüsselwortübereinstimmungen (FTS) und konzeptionelle Abfragen (Vektor). Ein einziges Suchfeld kann alle drei Benutzerabsichten bedienen.

Mehrschichtige hybride Architekturen

Echte Anwendungen haben selten eine einzige Suchoberfläche. Sie haben mehrere, jede mit einem anderen Bedarf:

Dies sind keine hypothetischen Szenarien. Die meisten inhaltsreichen Anwendungen benötigen mindestens zwei unterschiedliche Suchoberflächen mit unterschiedlichen Abfrageformen. Die Versuchung besteht darin, einen Ansatz zu wählen und ihn überall zu verwenden – normalerweise jetzt die Vektorsuche, da sie die modische Wahl ist. Das führt zu teuren Embeddings für Probleme, bei denen ein Trigramm-Index schneller, billiger und korrekter gewesen wäre.

Die Faustregel

Fügen Sie eine Ebene hinzu, wenn ein Fehlermodus auftritt, den die aktuelle Ebene nicht beheben kann:

• Benutzer beschweren sich, dass Tippfehler nicht erkannt werden → pg_trgm hinzufügen
• Benutzer suchen nach Konzepten und verpassen relevante Ergebnisse → pgvector hinzufügen
• Benutzer suchen nach exakten Symbolen oder Codes und erhalten konzeptionelle Ergebnisse → FTS hinzufügen oder prüfen, ob Sie sich zu sehr auf die Vektorsuche verlassen
• Latenz wird zum Problem → Vorfilterung, approximative Indizes oder einen dedizierten Store evaluieren

Wenn Sie doch einen dedizierten Vektor-Store brauchen

pgvector bewältigt viele Anwendungssuchen, bevor Sie eine weitere Datenbank benötigen. Der grobe Grenzwert hängt von der Vektoranzahl, den Indexeinstellungen, der Schreibrate, Filtern, Hardware und Parallelität ab – behandeln Sie also jede „unter 10 Millionen Vektoren”-Regel als eine zu benchmarkende Ausgangsannahme, nicht als Produktlimit. Wenn Sie es wirklich darüber hinaus geschafft haben – sehr hohe Parallelität, sehr niedrige p99-Latenzanforderungen, Milliarden von Vektoren oder ernsthafte Mandantenisolierung – ist die Landschaft der dedizierten Vektordatenbanken breit und das Verständnis wert.

Was die Matrix-Spalten tatsächlich bedeuten

Hybride Suche bedeutet, dass BM25-Schlüsselwortsuche und Vektorähnlichkeit in einer Abfrage laufen, zusammengeführt über RRF. Ohne sie wählen Sie entweder einen Suchmodus oder fusionieren zwei Abfragen selbst.

Sparse Vectors gehen weiter als BM25. Ein SPLADE-Sparse-Vector hat ~30.000 Dimensionen (eine pro Vokabularbegriff), ~98 % Nullen. Nicht-Null-Positionen sagen Ihnen, welche Begriffe wichtig sind und wie wichtig. Eine Abfrage nach „Hunden” gewichtet auch „canide” und „Haustier” – BM25-Niveau-Präzision plus Begriffserweiterung innerhalb eines Vektor-Index. Wenn diese Spalte falsch ist, benötigen Sie eine separate FTS-Ebene für exakte Begriffssuchen.

# SPLADE: ~30.000 Dims, ~60 ungleich Null – nur relevante Vokabularpositionen feuern
def encode_splade(text: str) -> dict:
    tokens = tokenizer(text, return_tensors="pt", truncation=True, max_length=512)
    with torch.no_grad():
        output = model(**tokens)
    vec = torch.log1p(torch.relu(output.logits)).max(dim=1).values.squeeze()
    return {"indices": vec.nonzero().squeeze().tolist(), "values": vec[vec != 0].tolist()}

SQL / SQL-ähnlich dreht sich wirklich um Filterung. Vektorsuche ohne Filterung ist eine Demo. Sie brauchen immer noch Mandantenbereich, Datumsbereiche, Berechtigungen und Kategoriefilter. Vollständiges SQL (pgvector, LanceDB) drückt dies neben Ihren bestehenden Joins aus. Zweckgebundene Datenbanken verwenden JSON-Filterobjekte (Qdrant, Pinecone), eine Abfrage-DSL (Elasticsearch, Milvus) oder GraphQL (Weaviate). Sie funktionieren; SQL wird attraktiver, je komplexer die Filterlogik wird.

-- pgvector: Vektorähnlichkeit ist nur ein weiterer Ausdruck
SELECT id, title, 1 - (embedding <=> $1) AS score
FROM documents
WHERE tenant_id = $2
  AND category = ANY($3::text[])
  AND created_at > NOW() - INTERVAL '90 days'
ORDER BY embedding <=> $1
LIMIT 10;

# Qdrant: äquivalenter Filter als Python-Objekt – gleiches Ergebnis, mehr Aufwand
results = client.query_points(
    collection_name="documents", query=query_embedding,
    query_filter=models.Filter(must=[
        models.FieldCondition(key="tenant_id", match=models.MatchValue(value=tenant_id)),
        models.FieldCondition(key="category",  match=models.MatchAny(any=categories)),
        models.FieldCondition(key="created_at", range=models.DatetimeRange(gte=cutoff)),
    ]),
    limit=10,
)

Multimodal nativ bedeutet, dass die Datenbank Embedding-Modelle für Nicht-Text-Inhalte mitliefert. Sie übergeben eine rohe Bild-URL; sie kümmert sich um die Vektorisierung. Die meisten Datenbanken sind Embedding-agnostisch – Sie besitzen die Embedding-Pipeline. Marqo und Weaviate (über CLIP/ImageBind-Module) schließen diesen Kreislauf.

# Marqo: rohe Bilder per POST, mit Text abfragen – kein externer Embedding-Schritt
mq.index("products").add_documents(
    [{"id": "shoe-001", "image": "https://cdn.example.com/shoes/001.jpg"}],
    tensor_fields=["image"]
)
results = mq.index("products").search(q="leichte Schuhe für den Sommer")
# Gibt shoe-001 trotz null Schlüsselwortüberschneidung zurück – CLIP erledigt die modalitätsübergreifende Übereinstimmung

Datenträgerbasierter Index ist ein Kostenhebel. Arbeitsspeicher-residente HNSW-Indizes können mehrere GB RAM pro Million 1536-Dimensions-Vektoren benötigen, wenn Rohvektoren, Graph-Overhead und Metadaten gezählt werden. Datenträger-native Alternativen (Milvus DiskANN, Elasticsearch DiskBBQ, LanceDBs Lance-Format, Turbopuffers Objektspeicher-Tier) tauschen oft etwas Abfragelatenz gegen geringere Infrastrukturkosten. Für RAG-Workloads, bei denen die Modelllatenz bereits dominiert, ist dieser Kompromiss oft das Benchmarking wert.

Maximale Dimensionen ist eine Migration, die in Ihrer Architektur versteckt ist. text-embedding-3-large verwendet 3072 Dims, Jina v3 kann größere Embeddings ausgeben, und Forschungsmodelle gehen immer weiter nach oben. Einige verwaltete Dienste veröffentlichen harte Dimensionsbeschränkungen; andere dokumentieren hohe Beschränkungen oder keine praktische Beschränkung für typische Embedding-Modelle. Überprüfen Sie die aktuellen Dokumente, bevor Sie sich festlegen. Wählen Sie etwas mit Spielraum; die Migration eines Vektor-Index, weil Sie eine Dimensionsgrenze erreicht haben, ist ein schmerzhafter Sprint.

Zuletzt geprüft anhand öffentlicher Projektdokumente und Produktseiten am 8. Mai 2026. Behandeln Sie die folgende Tabelle als Entscheidungshilfe, nicht als Ersatz für die Überprüfung aktueller Grenzwerte, Preise und Feature-Flags verwalteter Dienste.

Die Landschaft

Ein paar Dinge, die nicht in die Tabelle passen

Turbopuffers Multi-Mandanten-Fähigkeit ist auf sehr hohe Namespace-Anzahlen ausgelegt. Seine öffentliche Positionierung und Kundenberichte betonen Workloads wie Notions großen, namespace-lastigen Korpus. Wenn jeder Benutzer oder jede Organisation eine isolierte Vektorsuche benötigt, kann diese Architektur die Wirtschaftlichkeit verändern, aber benchmarken Sie immer noch Ihre eigene Mandantenform.

LanceDB Embedded Mode ist das, was „SQLite für Vektorsuche” am nächsten kommt. Es läuft prozessintern, benötigt keinen Server und funktioniert in Lambda, Cloudflare Workers und Edge-Umgebungen. Das Lance-Spaltenformat macht den eingebetteten Betrieb in echtem Maßstab praktikabel.

Chroma ist am stärksten bei Entwicklung/Test und kleinen App-Bereitstellungen. Wenn Sie auf sehr große Korpora, Hochverfügbarkeit, datenträgerlastigen Betrieb oder erstklassige hybride Suche abzielen, evaluieren Sie einen produktionsorientierten Store, bevor Sie den Prototyp zur Infrastruktur befördern.

Vespa ist das, wonach Sie greifen, wenn Retrieval nur die Hälfte des Produkts ist. Es kombiniert lexikalischen Retrieval, Nächste-Nachbarn-Suche, Tensoren, Ranking-Ausdrücke, Gruppierung und Online-Serving. Diese Leistung ist real, aber ebenso die betriebliche und modellierungstechnische Komplexität. Es passt eher zu Such-/Empfehlungsteams als zu „semantische Suche zu meiner CRUD-App hinzufügen”.

ClickHouse gehört in die Diskussion, wenn Suche an Analytik gekoppelt ist. Wenn Ihre Quelle der Wahrheit Ereignisse, Logs, Traces oder Metriken sind, hält ClickHouse Vektordistanz, Filterung, Aggregation und ernsthafte Volltextindizierung in einer SQL-Engine. Keine zweckgebundene Vektordatenbank, aber oft die langweilig richtige Antwort für analytischen Retrieval.

Sparse Vectors sind, wie Sie BM25-qualitative Schlüsselwortsuche innerhalb eines Vektor-Index bekommen – ohne eine separate Volltext-Engine zu betreiben. Qdrant und Elasticsearch haben besonders ausgereifte Implementierungen hier. Wenn hybride Suche kritisch ist und eine Zwei-System-Architektur ein Ausschlusskriterium ist, ist die Unterstützung für Sparse Vectors das, wonach Sie suchen sollten.

Wahl, wenn Sie pgvector entwachsen sind

• SaaS-Produkt mit mandantenfähiger Isolierung → Turbopuffer
• Komplexe Metadatenfilterung in großem Maßstab → Qdrant
• Bereits auf Elastic/ELK-Stack → Elasticsearch mit DiskBBQ
• AWS-Shop, der Open-Source bevorzugt → OpenSearch
• Such-/Empfehlungsplattform mit ernsthaften Ranking-Anforderungen → Vespa
• Analytik, Observability, Log-/Ereignissuche → ClickHouse
• Milliardenmaßstab, On-Premises / selbst gehostet → Milvus
• Edge / Serverless / Multimodal → LanceDB
• Kleine JS-App, Docs-Site oder Edge-native Such-UX → Orama
• Null Ops, Kosten sind zweitrangig → Pinecone
• Multimodal-first (Bilder, Video, Audio) → Marqo
• Bereits auf MongoDB → Atlas Vector Search
• Bereits auf Postgres, brauche mehr Spielraum → Supabase Vector oder Neon (beide pgvector verwaltet, mit besserem Tooling)

Die eine Sache, die man nicht tun sollte

Verwenden Sie Vektorsuche nicht als unscharfe Textsuche für Dinge, die korrekte Antworten haben.

„Finde mir den Benutzer mit der E-Mail dan@example.com” ist kein Vektorsuchproblem. „Finde die Bestellung mit der ID ORD-12345” ist es auch nicht. Das Einbetten von ORD-12345 und die Suche per Kosinus-Ähnlichkeit wird etwas zurückgeben – aber es könnte falsch sein. Ein Identifikator hat eine korrekte Antwort. Eine approximative Übereinstimmung bei einem Identifikator ist ein Fehler.

Vektorsuche gibt das ähnlichste Element in Ihrem Datensatz zurück, selbst wenn nichts tatsächlich relevant ist. Sie weiß nicht, wann keine gute Antwort existiert. Das ist in Ordnung für verwandte Dokumente. Es ist ein ernstes Problem für die exakte Datensatzsuche, bei der eine selbstbewusste falsche Antwort schlimmer ist als ein leeres Ergebnis.

Gleiches gilt in die andere Richtung: Verwenden Sie FTS nicht für Abfragen, bei denen der Benutzer ein Konzept beschreibt. „Artikel über schwierige Entscheidungen unter Unsicherheit” enthält keine zuverlässigen Schlüsselwörter. FTS gibt entweder Rauschen oder nichts zurück. Verwenden Sie das richtige Werkzeug für die Abfrageform.

Das vollständige Bild

Die meisten Produktionssuchsysteme benötigen mehr als eine Ebene:

• pg_trgm für Namen, Tippfehler, Autovervollständigung
• FTS / pg_search für die keywordbasierte Prosasuche
• pgvector für semantische und konzeptionelle Abfragen
• RRF-Fusion für Oberflächen, bei denen Benutzer Abfragearten mischen
• Reguläre Indizes für exakte Identifikatoren, Filter und sortierte Listen

Dies sind keine konkurrierenden Werkzeuge. Sie sind komplementär. Ein gut gebautes Suchsystem wählt die richtige Ebene für jede Abfrageform – und wenn sich Abfrageformen überschneiden, führt es mehrere Ebenen aus und fusioniert die Ergebnisse.

Die Teams, die gute Suchfunktionen ausliefern, verstehen den gesamten Stack. Diejenigen, die das nicht tun, greifen zu einer Vektordatenbank, embedden alles und wundern sich, warum exakte Suchvorgänge manchmal den falschen Datensatz zurückgeben.