RAG-System entwickeln: Vom PoC in Production in 8 Wochen

Ein RAG-Prototyp ist an einem Tag gebaut. Ein RAG-System, dem Kollegen echte Fragen anvertrauen und dessen Antworten sie gegenüber Kunden vertreten, dauert acht Wochen. Der Unterschied liegt nicht in einer besseren Bibliothek, er liegt in vier Phasen, die im Prototyp bewusst übersprungen werden dürfen und im Produktionssystem nicht.

Dieser Artikel beschreibt jede Phase mit realistischem Aufwand, typischen Stolpersteinen und dem Ergebnis, das am Phasenende vorhanden sein muss. Aus laufender RAG-Entwicklungspraxis für DACH-Mittelstand-Kunden.

Phase 1: Datengrundlage und Discovery (Woche 1–2)

Was in dieser Phase passiert, entscheidet zu 60 % über den Gesamterfolg.

Aktivitäten:

• Vollständige Inventur der zu ingestierenden Datenquellen: Format, Volumen, Aktualität, Zugriffsrechte, PII-Anteil
• Interviews mit den späteren Nutzergruppen: welche Fragen stellen sie heute wem, wie oft, mit welchem Ergebnis?
• Datenzugriff technisch klären: SharePoint-API, Confluence-Export, CRM-Datenbank-Zugang, ggf. neue Rechtsgrundlagen dokumentieren
• 20–30 realistische Testfragen mit erwarteten Antworten sammeln, die spätere Evaluationsgrundlage

Aufwand: 4–8 Personentage über 2 Wochen, verteilt zwischen technischem Lead, fachlichem Owner und ausgewählten Nutzern.

Typischer Stolperstein: Der Datenzugriff ist unterschätzt. In 4 von 5 Projekten kostet die reine Authentifizierung zu einer bestehenden Enterprise-Suite mehr Zeit als die eigentliche Ingestion-Pipeline.

Ergebnis: Ein Dokument mit vier Antworten: Wieviel Daten kommen tatsächlich rein, welche Nutzer stellen welche Fragen, was ist die Compliance-Baseline, und ein 20–30-Frage-Evaluationsset.

Phase 2: Pipeline-Architektur und Ingestion (Woche 3–4)

Jetzt wird technisch gearbeitet. Der Prototyp aus Phase 1 (falls einer existiert) wird durch eine produktionsreife Struktur ersetzt.

Aktivitäten:

• Ingestion-Pipeline: Format-Konverter (PDF, DOCX, HTML), Chunking-Strategie, Metadaten-Extraktion, PII-Filter
• Embedding-Modell auswählen und trainieren: OpenAI text-embedding-3-large, BGE-M3, oder E5-mistral je nach Sprache und Compliance
• Vector-DB einrichten: pgvector, Qdrant oder Weaviate, siehe Vector-DB-Auswahl-Guide
• Metadaten-Schema definieren: welche Filter braucht der Retrieval-Layer (Berechtigungsstufe, Dokumententyp, Zeitstempel, Sprache)?
• Backup, Reindexierung, Versionierung von Anfang an einplanen

Aufwand: 8–12 Personentage. Ein Senior-Engineer + fachlicher Owner für Rückfragen.

Typischer Stolperstein: Chunking-Strategie. Zu grobe Chunks (2000+ Tokens) verwässern das Retrieval; zu feine (200 Tokens) verlieren Kontext. Für die meisten Setups sind 500–800 Tokens mit 100 Tokens Overlap ein tragfähiger Startpunkt, aber die richtige Größe hängt vom Dokumententyp ab und muss in Phase 3 nachjustiert werden.

Ergebnis: Eine vollständig laufende Ingestion, die alle Datenquellen aus Phase 1 verarbeitet und in der Vector-DB abgelegt hat. Erste manuelle Retrieval-Tests bestätigen die Grundfunktion.

Phase 3: Retrieval-Qualität und Evaluation (Woche 5–6)

Die schwierigste Phase. Retrieval-Qualität ist der Ort, an dem RAG-Systeme wirklich gut oder wirklich schlecht werden.

Aktivitäten:

• Retrieval-Baseline messen: für jede der 20–30 Testfragen aus Phase 1, wie viele der Top-5-Ergebnisse sind wirklich relevant?
• Optimierungen ausprobieren und messen:
• Query-Expansion (LLM formuliert die Anfrage neu, mehrfach)
• Hybrid-Search (dense + sparse retrieval kombinieren)
• Reranking (kleines Cross-Encoder-Modell über die Top-20 Ergebnisse)
• Chunking-Größe anpassen
• Metadaten-Filter nutzen
• Groundedness-Check einbauen: verifiziert das generierte Antwort tatsächlich aus den Retrieval-Ergebnissen? Halluzinationen ohne Belegquelle werden zurückgewiesen
• Evaluations-Harness aufbauen, die bei jeder Änderung die 20–30 Testfragen automatisch durchlaufen und Regressionen erkennen lässt

Aufwand: 10–14 Personentage. Der schwierigste Sprint. Erfordert Iteration und Geduld.

Typischer Stolperstein: Die erste Retrieval-Qualität ist bei 50–70 %, jeder erwartet, dass es reicht, um live zu gehen. Aber 70 % Trefferrate heißt: 3 von 10 Nutzerfragen bekommen keine oder falsche Antwort. Das ist unter der Vertrauensschwelle. Ziel: >90 % Trefferrate auf den Testfragen und ein Refusal-Mechanismus für die restlichen 10 %.

Ergebnis: Ein reproduzierbarer Retrieval-Score, der sich nach jeder Änderung überprüfen lässt. Groundedness-Check funktioniert. Die 20–30 Testfragen werden mit >90 % Präzision beantwortet.

Phase 4: Produktions-Deployment und Übergabe (Woche 7–8)

Der System-Betrieb muss laufen, bevor er live geht.

Aktivitäten:

• Deployment-Infrastruktur: Kubernetes/Docker/Managed Service, Blue-Green-Deployment für risikofreie Updates
• Monitoring: Latenz pro Anfrage, Kosten pro Anfrage, Retrieval-Metriken, Fehlerraten, aktive Nutzer
• Rate-Limiting und Cost-Cap: kein einzelner Nutzer soll das monatliche Budget alleine verbrennen können
• Feedback-Mechanismus in der UI: Nutzer können Antworten als "hilfreich" oder "unbrauchbar" markieren, Basis für laufende Verbesserung
• Backup- und Rollback-Konzept: was passiert, wenn nach einer Woche die Datenqualität einbricht?
• Übergabe-Dokumentation: Runbook, Alerts, Wartungsverfahren
• Schulung der Betriebs-Personen: nicht was der Code macht, sondern was zu tun ist, wenn eine Kennzahl außer Toleranz läuft

Aufwand: 6–10 Personentage. Ein Senior-Engineer + Betriebs-Personen.

Typischer Stolperstein: Die Übergabe wird unterschätzt. Der Code läuft, aber ohne dokumentiertes Runbook wird der Betrieb nach zwei Wochen unbeherrschbar. Planen Sie explizit Zeit für Dokumentation und Übergabe ein, sonst wird das externes Wissen und Sie sind vom Umsetzer abhängig.

Ergebnis: Ein laufendes RAG-System, das die Business-Kriterien aus Phase 1 erfüllt, dokumentiert übergeben ist, und dessen Weiterbetrieb ohne den ursprünglichen Umsetzungs-Team möglich ist.

Gesamtaufwand und Kosten (realistisch)

Personentage: 28–44 Tage über 8 Wochen. Für einen Senior-Engineer im Vollzeit-Sprint entspricht das dem oberen Ende, realistisch mit einem 60–80 % Auslastungs-Sprint plus fachlichem Owner in Nebenrolle.

Externe Kosten für die 8 Wochen:

| Kategorie | Kostenrahmen | |---|---| | Umsetzungs-Sprint (extern) | 40.000–80.000 EUR | | LLM-API während Entwicklung + Evaluation | 200–500 EUR | | Vector-DB (managed, während Entwicklung) | 100–300 EUR | | Embedding-Vorberechnung (einmalig für Bestand) | 100–800 EUR je nach Volumen | | Summe extern | ~40.500–81.600 EUR |

Für einen internen Sprint mit vorhandenem Team fallen die externen Kosten weg, der Personalaufwand bleibt. Rechnen Sie realistisch mit einem Senior-Data-Engineer für 6–8 Wochen plus fachlicher Owner 2 Tage/Woche.

Was vermeidet den Sprint-12-Krisen-Meeting

Aus laufenden Projekten die häufigsten Gründe, warum RAG-Projekte zwischen Woche 8 und 12 hängenbleiben:

1. Datenzugriff wurde in Phase 1 nicht sauber geklärt, spätere Reklamation, wer die Zugangsdaten hat, wer sie widerruft, wer sie ergänzt
2. Evaluations-Harness fehlt, jede Änderung bricht etwas, was niemand mehr merkt
3. Kein Wartungs-Owner nach Livegang, das System funktioniert eine Woche und degradiert dann
4. Kein messbares Erfolgskriterium, Stakeholder sagen später "hat halt nicht so wirklich funktioniert"

Alle vier vermeidbar, wenn Phase 1 (Discovery) mit Ernst durchgeführt wird.

Nächster Schritt

Der RAG-Reifegrad-Check prüft in fünf Fragen, in welcher Phase euer Vorhaben aktuell steht, kostenlos, in unter fünf Minuten, mit Sofortauswertung und Empfehlung.

Wenn ihr die 8-Wochen-Reise mit einem Team gehen wollt, das RAG-Systeme schon produktiv gebracht hat: Kalendertermin buchen, 30 Minuten kostenlos.

---

Verwandte Artikel: RAG-System-Beratung: Was Sie vor der Tool-Auswahl klären müssen · Vector-DB-Auswahl für DACH-Mittelstand