RAG-Systeme im Unternehmen: was sie leisten und wo sie scheitern

Warum RAG überhaupt existiert

Große Sprachmodelle sind auf einem Ausschnitt des öffentlichen Internets trainiert. Ihr eigenes Unternehmenswissen, also Handbücher, Verträge, Tickets, Produktdokumentation, interne Richtlinien, ist dort nicht enthalten. Wer einem generischen LLM eine konkrete Frage zum eigenen Geschäft stellt, bekommt entweder eine unscharfe Antwort oder eine, die gut klingt, aber nicht stimmt.

Retrieval Augmented Generation schließt genau diese Lücke. Das Modell beantwortet eine Frage nicht mehr aus dem Gedächtnis, sondern bekommt vor der Antwort passende Textstellen aus einer eigenen Wissensbasis eingeblendet. Die eigentliche Intelligenz steckt dabei nicht im Modell, sondern im Retrieval: welche Inhalte werden wie gefunden, aufbereitet und dem Modell mitgegeben.

Wo RAG im Unternehmen wirklich trägt

RAG ist am stärksten, wenn drei Bedingungen zusammenkommen: Es gibt eine klar umrissene Menge an Inhalten, die Fragen sind relativ stabil, und die Antworten müssen belegbar auf diese Inhalte zurückgehen. In dieser Kombination schlägt ein gut gebautes RAG-System jede generische Chat-Lösung.

Typische Beispiele sind interne Wissensportale für Handbücher und Richtlinien, unterstützende Assistenten für Support- und Service-Teams, Recherche-Werkzeuge für Verträge oder Angebote sowie technische Dokumentations-Assistenten für Engineering-Teams. Gemeinsam haben diese Use Cases, dass ein falsches Detail einen sichtbaren Schaden anrichten kann und daher nachvollziehbar bleiben muss, woher eine Aussage stammt.

Weniger geeignet ist RAG, wenn die eigentliche Aufgabe kreativ ist, die Wissensbasis klein und stabil genug für einen einfachen Prompt oder wenn die Domäne so schlecht strukturiert ist, dass selbst Menschen die richtige Quelle kaum finden. In diesen Fällen verbessert man eher die Inhalte als die Architektur.

Typische Fallstricke im Alltag

Der erste Fallstrick liegt nicht im Modell, sondern in den Daten. Viele Inhalte sind uneinheitlich aufgebaut, enthalten veraltete Passagen, Duplikate oder tote Links. Ein RAG kann das nicht reparieren. Was reingeht, bestimmt, was rauskommt. Eine sinnvolle Datenaufbereitung ist kein Nebenprojekt, sondern ein Kernbestandteil jeder RAG-Einführung.

Der zweite Fallstrick betrifft das Chunking. Werden Dokumente zu grob geteilt, verliert das Retrieval Präzision. Werden sie zu klein zerlegt, verlieren Abschnitte ihren Kontext. Beides sieht man dem ersten Prototyp selten an, es zeigt sich erst, wenn Nutzer echte Fragen stellen und Antworten daneben liegen.

Der dritte Fallstrick ist das Vertrauen in einfache Vektorsuche. Für homogene Texte reicht das oft, für reale Unternehmensdaten nicht. Hybride Verfahren aus semantischer Suche und klassischer Volltextsuche liefern in der Praxis spürbar stabilere Ergebnisse. Welche Kombination passt, hängt von der Struktur der Inhalte und den typischen Fragen ab.

Der vierte Fallstrick ist fehlende Messbarkeit. Ohne saubere Evaluation weiß niemand, ob eine Änderung am Prompt, am Retrieval oder an den Daten die Qualität verbessert oder verschlechtert hat. Hier überschneidet sich RAG stark mit dem Feld der LLM-Qualitätssicherung: Testdaten, Metriken und systematische Regressionen gehören zu einem erwachsenen RAG-System genauso dazu wie Monitoring.

Was ein belastbares RAG-System ausmacht

Ein RAG-System, das im Betrieb trägt, erkennt man weniger an einem beeindruckenden Demo-Moment und mehr an seinem Verhalten im Alltag. Es liefert Antworten, die auf sichtbare Quellen zurückführen. Es sagt „ich weiß es nicht“ oder „dazu gibt es keine Informationen“, statt zu halluzinieren. Es respektiert Berechtigungen, so dass Nutzer nur sehen, was sie ohnehin sehen dürften. Und es lässt sich weiterentwickeln, ohne dass bei jeder Änderung die gesamte Architektur wackelt.

Technisch bedeutet das eine saubere Ingestion-Pipeline, eine bewusst gewählte Kombination aus Embeddings und Index, ein Retrieval, das sowohl auf Relevanz als auch auf Vielfalt achtet, sowie eine klar trennbare Antwortschicht mit Prompts, die Halluzinationen aktiv einschränken. Organisatorisch bedeutet es, dass es Verantwortliche für Inhalte, Berechtigungen und Qualität gibt, nicht nur für die Anwendung.

RAG, Agenten und das umgebende System

RAG wird in der Diskussion gerne gegen „Agenten“ gestellt, als wären es zwei konkurrierende Ansätze. In der Praxis ergänzen sie sich. RAG liefert den inhaltlichen Unterbau: Informationen aus den richtigen Quellen, mit Beleg. Ein KI-Agent kann darauf aufbauen, Schritte planen, Systeme abfragen oder Aktionen auslösen. Viele produktiv genutzte Assistenten sind heute eine Mischung aus beidem: Retrieval, das Fakten liefert, und Agenten-Logik, die damit etwas Sinnvolles tut.

Unabhängig davon, ob ein System rein als Frage-Antwort-Werkzeug oder mit Agenten-Fähigkeiten gebaut wird, bleibt die Architektur entscheidend. Modelle, Retrieval, Orchestrierung, Monitoring und Betrieb müssen zusammenpassen. Das ist der Punkt, an dem unser Bereich AI Engineering ansetzt.

Wann externe Unterstützung sinnvoll ist

Ein kleiner RAG-Prototyp für ein gut aufgeräumtes Wiki ist heute in wenigen Tagen gebaut. Der Anspruch, damit ein produktives System zu betreiben, das mehreren Teams, verschiedenen Datenquellen und wechselnden Inhalten standhält, liegt deutlich darüber. Spätestens dort lohnt sich ein Blick von außen: auf Architektur, Datenaufbereitung, Evaluationskonzept und Betriebsmodell.

Wir arbeiten mit Unternehmen, die RAG nicht als Selbstzweck, sondern als Werkzeug sehen, mit dem konkrete Prozesse besser werden sollen. Wenn das zu Ihrer Situation passt, sprechen Sie uns an, am besten zu Beginn, wenn Zielbild, Quellen und Erfolgskriterien noch gestaltbar sind.