Production Deployment

Eine RAG-Pipeline im Notebook ist ein Prototyp. Für Production brauchen Sie Skalierung, Index-Management, inkrementelle Updates, Cost Optimization und Disaster Recovery.

Vektor-Datenbank skalieren

Horizontal Scaling

Sizing Guide

Vektoren × Dimensionen × 4 Bytes = RAM-Bedarf (Minimum)

Beispiel:
1M Vektoren × 1536 Dimensionen × 4 Bytes = ~6 GB RAM
+ HNSW-Index-Overhead (~2x) = ~12 GB RAM
+ Safety-Margin (1.5x) = ~18 GB RAM empfohlen

Index-Management

Index-Typen auswählen

Index-Tuning

# HNSW-Parameter
hnsw_config = {
    "m": 16,              # Verbindungen pro Node (8-64)
    "ef_construction": 200, # Build-Qualität (100-500)
    "ef_search": 100       # Query-Qualität (50-500)
}
# Höhere Werte = bessere Qualität, aber langsamer und mehr RAM

Inkrementelle Updates

Neue Dokumente müssen ohne Downtime in den Index integriert werden:

class IncrementalIndexer:
    def __init__(self, vectorstore, embedder):
        self.vectorstore = vectorstore
        self.embedder = embedder
        self.processed_docs = set()

    async def process_new_documents(self, documents: list):
        new_docs = [d for d in documents if d.id not in self.processed_docs]
        if not new_docs:
            return

        # Chunks erstellen
        chunks = self.splitter.split_documents(new_docs)

        # In Batches verarbeiten (vermeidet Memory-Spikes)
        for batch in chunk_list(chunks, batch_size=100):
            await self.vectorstore.aadd_documents(batch)

        self.processed_docs.update(d.id for d in new_docs)

    async def delete_outdated(self, doc_ids: list[str]):
        for doc_id in doc_ids:
            await self.vectorstore.adelete(filter={"source_id": doc_id})
            self.processed_docs.discard(doc_id)

Update-Strategien

Cost Optimization

Embedding-Kosten senken

Strategie                          Einsparung
─────────────────────────────────────────────
Kleineres Modell (3-small statt 3-large)   ~60%
Caching identischer Dokumente              ~20-40%
Batch-Processing statt Einzel-Calls        ~10%
Open-Source-Modell (self-hosted)            ~80-90%

Inference-Kosten optimieren

• Smaller Context: Nur Top-3 statt Top-10 Chunks an LLM
• Model Routing: Einfache Fragen → günstigeres Modell
• Response Caching: Häufige Fragen cachen
• Streaming: Reduziert Time-to-First-Token

Monitoring

Metriken

Disaster Recovery

Backup-Strategie

• Vector Store: Tägliche Snapshots, wöchentliche Full-Backups
• Raw Documents: Immer eine Kopie der Quelldokumente behalten
• Index: Re-Build-Fähigkeit aus Raw Documents sicherstellen
• Config: Embedding-Modell-Version, Chunk-Parameter dokumentieren

Recovery-Verfahren

1. Vector Store aus Snapshot wiederherstellen (schnell)
2. Falls kein Snapshot: Re-Embed aus Raw Documents (Stunden)
3. Validation: Golden Dataset gegen wiederhergestellte Pipeline testen
4. Monitoring: Metriken in den ersten 24h engmaschig überwachen

Praxis-Tipp: Planen Sie das Blue-Green-Deployment von Anfang an ein. Es ermöglicht Index-Updates und Modell-Wechsel ohne Downtime. Behalten Sie immer die Quelldokumente — ein Vektor-Index ist reproduzierbar, die Originaldaten nicht.