BECHERCustom Software Development

Blueprint 03 · Production Architecture

Vom RAG-Prototyp
zum Cloud-Produkt.

Eine kommerzielle KI-Anwendung braucht mehr als Modell und Vector Store. Dieser AWS-Blueprint verbindet Daten, Zugriff, Retrieval, Guardrails, Evaluation und Betrieb zu einer belastbaren Gesamtarchitektur.

Von ·

Architekturprinzip

Managed,
wo es hilft.

Für einen schnellen, kontrollierten Einstieg kann Amazon Bedrock Knowledge Bases Ingestion, Chunking, Embeddings, Indexierung, Retrieval und Quellenzuordnung verwalten. Die Produktlogik bleibt davon getrennt und behält klare Schnittstellen.

AWS unterscheidet aktuell zwischen einer stärker verwalteten Knowledge Base und einer kundenseitig verwalteten Variante mit eigener Retrieval-Pipeline beziehungsweise eigenem Vector Store. Die richtige Wahl hängt von Datenquellen, Zugriffskontrolle, Anpassungstiefe, Lastprofil und Betriebsverantwortung ab.

Für kommerzielle Systeme gilt: Authentifizierung vor Retrieval, Least-Privilege-IAM, Verschlüsselung, getrennte Umgebungen, nachvollziehbare Modellaufrufe und eine Evaluation, die mit jedem Release wiederholbar ist.

AWS-Dokumentation zu Knowledge Bases ↗

Referenzarchitektur

Kommerzielle RAG-Anwendung auf AWS

Die Darstellung ist ein produktneutraler Startpunkt. Region, Services und Netzwerkgrenzen müssen für den konkreten Anwendungsfall validiert werden.

KMS · Verschlüsselung IAM · Least Privilege CloudWatch / CloudTrail · Observability CDK / CloudFormation · IaC

Technologieentscheidung

Der Vector Store folgt dem Lastprofil.

Eine spätere Migration ist möglich, aber nicht kostenlos. Filter, Mandantentrennung und Datenmodell gehören deshalb in den Architekturentscheid.

Option Passend, wenn … Stärke Früh prüfen
Managed Knowledge Base Time-to-market und wenig eigener Betrieb im Vordergrund stehen. Verwaltete Ingestion, Retrieval und erweiterte Konnektoren. Regionen, unterstützte Quellen, Kosten und benötigte Anpassungen.
OpenSearch Serverless Vektorsuche, Filter und skalierende Suchlast zentral sind. Search-native Funktionen und AWS-Integration. Index-Mapping, Kapazitätsuntergrenze, Mandantenmodell.
Aurora PostgreSQL Vektoren eng mit relationalen Geschäftsdaten verbunden sind. SQL, Transaktionen und vorhandenes PostgreSQL-Know-how. Indexstrategie, Connection Pooling, Skalierungsgrenzen.
Customer-managed Pipeline Chunking, Retrieval, Ranking oder Datenfluss stark angepasst werden müssen. Maximale Kontrolle und austauschbare Komponenten. Betriebsaufwand, Tests, Observability und Ownership.

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

    Scope, Risiko und KPIs festlegen

    Nutzer, Datenklassen, Geschäftsrisiko und Autonomiegrad dokumentieren. Golden Questions sowie Zielwerte für Retrieval, Groundedness, Latenz 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
    • Break-glass- und Administrationsrollen dokumentieren
  3. 03

    Datenzone und Governance 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

    Embedding-Modell, Parsing, Chunking, Vector Store und Metadatenmapping festlegen. Ingestion zunächst mit einem repräsentativen Teilbestand testen.

    • Dokument-ID, Version, ACL, Gültigkeit und Quell-URL als Metadaten
    • Incremental Sync und Löschverhalten verifizieren
    • Retrieval separat von der Antwort evaluieren
  5. 05

    API, Authentifizierung und Rechte anbinden

    Cognito-Tokens am API Gateway prüfen. Die Anwendung übersetzt Gruppen und Mandanten in Retrieval-Filter, bevor Kontext an das Modell gelangt.

  6. 06

    Guardrails und Antwortvertrag definieren

    Unerwünschte Inhalte, sensible Informationen, Prompt-Angriffe und verbotene Themen behandeln. Die Antwort enthält Quellen und einen klaren Fallback bei unzureichender Evidenz.

  7. 07

    Evaluation in CI/CD verankern

    Änderungen an Prompt, Modell, Embedding, Chunking oder Index führen den gleichen Evaluationssatz aus. Ein Release scheitert bei Qualitäts- oder Kostenregressionen.

  8. 08

    Observability und Betrieb übergeben

    CloudWatch-Metriken, strukturierte Logs, Trace-IDs, CloudTrail, Alarme und Runbooks einrichten. Feedback wird datensparsam erfasst und in den Evaluationssatz zurückgeführt.

Konfigurationsmuster

Explizite Verträge statt versteckter Annahmen.

Die Beispiele sind bewusst providernahe Pseudokonfiguration. Ressourcen-IDs, Modell-IDs und Regionen müssen im Projekt konkret validiert werden.

application:
  name: csd-knowledge-assistant
  environment: production
  region: eu-central-1  # Verfügbarkeit vorher prüfen

auth:
  provider: cognito
  retrieval_filter_from: [tenant_id, security_groups]

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 ersetzt keine Sicherheits- oder Rechtsprüfung, schafft aber einen belastbaren technischen Mindeststandard.

  • 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 im Retrieval getestet
  • Prompt-Injection- und Datenabflusstests bestanden
  • Quellenlinks führen auf autorisierte Originalstellen
  • Golden Questions gegen Release-Kandidat ausgeführt
  • Alarme für Fehler, Latenz, Throttling und Kosten aktiv
  • Runbooks, Rollback und verantwortliche Owner benannt
  • Nutzerfeedback datensparsam und nachvollziehbar
  • Rechtliche Freigaben und Datenschutzhinweise erfolgt

AWS · Offizielle Dokumentation

Blueprint-Grundlagen

Amazon Bedrock Knowledge Bases↗ AWS Prescriptive Guidance: Fully managed RAG↗ Amazon Bedrock Guardrails↗ AWS Well-Architected Generative AI Lens↗

Production Readiness

Bereit für mehr
als einen Prototyp?

CSD Becher übersetzt Ihren Anwendungsfall in eine sichere, messbare und betreibbare AWS-Architektur.

Architekturgespräch

info@csd-becher.de ↗

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

AWS-Blueprint besprechen