Vector-Datenbank-Pipelines mit Claude aufsetzen

1. Warum die Pipeline wichtiger ist als die Datenbank-Wahl

Viele Teams starten die Planung mit der Frage, welche Vector-Datenbank eingesetzt werden soll, und übersehen dabei, dass Embedding-Modell und Chunking-Strategie einen deutlich größeren Einfluss auf die Trefferqualität haben als die konkrete Datenbank. Eine schlecht chunkierte Dokumentensammlung liefert in jeder Datenbank schwache Ergebnisse, während eine sauber aufgebaute Pipeline auch in einer einfachen Konfiguration solide Treffer erzielt.

Die Reihenfolge sollte deshalb umgekehrt sein: zuerst Embedding-Modell und Chunking-Strategie für die konkreten Dokumente festlegen, danach die Datenbank passend zu Skalierung, Hosting-Anforderungen und Budget wählen. Claude eignet sich gut, um diese Reihenfolge frühzeitig einzuhalten, weil sich Chunking-Entscheidungen anhand echter Beispieldokumente konkret durchsprechen lassen, bevor Infrastruktur festgelegt wird.

In der Praxis zeigt sich dieser Effekt besonders deutlich bei einem nachträglichen Datenbank-Wechsel: Wird eine bestehende Pipeline von pgvector zu Pinecone oder umgekehrt migriert, bleibt die Trefferqualität weitgehend erhalten, solange Embedding-Modell und Chunking unverändert bleiben. Wird dagegen nur die Datenbank optimiert, ohne bestehende Chunking-Fehler zu beheben, bleibt die Trefferqualität spürbar hinter dem technisch möglichen Niveau zurück.

2. Embedding-Modell auswählen

Die Wahl des Embedding-Modells hängt von Sprache, Domäne und Kosten pro eingebettetem Token ab. Mehrsprachige Dokumentensammlungen brauchen ein Modell mit nachgewiesener mehrsprachiger Qualität, technische oder juristische Fachtexte profitieren von Modellen, die auf entsprechenden Korpora trainiert wurden. Die Dimensionalität des Embeddings beeinflusst zusätzlich Speicherbedarf und Suchgeschwindigkeit: höhere Dimensionen liefern oft feinere Unterscheidung, kosten aber mehr Speicherplatz und Rechenzeit bei der Suche.

Claude lässt sich gut nutzen, um anhand einer Stichprobe der eigenen Dokumente eine begründete Vorauswahl zu treffen: Welche Fachbegriffe kommen häufig vor, wie stark unterscheiden sich Dokumente inhaltlich, und wie wichtig ist mehrsprachige Abdeckung. Diese Analyse ersetzt kein Benchmark mit echten Testanfragen, verkürzt aber die Zahl der Kandidaten, die überhaupt getestet werden müssen.

Prompt an Claude zur Embedding-Modell-Vorauswahl:

Hier sind 5 Beispieldokumente aus unserer technischen Dokumentation
(deutsch, teils englische Fachbegriffe): <Beispiele>

Welche Embedding-Modell-Kategorien (allgemein vs. domänenspezifisch,
Dimensionsgröße) passen voraussichtlich am besten, und welche
3 Kandidaten sollten wir mit einem echten Retrieval-Benchmark
gegeneinander testen?

3. Chunking-Strategien für lange Dokumente durchdenken lassen

Chunking entscheidet darüber, ob ein Retrieval-Treffer den relevanten Kontext vollständig enthält oder mittendrin abgeschnitten ist. Naives Chunking nach fester Zeichenzahl ignoriert Absatz- und Kapitelgrenzen und zerreißt regelmäßig zusammengehörige Informationen. Semantisches Chunking orientiert sich stattdessen an inhaltlichen Grenzen wie Überschriften, Absätzen oder Listenstrukturen und hält zusammengehörige Aussagen beieinander.

Claude kann anhand eines konkreten Beispieldokuments vorschlagen, an welchen Stellen inhaltliche Brüche liegen und wo ein Chunk-Übergang wenig Schaden anrichtet. Für strukturierte Dokumente wie API-Dokumentation oder juristische Texte mit nummerierten Abschnitten liefert diese Analyse oft brauchbare Chunk-Grenzen, die weit über eine feste Zeichenzahl hinausgehen.

# Chunking mit Ueberlapp, Grenzen anhand von Ueberschriften
# (Grenzen wurden vorab mit Claude anhand von Beispieldokumenten geklärt)
import re

def chunk_by_headings(text: str, max_tokens: int = 400, overlap: int = 50):
    sections = re.split(r"\n(?=#{1,3}\s)", text)
    chunks = []
    for section in sections:
        words = section.split()
        if len(words) <= max_tokens:
            chunks.append(section.strip())
            continue
        start = 0
        while start < len(words):
            end = start + max_tokens
            chunks.append(" ".join(words[start:end]))
            start = end - overlap
    return [c for c in chunks if c]

4. Typische Fallstricke: zu große oder zu kleine Chunks

Zu große Chunks enthalten oft mehrere unterschiedliche Themen gleichzeitig, wodurch das Embedding zu einem verwaschenen Mittelwert wird, der auf keine der enthaltenen Fragen mehr präzise passt. Die Trefferquote sinkt, weil semantisch relevante Chunks bei spezifischen Anfragen nicht mehr weit genug oben im Ranking landen. Ein häufiges Symptom: Die Suche findet grundsätzlich passende Dokumente, aber die konkrete Antwort fehlt im zurückgegebenen Ausschnitt.

Zu kleine Chunks zerreißen dagegen zusammengehörige Informationen, etwa eine Bedingung und die dazugehörige Ausnahme in unterschiedlichen Chunks. Claude beantwortet die Anfrage dann scheinbar korrekt, aber unvollständig, weil der relevante Zusatzkontext im Retrieval fehlt. In der Praxis hat sich eine Chunk-Größe von 200 bis 500 Tokens mit einem Überlapp von 10 bis 20 Prozent für die meisten Fließtext-Dokumente bewährt, mit spürbaren Ausnahmen bei tabellarischen oder stark strukturierten Inhalten.

5. pgvector-Setup mit Claude-generiertem Code

Für Teams, die bereits PostgreSQL im Einsatz haben, ist pgvector oft die pragmatischste Wahl, da keine zusätzliche Infrastruktur nötig wird. Claude generiert zuverlässig das Grundgerüst aus Extension, Tabellenschema mit passendem Index und einer Beispielabfrage, die per Kosinus-Distanz die nächsten Nachbarn ermittelt.

Wichtig bei der Prompt-Formulierung ist, die erwartete Datenmenge und das Zielverhalten mitzugeben, etwa ob ein exakter oder approximativer Index gebraucht wird, denn davon hängt ab, ob Claude einen IVFFlat- oder HNSW-Index vorschlägt und wie die entsprechenden Parameter gewählt werden.

-- pgvector: Extension, Schema und HNSW-Index
CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE document_chunks (
    id BIGSERIAL PRIMARY KEY,
    document_id BIGINT NOT NULL,
    chunk_text TEXT NOT NULL,
    metadata JSONB DEFAULT '{}',
    embedding VECTOR(1536) NOT NULL
);

CREATE INDEX ON document_chunks
    USING hnsw (embedding vector_cosine_ops)
    WITH (m = 16, ef_construction = 64);

-- Nächste Nachbarn zu einem Query-Embedding finden
SELECT id, chunk_text, 1 - (embedding <=> $1) AS similarity
FROM document_chunks
WHERE metadata->>'status' = 'active'
ORDER BY embedding <=> $1
LIMIT 8;

6. Pinecone-Setup: verwaltete Infrastruktur ohne eigenen Betrieb

Pinecone eignet sich, wenn der Betrieb einer eigenen Datenbank vermieden werden soll und Skalierung auf mehrere Millionen Vektoren absehbar ist. Claude generiert das Client-Setup inklusive Index-Erstellung mit passender Metrik und Namespace-Struktur, was besonders bei Mandanten-getrennten Anwendungen relevant wird.

Ein Punkt, den Claude bei entsprechender Nachfrage zuverlässig mitliefert: die Trennung zwischen Namespaces für Mandantenisolation versus Metadatenfiltern für inhaltliche Filterung innerhalb eines Mandanten, da beide Mechanismen leicht verwechselt werden und unterschiedliche Kostenimplikationen haben.

from pinecone import Pinecone, ServerlessSpec

pc = Pinecone(api_key="PINECONE_API_KEY")

pc.create_index(
    name="support-docs",
    dimension=1536,
    metric="cosine",
    spec=ServerlessSpec(cloud="aws", region="eu-central-1"),
)

index = pc.Index("support-docs")

index.upsert(
    vectors=[
        {"id": "chunk-1", "values": embedding, "metadata": {
            "document_id": "42", "status": "active", "product": "checkout"
        }}
    ],
    namespace="tenant-acme",
)

results = index.query(
    vector=query_embedding,
    top_k=8,
    namespace="tenant-acme",
    filter={"status": {"$eq": "active"}},
)

7. Weaviate-Setup: Hybrid Search als eingebautes Feature

Weaviate kombiniert Vektorsuche und Schlüsselwortsuche in einem System, was besonders bei Anfragen mit exakten Produktnamen oder Fehlercodes wertvoll ist, die eine reine semantische Suche gelegentlich übersieht. Claude generiert die Schema-Definition inklusive Vectorizer-Konfiguration und die passende GraphQL- oder Python-Abfrage für Hybrid Search zuverlässig.

Bei der Prompt-Formulierung lohnt es sich, explizit nach dem Alpha-Parameter für die Gewichtung zwischen Vektor- und Schlüsselwortsuche zu fragen, da dieser Wert stark vom jeweiligen Anwendungsfall abhängt und in generischen Beispielen oft nur mit einem willkürlichen Standardwert belegt wird.

import weaviate
import weaviate.classes as wvc

client = weaviate.connect_to_local()

client.collections.create(
    name="DocumentChunk",
    vectorizer_config=wvc.config.Configure.Vectorizer.text2vec_openai(),
    properties=[
        wvc.config.Property(name="text", data_type=wvc.config.DataType.TEXT),
        wvc.config.Property(name="product", data_type=wvc.config.DataType.TEXT),
    ],
)

collection = client.collections.get("DocumentChunk")
results = collection.query.hybrid(
    query="Zahlung schlägt fehl mit Fehlercode 402",
    alpha=0.6,  # Gewicht Richtung Vektorsuche, 0 = reine Keyword-Suche
    limit=8,
)

8. Metadaten-Filterung und Hybrid Search kombinieren

Reine Vektorähnlichkeit reicht in produktiven Systemen selten aus. Metadatenfilter, etwa nach Produktbereich, Sprache oder Veröffentlichungsdatum, schränken den Suchraum vor der eigentlichen Ähnlichkeitsberechnung ein und verhindern, dass veraltete oder irrelevante Dokumente überhaupt in Betracht gezogen werden. Diese Filter sollten so früh wie möglich in der Abfrage greifen, nicht erst als Nachbearbeitung der Ergebnisliste.

Für Anwendungsfälle mit exakten Begriffen, etwa Fehlercodes, SKU-Nummern oder Versionsnummern, liefert eine Kombination aus Vektorsuche und Schlüsselwortsuche zuverlässigere Ergebnisse als reine semantische Suche, weil exakte Zeichenketten im Embedding-Raum nicht immer nah beieinanderliegen.

9. Monitoring und Reindexierung im laufenden Betrieb

Eine Vector-Datenbank-Pipeline ist kein einmaliges Setup, sondern braucht laufendes Monitoring: Trefferqualität über Stichproben, Latenz der Suche unter steigender Datenmenge, und die Erkennung veralteter Chunks, deren Quelldokument sich geändert oder gar nicht mehr existiert. Ohne systematische Reindexierung sammeln sich über Monate hinweg tote oder widersprüchliche Einträge an.

Claude eignet sich gut, um ein Reindexierungs-Skript samt Erkennung verwaister Chunks zu entwerfen, etwa durch Abgleich der in der Vektordatenbank gespeicherten Dokument-IDs gegen die aktuelle Quelldatenbank. Ergänzend lohnt sich ein regelmäßiger Stichprobentest mit realen Nutzeranfragen, um schleichende Qualitätsverluste frühzeitig zu erkennen, bevor sie in Supportanfragen sichtbar werden.

10. Zusammenfassung

11. FAQ: Vector-Datenbank-Pipelines: Das Wichtigste auf einen Blick