Bedrock Knowledge Bases: Managed RAG 2026 im Check

Pexon Consulting | 12 Min. Lesezeit | 15.07.2026

TL;DR

Amazon Bedrock Knowledge Bases ist AWS-managed RAG: Ingestion, Chunking, Embeddings, Vector-Store und Retrieval plus Generation in einem Dienst, ohne eigene Pipeline. Pexon (80 MA, AWS- und Microsoft-Partner) baut damit in 6 Wochen einen produktiven Wissens-Bot. Setup-Zeit sinkt von Wochen auf Tage, bei komplexen Dokumenten und Souveränität stößt Managed an Grenzen.

Was Bedrock Knowledge Bases wirklich macht

Bedrock Knowledge Bases nimmt Ihnen die komplette RAG-Klempnerei ab. Sie zeigen auf einen S3-Bucket (oder SharePoint, Confluence, Google Drive, Web Crawler), AWS übernimmt Parsing, Chunking, Embedding, das Anlegen des Vector-Index und die Retrieval-Logik. Am Ende rufen Sie eine einzige API auf und bekommen eine Antwort mit Quellen-Zitaten zurück. Das ist der Unterschied zu einem Framework: Sie schreiben keine Ingestion-Pipeline mehr.

Konkret laufen fünf Schritte automatisch: Dokumente aus der Datenquelle ziehen, in Text-Chunks zerlegen, jeden Chunk per Embedding-Modell in einen Vektor wandeln, im Vector-Store ablegen, und bei einer Anfrage die relevantesten Chunks holen und einem Foundation Model als Kontext geben. Amazon nennt seit 2026 zwei Betriebsmodelle: die Managed Knowledge Base (AWS betreibt Ingestion, Index, Storage, Retrieval komplett, inklusive Auto-Scaling und Smart Parsing) und die Customer-managed Knowledge Base, bei der Sie den Vector-Store selbst wählen und konfigurieren.

Beim Chunking haben Sie die Wahl zwischen fixed-size, semantic und hierarchical Chunking, plus einer No-Chunking-Option für vorsegmentierte Daten. Als Vector-Store stehen OpenSearch Serverless (Default), OpenSearch Managed Cluster (GA seit 27. März 2025), Aurora PostgreSQL mit pgvector, Neptune Analytics für GraphRAG sowie Pinecone, MongoDB Atlas und Redis zur Verfügung. Seit Dezember 2025 kommt Amazon S3 Vectors dazu, laut AWS bis zu 90 Prozent günstiger als klassische Vector-Datenbanken.

Der Code: retrieve und retrieve_and_generate

Zwei API-Operationen decken 90 Prozent der Fälle ab. retrieve gibt Ihnen nur die passenden Chunks zurück, wenn Sie den Generierungs-Prompt selbst bauen wollen. retrieve_and_generate macht Retrieval plus Antwort-Generierung in einem Call, inklusive Zitaten. Beide laufen über den boto3-Client bedrock-agent-runtime.

import boto3

# Runtime-Client für Retrieval und Generierung
client = boto3.client("bedrock-agent-runtime", region_name="eu-central-1")

KB_ID = "KB12345678"  # ID der Knowledge Base aus der Bedrock-Konsole
# Modell-ID für die Antwort-Generierung (Region-Präfix us. bei Cross-Region-Inference)
MODEL_ARN = "arn:aws:bedrock:eu-central-1::foundation-model/anthropic.claude-3-5-sonnet-20241022-v2:0"

# Variante 1: nur die relevanten Text-Chunks holen (eigener Prompt-Aufbau)
treffer = client.retrieve(
    knowledgeBaseId=KB_ID,
    retrievalQuery={"text": "Wie lange gilt die Gewährleistung bei Modell X?"},
    retrievalConfiguration={
        "vectorSearchConfiguration": {"numberOfResults": 5}  # Top-5 Chunks
    },
)
for c in treffer["retrievalResults"]:
    print(c["content"]["text"], "->", c["location"])  # Chunk plus Quelle

# Variante 2: Retrieval plus fertige Antwort mit Zitaten in einem Call
antwort = client.retrieve_and_generate(
    input={"text": "Wie lange gilt die Gewährleistung bei Modell X?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {
            "knowledgeBaseId": KB_ID,
            "modelArn": MODEL_ARN,
            "retrievalConfiguration": {
                "vectorSearchConfiguration": {"numberOfResults": 5}
            },
        },
    },
)
print(antwort["output"]["text"])          # generierte Antwort
print(antwort["citations"])                # Belegstellen für die Nachprüfung

Das ist der komplette RAG-Loop. Kein Ingestion-Skript, kein Embedding-Aufruf, keine Vector-DB-Verwaltung im Code. Genau hier liegt der Reiz von Managed RAG: Was bei einem Eigenbau 400 Zeilen Pipeline-Code sind, sind hier zwei API-Calls. Die vollständigen Parameter stehen in der offiziellen AWS-Dokumentation zu Bedrock Knowledge Bases.

Wann Managed RAG statt Eigenbau

Unsere klare Empfehlung: Starten Sie mit Managed, wechseln Sie erst auf Eigenbau, wenn ein konkreter Grund dazu zwingt. In der Mehrzahl der Enterprise-Projekte, die wir sehen, ist der Vector-Store nicht der Wettbewerbsvorteil. Wer seine ersten Wochen damit verbringt, OpenSearch-Cluster zu tunen und Embedding-Pipelines zu bauen, verbrennt Budget an einem gelösten Problem.

Managed lohnt, wenn Ihre Dokumente überschaubar strukturiert sind (PDFs, Office-Dateien, Confluence), Sie ohnehin in AWS sind und Time-to-Value zählt. Für einen internen Support-Bot auf 5.000 Handbuch-Seiten ist Bedrock KB in Tagen produktiv, während ein Eigenbau erst die Infrastruktur diskutiert. Die neuen 2026-Features verschieben diese Grenze weiter Richtung Managed: Smart Parsing wählt die Parsing-Strategie pro Dokumenttyp automatisch (PDF, PPTX, gescannte Dokumente, Audio, Video), und Agentic Retrieval zerlegt komplexe Fragen in Teilfragen und iteriert über mehrere Knowledge Bases.

Eigenbau wird dann sinnvoll, wenn Sie exotisches Chunking brauchen (etwa PLM-Stücklisten oder Tabellen-lastige Normen), mehrere Vector-Stores kombinieren, ein spezielles Reranking-Modell einhängen oder On-Prem hosten müssen. Wir haben Kunden, bei denen genau das der Fall ist, und dort ist LangChain oder LlamaIndex die richtige Wahl. Wie man die Qualitätsstufen bis zur Produktion durchzieht, haben wir separat aufgeschrieben, siehe unsere Übersicht zu den fünf Reifegraden vom Prototyp bis zum Betrieb.

GraphRAG und strukturierte Daten: die neuen Hebel

Seit 2025 kann Bedrock KB mehr als reines Vektor-Retrieval. GraphRAG mit Neptune Analytics ist seit März 2025 generell verfügbar und extrahiert automatisch Entitäten und Beziehungen aus Ihren Dokumenten in einen Knowledge Graph. Das hilft bei Fragen, deren Antwort über mehrere Dokumente hinweg verbunden werden muss, und macht die Antwort erklärbarer. Sie brauchen dafür kein Graph-Modellierungs-Know-how, AWS baut und aktualisiert den Graph selbst.

Parallel gibt es Structured Data Retrieval: Bedrock KB kann natürlichsprachige Fragen gegen ein Data Warehouse oder einen Data Lake stellen, statt nur unstrukturierte Texte zu durchsuchen. Für einen Controlling-Bot, der „Welcher Kunde hatte 2025 den höchsten Deckungsbeitrag?“ beantworten soll, ist das der Unterschied zwischen „geht nicht“ und „geht out-of-the-box“. Wo GraphRAG technisch reizvoll, aber nicht immer nötig ist, haben wir im Vergleich von agentischem RAG gegen den Standard-Ansatz eingeordnet. Faustregel: Graph erst, wenn einfaches Vektor-Retrieval nachweisbar an Multi-Hop-Fragen scheitert.

Die Grenzen: wo Managed RAG ehrlich aufhört

Managed RAG ist kein Freifahrtschein. Drei Grenzen sehen wir in unseren Projekten immer wieder, und keine davon steht auf der Landing Page von AWS. Wer sie ignoriert, baut einen Bot, der im Demo glänzt und im Betrieb enttäuscht.

Erstens komplexe Dokumente. Sobald Ihre Wahrheit in verschachtelten Tabellen, technischen Zeichnungen oder Querverweisen zwischen Normen steckt, reicht das Default-Chunking oft nicht. Das Standard-Retrieval reißt Tabellenzeilen aus dem Kontext, und die Antwort wird plausibel, aber falsch. Wir haben ausführlich beschrieben, warum Standard-RAG bei technischen Dokumenten an Grenzen kommt. Managed KB mit Smart Parsing hilft, löst es aber nicht vollständig.

Zweitens Souveränität. Bedrock läuft in AWS-Regionen. Für regulierte Kunden in Banking, Versicherung oder KRITIS, die On-Prem oder eine deutsche Souveränitäts-Cloud brauchen, ist Managed KB oft ein K.-o.-Kriterium. Frankfurt (eu-central-1) deckt DSGVO ab, aber nicht jede BaFin- oder BSI-Vorgabe akzeptiert einen US-Hyperscaler als Datenverarbeiter. Hier bauen wir souveräne RAG-Architekturen, kein AWS-Managed-Dienst.

Drittens Kosten-Transparenz. Das klassische OpenSearch Serverless kostete lange rund 350 Dollar pro Monat allein für die 2 Baseline-OCUs, auch bei null Anfragen. Seit dem 28. Mai 2026 gibt es NextGen Collections mit Scale-to-Zero (OCUs skalieren nach 10 Minuten Inaktivität auf null) und pay-per-usage, was den Idle-Kostenblock für neue Projekte entschärft. Der pauschale „350 Dollar auch im Leerlauf“-Einwand gilt damit nicht mehr für jede Serverless-Variante. Trotzdem gilt: Rechnen Sie den Vector-Store-Betrieb plus Token-Kosten vorab durch, sonst überrascht die erste Rechnung.

Was das für Ihr Projekt heißt

Für die meisten Enterprise-Wissens-Bots ist Bedrock Knowledge Bases 2026 der schnellste Weg zu einem produktiven RAG-System, vorausgesetzt Sie sind in AWS und Ihre Dokumente sind nicht pathologisch komplex. Unsere Empfehlung: Managed als Default, S3 Vectors oder NextGen für die Kosten, GraphRAG nur bei echtem Multi-Hop-Bedarf.

Der Fehler, den wir am häufigsten sehen: Teams bauen monatelang eine eigene Pipeline für ein Problem, das AWS in Tagen managed löst, oder umgekehrt, sie kleben aus Bequemlichkeit an Managed, obwohl ihre technischen Dokumente längst nach eigener Chunking-Logik verlangen. Die richtige Entscheidung hängt an Ihren Dokumenten, nicht an der Technologie. Genau diese Bewertung machen wir am Anfang jedes Projekts, bevor eine Zeile Code entsteht.

Häufig gestellte Fragen

Was kostet ein RAG-System mit Bedrock Knowledge Bases?

Die Kosten teilen sich in Vector-Store, Embeddings und LLM-Token. OpenSearch Serverless (klassisch) startete bei rund 350 Dollar pro Monat für 2 OCUs; seit den NextGen Collections (Mai 2026, Scale-to-Zero) und S3 Vectors (bis 90 Prozent günstiger) fällt der Idle-Block für neue Projekte weg. Rechnen Sie zusätzlich Embedding- und Generierungs-Token pro Anfrage. Für einen mittleren internen Bot bewegen sich Betriebskosten meist im niedrigen dreistelligen bis vierstelligen Euro-Bereich pro Monat.

Bedrock Knowledge Bases oder Eigenbau mit LangChain: was ist besser?

Kommt auf Ihre Dokumente an. Managed KB ist in Tagen produktiv und nimmt Ihnen den Vector-Store-Betrieb ab, taugt aber schlecht für exotisches Chunking, Multi-Store-Setups oder On-Prem. Eigenbau gibt volle Kontrolle, kostet aber Wochen Setup. Faustregel: Managed als Default, Eigenbau nur bei konkretem technischem Zwang.

Welche Vector-Stores unterstützt Bedrock Knowledge Bases?

OpenSearch Serverless (Default), OpenSearch Managed Cluster, Aurora PostgreSQL mit pgvector, Neptune Analytics (für GraphRAG), Pinecone, MongoDB Atlas und Redis. Seit Dezember 2025 kommt Amazon S3 Vectors dazu, laut AWS bis zu 90 Prozent günstiger. Für die meisten Neu-Projekte sind S3 Vectors oder NextGen Serverless die kostengünstigste Wahl.

Ist Bedrock Knowledge Bases DSGVO-konform?

In der Region Frankfurt (eu-central-1) verarbeitet Bedrock Daten innerhalb der EU, was DSGVO-Anforderungen abdeckt. Für regulierte Branchen mit On-Prem- oder Souveränitäts-Pflicht (BaFin, BSI, KRITIS) reicht das aber nicht immer, weil ein US-Hyperscaler als Verarbeiter ausgeschlossen sein kann. In diesen Fällen bauen wir souveräne RAG-Architekturen außerhalb von Managed AWS.

Kann Bedrock Knowledge Bases auch strukturierte Daten und Graphen abfragen?

Ja. Structured Data Retrieval erlaubt natürlichsprachige Fragen gegen Data Warehouses und Data Lakes, ohne SQL zu schreiben. GraphRAG mit Neptune Analytics (GA seit März 2025) baut automatisch einen Knowledge Graph aus Ihren Dokumenten für Multi-Hop-Fragen. Beides ist managed, Sie brauchen kein Graph-Modellierungs-Wissen.

Nächster Schritt

Bevor Sie sich zwischen Managed und Eigenbau entscheiden, lohnt ein strukturierter Blick auf Ihre Dokumente und Ihren Use-Case. Genau das machen wir im Workshop.

Verwandte Themen