RAG & Company Memory für Unternehmen

Das Problem

Unternehmenswissen ist über Shared Drives, Wikis, Tickets, CRM, ERP und E-Mail-Verläufe verteilt. Klassische Suche gibt Dokumente zurück — sie fasst nicht zusammen, kontextualisiert nicht und schlussfolgert nicht über Quellen hinweg.

LLMs ohne Governance-Schicht produzieren plausibel klingende Antworten, die falsch, veraltet oder aus Datenmaterial stammen können, auf das der anfragende Nutzer keine Berechtigung hat. In regulierten Umgebungen oder wenn Outputs in Entscheidungen einfließen, ist beides nicht akzeptabel.

Was ein produktionsreifes KI-Wissenssystem leisten muss

Quellenaufnahme und Dokumentenpipeline Strukturierte Extraktion aus internen Quellen: Dokumente, Datenbanken, Wikis und APIs. Chunking-Strategien, die zum jeweiligen Inhaltstyp passen — kein Einheitsansatz. Metadaten und Zugriffsklassifikationen werden zum Aufnahmezeitpunkt erfasst.

Retrieval und Ranking Semantische Suche, hybrides Retrieval und Re-Ranking. Der Retrieval-Schritt bestimmt, welcher Kontext das LLM erreicht — hier entstehen die meisten Qualitäts- und Konsistenzprobleme.

Zugriffskontrolle vor Kontextübergabe Berechtigungen werden vor der Kontextzusammenstellung geprüft — nicht an das Modell delegiert. Nutzer erhalten nur Inhalte, auf die sie berechtigt sind. Zugriffskontrolle und Datengrenzen-Architektur ist ein zentraler Architekturpunkt, kein Nachgedanke.

Quellengebundene Antworten Antworten sind an den abgerufenen Kontext gebunden. Das Modell erhält die Anweisung, nicht über die bereitgestellten Quellen hinaus zu schlussfolgern. Quellenverweise sind im Output enthalten, wo der Use Case das erfordert.

Human Review für risikoreiche Outputs Für Outputs, die in Entscheidungen, Genehmigungen oder regulierte Prozesse einfließen, ist ein menschlicher Prüfschritt Teil der Architektur. Das System zeigt Unsicherheit an, anstatt sie zu unterdrücken.

Observability, Evals und Kostenkontrolle Jede Anfrage, jedes Retrieval-Event und jeder Output ist beobachtbar. Eval-Harnesses messen Antwortqualität anhand kuratierter Testfälle. Kosten pro Query werden verfolgt und steuerbar gehalten. LLMOps-Architektur wird ab dem ersten Sprint berücksichtigt, nicht nachträglich ergänzt.

Für wen geeignet

Teams, bei denen internes Wissen Entscheidungen treibt, aber derzeit schwer konsistent und zuverlässig zugänglich ist:

• Finance- und Controlling-Teams, die Berichte, Abweichungen und Richtlinien abfragen müssen
• Legal- und Compliance-Teams, die über Verträge, Regulierung und interne Vorgaben arbeiten
• Sales-Teams, die Angebote vorbereiten und schnellen Zugriff auf Produkt-, Preis- und Case-Wissen brauchen
• Support- und Betriebsteams, die Vorgänge anhand interner Dokumentation lösen
• Geschäftsführung, die strukturierte Zusammenfassungen interner Leistungsdaten abfragt
• Produkt- und Projektteams, die Entscheidungen, Specs und Retrospektiven navigieren

Architekturprinzipien

Jedes Wissenssystem-Engagement wird auf diesen Grundsätzen gebaut:

• Retrieval vor Generation: Das LLM schlussfolgert nur über abgerufenen Kontext — nicht über allgemeines Modellwissen
• Zugriffskontrolle vor Kontextübergabe: Dokumentberechtigungen werden vor jedem LLM-Aufruf gefiltert
• Quellengebundene Antworten: Antworten referenzieren ihre Quellen; unsichere Antworten werden markiert, nicht geglättet
• Menschliche Freigabe wo Entscheidungen zählen: Risikoreiche oder regulierte Outputs werden einem menschlichen Prüfschritt übergeben
• Monitoring und Evals ab dem ersten Sprint: Qualität wird ab dem ersten Prototyp gemessen, nicht nachträglich eingebaut
• Prompt-Injection-bewusstes Design: Inputs werden validiert; abgerufene Inhalte werden als nicht vertrauenswürdig behandelt. Siehe KI-Security und Hardening

Was es nicht ist

• Kein allgemeiner Chatbot: Ein Wissenssystem hat ein definiertes Korpus, ein explizites Zugriffsmodell und Qualitätsgates — kein frei agierender Assistent
• Nicht nur eine Vektordatenbank: Die Retrieval-Schicht ist eine Komponente; das System umfasst Aufnahme, Zugriffskontrolle, Evaluierung und Betriebstooling
• Nicht „alle Daten ins LLM”: Context-Window-Grenzen und Kosten machen pauschale Aufnahme unpraktisch; selektives, gewichtetes Retrieval ist der richtige Ansatz
• Kein autonomer Agent: Retrieval-basierte Wissenssysteme arbeiten innerhalb enger, definierter Grenzen — keine offenen Agent-Loops

Delivery-Modell

Discovery und Knowledge Audit Inventar der internen Quellen, des Zugriffsmodells, der Nutzer-Workflows und der Qualitätserwartungen. Scope wird definiert und Risiken werden sichtbar gemacht, bevor mit dem Bauen begonnen wird.

Quellen- und Zugriffsmodell Datenextraktions-Pipeline, Chunking-Strategie und Berechtigungsarchitektur. Das Fundament, von dem jede weitere Schicht abhängt.

Prototyp mit begrenztem Korpus Ein funktionsfähiges Retrieval-System gegen einen begrenzten, repräsentativen Datensatz. Qualität ist messbar, bevor Skalierung versucht wird.

Evaluierungs- und Review-Prozess Kuratierte Testfälle, Retrieval-Qualitätsmetriken und Antwortbewertung. Eine geschlossene Feedbackschleife zwischen Outputs und der Retrieval-Schicht.

Produktionshärtung Fehlerbehandlung, Rate-Limits, Kostenkontrolle, Audit-Logging und Integration mit bestehender Authentifizierungsinfrastruktur.

Monitoring und Iteration Laufende Observability, regelmäßige Eval-Läufe und ein klarer Prozess für Korpus-Updates und Modelländerungen. Abgestimmt auf LLM-Engineering-Standards.

Verwandte Referenz

Zur Zugriffskontroll-Architektur hinter berechtigungsbewusstem Retrieval siehe den Use Case: Datenzugriffssteuerung.

Zur Architektur berechtigungsbewussten Retrievals und Zugriffskontrolle siehe RAG, Zugriffskontrolle und permission-aware Retrieval.

Häufige Fragen

Kann das System mit unserem bestehenden Dokumentenmanagementsystem arbeiten? In den meisten Fällen ja. Ingestion-Pipelines können Inhalte aus SharePoint, Confluence, Notion, internen Datenbanken und den meisten Systemen mit API extrahieren. Die Komplexität hängt von Volumen, Zugriffsmodell und Format-Vielfalt des Korpus ab.

Wie wird sichergestellt, dass Nutzer nur Daten sehen, für die sie berechtigt sind? Die Berechtigungsprüfung erfolgt auf der Retrieval-Schicht — bevor ein Dokument den LLM-Kontext erreicht. Das ist eine technische Kontrolle, keine modellbasierte Anweisung. Sie setzt voraus, dass Zugriffsklassifikationen zum Aufnahmezeitpunkt korrekt gepflegt sind.

Was passiert, wenn das System eine Frage nicht beantworten kann? Ein gut konzipiertes Wissenssystem gibt bei niedriger Retrieval-Konfidenz oder fehlendem relevantem Kontext eine Fallback-Antwort mit Begründung zurück. Es rät nicht und füllt Lücken nicht mit allgemeinem Modell-Wissen.

Wie werden Antwortqualität und Zuverlässigkeit gemessen? Ein Eval-Harness läuft gegen einen Satz kuratierter Frage-Antwort-Paare. Retrieval Recall, Antwortgenauigkeit und Zitiergenauigkeit werden als laufende Metriken verfolgt. Qualitäts-Benchmarks werden vor dem Produktionsbetrieb vereinbart.

Wie lange dauert es, etwas Produktionsreifes zu bauen? Ein erster funktionsfähiger Prototyp gegen einen begrenzten Korpus ist typischerweise in drei bis vier Wochen erreichbar. Produktionshärtung — einschließlich Zugriffskontrollen, Eval-Harness und Monitoring — verlängert die Zeitlinie abhängig von Quellenvielfalt und Compliance-Anforderungen. Ein Scoping-Gespräch ist der richtige erste Schritt.

Ist das an einen bestimmten LLM-Anbieter gebunden? Nein. Die Architektur ist anbieter-agnostisch. Routing zwischen Anbietern oder ein Anbieterwechsel sind unterstützte und eingeplante Muster. Siehe LLMOps und Kostenkontrolle für die operative Steuerung.