Ein Leitfaden zu RAG System AWS für Entwickler und Unternehmen

Autor: Provimedia GmbH

Veröffentlicht:

Aktualisiert:

Kategorie: KI-Tools & Workflows

Zusammenfassung: Ein RAG-System auf AWS sollte Daten, Wissenssuche, Anwendung und Governance klar trennen sowie Quellen, Metadaten, Berechtigungen und Qualität systematisch berücksichtigen.

RAG System on AWS: Architektur und Zielbild für Unternehmen

Ein RAG System on AWS sollte nicht als einzelner Dienst, sondern als klar abgegrenzte Plattform für eine konkrete Geschäftsaufgabe geplant werden. Das Zielbild besteht aus drei Ebenen: einer Datenebene für verlässliche Unternehmensinhalte, einer Anwendungsebene für Suche und Antwortlogik sowie einer Betriebsebene für Kontrolle, Kosten und Qualität.

Für Entwickler ist diese Trennung wichtig. Sie erlaubt, einzelne Bausteine auszutauschen, ohne die gesamte Anwendung neu zu bauen. Unternehmen gewinnen zugleich einen belastbaren Rahmen für Skalierung, Zuständigkeiten und Freigaben. Die AWS-Seite „What is RAG? – Retrieval-Augmented Generation“ beschreibt dazu das Grundprinzip: RAG verbindet ein Sprachmodell mit externem Wissen, das zur Anfrage dynamisch bereitgestellt wird.

Ein sinnvolles Zielbild für ein RAG System on AWS sieht so aus:

Für die Architekturentscheidung zählt zuerst der Anwendungsfall. Ein interner Assistent für Richtlinien braucht andere Regeln als eine technische Suchanwendung mit Versionsvergleich. Bei vertraulichen Inhalten ist außerdem entscheidend, ob Antworten nur innerhalb einer Organisation erscheinen dürfen oder ob mehrere Mandanten bedient werden. Diese Frage beeinflusst Datenmodell, Netzgrenzen und Berechtigungsprüfung von Anfang an.

Vollständig verwaltete Optionen auf AWS verkürzen den Weg zu einem ersten nutzbaren System. Dazu zählen Knowledge Bases for Amazon Bedrock, Amazon Q Business und Amazon SageMaker AI Canvas. Sie können Datenaufnahme, Suchindex und Modellanbindung bündeln. Der Preis dafür ist weniger Feintuning bei Ranking, Chunking und eigener Orchestrierung. Für stark spezialisierte Anwendungen bleibt daher eine individuell zusammengesetzte Pipeline oft die bessere Wahl.

Unternehmen sollten das Zielbild an messbaren Ergebnissen ausrichten: Wie oft wird eine Antwort korrekt belegt? Wie schnell erscheint sie? Welche Daten dürfen verarbeitet werden? Und was kostet eine Anfrage bei 10.000 oder 1 Million Dialogen pro Monat? Ohne diese Leitplanken wird ein RAG-Projekt schnell zur hübschen Demo, die im Alltag knirscht.

Für die technische Umsetzung empfiehlt sich eine entkoppelte Schnittstelle zwischen Anwendung und Wissenssuche. So kann das Team den Suchdienst oder das Modell wechseln, ohne die Benutzeroberfläche zu verändern. Jede Antwort sollte zudem ihre verwendeten Quellen als interne Referenzen mitführen. Das schafft Nachvollziehbarkeit und erleichtert die Analyse fehlerhafter Ergebnisse.

Datenquellen und Konnektoren für AWS-RAG-Systeme

Für ein RAG System on AWS entscheidet nicht nur die Menge der Daten. Ausschlaggebend ist, ob ein Konnektor verlässliche, aktuelle und fachlich passende Inhalte liefert. Eine kleine, gut gepflegte Wissensbasis schlägt oft ein riesiges Archiv voller Duplikate und veralteter Dateien.

Typische Quellen sind Dokumentenablagen, Wikis, Ticketsysteme, Quellcode, Webseiten und relationale Datenbanken. Bei Cloud-Speichern sollten Dateien nicht einfach ungefiltert übernommen werden. Besser ist eine Auswahl nach Ordner, Dateityp, Änderungsdatum oder fachlicher Domäne. So bleibt der Index schlank und die Suche erhält weniger Störsignale.

Ein Konnektor hat im RAG System on AWS mehr Aufgaben als das bloße Kopieren von Dateien. Er muss Authentifizierung, Änderungsabgleich, Löschungen und Fehlerzustände sauber behandeln. Besonders wichtig: Wird eine Quelle gelöscht oder der Zugriff entzogen, muss diese Änderung auch im Suchbestand ankommen. Sonst liefert das System Inhalte, die längst nicht mehr gelten.

Für strukturierte Daten reicht ein Dateikonnektor nicht aus. Ein Datensatz benötigt eine verständliche Textdarstellung, etwa aus Produktnummer, Status, Zeitraum und Beschreibung. Zahlenfelder sollten dabei nicht beliebig in Fließtext verwandelt werden. Für Preislisten, Bestände oder Finanzwerte ist eine präzise Filterabfrage häufig geeigneter als eine rein semantische Suche.

Metadaten machen diese Unterscheidung praktisch nutzbar. Sinnvolle Felder sind etwa source_system, document_id, department, language, valid_from, valid_to und classification. Mit solchen Angaben kann die Anwendung gezielt nach Abteilung, Sprache oder Gültigkeitszeitraum filtern. Das erhöht die Trefferqualität und verhindert, dass eine alte Richtlinie neben einer aktuellen als gleichwertig erscheint.

Beim Vergleich verwalteter AWS-Dienste sollten Entwickler deshalb zuerst die verfügbaren Quellen und deren Synchronisationslogik prüfen. Nicht jeder Dienst unterstützt dieselben Systeme. Auch die erlaubten Dateiformate, Aktualisierungsintervalle und Filteroptionen können abweichen. Eine Konnektor-Matrix mit Quelle, Eigentümer, Aktualität, Berechtigungen und erwarteter Dokumentzahl schafft hier rasch Klarheit.

Ein robuster Import braucht zudem einen Quarantänepfad. Nicht lesbare Dateien, beschädigte Scans oder ungewöhnlich große Dokumente dürfen den gesamten Lauf nicht stoppen. Der Konnektor sollte Fehler protokollieren, Wiederholungen begrenzen und betroffene Datensätze zur Nachbearbeitung markieren. Das klingt unspektakulär, spart im Betrieb aber viel Ärger.

Für ein neues RAG System on AWS genügt meist ein klar begrenzter Datenbereich. Starten Sie beispielsweise mit einer freigegebenen Richtliniensammlung und dokumentieren Sie Quelle, Besitzer und Aktualisierungsrhythmus. Erst wenn diese Strecke stabil läuft, lohnt sich die Anbindung weiterer Systeme. So bleibt sichtbar, ob ein Problem am Konnektor, am Inhalt oder an der späteren Suche liegt.

Vergleich wichtiger AWS-Optionen für ein RAG-System

AWS-Option Geeignet für Stärken Zu beachten
Knowledge Bases for Amazon Bedrock Schnelle Umsetzung wissensgestützter Anwendungen Verwaltete Datenaufnahme, Suche und Modellanbindung; kurze Integrationszeit Weniger Kontrolle über Chunking, Ranking und individuelle Retrieval-Logik
Amazon Q Business Interner Unternehmensassistent für Mitarbeitende Dialogorientierte Nutzung, zentrale Administration und Fokus auf Organisationswissen Weniger geeignet für stark individualisierte Produktfunktionen oder Speziallogik
Amazon SageMaker AI Canvas Visuelle Exploration und frühe Prototypen Geringer Programmieraufwand und schnelle Erprobung datenbezogener Ideen Produktive RAG-Anwendungen müssen hinsichtlich Funktionen und Integrationen geprüft werden
Individuelle AWS-RAG-Pipeline Spezialisierte Unternehmens- und Produktanwendungen Maximale Kontrolle über Datenaufbereitung, hybride Suche, Ranking, Modelle und Schnittstellen Höherer Entwicklungs-, Betriebs- und Wartungsaufwand

Dokumente aufbereiten, teilen und indexieren

Beim RAG System on AWS entscheidet die Dokumentaufbereitung oft stärker über die Antwortqualität als die Wahl des Sprachmodells. Ein gutes Dokument ist für Menschen lesbar, für Maschinen eindeutig und fachlich klar begrenzt. Ziel ist nicht, möglichst viele Dateien zu indexieren. Ziel ist ein Bestand, in dem jede Textstelle einen erkennbaren Zweck erfüllt.

Beginnen Sie mit einer Inhaltsinventur. Erfassen Sie für jedes Dokument Eigentümer, Version, Sprache, Gültigkeitszeitraum und Freigabestatus. Entfernen Sie Entwürfe, Duplikate und abgelaufene Fassungen. Bei Richtlinien sollte nur die aktuell freigegebene Version auffindbar sein. Alte Versionen können in einem getrennten Archiv verbleiben, dürfen aber nicht versehentlich als aktuelle Grundlage erscheinen.

Vor dem Teilen wird der Inhalt normalisiert. Kopf- und Fußzeilen, Seitenzahlen, wiederholte Menüs sowie OCR-Fehler erzeugen sonst künstliche Treffer. Tabellen brauchen besondere Aufmerksamkeit: Eine Zeile ohne Spaltenüberschrift verliert beim späteren Abruf ihre Bedeutung. Fügen Sie deshalb die Überschrift in jeden logisch geschlossenen Abschnitt ein. Auch Bildbeschreibungen, Fußnoten und Querverweise sollten nicht wortlos verschwinden.

Beim Teilen eines Dokuments im RAG System on AWS sollte ein Abschnitt eine eigenständige Aussage enthalten. Zu kleine Stücke verlieren den Zusammenhang. Zu große Stücke bringen dagegen viel Ballast in den Prompt. Als praktischer Startpunkt eignen sich etwa 300 bis 800 Wörter pro Abschnitt. Das ist kein Naturgesetz: Überschriften, Listen und Satzgrenzen sind wichtiger als eine starre Zeichenzahl.

Nutzen Sie eine leichte Überlappung, wenn Sätze über Abschnittsgrenzen hinweg zusammengehören. Bei stark strukturierten Handbüchern ist eine hierarchische Aufteilung meist besser: Dokument, Kapitel, Unterkapitel und Absatz werden als getrennte Metadaten gespeichert. So kann die Anwendung einen präzisen Abschnitt abrufen und bei Bedarf den übergeordneten Kontext ergänzen.

Jeder Abschnitt braucht eine stabile Kennung. Kombinieren Sie beispielsweise Dokument-ID, Version und Abschnittsnummer. Speichern Sie zusätzlich den Originalpfad, den Abschnittstitel und den Zeitpunkt der Verarbeitung. Diese Angaben helfen bei Nachfragen, bei erneuten Importen und beim gezielten Entfernen einzelner Inhalte.

Für verwaltete RAG-Dienste auf AWS ist die Indexierung eng an das gewählte Angebot gebunden. Prüfen Sie daher vor dem Import, welche Segmentierungsregeln, Dateigrößen und Metadatenfilter verfügbar sind. Bei einer eigenen Pipeline können Sie diese Regeln selbst bestimmen. Der Aufwand steigt dann allerdings deutlich, besonders bei erneuter Verarbeitung und Versionswechseln.

Ein sauberer Index entsteht in mehreren Durchläufen. Testen Sie zunächst mit echten Fragen aus dem Fachbereich und prüfen Sie, ob der gefundene Abschnitt die Antwort vollständig trägt. Werden regelmäßig Nachbarabschnitte benötigt, ist die Aufteilung zu eng. Enthalten Treffer dagegen viele irrelevante Passagen, ist sie vermutlich zu breit oder schlecht bereinigt.

Die Dokumentqualität sollte als messbarer Prozess behandelt werden. Erfassen Sie den Anteil erfolgreich gelesener Dateien, die Zahl veralteter Inhalte und die Quote unvollständiger Abschnitte. Ein monatlicher Bericht genügt zu Beginn. So wird aus Datenpflege kein Bauchgefühl, sondern eine überprüfbare Grundlage für ein belastbares RAG System on AWS.

Embeddings und Vektorsuche in einer RAG-Pipeline

In einem RAG System on AWS bestimmen Embeddings, welche Inhalte als ähnlich gelten. Ein Embedding-Modell wandelt Text in einen Vektor mit vielen Zahlen um. Ähnliche Bedeutungen liegen dabei im Vektorraum näher beieinander, auch wenn die verwendeten Wörter nicht identisch sind.

Für die Suche müssen Dokumentabschnitte und Nutzerfragen mit demselben Embedding-Modell verarbeitet werden. Ein Wechsel des Modells verändert den Vektorraum. Bereits gespeicherte Vektoren sind dann meist nicht mehr direkt vergleichbar und müssen neu erzeugt werden. Diese Abhängigkeit gehört in die Versionsverwaltung.

Entscheidend ist außerdem die Dimension des Vektors. Ein Modell kann beispielsweise 768, 1.024 oder 3.072 Werte erzeugen. Die verwendete Vektorsuche muss genau zu dieser Dimension passen. Auch die Distanzmetrik beeinflusst das Ergebnis:

Bei einem RAG System on AWS sollte die Wahl nicht nach dem Namen des Dienstes erfolgen, sondern anhand eines kleinen Testbestands. Verwenden Sie reale Fragen mit bekannten Zielabschnitten. Messen Sie, ob der richtige Abschnitt unter den ersten drei oder fünf Treffern erscheint. Diese Kennzahl heißt oft Recall@k. Sie zeigt, ob die Suche relevante Belege überhaupt findet.

Eine hohe semantische Ähnlichkeit bedeutet jedoch nicht automatisch fachliche Relevanz. Ein allgemeiner Abschnitt kann sprachlich gut zur Frage passen, aber die falsche Produktversion oder Region betreffen. Kombinieren Sie deshalb die Vektorsuche mit Metadatenfiltern. Filter für Sprache, Mandant, Gültigkeit oder Dokumenttyp wirken häufig stärker als ein größeres Sprachmodell.

Für Fachbegriffe, Artikelnummern und exakte Fehlermeldungen ist eine hybride Suche besonders nützlich. Sie verbindet semantische Treffer mit klassischer Schlüsselwortsuche. So findet das System sowohl einen sinngleichen Absatz als auch die konkrete Zeichenfolge ERR-2048. Das ist im technischen Support kein Luxus, sondern ziemlich wichtig.

Die Anzahl der abgerufenen Treffer sollte kontrolliert bleiben. Bei vielen Treffern wächst der Kontext, während die Qualität nicht zwingend steigt. Ein sinnvoller Startwert liegt oft bei drei bis acht Abschnitten. Danach sollten Sie prüfen, ob ein Ranking-Schritt die besten Ergebnisse neu sortiert. Ein sogenannter Reranker bewertet Frage und Treffer gemeinsam und kann bei ähnlichen Passagen deutliche Verbesserungen bringen.

Auch die Anfrage selbst darf vor der Suche verändert werden. Bei kurzen Fragen wie „Und was gilt für Österreich?“ fehlt der Bezug zum vorherigen Dialog. Eine Anfrageumschreibung kann daraus eine vollständige Suchfrage bilden. Dieser Schritt sollte sparsam eingesetzt werden, weil jede Umformulierung neue Fehler einführen kann.

In verwalteten AWS-Angeboten werden Modellwahl, Index und Suchparameter teilweise vorgegeben. Bei einer eigenen Pipeline lassen sich Embedding-Modell, Distanzmetrik, Filter und Reranking getrennt testen. Dokumentieren Sie dabei Modellversion, Vektordimension, Normalisierung und Indexkonfiguration. Ohne diese Angaben ist ein späterer Vergleich kaum belastbar.

Eine gute Qualitätsprüfung bewertet nicht nur den Treffer, sondern auch die Antwortgrundlage. Für jede Testfrage sollte feststehen, welche Abschnitte relevant sind, ob ein Filter greifen muss und welche Information keinesfalls fehlen darf. So wird sichtbar, ob ein Fehler aus dem Embedding, dem Ranking oder der Datenstruktur stammt.

Retriever, Orchestrator und Foundation Model verbinden

In einem RAG System on AWS entsteht die eigentliche Anwendungslogik an der Übergabe zwischen Suche und Modell. Der Retriever liefert nicht einfach eine Trefferliste. Er gibt strukturierte Ergebnisse mit Rang, Abschnittskennung und Herkunft zurück. Der Orchestrator entscheidet anschließend, welche dieser Ergebnisse in die Modellanfrage gelangen.

Diese Trennung verhindert eine häufige Fehlkonstruktion: Das Foundation Model sollte nicht selbst festlegen, welche internen Daten es sehen darf. Diese Entscheidung gehört in eine überprüfbare Anwendungsschicht. Das Modell formuliert die Antwort; der Orchestrator kontrolliert Ablauf, Kontext und Rückgabestruktur.

Ein belastbares Übergabeformat kann neben dem Text mindestens folgende Felder enthalten:

Der Orchestrator sollte vor dem Modellaufruf drei Prüfungen durchführen. Erstens muss er erkennen, ob überhaupt ein ausreichender Treffer vorliegt. Zweitens muss er den Kontext auf ein festes Tokenbudget begrenzen. Drittens muss er den Dialogverlauf von den gefundenen Belegen trennen. Sonst verdrängt ein langer Chat frühere, aber wichtige Suchergebnisse.

Für das Prompt-Design bewährt sich eine klare Rollenverteilung. Systemanweisungen definieren Aufgabe und Ausgabeformat. Die Nutzerfrage bleibt unverändert erkennbar. Abgerufene Inhalte werden als Belegmaterial markiert. Eine solche Struktur reduziert die Gefahr, dass Anweisungen innerhalb eines Dokuments mit der eigentlichen Steuerung verwechselt werden.

Das Foundation Model sollte eine Antwort auch ablehnen dürfen. Fehlen belastbare Treffer, ist „Dazu liegen keine ausreichenden Informationen vor“ besser als eine plausible Erfindung. Der Orchestrator kann dafür einen Schwellenwert verwenden oder eine separate Antwortklasse wie insufficient_context zurückgeben.

Bei mehrteiligen Fragen reicht ein einzelner Abruf nicht immer aus. Der Orchestrator kann die Frage in Teilfragen zerlegen, jede separat suchen und die Ergebnisse anschließend zusammenführen. Das eignet sich etwa für Vergleiche, Ursachenanalysen oder Fragen mit mehreren Produkten. Die Zerlegung sollte begrenzt bleiben, damit Laufzeit und Kosten nicht aus dem Ruder laufen.

Für AWS-Anwendungen ist außerdem die Wahl des Modellzugriffs relevant. Eine verwaltete Schnittstelle kann den Aufruf verschiedener Foundation Models vereinheitlichen. Die Anwendung sollte dennoch ein eigenes internes Antwortschema nutzen. Dazu gehören etwa Antworttext, Belegstellen, Status und technische Kennzahlen. Ein späterer Modellwechsel wird dadurch deutlich weniger riskant.

Beobachten Sie die Kette getrennt: Suchdauer, Anzahl der Treffer, Kontextgröße, Modelllaufzeit und Ausgabeumfang. Eine langsame Antwort entsteht nicht zwingend beim Foundation Model. Häufig wartet der Orchestrator auf eine langsame Quelle oder übergibt zu viel Kontext. Ohne diese Aufteilung bleibt die Fehlersuche im Nebel.

Knowledge Bases for Amazon Bedrock als verwaltete RAG-Option

Knowledge Bases for Amazon Bedrock eignen sich für Unternehmen, die ein RAG System on AWS mit wenig eigener Infrastruktur umsetzen möchten. Der Dienst verbindet eine Wissensbasis mit einem Foundation Model und übernimmt zentrale Schritte der Verwaltung. Dazu gehören die Konfiguration der Datenquelle, die Aufbereitung für die Suche und der Abruf passender Inhalte zur Anfrage.

Für Entwickler liegt der Vorteil vor allem in der kurzen Integrationsstrecke. Eine Anwendung kann die Wissensbasis über eine API ansprechen, statt eigene Abläufe für Indexpflege und Suchanfragen zu betreiben. Die Antwortlogik bleibt dabei in der Anwendung steuerbar. Das ist praktisch, wenn ein Team schnell einen internen Assistenten, eine technische Suche oder eine wissensgestützte Kundenanwendung testen möchte.

Der Dienst unterstützt je nach Konfiguration verschiedene Datenquellen. Dazu können beispielsweise Inhalte aus einem Objektspeicher, Webseiten, Atlassian Confluence oder Microsoft SharePoint gehören. Vor der Auswahl sollten Teams die aktuelle AWS-Dokumentation prüfen, da unterstützte Quellen, Regionen, Dateiformate und Funktionen Änderungen unterliegen können.

Ein wichtiger Architekturpunkt ist die Trennung von Wissensbasen. Vermischen Sie nicht automatisch Personalrichtlinien, Produktdokumentation und Supportfälle in einem gemeinsamen Bestand. Besser sind klar definierte Wissensdomänen mit eigenen Verantwortlichen. Dadurch lassen sich Aktualität, Zugriff und fachliche Zuständigkeit leichter prüfen.

Die verwaltete Variante hat Grenzen. Entwickler können nicht jeden Verarbeitungsschritt beliebig verändern. Spezielle Chunking-Regeln, eigene Rankingverfahren oder fachliche Suchalgorithmen sind daher weniger flexibel als in einer selbst gebauten Pipeline. Für Standardfälle ist diese Einschränkung oft akzeptabel. Bei regulierten oder sehr spezialisierten Anwendungen sollte sie in einem frühen Proof of Concept geprüft werden.

Auch die Kostenplanung verdient Aufmerksamkeit. Relevant sind unter anderem Speicher, Datenverarbeitung, Suchanfragen und Modellaufrufe. Ein Lasttest mit realistischen Anfragezahlen zeigt besser als eine einzelne Demo, ob die Lösung wirtschaftlich bleibt. Protokollieren Sie außerdem Antwortdauer und Fehlerraten getrennt, denn schnelle Suche und langsame Generierung haben unterschiedliche Ursachen.

Für ein RAG System on AWS mit Knowledge Bases empfiehlt sich ein klarer Abnahmetest:

Amazon Q Business und Amazon SageMaker AI Canvas im Vergleich

Amazon Q Business und Amazon SageMaker AI Canvas verfolgen unterschiedliche Ziele. Für ein RAG System on AWS ist deshalb weniger die Frage entscheidend, welcher Dienst „besser“ ist. Wichtiger ist, ob ein fertiger Unternehmensassistent oder ein stärker anpassbarer Entwicklungsweg gebraucht wird.

Amazon Q Business richtet sich an Fachabteilungen und Unternehmen, die interne Informationen über eine dialogorientierte Anwendung nutzbar machen möchten. Die Lösung ist auf Fragen zu Organisationswissen ausgelegt. Der Schwerpunkt liegt auf einer schnellen Bereitstellung, zentraler Administration und einer Nutzung durch Mitarbeitende ohne eigene ML-Pipeline.

Amazon SageMaker AI Canvas zielt dagegen auf die Entwicklung und Erprobung datenbezogener Anwendungen mit geringem Programmieraufwand. Es kann für Teams interessant sein, die Modelle, Datenflüsse und Prototypen fachnah untersuchen möchten. Für einen produktiven, frei gestalteten RAG-Chat ist jedoch zu prüfen, welche Funktionen tatsächlich verfügbar sind und ob sie den gewünschten Ablauf abdecken.

Die Unterschiede lassen sich so einordnen:

Für die Auswahl sollten Unternehmen vier praktische Fragen beantworten. Wer erstellt und pflegt die Anwendung? Wie viel technische Kontrolle ist erforderlich? Soll das Ergebnis primär ein Mitarbeiterassistent oder ein eingebettetes Produktfeature sein? Und benötigt das Team reproduzierbare Entwicklungs- und Freigabeprozesse?

Amazon Q Business passt eher zu einem klaren Geschäftsziel wie „Mitarbeitende finden schnell interne Vorgaben“. Der Nutzen lässt sich über Sucherfolg, Bearbeitungszeit und Nutzungshäufigkeit bewerten. SageMaker AI Canvas passt eher zu einer frühen Untersuchungsphase, in der Teams Hypothesen zu Daten und Modellen testen. Das sind zwei verschiedene Betriebsmodi, auch wenn beide mit generativer KI verbunden werden können.

Ein häufiger Fehler ist, einen Prototypen mit einer fertigen Unternehmensanwendung gleichzusetzen. Ein visueller Versuch kann zeigen, dass ein Anwendungsfall grundsätzlich funktioniert. Er beantwortet aber nicht automatisch Fragen zu Mandantenfähigkeit, Schnittstellen, Last, Protokollierung oder Kosten. Diese Lücke muss vor dem Übergang in den Alltag geschlossen werden.

Für ein RAG System on AWS empfiehlt sich ein kurzer Entscheidungstest:

Die AWS-Dokumentation, darunter der Leitfaden zur Auswahl von RAG-Optionen, liefert den technischen Rahmen. Die konkrete Entscheidung sollte dennoch aus dem eigenen Nutzungsszenario entstehen. Kurz gesagt: Amazon Q Business ist der naheliegendere Weg zum verwalteten Unternehmensassistenten; SageMaker AI Canvas ist eher ein Werkzeug für visuelle Exploration und frühe Entwicklung. Die aktuellen Funktionsgrenzen sollten vor einer Festlegung in der offiziellen AWS-Dokumentation geprüft werden.

Individuelle RAG-Architekturen auf AWS für mehr Kontrolle

Eine individuelle RAG-Architektur auf AWS lohnt sich, wenn Standarddienste die fachlichen oder technischen Anforderungen nicht abdecken. Der größte Vorteil ist die gezielte Kontrolle über Suchlogik, Datenflüsse, Modellwahl und Betriebsgrenzen. Der Preis: Das Unternehmen übernimmt mehr Entwicklungs- und Wartungsarbeit.

Ein flexibler Aufbau kann verschiedene AWS-Bausteine kombinieren. Ein Objektspeicher dient als unveränderliche Rohdatenablage. Eine serverlose Funktion oder ein Container verarbeitet neue Dokumente. Ein Workflow-Dienst steuert lange Verarbeitungsschritte und Wiederholungen. Die erzeugten Embeddings landen anschließend in einem passenden Vektorindex. Für die Antwortgenerierung wird eine Modelllaufzeit über eine klar definierte Anwendungsschnittstelle angesprochen.

Diese Entkopplung ermöglicht gezielte Änderungen. Das Embedding-Modell kann unabhängig vom Antwortmodell aktualisiert werden. Ein neues Rankingverfahren lässt sich testen, ohne die Rohdaten erneut zu importieren. Auch unterschiedliche Suchstrategien für Support, Recht oder Technik sind möglich. Genau diese Beweglichkeit macht ein RAG System on AWS für komplexe Unternehmensprodukte interessant.

Entwickler sollten die Pipeline als mehrere austauschbare Verträge gestalten:

Für hohe Verfügbarkeit sollte die Anwendung zustandsarm bleiben. Sitzungsdaten gehören in einen dafür geeigneten Speicher; einzelne Anfrageprozesse dürfen nicht an einen bestimmten Server gebunden sein. Zeitaufwendige Indexläufe sollten über Warteschlangen entkoppelt werden. So blockiert ein fehlerhaftes Dokument nicht den gesamten Import. Bei Lastspitzen können Verarbeitung und Antwortpfad getrennt skaliert werden.

Ein eigener Ansatz ist besonders nützlich, wenn mehrere Sucharten zusammenkommen. Ein System kann etwa zuerst strukturierte Filter anwenden, danach semantisch suchen und zum Schluss fachliche Regeln über die Treffer legen. Für Produktkataloge, Ersatzteile oder Vertragsklauseln ist diese Reihenfolge oft genauer als eine reine Vektorsuche.

Mehr Kontrolle bedeutet auch mehr Verantwortung. Das Team muss Lebenszyklen für Indizes, Modellversionen und Schnittstellen definieren. Jede Änderung braucht eine reproduzierbare Konfiguration. Infrastruktur als Code, getrennte Entwicklungsumgebungen und automatisierte Tests verhindern, dass eine Änderung in der Konsole unbemerkt den Produktivbetrieb verändert.

Für sensible Anwendungen sollte die Architektur Datenflüsse sichtbar machen: Welche Komponente verarbeitet welchen Inhalt? Wo entstehen temporäre Kopien? Welche Logs enthalten Nutzereingaben? Antworten auf diese Fragen gehören in ein technisches Datenflussdiagramm. Zusätzlich können private Netzwerkpfade, verschlüsselte Verbindungen und kurzlebige Zugriffstoken erforderlich sein.

Ein eigenes RAG System on AWS ist nicht automatisch günstiger. Die laufenden Kosten für Suchindex, Datenverarbeitung, Modellaufrufe, Monitoring und Bereitschaftsdienst werden leicht unterschätzt. Wirtschaftlich wird der Ansatz vor allem dann, wenn die zusätzliche Kontrolle einen konkreten Nutzen bringt: bessere Treffer, spezielle Integrationen, strenge Latenzvorgaben oder ein differenziertes Mandantenmodell.

IAM, Guardrails und Datenschutz im produktiven Betrieb

Ein produktives RAG System on AWS braucht eine Sicherheitsarchitektur, die Zugriffe nicht nur beim Login, sondern bei jeder Anfrage prüft. Entscheidend ist die Kombination aus Identität, Datenkontext und Zweck. Ein Mitarbeiter darf zum Beispiel interne Personalrichtlinien sehen, aber nicht automatisch vertrauliche Vertragsdaten derselben Organisation.

Vergeben Sie Berechtigungen nach dem Prinzip der geringsten Rechte. Anwendungen sollten eigene IAM-Rollen erhalten. Dauerhafte Zugangsschlüssel gehören nicht in Quellcode, Container oder Konfigurationsdateien. Für kurzlebige Aufgaben sind temporäre Anmeldeinformationen vorzuziehen. Trennen Sie außerdem Rollen für Entwicklung, Test und Produktion. Ein Entwicklerkonto sollte niemals direkt auf produktive Unternehmensdaten zugreifen können.

IAM allein reicht bei einem RAG System on AWS nicht aus. Die Anwendung muss die Identität bis zur Retrieval-Anfrage weiterreichen. Erst dann kann sie Dokumente anhand von Mandant, Abteilung, Projekt oder Schutzklasse begrenzen. Eine nachträgliche Filterung des fertigen Antworttexts ist riskant: Der Retriever könnte sensible Inhalte bereits an das Modell übertragen haben.

Guardrails sollten auf mehreren Ebenen wirken. Eingaben können unerlaubte Themen, Prompt-Injection-Muster oder gefährliche Handlungsaufforderungen enthalten. Abgerufene Dokumente können wiederum eigene Anweisungen einschleusen. Das Modell muss solche Inhalte als Daten behandeln, nicht als Befehle. Zusätzlich sollten Ausgaben auf verbotene Inhalte, personenbezogene Daten und unzulässige Empfehlungen geprüft werden.

Eine robuste Regel lautet: Das System beantwortet nur Fragen innerhalb seiner freigegebenen Wissensdomäne. Für unbekannte oder nicht berechtigte Inhalte gibt es eine neutrale Rückmeldung. Diese Begrenzung lässt sich über Themenfilter, Antwortklassen und einen kontrollierten Abbruch umsetzen. Freie Improvisation klingt angenehm, ist im Unternehmensbetrieb aber eine schlechte Sicherheitsstrategie.

Beim Datenschutz zählt der gesamte Lebenszyklus einer Anfrage. Prüfen Sie, ob Nutzereingaben, Suchtreffer und Modellantworten gespeichert werden müssen. Reduzieren Sie Protokolle auf das notwendige Maß und maskieren Sie personenbezogene Daten, bevor sie in Diagnose- oder Analysesysteme gelangen. Definieren Sie Löschfristen für Gesprächsdaten, temporäre Dateien und Fehlermeldungen.

Für personenbezogene Informationen gelten je nach Anwendungsfall unter anderem die Datenschutz-Grundverordnung, vertragliche Pflichten und interne Richtlinien. Eine Datenschutz-Folgenabschätzung kann erforderlich sein, wenn sensible Daten systematisch verarbeitet oder Personen bewertet werden. Der EU AI Act gilt risikobasiert; Pflichten hängen unter anderem von Zweck, Rolle und Risikoklasse des Systems ab. Rechtsberatung ersetzt diese technische Prüfung nicht.

Verschlüsselung sollte sowohl gespeicherte Daten als auch Übertragungen abdecken. Verwenden Sie getrennte Schlüssel oder Schlüsselbereiche für unterschiedliche Schutzklassen, wenn die Risikobewertung dies verlangt. Netzwerkzugriffe lassen sich durch private Endpunkte, eingeschränkte Sicherheitsgruppen und klar definierte Ausnahmen begrenzen. Jede Ausnahme braucht einen Eigentümer und ein Ablaufdatum.

Für die laufende Kontrolle eines RAG System on AWS sind Sicherheitsereignisse getrennt von normalen Leistungsdaten auszuwerten. Achten Sie etwa auf ungewöhnlich viele Anfragen, wiederholte Zugriffsfehler, auffällige Exportmengen und unerwartete Rollenwechsel. Ein Alarm sollte nicht nur ausgelöst, sondern auch mit einer konkreten Reaktion verbunden werden: Zugriff sperren, Sitzung beenden oder Quelle vorübergehend aus dem Abruf nehmen.

Dokumentieren Sie schließlich, welche Daten verarbeitet werden, welche Rollen darauf zugreifen dürfen und welche Guardrails aktiv sind. Für den Betrieb kommen zur technischen Verbindung von Abruf und Generierung Risikoanalyse, Datenschutzkonzept und Zugriffskontrollen hinzu. Erst dieses Zusammenspiel macht die Lösung für Unternehmen vertretbar.

RAG-Systeme auf AWS testen, messen und skalieren

RAG-Systeme auf AWS sollten vor dem Produktivstart mit einem festen Prüfverfahren bewertet werden. Entscheidend sind nicht nur korrekte Antworten. Auch Quellenabdeckung, Antwortzeit, Fehlerraten und Kosten pro Anfrage müssen unter realistischen Bedingungen messbar sein.

Erstellen Sie dafür einen Referenzdatensatz mit echten, anonymisierten Fragen aus dem späteren Einsatz. Jede Frage erhält eine erwartete Antwort, relevante Belegstellen und eine Bewertungsskala. Trennen Sie dabei Faktenfragen, Vergleiche, mehrdeutige Fragen und Fälle ohne ausreichende Daten. So zeigt der Test, ob das RAG System on AWS auch bei schwierigen Eingaben stabil bleibt.

Bewerten Sie Such- und Antwortqualität getrennt. Ein Treffer kann relevant sein, während das Modell ihn falsch zusammenfasst. Umgekehrt kann eine flüssige Antwort auf schwachen Belegen beruhen. Ein kleiner Test mit 100 bis 300 sorgfältig ausgewählten Fragen ist oft aussagekräftiger als tausende zufällige Anfragen.

Für automatisierte Prüfungen eignen sich Regeln wie Quellenpflicht, Antwortlänge und verbotene Ausgaben. Ergänzen Sie diese durch Stichproben fachkundiger Personen. Bei jeder Änderung an Suchparametern, Prompts oder Modellen sollte derselbe Referenzdatensatz erneut laufen. Ein Ergebnisvergleich macht sichtbar, ob eine Verbesserung wirklich trägt oder nur einzelne Beispiele verschönert.

Im Betrieb braucht ein RAG System on AWS technische Messpunkte. Erfassen Sie Anfragevolumen, Fehlerraten, Zeitüberschreitungen, Tokenverbrauch und Modellfehler. Speichern Sie keine vollständigen Inhalte, wenn für die Kennzahl nur Länge, Status oder eine anonymisierte Kennung genügt. Alarme sollten sich an vereinbarten Schwellen orientieren, etwa an einem starken Anstieg der Antwortzeit oder an vielen Antworten ohne belastbare Belege.

Skalierung beginnt mit der Trennung von Anfrage- und Aktualisierungslast. Nutzeranfragen benötigen kurze Reaktionszeiten. Indexaktualisierungen können dagegen gepuffert und in ruhigeren Zeitfenstern verarbeitet werden. Eine Warteschlange glättet Spitzen. Horizontale Skalierung der Anwendung verhindert, dass einzelne Sitzungen zum Flaschenhals werden.

Planen Sie Lasttests mit mehreren Stufen:

Bei verwalteten AWS-Diensten hängt die Skalierung von Servicegrenzen, Region und gewählter Konfiguration ab. Prüfen Sie Quoten frühzeitig und beantragen Sie Erhöhungen nicht erst kurz vor dem Start. Bei einer eigenen Architektur kommen zusätzliche Grenzen für Index, Netzwerk, Warteschlangen und Modellzugriffe hinzu. Diese Werte gehören in ein Kapazitätsmodell.

Für die Kostenkontrolle helfen harte Budgets und abgestufte Antwortpfade. Eine einfache Frage muss nicht denselben Modell- und Kontextumfang erhalten wie eine komplexe Analyse. Begrenzen Sie maximale Kontextgröße, Antwortlänge und Wiederholungsversuche. Ein Cache kann identische Anfragen entlasten, sofern Aktualität und Berechtigungen dabei korrekt berücksichtigt werden.

Beispiel: Interner Unternehmens-Chat mit RAG System on AWS

Ein interner Chat ist ein greifbares Einsatzbeispiel für ein RAG System on AWS: Mitarbeitende fragen nach einer Reisekostenregel, einer Arbeitsanweisung oder einem aktuellen Produktstand. Die Anwendung antwortet nur mit freigegebenem Unternehmenswissen und verweist auf die verwendeten Dokumentstellen.

Für den Pilot werden drei klar abgegrenzte Wissensbereiche verbunden: ein internes Handbuch, eine Sammlung technischer Betriebsanweisungen und ein Katalog mit Produktfragen. Jeder Bereich erhält einen fachlichen Eigentümer. So lässt sich später nachvollziehen, wer Inhalte aktualisiert und wer für widersprüchliche Aussagen zuständig ist.

Die Chat-Anwendung besteht aus einer kleinen Weboberfläche und einer Backend-API. Nach der Anmeldung erhält die API die Identität des Nutzers sowie dessen Organisationsmerkmale. Vor dem Suchaufruf wird daraus ein zulässiger Datenbereich gebildet. Ein Mitarbeiter aus dem Vertrieb sieht dadurch nicht automatisch vertrauliche Entwicklungsnotizen, selbst wenn beide Inhalte sprachlich ähnlich sind.

Ein beispielhafter Dialogablauf sieht so aus:

Eine nützliche Antwort enthält nicht nur Fließtext. Sie kann einen kurzen Ergebnisblock, Quellenangaben, das Gültigkeitsdatum und einen Link zum Originaldokument zeigen. Für Richtlinien ist außerdem ein Hinweis sinnvoll, dass im Zweifel die zuständige Fachabteilung entscheidet. So bleibt der Chat ein Recherchewerkzeug und wird nicht versehentlich zur verbindlichen Rechts- oder Personalinstanz.

Die Gesprächshistorie sollte bewusst gestaltet werden. Kurze Rückfragen wie „Gilt das auch für Österreich?“ benötigen den Bezug zur vorherigen Frage. Nach mehreren Themenwechseln kann der Verlauf jedoch störenden Ballast enthalten. Die Anwendung sollte daher Themenwechsel erkennen und den Suchkontext auf den aktuellen Dialogabschnitt begrenzen.

Für die Einführung eignet sich ein begrenzter Nutzerkreis aus verschiedenen Abteilungen. Sammeln Sie nicht nur Sternebewertungen, sondern konkrete Rückmeldungen: War die Quelle passend? Fehlte eine Ausnahme? War die Formulierung zu lang? Wurde eine alte Regel verwendet? Diese Angaben zeigen, ob der Chat im Arbeitsalltag tatsächlich Zeit spart.

Ein RAG System on AWS sollte bei diesem Beispiel drei Antwortzustände unterscheiden: beantwortet, nicht ausreichend belegt und kein Zugriff. Diese klare Trennung verhindert, dass fehlende Berechtigungen wie fehlendes Wissen wirken. Sie verbessert außerdem die Auswertung, weil Sicherheitsprobleme und Inhaltslücken getrennt sichtbar bleiben.

Für die Umsetzung kann eine verwaltete AWS-RAG-Option den Pilot beschleunigen. Ein individuell gebauter Chat bietet dagegen mehr Spielraum für eigene Benutzeroberflächen, Eskalationswege und Geschäftsregeln. Die Entscheidung sollte erst nach einem Test mit echten, anonymisierten Fragen fallen. Eine hübsche Demo ist schnell gebaut; ein nützlicher Unternehmenschat braucht dagegen klare Quellen, verständliche Zustände und einen verlässlichen Arbeitsablauf.

Fazit: Passende AWS-RAG-Option auswählen und sicher starten

Die passende Lösung für ein RAG System on AWS richtet sich nach dem konkreten Arbeitsziel, nicht nach der längsten Funktionsliste. Ein interner Wissensassistent, eine Suchfunktion in einem Produkt und eine datenwissenschaftliche Testumgebung stellen unterschiedliche Anforderungen an Bedienung, Anpassung und Betrieb.

Für eine schnelle Einführung sind vollständig verwaltete Angebote meist der pragmatische Einstieg. Eine individuell aufgebaute Architektur ist sinnvoll, wenn eigene Suchregeln, besondere Schnittstellen oder sehr genaue Steuerung erforderlich sind. Die Auswahl sollte mit einem begrenzten Anwendungsfall beginnen und erst danach auf weitere Abteilungen oder Datenbereiche wachsen.

Nutzen Sie für die Entscheidung eine kurze Prüfliste:

Starten Sie anschließend mit einem abgegrenzten Pilotbestand. Definieren Sie vor dem ersten Modellaufruf Erfolgskriterien, Abbruchbedingungen und ein Budget. Ein sinnvoller Pilot endet nicht mit einer beeindruckenden Demo, sondern mit einer belastbaren Entscheidung: ausbauen, nachbessern oder den Ansatz verwerfen.

Prüfen Sie vor dem Produktivstart zudem die aktuelle AWS-Dokumentation. Funktionen, unterstützte Datenquellen, Preise und regionale Verfügbarkeit können sich ändern. Hilfreich sind besonders die AWS-Seite „What is RAG? – Retrieval-Augmented Generation“ sowie der Leitfaden „Choosing a RAG option“ im AWS-Prescriptive-Guidance-Umfeld.

Entwickler sollten ihre Architektur als veränderbaren Baukasten planen. Unternehmen brauchen dagegen klare Zuständigkeiten, Freigaben und Betriebsprozesse. Beides gehört zusammen. Ein technisch eleganter Prototyp bleibt wertlos, wenn niemand Inhalte pflegt, Kosten überwacht oder Fehler bearbeitet.

Wer diese Reihenfolge einhält, reduziert Fehlentscheidungen: erst Geschäftszweck und Datenbereich festlegen, dann AWS-Option vergleichen, danach mit echten Fragen prüfen und zuletzt kontrolliert skalieren. So wird aus einem RAG System on AWS kein bloßes Experiment, sondern ein nutzbarer Baustein für generative KI in der Organisation.