Wie Chatbot auf RAG-Basis arbeiten

Wie RAG-Systeme arbeiten

Retrieval-Augmented Generation, kurz RAG, besteht im Kern 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 fast alle modernen RAG-Chatbots basieren.
Doch damit sie in einem Unternehmen wirklich funktionieren, braucht es zwei zentrale 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 Feedback 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.

Später, wenn wir über den dritten Pfad sprechen, wird deutlich, wie genau diese Zusammenarbeit zwischen Creator und Nutzern das System lebendig hält.

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.

Für das Lesen und Transformieren der Dokumente setzen wir bei Nauli bewusst auf starke Open-Source-Bibliotheken wie PyMuPDF und Docling.
Sie haben sich in der Praxis als stabil und leistungsfähig erwiesen, auch bei komplexen PDFs und größeren Dokumentmengen.

Nach dem Chunken und Embedden landen die Inhalte in einer Vektor-Datenbank.
Hier bietet Nauli die Wahl zwischen ChromaDB oder Postgres mit passenden Vektor-Erweiterungen, je nach Architektur, Skalierungsbedarf und bestehender Infrastruktur.
Auf diese Entscheidung und ihre Auswirkungen gehen wir in einem späteren Artikel noch genauer ein.

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 wie ein GPT-5 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 den größten Fokus genau auf diese Phase.
Nauli prüft beim Einlesen jedes Dokuments automatisch die Lesbarkeit, Konsistenz und Struktur und gibt dem sogenannten 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 der Chatbot wirklich hilfreich ist 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, genau so wie im Diagramm: 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. (Top K ist ein Parameter, Top 3 ist ein typischer Startwert.)
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.
Auf diese Varianten und deren Vor- und Nachteile gehen wir in einem späteren Artikel genauer ein.
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.

Ausblick

Die meisten Beschreibungen von RAG enden hier – beim Zusammenspiel von Ingestion und Q&A.
Doch im praktischen Einsatz zeigt sich schnell: Ohne Rückkopplung durch reale Nutzer bleibt das System statisch.

Mit Nauli führen wir deshalb einen dritten Pfad ein, der diese Lücke schließt: den Feedback- und Reranking-Pfad.
Er macht den Chatbot lernfähig, ohne das Sprachmodell selbst zu verändern.
Darüber sprechen wir im nächsten Teil ausführlicher.