Was ist ein Enterprise-RAG-System?
Ein Enterprise-System für Retrieval-Augmented Generation ruft genehmigte Informationen aus Organisationsquellen ab und stellt sie einem Sprachmodell als Kontext bereit, bevor das Modell eine Antwort oder Aktion erzeugt. Ein produktionsreifes System braucht außerdem Ingestion, Berechtigungen, Aktualität, Quellenangaben, Evaluation, Observability, Sicherheit und menschliche Eskalation.
Das beste System ist nicht das mit der längsten Feature-Liste. Es ist die kleinste Architektur, die bei realen Aufgaben einen vereinbarten Qualitätswert erreicht und gleichzeitig Daten-, Latenz-, Governance-, Zuverlässigkeits- und Kostenanforderungen erfüllt.
Mit der Entscheidung beginnen, nicht mit der Vektordatenbank
Definieren Sie zuerst einen begrenzten Anwendungsfall:
- Support-Mitarbeiter beantworten Richtlinienfragen;
- Beschäftigte durchsuchen interne Verfahren;
- Vertriebsteams finden freigegebene Produktnachweise;
- Analysten vergleichen kontrollierte Dokumente;
- Kundenassistenten erklären Konto oder Bestellung;
- Engineering-Teams navigieren technische Dokumentation.
Bestimmen Sie für diesen Anwendungsfall Nutzergruppen, erlaubte Quellen, verbotene Ausgaben, erforderliche Zitate, Aktualität, Antwortzeit, Sprachen, Eskalationsweg und Kosten einer falschen Antwort. Diese Anforderungen bestimmen die Architektur zuverlässiger als das allgemeine Briefing „Unternehmens-Chatbot bauen“.
Der Enterprise-RAG-Lebenszyklus
- Verbinden und ingestieren: autorisierte Inhalte und Metadaten aus Quellsystemen aufnehmen.
- Normalisieren und anreichern: Dateien parsen, Boilerplate entfernen, Struktur erhalten sowie Berechtigungen, Entitäten, Datum und Herkunft ergänzen.
- Segmentieren: Retrieval-Einheiten bilden, die den notwendigen Antwortkontext behalten.
- Indexieren: lexikalische, Vektor-, Graph- oder Hybridstrukturen aufbauen.
- Abrufen: Anfrage interpretieren, Zugriff filtern, suchen und Kandidaten neu sortieren.
- Generieren oder handeln: begrenzte Nachweise an das Modell geben und Quellenangabe oder strukturiertes Ergebnis verlangen.
- Evaluieren: Retrieval- und Antwortverhalten mit einem festen Testset bewerten.
- Betreiben: Aktualität, Zugriff, Qualität, Latenz, Kosten, Incidents und Feedback überwachen.
Googles RAG-Engine-Übersicht beschreibt den Kernpfad von Ingestion und Transformation über Embedding, Indexierung und Retrieval bis zur Generierung. Ein Anbieter kann Teile davon verwalten; die Akzeptanzkriterien bleiben Aufgabe des Unternehmens.
Zehn Auswahlkriterien
1. Quellen- und Formatabdeckung
Inventarisieren Sie Dokumentenspeicher, Wikis, Datenbanken, CRM, Ticketsysteme, Object Storage, Code und Medien. Testen Sie die schwierigsten realen Formate: gescannte PDFs, Tabellen, Präsentationen, verschachtelte Rechte und häufig veränderte Datensätze.
Ein langer Connector-Katalog ist weniger wichtig als korrektes Parsing, inkrementelle Synchronisierung, Löschverarbeitung und nachvollziehbare Herkunft für die tatsächlich wichtigen Quellen.
2. Identität und Berechtigungen
Das System muss Zugriffsrechte anwenden, bevor es Belege liefert, nicht eingeschränkten Text erst nach der Generierung verstecken. Prüfen Sie SSO, Gruppensynchronisierung, Dokument- und Zeilenrechte, Service-Identitäten, Tenant-Isolation, Audit-Logs und Rechteänderungen.
Führen Sie adversariale Tests durch, in denen Nutzer direkt und indirekt nach nicht zugänglichen Dokumenten fragen.
3. Retrieval-Qualität
Vergleichen Sie lexikalisches, vektorbasiertes, hybrides, metadatengefiltertes, reranktes und Multi-Query-Retrieval mit demselben Aufgabensatz. OpenAIs Retrieval-Leitfaden beschreibt semantische Suche über Vector Stores, die auch Ergebnisse mit wenigen gemeinsamen Keywords findet. Semantische Ähnlichkeit ist wertvoll; exakte Namen, Codes, Daten und Rechtsklauseln brauchen häufig zusätzliche lexikalische und Metadaten-Signale.
Messen Sie mindestens:
- Recall at K für erforderliche Belege;
- Präzision oder Quote irrelevanten Kontexts;
- Ranking-Qualität;
- Korrektheit der Berechtigungsfilter;
- Retrieval-Latenz;
- Abdeckung je Quelle, Sprache und Fragetyp.
4. Fundierte Antworten und Quellenangaben
Definieren Sie, ob das System zitieren, zusammenfassen, ablehnen, nachfragen oder eine strukturierte Aktion erzeugen soll. Quellen müssen zur exakten autorisierten Passage führen, die dem Nutzer zugänglich ist.
AWS dokumentiert getrennte Retrieve- und kombinierte RetrieveAndGenerate-Operationen für Bedrock Knowledge Bases, einschließlich Quellenangaben zu Chunks. Diese Trennung verdeutlicht eine zentrale Kaufentscheidung: ein verwalteter End-to-End-Pfad für Geschwindigkeit oder getrenntes Retrieval und Generierung für mehr Kontrolle.
5. Evaluationsfähigkeit
Erstellen Sie vor der Anbieterauswahl ein versioniertes Testset aus realen Fragen. Es muss beantwortbare, nicht beantwortbare, mehrdeutige, veraltete, mehrsprachige, adversariale und berechtigungssensitive Fälle enthalten.
Microsofts Leitfaden zu RAG-Design und -Evaluation empfiehlt, einzelne Stufen und das sichtbare Endergebnis getrennt zu bewerten. Groundedness, Vollständigkeit, Nutzung und Relevanz gehören zu den genannten Antwortdimensionen.
6. Data Governance und Deployment-Kontrollen
Prüfen Sie Regionen, Data Residency, Verschlüsselung, kundenseitig verwaltete Schlüssel, private Netzwerke, Retention, Modell-Datennutzung, Löschung, Backups, Disaster Recovery, Audit-Export, Compliance-Nachweise und Subprozessoren. Verifizieren Sie die genaue Verfügbarkeit für die benötigte Region und Servicestufe in aktueller Anbieterdokumentation.
Leiten Sie Governance nicht von der Cloud-Marke ab. Kontrollen und Launch-Status unterscheiden sich je Produkt.
7. Aktualität und Content-Lifecycle
Messen Sie die Zeit von Quellenänderung, Rechteentzug oder Löschung bis zur entsprechenden Indexänderung. Verlangen Sie Fehlerberichte, Reconciliation, Tombstones, Versionshistorie und Rollback.
Ein System, das die gestrige Richtlinie korrekt wiedergibt, ist dennoch unsicher, wenn sich die Richtlinie heute geändert hat.
8. Integration und Portabilität
Bevorzugen Sie klare Grenzen für Connectoren, Parsing, Retrieval, Reranking, Generierung, Richtlinien und Telemetrie. Speichern Sie Herkunft und Evaluationsdaten in portablen Formaten. Verteilen Sie anbieterspezifische Response-Formate nicht über jede Anwendung.
Portabilität bedeutet nicht, jede Komponente sofort austauschen zu können. Sie bedeutet, Grenze und Kosten einer künftigen Änderung zu kennen.
9. Zuverlässigkeit, Latenz und Observability
Definieren Sie Serviceziele für Ingestion-Verzögerung, Retrieval-Latenz, End-to-End-Antwort, Verfügbarkeit, Fehlerquote und Auflösung von Quellen. Verfolgen Sie jede Antwort durch Query-Transformation, Filter, abgerufene Elemente, Scores, Modellinput und -output, Richtlinienentscheidung und Feedback, ohne vertrauliche Inhalte in Logs zu leaken.
Testen Sie degradierte Zustände, wenn Quelle, Index, Reranker oder Modell ausfallen.
10. Gesamte Lifecycle-Kosten
Modellieren Sie:
- Connector- und Ingestion-Volumen;
- Parsing und Anreicherung;
- Embedding und Re-Embedding;
- Indexspeicher und Replikate;
- Retrieval, Reranking und Generierung;
- Netzwerk- und regionenübergreifenden Transfer;
- Evaluation und Observability;
- Engineering, Sicherheit, Content Operations und Support.
Kosten pro Antwort sind unvollständig, wenn schlechte Antworten Eskalationen oder Risiken erzeugen.
Managed, composable oder selbst gehostet?
| Modell | Beste Eignung | Hauptkompromiss |
|---|---|---|
| Verwaltetes End-to-End-RAG | Schnelle Delivery mit unterstützten Quellen und Standardkontrollen | Weniger Kontrolle einzelner Komponenten |
| Composable Managed Services | Eigene Retrieval- und Governance-Anforderungen ohne Betrieb jedes Primitivs | Mehr Integrationsverantwortung |
| Selbst gehostete Komponenten | Infrastrukturkontrolle oder spezialisiertes Retrieval zwingend nötig | Höchster Betriebs- und Upgrade-Aufwand |
Führen Sie dasselbe Testset auf realistischen Prototypen aus. Die Architektur folgt gemessenen Lücken, nicht einer ideologischen Vorliebe für Managed oder Open Source.
Scorecard für einen Proof of Value
Gewichten Sie Kriterien vor den Demos:
| Kriterium | Beispielgewicht |
|---|---|
| Retrieval- und Antwortqualität | 30 % |
| Sicherheit und Berechtigungen | 20 % |
| Governance und regionale Eignung | 15 % |
| Integration und Aktualität | 10 % |
| Zuverlässigkeit und Observability | 10 % |
| Nutzererfahrung und Workflow | 5 % |
| Lifecycle-Kosten | 10 % |
Die Gewichte sind Beispiele, keine universellen Vorgaben. Ein juristischer Rechercheassistent kann Herkunft stärker gewichten, ein Support-Assistent mit hohem Volumen Latenz und Stückkosten.
Häufige Beschaffungsfehler
- Nach einer polierten Demo ohne festes Testset auswählen.
- Sprachliche Eleganz statt Belegen und Groundedness messen.
- Dokument- und Zeilenberechtigungen ignorieren.
- Alle PDFs und Tabellen als einfache Ingestion behandeln.
- Nur Englisch testen, obwohl die Produktion mehrsprachig ist.
- Doppelte und veraltete Inhalte ohne Verantwortliche indexieren.
- Erwarten, dass größere Modelle schlechtes Retrieval reparieren.
- Ablehnungs- und Eskalationsverhalten überspringen.
- Listenpreise ohne Lifecycle-Betrieb vergleichen.
- Ohne nachvollziehbare Quellenlinks und Feedback-Erfassung starten.
Der Auswahlprozess
- Einen Anwendungsfall und eine Risikoklasse genehmigen.
- Ein repräsentatives, berechtigungssensitives Testset erstellen.
- Grenzwerte für Qualität, Latenz, Aktualität, Sicherheit und Kosten definieren.
- Die schwierigsten Quellen und Workflows mit zwei oder drei Architekturen prototypisieren.
- Verblindete Evaluationen und adversariale Zugriffstests ausführen.
- Regionale, vertragliche, sicherheitsbezogene und betriebliche Anforderungen prüfen.
- Das einfachste System wählen, das alle Grenzwerte erfüllt.
- Mit menschlicher Eskalation für eine kontrollierte Kohorte starten.
- Nach Änderungen an Daten, Modell, Prompt oder Retrieval erneut evaluieren.
Die praktische Antwort
Wählen Sie ein Enterprise-RAG-System anhand des vollständigen Belegpfads, nicht durch den Kauf eines Modells plus Vektordatenbank. Der dauerhafte Wert ist die kontrollierte Wissens- und Evaluationsschicht: Quellen, Identitäten, Herkunft, Testfälle und Akzeptanzwerte.
Unser Service für Enterprise-RAG-Architektur konzipiert und validiert diese Schicht. Der bestehende Leitfaden zu Enterprise-KI-Agenten, RAG und Knowledge Graphs zeigt, wie Retrieval mit Agenten- und Entity-Systemen zusammenwirkt.