AWS hat ein neues Pattern vorgestellt, um KI-Retrieval-Kosten auf Amazon Bedrock zu senken. Wenn Sie Retrieval-Augmented-Generation-Apps (RAG) entwickeln, kann dieses Setup Ihre Token-Ausgaben reduzieren, doch Ihre Nutzer müssen möglicherweise länger auf Antworten warten.
In einem am 2026-08-21 im AWS Machine Learning Blog veröffentlichten Beitrag zeigte AWS, wie sich ein kleines Modell zwischen Retrieval und die finale Antwort schalten lässt. Anstatt lange Text-Chunks an ein großes Modell zu senden, extrahiert ein schnelles Modell zunächst nur genau die relevanten Sätze.
Wie das Setup funktioniert
Das Referenzdesign läuft innerhalb einer AWS-Lambda-Funktion unter Verwendung der Amazon Bedrock Converse API. Sie benötigen ein AWS-Konto, IAM-Berechtigungen und Modellzugriff.
Die Pipeline teilt die Arbeit zwischen zwei Modellen auf:
– Claude Haiku fungiert als Kompressor und wählt wortwörtliche Textpassagen aus, die zur Frage des Nutzers passen.
– Claude Sonnet liest nur den gekürzten Text und verfasst die finale Antwort.
AWS hat drei Ansätze anhand von mehr als 500.000 Dokumenten aus neun Enterprise-Quelltypen und 500 Fragen aus 10 Kategorien getestet: Baseline-RAG, reine Komprimierung und Rerank plus Komprimierung.
Was die Zahlen zeigen
Laut AWS sorgt das Verkleinern des Kontexts für deutliche Einsparungen:
– Token-Volumen: Sinkt auf 12% bei Komprimierung (8.6x weniger Tokens) und 10% bei Rerank plus Komprimierung (10.1x weniger Tokens), verglichen mit 100% bei Baseline-RAG.
– Gesamtkosten: Fallen auf 67% (eine Ersparnis von 33%) und 64% (eine Ersparnis von 36%).
– Qualitätswert: Bleibt nahe an der Baseline (97.5% und 97.6% gegenüber 100%), basierend auf einem LLM-Judge, der Korrektheit, Vollständigkeit, Zitationsgenauigkeit und Prägnanz bewertet.
– Halluzinationsrate: Sinkt von 51% bei der Baseline auf 44% bei Komprimierung und 38% bei Reranking, wobei Faithfulness separat erfasst wurde.
– Latenz: Steigt um +19% bei Komprimierung und +12% bei Rerank plus Komprimierung. Die Geschwindigkeit leidet.
Die Behauptungen, die Sie selbst überprüfen sollten
Diese Zahlen stammen vollständig aus internen Tests von AWS an einem einzelnen Korpus, der von einem LLM-Judge bewertet wurde. Niemand außerhalb von AWS hat sie unabhängig überprüft, und sie stellen keine Leistungsgarantie für andere Workloads, Preisstufen oder Modelle dar. Ein zusätzlicher Modellaufruf schafft eine neue Fehlerquelle. Der Kompressor könnte versehentlich wichtige Fakten verwerfen, Zitate schwächen oder an fehlerhaften Spans und Prompt Injections scheitern.
So testen Sie dieses Pattern
Ändern Sie Ihre Produktions-Pipeline noch nicht. Testen Sie zuerst Ihre eigenen Daten.
Richten Sie ein festes Test-Query-Set mit Ihrem Retriever, Ihren Top-k-Einstellungen, Chunking und Modell-IDs ein. Führen Sie Abfragen über alle drei Pfade aus: Baseline-RAG, Komprimierung und Rerank plus Komprimierung. Protokollieren Sie Input-Tokens, Output-Tokens, Lambda-Kosten, Modellkosten sowie p50- und p95-Latenz. Vor allem: Überprüfen Sie die komprimierten Spans direkt. Prüfen Sie, was verworfen wird. Wenn die Tail-Latenz in die Höhe schnellt oder wichtige Belege verloren gehen, bleibt Ihr Baseline-RAG-Pfad die sicherere Wahl.