RAG in Produktion: Vom PoC zum Enterprise-System
Foto von Zdeněk Macháček auf Unsplash
Der Sprung vom RAG-Prototyp zum produktiven System ist größer als viele erwarten. In diesem Artikel teile ich meine Erfahrungen aus dem Aufbau eines RAG-Systems für einen pharmazeutischen Fachverlag – mit über 135 Fachbüchern und etwa 2.000 Fachartikeln als Wissensbasis.
Die Ausgangssituation
Ein Fachverlag im pharmazeutischen Bereich stand vor einer klassischen Herausforderung: Jahrzehnte an wertvollem Fachwissen, verteilt über verschiedene Publikationsformate, sollten durch eine KI-gestützte Suche zugänglich gemacht werden.
Die Anforderungen:
- 135 Fachbücher (primär PDF)
- ~2.000 Fachartikel (XML, JSON, HTML)
- Viele komplexe Tabellen mit pharmazeutischen Daten
- Ziel: 5.000-10.000 Anfragen pro Tag
- Antwortzeit unter 15 Sekunden
Was als überschaubares Projekt begann, entwickelte sich zu einer Lektion in Enterprise-RAG-Architektur.
Architektur-Entscheidungen
Der Tech-Stack
Nach Evaluation verschiedener Optionen entschieden wir uns für:
| Komponente | Technologie | Begründung |
|---|---|---|
| Vector Store | Elasticsearch | Bestehende Expertise, Hybrid-Suche möglich |
| Embeddings | OpenAI | Qualität, einfache Integration |
| LLM | GPT-4 | Fachsprachliche Kompetenz |
| Infrastruktur | AWS (EC2, später managed) | Skalierbarkeit |
Die erste Architektur: Docker auf EC2
Unsere initiale Architektur sah so aus:
Das Problem: Die GPU-Instance für Embeddings lief permanent – auch wenn keine Dokumente verarbeitet wurden. Bei aktuellen GPU-Preisen ein erheblicher Kostenfaktor.
Die optimierte Architektur
Nach den ersten Monaten migrierten wir zu:
Die Vorteile:
- Elastic Cloud statt selbst gehosteter Elasticsearch: Weniger Ops-Aufwand, automatische Skalierung
- On-Demand Ingestion: Embedding-Pipeline läuft nur bei Bedarf, nicht 24/7
- OpenAI API für Embeddings: Keine eigene GPU-Infrastruktur nötig
Multi-Format-Verarbeitung: Die unterschätzte Komplexität
Das Format-Chaos
Unser Dokumentenkorpus bestand aus:
| Format | Quelle | Herausforderung |
|---|---|---|
| Fachbücher | Layout-Erkennung, Tabellen, Grafiken | |
| XML | Artikel-Export | Strukturierte aber tiefe Verschachtelung |
| JSON | API-Exports | Unterschiedliche Schemas |
| HTML | Web-Inhalte | Inkonsistente Strukturen |
Chunking-Strategie: One Size Fits None
Die wichtigste Erkenntnis: Unterschiedliche Inhaltstypen brauchen unterschiedliche Chunking-Strategien.
Für Fließtext (Bücher, Artikel):
Strategie: Semantisches Chunking
- Chunk-Größe: 500-800 Tokens
- Overlap: 100 Tokens
- Trennung an Absatzgrenzen
Für strukturierte Daten (XML, JSON):
Strategie: Strukturerhaltend
- Chunk an logischen Einheiten (Kapitel, Abschnitte)
- Metadaten als Kontext mitführen
- Hierarchie bewahren
Für Tabellen:
Strategie: Große Chunks
- Tabellen als Ganzes oder in logischen Teilen
- HTML-Format für Strukturerhalt
- Zusätzlicher Beschreibungstext für Kontext
Tabellen: Der unterschätzte Gegner
Das Problem
Pharmazeutische Fachliteratur strotzt vor Tabellen: Wirkstoff-Interaktionen, Dosierungstabellen, Laborwerte. Diese Tabellen enthalten oft die wertvollsten Informationen – aber sie sind für RAG-Systeme notorisch schwer zu handhaben.
Typische Probleme:
- PDF-Extraktion zerstört die Tabellenstruktur
- Zellinhalte werden falsch zugeordnet
- Spalten- und Zeilenbeziehungen gehen verloren
Unsere Lösung: LLM-gestützte Tabellenerkennung
Wir entwickelten einen mehrstufigen Prozess:
Schritt 1: Layout-Analyse Identifikation von Tabellenbereichen auf der Seite.
Schritt 2: LLM-Strukturierung Ein spezialisierter Prompt extrahiert die Tabellenstruktur:
Analysiere diese Tabelle und konvertiere sie in valides HTML.
Behalte alle Spalten- und Zeilenbeziehungen bei.
Füge eine kurze Beschreibung des Tabelleninhalts hinzu.
Schritt 3: Große Chunks Tabellen werden als große Chunks (bis 2.000 Tokens) gespeichert, um den Kontext zu erhalten.
Die Ergebnisse
| Metrik | Vor LLM-Extraktion | Nach LLM-Extraktion |
|---|---|---|
| Strukturerhalt | ~40% | ~90% |
| Korrekte Zellzuordnung | ~50% | ~85% |
| Retrievalqualität für Tabellenfragen | niedrig | hoch |
Lesson Learned: Die Investition in hochwertige Tabellen-Extraktion zahlt sich aus. Bei fachspezifischen Inhalten sind Tabellen oft die primäre Informationsquelle.
Latenz: Die zwei Welten
Das Latenz-Profil
Unsere Messungen zeigten ein interessantes Muster:
| Phase | Latenz | Anteil |
|---|---|---|
| Embedding der Anfrage | ~100ms | 1% |
| Vektorsuche | ~200ms | 2% |
| Reranking | ~700ms | 7% |
| LLM-Generierung | ~10.000ms | 90% |
Die Erkenntnis: 90% der Latenz entstehen beim LLM-Aufruf, nicht beim Retrieval.
Optimierungsstrategien
1. Streaming-Responses
Statt: Warten auf komplette Antwort (10+ Sekunden)
Besser: Streaming ab dem ersten Token (~500ms Time-to-First-Token)
2. Kontext-Optimierung
Weniger ist mehr:
- Top-3 statt Top-10 Dokumente
- Präzise Chunks statt langer Passagen
- Reduktion des Context Windows = schnellere Antwort
3. Caching-Strategien
- Embedding-Cache für häufige Anfragen
- Response-Cache für identische Queries
- Dokumenten-Snippets vorberechnen
Kostenoptimierung: Die harten Lektionen
Der Kostenschock
Nach dem ersten Produktionsmonat die ernüchternde Rechnung:
| Posten | Monatliche Kosten |
|---|---|
| GPU-Instance (24/7) | Signifikant |
| OpenAI API (Embeddings) | Moderat |
| OpenAI API (LLM) | Hoch |
| Elasticsearch | Moderat |
Die Optimierungen
1. Von 24/7 GPU zu On-Demand
Die größte Ersparnis: Ingestion-Pipeline nur bei Bedarf.
Vorher: GPU-Instance läuft permanent
Nachher: Lambda-Trigger bei neuen Dokumenten
Ersparnis: >70% der Compute-Kosten
2. Managed Services vs. Self-Hosted
| Aspekt | Self-Hosted | Managed |
|---|---|---|
| Initiale Kosten | Niedriger | Höher |
| Ops-Aufwand | Hoch | Minimal |
| Skalierung | Manuell | Automatisch |
| Gesamtkosten (1 Jahr) | Oft höher | Oft niedriger |
3. Embedding-Kosten reduzieren
- Batch-Processing für neue Dokumente
- Inkrementelle Updates statt vollständiger Re-Indexierung
- Embedding-Cache für häufige Anfragen
Monitoring: Was wirklich zählt
Die wichtigsten Metriken
Qualitätsmetriken:
- Retrieval-Präzision (relevante Dokumente in Top-K?)
- Answer-Relevanz (beantwortet die Antwort die Frage?)
- Halluzinationsrate (werden nicht belegte Fakten genannt?)
Performance-Metriken:
- Time-to-First-Token (User Experience)
- End-to-End-Latenz
- Throughput (Anfragen pro Sekunde)
Business-Metriken:
- Nutzerzufriedenheit
- Erfolgreiche Antworten pro Tag
- Eskalationen an menschliche Experten
Alerting-Setup
Kritisch:
- Latenz > 20 Sekunden
- Fehlerrate > 5%
- Elasticsearch nicht erreichbar
Warnung:
- Latenz > 15 Sekunden
- Retrieval-Qualität sinkt
- Ungewöhnliche Anfragemuster
Lessons Learned
Was wir anders machen würden
1. Früher auf Managed Services setzen Der Self-Hosted-Ansatz war lehrreich, aber der Ops-Aufwand stand in keinem Verhältnis zum Nutzen.
2. Mehr Zeit für Dokumentenaufbereitung Die Qualität der Eingabedaten bestimmt maßgeblich die Qualität der Antworten. Investition hier zahlt sich doppelt aus.
3. Tabellen von Anfang an priorisieren Wir haben Tabellen zunächst als "Sonderfall" behandelt. Sie waren aber für viele Anwendungsfälle der Kerninhalt.
4. Realistische Latenz-Erwartungen setzen 10+ Sekunden Antwortzeit sind bei komplexen LLM-Generierungen normal. Lieber Streaming implementieren als unrealistische Optimierungen versuchen.
Was gut funktioniert hat
- Hybrid-Suche (Vektor + Keyword) verbesserte die Retrieval-Qualität signifikant
- Chunk-Overlap reduzierte Kontextverlust an Chunk-Grenzen
- Strenge Quellenangaben erhöhten das Nutzervertrauen
- Feedback-Loop mit Domain-Experten verbesserte kontinuierlich die Qualität
Fazit
Der Weg vom RAG-PoC zum Produktionssystem erfordert Entscheidungen in vielen Dimensionen: Infrastruktur, Datenverarbeitung, Kostenoptimierung und Monitoring. Die wichtigste Erkenntnis: Es gibt keine One-Size-Fits-All-Lösung. Jeder Dokumentenkorpus, jede Domäne und jede Nutzerbasis bringt eigene Herausforderungen mit.
Was zählt, ist ein iterativer Ansatz: Starten Sie mit einer soliden Grundarchitektur, messen Sie konsequent, und optimieren Sie dort, wo es den größten Impact hat. Und unterschätzen Sie nie die Komplexität der Dokumentenaufbereitung – sie ist oft der Schlüssel zum Erfolg.
Sie planen ein RAG-System für Ihre Fachinhalte? Kontaktieren Sie mich für eine unverbindliche Beratung zu Architektur und Implementierung.