Production RAG Knowledge Pipeline
End-to-End-Wissens- und Retrieval-Schicht für einen Production-RAG-Assistenten — eine deterministische, regelbasierte Ingestion- und Chunking-Pipeline (kein ML, kein LLM), struktur-bewusste Indexierung für AWS Bedrock, zweistufiges Retrieval mit Reranking und ein Evaluations-Harness mit vier Säulen.
Eine messbare, betreibbare RAG-Wissensschicht: Recall@5 bei 78 % (MRR 0,66) auf einem experten-validierten Gold-Set (n=56) — gegenüber rund 30 % in frühen Messungen unter dem Standard-Chunking der Plattform — mit jeder Änderung abgesichert durch stratifizierte Konfidenzintervall-Metriken und ein 5-Prozentpunkt-Recall-Regression-Gate, das jeden Abfall in der CI blockiert. Auf AWS Bedrock mit EU-Datenresidenz gebaut und deployt, im User-Acceptance-Testing vor dem Produktions-Rollout.
Das ist der Teil eines RAG-Systems, der entscheidet, ob es funktioniert: eine Enterprise-Wissensbasis in retrieval-optimierte Chunks zu verwandeln, sie gegen ein Vector-Backend ohne hybride Suche auffindbar zu machen und Retrieval-Qualität mit Konfidenzintervall-Metriken zu beweisen statt sie zu behaupten. Die Ingestion-Pipeline ist vollständig deterministisch — keine ML-Inferenz, keine heuristische Bewertung — sodass ihr Output reproduzierbar und auditierbar ist.
Diese Seite behandelt das Systemdesign, die nicht-trivialen Engineering-Entscheidungen und wie das System evaluiert und betrieben wird — nicht die Implementierungsdetails.
End-to-End-Flow: Ingestion → Chunking → Indexierung → Retrieval & Reranking → fundierte Generierung, mit einer Evaluations-Schicht aus vier Säulen, die den Iterations-Loop speist.
Hintergrund
Eine Enterprise-Wissensbasis musste zuverlässig über einen Retrieval-Augmented-Assistenten beantwortbar werden. Die harten Probleme sitzen vor dem Sprachmodell: Quellinhalt ist semi-strukturiertes HTML, in dem Prozesswissen als UI-Makros statt als Überschriften kodiert ist; Chunk-Grenzen bestimmen die Retrieval-Qualität und unterscheiden sich nach Content-Type; und das Vector-Backend unterstützt weder hybride Suche noch Metadaten-Embedding. Die Aufgabe war, die Wissens- und Retrieval-Schicht end-to-end zu besitzen und ihre Qualität messbar zu machen — die Generierung selbst ist ein gemanagter Modellaufruf.
Design-Entscheidungen
Die Ingestion-Pipeline ist deterministisch und regelbasiert statt LLM-getrieben. In einem regulierten Kontext des öffentlichen Sektors wiegen Reproduzierbarkeit und Auditierbarkeit schwerer als Bequemlichkeit: derselbe Input ergibt immer dieselben Chunks, ohne Inferenzkosten und ohne Halluzinationsrisiko in der Wissensbasis. Sie läuft als geordnete Single-Responsibility-Stages mit einer Compute-once-Architektur — explizite Contracts und Invarianten, erzwungen an Stage-Grenzen.
Chunking ist content-type-bewusst. Prozess-, Referenz- und Definitionsseiten werden mit unterschiedlichen Strategien und eigenen Größenprofilen geteilt, und die Dokumentstruktur wird vor dem Chunking wiederhergestellt (UI-Makros werden zu echten Überschriften befördert), sodass semantisches Signal bis ins Embedding überlebt. Der Chunk ist die Einheit des Retrievals, also deckelt seine Qualität alles weiter unten.
Weil das Embedding-Modell nur den Chunk-Körper sieht und das Backend keine hybride Suche hat, wird strukturelles und thematisches Signal direkt in den Chunk-Körper angereichert, und die Query-Seite wird symmetrisch mit demselben Glossar erweitert — was die Vokabular-Lücke zwischen Fachterminologie und Alltagsformulierung schließt.
Retrieval ist zweistufig: Vektor-Recall gefolgt von einem Reranker, der wirksamste verfügbare Hebel auf diesem Backend — sein Beitrag isoliert gegen das Gold-Set gemessen, nicht angenommen.
Wie ich Production RAG baue
RAG wird hier als messbarer Loop behandelt, nicht als linearer Build: Ingest, Chunk, Index, Retrieve, Generate — mit einer Evaluation, die über die gesamte Kette läuft, und Operations (Netzwerk-Constraints, Datenresidenz, Kosten, Reproduzierbarkeit) darunter; beide speisen die nächste Iteration.
Diese zwei Schichten darunter sind es, die einen Proof of Concept von Produktion trennen. Die meiste RAG-Arbeit hört auf, wenn die Generierung richtig aussieht; hier wird jede Pipeline-Änderung als messbare Wette gegen das Evaluations-Harness ausgeliefert, und die operativen Constraints sind Architektur, keine Nachgedanken.
Evaluation
Qualität wird als gemessene Eigenschaft behandelt, nicht als Gefühl. Ein Harness mit vier Säulen deckt Pipeline-Struktur ab, Retrieval (Recall@k, MRR und nDCG mit 95-%-Konfidenzintervallen, stratifiziert nach Quelle und Content-Type), einen direkten Wissensbasis-vs.-Bot-Antwortvergleich auf identischer Query-Population und ein strukturiertes Human-in-the-Loop-Review, in dem Fachexperten Antworten über fünf Qualitätsdimensionen bewerten.
Jede Pipeline-Änderung ist abgesichert: ein 5-Prozentpunkt-Recall-Regression-Gate lässt den Lauf (und die CI) fehlschlagen, wenn der Recall über diesen Schwellwert fällt, und ein byte-exakter Snapshot-Test schützt die Reporting-Schicht. Ergebnisse und Experten-Feedback speisen die nächste Iteration — der Loop ist das Produkt. Auf dem experten-validierten Gold-Set (n=56) liegt Recall@5 bei 78 % (MRR 0,66) — gegenüber rund 30 % in frühen Messungen unter dem Standard-Chunking der Plattform. Der Beitrag des Rerankers ist isoliert gemessen: identische Queries pre- und post-Rerank heben das Gold-Set von 67 % auf 78 % (MRR 0,54 → 0,66) und den vollen 287-Query-Pool von 56 % auf 76 %. Bewusst harte Grenzfall-Probes laufen in separaten Suiten und zählen nicht in diese Werte.
Der Query-Pool ist nach Zweck in drei Suiten getrennt: ein eingefrorener, content-gehashter Benchmark, der das Urteil liefert; eine append-only Regression-Suite, in der jeder behobene Bug zu einer permanenten Query wird; und eine LLM-generierte Audit-Suite für Coverage-Diagnose — bewusst aus der Headline-Metrik herausgehalten, weil diagnostische Daten nicht menschlich validiert sind. Vor der Trennung diente ein Pool allen drei Zwecken, und unvalidierte Queries verzerrten das Aggregat.
Synthetische Evaluations-Queries werden validiert, nicht blind vertraut: die synthetische Kohorte reproduziert die Schwierigkeit des Experten-Gold-Sets über mehrere Metriken hinweg auf wenige Punkte genau und dient strikt als statistisches Surrogat. Eine drastische Abweichung wird als Ground-Truth-Problem gelesen, nie als Gewinn.
Operative Überlegungen
Das System spannt sich über zwei isolierte Netze — Wissensquelle und Cloud-Umgebung können nicht direkt miteinander sprechen. Das wurde architektonisch gelöst: eine regions-agnostische Verarbeitungs-Pipeline und ein regions-bewusster Cloud-Worker, gekoppelt nur über idempotente, verschlüsselte Datei-Bundles, mit erzwungener Reproduzierbarkeit und Foot-Gun-Schutz (kein regionsübergreifender State).
Der Assistent ist über zwei AWS-Regionen mit EU-Datenresidenz deployt, mit einer code-seitig deterministischen Deploy-Region und gegatetem Zugriff. Kosten werden bewusst kontrolliert: ein Vektor-Index statt eines gemanagten Such-Clusters, Per-Lauf-Reranker-Kostenzähler und ein deterministischer Replay-Modus, der Live-API-Aufrufe während der Iteration vermeidet.
Die gemanagte Knowledge Base re-chunkte still den bereits semantisch gechunkten Output der Pipeline in Stücke fester Größe mit Überlappung — und zerstörte damit die Strategie-Trennung nach Content-Type. Die Evaluation hat es gefangen; der Fix war, den Index auf kein gemanagtes Chunking zu konfigurieren. Plattform-Defaults sind Teil des Systems — zu wissen, welche man abschalten muss, ist Betriebswissen, das eine Demo nie zeigt.
Der Scope ist bewusst begrenzt. Die Ingestion-Pipeline ist regelbasiert und versucht kein LLM-Chunking; Generierung und Chat-Frontend sind ein gemanagtes Modell und die Oberfläche eines anderen Teams. Der Besitz hier ist die Wissens-, Retrieval- und Evaluations-Schicht plus das Multi-Region-Deployment — die Teile, die ein Production-RAG-System von einer Demo unterscheiden.
Möchten Sie das vollständige Bild hinter diesem System? Nehmen Sie Kontakt auf — oder sehen Sie sich die Engineering-Prinzipien an, die durch alle laufen.