RAG-Systeme implementieren: Architektur, Kosten und Pilotplan

Ein RAG-System verbindet die Suche in eigenen Dokumenten mit einem Sprachmodell. Für eine verlässliche Implementierung brauchst du freigegebene Datenquellen, passende Suchverfahren, prüfbare Antworten und einen betreuten Betrieb. Dieser Leitfaden zeigt einen Pilotplan mit konkreten Abnahmekriterien. Ob daraus ein produktives System wird, entscheidet die Prüfung – nicht ein pauschales 30-Tage-Versprechen.

RAG implementieren: die wichtigsten Entscheidungen

• Use Case begrenzen: Welche Fragen soll das System beantworten und wann muss es an einen Menschen übergeben?
• Daten und Rechte klären: Welche Dokumente sind aktuell, wer verantwortet sie und wer darf welche Inhalte sehen?
• Suche vor Antwortstil prüfen: Fehlen die richtigen Quellen, hilft auch eine überzeugend formulierte Antwort nicht.
• Qualität und Kosten gemeinsam messen: Antwortbelege, Fehlantworten, Wartezeit und Aufwand pro bearbeitetem Fall gehören in dieselbe Abnahme.
• Produktion gesondert freigeben: Zuständigkeiten, Aktualisierung, Fehlerbehandlung und Wiederherstellung müssen vor dem breiten Einsatz funktionieren.

Du suchst Unterstützung für ein konkretes Vorhaben? In einem Gespräch zur KI-Beratung lassen sich Anwendungsfall, vorhandene Systeme und die Anforderungen an einen RAG-Piloten eingrenzen.

Wann sich RAG lohnt – und wann eine Suche genügt

Bei Retrieval-Augmented Generation sucht eine Anwendung zunächst passende Informationen. Das Sprachmodell erhält ausgewählte Fundstellen als Kontext und formuliert daraus eine Antwort. RAG kann dadurch eigene oder veränderliche Wissensbestände nutzbar machen; es garantiert weder richtige Quellen noch fehlerfreie Antworten. Die Microsoft-Dokumentation zu RAG erläutert das Zusammenspiel von Suche, Kontext und Generierung.

Aufgabe	Sinnvoller Ausgangspunkt	Prüffrage
Ein bestimmtes Dokument finden	Volltextsuche und Filter	Genügt eine gut sortierte Trefferliste?
Eine Frage aus mehreren freigegebenen Dokumenten beantworten	RAG-Pilot mit sichtbaren Quellen	Lässt sich jede wesentliche Aussage an einer Fundstelle prüfen?
Einen definierten Vorgang ausführen	Workflow mit Berechtigungen und klaren Regeln	Welche Schritte benötigen eine menschliche Freigabe?

Diese Auswahl ist eine redaktionelle Entscheidungshilfe. Starte mit einem abgegrenzten Wissensbereich statt mit sämtlichen Unternehmensdaten. Halte vorab fest, wer den Nutzen beurteilt und welche bestehende Lösung als Vergleich dient.

Die Architektur im Überblick

Eine klassische Pipeline umfasst Datenimport, Aufbereitung, Suchindex, Abfrage und Antwortgenerierung. Eine Vektorsuche findet semantisch ähnliche Inhalte; eine Stichwortsuche kann exakte Produktnamen und Kennungen erfassen. Hybridverfahren kombinieren beide Ansätze. Ein zusätzlicher Reranker kann Treffer neu ordnen, erhöht aber auch die Verarbeitungskosten und Laufzeit. Die passende Kombination musst du an deinen Fragen prüfen.

Phase 1: Datenbasis und Testfragen vorbereiten

Lege ein Quellenverzeichnis an. Es sollte für jeden Bestand Quelle, zuständige Person, Aktualisierungsweg, Zugriffsregeln und Umgang mit Löschungen enthalten. Trenne freigegebene Anleitungen von Entwürfen und veralteten Versionen. Prüfe bei PDFs und Tabellen, ob beim Import Überschriften, Zahlen und Zusammenhänge erhalten bleiben.

Chunks nachvollziehbar erzeugen

Teile Inhalte zunächst entlang sinnvoller Abschnitte. Ein Chunk sollte eine eindeutige Dokument-ID, eine Versionsangabe und eine auffindbare Fundstelle besitzen. Vergleiche kleinere und größere Abschnitte mit denselben Testfragen. Wähle Überlappungen dort, wo sonst notwendiger Kontext verloren geht; eine universell beste Tokenzahl gibt es für dieses Projekt ohne Messung nicht.

Ein Prüfset vor dem ersten Demo-Termin

Unsere Empfehlung für den Pilot: Sammle eine überschaubare erste Auswahl realer, freigegebener Fragen und erweitere sie um gezielte Grenzfälle. Halte erwartete Quellen und das gewünschte Verhalten fest.

• Eine klare Frage mit genau einer gültigen Fundstelle.
• Eine Frage, deren Antwort mehrere Dokumente benötigt.
• Eine unklare Frage, die eine Rückfrage erfordert.
• Eine Frage ohne ausreichende Quelle: Das System soll seine Grenze nennen.
• Eine Frage nach gesperrten oder inzwischen gelöschten Inhalten.

Abnahme dieser Phase: Fachverantwortliche bestätigen Quellenumfang und Sollantworten. Ohne dieses Prüfset lässt sich eine ansprechende Demo kaum von einem belastbaren Ergebnis unterscheiden.

Phase 2: Retrieval und Systemauswahl testen

Vergleiche die vorhandene Suche mit einer Vektor- und gegebenenfalls einer Hybridsuche. Nutze denselben Dokumentstand und dieselben Fragen. Ändere pro Vergleich möglichst nur eine zentrale Einstellung, etwa Chunking, Embedding-Modell oder Ranking. So erkennst du eher, woher Verbesserungen oder Verschlechterungen kommen.

Entscheidung	Im eigenen Pilot prüfen
Suchdienst oder Datenbank	Rechtefilter, Aktualisierung, Löschungen, Sicherungen, Betriebsaufwand und Exportmöglichkeiten.
Embedding-Modell	Treffer bei deutschen Fachbegriffen, Abkürzungen, Versionsnummern und typischen Nutzerfragen.
Reranking	Verbessern sich relevante Treffer ausreichend, um zusätzliche Kosten und Wartezeit zu rechtfertigen?
Managed Service oder Eigenbetrieb	Vorhandene Infrastruktur, Zuständigkeiten, Datenflüsse und laufender Wartungsaufwand.

Abnahme dieser Phase: Die benötigten Quellen werden bei den vereinbarten Testfragen zuverlässig gefunden; Fehlertypen bleiben sichtbar dokumentiert. Eine gute Platzierung in einem öffentlichen Modellbenchmark ersetzt diese Prüfung nicht.

Phase 3: Antworten belegen und Qualität messen

Die Antwort sollte zwischen belegten Informationen, offenen Punkten und nötigen Rückfragen unterscheiden. Quellen müssen auf die verwendete Passage führen. Fehlt eine ausreichende Grundlage, soll die Anwendung das mitteilen und einen passenden nächsten Schritt anbieten. Ein Link allein beweist noch nicht, dass die zitierte Stelle die Aussage trägt.

Messgröße	Was sie beantwortet	Grenze
Recall@k	Welcher Anteil der als relevant markierten Quellen erscheint unter den ersten k Treffern?	Benötigt belastbare Relevanzbewertungen.
Quellenstützung / Groundedness	Werden Aussagen durch den abgerufenen Kontext gestützt?	Eine veraltete Quelle kann eine ebenfalls veraltete Antwort stützen.
Antwortrelevanz und Vollständigkeit	Beantwortet die Ausgabe die tatsächliche Frage und die benötigten Teilaspekte?	Ein Sprachmodell als Bewerter kann selbst Fehler machen.
End-to-End-Latenz und Fehlerquote	Wie lange dauert die vollständige Antwort, und wie oft scheitert die Verarbeitung?	Durchschnittswerte können langsame Randfälle verdecken.
Kosten je Anfrage und bearbeitetem Fall	Wie viel Aufwand entsteht inklusive Wiederholungen und menschlicher Nacharbeit?	Eine billige Einzelantwort kann einen teuren Gesamtprozess verursachen.

Die Trennung zwischen Retrieval- und Antwortbewertung beschreibt Microsoft in den RAG-Evaluatoren. Für Testdatensätze, Bewertungsverfahren und die gemeinsame Betrachtung von Qualität, Kosten und Laufzeit siehe die Anleitung zur End-to-End-Evaluation.

Abnahme dieser Phase: Fachverantwortliche prüfen eine Stichprobe selbst. Grenzen und Schwellenwerte werden passend zum Einsatzfall festgelegt. Vergleiche laufen mit dokumentierten Modell-, Prompt-, Index- und Datensatzversionen; eine Änderung darf unzulässige Zugriffe oder kritische Fehlantworten nicht durch einen besseren Durchschnitt verdecken.

Phase 4: Betrieb und Produktionsfreigabe vorbereiten

Ein funktionierender Pilot benötigt vor dem produktiven Einsatz einen benannten Betriebsverantwortlichen. Lege fest, wer Quellen aktualisiert, Fehler beurteilt, Kosten kontrolliert und bei Ausfällen entscheidet. Eine Kubernetes-Installation oder eigene GPU ist dafür keine pauschale Voraussetzung; die Infrastruktur folgt den gemessenen Anforderungen.

Berechtigungen vor dem Modell durchsetzen

Zugriffsregeln müssen bis zu den einzelnen indexierten Abschnitten erhalten bleiben und bei jeder Abfrage berücksichtigt werden. Das Sprachmodell darf nicht entscheiden, ob es vertrauliche Inhalte herausgibt: Unzulässige Inhalte sollen es gar nicht erreichen. Dokumentänderungen, entzogene Rechte und Löschungen müssen auch Index und Caches erreichen. Diese Anforderungen behandelt das OWASP RAG Security Cheat Sheet.

Prüfe außerdem manipulierte Dokumente, die versteckte Anweisungen enthalten. Abgerufener Inhalt ist Datenmaterial und keine Berechtigung, Systemregeln zu ändern oder Werkzeuge auszuführen. Plane Kontrollen für Datenaufnahme, Retrieval und Ausgabe; ein einzelner Prompt oder ein Eingabefilter genügt als Schutzkonzept nicht.

Freigabecheck für den Pilot

• Testkonten sehen ausschließlich ihre freigegebenen Quellen.
• Ein zurückgezogenes Dokument verschwindet auch aus Antworten und relevanten Caches.
• Fehlende Belege führen zu einer kenntlich gemachten Grenze oder Übergabe.
• Timeouts, Ausfälle und Budgetgrenzen lösen das vereinbarte Verhalten aus.
• Aktualisierung und Wiederherstellung wurden praktisch geprüft; Verantwortliche kennen den Ablauf.
• Protokolle enthalten die zur Fehlersuche nötigen Angaben; sensible Volltexte werden nicht pauschal mitgeschrieben.

Aufbewahrung, Datenverarbeitung und rechtliche Anforderungen müssen zum konkreten Einsatz passen. Eine bestimmte Hostingregion oder Log-Aufbewahrungsdauer belegt für sich genommen keine vollständige Compliance.

RAG-Kosten nachvollziehbar planen

Trenne einmalige Einrichtung von laufendem Betrieb. Zur Einrichtung gehören Datenaufbereitung, Integration, Testfragen und Abnahme. Laufend entstehen unter anderem Kosten für Suche, Modellaufrufe, Aktualisierung, Überwachung und menschliche Pflege. Ein API-Preis allein ist kein Projektbudget.

Rechenbeispiel mit frei gewählten Planwerten, keine Anbieterpreise und kein Kundenfall: Angenommen werden 6.000 Anfragen pro Monat, 0,02 Euro variable Verarbeitungskosten je Anfrage, 180 Euro fixe Infrastrukturkosten und sechs Stunden Pflege zu intern angesetzten 80 Euro je Stunde. Alle Beträge sind kalkulatorische Werte vor Umsatzsteuer.

Position	Rechnung	Monatlicher Planwert
Variable Verarbeitung	6.000 × 0,02 Euro	120 Euro
Infrastruktur	Angenommener Fixbetrag	180 Euro
Pflege	6 × 80 Euro	480 Euro
Summe	120 + 180 + 480 Euro	780 Euro

Das ergibt in diesem Beispiel 0,13 Euro je Anfrage. Die anfängliche Implementierung ist noch nicht enthalten. Ob sich der Einsatz lohnt, hängt vom tatsächlich verbesserten Prozess ab. Frei werdende Arbeitszeit ist nicht automatisch eine zahlungswirksame Personalkosteneinsparung.

Beispiel für einen Kundenservice-Piloten

Hypothetisches Planungsszenario: Ein Supportteam möchte Fragen zu freigegebenen Produktanleitungen beantworten. Der Pilot beschränkt sich auf einen Produktbereich. Interne Notizen bleiben außerhalb der für Kunden erreichbaren Wissensbasis. Das Team vergleicht RAG mit seiner bisherigen Suche und hält richtige Antworten, Rückfragen, Eskalationen und Nacharbeit fest.

Die Freigabe erfolgt erst nach Quellenprüfung, Zugriffstests und fachlicher Abnahme. Wenn die Ergebnisse nicht überzeugen, wird zunächst die Datenbasis oder Suche verbessert. Es wird hier keine erreichte Ticketreduktion, Amortisation oder Bearbeitungsdauer behauptet.

RAG-Projekt besprechen

Bring zum Erstgespräch eine Beschreibung des Prozesses, Beispiele typischer Fragen und eine Liste der vorhandenen Datenquellen mit. Vertrauliche Dokumente sind für diese erste Einordnung nicht nötig. RAG-Projekt mit AI Rockstars besprechen. Für die Anbindung wiederkehrender Abläufe findest du weitere Informationen bei unserer n8n-Beratung und Automatisierung.

Häufige Fragen zur RAG-Implementierung

Ist ein RAG-System in 30 Tagen produktionsreif?

Das lässt sich ohne geprüften Umfang nicht zusagen. Plane den Piloten nach Datenzugang, Integrationen und Abnahmekriterien. Ein begrenzter Test und ein freigegebener Produktionsbetrieb sind unterschiedliche Ergebnisse.

Verhindert RAG Halluzinationen?

Nein. RAG kann passende Belege bereitstellen, aber Suche, Quellen und Antwortgenerierung können fehlerhaft sein. Prüfe Fundstellen, fachliche Richtigkeit und das Verhalten bei fehlenden Informationen.

Welche Vektordatenbank ist die beste?

Eine pauschale Empfehlung ist für dein Projekt nicht belastbar. Vergleiche Rechtefilter, Aktualisierung, Trefferqualität, Betriebsaufwand und Kosten an denselben Dokumenten und Fragen.

Wie wird der Erfolg eines RAG-Piloten gemessen?

Mit freigegebenen Testfragen, Quellen- und Antwortprüfungen sowie Kosten und Bearbeitungsaufwand gegenüber dem bisherigen Prozess. Nutzerbewertungen ergänzen diese Daten, ersetzen sie aber nicht.

Methode und Grenzen: Redaktioneller Leitfaden, anhand der verlinkten Primärquellen überarbeitet am 15. September 2026. Pilotplan, Auswahlhilfen und Planrechnung sind Vorschläge, keine dokumentierte Kundenimplementierung und kein ausgeführter Produktbenchmark. Eine frühere Fassung enthielt nicht belegte Erfolgs- und Kostenangaben; die Neufassung ersetzt sie durch nachvollziehbare Prüfschritte und ausdrücklich angenommene Planwerte.