Die Stateless-RAG-Falle: Warum KI-Architektur zur Abfragezeit zu kurz greift

Von Mirko Peters · 2026-08-13

Willkommen zurück im Blog! Wenn Sie unsere Podcast-Diskussionen zu Enterprise Artificial Intelligence verfolgt haben, wissen Sie, dass wir uns viel damit beschäftigen, über den anfänglichen Hype moderner Produktivitätstools hinauszuschauen.

Automatisch mit KI aus dem Originalbeitrag übersetzt. Englisches Original lesen

Willkommen zurück im Blog! Wenn Sie unsere Podcast-Diskussionen zu Enterprise Artificial Intelligence verfolgt haben, wissen Sie, dass wir uns viel damit beschäftigen, über den anfänglichen Hype moderner Produktivitätstools hinauszuschauen. In einer typischen Demonstration wirken Werkzeuge wie Microsoft Copilot erstaunlich intelligent. Sie finden ein Projektdokument, fassen eine Richtlinie zusammen, extrahieren Informationen aus SharePoint und verknüpfen Inhalte aus dem Unternehmen zu einer überzeugenden Antwort. Hinter dieser beeindruckenden Benutzererfahrung verbirgt sich jedoch eine grundlegende architektonische Einschränkung: Abruf ist kein Gedächtnis. Copilot kann Ihre Organisation durchsuchen, aber das bedeutet nicht, dass es ein dauerhaftes Verständnis Ihrer Organisation aufgebaut hat. In diesem Beitrag tauchen wir tief in die Mechanik von Retrieval-Augmented Generation ein und zeigen, wie Chunking und zustandslose Abfrageschleifen verhindern, dass KI über Interaktionen im Unternehmen hinweg angesammelten Kontext behält. Schauen Sie sich unbedingt die zugehörige Podcast-Folge Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It an, in der diese Konzepte als Audio ausführlicher erläutert werden.

Copilot erinnert sich nicht – es ruft ab

Die Nutzung von Copilot erzeugt eine wichtige Illusion. Wenn das System Informationen aus Microsoft 365 erfolgreich miteinander verknüpft, kann es so wirken, als hätte es etwas über Ihre Organisation gelernt. Stellen Sie jedoch später eine ähnliche Frage, kann das System zu einem anderen Ergebnis kommen, weil es erneut einen Abruf durchführt, statt das zuvor gewonnene Verständnis einfach abzurufen. Diese Unterscheidung wird entscheidend, wenn Organisationen über einfache Zusammenfassungen hinausgehen und erwarten, dass KI reale Entscheidungen unterstützt.

Wenn im Grunde identische Fragen je nachdem, welche Informationen abgerufen wurden, zu widersprüchlichen Antworten führen, werden Anwender schnell zurückhaltend, wenn es um geschäftskritische Aufgaben geht. Daraus kann ein Akzeptanzproblem entstehen, und nicht nur ein technisches. Anwender wollen Verlässlichkeit. Wenn ein Assistent auf dieselbe Eingabe am Montag eine Antwort gibt und am Donnerstag eine widersprüchliche, schwindet das Vertrauen rasch.

Was Retrieval-Augmented Generation tatsächlich leistet

RAG steht für Retrieval-Augmented Generation. Vereinfacht ausgedrückt werden Unternehmensdokumente in Chunks zerlegt, diese Chunks über Embeddings dargestellt, die Frage des Nutzers in eine vergleichbare Repräsentation überführt und das System durchsucht die Chunks nach semantisch relevanten Inhalten. Die am höchsten bewerteten Informationsabschnitte werden anschließend als Kontext an das Sprachmodell übergeben, um die Antwort zu erzeugen.

Diese Architektur ist äußerst nützlich. Sie ermöglicht es einem großen Sprachmodell, Fragen mithilfe von Informationen zu beantworten, die nie Teil seiner ursprünglichen Trainingsdaten waren, und bietet einen praktikablen Weg, KI-Antworten auf Unternehmensinhalte zu stützen. Sie bringt jedoch auch eine wichtige architektonische Einschränkung mit sich: Das Modell erhält Fragmente, die für die aktuelle Abfrage ausgewählt wurden, statt eine vollständige, dauerhafte Repräsentation des Wissens der Organisation zu besitzen.

Das Chunking-Problem

Unternehmenswissen existiert selten als isolierte Absätze. Ein Projektplan kann Abhängigkeiten enthalten, die sich über dutzende Seiten verteilen. Eine Richtlinie kann auf eine andere Richtlinie verweisen. Eine technische Architektur kann von Entscheidungen abhängen, die Monate zuvor in Besprechungsnotizen, Teams-Unterhaltungen, SharePoint-Seiten und Designdokumenten festgehalten wurden.

Traditionelles RAG zerlegt diese Quellen in kleinere Einheiten und ermittelt, welche Fragmente für die aktuelle Frage relevant erscheinen. Das Modell sieht daher ausgewählte Teile, nicht zwingend das vollständige Dokument mit allen Zusammenhängen. Für einfache Informationsabfragen kann das hervorragend funktionieren. Bei Fragen, die Beziehungen, historischen Kontext, Abhängigkeiten, angesammelte Entscheidungen oder Schlussfolgerungen über viele Quellen hinweg erfordern, werden die Grenzen jedoch deutlich sichtbar.

Die Stateless-RAG-Falle

Ein konventioneller Retrieval-Workflow kennt von Haus aus kein Konzept dafür, dass etwas bereits geklärt ist. Eine Frage wird entgegengenommen, Informationen werden abgerufen, eine Antwort wird generiert, und danach beginnt der Prozess für die nächste Retrieval-Operation praktisch von vorn. Genau an diesem Punkt wird die Zustandslosigkeit von RAG's zu einer großen Hürde.

Wissen, das in einer Interaktion entdeckt wird, wird nicht automatisch zu dauerhaftem Unternehmenswissen, das jeder künftigen Interaktion zur Verfügung steht. Für Enterprise AI ist das ein gewaltiger Unterschied. Unternehmen brauchen nicht einfach nur bessere Suche. Sie benötigen zunehmend Systeme, die ein strukturiertes Verständnis von Projekten, Prozessen, Richtlinien, Technologien, Personen, Entscheidungen, Abhängigkeiten und den Beziehungen zwischen diesen Elementen aufrechterhalten können.

Wissen suchen vs. Wissen kompilieren

Daraus ergibt sich die zentrale Architekturidee, die wir in unserer neuesten Audioserie untersuchen: Was wäre, wenn KI dieses Wissen im Voraus kompilieren würde, anstatt es zur Abfragezeit immer wieder neu zusammenzusetzen? Ein LLM Wiki steht für genau diesen Wandel im Denken.

Statt jedes Unternehmensdokument als weiteres Fragment zu behandeln, das auf Abruf wartet, kann künstliche Intelligenz Informationen zu strukturierten Wissensartefakten zusammenführen, die abbilden, was die Organisation derzeit versteht. Die entscheidende Veränderung ist nicht einfach eine neue Benutzeroberfläche. Intelligenz verlagert sich von der Rekonstruktion zur Abfragezeit hin zu einer dauerhaften Wissenssynthese.

Warum ein LLM Wiki das Modell verändert

Stellen Sie sich Tausende Dokumente vor, die dasselbe Produkt, denselben Kunden, dasselbe Projekt, dieselbe Richtlinie oder dieselbe Architektur beschreiben. Klassisches RAG wartet auf eine Frage und versucht dann, die Fragmente zu finden, die sie am wahrscheinlichsten beantworten. Ein LLM-Wiki-Ansatz wandelt diese fragmentierten Quellen dagegen kontinuierlich in zusammenhängende Wissensseiten um.

Beziehungen, Entscheidungen, Definitionen, Abhängigkeiten, historischer Kontext und unterstützende Quellen können Teil einer gepflegten Wissensrepräsentation werden. Copilot oder ein anderer KI-Agent kann dann aus einer Ebene abrufen, die synthetisiertes Verständnis der Organisation enthält, statt dieses Verständnis immer wieder aus Rohdokumenten neu zu rekonstruieren.

Vom Dokumentenspeicher zur Wissensebene

Das verändert die Rolle von Systemen wie SharePoint. SharePoint kann weiterhin das maßgebliche Repository für Dokumente, Seiten, Richtlinien, Präsentationen, Besprechungsunterlagen und Zusammenarbeitsinhalte sein. Rohe Unternehmensinhalte ergeben jedoch nicht automatisch nutzbares Organisationswissen.

Eine KI-generierte Wissensebene kann über diesen Quellsystemen liegen und verstreute Informationen in eine Art organisatorische Landkarte verwandeln: Projekte sind mit Entscheidungen verbunden, Richtlinien mit Prozessen, Systeme mit Eigentümern und Konzepte mit ihren belegenden Nachweisen. Ziel ist nicht, die Quelldokumente abzuschaffen. Es geht darum, die Beziehungen, die in ihnen verborgen liegen, explizit zu machen.

Warum bessere Prompts die Architektur nicht lösen

Prompt Engineering kann verbessern, wie ein LLM den abgerufenen Kontext interpretiert, aber es kann nicht garantieren, dass überhaupt der richtige Kontext abgerufen wurde. Liefert die Retrieval-Ebene unvollständige Fragmente, übersieht eine wichtige Abhängigkeit oder liefert ein veraltetes Dokument, argumentiert selbst ein hervorragendes Modell auf Basis einer unvollständigen Informationsmenge.

Deshalb kann die alleinige Verbesserung des Modells nicht jedes Enterprise-AI-Problem lösen. Qualität und Struktur des Wissens, das dem Modell bereitgestellt wird, bleiben grundlegend. Kein noch so ausgeklügelter Prompt kann eine Architektur reparieren, die auf flüchtige Suchergebnisse statt auf strukturierten, dauerhaften Speicher setzt.

Das Governance-Problem wird größer

Mit dieser Architektur ist zudem eine deutliche Warnung verbunden. Enthält die SharePoint-Umgebung einer Organisation veraltete Richtlinien, doppelte Dokumentation, aufgegebene Prozesse, widersprüchliche Anweisungen oder Dokumente ohne klare Verantwortlichkeit, kann ein LLM Wiki diese fehlerhaften Informationen genauso effizient synthetisieren wie gute Informationen.

Die Gefahr besteht darin, dass synthetisiertes Wissen deutlich sauberer und maßgeblicher wirkt, als es die zugrunde liegenden Inhalte verdienen. KI macht klassische Informations-Governance daher wichtiger, nicht unwichtiger. Inhaltsverantwortung, Lebenszyklusmanagement, Versionierung, Aufbewahrung, Archivierungsprozesse, maßgebliche Quellen, Metadaten und klar definierte Systeme of Record werden zu grundlegenden Bausteinen der KI-Architektur.

KI-Bereitschaft beginnt mit der Qualität der Inhalte

Organisationen behandeln die Copilot-Bereitschaft häufig als Projekt rund um Lizenzierung, Sicherheit, Bereitstellung oder Schulung. Diese Aspekte sind wichtig, doch die zugrunde liegende Wissensbasis ist mindestens genauso entscheidend. Wenn niemand weiß, welches Dokument den aktuellen Prozess beschreibt, kann die KI die organisatorische Unklarheit nicht auf magische Weise auflösen.

Pflegen drei Abteilungen widersprüchliche Versionen einer Richtlinie, hat die KI drei Versionen der Wahrheit übernommen. Bleibt veraltete Dokumentation dauerhaft durchsuchbar, bleibt sie potenzielles Grundlagenmaterial. Enterprise-KI macht daher eine Wissensmanagement-Schuld sichtbar, die Organisationen bisher ignorieren konnten.

Warum Vertrauen über die Copilot-Akzeptanz entscheidet

Technische Folgen werden schnell zu geschäftlichen Folgen. Nutzer tolerieren gelegentliche Ungenauigkeiten, wenn KI eine E-Mail formuliert oder eine Besprechung zusammenfasst. Sie werden deutlich weniger nachsichtig, wenn die KI Richtlinien erklären, Kundenentscheidungen unterstützen, den Projektstatus interpretieren, Informationen zur Compliance liefern oder operative Prozesse anleiten soll.

Erhalten Nutzer bei wichtigen Fragen inkonsistente Antworten, greifen sie häufig wieder auf vertraute menschliche Experten und etablierte manuelle Prozesse zurück. Das ist ein wesentlicher Grund, warum die Copilot-Nutzung selbst nach einer scheinbar erfolgreichen Einführung wieder abflacht. Vertrauen wird daher zu einer architektonischen Anforderung und ist nicht nur eine Kennzahl für die Akzeptanz.

Fazit

Zusammengefasst hat Retrieval-Augmented Generation der Enterprise-KI zwar einen leistungsstarken Weg eröffnet, auf externe Dokumente zuzugreifen. Doch ihre zustandslosen Abfrageschleifen und Einschränkungen beim Chunking bedeuten, dass sie einem echten organisatorischen Gedächtnis oft nicht gerecht wird. Ohne persistente Wissensverdichtung werden Systeme wie Copilot weiterhin Probleme mit Konsistenz, tiefen Kontextzusammenhängen und dem Vertrauen in Unternehmen haben. Der Übergang von reinen Dokumentenablagen zu einer strukturierten, verdichteten Wissensschicht – etwa dem aufkommenden LLM-Wiki-Ansatz – ist der Schlüssel, um die Lücke zwischen beeindruckenden Demos und verlässlichen Geschäftswerkzeugen zu schließen. Um dieses Thema weiter zu vertiefen und unsere vollständige Analyse zur Verbesserung des KI-Gedächtnisses im Unternehmen zu hören, hören Sie sich die komplette Episode auf Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It an.