Company Brain aufbauen: Warum Standard-RAG scheitert

Viele Unternehmen wollen derzeit ein Company Brain aufbauen und ihr verstreutes Wissen aus Confluence, Google Drive, Jira und SharePoint für Sprachmodelle nutzbar machen. Ein Company Brain ist eine zentrale KI-Wissensschicht, die Firmenwissen aus mehreren Quellen mit Rechteprüfung, Versionierung und Quellenbeleg abrufbar macht. Die Realität ernüchtert jedoch schnell: Was in einer Demo mit drei sauberen PDF-Dateien beeindruckt, bricht im Unternehmensalltag regelmäßig zusammen. Mitarbeiter erhalten erfundene Antworten, finden widersprüchliche Richtlinienstände oder sehen Informationen, für die ihnen die Berechtigung fehlt.

Das Grundproblem liegt selten am Sprachmodell selbst, sondern an einer naiven Retrieval-Augmented-Generation-Architektur (RAG). Wer Firmenwissen lediglich in feste Abschnitte zerlegt, durch ein Embedding-Modell schickt und in einer Vektordatenbank ablegt, baut keine verlässliche Wissensquelle, sondern eine Sammlung von Textstücken ohne Zusammenhang und Kontrolle. Naive Vektorsuchen übersehen relevante Textstellen; Anthropic senkte diese Fehlerrate mit Contextual Retrieval, hybrider Suche und Reranking um bis zu 67 Prozent (von 5,7 auf 1,9 Prozent; Anthropic, September 2024). Gemessen wurde der Anteil relevanter Chunks, die nicht unter den Top 20 Treffern landen. Ein modernes Company Brain verlangt deshalb Context Engineering: Textabschnitte behalten ihren Dokumentenursprung, die Suche vereint Bedeutung und exakte Begriffe, und Zugriffsrechte greifen vor der Antwortgenerierung.

Das Versprechen vom Company Brain: Warum einfache „Frag dein Dokument“-Tools scheitern

Die Vision eines zentralen Firmengehirns klingt verlockend: Eine KI beantwortet operative Fragen in Sekunden, unterstützt das Onboarding neuer Teammitglieder und führt Fachwissen über Abteilungsgrenzen hinweg zusammen. In der Praxis greifen viele Organisationen zu einfachen „Frag dein Dokument“-Tools oder zu elementaren Open-Source-Skripten. Dokumente werden eingelesen, in Chunks (Textabschnitte, in die Dokumente zerlegt werden) von meist einigen hundert Token zerteilt, in Vektoren umgerechnet und bei einer Nutzeranfrage nach mathematischer Ähnlichkeit (Kosinus-Ähnlichkeit) gesucht.

Dieser Ansatz ignoriert die Realität gewachsener Unternehmensdaten. Dokumente im Betrieb sind weder isoliert noch einheitlich strukturiert. Sie enthalten Tabellen ohne wiederholte Kopfzeilen, Querverweise auf frühere Richtlinien, Abkürzungen ohne Glossar und Versionsstände aus verschiedenen Jahren. Wird ein solcher Text blind zerschnitten, verliert der einzelne Chunk seinen Bezugsrahmen. Ein Vektormodell sieht dann nur noch Sätze wie „gemäß Absatz 3 gilt ein Schwellenwert von 5.000 Euro“, weiß aber weder, um welchen Vertragstyp es geht, noch für welchen Mandanten die Klausel gilt. Ein praxistaugliches Company Brain braucht daher eine Architektur, die Wissen kuratiert, Kontext bewahrt und Antworten mit Quellen belegt. Wie eine solche Anbindung über offene Protokolle gelingt, zeigt das Projekt RAG-Wissensbasis mit MCP-Server, bei dem strukturierte Schnittstellen statt statischer Dateiablagen im Mittelpunkt stehen.

Die vier Sollbruchstellen klassischer RAG-Systeme im Unternehmensalltag

Die Schwächen naiver RAG-Implementierungen lassen sich auf vier wiederkehrende Architekturfehler zurückführen:

1. Kontextverlust durch naives Zerteilen: Werden Dokumente rein nach Zeichen- oder Tokenanzahl zerteilt, landen zusammengehörige Informationen in getrennten Chunks. Noch gravierender ist das Fehlen von Metadaten: Welches Dokument, welches Kapitel und welcher Gültigkeitszeitraum liegen dem Abschnitt zugrunde? Ohne diesen Kontext findet die Suche die richtige Stelle oft nicht.
2. Das Problem mit Abkürzungen und Kennungen: Die Bedeutungssuche per Vektoren erkennt inhaltliche Ähnlichkeiten gut. Sie scheitert aber häufig an exakten Codes wie Produktnummern (z. B. KB-9482-X), Servernamen, internen Projektnamen oder Aktenzeichen. Fragt ein Ingenieur nach einem bestimmten Fehlercode, liefert die Vektorsuche oft ähnlich klingende, aber sachlich falsche Fehlerbeschreibungen.
3. Zu viele Textstellen im Prompt: Viele Entwickler gleichen schlechte Trefferquoten aus, indem sie 30 oder 50 Chunks ungefiltert in den Prompt packen. Modelle nutzen Informationen in der Mitte langer Kontexte jedoch schlechter (Liu et al. 2023, „Lost in the Middle“); die Antwortqualität sinkt.
4. Fehlende Berechtigungslogik: In Standard-RAG-Demos hat jeder Nutzer Zugriff auf alle Chunks. Im Unternehmen dürfen Marketing-Mitarbeiter jedoch keine Gehaltsstrukturen sehen, und Vertriebsdaten müssen nach Mandanten getrennt bleiben. Wird die Berechtigung nicht in der Suchschicht selbst erzwungen, drohen Datenschutz- und Compliance-Verstöße.

Contextual Retrieval und hybride Suche: Chunks mit Kontext anreichern

Contextual Retrieval ist ein verbreiteter, gut dokumentierter Ansatz, um die Treffsicherheit zu erhöhen. Statt rohe Textblöcke direkt in Vektoren umzurechnen, ergänzt ein kleines, schnelles Sprachmodell jeden Chunk vor der Einbettung um ein Kontext-Präfix. Dieses Präfix erklärt in 50 bis 100 Tokens, aus welchem Gesamtdokument der Abschnitt stammt und worum es in seinem Umfeld geht.

# Ursprünglicher Chunk (ohne Kontext):
„Im Geschäftsjahr 2025 stieg der operative Gewinn um 14 %, während die Personalkosten stabil blieben.“

# Kontextualisierter Chunk:
„Dieses Dokument ist der Jahresabschlussbericht 2025 der Logistik Nord GmbH. Der folgende Abschnitt beschreibt die finanzielle Performance der Sparte Kontraktlogistik:
Im Geschäftsjahr 2025 stieg der operative Gewinn um 14 %, während die Personalkosten stabil blieben.“

Im Benchmark von Anthropic (September 2024) senkten kontextualisierte Embeddings allein die Fehlerrate um 35 Prozent (von 5,7 auf 3,7 Prozent), zusammen mit kontextualisierter BM25-Suche um 49 Prozent (auf 2,9 Prozent). Die Fehlerrate misst dort den Anteil relevanter Chunks, die nicht unter den Top 20 Treffern landen.

Reine Vektorsuche genügt internen Suchen selten. Moderne Wissensdatenbanken setzen deshalb auf eine hybride Suche: Bedeutungssuche per Vektoren für thematische Zusammenhänge plus klassische Stichwortsuche (BM25), die exakte Begriffe, Teilenummern und Abkürzungen findet. Beide Ergebnislisten werden über Verfahren wie Reciprocal Rank Fusion (RRF) zusammengeführt, bevor die Daten weiterverarbeitet werden.

Reranking: Wie Cross-Encoder die Treffer im Prompt bereinigen

Nach der hybriden Suche liegen viele potenziell relevante Kandidaten vor. Sie alle an das Sprachmodell zu übergeben, würde Kosten treiben und die Antwortqualität verwässern. Ein Reranker sortiert die Treffer neu und behält nur die wirklich passenden.

Embedding-Modelle (Bi-Encoder) übersetzen Anfrage und Dokument getrennt voneinander in Vektoren. Ein Cross-Encoder-Reranker liest dagegen Nutzerfrage und Kandidaten-Chunk gemeinsam in einem Durchlauf. Dadurch erkennt er Verneinungen, feine Bedeutungsunterschiede und die eigentliche Frageabsicht, die der reinen Vektorsuche entgehen. Contextual Embeddings, kontextualisiertes BM25 und Reranking zusammen senkten die Fehlerrate im Anthropic-Benchmark um 67 Prozent (von 5,7 auf 1,9 Prozent). Anthropic reduzierte dabei 150 Kandidaten auf 20; weniger Chunks im Prompt sind möglich, aber nicht durch diesen Benchmark belegt. Wie Agenten Daten darüber hinaus schrittweise abfragen, beschreibt der Beitrag Agentic RAG mit MCP.

Governance und Berechtigungen: RBAC und DSGVO in der KI-Wissensschicht

Ein Company Brain ist nur so sicher wie seine Zugriffskontrolle. Antworten nachträglich per System-Prompt zu filtern („Antworte nur, wenn der Nutzer zur HR-Abteilung gehört“) ist unsicher: Anweisungen im System-Prompt sind keine Sicherheitsgrenze und lassen sich durch Prompt Injection umgehen (OWASP LLM07). Ein verlässliches Rechtemodell muss auf Datenbank- und Indexebene greifen.

In einer produktiven Wissensarchitektur erhält jeder Chunk beim Einlesen einheitliche Metadaten:

• source_system: z. B. jira_cloud oder confluence_intern
• document_id und version: eindeutige Kennung, damit keine veralteten Stände ausgespielt werden
• access_roles: Rollenfreigaben wie engineering, hr_admin, all_internal
• classification_level: Vertraulichkeitsstufe gemäß eigenem Klassifizierungsschema (ISO 27001, A 5.12), z. B. public, internal, restricted

Stellt ein Mitarbeiter eine Anfrage, geht sein authentifiziertes Rollenprofil als Metadatenfilter in die Vektordatenbank ein: eine Rechteprüfung vor der Suche (Pre-Filtering). Dokumente, für die er keine Leserechte hat, werden von vornherein aus der Suche herausgefiltert und können nicht als Kontext im Sprachmodell auftauchen. Auch die DSGVO verlangt Lösch- und Aktualisierungsroutinen (Art. 17 und Art. 5): Ändert sich ein Dokument im Quellsystem, wird sein alter Stand über eine feste Dokument-ID eindeutig ersetzt oder gelöscht, damit keine Dubletten entstehen.

Schritt-für-Schritt-Fahrplan: Vom unstrukturierten Ordner zur produktiven KI-Wissensdatenbank

Eine unternehmensweite Wissensplattform entsteht nicht in einem einzigen großen Rollout. Erfolgreiche Teams gehen schrittweise vor und prüfen jeden Schritt:

1. Quellen prüfen und priorisieren: Nicht jedes Dokument gehört ins Firmengehirn. Starten Sie mit einer klar abgegrenzten Domäne, etwa technischem Kundensupport, internen IT-Richtlinien oder Produkt-Wikis. Veraltete Ablagen werden vor der Indexierung bereinigt.
2. Strukturierte Einlese-Pipelines aufbauen: Automatisierte Parser zerlegen PDFs, Markdown und Tabellen sauber in Text und Metadaten. Tabellenstrukturen müssen erhalten bleiben, statt zu unleserlichem Fließtext zu werden.
3. Kontext ergänzen: Ein leichtgewichtiges Sprachmodell versieht jeden Chunk mit dem Dokumentenkontext, bevor die Embeddings entstehen.
4. Hybriden Index aufsetzen: Geeignet sind etwa Milvus (natives BM25), Qdrant (Sparse-Vektoren) oder Postgres mit pgvector plus einer BM25-Erweiterung, um Vektoren und Stichwortindex gemeinsam zu nutzen.
5. Reranker und Evaluierung einbinden: Ein Cross-Encoder-Reranker sitzt vor der Prompt-Erstellung. Feste Testfragen mit geprüften Musterantworten messen Treffergenauigkeit und Antwortqualität vor jeder Produktivschaltung.
6. Quellenbelege sicherstellen: Das Sprachmodell darf Fakten nur nennen, wenn ein konkreter Chunk sie belegt. Antworten enthalten anklickbare Quellenangaben und Versionshinweise. Wie das in der Praxis aussieht, zeigt das Projekt Grounding Page Generator.

Fazit: Ein Company Brain aufbauen erfordert Context Engineering statt Tool-Aktionismus

Ein Company Brain aufbauen ist keine Frage der Lizenz für ein beliebiges KI-Tool, sondern eine Aufgabe der Daten- und Wissensarchitektur. Naive RAG-Systeme scheitern im Produktiveinsatz, weil sie Kontext zerschlagen, Fachbegriffe übersehen und Sicherheitsgrenzen verwischen.

Unternehmen, die ihr Firmenwissen nachhaltig erschließen wollen, investieren in die Vorbereitung ihrer Daten: Chunks mit Kontext, die Kombination aus Bedeutungs- und Stichwortsuche, konsequentes Reranking und Rechteprüfung vor der Suche machen aus Dokumentenbergen eine verlässliche Wissensquelle. Wer diesen Unterbau schafft, vermeidet teure Fehlversuche und legt das Fundament für Agenten, die Aufgaben auf belastbarem Betriebswissen ausführen.