Die Anfrage kommt fast wortgleich zwei- bis dreimal pro Monat: „Wir wollen ein RAG-System bauen, welches Tool empfehlt ihr?" Die Antwort ist immer dieselbe: das ist die falsche erste Frage. Wer mit der Tool-Auswahl beginnt, landet mit hoher Wahrscheinlichkeit in Sprint 12 in einer Sackgasse, in der die eigentlichen Probleme nichts mit dem Framework zu tun haben.
Dieser Artikel beschreibt die acht Vorfragen, die vor der Tool-Auswahl geklärt werden müssen. Aus laufender RAG-Beratung im DACH-Mittelstand. Wenn Sie diese Fragen sauber beantworten, ist die Framework-Wahl fast automatisch, und der Sprint 12 endet mit einem Livegang, nicht einem Krisenmeeting.
Frage 1: Welche Daten stehen tatsächlich zur Verfügung?
Nicht welche wären schön, welche sind heute in einer maschinenlesbaren Form abrufbar. In der Praxis sind das oft:
- Ein SharePoint mit 40.000 Dokumenten unterschiedlicher Qualität
- Ein Confluence-Wiki, das gepflegt wird oder auch nicht
- Ein CRM mit strukturierten Tickets plus unstrukturierten Notizen
- E-Mails, PDFs, Präsentationen, Excel-Tabellen, jede mit ihrer eigenen Extraktionsherausforderung
Realistische Antwort: 30–60 % dessen, was Ihnen anfangs versprochen wird, ist innerhalb der ersten sechs Wochen wirklich ingestierbar. Der Rest braucht Datenaufbereitung, PII-Klärung oder liegt technisch im Weg. Ein RAG-Projekt scheitert selten am LLM, es scheitert an der Datenverfügbarkeit.
Frage 2: Was ist der konkrete Use-Case und wer nutzt ihn?
„Wir wollen unseren Wissensbestand durchsuchbar machen" ist kein Use-Case. Ein Use-Case ist:
- „Kundenservice-Agents sollen bei Ticket-Bearbeitung passende technische Anleitungen aus 4.200 Dokumenten in unter 3 Sekunden bekommen"
- „Vertrieb soll bei Angebotserstellung ähnliche vergangene Angebote inkl. Konditionen erhalten"
- „Compliance-Team soll bei neuen Regulierungen relevante interne Policies mit Änderungshinweisen bekommen"
Je konkreter der Use-Case, desto einfacher wird die Architektur. Ein generisches „Wissenschatbot"-Projekt hat 5x höheren Aufwand als drei fokussierte Use-Cases.
Frage 3: Wer trägt die Datenqualität-Verantwortung nach Livegang?
Ein RAG-System ist so gut wie sein zugrundeliegender Datenbestand. Nach dem Livegang muss jemand entscheiden, welche neuen Dokumente aufgenommen werden, welche gelöscht, welche als veraltet markiert. Ohne diesen Prozess degradiert die Qualität innerhalb von drei Monaten so weit, dass Nutzer aufhören zu vertrauen.
Klären Sie vor Projektstart: Welche Person, welche Rolle, welcher Zeitanteil pro Woche? Wenn die Antwort „das machen wir mit dem Team nebenbei" ist, planen Sie den Betrieb realistisch mit ein oder rechnen Sie mit Verfall.
Frage 4: Welche Compliance-Anforderungen gelten wirklich?
DSGVO ist immer relevant, wenn personenbezogene Daten im Bestand liegen. Aber die Details unterscheiden sich stark:
- B2B-Ticket-System mit Kunden-E-Mails im Retrieval-Path: DSGVO-Anforderungen für Right-to-Erasure, PII-Filter, Auditability
- HR-Dokumente mit Mitarbeiterdaten: strengere Zugriffskontrollen, Löschfristen, mögliche Betriebsratsbeteiligung
- Medizinische Daten: MDR-Bezug, ggf. sogar Klassifizierung als Medizinprodukt (siehe EU AI Act für Medizinprodukte-Hersteller)
- Öffentliche Marketing-Inhalte: praktisch keine, wenn wirklich nichts Personenbezogenes enthalten ist
Bewusstsein für die richtige Kategorie vor der Tool-Auswahl spart eine spätere Architektur-Umstellung.
Frage 5: Welche Latenz und Verfügbarkeit sind akzeptabel?
- Kundenservice mit Nutzer der auf Antwort wartet: unter 2 Sekunden First-Token, 99,5 % Verfügbarkeit
- Interner Wissensassistent mit tolerantem Nutzer: 5 Sekunden ok, 98 % reicht
- Batch-Analyse ohne Echtzeit-Interaktion: Minuten möglich, Verfügbarkeit unkritisch
Die Anforderungen entscheiden über Modellwahl (Cloud-LLM vs Self-Hosted), Infrastruktur-Redundanz und Cache-Strategie. Ein Team, das ohne Latenz-Zielwerte in ein RAG-Projekt geht, wird Sprint 12 mit „das ist doch viel zu langsam" konfrontiert.
Frage 6: Was kostet das Modell pro Abfrage, und was ist das Budget?
Ein typisches DACH-Mittelstands-RAG mit GPT-4-Klasse und mittleren Kontexten kostet 0,02–0,08 EUR pro Nutzer-Abfrage. Bei 500 Abfragen/Tag sind das 300–1.200 EUR/Monat nur für die LLM-API. Plus Vector-DB, Embedding-Berechnung, Infrastruktur.
Realistische Gesamtkosten pro Monat für ein Produktions-RAG:
| Kategorie | Kosten/Monat | |---|---| | LLM-API (500 Abfragen/Tag) | 500–1.500 EUR | | Vector-DB (managed, mittlere Größe) | 200–800 EUR | | Embedding-Batches (Neuindexierung) | 100–400 EUR | | Hosting + Monitoring | 200–500 EUR | | Summe | 1.000–3.200 EUR/Monat |
Wenn Ihr Budget bei 300 EUR/Monat liegt, brauchen Sie ein anderes Design (Self-Hosted-Modell, kleinere Kontexte, weniger Nutzer). Klären Sie das vor der Tool-Auswahl, nicht nach dem PoC.
Frage 7: Wer wartet das System nach Sprint 8?
Nach dem Livegang bricht die Realität ein: LLM-Provider ändern Preise, Bibliotheken werden deprecated, neue Modelle erscheinen, die Datenlage ändert sich. Ohne kontinuierliche Wartung wird ein RAG-System innerhalb von 6–12 Monaten stabil unattraktiv.
Wer trägt diese Wartung? Ein internes Data-Engineering-Team? Eine externe Partnerschaft mit dem Umsetzungs-Team? Ein neuer Rollen-Zuschnitt? Wenn diese Frage offen bleibt, planen Sie mindestens 2 Tage/Monat für einen externen Partner ein, realistisch 4–8 Tage.
Frage 8: Was ist das messbare Erfolgskriterium?
„Das System funktioniert" ist kein Kriterium. Was ist es dann?
- Reduzierte Ticket-Bearbeitungszeit um X %? Messen Sie das vorher und nachher.
- Wieviel Prozent der Nutzeranfragen werden mit dem RAG-System beantwortet, ohne dass ein Mensch nachfassen muss?
- Wie viele Angebote werden mit RAG-Unterstützung erstellt, wie hoch ist die Conversion-Rate vs. ohne?
Ohne messbares Kriterium ist der Projekt-Erfolg subjektiv, was in großen Organisationen dazu führt, dass das Projekt später als „hat halt nicht so richtig geklappt" abgestempelt wird.
Wenn diese acht Fragen beantwortet sind
Dann ist die Tool-Auswahl fast trivial:
- Kleiner Datenbestand, Standard-Use-Case, DSGVO-relevant, mittleres Budget: pgvector auf existierender PostgreSQL + LlamaIndex + OpenAI-API mit EU-Data-Processing-Addendum
- Großer Datenbestand, komplexe Multi-Agent-Anforderungen: Weaviate + LangChain + Mistral-Large in Frankfurt
- Hochsensible Daten, kein Cloud-LLM erlaubt: Qdrant self-hosted + Haystack + Llama-3-Instruct in eigener GPU-Umgebung
- Prototyp-Phase, klein, schnell: Chroma + LlamaIndex + Claude-API (nach klarem PoC-Ergebnis auf produktives Setup umstellen)
Details zu diesen Optionen im RAG-Software-Vergleich.
Nächster Schritt
Unser RAG-Reifegrad-Check prüft in fünf Fragen, wie weit euer RAG-Vorhaben inhaltlich und organisatorisch ist, kostenlos, in unter fünf Minuten, mit Sofortauswertung.
Wenn ihr die acht Fragen strukturiert mit einem Team beantworten wollt, das RAG-Systeme schon produktiv gebracht hat: 1-Tages-RAG-Discovery ab EUR 2.500, Kalendertermin buchen.
---
Verwandte Artikel: RAG-System entwickeln, vom PoC in Production in 8 Wochen · DSGVO-konforme RAG-Pipeline: Architektur-Blueprint