Die meisten KI-Projekte, die wir begleiten, starten mit derselben Beobachtung des Auftraggebers: „Wir haben das Wissen im Haus — wir finden es nur nicht wieder.” Es liegt verteilt auf Wiki-Seiten aus drei Jahren, in Ticket-Verläufen, in Word-Dokumenten auf Dateifreigaben, in E-Mails. Suche-Funktionen funktionieren halb — entweder finden sie zu viel oder das Falsche.
RAG, Retrieval Augmented Generation, ist die Technologie, die diese Lücke gezielt schließt. Aber sie funktioniert nicht out-of-the-box. Sie braucht eine durchdachte Architektur.
Was RAG technisch wirklich macht
Ein RAG-System besteht aus drei Schichten:
- Retrieval: zu einer gestellten Frage werden relevante Textstellen aus den indexierten Quellen herausgesucht — meist über Vektorähnlichkeit, oft kombiniert mit klassischer Keyword-Suche.
- Augmentation: die gefundenen Textstellen werden in den Kontext des Sprachmodells gegeben — als Anhang zur eigentlichen Frage.
- Generation: das Sprachmodell formuliert eine Antwort auf Basis dieses Kontexts — idealerweise mit Quellenangabe zu den verwendeten Textstellen.
Das Modell „weiß” nichts über das Unternehmen — es weiß nur, was im aktuellen Kontext steht. Was es dort findet, fasst es zusammen, kombiniert es, formuliert es. Was es nicht findet, kann es nicht beantworten — und genau das ist die gewünschte Eigenschaft.
Welche Quellen sich eignen
Drei Quell-Kategorien sind in mittelständischen Unternehmen typisch und gut zugänglich:
- Wikis und Confluence-ähnliche Systeme. Strukturiert, oft mit klarer Aktualitätsmarkierung, gut indexierbar. Erfahrungsgemäß die wertvollste Quelle, wenn sie gepflegt ist.
- Tickets und ihre Lösungen. Eine Goldgrube für Support- und IT-Anwendungen. Wenn dieselbe Frage schon zwölfmal gestellt und gelöst wurde, weiß die Suche nach dem RAG-Index Bescheid.
- Dokumente auf Dateifreigaben. PDF, Word, manchmal Excel. Mit deutlich mehr Aufbereitungsaufwand verbunden — Strukturierung, Versions-Bereinigung, Bereich-Zuordnung — aber oft sind hier die wirklich verbindlichen Festlegungen.
Nicht jede Quelle muss in jedem RAG-Index landen. Ein RAG-System für den IT-Service braucht Tickets und IT-Runbooks; ein RAG-System für die Buchhaltung braucht Steuerrichtlinien und Vertragsmuster. Die Aufteilung in mehrere fokussierte Indizes ist meistens besser als ein großer Universalindex.
Berechtigungen — der oft unterschätzte Knackpunkt
Ein RAG-System muss mit den Berechtigungen der jeweiligen Person umgehen. Wenn die HR-Abteilung Zugriff auf Personalakten hat und die IT nicht, dann darf das RAG-System einer IT-Person keine Antwort zusammenstellen, die auf Personalakten basiert.
Das klingt selbstverständlich. In der Praxis ist es einer der häufigsten Fehler — weil es technisch aufwendig ist:
- Jede Quelle muss Berechtigungs-Metadaten haben.
- Der Vektorindex muss diese Metadaten beim Retrieval auswerten.
- Auch das Sprachmodell muss verstehen, dass es in seiner Antwort keine Informationen aus Quellen verwenden darf, auf die der Anfrager keinen Zugriff hat.
Wir haben Setups gesehen, in denen aus Bequemlichkeit auf diese Trennung verzichtet wurde — mit dem Argument „alle Daten sind ja sowieso im Haus”. Das ist rechtlich riskant und organisatorisch toxisch. Ein RAG-System muss von Anfang an mit den vorhandenen Berechtigungsstrukturen leben.
Wie eine produktive Architektur aussieht
In vereinfachter Form besteht ein produktives RAG-Setup aus:
- Quellen-Adapter. Pro Quellsystem (Wiki, Ticket, Dateifreigabe) ein Konnektor, der Inhalte abruft, normalisiert und mit Metadaten anreichert.
- Pipeline für Aufbereitung. Texte werden in passende Stücke zerlegt („chunks”), in Vektoren überführt, im Index gespeichert. Aktualisierungen laufen periodisch (täglich oder bei Änderung).
- Retrieval-Schicht. Auf eine Anfrage werden relevante Chunks mit Berechtigungsfilter zurückgegeben. Oft kombiniert mit zusätzlicher Re-Sortierung („reranking”) für bessere Treffer.
- Generation-Schicht. Das Sprachmodell bekommt Frage und gefundene Chunks, formuliert die Antwort, gibt Quellen mit aus.
- Audit-Schicht. Jede Anfrage, jede gefundene Quelle, jede Antwort wird protokolliert — für Qualitätskontrolle und Compliance.
Eine solche Architektur kann auf Open-Source-Bausteinen vollständig im eigenen Rechenzentrum laufen. Cloud-Lösungen sind möglich, bringen aber zusätzliche Datenschutz-Klärung mit sich.
Wo der häufigste Fehler steckt
Aus den Projekten, die wir gesehen haben, ist der häufigste Stolperstein das Quellen-Tuning. Ein RAG-Index ist nur so gut wie die Strategie, wie Inhalte in Chunks zerlegt werden. Zu kleine Chunks: zu wenig Kontext für eine gute Antwort. Zu große Chunks: zu viel Rauschen, falsche Treffer.
Es gibt keine Universalantwort. Eine produktive Chunk-Strategie wird in den ersten vier bis sechs Wochen mit echten Anfragen geprüft und nachjustiert — das ist Handarbeit, aber sie zahlt sich aus.
Was am Ende sichtbar wird
Ein gut umgesetztes RAG-System macht aus „wir haben das Wissen, wir finden es nur nicht” ein „wir fragen, und wir bekommen eine Antwort mit Quellenangabe”. Der Effekt ist nicht spektakulär, aber tief: Mitarbeiter sind schneller, neue Mitarbeiter werden früher einsatzfähig, fachliche Inkonsistenzen werden sichtbar — weil das System sie freilegt.
Das ist die produktive Seite von KI im Mittelstand. Nicht laut, aber spürbar.