Enterprise-RAG: Gute Antworten reichen nicht

Bei einem RAG-Prototyp ist der erste Erfolgsmoment schnell erreicht: Dokumente werden indexiert, eine Frage wird gestellt und das Modell liefert eine flüssige Antwort mit Quellen. Für eine Demo wirkt das beeindruckend. Für einen Einsatz im Unternehmenskontext bleiben damit aber die schwierigsten Fragen noch offen.

Darf die anfragende Person diese Dokumente überhaupt sehen? Reicht die gefundene Evidenz für eine Antwort? Sind die genannten Quellen tatsächlich im Retrieval-Ergebnis enthalten? Und wie lässt sich erkennen, ob eine technische Änderung die Qualität verbessert oder unbemerkt verschlechtert? Genau diese Fragen standen im Mittelpunkt meines lokalen Enterprise Knowledge Assistant.

Das Projekt arbeitet ausschließlich mit einer synthetischen Wissensbasis. Es ist kein Kundensystem und keine produktive Einführung. Gerade diese klare Grenze machte es möglich, Architektur- und Qualitätsfragen offen zu untersuchen, ohne vertrauliche Daten zu verwenden.

Der wichtigste Entwurfspunkt war, dem Modell nicht die Kontrolle über Quellenintegrität zu überlassen. Dokumente werden gechunkt, mit multilingualen E5-Embeddings indexiert und zunächst über Chroma oder pgvector gesucht. Erlaubte Quellen entstehen aus Retrieval-Metadaten. Nennt das Modell eine andere Quelle, verwirft ein deterministischer Citation Gate die Antwort. Plausibilität ersetzt damit keine Prüfung.

In einem Enterprise-Kontext reicht es nicht, Dokumente erst nach der Antwort auszublenden. Nicht erlaubte Inhalte dürfen weder in Re-Ranking noch Prompt oder Debug-Ausgabe gelangen. Deshalb greifen ACL- und Tenant-Filter vor dem Modellkontext.

Der Demonstrator bildet dafür mehrere Reifestufen ab: frei gesetzte Gruppenheader als frühes Experiment, serverseitiges API-Key-zu-Gruppen-Mapping und optional validierte OIDC/JWT-Tokens. Das ist keine fertige Identity-Plattform, zeigt aber die entscheidende Architekturregel: Identität und Berechtigung werden außerhalb des Modells geprüft und in Retrieval-Filter übersetzt.

Mit LangGraph wurde der Ablauf in explizite Schritte zerlegt: Retrieval, Evidence Gate, kontextgebundene Antwort und Citation Gate. Fehlt ausreichende Evidenz, wird das Modell gar nicht erst gefragt. Sind Quellen ungültig, wird die Antwort nicht ausgeliefert.

Diese Struktur ist für mich der Unterschied zwischen einer losen Prompt-Kette und einem kontrollierbaren Qualitätsprozess. Entscheidungspunkte werden sichtbar, einzeln testbar und im Debug-Modus nachvollziehbar. FastAPI, eine lokale Web-Oberfläche und Request-IDs ergänzen die Nutzungs- und Betriebsperspektive. Fragen, Dokumentinhalte und Kontext bleiben bewusst aus den Request-Logs heraus.

Chroma eignet sich für einen schnellen lokalen Einstieg. pgvector ist interessant, wenn Vektorsuche näher an bereits betriebene Postgres-Infrastruktur rücken soll. Die technische Anbindung allein sagt jedoch nicht, ob die Ergebnisqualität stabil bleibt.

Deshalb wurden beide Backends mit derselben Wissensbasis, demselben Dataset und denselben Metriken verglichen. Hit Rate und MRR waren im dokumentierten Lauf gleich. pgvector lag bei Citation Accuracy und Keyword Recall leicht vorn. Trotzdem bestanden beide Live-Reports die strengen Qualitätsschwellen nicht. Besonders das Abstention-Verhalten bei unbeantwortbaren Fragen blieb unzureichend.

Das wertvollste Ergebnis ist nicht, dass ein lokales Modell Dokumentfragen beantworten kann. Wertvoll ist die Verbindung aus Requirements Engineering, QA und Architektur: Welche Aussage darf das System treffen, welche Evidenz braucht es dafür, wer darf welchen Kontext verwenden und welche Metrik entscheidet über eine Freigabe?

Enterprise-RAG wird belastbar, wenn diese Regeln als Systemverhalten umgesetzt werden. Gute Antworten bleiben wichtig. Vertrauen entsteht aber erst durch überprüfbare Quellen, kontrollierten Zugriff, sichtbare Grenzen und Evaluation, die auch ein negatives Ergebnis zulässt.

Sie arbeiten an einem RAG- oder Agenten-Produkt und möchten Qualitätsziele, Guardrails und Delivery Readiness früh strukturieren? Lassen Sie uns die kritischen Entscheidungen vor dem Rollout sichtbar machen.