Chatbot auf Basis von Firmendokumenten – wie RAG funktioniert und wie Sie KI-Halluzinationen vermeiden

Kunden fragen uns immer häufiger danach: “Könnten wir einen Assistenten haben, der unsere Dokumente kennt und Mitarbeitenden sowie Kunden Fragen zu Angeboten, Prozessen und Verträgen beantwortet?”. Und so beginnt üblicherweise das Gespräch über einen RAG-Chatbot. Wir, Web Systems, ein seit 2006 tätiger software house aus Łódź, betrachten das ohne Illusionen. Das ist kein Spielzeug für die Show. Das ist ein vollwertiges Integrationsprojekt mit Architektur, Sicherheit und Wartung. In diesem Artikel zeige ich Ihnen, wie ein Chatbot auf Basis von Firmendokumenten funktioniert, worin die RAG-Technologie besteht und wie sich Halluzinationen der Künstlichen Intelligenz wirklich eindämmen lassen.

Was ein Chatbot auf Basis von Firmendokumenten ist und warum RAG die Spielregeln verändert

Ein gewöhnliches Sprachmodell antwortet auf Grundlage des allgemeinen Wissens, das es beim Training aufgenommen hat. Nur kennt es weder Ihr Angebot noch Ihre Preisliste, Ihre Reklamationsordnung oder Ihren internen Onboarding-Prozess. Woher auch? Nach Details gefragt, beginnt es zu raten. Und genau dort entstehen teure Fehler. Ein Chatbot, der auf der internen Wissensbasis des Unternehmens aufsetzt, arbeitet anders: Er stützt seine Antworten auf reale Dateien und nicht auf die Vorstellung des Modells davon, wie Ihr Unternehmen funktionieren könnte.

Die Abkürzung RAG steht für Retrieval-Augmented Generation, also für eine durch Suche angereicherte Generierung. Die Idee ist denkbar einfach. Das Modell durchsucht zuerst die Dokumente, findet passende Fragmente und formuliert erst danach eine Antwort auf deren Grundlage. Dadurch hört die Künstliche Intelligenz auf, ein Orakel zu sein, das aus dem Gedächtnis erzählt. Sie wird zu einem Assistenten, der die Quelle liest, bevor er irgendetwas sagt. Das ist eine Änderung der Funktionslogik von Grund auf.

Die Absicht unserer Kunden ist meist klar: die Mutmaßungen der KI eindämmen und die Antworten an konkrete Prozesse, Angebote, Verträge und technische Dokumentation binden. Niemand will ein effektvolles Gadget, das mal richtig liegt und mal einen Vertragsparagrafen erfindet. Unternehmen erwarten ein verlässliches Werkzeug, das einen Teil der Anrufe von der Kundenbetreuung nimmt und die Suchzeit der Mitarbeitenden verkürzt. Mehr nicht. Darum geht es tatsächlich.

Wir als Dienstleister behandeln ein solches System wie ein Ingenieursprojekt. Es erfordert eine durchdachte Datenverarbeitungspipeline, die Auswahl der Vektordatenbank, die Integration mit vorhandenen B2B-Systemen und eine Zugriffskontrolle. Ein an einem Wochenende zusammengezimmertes Demo kann in einer Präsentation Eindruck machen. Doch eine produktive Umsetzung, die Hunderte Dokumente und viele Nutzer bedient, folgt völlig anderen Gesetzen. Dieser Unterschied wird erst sichtbar, wenn der Chatbot mit echten Daten und echtem Traffic zu arbeiten beginnt. Vorher spürt ihn niemand.

Wie RAG technisch funktioniert – vom Dokument zur Antwort

Alles beginnt mit der Ingestion, also dem Einlesen der Dokumente in das System. PDF-Dateien, DOCX, Tabellen oder Datensätze aus einer Datenbank gelangen in eine Pipeline, wo sie geparst und von störenden Elementen wie Fußzeilen, Kopfzeilen oder sich wiederholenden Tabellen bereinigt werden. Danach zerlegen wir den Inhalt in kleinere Fragmente, sogenannte Chunks. Und die Art dieser Zerlegung hat enorme Bedeutung. Zu große Fragmente verwässern den Sinn, zu kleine verlieren den Kontext. Man muss genau die Mitte treffen.

Jedes Fragment wandeln wir in ein Embedding um, also in einen Zahlenvektor, der die Bedeutung des Textes repräsentiert. Diese Vektoren landen in einer Vektordatenbank, die einen blitzschnellen Vergleich der semantischen Ähnlichkeit ermöglicht. Stellt ein Nutzer eine Frage, wandelt das System auch sie in einen Vektor um und sucht die Fragmente, die im Bedeutungsraum am nächsten liegen. Diese semantische Suche unterscheidet sich vom klassischen Abgleich von Wörtern. Es zählt der Sinn der Anfrage, nicht der identische Wortlaut.

In der Generierungsphase gelangen die ausgewählten Fragmente als Kontext in das Sprachmodell. Das LLM erhält die Anweisung, ausschließlich auf Basis des gelieferten Materials zu antworten, und das nennen wir Grounding. Durch diese Verankerung der Antworten in echtem Text minimiert das Modell Widersprüche und hört auf zu improvisieren. Die Qualität dieses Schritts hängt unmittelbar von der Treffsicherheit der vorangegangenen Suche ab. Müll rein, Müll raus.

Vereinfacht sieht der Datenfluss folgendermaßen aus:

1. Das Quelldokument (PDF, DOCX, Datenbank) gelangt in das System und wird geparst.
2. Chunking teilt den Inhalt in inhaltlich zusammenhängende Fragmente.
3. Embedding wandelt jedes Fragment in einen Vektor um und speichert ihn in der Vektordatenbank.
4. Die Suche wählt die Fragmente aus, die am besten zur Frage des Nutzers passen.
5. Die Antwort entsteht auf Basis des abgerufenen Kontexts, unter Wahrung des Groundings.

Das Wichtigste an alldem ist das Retrieval. Eine gute semantische Suche über einer sorgfältig kuratierten Wissensbasis entscheidet darüber, ob das Modell das richtige Material erhält. Ein verfehlter Kontext führt zu einer formal korrekten, thematisch aber völlig danebenliegenden Antwort. Klar gesagt: Das Modell kann eine Frage, die niemand gestellt hat, wunderbar beantworten, wenn wir ihm die falschen Fragmente unterschieben. Deshalb betrachten wir die Investition in das Retrieval als Herzstück des gesamten Systems. Hier gewinnt oder verliert man.

Woher KI-Halluzinationen kommen und wie RAG sie eindämmt

Eine Halluzination ist eine Situation, in der das Modell Daten erfindet, die in den Dokumenten nicht vorkommen, oder Fakten aus verschiedenen Quellen vermischt. Heraus kommt eine Antwort, die glaubwürdig klingt und dennoch falsch ist. Eine nicht existierende Vertragsklausel, ein falscher Satz, eine erfundene Garantiefrist. Im Geschäftsleben können solche Fehler teuer werden, denn der Nutzer vertraut dem Assistenten und handelt nach dessen Worten.

Allein RAG anzuschließen löst allerdings nichts automatisch. Halluzinationen kehren zurück, wenn das Chunking nachlässig gemacht wurde, das Retrieval irrelevante Fragmente zurückgibt, die Daten in der Datenbank veraltet sind oder der Prompt so weit gefasst ist, dass er dem Modell freien Lauf lässt. Die Technologie begrenzt das Risiko, hebt es aber nicht auf. Es zählt die Sorgfalt in jeder Stufe der Pipeline und nicht die bloße Tatsache, dass in der Architektur ein modisches Kürzel steckt.

Es gibt mehrere Mechanismen zur Eindämmung, und sie wirken am besten zusammen. Grounding erzwingt, dass sich das Modell ausschließlich auf den abgerufenen Kontext stützt. Eine präzise Anweisung im Stil von “antworte nur auf Basis der gelieferten Fragmente, und wenn es keine gibt, sage, dass du es nicht weißt” nimmt dem Modell die Erlaubnis zum Raten. Hinzu kommt: Quellenangaben bei jeder Antwort schaffen Vertrauen und ermöglichen eine Überprüfung.

Und genau das Zitieren von Quellen halte ich für eine der wirksamsten Absicherungen, die ich kenne.

• Tipp: Erzwingen Sie die Angabe des Dokumentnamens und des Fragments bei jeder Antwort. Der Nutzer kann dann mit einem Klick prüfen, woher die Information stammt, und das Modell selbst improvisiert seltener, wenn es weiß, dass es eine konkrete Quelle nennen muss.

Ein solcher Ansatz verändert die Beziehung zwischen Mensch und Assistent. Statt einem generierten Satz blind zu vertrauen, sieht die mitarbeitende Person eine Fußnote, die zum Originalparagrafen führt. Etwas passt nicht? Die Überprüfung dauert Sekunden. Ein einfacher Mechanismus, der in der Praxis jedoch die Glaubwürdigkeit der gesamten Lösung drastisch erhöht und es erleichtert, mögliche Retrieval-Fehler abzufangen, bevor sie beim Endkunden ankommen.

Die häufigsten Konstruktionsfehler und Risiken bei der Umsetzung

Fehler Nummer eins, den wir am häufigsten sehen, ist das Einwerfen roher Dokumente in das System ohne jede Vorbereitung. Scans voller Rauschen, zu einer einzigen Zeichenkette verklebte Tabellen, null Strategie für die Zerlegung in Fragmente. Das Retrieval arbeitet dann auf Chaos. Der Effekt lässt sich leicht vorhersagen: Der Chatbot liefert zufällige Bruchstücke und das Team zerbricht sich den Kopf, warum “diese ganze Künstliche Intelligenz” nicht funktioniert. Das Problem sitzt nicht im Modell. Es sitzt in der Qualität der Eingangsdaten.

Die zweite Sünde ist die fehlende Evaluation. Das Team “fühlt”, dass das System sinnvoll antwortet, statt die Treffsicherheit des Retrievals und die Groundedness zu messen, also den Grad der Verankerung der Antworten in den Quellen. Ohne Metriken lässt sich nicht sagen, ob die nächste Änderung am Chunking etwas verbessert oder verschlechtert hat. Eine produktive Umsetzung ohne Messung ist wie das Abstimmen eines Motors im Blindflug. Ein direkter Weg zu einer Regression, die niemand bemerkt, bis ein verärgerter Kunde anruft.

Ein eigenes Thema ist die Sicherheit. Firmendokumente enthalten sensible Daten, deshalb ist die Zugriffskontrolle keine Zugabe, sondern eine Anforderung. Der Chatbot muss Berechtigungen respektieren. Ein Vertriebsmitarbeiter sollte über den Assistenten nicht an Personalunterlagen gelangen. Entscheidend sind hier die Isolation der Daten einzelner Kunden sowie die Gewissheit, dass Fragmente aus der Vektordatenbank nicht an Unbefugte gelangen. Diese Schicht planen wir vom ersten Tag an und kleben sie nicht am Ende notdürftig an.

Auch die Wartungskosten darf man nicht ausblenden. Die Wissensbasis altert, daher braucht es einen Prozess zur Aktualisierung der Dokumente und zur erneuten Indexierung. Eine wachsende Zahl von Dateien erhöht die Anforderungen an die Vektordatenbank, und jede Anfrage an das Modell erzeugt Inferenzkosten. Bei starkem Traffic kann die Rechnung ordentlich überraschen, wenn sie vorher niemand kalkuliert hat.

Für uns bei Web Systems läuft die Umsetzung auf reale Architekturentscheidungen hinaus. Wir wählen die Vektordatenbank passend zur Größenordnung, wägen ein On-Premise-Modell gegen eine API ab, je nach Sensibilität der Daten und Budget, und verbinden anschließend das Ganze mit vorhandenen B2B-Systemen – CRM, ERP oder Dokumentenablagen. Diese Entscheidungen bestimmen Kosten, Sicherheit und die künftige Skalierbarkeit der Lösung. Deshalb treffen wir sie bewusst und nicht aus dem Bauch heraus.

Wie man einen glaubwürdigen RAG-Chatbot baut – praktische Hinweise

Das Fundament eines guten Systems ist die Kuratierung der Quellen. Bevor irgendetwas in die Datenbank gelangt, müssen die Dokumente bereinigt, strukturiert und unter Berücksichtigung ihres Aufbaus geparst werden. Eine Geschäftsordnung behandeln wir anders als eine Preistabelle. Erst auf so vorbereitetem Material ergeben ein durchdachtes Chunking, die Wahl eines für die polnische Sprache geeigneten Embedding-Modells sowie das Umformulieren der Nutzerfrage, damit sie besser zu den Inhalten in der Datenbank passt, einen Sinn.

Ebenso wichtig ist die Qualitätsmessung. Der Ansatz, den wir RAG Ops nennen, stützt sich auf Metriken wie Groundedness, Fluency und Treffsicherheit der Antworten. Wir messen, iterieren und verbessern die Konfiguration der Suche, die Chunking-Strategie und die Art der Fragenumformulierung. Diese datengestützte Arbeit erlaubt es, sich Schritt für Schritt zu einer hohen Generierungsqualität hochzuarbeiten, statt zu raten, ob eine Änderung überhaupt etwas gebracht hat.

Praktische Hinweise, die wir beim Bau anwenden:

• Kuratierung und Parsing – entfernen Sie das Rauschen, erhalten Sie die Struktur, passen Sie das Parsing an den Dokumenttyp an.
• Durchdachtes Chunking – stimmen Sie die Fragmentgröße auf den Charakter des Inhalts ab, testen Sie verschiedene Varianten.
• Ein gutes Embedding-Modell – wählen Sie eines, das die Sprache und die Domäne des Kunden gut versteht.
• Umformulierung der Anfrage – bereinigen und präzisieren Sie die Nutzerfrage vor der Suche.
• Messung und Iteration – behandeln Sie Metriken als Kompass und nicht als einmaligen Bericht.

Die Architektur ist das Fundament des Ganzen. Wir trennen die Schichten Ingestion, Retrieval, Generierung und Benutzeroberfläche und achten auf eine einzige Quelle der Wahrheit für die Daten sowie auf die Testbarkeit jeder einzelnen Komponente. Diese Trennung der Verantwortlichkeiten sorgt dafür, dass sich das System leichter warten, skalieren und weiterentwickeln lässt und eine Änderung in einer Schicht die übrigen nicht auf den Kopf stellt. Es sind dieselben Ingenieursprinzipien, die wir seit Jahren bei der Entwicklung von Individualsoftware, bei Webanwendungen und B2B-Systemen anwenden. Nichts Neues, sie funktionieren einfach.

Tipp: Beginnen Sie mit einem klar definierten MVP auf einem eng begrenzten Dokumentenbestand. Messen Sie die Ergebnisse an echten Fragen, bessern Sie die Schwachstellen aus und erweitern Sie erst danach den Umfang der Wissensbasis. Der Versuch, sofort alles abzudecken, endet in einem Projekt, das niemand messen oder bändigen kann.

FAQ – die häufigsten Fragen zu RAG-Chatbots auf Basis von Firmendokumenten

Beseitigt RAG Halluzinationen vollständig?

Nein, aber es dämmt sie wirksam ein, sofern Retrieval und Grounding gut entworfen wurden und regelmäßig gemessen werden. RAG verankert die Antworten in realen Dokumenten, wodurch das Modell seltener etwas erfindet. Eine vollständige Beseitigung gibt es nicht. Dafür sinkt bei sorgfältigem Chunking, treffsicherer Suche, erzwungener Quellenangabe und ständiger Evaluation das Risiko auf ein betriebswirtschaftlich akzeptables Niveau. Der Schlüssel liegt in der Ingenieursarbeit und der Wartung, nicht im bloßen Vorhandensein der Technologie.

Sind meine Daten sicher?

Das hängt von der gewählten Architektur ab, und Sicherheit lässt sich von Grund auf einplanen. Wir setzen auf eine berechtigungsbasierte Zugriffskontrolle, die Isolation der Daten einzelner Kunden sowie Mechanismen, die garantieren, dass Fragmente aus der Datenbank nicht an Unbefugte gelangen. Für sensible Anwendungsfälle sind Umsetzungen näher an der Infrastruktur des Kunden möglich, einschließlich On-Premise-Modellen, die das Versenden von Daten nach außen einschränken. Sicherheit betrachten wir als Konstruktionsanforderung, nicht als Option.

Lässt sich der Chatbot in unsere Systeme integrieren?

Ja, und gerade die Integration ist einer der Hauptgründe, warum solche Projekte überhaupt sinnvoll sind. Wir verbinden den Chatbot über eine API mit den Dokumenten, Datenbanken und B2B-Werkzeugen, die im Unternehmen bereits laufen – vom CRM über das ERP bis zu internen Dateiablagen. Dadurch antwortet der Assistent auf Basis aktueller Daten und nicht auf einer statischen Kopie von vor Monaten. Den Umfang der Integration legen wir anhand der realen Systeme und Prozesse auf Kundenseite fest.

Zusammenfassung und Kontakt

RAG ist ein Weg dafür, dass ein Chatbot seine Antworten auf reale Firmendokumente stützt, statt auf Basis des allgemeinen Modellwissens zu raten. Zuerst sucht er die passenden Fragmente, dann formuliert er eine in den Quellen verankerte Antwort. Scheinbar eine einfache Änderung der Logik. Und doch erhöht sie die Glaubwürdigkeit des Assistenten grundlegend und macht aus ihm ein Werkzeug, das sich für die Arbeit mit Verträgen, Angeboten und Prozessen eignet.

Der Erfolg einer solchen Umsetzung ruht auf mehreren Säulen: der Qualität des Retrievals, konsequentem Grounding, der Qualitätsmessung im Geiste von RAG Ops, der Datensicherheit und einer durchdachten Architektur mit getrennten Schichten. Halluzinationen beseitigt weder Magie noch ein modisches Kürzel auf einer Folie, sondern Ingenieursarbeit und solide Wartung. Ein Chatbot, der heute fehlerfrei antwortet, wird sich morgen zu irren beginnen, wenn sich niemand um die Aktualisierung der Datenbank und das Monitoring der Metriken kümmert. So funktioniert das nun einmal.

Planen Sie einen Chatbot auf Basis von Firmendokumenten, den Bau eines MVP, eine Integration über eine API oder eine breitere KI-Automatisierung in Ihren Prozessen? Sprechen wir über die Details. Wir, Web Systems, gestalten seit 2006 Web- und Mobilanwendungen, B2B-Systeme, Integrationen sowie KI-Anwendungen für Unternehmen. Gerne beraten wir Sie, wie sich eine Lösung bauen lässt, die glaubwürdig, sicher und für die Skalierung bereit ist. Nehmen Sie Kontakt mit unserem Team auf, und gemeinsam planen wir einen vernünftigen, technischen ersten Schritt.