Vektor-Datenbank

Ein Embedding ist nur ein Array Fließkommazahlen. Tausend Embeddings sind eine kleine JSON-Datei. Eine Million Embeddings sind etwa 4 GB, und du willst trotzdem in Millisekunden den nächsten Nachbarn finden. Das ist die Domäne von Vektor-Datenbanken.

Was eine Vektor-DB können muss

• Speichern von hochdimensionalen Vektoren in großer Stückzahl
• Top-K-Nearest-Neighbor-Suche - gegeben ein Query-Vektor, finde die K ähnlichsten gespeicherten Vektoren, gemessen z. B. an Cosinus-Distanz
• Filtern auf Metadaten - „nur Chunks mit locale='de'", „nur Chunks aus Dokumenten von 2025"
• Indexierung, die das Ganze schnell macht - bei großem Korpus zwingend, sonst skaliert nichts

Die Optionen

Es gibt eigene Vektor-DBs (Qdrant, Weaviate, Pinecone, Milvus, Chroma) und Erweiterungen für vorhandene Datenbanken (pgvector für Postgres, Lucene-Plugins für Elasticsearch, Redis Vector). Beide Wege funktionieren.

Für dieses Projekt - und für viele kleinere Setups - ist pgvector die ehrlichste Wahl: Postgres steht ohnehin schon, das Schema-Management ist vertraut, und du kannst Embeddings in derselben Transaktion mit deinen Domain-Daten konsistent halten.

Bei zehntausend Chunks ist pgvector mit HNSW-Index spürbar schnell. Erst irgendwo bei vielen Millionen Vektoren oder bei sehr hoher Schreib-Last lohnt sich der Umstieg.

Was wir neben dem Vektor brauchen

Ein Chunk-Vektor allein ist nutzlos - nach der Suche willst du wissen:

• Aus welchem Dokument kam der Chunk? (document_id, slug, title)
• Aus welchem Abschnitt? Heading-Pfad, Seitenzahl, Position
• Welche Locale? Zur Filterung deutscher vs. englischer Antworten
• Welche Strategie? Damit man später Chunking-Strategien gegeneinander evaluieren kann

In unserem Schema sieht das so aus (vereinfacht):

rag_chunks       (id, document_id, chunk_index, strategy, content, metadata, content_tsv)
rag_embeddings   (id, chunk_id, model, vector_768, vector_1024, vector_384)
rag_documents    (id, slug, locale, title, doc_kind, source_path)

Drei Vektor-Spalten parallel - eine pro getestetem Modell, jeweils mit eigener Dimensionalität und eigenem HNSW-Index.

Frische und Updates

Wenn ein Dokument sich ändert, müssen seine Chunks und Embeddings ungültig werden. Praktisch heißt das: re-chunken, neu embedden, alte Zeilen löschen. Idempotente Seeder helfen - sie erkennen, was schon da ist, und ersetzen nur, was sich geändert hat. Genau das macht der rag-seeder Container in diesem Projekt.

Eine vollständige Update-Pipeline (Document-Hashing, Diffs, hot-reload) bleibt in v1 außen vor. Hier reicht: „Korpus committed → Seeder neu durchlaufen lassen".