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.
01 · Zugang
02 · Anwendung
03 · KI-Schicht
04 · Wissen
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.
-
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. -
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.
-
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.
-
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
-
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.
-
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
-
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.
-
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.
-
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.
-
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
# Pseudokonfiguration; Zahlenwerte im Projekt erproben. ingestion: source_bucket: approved-knowledge quarantine_prefix: incoming/ approved_prefix: published/ preserve_source_version: true missing_or_invalid_access_metadata: exclude_from_search chunking: strategy: semantic_with_heading_context target_tokens: 700 overlap_tokens: 100 metadata_required: - document_id - source_version - owner - valid_from - tenant_id - security_groups - canonical_url
# Beispielwerte, keine Zusagen oder allgemeingültigen Grenzwerte.
quality_gate:
dataset: golden-questions-v3
compare_against: current-production
retrieval:
context_recall_min: 0.90
source_hit_rate_min: 0.92
generation:
groundedness_min: 0.95
citation_coverage_min: 0.95
operations:
p95_latency_ms_max: 5000
cost_per_answer_eur_max: 0.08
release_on_regression: block
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
AWS · Offizielle Dokumentation
Blueprint-Grundlagen
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