KI mit eigenen Daten grounden (Google Vertex AI): RAG in der Praxis

Definition

KI mit eigenen Daten zu grounden bedeutet, Antworten eines Modells durch konkrete Inhalte aus definierten Datenquellen zu stützen, typischerweise via RAG (Retrieval-Augmented Generation).

Es ist kein Training oder Fine-Tuning des Basismodells, sondern eine Laufzeit-Anreicherung mit Kontext aus deinen Daten.

Einleitung

Wenn du willst, dass KI nicht „klingt wie richtig“, sondern sich auf eure Fakten bezieht, führt am Grounding kaum ein Weg vorbei. In Google Cloud ist Vertex AI die KI-Plattform für Modelle, Pipelines, Bereitstellung, Monitoring und MLOps. Der praktische Hebel: Du verbindest Gemini-Modelle in Vertex AI mit deinen Quellen, damit KI-Anwendungen belastbar, nachvollziehbar und nutzbar im Tagesgeschäft werden.

Vertex AI und Grounding: was gehört wohin?

Vertex AI ist die Plattform in Google Cloud, um KI-Modelle zu entwickeln, zu trainieren, bereitzustellen und zu betreiben (inkl. APIs, Vertex AI Pipelines und Monitoring). Grounding ist ein Muster innerhalb von KI-Anwendungen: Das Modell bekommt beim Antworten zusätzliche, relevante Fakten aus euren Systemen.

Wichtig für die Erwartung: Grounding verbessert Relevanz und Quellenbezug, aber löst keine Datenqualitätsprobleme. Wenn Richtlinien veraltet sind, wird die Antwort sauber „falsch“ grounded.

Datenquellen: Inline-Daten vs. Vertex AI Search-Daten

Du hast im Kern zwei Wege, um Kontext zu liefern. Beide sind valide – sie unterscheiden sich bei Skalierung, Governance und Aufwand.

• Inline-Daten: Du gibst dem Modell den Kontext direkt im Request mit. Gut für kleine, geprüfte Factsheets, z. B. „aktueller SLA-Text“ oder „Freigaberegeln als Auszug“.
• Vertex AI Search-Daten: Du baust einen Data Store (Index) auf Dokumenten und lässt Retrieval gezielt Textstellen holen. Gut für Wissensbasen, Handbücher, Tickets, Policies und Intranets.
• Kombi: Inline für situative Parameter (z. B. Kundensegment), Search für den Wissenskontext.

Nutzen für Anwender: Statt in SharePoint, Wikis und PDFs zu suchen, bekommen sie eine Antwort mit belegbaren Quellen – und können schneller entscheiden oder weiterarbeiten.

Schritt-für-Schritt: KI mit eigenen Daten grounden in Vertex AI

Ein pragmatischer Ablauf, der in Projekten funktioniert, ohne direkt in Komplexität zu versinken.

• Schritt 1: Use Case und „Definition of Done“ festlegen (z. B. „Antwort muss Quelle nennen“).
• Schritt 2: Daten auswählen und „Gold-Quelle“ definieren (nur freigegebene, aktuelle Inhalte).
• Schritt 3: Data Store in Vertex AI Search anlegen und Dokumente ingestieren.
• Schritt 4: Zugriff mit IAM und (falls nötig) DLP-Regeln sauber setzen.
• Schritt 5: Prompting + Retrieval testen (Qualität, Abdeckung, Fehlantworten).
• Schritt 6: Betrieb aufsetzen (Logging, Monitoring, Versionierung von Datensätzen/Prompts).

Python-Code: minimales Grounding-Beispiel

Das folgende Beispiel zeigt die typische Struktur: Gemini in Vertex AI antwortet, während Retrieval aus einem Such-Index (Data Store) Kontext liefert. Je nach SDK-Version und Setup unterscheiden sich Klassen/Parameter, aber die Logik bleibt gleich.

Voraussetzungen: Google Cloud Projekt aktivieren, Vertex AI API einschalten, Auth (z. B. Workload Identity oder Service Account), Data Store in Vertex AI Search.

import vertexai
from vertexai.generative_models import GenerativeModel

PROJECT_ID = "my-gcp-project"
LOCATION = "europe-west3"  # Beispiel
MODEL_NAME = "gemini-1.5-flash"

vertexai.init(project=PROJECT_ID, location=LOCATION)
model = GenerativeModel(MODEL_NAME)

question = "Wie läuft der interne Freigabeprozess für Änderungen ab? Bitte mit Quellen."

# Konzeptuell: Retrieval-Kontext kommt aus Vertex AI Search (Data Store).
# In der Praxis wird hier ein Retrieval-/Tool-Connector konfiguriert,
# der relevante Textstellen aus dem Index holt und als Kontext einspeist.

response = model.generate_content(question)
print(response.text)

Produktions-Tipp: Baue Tests, die nicht nur „klingt gut“ prüfen, sondern z. B. Quellenabdeckung, Zitierquote und „No-Answer“-Verhalten messen.

Architektur und Datenfluss (Textdiagramm)

So sieht der Datenfluss in einer typischen RAG-Architektur in Google Cloud aus:

Nutzerfrage → API/Backend → Retrieval (Vertex AI Search Data Store) → Kontext (Top-Passagen) → Gemini in Vertex AI → Antwort + Quellen → Logging/Monitoring

Mehrwert: Du kannst steuern, welche Inhalte überhaupt in KI-Antworten landen. Das ist der Unterschied zwischen „KI als Chat“ und „KI als verlässliche Arbeitsunterstützung“.

Best Practices: Sicherheit, Governance und Versionierung

• Least Privilege: Data Store und Quellen strikt nach Rollen trennen; nicht jede KI-Anwendung braucht Zugriff auf alles.
• Versionierung: Data Store-Updates, Prompt-Versionen und Evaluations-Sets versionieren, damit Änderungen nachvollziehbar bleiben.
• Monitoring: Drift und Antwortqualität beobachten (z. B. neue Dokumente ändern die Trefferlage); Vertex AI Model Monitoring kann hier Teil der MLOps-Routine sein.

Typische Use Cases (1 Mini-Story)

Ein IT-Team baut einen internen Assistenz-Chat für Betriebsfragen: „Welche Ports sind für System X erlaubt?“ Vorher: 15 Minuten Suche in Wiki + Tickets. Nachher: die KI liefert eine Antwort mit verlinkten Richtlinienauszügen aus dem Data Store und markiert, wenn keine Quelle gefunden wurde. Dadurch sinkt die Rückfragequote, und neue Teammitglieder werden schneller produktiv.

Fallstricke, Grenzen und Aufwandseinordnung

• Kosten: Treiber sind Indexierung/Retrieval, Modellaufrufe und Betrieb. Ohne klare Scope-Grenzen wird RAG teuer, weil zu viel gesucht und zu viel generiert wird.
• Zeitaufwand: Der Engpass ist selten Code, sondern Datenfreigabe, Berechtigungen und Tests. Plane das von Anfang an ein.
• Komplexität: Multi-Quellen, unterschiedliche Rechte und „was gilt als Wahrheit?“ machen es anspruchsvoll. Starte mit einer Gold-Quelle.

Wann externe Unterstützung sinnvoll wird

Externe Unterstützung lohnt sich, wenn du von einem PoC zu einem produktiven Dienst willst: mehrere Teams, mehrere Datenquellen, Compliance-Anforderungen, klare Messbarkeit und Betrieb. Dann entscheidet Architektur (Datenfluss, Rechte, Monitoring) über Tempo und Risiko.