Die Implementierung eines RAG Systems auf GCP: Schritt für Schritt erklärt

Autor: Provimedia GmbH

Veröffentlicht:

Aktualisiert:

Kategorie: KI-Tools & Workflows

Zusammenfassung: Der Artikel beschreibt den Aufbau eines sicheren, kostengesteuerten GCP-RAG-Systems sowie die strukturierte Speicherung und OCR-basierte Aufbereitung von Dokumenten mit Document AI.

GCP-Projekt, APIs und Zugriffsrechte für das RAG-System einrichten

Lege zuerst eine klare Umgebung an. Für eine saubere Trennung empfiehlt sich mindestens ein Entwicklungs-, ein Test- und ein Produktionsprojekt. So bleiben Experimente, Dienstkonten und Kosten voneinander getrennt. Aktiviere die Abrechnung und setze ein Budget mit Benachrichtigungen. Ein Budget stoppt Ausgaben nicht automatisch, macht ungewöhnliche Kosten aber früh sichtbar.

Aktiviere nur die APIs, die der geplante Aufbau benötigt:

Die Aktivierung erfolgt zum Beispiel über die Google-Cloud-Shell:

gcloud services enable aiplatform.googleapis.com documentai.googleapis.com run.googleapis.com storage.googleapis.com secretmanager.googleapis.com logging.googleapis.com monitoring.googleapis.com

Wähle danach eine feste Region. Sie sollte möglichst nahe bei den Nutzern liegen und von allen benötigten Diensten unterstützt werden. Eine einheitliche Region verringert Latenz und vereinfacht Vorgaben zur Datenhaltung. Prüfe vor dem Start die aktuelle regionale Verfügbarkeit, denn nicht jede Modell- oder Indexfunktion ist überall verfügbar.

Für den Zugriff gilt das Prinzip der kleinsten Rechte. Verwende nicht das Standarddienstkonto für die gesamte Anwendung. Besser sind getrennte Identitäten:

Vergebe Rollen auf Projekt- oder Ressourcenniveau, nicht pauschal als Editor. Prüfe die effektiven Berechtigungen mit Policy Analyzer oder den IAM-Empfehlungen. Besonders wichtig: Ein Dienstkonto für Cloud Run sollte keine Schreibrechte auf den Dokumentenbestand besitzen, wenn die Anwendung nur Fragen beantworten soll.

Schütze API-Schlüssel, externe Zugangsdaten und andere sensible Konfigurationswerte über Secret Manager. Sie gehören weder in Quellcode und Container-Images noch in Logzeilen. Gewähre dem jeweiligen Laufzeitkonto nur Zugriff auf die benötigte Secret-Version. Nach Änderungen lässt sich gezielt eine neue Version aktivieren, ohne das Image neu zu bauen.

Lege technische Leitplanken fest, bevor der erste Index entsteht. Dazu gehören ein maximales Dokumentvolumen, erlaubte Dateitypen, Größenlimits, Aufbewahrungsfristen und ein Kostenlimit für Modellaufrufe. Zusätzlich sollte jede Anfrage eine eindeutige Kennung erhalten. Diese Kennung verbindet Logs, Suchvorgang und Modellantwort und erleichtert die Fehlersuche.

Für produktive Umgebungen empfiehlt sich eine Bereitstellung über Terraform oder eine vergleichbare Infrastrukturverwaltung. APIs, Buckets, Dienstkonten, IAM-Bindings und Monitoring-Regeln bleiben dadurch versioniert und reproduzierbar. Teste Änderungen zunächst in der Entwicklungsumgebung. Erst wenn Berechtigungen, Region und Kostenkontrollen stimmen, sollte die eigentliche Dokumentenpipeline beginnen.

Dokumente in Cloud Storage speichern und für die Verarbeitung vorbereiten

Lege die Quelldateien nicht direkt in einen einzigen Arbeitsordner. Bewährt haben sich getrennte Pfade für Eingänge, erfolgreich verarbeitete Dateien und Fehlerfälle:

Verwende für jeden Mandanten oder jede Datenquelle einen eigenen Namensraum. Ein Pfad wie incoming/unternehmen-a/2026/07/ ist besser als eine lose Sammlung vieler Dateien. Der Pfad ersetzt keine Zugriffskontrolle, hilft aber bei Filtern, Löschläufen und der späteren Zuordnung.

Prüfe beim Eingang nicht nur die Dateiendung. Kontrolliere zusätzlich MIME-Typ, Dateigröße und – bei kritischen Anwendungen – die tatsächliche Dateisignatur. Lege erlaubte Grenzen fest, zum Beispiel für PDF-, DOCX-, TXT- und HTML-Dateien. Nicht unterstützte Formate werden in die Quarantäne verschoben und lösen einen nachvollziehbaren Fehler aus.

Eine kleine Eingangskontrolle kann folgende Werte erfassen:

Der Hashwert verhindert Doppelarbeit. Kommt eine Datei mit identischem Inhalt erneut an, kann die Pipeline sie überspringen. Ändert sich nur der Dateiname, bleibt der Inhalt trotzdem erkennbar. Bei einer neuen Version sollte die alte Fassung nicht still überschrieben werden. Für Antworten mit zeitlichem Bezug ist die Dokumentversion später entscheidend.

Speichere die Originaldatei unverändert. Extrahierter Text, Seitenbilder und bereinigte Zwischenstände gehören in eigene Pfade oder einen getrennten Bucket. So bleibt der Ausgangspunkt beweisbar, während die Verarbeitung frei angepasst werden kann. Bei PDF-Dateien ist außerdem die Seitennummer wichtig: Sie ermöglicht später eine präzise Zuordnung von Textstellen zur Quelle.

Aktiviere Ereignisse für neue Objekte nur, wenn die Verarbeitung idempotent arbeitet. Ein Upload kann mehr als ein Ereignis auslösen. Die Pipeline muss daher anhand der Dokument-ID oder des Hashwerts erkennen, ob ein Auftrag bereits läuft. Andernfalls entstehen doppelte Extraktionen und unnötige Modellkosten.

Für veraltete Daten eignen sich Lebenszyklusregeln. Temporäre Dateien können nach wenigen Tagen gelöscht werden. Originale sollten dagegen so lange erhalten bleiben, wie es fachliche, vertragliche oder gesetzliche Vorgaben verlangen. Bei personenbezogenen Daten muss ein Löschvorgang auch extrahierte Texte, Chunks, Embeddings und Cache-Dateien erreichen. Ein gelöschtes PDF allein reicht nicht.

Prüfe vor der Übergabe die Textqualität grob. Leere Dateien, passwortgeschützte PDFs, reine Bildscans und extrem kurze Extraktionen gehören nicht automatisch in den normalen Lauf. Markiere sie für OCR oder manuelle Nachbearbeitung. Damit gelangen weniger unbrauchbare Inhalte in den späteren Suchindex.

Wichtige Schritte und Entscheidungen bei der RAG-Implementierung auf GCP

Schritt GCP-Dienst oder Komponente Wichtige Aufgabe Zu beachten
1. Projekt vorbereiten Google Cloud-Projekte, Cloud Billing, Budgets Entwicklungs-, Test- und Produktionsumgebungen anlegen, Abrechnung aktivieren und Kostenbudgets definieren. Umgebungen trennen und Kostenbenachrichtigungen einrichten.
2. APIs aktivieren Vertex AI, Cloud Storage, Document AI, Cloud Run, Secret Manager, Logging und Monitoring Nur die für die geplante Architektur erforderlichen APIs aktivieren. Die aktuelle regionale Verfügbarkeit der benötigten Modelle und Funktionen prüfen.
3. Zugriffsrechte festlegen IAM und Dienstkonten Getrennte Identitäten für Import, Indexierung, Laufzeit und Bereitstellung einrichten. Das Prinzip der kleinsten Rechte anwenden und keine pauschale Editor-Rolle vergeben.
4. Quelldokumente speichern Cloud Storage Dokumente in Pfade wie incoming/, processed/ und quarantine/ organisieren. Originaldateien unverändert aufbewahren und Mandanten durch getrennte Namensräume organisieren.
5. Eingang prüfen Cloud Storage und Importpipeline MIME-Typ, Dateigröße, Dateisignatur, Hashwert und Verarbeitungsstatus erfassen. Doppelverarbeitung durch idempotente Abläufe und stabile Dokument-IDs verhindern.
6. Text extrahieren Document AI Text, Überschriften, Tabellen, Seiten, Bounding Boxes und Konfidenzwerte erkennen. Für Scans OCR und für strukturierte Dokumente passende Prozessoren verwenden.
7. Inhalte normalisieren Verarbeitungslogik Extrahierten Text bereinigen und in ein einheitliches Format mit Quellen- und Seitenangaben überführen. Rohresultate zuerst speichern und wichtige Kopf- oder Fußzeilen nicht blind entfernen.
8. Chunks bilden Chunking-Pipeline Dokumente entlang von Überschriften, Absätzen, Listen und Tabellen in sinnvolle Abschnitte teilen. Als Startpunkt etwa 300 bis 800 Token und 10 bis 20 Prozent Überlappung testen.
9. Embeddings erzeugen Vertex AI Embeddings Für jeden Chunk und jede Nutzerfrage Vektorrepräsentationen mit demselben Modell erstellen. Modell, Dimension und Version dokumentieren; bei einem Modellwechsel meist neu indexieren.
10. Vektoren indexieren Vertex AI Vector Search Embeddings mit stabilen Chunk-IDs und filterbaren Metadaten speichern. Vektordimension, Suchmetrik, Mandant und Zugriffsklasse konsistent konfigurieren.
11. Relevante Inhalte abrufen Vector Search und optional Schlüsselwortsuche oder Reranker Nutzerfragen einbetten, Treffer filtern, Kandidaten abrufen und nach Relevanz sortieren. Zugriffsfilter aus der authentifizierten Sitzung ableiten und schwache Treffer ablehnen.
12. Antwort generieren Gemini auf Vertex AI Frage und relevante Chunks in einem strukturierten, sicheren Prompt an Gemini übergeben. Dokumentinhalte als nicht vertrauenswürdige Daten behandeln und Quellen verpflichtend ausgeben.
13. Anwendung bereitstellen Cloud Run Die RAG-API als Container deployen, authentifizieren und skalieren. Keine unauthentifizierten Endpunkte verwenden, Zeitlimits setzen und maximale Instanzzahl begrenzen.
14. Betrieb überwachen Cloud Logging und Cloud Monitoring Latenz, Fehlerquote, Trefferzahl, Tokenverbrauch und Kosten beobachten. Keine vollständigen Nutzerfragen oder Dokumentinhalte in Logs speichern.
15. Qualität und Sicherheit testen Referenzdatensatz und automatisierte Tests Trefferqualität, Quellen, Halluzinationen, Zugriffstrennung und Antwortzeiten prüfen. Auch unbeantwortbare Fragen, widersprüchliche Versionen und Prompt-Injection-Szenarien testen.

Text und Metadaten mit Document AI aus den Dokumenten extrahieren

Document AI übernimmt die Umwandlung heterogener Dateien in strukturierte Inhalte. Für ein belastbares RAG-System müssen neben dem erkannten Text auch Seiten, Tabellen, Absätze, Überschriften und die Position eines Inhalts erhalten bleiben.

Wähle den passenden Prozessor nach dem Dokumenttyp. Ein Layout-Parser eignet sich für Fließtext, Überschriften, Listen und Tabellen. Für Rechnungen, Formulare oder Verträge können spezialisierte Prozessoren zusätzliche Felder erkennen. Bei gescannten PDFs ist OCR nötig. Ein falscher Prozessor liefert oft formal gültige, aber fachlich unbrauchbare Ergebnisse.

Übergebe die Datei mit ihrem korrekten MIME-Typ und speichere die Antwort zusammen mit einer eigenen Dokument-ID. Eine brauchbare interne Struktur enthält mindestens:

Die Bounding Box verbindet eine Textstelle mit ihrer Position im Original. Bei einer späteren Quellenangabe lässt sich dadurch etwa die konkrete PDF-Seite anzeigen. Auch Tabellen profitieren davon: Ihre Werte bleiben einer visuellen Struktur zugeordnet, statt als ungeordnete Wortkette im Index zu landen.

Normalisiere den extrahierten Text erst nach der Speicherung des Rohresultats. Entferne überflüssige Leerzeichen, trenne Zeilenumbrüche am Satzende korrekt und vereinheitliche Ligaturen. Kopf- und Fußzeilen solltest du erkennen, aber nicht blind löschen. In manchen Dokumenten enthalten sie Versionsnummern oder wichtige Warnhinweise.

Behandle Tabellen separat. Wandle jede Zeile in eine stabile Textform um, zum Beispiel: „Produkt: X; Preis: 49 Euro; Gültig ab: 1. April 2026“. So bleiben Spaltenbeziehungen auch nach dem späteren Aufteilen erhalten. Bei verschachtelten Tabellen oder schlecht erkannten Spalten ist eine automatische Prüfung sinnvoll.

Nutze Konfidenzwerte als Signal, nicht als absolute Wahrheit. Ein Wert unter etwa 0,8 kann eine Nachprüfung auslösen, doch die geeignete Grenze hängt von Sprache, Scanqualität und Dokumenttyp ab. Zahlen, Datumsangaben und Negationen verdienen besondere Aufmerksamkeit. Ein falsch erkanntes Minuszeichen kann eine Antwort komplett verkehren.

Erzeuge aus jedem Ergebnis ein einheitliches internes Format:

Speichere keine leeren Elemente und verwerfe kurze Fragmente nicht ohne Prüfung. Ein einzelner Satz wie „Gilt nicht für Bestandskunden“ kann für die spätere Antwort wichtiger sein als eine ganze Seite. Führe stattdessen eine Mindestlänge nur für rein technische Artefakte ein.

Prüfe den Output mit einem kleinen Referenzsatz von Dokumenten. Vergleiche Seitenzahl, Überschriften, Tabellenwerte und Sonderzeichen. Erst wenn diese Stichprobe stimmt, sollte der bereinigte Datensatz an die Chunk-Erzeugung übergeben werden.

Dokumente sinnvoll in Chunks aufteilen

Die Chunk-Größe entscheidet mit darüber, ob eine Suche präzise oder beliebig wirkt. Ein zu kleiner Abschnitt verliert seinen Zusammenhang, ein zu großer enthält oft mehrere Themen und verwässert den Treffer. Als brauchbarer Startpunkt gelten etwa 300 bis 800 Token pro Chunk. Handbücher, Verträge und kurze FAQ-Antworten brauchen jedoch unterschiedliche Grenzen.

Teile nicht nach einer starren Zeichenanzahl, sondern entlang der Dokumentstruktur. Überschriften, Absätze, Listen und Tabellen liefern natürliche Schnittstellen. Ein Chunk sollte möglichst eine abgeschlossene Aussage enthalten. Beginnt ein Abschnitt mit „Diese Frist gilt ebenfalls“, muss der vorherige Kontext erhalten bleiben.

Eine robuste Reihenfolge für die Aufteilung lautet:

Verwende einen moderaten Überlapp zwischen benachbarten Chunks. Bei 10 bis 20 Prozent bleiben Definitionen und Übergänge eher erhalten. Zu viel Überlapp vervielfacht jedoch nahezu gleiche Inhalte und erhöht Indexgröße sowie Suchrauschen. Bei einem Chunk von 600 Token entsprechen 60 bis 120 Token meist einem vernünftigen ersten Versuch.

Ergänze jeden Chunk um Kontextfelder. Dazu gehören Dokumenttitel, Abschnittspfad, Seitenzahl und Versionsnummer. Diese Angaben können als Metadaten gespeichert und später für Filter oder Quellenlinks verwendet werden; der eigentliche Text bleibt dadurch schlanker.

Behandle verschiedene Dokumenttypen mit eigenen Regeln:

Nutze Parent-Child-Chunks, wenn einzelne Treffer präzise sein sollen, die Antwort aber mehr Kontext braucht. Ein kleiner Such-Chunk findet die passende Stelle. Der übergeordnete Abschnitt wird erst danach nachgeladen. Dieses Verfahren reduziert unnötigen Prompt-Inhalt, ohne den Zusammenhang zu opfern.

Bewahre die Reihenfolge im Dokument und speichere dafür eine Abschnitts- oder Positionsnummer. Bei mehreren Treffern kann die Anwendung benachbarte Chunks zusammenführen und doppelte Passagen entfernen. Das ist besonders hilfreich bei Prozessbeschreibungen, deren Sinn sich über mehrere Absätze verteilt.

Teste die Aufteilung mit echten Fragen. Markiere für jede Frage, ob der benötigte Beleg in einem Treffer vollständig enthalten ist. Miss dabei nicht nur die Trefferquote, sondern auch die durchschnittliche Chunk-Anzahl pro Antwort und die Zahl widersprüchlicher Passagen. Ein gutes Ergebnis ist ein Kompromiss aus Kontext, Präzision und Kosten.

Versioniere die Chunk-Strategie. Ändert sich Größe, Überlapp oder Segmentierungslogik, müssen die betroffenen Embeddings neu erzeugt werden. Eine Kennung wie chunk-v2 im Datensatz verhindert, dass alte und neue Abschnitte unbemerkt im selben Index landen.

Embeddings mit einem Vertex-AI-Modell erzeugen

Erzeuge für jeden Chunk genau ein Embedding mit demselben Modell, das später auch Nutzerfragen verarbeitet. Vektoren aus unterschiedlichen Embedding-Modellen liegen nicht zuverlässig im selben Bedeutungsraum. Ein Austausch des Modells erfordert daher normalerweise eine neue Indexierung.

Lege die Modellkennung als versionierte Konfiguration fest und speichere zusätzlich Modellname, Region, Erstellungszeitpunkt und Chunk-Version im Datensatz. So lässt sich später nachvollziehen, warum zwei inhaltlich ähnliche Texte unterschiedliche Suchergebnisse liefern.

Ein typischer Aufruf über die Python-Bibliothek sieht vereinfacht so aus:

from vertexai.language_models import TextEmbeddingModel
model = TextEmbeddingModel.from_pretrained("text-embedding-005")
vectors = model.get_embeddings(["Text des Chunks"])

Die konkrete Modellkennung und unterstützte Dimensionen können sich ändern. Prüfe deshalb vor dem Einsatz die aktuelle Vertex-AI-Dokumentation. Entscheidend ist ein konsistenter Prozess. Kürze oder projiziere Vektoren nicht nachträglich, wenn der Zielindex eine andere Dimension erwartet.

Bereite den Eingabetext gezielt vor. Entferne technische Steuerzeichen, aber keine fachlich relevanten Begriffe. Produktnummern, Paragraphen, Fehlermeldungen und Eigennamen müssen unverändert bleiben. Füge bei Bedarf den Abschnittspfad voran, damit ein isolierter Chunk mehr Bedeutung erhält. Metadaten wie Zugriffsgruppen gehören dagegen besser in separate Felder.

Erzeuge Embeddings in Batches. Das verringert den Netzwerkaufwand und beschleunigt große Importe. Bei Fehlern darf nicht der gesamte Lauf wiederholt werden: Speichere erfolgreiche Ergebnisse sofort und wiederhole nur fehlgeschlagene Einheiten. Exponentielles Backoff hilft bei temporären Drosselungen.

Normalisiere die Vektoren nur, wenn die Suchkonfiguration dazu passt. Bei einer Kosinus-Ähnlichkeit ist eine L2-Normalisierung üblich. Manche Suchdienste übernehmen diese Behandlung intern. Lege deshalb Metrik und Vorverarbeitung gemeinsam fest.

Prüfe die Ergebnisse nicht nur auf ihre Länge. Identische Eingaben sollten identische oder nahezu identische Vektoren liefern. Inhaltlich verwandte Texte müssen näher beieinander liegen als zufällige Passagen. Ein einfacher Testdatensatz mit bekannten Paaren und Negativbeispielen deckt Fehlkonfigurationen früh auf.

Speichere neben dem Vektor eine unveränderliche Chunk-ID. Der Vektor selbst ist nur die Suchrepräsentation; Text, Quelle und Berechtigungen bleiben getrennt verwaltbare Daten. Diese Trennung erleichtert Korrekturen, Löschungen und eine spätere Migration auf eine neue Modellversion.

Embeddings und Metadaten in Vertex AI Vector Search speichern

Für jeden Vektor braucht der Index eine stabile ID und ein passendes Metadatenobjekt. Die ID sollte sich aus Dokument-ID, Version und Chunk-Position ableiten, zum Beispiel vertrag-4711:v3:chunk-008. Eine deterministische ID macht Schreibvorgänge wiederholbar und verhindert Dubletten.

Ein Indexeintrag besteht praktisch aus drei Teilen:

Bei Vertex AI Vector Search wird zwischen dem eigentlichen Index und der Datenablage für die Indexaktualisierung unterschieden. Für einen großen Bestand ist ein Batch-Index oft wirtschaftlicher. Neue oder geänderte Chunks lassen sich dagegen über inkrementelle Updates nachführen, sofern die gewählte Indexart und Konfiguration dies unterstützen. Prüfe vor der Umsetzung die aktuellen Einschränkungen der jeweiligen Indexvariante.

Die Dimension des Index muss exakt zur Ausgabe des Embedding-Modells passen. Auch die Suchmetrik gehört zur gemeinsamen Konfiguration. Kosinus-Ähnlichkeit, Skalarprodukt und euklidische Distanz liefern nicht dieselben Rangfolgen. Wird die Metrik später geändert, muss der Index passend neu aufgebaut werden.

Halte die Nutzdaten der Attribute klein. Für Filter reichen kompakte Werte wie tenant_id, language, doc_type, access_group und valid_from. Den vollständigen Chunk-Text solltest du in einem separaten Dokumentenspeicher oder einer Datenbank ablegen und über die Chunk-ID verknüpfen.

Ein Metadatenobjekt könnte logisch so aussehen:

Setze Zugriffsfilter bereits bei der Suche. Die Identität des Nutzers muss vor der Abfrage in zulässige Filterwerte übersetzt werden. Verlasse dich dabei nicht auf vom Nutzer selbst gelieferte Mandanten- oder Gruppenangaben.

Aktualisierungen sollten als kontrollierter Upsert laufen. Zuerst wird der neue Chunk mit seiner Version geschrieben. Danach kann die alte Version aus dem aktiven Suchraum entfernt werden. Bei zeitkritischen Inhalten verhindert ein zusätzliches Gültigkeitsfeld, dass abgelaufene Informationen weiterhin Treffer erzeugen.

Beobachte beim Indexaufbau die Zahl erfolgreicher und abgelehnter Einträge. Häufige Ursachen für Fehler sind falsche Vektordimensionen, ungültige IDs oder nicht unterstützte Attributtypen. Speichere die Fehlermeldung zusammen mit dem betroffenen Chunk.

Prüfe den fertigen Index mit bekannten Suchfällen. Jeder Test sollte neben dem erwarteten Chunk auch die zulässigen Dokumentversionen und Zugriffsklassen enthalten.

Nutzerfragen einbetten und relevante Chunks abrufen

Behandle die Nutzerfrage vor der Vektorsuche als eigenen Verarbeitungsschritt. Entferne zunächst Steuerzeichen und führende Leerzeichen, bewahre aber Fachbegriffe, Produktcodes und Datumsangaben. Eine automatische Korrektur darf den Sinn nicht verändern. Aus „nicht zulässig“ darf keinesfalls „zulässig“ werden.

Erzeuge anschließend das Anfrage-Embedding mit demselben Modell und derselben Vektordimension wie bei den Chunks. Fordere zunächst mehr Treffer an, als später im Prompt landen sollen. Bei einem Ziel von fünf Kontextabschnitten sind beispielsweise zehn bis zwanzig Kandidaten ein sinnvoller Startpunkt.

Beschränke die Suche mit sicheren Metadatenfiltern. Typische Filter betreffen Mandant, Sprache, Dokumentstatus oder fachliche Gültigkeit. Der Filter muss aus der authentifizierten Sitzung stammen. Angaben aus dem Fragetext dürfen keine Zugriffsrechte erweitern.

Eine Anfrage kann logisch drei Ebenen enthalten:

Nutze bei kurzen oder mehrdeutigen Fragen eine Anfrageerweiterung. Aus „Kündigungsfrist?“ können interne Suchvarianten wie „Frist zur Beendigung des Vertrags“ entstehen. Die Erweiterung dient nur dem Retrieval; die ursprüngliche Frage bleibt für die spätere Antwort maßgeblich. Bei langen Fragen ist Zurückhaltung besser, damit keine wichtigen Details verloren gehen.

Semantische Suche allein reicht bei exakten Kennungen oft nicht aus. Rechnungsnummern, Paragraphen, Versionscodes und Fehlermeldungen werden durch eine zusätzliche Schlüsselwortsuche zuverlässiger gefunden. Kombiniere beide Ranglisten mit einem nachvollziehbaren Verfahren, etwa Reciprocal Rank Fusion.

Sortiere die Kandidaten nach dem ersten Abruf neu. Ein Reranker kann Frage und Chunk gemeinsam bewerten. Verwende ihn nur für eine begrenzte Kandidatenmenge, sonst steigen Latenz und Kosten. Entferne danach nahezu identische Treffer und bevorzuge, wenn möglich, unterschiedliche relevante Dokumente.

Ein einfacher Retrieval-Datensatz sollte pro Anfrage speichern:

Definiere einen Abbruchwert für schwache Treffer. Liegt kein Kandidat über dieser Schwelle, sollte die Anwendung eine Rückfrage stellen oder offen mitteilen, dass kein passender Beleg gefunden wurde. Der genaue Wert muss mit realen Fragen kalibriert werden; ein universeller Schwellenwert existiert nicht.

Führe für die Bewertung zwei Messungen getrennt durch: Recall@k zeigt, ob der richtige Chunk überhaupt unter den ersten k Treffern liegt. Precision@k zeigt, wie viele dieser Treffer wirklich nützlich sind.

Gib an die Antwortstufe nur die ausgewählten, bereinigten Chunks weiter. Übernimm Quellen-ID und Seitenangabe unverändert, damit die Verbindung zwischen Treffer und Original erhalten bleibt.

Gemini mit gefundenem Kontext und einem sicheren Prompt aufrufen

Baue die Anfrage als klar getrennte Nachrichtenteile auf: Rolle, Regeln, Kontext, Nutzerfrage und gewünschtes Ausgabeformat. Der abgerufene Text sollte sichtbar als Datenblock markiert sein. So wird für das Modell klar, welche Inhalte es verwenden darf und welche Anweisungen tatsächlich gelten.

Ein kompakter Prompt kann folgende Leitlinien enthalten:

Die letzte Regel schützt vor sogenanntem Prompt Injection. Ein Dokument kann selbst Text enthalten, der das Modell zu einer anderen Handlung auffordert. Solcher Text ist für die Antwort ein Beleg, aber keine Systemanweisung. Markiere Kontext deshalb etwa mit <context> und </context> und behandle ihn im Prompt ausdrücklich als untrusted data.

Nutze eine strukturierte Antwort. JSON ist für Anwendungen meist besser als freier Text. Ein mögliches Schema umfasst answer, citations, confidence und needs_clarification. Validiert die Anwendung das Ergebnis vor der Ausgabe, werden fehlende Quellen oder beschädigte Daten früh erkannt.

Gib die Quellen nicht nur als Fließtext aus. Übermittle pro Beleg Chunk-ID, Dokumenttitel und Seitenzahl. Die Benutzeroberfläche kann daraus klickbare Verweise erzeugen.

Begrenze den Kontext vor dem Modellaufruf. Entferne doppelte Passagen und kürze nur dort, wo keine Bedingung verloren geht. Lege ein Token-Limit für Frage, Kontext und Antwort zusammen fest. Bleibt zu wenig Platz, sollten zuerst weniger relevante Chunks entfallen, nicht wichtige Teile der Nutzerfrage.

Eine niedrige Temperatur passt zu Richtlinien, Support und Faktenabfragen. Für sachliche Anwendungen sind Werte zwischen 0 und 0,3 oft ein sinnvoller Ausgangspunkt. Zusätzlich sollten maximale Ausgabelänge, Stop-Sequenzen und ein Zeitlimit definiert werden.

Behandle Modellfehler technisch sauber:

Trenne Nutzereingaben von Systemparametern. Die Frage darf weder Modellname, Temperatur noch Sicherheitsregeln verändern. Auch eine scheinbar harmlose Bitte wie „Ignoriere die Quellen“ muss als normaler Inhalt behandelt werden. Nur die Anwendung entscheidet, welche Felder an den Modellaufruf gelangen.

Prüfe das Ergebnis formal und inhaltlich, bevor es an den Nutzer geht. Fehlen Quellen, widerspricht die Antwort dem Kontext oder enthält sie nicht erlaubte Felder, darf sie nicht ungeprüft ausgegeben werden.

Eine RAG-Anwendung mit Cloud Run bereitstellen

Verpacke die RAG-Logik in einen schlanken HTTP-Dienst und deploye ihn als Container auf Cloud Run. Der Dienst sollte nur Anfragen annehmen, authentifizieren, Retrieval und Modellaufruf koordinieren sowie eine strukturierte Antwort zurückgeben. Die Dokumentenaufbereitung gehört in einen getrennten Batch- oder Ereignisprozess.

Ein Container benötigt einen festen Startbefehl, einen erreichbaren HTTP-Port und einen schnellen Bereitschaftscheck. Lies den Port aus der Umgebungsvariable PORT. Der Dienst sollte beim Start keine umfangreichen Indizes laden. Cloud Run kann Instanzen beenden und neu erzeugen; flüchtiger lokaler Speicher ist daher kein dauerhafter Datenbestand.

Ein minimales Deployment sieht beispielsweise so aus:

gcloud run deploy rag-api --source . --region europe-west3 --no-allow-unauthenticated

Die Option --no-allow-unauthenticated verhindert einen offenen Endpunkt. Für öffentliche Anwendungen sollte ein vorgeschalteter Identitäts- oder API-Gateway-Dienst Anmeldung und Quoten prüfen. Interne Dienste können die Cloud-Run-URL mit signierten Identitätstoken aufrufen. Das Laufzeitkonto erhält nur die Rechte, die der Anfragepfad benötigt.

Trenne Konfiguration und Image. Region, Indexname, Modellkennung, Zeitlimits und maximale Kontextgröße gehören in Umgebungsvariablen oder versionierte Konfigurationsobjekte. Geheimnisse werden zur Laufzeit aus Secret Manager bezogen.

Setze für den interaktiven Pfad klare Grenzen:

Cloud Run skaliert Instanzen automatisch. Begrenze deshalb die maximale Instanzzahl und passe die Parallelität an die Backend-Limits an. Eine niedrige Parallelität reduziert Engpässe bei langsamen Modellantworten, während eine zu niedrige Einstellung unnötig viele Instanzen erzeugen kann.

Nutze Streaming nur, wenn die Benutzeroberfläche davon profitiert. Für strukturierte Antworten ist eine vollständige Antwort oft einfacher zu validieren. Bei langen Modellaufrufen verhindern angemessene Timeouts, dass blockierte Verbindungen Ressourcen binden. Wiederholungen gehören gezielt nur zu transienten Fehlern.

Protokolliere technische Kennzahlen, aber keine vollständigen Nutzerfragen oder Dokumentinhalte. Sinnvolle Felder sind Anfrage-ID, Latenz, Statuscode, Trefferzahl, Modelllaufzeit und Tokenverbrauch. Personenbezug sollte, wenn möglich, vor dem Logging entfernt oder durch einen Hash ersetzt werden.

Veröffentliche neue Versionen zunächst mit einem kleinen Traffic-Anteil. Prüfe Fehlerquote, Antwortzeit und Kosten, bevor der gesamte Datenverkehr umgeschaltet wird. Bei Problemen lässt sich der Traffic auf die vorherige Revision zurückführen. Wenn gleichzeitig Index, Prompt oder Modellversion geändert wurden, müssen diese Komponenten gemeinsam versioniert werden.

Führe Lasttests mit realistischen Fragen durch. Miss Kaltstart, Warmstart, parallele Anfragen und Abbrüche während des Modellaufrufs.

Ein verwaltetes RAG-System mit Vertex AI Search & Conversation prüfen

Lege vor dem Import ein kleines Referenzset mit echten Nutzerfragen an. Jede Frage erhält eine erwartete Antwort, die zulässige Quelle und – falls nötig – eine Liste von Aussagen, die nicht erscheinen dürfen. So wird aus einem Demo-Test eine reproduzierbare Abnahme.

Teste besonders Dokumente, die im Betrieb häufig Schwierigkeiten bereiten:

Bewerte die Ausgabe auf drei Ebenen: Wird die richtige Stelle gefunden? Nutzt die Antwort diese Stelle korrekt? Sind Quellen und Einschränkungen für den Nutzer sichtbar? Eine sprachlich flüssige Antwort kann fachlich trotzdem falsch sein.

Vergleiche außerdem die automatische Antwort mit einer reinen Suchansicht. Zeigt die Suche die erwarteten Dokumente, die generierte Antwort nennt sie aber nicht, liegt das Problem eher bei Zusammenfassung oder Quellenzuordnung. Fehlen die Dokumente bereits in der Suche, solltest du Datenbestand, Parser, Berechtigungen oder Suchkonfiguration untersuchen.

Prüfe die Quellenfunktion mit Fragen, deren Antwort auf einer bestimmten Seite oder in einer konkreten Passage steht. Teste auch negative Fälle: Für eine nicht vorhandene Information sollte der Dienst keine scheinpräzise Antwort erzeugen.

Miss neben der Qualität messbare Betriebswerte:

Führe einen Sicherheitstest mit absichtlich manipulierten Dokumentpassagen durch. Ein Dokument darf den Dienst nicht dazu bringen, interne Regeln zu ignorieren, geheime Inhalte auszugeben oder externe Aktionen anzustoßen. Prüfe zudem, ob Nutzer mit unterschiedlichen Rollen tatsächlich nur ihre freigegebenen Daten erhalten.

Vergleiche den verwalteten Ansatz mit einer kleinen, kontrollierten Eigenimplementierung anhand derselben Fragen. Interessant sind Trefferzahlen, Pflegeaufwand, Quellenqualität, Filterverhalten, Latenz und Änderbarkeit. Die verwaltete Variante ist nicht automatisch die bessere Wahl.

Dokumentiere die verwendeten Daten, Einstellungen, Testfragen und Ergebnisse. Bei einer späteren Änderung der Suchkonfiguration lässt sich dadurch erkennen, ob sich die Antwortqualität wirklich verbessert hat.

Antwortqualität, Quellen und Halluzinationen testen

Teste nicht nur, ob eine Antwort flüssig klingt. Prüfe, ob sie richtig, vollständig, belegbar und angemessen zurückhaltend ist. Ein RAG-System kann den passenden Text finden und trotzdem eine falsche Schlussfolgerung ziehen. Deshalb braucht die Abnahme getrennte Prüfungen für Suche, Belegtreue und Formulierung.

Erstelle ein festes Testset aus realen Fragetypen. Entferne personenbezogene Daten oder ersetze sie durch neutrale Platzhalter. Jede Testfrage erhält eine fachlich geprüfte Referenz: erwartete Aussage, zulässige Quelle und bekannte Stolperstellen. Ergänze auch Fragen, auf die der Datenbestand keine Antwort enthält.

Bewerte jede Antwort mit einer einfachen Prüftabelle. Markiere, ob die Kernaussage stimmt, ob wichtige Bedingungen fehlen, ob die Quelle die Aussage tatsächlich trägt und ob unbelegte Ergänzungen auftauchen. Eine korrekte Quelle macht eine falsche Interpretation nicht automatisch richtig.

Miss die Leistung auf mehreren Ebenen. Faithfulness beschreibt, ob Aussagen aus dem bereitgestellten Kontext folgen. Answer relevancy zeigt, ob die Antwort die Frage wirklich trifft. Completeness prüft, ob wesentliche Bedingungen fehlen. Für die Quellenqualität zählt außerdem, ob die angegebene Passage die konkrete Aussage beweist.

Nutze eine Bewertungsskala, die Prüfer einheitlich anwenden können:

Berechne zusätzlich harte Kennzahlen. Erfasse den Anteil vollständig korrekter Antworten, die Rate unbelegter Behauptungen und die Rate korrekt verweigerter Antworten. Ein System, das bei fehlenden Informationen sauber „nicht bestimmbar“ sagt, ist oft wertvoller als eines, das jede Frage beantwortet.

Führe einen gezielten Halluzinationstest durch. Formuliere Fragen mit plausiblen, aber nicht vorhandenen Begriffen. Verändere Jahreszahlen, Produktnamen oder Vertragsklauseln leicht. Prüfe, ob das System die Lücke erkennt oder eine überzeugende Erfindung liefert. Wiederhole diese Tests nach Änderungen an Modell, Prompt oder Datenbestand.

Prüfe Quellen gegen den tatsächlichen Antworttext. Markiere jede Aussage, die eine Quelle benötigt, und ordne ihr eine konkrete Fundstelle zu. Bei widersprüchlichen Dokumenten muss die Antwort den Konflikt sichtbar machen. Sie darf nicht still eine Version auswählen, wenn Gültigkeit oder Priorität unklar sind.

Führe die Bewertung mit mehreren fachkundigen Personen durch. Vergleiche abweichende Urteile und schärfe danach die Bewertungsregeln. Automatische Prüfer können große Testmengen vorsortieren, ersetzen aber bei rechtlichen, medizinischen oder finanziellen Inhalten keine fachliche Abnahme.

Lege vor jeder Änderung eine Vergleichsmessung an. Speichere Testset, Modellversion, Prompt-Version, Retrieval-Einstellungen und Ergebniswerte. So lässt sich erkennen, ob eine bessere Trefferquote vielleicht mit mehr unbelegten Aussagen bezahlt wurde.

Beziehe den EU AI Act in die Betriebsplanung ein. Je nach Einsatzbereich gelten unterschiedliche Pflichten; bei bestimmten interaktiven Systemen kann eine Information über die maschinelle Erzeugung erforderlich sein. Prüfe die konkrete Risikoklasse und die geltenden Fristen mit einer fachkundigen Stelle. Für den Artikelstand im Juli 2026 ist eine aktuelle Rechtsprüfung unverzichtbar, da technische und organisatorische Pflichten stufenweise greifen.

Fazit: Mit kleinen Tests starten und das RAG-System schrittweise produktionsreif machen

Ein produktionsreifes RAG-System entsteht durch kontrollierte Verbesserungen. Beginne mit einem kleinen, repräsentativen Dokumentbestand und klaren Erfolgskriterien. Erst wenn der Ablauf stabil ist, lohnt sich die Ausweitung auf weitere Datenquellen, Sprachen und Nutzergruppen.

Suchqualität, Antwortstil und Betriebskosten müssen gemeinsam betrachtet werden. Eine Änderung an der Datenaufbereitung kann die Treffer verbessern, aber die Antwort verlängern oder den Verbrauch erhöhen. Dokumentiere solche Änderungen mit einer Versionsnummer, damit Ergebnisse vergleichbar bleiben.

Plane den Übergang in den Regelbetrieb anhand messbarer Bedingungen:

Nach dem Start verändern sich Inhalte, Nutzer stellen neue Fragetypen und Modelle werden aktualisiert. Richte deshalb einen festen Verbesserungsprozess ein: Neue Fehlfälle fließen in das Testset ein, Fachanwender bewerten kritische Antworten und technische Messwerte zeigen, wo die Pipeline langsamer oder teurer wird.

Wähle die Architektur nach dem tatsächlichen Änderungsbedarf. Ein verwalteter Dienst kann für einen schnellen fachlichen Nutzen genügen. Eine selbst kombinierte Pipeline ist sinnvoll, wenn Zugriffslogik, Datenformate oder Suchverfahren stark angepasst werden müssen. Entscheidend ist, ob das System dauerhaft verständliche und überprüfbare Antworten liefert.

Für die Transparenz gegenüber Nutzern sollte die Anwendung klar ausweisen, wann eine Antwort automatisch erzeugt wurde. Bei sensiblen Themen braucht es zusätzlich einen fachlichen Eskalationsweg. Ein RAG-Dienst unterstützt Entscheidungen, ersetzt aber nicht automatisch die verantwortliche Stelle.

Wer klein beginnt, misst und gezielt nachschärft, vermeidet eine technisch beeindruckende Demo ohne belastbaren Alltagsnutzen. Auf GCP stehen dafür sowohl verwaltete Bausteine als auch frei kombinierbare Dienste bereit. Nachhaltiger Erfolg entsteht durch saubere Daten, klare Betriebsregeln und einen Verbesserungsprozess, der im Alltag tatsächlich gelebt wird.