Production RAG: Retrieval-Qualität geht vor Kosten

RAG-Systeme durchlaufen nach dem Go-live zwei mögliche Schicksale: Entweder werden sie innerhalb von 3 Wochen wegen Halluzinationen abgeschaltet, oder die Retrieval-Qualität wird auf 90+ F1 optimiert und das System wird zum geschäftskritischen Backbone. Der Unterschied liegt in der Embedding-Auswahl, der Chunking-Strategie und dem Evaluations-Setup. Cost-Optimierung ist ein sekundäres Thema – wenn du nicht zuerst das richtige Dokument holen kannst, wird ein billiges Modell teure Fehler produzieren.

Embedding-Modell: Größe ist nicht alles, Domain-Fit entscheidet

Die erste Intuition beim Embedding ist häufig „größeres Modell = bessere Embeddings". text-embedding-3-large (3072 Dimensionen) ist nicht automatisch besser als text-embedding-3-small (1536 Dimensionen) in jeder Situation. MTEB-Benchmarks messen auf generellen Corpora – wenn deine Domain Finanzen, Medizin oder E-Commerce ist, sind diese Scores irreführend.

In Production haben wir gesehen: Ein 768-dimensionales domain-spezifisches Modell (sentence-transformers/all-mpnet-base-v2, fein-abgestimmt auf unsere Daten) übertraf ein 3072-dimensionales generisches Modell um 12 % besseren Recall@10. Der Grund ist simpel: Der Embedding-Space kennt nicht die Domain-Jargon. „Conversion Rate Optimization" und „CRO" haben im generischen Modell einen semantischen Abstand von 0.68, im domain-tuned Modell von 0.91.

Die Größen-Tradeoffs sind klar: 3072 Dimensionen führen zu einem Index von 4,2 GB, 768 Dimensionen zu 1,1 GB. Query-Latenz liegt bei 47 ms bzw. 18 ms (FAISS HNSW, m=16). Wenn der Recall-Verlust unter 5 % liegt, gewinnt das kleinere Modell – sowohl bei Kosten als auch bei Speed. Diese Entscheidung ohne Messung zu treffen ist Guesswork statt Engineering.

Fine-Tuning: Wann es notwendig ist

Embedding Fine-Tuning ist in zwei Fällen obligatorisch: (1) Die Domain-Vokabeln sind extrem spezifisch (medizinische Begriffe, Krypto-Token-Namen), (2) Die Query-Dokument-Verteilung ist asymmetrisch (kurze Fragen, lange Dokumente). OpenAI Embeddings unterstützen kein Fine-Tuning; du brauchst sentence-transformers oder Cohere embed-v3. Starten Sie mit 500–1000 gelabelten Paaren – mehr bringt marginale Gewinne.

Chunking: Es geht um semantische Integrität, nicht Größe

„Chunk-Größe 512 Token ist optimal" – diese Regel existiert nicht. Wir haben 3 Strategien verglichen: (1) Fixed 512 Token, (2) Markdown-Header-basiert (Schnitte bei H2/H3), (3) Semantisches Chunking (LLM liest Paragraph-Kontext, bricht bei semantischen Übergängen). Ergebnis: Markdown-basiertes Chunking lieferte 18 % besseres NDCG@5, war aber 2,3x langsamer beim Index-Build.

Das Problem mit Fixed Chunking: Es trennt Sätze mitten im Gedanken. Der Satz „Wenn Sie Server-Side Tracking mit First-Party-Datenverwaltung integrieren..." wird bei Token 510 abgeschnitten; der nächste Chunk beginnt mit „...integrieren, verbessert sich die Zuordnungsgenauigkeit erheblich" – der Kontext ist verloren. Der Retriever findet diesen Chunk vielleicht bei einer „Attribution"-Anfrage, aber ohne Kontext kann das LLM keine sinnvolle Antwort generieren. Die Halluzination beginnt hier.

Semantisches Chunking (gpt-4o-mini fragt „springt dieser Paragraph zu einer neuen Idee?") liefert bessere Ergebnisse, ist aber teuer: Das Chunking einer 10.000-Seiten-Wissensbasis kostete $47 (0,15 $/1M Token Input). Der Tradeoff: Index-Build ist eine einmalige Kosten, Retrieval-Qualität ist kontinuierlicher Wert. Wir wählten Semantic, aber wenn deine Dokumente wöchentlich aktualisiert werden, könntest du zu Fixed Chunking zurückkehren.

Overlap-Strategie

Überlappung zwischen Chunks verbessert Recall – vergrößert aber den Index um Faktor 1.4–1.8. Mit 50-Token-Overlap sahen wir 6 % Recall-Gewinn (Recall@10: 0.78 → 0.83). Du kannst Overlap nur für lange Dokumente (>2000 Token) aktivieren und bei kurzen Inhalten deaktivieren – conditional Overlap-Logik.

Eval-Setup: Von Offline-Metriken zu Online A/B

Ohne Eval-Pipeline vor Production-Launch ist das Risiko enorm. „Das LLM-Output sieht gut aus" reicht nicht – Retrieval (Precision/Recall) und LLM Faktualität müssen separat gemessen werden.

Zwei Schichten:

1. Retrieval-Layer: Precision@k, Recall@k, NDCG@k, MRR. Ground Truth: manuell etikett Query-Dokument-Paare (320 in unserem Fall). Die context_precision-Metrik der Ragas-Bibliothek läuft LLM-frei und ermöglicht schnelle Iteration.
2. Generation-Layer: Faktische Konsistenz (Entailment zwischen Dokument und Output), Halluzinations-Rate (LLM spricht über Dinge außerhalb der Dokumente), Citation Accuracy (Quellenangaben des LLM). Hierfür nutzen wir LLM-as-Judge – gpt-4o wird gefragt, „basiert diese Antwort auf den Dokumenten?" Agreement-Rate: 0.89 (vs. Human Eval).

Offline Eval läuft täglich automatisiert (CI/CD-Pipeline). Wenn du ein neues Chunking-Strategie, Embedding-Modell oder Reranker testest, müssen diese Metriken vor dem Commit grün sein. Online A/B-Test ist anders: 10 % Traffic erhält die neue RAG-Version, du misst User Feedback + Session-Metriken (Task Completion, Query-Reformulation Rate). Wenn Offline NDCG 0.02 steigt, bedeutet das nicht unbedingt bessere Task Completion – dann skippen wir das Deployment.

LLM-as-Judge Zuverlässigkeit

Vertraue LLM-as-Judge nicht blind. GPT-4o markierte sich selbst in 6 % der Fälle als halluzinierend (False Positive), verpasste aber in 4 % echte Halluzinationen (False Negative). Die Lösung: Bei kritischen Use Cases Human-in-the-Loop Eval – 5 % Sample manuell überprüfen, Calibrations-Score des Judge auf dieser Subset berechnen. Wenn Calibration <0.85, revise den Judge-Prompt.

Reranker: Die Macht des zweiten Passes

First Retrieval holt 20–50 Chunks (Recall-fokussiert), Reranker reduziert auf 3–5 (Precision-fokussiert). Mit Cohere rerank-v3 sahen wir 14 % Precision-Gewinn (P@5: 0.68 → 0.78). Kosten: $2 pro 1M reranked Token (10x teurer als Embedding), aber 50 statt 5 Chunks ins LLM-Context zu geben spart Token und senkt Halluzinations-Risiko.

Der Reranker-Tradeoff ist Latenz: Embedding-Search 18 ms, mit Rerank 95 ms. Mit async Pipeline ist das akzeptabel – Retrieval + Rerank im Background, während LLM-Response streamt, gesamte Latenz 400–500 ms. Synchron würde das UX zerstören.

RAG-Systeme ohne Reranker setzen voraus, dass „die Top-k Embedding-Results korrekt sind". Das stimmt nur bei hohem Lexical-Overlap zwischen Query und Chunk. Bei semantischen Queries wie „Wie verbinde ich First-Party-Daten-Architektur mit Server-Side-Messung?" holt Embedding 4 irrelevante Chunks in die Top 10. Der Reranker nutzt Query-Dokument Cross-Attention um diesen Noise zu bereinigen. Production RAG ohne Reranker ist risikant – Citation Accuracy fällt 18 %.

Hybrid Search: BM25 + Embedding

Embedding-only Retrieval scheitert in zwei Szenarien: (1) Exact-Match-Suchen (Brand-Namen, Produkt-Codes), (2) Rare Terms (Begriffe, die selten im Embedding-Space vorkommen). BM25 (Keyword-basiert) schließt diese Lücke. In Weaviate oder Qdrant: Hybrid Search mit 0.7 Embedding-Weight + 0.3 BM25-Weight. Recall@10: Embedding-only 0.76, Hybrid 0.83.

Der BM25-Index ist 5–8x kleiner als der Embedding-Index (Inverted Index Struktur). Keine zusätzliche Latenz (parallel). Die einzige Kosten des Hybrid-Setups: Query-Planning – welche Gewichtung für welchen Query-Typ? Das findest du per A/B-Test. Bei uns: Allgemeine Queries 0.8 Embedding, Brand/Produkt-Mentions 0.5 Embedding.

Monitoring in Production

60 % eines RAG-Deployments ist Monitoring – um zu verhindern, dass sich das System still verschlechtert. Metriken, die wir verfolgen:

• Retrieval Coverage: Anteil der Queries, für die Dokumente gefunden werden (Target >95 %)
• Avg Context Relevance: Wieviel % der LLM-Chunks sind tatsächlich relevant (Target >0.8)
• Hallucination Rate: Wie oft spricht das LLM über Dinge außerhalb der Dokumente (Target <5 %)
• Latency P95: 95 % der Queries beendet in (Target <800 ms)
• Cost per Query: Embedding + Rerank + LLM (Target <$0.02)

Diese Metriken pushen wir an Datadog; Threshold-Überschreitung triggert Slack Alert. Wenn Retrieval Coverage 2 Tage unter 92 % fällt, gibt es Lücken in der Knowledge Base – Content-Team wird aktiv. Hallucination Rate steigt? LLM-Prompt oder Chunk-Größe revieren. Latency Spike? Vector Database Sharding prüfen.

Daten-Analytics & Insights-Engineering – Korreliere RAG-Metriken mit Business Outcomes. Verbessert sich die User Satisfaction, wenn Retrieval Kalität steigt, oder steht nur die technische Metrik? Das messen wir per Korrelations-Analyse.

Cost vs. Qualität Balancieren

Production RAG, 1M Queries/Monat, durchschnittlich 3 Chunks retrieved, gpt-4o-mini Generation: ~$420/Monat (Embedding $80, Rerank $40, LLM $300). Ohne Reranker sinkt das auf $380, aber Hallucination-Rate springt von 5 % auf 11 % – das bedeutet mehr Support-Tickets, indirekte Kosten >$600.

Die richtige Way, Kosten zu senken: (1) Cache-Layer (gleiche Query in 24h? Cache-Treffer, 23 % Queries sind Duplikate), (2) Kleineres Embedding-Modell (domain-tuned 768 Dim), (3) Async Rerank (für non-kritische Queries Rerank skippen). So sinkt es auf $280, Qualitätsverlust <2 %.

Falsche Ansätze: Embedding durch Keyword-Search ersetzen, LLM durch Rule-basierte Templates. Das ergibt kein „echtes" System – Retrieval Precision fällt unter 40 %. Cost-Optimierung darf Retrieval-Qualität nicht sabotieren.

RAG in Production ist mehr als Modell-Auswahl – es braucht Eval-Disziplin, Monitoring und Iteration. Du kannst die Embedding-Dimension senken und Latenz gewinnen, aber wenn Recall leidet, halluziniert das LLM und verliert User-Vertrauen. Optimiere zuerst Retrieval-Qualität auf 0.85+ F1, dann kümmere dich um Kosten. Sonst betreibst du nur eine teure Halluzinations-Maschine.