Blueprint 03 · Production Architecture

Vom RAG-Prototyp
zum Cloud-Produkt.

Eine KI-Anwendung für Unternehmen braucht mehr als ein Sprachmodell und eine Datenbank. Diese AWS-Referenzarchitektur zeigt, wie Daten, Zugriffsrechte, Wissenssuche, Antwortprüfung und Betrieb zusammenwirken.

Architekturprinzip

Managed,
wo es hilft.

Amazon Bedrock Knowledge Bases kann Dokumente einlesen, für die Suche aufbereiten und passende Textstellen für eine KI-Antwort bereitstellen. Die fachlichen Abläufe Ihrer Anwendung werden über definierte Schnittstellen angebunden.

Zuerst wählen Sie das Betriebsmodell: Bei einer Managed Knowledge Base verwaltet AWS auch die Speicher- und Suchinfrastruktur. Bei einer Customer-managed Knowledge Base wählen und konfigurieren Sie diese Komponenten selbst. Erst danach folgt gegebenenfalls die Entscheidung für einen eigenen Vektorspeicher, etwa OpenSearch oder Aurora.

In beiden Varianten müssen Nutzer vor der Wissenssuche angemeldet und ihre Zugriffsrechte geprüft werden. Hinzu kommen auf das Nötigste begrenzte technische Berechtigungen, Verschlüsselung, getrennte Test- und Produktivumgebungen sowie wiederholbare Qualitätsprüfungen.

AWS-Dokumentation zu Knowledge Bases ↗

Referenzarchitektur

Kommerzielle RAG-Anwendung auf AWS

Diese AWS-Referenzarchitektur zeigt eine mögliche kundenseitig verwaltete Variante mit eigenem Vektorspeicher. OpenSearch und Aurora sind hier Alternativen. Region, Dienste und Netzwerkgrenzen werden passend zum Projekt ausgewählt und geprüft.

KMS · Verschlüsselung IAM · Minimale Zugriffsrechte CloudWatch / CloudTrail · Überwachung und Protokolle CDK / CloudFormation · Infrastruktur als Code

Technologieentscheidung

Erst das Betriebsmodell,
dann der Speicher.

Wer übernimmt welche Aufgaben? Diese Frage kommt vor der Datenbankwahl. Datenquellen, Zugriffsrechte, Suchlast und verfügbarer Betriebsaufwand bestimmen die Auswahl.

  1. 01

    Betriebsmodell auswählen

    Die Modelle unterscheiden sich darin, wie viel Infrastruktur AWS verwaltet und wie viel Sie selbst konfigurieren und betreiben.

    Betriebsmodell Passend, wenn … Stärke Früh prüfen
    Managed Knowledge Base Ein schneller Einstieg und wenig eigener Infrastrukturaufwand wichtig sind. AWS verwaltet Datenaufnahme, Indexierung, Speicher und Suche. Region, Datenquellen, Rechteanbindung, Kosten und Anpassungsmöglichkeiten.
    Customer-managed Knowledge Base Sie Speicher und Datenaufbereitung gezielt selbst auswählen und konfigurieren möchten. Mehr Kontrolle über die eingebundenen Komponenten und deren Konfiguration. Eigene Berechtigungslogik, Betriebsaufwand, Tests und Verantwortlichkeiten.
  2. 02

    Bei kundenseitig verwalteter Variante: Vektorspeicher wählen

    Die folgende Auswahl zeigt zwei mögliche Speicher. Bei einer Managed Knowledge Base übernimmt AWS diese Infrastruktur; dafür ist diese zusätzliche Auswahl nicht erforderlich.

    Speicher Passend, wenn … Stärke Früh prüfen
    OpenSearch Serverless Die Suche nach ähnlichen Inhalten und ein wachsendes Suchvolumen im Mittelpunkt stehen. Suchfunktionen und Integration in die AWS-Umgebung. Suchindex, Filter, Mindestkosten und Trennung der Kundendaten.
    Aurora PostgreSQL Vektoren eng mit relationalen Geschäftsdaten verbunden sind. SQL-Abfragen und vorhandene PostgreSQL-Erfahrung. Suchindex, Datenbankverbindungen, Lastgrenzen und Rechtekonzept.

Erstellungsablauf

In acht Schritten in Produktion.

Jeder Schritt erzeugt ein prüfbares Ergebnis. So bleiben Architektur, Datenqualität und Wirtschaftlichkeit während der Entwicklung sichtbar.

  1. 01

    Ziele, Risiken und Messgrößen festlegen

    Nutzer, Datenarten und Geschäftsrisiken dokumentieren. Festlegen, welche Aufgaben die KI selbst übernehmen darf. Repräsentative Testfragen mit erwarteten Quellen sowie Zielwerte für Suchqualität, Quellenbezug, Antwortzeit und Kosten definieren.

  2. 02

    AWS-Konten und Umgebungen trennen

    Mindestens Entwicklung, Test und Produktion isolieren. Region anhand Datenanforderungen und aktueller Modell- sowie Serviceverfügbarkeit auswählen.

    • Budgets und Kostenalarme pro Umgebung
    • Keine Produktionsdaten in Entwicklungsaccounts
    • Notfallzugänge und Administrationsrollen dokumentieren
  3. 03

    Datenablage und Verantwortlichkeiten aufbauen

    S3-Buckets mit Versionierung, Block Public Access, KMS-Verschlüsselung, Lifecycle-Regeln und klaren Präfixen für Rohdaten, freigegebene Daten und Quarantäne konfigurieren.

  4. 04

    Knowledge Base und Retrieval konfigurieren

    Das gewählte Betriebsmodell einrichten. Für die hier gezeigte kundenseitig verwaltete Variante werden Textauslesung, Aufteilung in Abschnitte, Vektorisierung und Suchspeicher konfiguriert. Die Datenaufnahme zunächst mit einem repräsentativen Teilbestand testen.

    • Dokument-ID, Version, Mandant, Zugriffsgruppen, Gültigkeit und Quell-URL als Metadaten
    • Dokumente mit fehlenden oder ungültigen Zugriffsdaten aus der Suche ausschließen
    • Aktualisierungen und Löschungen in Quelle und Suchindex prüfen
    • Suchtreffer getrennt von der formulierten Antwort bewerten
  5. 05

    API, Authentifizierung und Rechte anbinden

    Cognito-Tokens am API Gateway prüfen. Die Anwendung muss Suchfilter serverseitig aus der überprüften Nutzeridentität und den zugehörigen Berechtigungen ableiten. Mandant und erlaubte Gruppen werden gemeinsam berücksichtigt. Fehlen gültige Zugriffsdaten, muss die Anfrage abgewiesen werden. Vom Browser frei übermittelte Filter dürfen keine Zugriffsrechte erweitern.

  6. 06

    Schutzfilter und Regeln für Antworten festlegen

    Bedrock Guardrails als zusätzliche Filter für unerwünschte Inhalte und sensible Informationen konfigurieren und testen. Sie ersetzen keine Zugriffskontrolle. Antworten sollen Quellen nennen; fehlen belastbare Fundstellen, soll das System dies deutlich sagen. Diese Regeln müssen auch mit irreführenden Dokumentinhalten geprüft werden.

  7. 07

    Qualität vor jeder Veröffentlichung prüfen

    Die automatisierte Bereitstellung so einrichten, dass Änderungen an Modell, Anweisungen, Datenaufbereitung oder Suchindex dieselben Testfragen durchlaufen. Eine Veröffentlichung wird gestoppt, wenn zuvor vereinbarte Qualitäts- oder Kostengrenzen verletzt werden.

  8. 08

    Überwachung einrichten und Betrieb übergeben

    Fehler, Antwortzeiten und Kosten mit CloudWatch überwachen; technische Abläufe und Änderungen nachvollziehbar protokollieren. Alarme, Betriebsanleitungen und Zuständigkeiten mit dem Betriebsteam abstimmen. Nutzerfeedback datensparsam erfassen und für weitere Testfragen nutzen.

Konfigurationsmuster

Konfiguration mit klaren Regeln.

Die Beispiele beschreiben die gewünschte Anwendungslogik und sind nicht direkt ausführbare AWS-Konfigurationen. Zahlenwerte sind projektspezifisch zu prüfende Startwerte, keine zugesagten Qualitäts-, Kosten- oder Leistungswerte.

# Pseudokonfiguration; im Projekt implementieren und testen.
application:
  name: csd-knowledge-assistant
  environment: production
  region: eu-central-1  # Verfügbarkeit vorher prüfen

auth:
  provider: cognito
  identity_source: verified_server_side_identity
  retrieval_filter_from: [tenant_id, security_groups]
  require_tenant_match: true
  require_allowed_group_match: true
  missing_or_invalid_access_data: deny

answer_contract:
  use_only_retrieved_context: true
  citations_required: true
  insufficient_evidence: "Keine belastbare Quelle gefunden."

limits:
  request_timeout_ms: 12000
  max_retrieved_chunks: 8
  max_context_tokens: 12000

Go-live-Check

Vor dem ersten echten Nutzer.

Die Checkliste bündelt wichtige Prüfpunkte vor dem Start. Welche Nachweise und Freigaben erforderlich sind, wird anhand des konkreten Projekts festgelegt.

  • Datenklassifizierung, Zweck und Löschfristen dokumentiert
  • Service- und Modellverfügbarkeit für Zielregion bestätigt
  • IAM-Rollen auf kleinste notwendige Rechte reduziert
  • S3 Public Access blockiert und KMS-Schlüssel geregelt
  • Mandanten- und Dokumentrechte einschließlich fehlender Zugriffsdaten getestet
  • Prompt-Injection- und Datenabflusstests bestanden
  • Quellenlinks führen auf autorisierte Originalstellen
  • Vereinbarte Testfragen mit der geplanten Version geprüft
  • Alarme für Fehler, Antwortzeit, Anfragelimits und Kosten aktiv
  • Betriebsanleitung, Rückkehr zur Vorversion und Verantwortliche festgelegt
  • Nutzerfeedback datensparsam und nachvollziehbar
  • Rechtliche Freigaben und Datenschutzhinweise erfolgt

Production Readiness

Bereit für mehr
als einen Prototyp?

CSD Becher entwickelt eine AWS-Architektur passend zu Ihren Daten, Zugriffsregeln und Qualitätszielen und begleitet die Einführung sowie die Übergabe an Ihr Betriebsteam.

Architekturgespräch

info@csd-becher.de ↗

Vorhandene AWS-Landschaft, Datenquellen und drei Kernfragen genügen für ein fokussiertes Erstgespräch.

AWS-Blueprint besprechen