Enterprise-RAG auf OCI: Architekturmuster, die wirklich skalieren

Fast jedes Unternehmen hat RAG probiert. Die meisten haben irgendwo ein Notebook, in dem es auf einem kuratierten Dokumentensatz und einer handverlesenen Fragenliste funktioniert hat. Die schmerzhafte Lücke liegt zwischen diesem Notebook und dem System, das tausend Kolleginnen drei Monate später gegen einen sich bewegenden Dokumentenkorpus nutzen, wenn das Team, das es gebaut hat, weitergezogen ist. Dieser Beitrag zeigt die Architektur, die diese Lücke schließt, in OCI-Begriffen — die Muster übertragen sich aber auf jede Cloud.

Die fünf Dinge, die Produktions-RAG schwer machen

Es lohnt sich, die Reibung explizit zu benennen, weil die Unterschiede zwischen Demo und Produktion nicht exotisch sind:

• Korpus-Drift. Dokumente ändern sich, kommen hinzu, werden gelöscht. Der Index muss ohne manuellen Eingriff folgen.
• Retrievalqualität bei Skalierung. Reine Vektorähnlichkeit reicht nicht, sobald der Korpus groß ist. Sie brauchen hybride Retrieval, Reranking und Signale aus Metadaten.
• Eval, das Release nach Release übersteht. "Sieht beim Testen richtig aus" ist kein Eval. Sie brauchen einen Held-out-Fragensatz, Ground-Truth-Antworten und automatisches Scoring.
• Guardrails. Die Weigerung zu antworten, wenn der Korpus eine Aussage nicht stützt, ist wertvoller als eine selbstbewusste falsche Antwort.
• Kosten. Ohne explizite Deckel werden RAG-Systeme auf überraschende Weise teuer. Inferenz, Embeddings, Vektor-Storage, Re-Training — alles Posten, die wachsen.

Eine Architektur ohne Geschichte für jeden dieser Punkte ist eine Demo, egal wie beeindruckend sie aussieht.

Die Referenzarchitektur auf OCI

Ein Muster, das sich in mehreren DACH-Enterprise-Deployments bewährt hat:

Quell-Schicht. Dokumente leben in OCI Object Storage, partitioniert nach Sensitivität und Quellsystem. SharePoint, Confluence, File Shares und Datenbankexports fließen in kuratierte Buckets — nicht direkt in den Index.

Ingestion-Pipeline. Ein geplanter Job (OCI Functions oder ein kleiner Kubernetes-Job) erkennt Änderungen in den Quell-Buckets, führt sie durch einen Normalisierungsschritt (Textextraktion, OCR für gescannte PDFs, Metadaten-Anreicherung) und schreibt strukturierte Chunks in einen Staging-Bereich.

Embedding und Indexing. Chunks werden mit einem gewählten Embedding-Modell eingebettet (oft derselbe OCI-Generative-AI-Embedding-Endpunkt, den Ihre Anwendung aufruft; manchmal ein selbst-gehostetes Modell für sensible Daten). Embeddings landen in einem Vektor-Index — Oracle AI Vector Search in der Datenbank ist die natürliche Wahl für OCI-verankerte Teams, mit den operativen Vorteilen, Vektoren neben den Daten zu halten.

Retrieval-Schicht. Ein Retrieval-Service exponiert hybride Suche: Vektorähnlichkeit kombiniert mit Keyword (BM25-artig)-Relevanz, gefiltert nach Metadaten (Sensitivität, Dokumenttyp, Letzte-Aktualisierung). Ein Reranker ordnet die Top-Ergebnisse, bevor sie das LLM erreichen.

Generierung. Der retrievte Kontext, die Anfrage des Nutzers und ein System-Prompt gehen an OCI Generative AI (oder ein selbst-gehostetes Modell für die sensibelsten Use Cases). Die Antwort wird nachverarbeitet, um Zitate und Confidence-Signale zu extrahieren.

Eval und Observability. Jede Anfrage, jeder retrievte Kontext, jede generierte Antwort und jedes Nutzer-Feedback-Signal fließt in ein strukturiertes Log. Ein täglicher Eval-Job läuft den Held-out-Fragensatz und emittiert Qualitätsmetriken.

Das sind sechs Komponenten. Jede ist austauschbar. Keine ist exotisch. Die Stärke der Architektur liegt in den Grenzen, nicht in den einzelnen Stücken.

Was "hybrid Retrieval" wirklich bedeutet und warum es zählt

Reine Vektorähnlichkeit gewinnt für semantische Ähnlichkeit ("finde mir Dokumente zur Vertragsbeendigung" gibt Dokumente zurück, die über das Ende von Vereinbarungen sprechen, auch wenn sie das exakte Wort nicht nutzen). Sie verliert für Exakt-Match-Anfragen ("finde mir Vertrag 2024-718") und für Anfragen, in denen ein spezifischer Begriff Gewicht trägt.

Hybrid Retrieval kombiniert Vektor mit Keyword (BM25 oder ähnlich) und gewichtet beides je nach Anfrage-Eigenschaften. Die harte Arbeit liegt nicht in der Umsetzung der Ansätze; sie liegt im Tunen der Gewichtung und im Entscheiden, welche Metadatenfilter angewandt werden. Das tragfähige Muster: mit einer 70/30-Vektor-zu-Keyword-Gewichtung starten, auf dem Eval-Set messen, dann tunen.

Die Eval-Disziplin, die Regression verhindert

Der eine Unterschied zwischen einem RAG-System, das sich über Zeit verbessert, und einem, das verfällt, ist die Eval-Pipeline. Ein machbares Minimum:

• Ein Held-out-Fragensatz aus 100 bis 300 repräsentativen Anfragen mit bekannten guten Antworten.
• Ein automatischer Scorer — entweder ein kleineres günstigeres Modell, das semantische Äquivalenz beurteilt, oder regelbasiertes Scoring für Anfragen, in denen Exakt-Matches zählen.
• Ein täglicher Lauf, der aggregierte Qualitätsmetriken emittiert: Hit-Rate, Faithfulness (passt die Antwort zum retrievten Kontext), Zitiergenauigkeit, Refusal-Rate.
• Ein Regressions-Alarm, wenn eine Metrik mehr als einen gewählten Schwellenwert gegenüber der gleitenden Baseline fällt.

Das Eval-Set ist kuratiert, nicht generiert. Eine Woche investieren, einmal bauen; jedes Release davon profitieren.

Ohne Eval ist jedes Release eine Vermutung. Mit Eval können Sie Ihrem CIO sagen "die Antwortqualität ist diesen Monat um 3 % gestiegen" — und es ernst meinen.

Kostendisziplin, die das Projekt nicht erstickt

Ein häufiger Fehler: ohne explizite Kostendeckel starten und mitten im Quartal entdecken, dass die Rechnung schneller wuchs als der Wert. Die defensiven Muster:

• Embedding-Caching. Dokumente ändern sich; die meisten Chunks nicht. Nur veränderte Chunks re-embedden.
• Gestaffelte Modelle. Günstigeres Modell für Retrieval-Reranking und für den Eval-Scorer; das teure Modell für die anwenderseitige Antwort reservieren.
• Kontext-Trimming. Der Agent braucht selten die vollen Top-10-Chunks; Top-3 rerankte Chunks produzieren meist dieselbe Antwort zu einem Viertel der Token-Kosten.
• Pro-Nutzer-Soft-Caps. Die meisten Nutzer stellen eine Handvoll Fragen; die lange Reihe "lass mich tausend Prompts ausprobieren" ist, wo unerwartete Ausgaben versteckt sind.

Keines kompromittiert Qualität. Alle halten die Rechnung erklärbar.

Guardrails, die Nutzervertrauen verdienen

Das am meisten unterschätzte Produktionsfeature: die Weigerung zu antworten, wenn der Korpus eine Aussage nicht stützt. Nutzer lernen schnell, welche Assistenten selbstbewusst halluzinieren; sobald sie wissen, dass Ihrer das tut, stirbt die Bindung.

Die funktionierenden Muster:

• Faithfulness-Scoring auf jeder Antwort. Wenn die Antwort über einem Schwellenwert nicht im retrievten Kontext gegründet ist, ablehnen und erklären.
• Zitierte Passagen ab Werk. Jede Aussage zeigt das Dokument und den Absatz, aus dem sie stammt. Nutzer verifizieren selbst und vertrauen schneller.
• Ehrliche Confidence. Wenn das Retrieval schwache Ergebnisse lieferte, das sagen. "Ich konnte in unserer Wissensbasis keine klare Antwort für diese Frage finden" ist ein Feature.

Wie das nach drei Monaten aussieht

Ein Team, das diesem Muster folgt, hat im dritten Monat eines Produktions-Deployments:

• Eine täglich laufende Ingestion-Pipeline mit überwachten Fehlerquoten.
• Einen Vektor-Index, der den vereinbarten Korpus abdeckt, automatisch aktualisiert.
• Einen hybriden Retrieval-Service mit getunten Gewichten.
• Einen täglichen Eval-Lauf mit einem 100+-Fragen-Held-out-Set.
• Einen Observability-Stack, der jede Anfrage und Antwort erfasst.
• Ein Kosten-Dashboard mit expliziten Pro-Komponenten-Aufschlüsselungen.

Das klingt nach viel. Es ist grob ein sechswöchiger Build für ein erfahrenes Team. Verglichen mit einem Jahr "das RAG benimmt sich wieder komisch in Produktion" ist es ein Schnäppchen.

Das längere Muster

Der Grund, warum Enterprise-RAG schwer ist, ist nicht die KI; es ist derselbe Grund, warum jedes Produktionsdaten-System schwer ist. Pipelines driften, Qualität degradiert, Kosten wachsen. Die funktionierenden Muster sind die, die wir aus Data Engineering schon kennen: Trennung der Belange, explizite Grenzen, überwachte Qualität, Kostendisziplin. Wenden Sie sie an, und RAG hört auf, ein interessantes Demo zu sein, und beginnt, Infrastruktur zu sein.