Ich habe einen KI-Chatbot mit RAG in meiner Firma getestet – das hat mich überrascht

Als uns wieder einmal ein Kunde fragte, ob ein KI-Chatbot Fragen zur firmeneigenen Dokumentation tatsächlich zuverlässig beantwortet, sagten wir uns: genug geredet, jetzt wird geprüft. Bei Web Systems entwickeln wir Webanwendungen seit 2006. Der naheliegende Schritt? Es an uns selbst testen. An unserer internen Wissensbasis, an Projektprozeduren, an technischer Dokumentation. Drei Monate lang haben wir einen Chatbot auf Basis der RAG-Architektur auf Herz und Nieren geprüft und alles notiert – jeden Erfolg und jeden Fehlschlag. Dieser Artikel ist ein ehrlicher Bericht aus der Praxis. Ohne Schönfärberei, ohne erfundene Case Studies. Konkrete Zahlen, Probleme, die uns überrascht haben, und Schlussfolgerungen, die wir heute an Kunden weitergeben, die über eine ähnliche Einführung nachdenken.

Was RAG ist und warum wir dieses Muster statt Fine-Tuning gewählt haben

Retrieval-Augmented Generation ist eine Architektur, bei der ein Sprachmodell nicht ausschließlich aus dem Trainingsgedächtnis antwortet. Zuerst durchsucht es eine externe Wissensbasis und erst danach erzeugt es eine Antwort auf Grundlage der gefundenen Fragmente. In der Praxis? Eine Kombination aus intelligenter Suchmaschine und Textgenerator. Der Nutzer stellt eine Frage, das System findet die treffendsten Dokumente, und das LLM formuliert eine stimmige, in Fakten verankerte Antwort. Und wichtig: Das Modell muss nicht jedes Mal neu trainiert werden, wenn jemand die Dokumentation aktualisiert.

„Der Suchmechanismus in RAG ist von entscheidender Bedeutung. Sie brauchen die bestmögliche semantische Suche auf einer sorgfältig aufbereiteten Wissensbasis, damit die abgerufenen Informationen für die Anfrage relevant sind. Sind die abgerufenen Daten unpassend, kann die erzeugte Antwort zwar korrekt begründet, thematisch aber völlig verfehlt sein.” – Google / Gemini Enterprise Agent Platform

Fine-Tuning? Anfangs haben wir es erwogen, es aber schnell verworfen. Es verlangt Tausende von Frage-Antwort-Paaren, einen kostspieligen Trainingsprozess und die Wiederholung des gesamten Aufwands bei jeder Wissensaktualisierung. Bei RAG legt man einfach ein neues Dokument in die Basis – der Chatbot sieht es sofort. Für ein Software House, in dem sich Prozeduren quartalsweise ändern, war diese Flexibilität ausschlaggebend. Zudem lagen die Kosten der RAG-Einführung um ein Vielfaches unter denen eines Fine-Tunings vergleichbarer Qualität.

• Wissensbasis – eine Sammlung von Firmendokumenten in den Formaten PDF, DOCX und Markdown, bereinigt und in Fragmente zerlegt
• Embedding-Modell – wandelt Text in numerische Vektoren um und ermöglicht so die semantische Suche
• Vektordatenbank – speichert die Embeddings und bedient schnelle Ähnlichkeitsabfragen
• Großes Sprachmodell (LLM) – erzeugt Antworten auf Grundlage des abgerufenen Kontexts
• Chat-Oberfläche – die Frontend-Schicht, über die Nutzer Fragen stellen und Antworten erhalten

Diese modulare Architektur schafft viel Spielraum. Sie wollen das Sprachmodell wechseln? Die Suchmaschine muss nicht umgebaut werden. Die Wissensbasis aktualisieren? Die Oberfläche bleibt unverändert. Das Ganze lässt sich schrittweise skalieren, während die Organisation wächst.

Wie die Einführung Schritt für Schritt ablief – von Rohdokumenten zum funktionierenden Chatbot

Wir haben mit dem Sammeln und Bereinigen der Dokumentation begonnen. Rund 400 Dateien kamen zusammen – Projektprozeduren als PDF, Angebotsvorlagen als DOCX, Notizen aus Retrospektiven und Auszüge aus dem internen Wiki. Das Parsen lief leichter als angenommen. Aber Scans mit OCR? Eine Katastrophe. Polnische diakritische Zeichen wurden auf Schritt und Tritt verfälscht. Jedes Dokument musste manuell geprüft werden – ob der extrahierte Text für das Embedding-Modell überhaupt lesbar ist.

Chunking, also das Zerlegen von Dokumenten in kleinere Fragmente – hier haben wir die meisten Fehler gemacht. Und zwar vermeidbare. Zunächst haben wir den Text mechanisch alle 500 Token geschnitten und Abschnitts- und Absatzgrenzen ignoriert. Das Ergebnis? Kläglich. Die Antworten des Chatbots verbanden Stränge aus völlig unterschiedlichen Kontexten, weil ein Chunk das Ende eines Kapitels und den Anfang des nächsten enthielt. Erst als wir auf eine Aufteilung umgestiegen sind, die Überschriften und logische Inhaltsblöcke respektiert, ist die Antwortqualität deutlich gestiegen.

„Über den bloßen Ersatz einer Vektordatenbank hinaus bietet watsonx Discovery fertige NLP-Anreicherungen, darunter Entitätsextraktion, Sentimentanalyse, Emotionsanalyse, Schlüsselwortextraktion, Kategorienklassifikation und Konzept-Tagging.” – IBM, watsonx-Dokumentation

Wir haben ein Embedding-Modell gewählt, das Polnisch unterstützt, und eine Vektordatenbank, die auch bei mehreren Zehntausend Fragmenten schnell suchte. Die Suchqualität haben wir an einer Stichprobe von Fragen geprüft, noch bevor das generative Modell angeschlossen war – eine hervorragende Entscheidung. Tipp: Bevor Sie einen Chatbot produktiv nehmen, stellen Sie 50 bis 100 Testfragen mit erwarteten Antworten zusammen und prüfen Sie, ob die semantische Suche die richtigen Fragmente liefert – so lassen sich Chunking-Probleme früh erkennen, bevor Nutzer falsche Antworten melden. Uns hat dieser einfache Schritt wochenlange Nacharbeiten nach der Einführung erspart. Wirklich.

Was mich positiv überrascht hat – Treffsicherheit der Antworten und Zeitersparnis

Die Qualität der auf firmeneigener Dokumentation basierenden Antworten hat unsere Erwartungen übertroffen. Der Chatbot konnte präzise die Prozedur für den Start eines neuen Projekts nennen, die Technologien, die wir bei bestimmten Arten von Umsetzungen einsetzen, und die Stelle, an der die NDA-Vorlage liegt. Es ging aber nicht nur um inhaltliche Richtigkeit. Die Antworten klangen natürlich – nicht wie aus einem Dokument kopierte Passagen, sondern wie die Erklärung eines erfahrenen Kollegen aus dem Team.

Die größte Überraschung? Das Onboarding neuer Mitarbeiter. Statt in der ersten Woche täglich mehrere Stunden eines Seniors zu binden, konnte ein neues Teammitglied seine Fragen dem Chatbot stellen. Sofortige, kontextbezogene Antworten. Die Einarbeitungszeit in die Firmenprozeduren verkürzte sich um etwa 40 Prozent. Klar, der Chatbot hat den Mentor nicht vollständig ersetzt, aber er hat die immer wiederkehrenden Fragen übernommen. „Wo finde ich die Vorlage?” „Wie läuft der Code-Review-Prozess?” „Wem melde ich ein Infrastrukturproblem?” Solche Dinge.

Mit mehrteiligen Fragen kam das System besser zurecht als erwartet. Ein Nutzer konnte nach dem Unterschied zwischen zwei Prozeduren fragen, und der Chatbot verglich Fragmente aus getrennten Dokumenten und baute daraus eine zusammenfassende Antwort. Im ersten Monat hat er über 1.200 Anfragen bearbeitet. 78 Prozent davon erforderten keine Eskalation an einen Menschen. Der Rest betraf vor allem Themen, die in der Basis fehlten, oder Fragen, die eine geschäftliche Entscheidung verlangten – und diese Entscheidungen hat der Chatbot zu Recht nicht selbst getroffen.

Ein zusätzlicher Bonus, mit dem wir nicht gerechnet hatten – das Aufspüren von Lücken in der Dokumentation. Die Auswertung der Fragen, die der Chatbot nicht beantworten konnte, zeigte uns konkrete Lücken, die zu schließen waren. Dieser unerwartete Nebeneffekt hat die Investition in das Projekt für sich genommen schon gerechtfertigt.

Was mich negativ überrascht hat – Fallstricke, über die niemand schreibt

Die erste Enttäuschung kam schnell. Die semantische Suche lieferte mitunter Fragmente, die scheinbar zur Frage passten, im konkreten Kontext aber völlig danebenlagen. Eine Frage zum „Deployment in die Produktion” brachte Fragmente über die „Umsetzung eines Projekts” im organisatorischen, nicht im technischen Sinn. Das Modell erzeugte dann eine sprachlich korrekte Antwort, die die Absicht des Fragenden komplett verfehlte. Solche feinen semantischen Unterschiede können selbst fortgeschrittene Embedding-Modelle in die Irre führen. Frustrierend.

„Durch Feinabstimmung oder Prompt-Engineering, das auf die Texterzeugung ausschließlich anhand des abgerufenen Wissens abzielt, hilft RAG dabei, Widersprüche und Inkonsistenzen im erzeugten Text zu minimieren. Das verbessert die Qualität der erstellten Inhalte und das Nutzererlebnis erheblich.” – Google / Gemini Enterprise Agent Platform

Doch selbst mit diesem Ansatz verschwanden die Halluzinationen nicht vollständig. In etwa 5 Prozent der Fälle ignorierte das Modell den bereitgestellten Kontext und ging seinen eigenen Weg – es erzeugte Antworten aus dem Trainingswissen. Mal korrekt, mal völlig erfunden. Am schlimmsten waren Situationen, in denen der Kontext nur teilweise passte. Das Modell ergänzte fehlende Informationen durch eigene Konfabulationen und erzeugte Antworten, die glaubwürdig aussahen. Und falsch waren.

1. Dubletten in der Wissensbasis – dasselbe Dokument in verschiedenen Fassungen führte zu widersprüchlichen Antworten, weil das Modell konfliktreiche Fragmente erhielt
2. Schlecht geschnittene Fragmente – Chunks, die einen Gedanken mitten im Satz zerschneiden, erzeugten unvollständige oder verzerrte Antworten
3. Fehlende aktuelle Daten – veraltete Dokumente tauchten weiterhin in den Suchergebnissen auf und der Chatbot behandelte sie als gültig
4. Zu allgemeine Nutzeranfragen – Fragen wie „wie funktioniert das” ohne Kontext führten zu zufälligen Antworten, weil der Suche das Signal für eine präzise Zuordnung fehlte
5. Konflikte zwischen Quellen – beschrieben zwei Dokumente dieselbe Prozedur unterschiedlich, wählte das Modell zufällig aus oder vermischte beide Ansätze

Jedes dieser Probleme verlangte eine eigene Lösung. Deduplizierung der Dokumente, Versionierung der Wissensbasis, eine zusätzliche Reranking-Schicht, die die Treffer vor der Übergabe an das Modell erneut bewertete. Einen einzigen magischen Fix gibt es hier nicht.

Metriken und Evaluierung – wie wir die Qualität des RAG-Chatbots gemessen haben

Der Ansatz „einführen und schauen, was passiert” ist schon in der ersten Woche gescheitert. Ohne systematische Messungen konnten wir subjektive Eindrücke nicht von echten Verbesserungen unterscheiden. Wir sind zu einem RAG-Ops-Modell übergegangen – iterative Verbesserung auf Basis konkreter Metriken. Jede Änderung am Chunking, an den Prompts oder an der Konfiguration der Suche wurde gemessen und mit dem vorherigen Ergebnis verglichen. Mehr Aufwand? Ja. Aber es hat die Sackgassen ausgeschlossen, in die wir zuvor mit Schwung hineingelaufen sind.

Wir haben eine interne Evaluierungsplattform gebaut, die Antworten auf mehreren Achsen bewertete – Kohärenz (hält die Antwort logisch zusammen), sprachliche Flüssigkeit, Verankerung in den Quellen (hat jeder Satz Deckung im bereitgestellten Kontext) und Sicherheit (führt die Antwort nicht in die Irre). Jede dieser Metriken lieferte ein eigenes Signal darüber, was hakt. Denn Verankerung allein garantiert keine Qualität – eine Antwort kann korrekt in den Quellen verankert und dennoch unlesbar oder unstimmig sein.

Die wichtigste Metrik war der Wert „Groundedness” – der Anteil der Aussagen in einer Antwort, die unmittelbare Deckung in den bereitgestellten Fragmenten haben. Zu Beginn? 71 Prozent. Das hieß, fast jeder dritte Satz enthielt Informationen von außerhalb des Kontexts. Nicht gut. Nach drei Iterationen der Prompt-Optimierung und einem Umbau der Chunking-Strategie haben wir den Wert auf 89 Prozent gehoben. Parallel dazu verbesserte sich die Treffsicherheit der Suche um 23 Prozentpunkte – und das schlug sich in einem spürbar besseren Nutzererlebnis nieder.

Der Vergleich der Qualität vor und nach der Optimierung hat etwas gezeigt, das man sich merken sollte. Den größten Sprung brachte die Verbesserung der Quelldaten, nicht die Änderung des Modells. Besseres Parsen der Dokumente, Entfernen von Dubletten, Metadaten an den Fragmenten – das hat mehr gebracht als Experimente mit verschiedenen LLMs. Eine Lehre für alle, die eine Einführung planen: Die Qualität der Wissensbasis bestimmt die Qualität der Antworten stärker als die Wahl des Modells. Ich habe das am eigenen Leib erprobt.

FAQ – die häufigsten Fragen zu KI-Chatbots mit RAG

Was kostet die Einführung eines RAG-Chatbots in einem mittelständischen Unternehmen?

Das hängt vom Umfang der Wissensbasis und den Integrationsanforderungen ab. Ein einfaches MVP mit einigen Hundert Dokumenten und einem Kanal (Web-Chat) lässt sich mit einem Budget von 15.000 bis 40.000 PLN starten. Fortgeschrittenere Lösungen – mit CRM-Anbindung, mehrsprachiger Unterstützung und aufwendigem Reranking – liegen bei 60.000 bis 150.000 PLN. Hinzu kommen laufende Kosten: Hosting der Vektordatenbank, Gebühren für die API des Sprachmodells und die fortlaufende Pflege der Wissensbasis. Insgesamt einige Hundert bis einige Tausend PLN pro Monat.

Kann ein Chatbot mit RAG die Kundenserviceabteilung ersetzen?

Er sollte es nicht. Aber er entlastet wirksam. Nach unserer Erfahrung übernimmt ein gut eingeführter RAG-Chatbot 60 bis 80 Prozent der wiederkehrenden Anfragen. Also jener, deren Antwort in der Dokumentation, in den Geschäftsbedingungen oder im FAQ steht. Komplexe Fälle, Beschwerden, die Empathie verlangen, ungewöhnliche Situationen – dafür braucht es weiterhin einen Menschen. Am besten bewährt sich ein hybrides Modell. Der Chatbot bedient die erste Linie und eskaliert schwierigere Fälle mit dem vollständigen Gesprächskontext an einen Berater.

Wie lange dauert die Einführung eines RAG-Chatbots von der Idee bis zur Produktion?

Realistisch? 4 bis 8 Wochen für ein MVP, 3 bis 4 Monate für eine vollständige Produktionslösung. Die erste Woche geht für Audit und Aufbereitung der Wissensbasis drauf. Die folgenden zwei für den Aufbau der Verarbeitungs-Pipeline, die Konfiguration der Suche und die Anbindung an das Sprachmodell. Die letzte Woche des MVP widmen wir Qualitätstests und Iteration. Und der häufigste Grund für Verzögerungen? Die unterschätzte Zeit für das Bereinigen und Strukturieren der Quelldokumentation. Unternehmen stellen regelmäßig fest, dass ihre Wissensbasis chaotischer ist, als irgendjemand vermutet hat.

Fazit nach drei Monaten – lohnt sich RAG im Unternehmen

Drei Monate Test haben uns ein deutlich differenzierteres Bild geliefert als die üblichen Marketingversprechen der KI-Anbieter. RAG funktioniert. Es bringt echten Nutzen. Aber unter einer Bedingung – kontinuierliche Arbeit an der Qualität der Wissensbasis. Das ist keine Lösung nach dem Muster „installieren und vergessen”. Es ist ein lebendes System, das regelmäßige Aktualisierung der Dokumente, Überwachung der Metriken und Reaktion auf neue Muster in den Nutzeranfragen verlangt.

Die größte Lehre? Der Erfolg einer RAG-Einführung hängt zu 70 Prozent von der Qualität der Eingangsdaten ab und nur zu 30 Prozent von der Technologie. Unternehmen mit geordneter Dokumentation, klaren Prozeduren und einer stimmigen Wissensbasis erreichen schnell gute Ergebnisse. Organisationen mit verstreuten, veralteten oder widersprüchlichen Quellen müssen zuerst in das Aufräumen ihrer Inhalte investieren. Das Paradoxe daran: Schon der Prozess der Datenaufbereitung für den Chatbot erzwingt Informationshygiene. Und die zahlt sich unabhängig von KI aus.

RAG bewährt sich am besten dort, wo es viele wiederkehrende Fragen mit Antworten gibt, die in der Dokumentation verborgen liegen – Kundenservice, Onboarding von Mitarbeitern, technischer Support, Produktwissensdatenbanken. Wenn Ihre Anfragen aber vor allem kreativ sind, Entscheidungen verlangen oder Daten außerhalb der Dokumentation betreffen? Dann kann eine einfachere Lösung – ein gut organisiertes FAQ oder ein Ticketsystem – ausreichen. Und im Unterhalt günstiger sein.

Wenn Sie über die Einführung eines KI-Chatbots in Ihrem Unternehmen nachdenken, über die Anbindung von RAG an bestehende Systeme, oder mit einem MVP starten möchten, das das Potenzial dieser Technologie in Ihrem geschäftlichen Umfeld prüft – melden Sie sich bei uns bei Web Systems. Wir teilen unsere Erfahrung gern und helfen Ihnen, die Fehler zu vermeiden, die wir selbst am Anfang gemacht haben.