RAG-Implementierung im Unternehmen: So wird internes Wissen nutzbar

Wann eine RAG-Implementierung im Unternehmen sinnvoll ist

Ein RAG-Chatbot wird im Unternehmen selten eingeführt, weil das Akronym spannend klingt. Der eigentliche Anlass ist meist viel pragmatischer:

• Mitarbeitende suchen zu lange nach Informationen in PDFs, Wikis und Dateiablagen.
• Fachabteilungen beantworten dieselben internen Fragen immer wieder neu.
• Onboarding stockt, weil Prozesse und Richtlinien nicht schnell genug auffindbar sind.
• Support- oder Service-Teams verlieren Zeit mit wiederkehrenden Standardanfragen.

Wenn Kunden nach Themen wie Unternehmenswissen nutzbar machen, interne Fragen mit KI beantworten, Wissensmanagement mit Chatbot oder Chatbot RAG Implementierung suchen, meinen sie genau diese Probleme.

Retrieval-Augmented Generation, kurz RAG, ist deshalb vor allem eines: ein Weg, verteiltes Wissen im Arbeitsalltag schneller, sicherer und kontextbezogen nutzbar zu machen. Im Kern besteht RAG aus zwei Hauptpfaden:

• 1. Ingestion-Pfad – bereitet Wissen auf, strukturiert es und legt die Grundlage für die spätere Suche.
• 2. Q&A-Pfad – nutzt dieses Wissen im Dialog, um relevante Antworten zu formulieren.

Diese beiden Pfade bilden das Fundament, auf dem moderne RAG-Chatbots basieren.
Damit sie in einem Unternehmen wirklich funktionieren, braucht es aber zusätzlich zwei klare Rollen:

• - Creator: die Person, die den Chatbot einrichtet, Daten hochlädt, prüft und pflegt.
  Das muss kein Entwickler oder IT-Administrator sein, sondern jemand, der das Fachwissen versteht und bereit ist, Verantwortung für die Qualität der Inhalte zu übernehmen.
  Der Creator ist sozusagen die „Wissenskuratorin“ oder der „Wissenskurator“ des Systems.
• - Nutzer: die Personen, die später mit dem Chatbot arbeiten, Fragen stellen und Rückmeldungen geben.
  Ihr Verhalten und ihre Rückmeldungen helfen, die Wissensbasis stetig zu verbessern.

Erst wenn diese beiden Rollen im Unternehmen klar sind, entfalten die technischen Pfade von RAG ihren echten Mehrwert.
Und genau hier setzt Nauli an: Es bietet beiden Rollen Werkzeuge, um Wissen verständlich, sicher und dynamisch nutzbar zu machen.

Typische Anwendungsfälle im Unternehmen

Ein RAG-Chatbot ist besonders dann sinnvoll, wenn Antworten aus vorhandenen Dokumenten, Richtlinien oder Wissensquellen kommen sollen. Typische Beispiele sind:

• interne HR-Fragen wie Urlaubsregeln, Onboarding oder Richtlinien
• Wissensmanagement für Fachabteilungen und interne Supportteams
• dokumentbasierte Service- und Kundenanfragen
• produkt- oder prozessbezogene Rückfragen, bei denen Quellen wichtig sind

Wie eine RAG-Implementierung im Unternehmen abläuft

Wer nach einer RAG-Implementierung sucht, meint in der Praxis meist keinen einzelnen technischen Schritt, sondern ein Vorhaben mit mehreren Phasen.

Typischerweise läuft ein solches Projekt so ab:

• Ziele, typische Fragen und Prioritäten gemeinsam mit den Fachbereichen festlegen
• relevante Wissensquellen auswählen und inhaltlich bereinigen
• Ingestion, Chunking und semantische Suche technisch aufsetzen
• Antwortqualität mit realen Fragen testen und nachschärfen
• Pilot mit begrenztem Nutzerkreis starten und danach schrittweise ausrollen

Genau diese Abfolge ist wichtig. Wer nur das Modell auswählt, aber Datenbasis, Testfragen und Rollout offenlässt, bekommt selten ein stabiles System. Für die produktive Umsetzung braucht es sowohl technische als auch organisatorische Klarheit.

Wenn Ihr konkretes Problem eher eine langsame oder unpräzise interne Suche ist, hilft zusätzlich unser Praxisbeitrag zur Intranet-Suche und KI-Suchlösung.

1. Der Ingestion-Pfad: wo die meisten Probleme entstehen

Bevor ein Chatbot überhaupt eine Antwort geben kann, muss er das Wissen des Unternehmens erst einmal verstehen können.
Und genau hier beginnt der schwierigste Teil.

Die Abbildung zeigt den grundlegenden Ablauf des Ingestion-Pfads.
Ein Creator lädt Unternehmensdokumente hoch, etwa PDFs, Office-Dateien oder Inhalte aus anderen Quellen.
Diese Dokumente werden gelesen, in ein einheitliches Format transformiert, geprüft, in sinnvolle Abschnitte unterteilt und anschließend in eine Vektor-Datenbank überführt.

Wichtig ist dabei die Rolle des Creators.
Er oder sie muss kein IT-Experte sein, übernimmt aber Verantwortung für die Qualität des Wissens.
Wenn beim Einlesen oder Prüfen der Dokumente Probleme auftreten, etwa unklare Struktur, doppelte Inhalte oder fehlende Lesbarkeit, wird der Creator aktiv eingebunden und kann gezielt nachschärfen.

Nach dem Chunken und Embedden landen die Inhalte in einer Vektor-Datenbank.
Welche Architektur sinnvoll ist, hängt dann von Datenmenge, Sicherheitsanforderungen und bestehender Infrastruktur ab. Für Unternehmen ist aber vor allem entscheidend: Aus unübersichtlichen Dokumenten muss ein belastbarer, durchsuchbarer Wissensbestand werden.

An dieser Stelle ist nur eines wichtig zu verstehen:
Wenn dieser Pfad nicht sauber umgesetzt ist, können selbst die besten Sprachmodelle keine guten Antworten liefern.
Die Qualität eines RAG-Systems wird zu einem großen Teil bereits hier entschieden.

Schon zu Beginn tauchen Fragen auf, die oft unterschätzt werden:

• Welche Daten sind relevant?
  In vielen Unternehmen gibt es eine Mischung aus Richtlinien, PowerPoints, PDFs, E-Mails und Datenbankexporten. Meist weiß niemand genau, welche Quellen wirklich vollständig oder aktuell sind.
• Wo liegen die Daten?
  Lokal, in SharePoint, auf Netzlaufwerken oder in privaten Ablagen? Schon die Suche nach konsistenten Speicherorten ist oft eine eigene Projektphase.
• In welchem Zustand sind sie?
  Veraltete Versionen, fehlerhafte Kodierungen, doppelte Dokumente oder unterschiedliche Dateistrukturen erschweren die Automatisierung.

Diese Fragen klingen banal, entscheiden aber, ob ein RAG-System überhaupt belastbar arbeiten kann.

Und hier meine persönliche Empfehlung:
Fangt klein an.
Nehmt euch zunächst ein paar einfache PDF-Dokumente, etwa interne Richtlinien wie
„Tragen von Sicherheitsschuhen“, „Umgang mit mobilen Geräten“ oder „Passwortregeln“ –
und startet mit diesen. Parallel dazu arbeitet ihr daran, Schritt für Schritt immer mehr
gesäuberte, konsistente Daten in das System zu bringen.

So bekommt ihr schnell erste Ergebnisse, ohne euch im Perfektionsanspruch zu verlieren
und das RAG-System wächst organisch mit der Qualität eurer Daten.

Der Klassiker: PDF

Das häufigste Format im Unternehmenskontext ist zugleich das problematischste.
Ein PDF sieht am Bildschirm sauber aus, ist intern aber oft chaotisch.
Zeilenumbrüche sind willkürlich, Textabschnitte werden als einzeln positionierte Fragmente gespeichert, Überschriften sind nicht als solche markiert.

Noch kritischer wird es, wenn PDFs aus Scans bestehen.
Dann enthält die Datei nur Bilder: kein einziger echter Buchstabe.
Ohne eine saubere OCR-Erkennung (Optical Character Recognition) bleibt der Inhalt für das System unsichtbar.

Typische Stolpersteine, die uns in Projekten immer wieder begegnen:

Problem	Ursache	Wirkung im Chatbot
Text nicht lesbar	Scan ohne OCR oder fehlerhafte Kodierung	Das LLM erhält leere oder sinnlose Eingaben.
Falsche Reihenfolge	Layout-basierte PDF-Struktur, Spalten oder Tabellen nicht erkannt	Antworten vermischen Inhalte oder verlieren Kontext.
Bilder ignoriert	Parser erkennt keine Abbildungen oder Beschriftungen	Wichtige Informationen (z. B. Prozessdiagramme) fehlen völlig.
Versionen-Chaos	Alte und neue Dokumente gleichzeitig im Index	Widersprüchliche Antworten, weil der Bot beide Quellen gleichwertig behandelt.

Selbst das leistungsfähigste Sprachmodell kann aus solchen Eingaben keine guten Ergebnisse erzeugen.
Ein starkes LLM ersetzt keine saubere Datenbasis.
Wenn die Ingestion schwach ist, bleibt das gesamte System unpräzise, egal, wie teuer oder „intelligent“ das Modell ist.

Das unterschätzte Problem der Struktur

Viele Unternehmen unterschätzen, wie viel Struktur in scheinbar unstrukturierten Daten steckt oder umgekehrt.
Eine PDF-Richtlinie mag für Menschen klar gegliedert sein, für Maschinen ist sie eine Abfolge von Textblöcken ohne Hierarchie.
Tabellen verlieren ihre Bezüge, Listen verschwinden, Absätze fließen zusammen.

Fehlt hier eine intelligente Transformation – etwa in Markdown oder ein anderes leichtgewichtiges Zwischenformat –,
dann fehlt dem System die semantische Ordnung, die es später für die Chunking- und Embedding-Phase braucht.

Gerade bei Tabellen, Diagrammen und eingebetteten Bildern entscheidet sich,
ob ein Chatbot später präzise antwortet oder nur Fragmente wiederholt.

Warum hier der Unterschied gemacht wird

In der Praxis wird viel Energie auf das LLM gelegt – Parameter, Modelversion, Kontextlänge.
Doch diese Optimierung bringt wenig, wenn der Ingestion-Pfad fehlerhaft ist.
Er ist die Grundlage, auf der alles aufbaut.

Die Qualität der Daten bestimmt:

• wie gut die semantische Suche später funktioniert,
• wie zuverlässig der Kontext erfasst wird,
• und wie stark die Halluzinationsneigung des Modells ist.

Deshalb legen wir bei Kunftia in Projekten einen großen Fokus genau auf diese Phase.
Nauli prüft beim Einlesen jedes Dokuments automatisch Lesbarkeit, Konsistenz und Struktur und gibt dem Creator Hinweise, wo Nacharbeit nötig ist.
Denn nur, wenn hier sauber gearbeitet wird, kann der Chatbot später präzise, nachvollziehbar und vertrauenswürdig antworten.

2. Der Q&A-Pfad: Fragen verstehen und Antworten zusammensetzen

Sobald der Nutzer eine Frage stellt, tritt der Q&A-Pfad in Aktion.
Hier entscheidet sich, ob ein RAG-Chatbot im Alltag wirklich hilft oder ob er nur gut klingende Standardantworten liefert.

Wenn man sich den Q&A-Pfad genau anschaut, dann ist er im Prinzip eine klare Kette von Schritten: Erst wird die Frage verarbeitet, dann wird gesucht, dann wird aus den Treffern der Kontext gebaut und erst ganz am Ende generiert das LLM die Antwort.

Schritt	Ziel	Beschreibung
1. Frage stellen	Startpunkt der Anfrage.	Der Nutzer formuliert eine Frage im Chat.
2. Query Embedding	Die Frage maschinenlesbar machen.	Die Frage wird in einen Vektor übersetzt, also in eine semantische Repräsentation im gleichen Vektorraum wie die Dokumente.
3. Similarity Search	Relevante Inhalte finden.	In der Vektor-Datenbank wird nach den ähnlichsten Chunks gesucht. Häufig wird dafür Cosine Similarity verwendet.
4. Top 3 Chunks	Die besten Treffer auswählen.	Aus allen Kandidaten werden die Top 3 Chunks mit dem höchsten Similarity-Score ausgewählt.
5. Kontext bauen	Kontext für das LLM vorbereiten.	Die ausgewählten Chunks werden zusammengeführt, sortiert und oft um Metadaten ergänzt (Quelle, Abschnitt, Datum).
6. LLM generiert Antwort	Antwort formulieren.	Das LLM bekommt den gebauten Kontext und formuliert daraus eine Antwort, idealerweise ohne außerhalb dieses Kontexts zu raten.
7. Antwort	Ausgabe an den Nutzer.	Die Antwort wird im Chat angezeigt.

Der wichtigste Schritt in diesem Pfad ist aus meiner Sicht ganz klar die Suche.
Genauer gesagt: die semantische Suche.
Sie ist das Herzstück eines jeden RAG-Systems.

Im Gegensatz zur klassischen Keyword-Suche geht es hier nicht darum, ob ein Wort exakt im Text vorkommt.
Es geht darum, ob die Bedeutung der Frage zu einem Abschnitt im Dokument passt.
Eine Frage wie „Wie melde ich einen Arbeitsunfall?“ kann so auch dann beantwortet werden, wenn im Dokument von „Meldung eines Arbeitsunfalls“ die Rede ist.
Der Wortlaut ist unterschiedlich, der Sinn ist gleich – und genau das erkennt die semantische Suche.

In der Praxis greifen wir dabei auf eine Vektor-Datenbank zurück, die die Ähnlichkeit zwischen Frage und Dokumenten misst, meist über Cosine Similarity.
Die besten Treffer, zum Beispiel die Top 3 mit dem höchsten Ähnlichkeitswert, werden ausgewählt und an das Sprachmodell weitergegeben.

Natürlich ist semantische Suche nicht die einzige Möglichkeit.
Es gibt auch Keyword-basierte Ansätze, graphbasierte Modelle oder Kombinationen aus mehreren Technologien.
Je nach Anwendungsfall können diese Varianten sinnvoll sein.
Für diesen Kontext ist nur wichtig zu verstehen:
Ohne gute semantische Suche gibt es kein gutes RAG-System.

Erst im letzten Schritt kommt das LLM ins Spiel.
Es „weiß“ in diesem Moment nichts Neues, sondern formuliert lediglich eine Antwort auf Basis der gefundenen Inhalte.

Ein gut abgestimmter Q&A-Pfad schafft hier die Balance:
schnell genug, um akzeptiert zu werden,
präzise genug, um echten Mehrwert zu liefern,
und kontrolliert genug, um Halluzinationen zu vermeiden.

Fazit

Die meisten Beschreibungen von RAG enden beim Zusammenspiel von Ingestion und Q&A.
Für den praktischen Einsatz reicht es aber nicht, nur über Modelle zu sprechen. Entscheidend sind saubere Daten, eine belastbare semantische Suche und klare Verantwortlichkeiten im Unternehmen.

Genau deshalb betrachten wir bei Nauli nicht nur das Sprachmodell, sondern den gesamten Prozess: vom Einlesen der Dokumente bis zur Antwort im Dialog. Erst dieses Zusammenspiel macht RAG-Chatbots im Unternehmenskontext nachvollziehbar, nützlich und vertrauenswürdig.

Wenn Sie eher aus der Problemrichtung kommen und klären möchten, warum Unternehmenswissen bei Chatbots den Unterschied macht, lesen Sie auch Chatbot für Unternehmen: Warum Unternehmenswissen den Unterschied macht. Für ein aktuelles Praxisbeispiel aus einem historisch gewachsenen Intranet lesen Sie außerdem Intranet-Suche verbessern: Welche KI-Suchlösung besser als die Standardsuche ist. Mehr zur konkreten Lösung finden Sie auf unserer Produktseite zum Chatbot für internes Wissen.