Wir setzen seit Jahren Chatbots um, und in fast jedem Projekt kehrt derselbe Moment wieder. Ein Bot, der die Begrüßung des Kunden und einige Standardfragen hervorragend bewältigt hat, beginnt plötzlich, in selbstsicherem Ton Dinge zu beantworten, die er gar nicht kennt. Der Kunde fragt nach der Garantie für ein bestimmtes Modell, und der Bot erfindet Bedingungen, die es im Angebot nie gab. Das ist kein Zufallsfehler. Das ist eine Folge der Architektur. Einen KI-Chatbot für Unternehmen baut man auf zwei Arten, und man muss sie unterscheiden, bevor überhaupt das Gespräch über Budget und Umfang beginnt.
Spis treści
Einfacher Chatbot gegen den realen Bedarf des Unternehmens
Ein klassischer regelbasierter Bot arbeitet auf einem starren Entscheidungsbaum. Der Designer definiert Fragen, Schaltflächen und Pfade im Voraus, und das System ordnet die Äußerung des Nutzers lediglich dem nächstliegenden Szenario zu. Berechenbar, günstig im Betrieb – und es fällt bei der ersten Frage außerhalb des Schemas auseinander. Es reicht, dass ein Kunde seinen Gedanken in eigenen Worten formuliert, und der Bot verweist ihn an einen Berater oder bittet um eine Umformulierung.
Die zweite Variante ist ein Bot, der ausschließlich auf einem Sprachmodell beruht, ohne Zugriff auf Unternehmensdaten. Er klingt natürlich, führt ein freies Gespräch, wirkt intelligent. Doch sein Wissen stammt aus dem Training des Modells und nicht aus Ihrer Preisliste, Ihrer Dokumentation oder Ihren Abläufen. Das Modell weiß nicht, was eine konkrete Leistung kostet oder welche Lieferzeiten aktuell gelten. Wenn also jemand danach fragt, erzeugt es eine statistisch wahrscheinliche Antwort. So entstehen Halluzinationen, die für den Kunden genauso aussehen wie echte Informationen.
Das typische Szenario, mit dem Unternehmen zu uns kommen, kommt uns bekannt vor. Jemand hat schnell einen Bot aufgesetzt, ein Sprachmodell angebunden, ein paar Absätze über das Unternehmen in den Prompt kopiert und das Ganze in den Produktivbetrieb geschickt. In den ersten Wochen passt alles, weil die Fragen einfach sind. Dann kommen die Reklamationen. Der Bot hat einem Kunden einen Rabatt versprochen, den es nicht gibt, eine nicht existierende Telefonnummer genannt oder eine Produktfunktion beschrieben, die nie gebaut wurde. Das Serviceteam löscht Brände, und das Vertrauen in das Werkzeug sinkt.
Die Grenze eines einfachen Bots ist hart und ergibt sich direkt aus einem Punkt: Er hat keinen Zugang zum lebendigen Wissen der Organisation. Er kennt keine Produktdetails, liest keine Preisliste, greift weder auf technische Dokumentation noch auf interne Abläufe zu. Man kann versuchen, diese Informationen in den Prompt zu stopfen, nur skaliert das miserabel. Je mehr Daten, desto länger und teurer der Prompt, und das Modell verliert die Details trotzdem. Und genau hier beginnt das Gespräch über eine ernsthaftere Architektur, denn der reale Bedarf eines Unternehmens geht meist weit über das Beantworten von Begrüßungen hinaus.
Woran Sie erkennen, dass ein einfacher Bot nicht mehr ausreicht
Aus Sicht des Umsetzers gibt es einige Signale, die fast immer bedeuten, dass ein Unternehmen den Möglichkeiten eines einfachen Bots entwachsen ist. Das erste und teuerste sind Halluzinationen, also Antworten, die glaubwürdig klingen, aber nicht der Realität entsprechen. Das zweite sind veraltete Inhalte. Der Bot wiederholt Daten von vor einem halben Jahr, weil niemand das im Prompt vergrabene Wissen schnell aktualisieren kann. Das dritte ist das Fehlen von Quellen. Der Kunde weiß nicht, woher die Antwort stammt, und Sie können sie im Nachhinein nicht überprüfen.
Ein weiteres deutliches Symptom sind häufige Eskalationen an Berater. Wenn der Bot bei den meisten inhaltlichen Fragen an einen Menschen weiterleitet, schmilzt sein geschäftlicher Wert dahin, weil er das Team nicht entlastet. Und das Problem verschärft sich mit dem Wachstum der Wissensbasis. Hat ein Unternehmen Dutzende Produkte, Geschäftsbedingungen, Dokumentation und Abläufe, die sich wöchentlich ändern, ist es nicht mehr machbar, all das in statischen Prompts zu pflegen. Jede Änderung erfordert manuelle Bearbeitung und Tests, und das Fehlerrisiko steigt.
Um die Diagnose zu erleichtern, haben wir die konkreten Symptome zusammengetragen, die wir bei Kunden am häufigsten beobachten, wenn sie einen Wechsel zu RAG erwägen:
- Erfundene Antworten auf Fragen nach Preisen, Parametern oder Verfügbarkeit, die in den Daten nicht enthalten sind.
- Abweichungen zwischen dem, was der Bot sagt, und dem, was auf der Website oder in der Dokumentation steht.
- Keine Möglichkeit, die Quelle einer Antwort zu benennen, was Audits und die Abwehr von Reklamationen erschwert.
- Lawinenartiges Wachstum der Promptlänge bei jedem Versuch, neues Wissen zu ergänzen.
- Ein hoher Anteil an Weiterleitungen an Berater trotz funktionierendem Bot.
- Schwierigkeiten bei der Aktualisierung von Inhalten nach jeder Änderung des Angebots oder eines Ablaufs.
Wenn Sie bei sich auch nur drei dieser Symptome wiedererkennen, geht es wahrscheinlich nicht mehr um einen besseren Prompt oder die Wahl eines besseren Modells. Das ist ein Signal, dass der Bot einen dauerhaften, kontrollierten Zugriff auf das aktuelle Wissen des Unternehmens braucht. Anders gesagt: Er braucht einen Mechanismus, der im Moment der Frage die richtigen Informationen abruft, statt auf Basis dessen zu raten, was das Modell irgendwann einmal gelernt hat. Dieser Mechanismus ist RAG. Dazu kommen wir im nächsten Abschnitt.
Was RAG ist und warum es diese Probleme löst
RAG, also abrufgestützte Generierung, verbindet zwei Elemente zu einem stimmigen Prozess. Zuerst sucht das System in der Wissensbasis die Textstellen, die der Frage des Nutzers inhaltlich am nächsten kommen, und übergibt sie anschließend dem Sprachmodell als Kontext für die Formulierung der Antwort. Dadurch antwortet das Modell nicht aus dem Trainingsgedächtnis, sondern auf Grundlage aktueller, eigener Daten Ihres Unternehmens. Eine konzeptionell einfache Änderung mit enormen praktischen Folgen, denn sie verschiebt die Quelle der Wahrheit vom Modell in eine vom Unternehmen kontrollierte Datenbasis.
Das Herzstück der gesamten Lösung ist der Retrieval-Mechanismus, also die Suche. Sie entscheidet über die Treffsicherheit der Antworten. Nötig ist hier die bestmögliche semantische Suche auf einer sorgfältig aufbereiteten Wissensbasis, damit die abgerufenen Informationen tatsächlich der Absicht der Frage entsprechen. Der Zusammenhang ist gnadenlos. Liefert die Suche unpassende Fragmente, beruht die Antwort zwar auf Daten, geht aber trotzdem am Thema vorbei oder ist schlicht falsch. Deshalb widmen wir in unseren Projekten dem Retrieval mindestens so viel Aufmerksamkeit wie dem generierenden Modell selbst.
Der zweite große Vorteil betrifft die Eindämmung von Widersprüchen und Halluzinationen. Wenn das Modell so konfiguriert ist, über passende Prompts oder Feinabstimmung, dass es Inhalte ausschließlich auf Basis des abgerufenen Wissens erzeugt, verschwindet der Raum fürs Erfinden. Der Bot denkt sich keine Preise mehr aus, weil er die Preisliste im Kontext bekommt. Er verspricht keine nicht existierenden Funktionen mehr, weil er mit der tatsächlichen Dokumentation arbeitet. Weniger Inkonsistenz schlägt sich direkt in der Antwortqualität nieder und im Komfort des Kunden, der dem Werkzeug zu vertrauen beginnt.
Und man muss auch sagen, was RAG nicht ist. Es ist kein Zauberspruch, der schlechte Daten repariert. Ist die Wissensbasis chaotisch, widersprüchlich oder unvollständig, spiegelt der Bot dieses Durcheinander getreu wider. RAG wirkt wie ein Spiegel. Es zeigt genau das, was wir ihm geben. Deshalb beginnt eine gut umgesetzte Lösung nicht beim Modell, sondern bei der Frage, welche Daten das Unternehmen besitzt, in welchem Zustand und wie man sie ordnet. Und das führt uns zu den architektonischen Entscheidungen, die über Erfolg oder Scheitern des Projekts bestimmen.
Architektonische Entscheidungen bei der RAG-Umsetzung
Die erste Entscheidung ist die Wahl der Vektordatenbank, also des Ortes, an dem wir die semantischen Repräsentationen der Dokumente speichern und in dem wir suchen. Der Markt bietet davon reichlich, von leichtgewichtigen Bibliotheken bis zu ausgebauten Engines mit zusätzlichen Anreicherungen wie Entitätserkennung, Kategorienklassifikation oder Sentimentanalyse. Die Wahl hängt von der Größenordnung ab, von den Anforderungen an die Latenz und davon, ob die Daten die Infrastruktur des Unternehmens verlassen dürfen. Für die einen Kunden ist eine Cloud-Lösung sinnvoll, für die anderen ausschließlich eine On-Premise-Installation.
Die zweite Entscheidung betrifft die Chunking-Strategie, also die Art, wie Dokumente in Fragmente zerlegt werden. Zu große Fragmente verwässern die Treffsicherheit der Suche und treiben die Kosten. Zu kleine verlieren den Kontext und führen zu abgerissenen Antworten. Damit verbunden sind das Parsen und die Qualität der Quelldaten. Ein eingescanntes PDF, eine Preistabelle als Bild oder Geschäftsbedingungen mit unleserlichem Layout sind die klassischen Fallen. Liest der Parser die Struktur falsch aus, arbeitet die gesamte weitere Pipeline mit verzerrten Daten.
Der dritte Bereich ist das Gedächtnis für den Gesprächskontext. Ein guter RAG-Chatbot muss Bezüge auf frühere Fragen verstehen. Fragt ein Kunde zuerst nach einem bestimmten Produkt und wirft dann ein kurzes was kostet das ein, sollte das System wissen, dass sich das auf den zuvor besprochenen Gegenstand bezieht. Ohne Kontextverarbeitung wird das Gespräch steif und frustrierend, und der Nutzer muss vollständige Fragen wiederholen. Dieses Element wird bei überhasteten Umsetzungen oft ausgelassen. Dabei entscheidet es über die Natürlichkeit des Erlebnisses.
Tipp: Bevor Sie irgendetwas vektorisieren, lohnt sich eine Datenkur. Aus unserer Erfahrung ist das die Phase, die die Endqualität bei geringstem Aufwand am stärksten hebt. In der Praxis bedeutet das einige konkrete Schritte:
- Entfernen veralteter und widersprüchlicher Inhalte, damit der Bot nicht zwei einander ausschließende Versionen der Wahrheit abruft.
- Vereinheitlichen der Dokumentformate und Rückgewinnung der Struktur aus schwer zu parsenden Dateien.
- Kennzeichnen von Quellen und Aktualisierungsdaten, was später Audit und Wartung erleichtert.
- Ein erster Test mit einigen Dutzend echten Kundenfragen auf der rohen Wissensbasis.
Diese Entscheidungen fallen am Anfang des Projekts, und ihre Folgen ziehen sich durch den gesamten Lebenszyklus des Systems. Deshalb behandeln wir die Phase des Architekturentwurfs als Investition, nicht als Formalität. Besser Zeit in die Ordnung der Daten und die Auswahl der richtigen Komponenten stecken, als später Halluzinationen zu flicken, die aus einem schlechten Fundament stammen.
Sicherheit, Integrationen und Betrieb des Systems
Sicherheit ist bei einem RAG-Chatbot keine Zugabe. Sie ist die Bedingung dafür, die Lösung überhaupt in den Produktivbetrieb zu lassen. Am wichtigsten ist die Zugriffskontrolle auf sensible Daten. Ein Bot, der interne Dokumente in seiner Wissensbasis hat, darf sie einem beliebigen Nutzer nicht offenlegen. Deshalb entwerfen wir eine Trennung der Berechtigungen, bei der der Umfang des abgerufenen Wissens von der Rolle des Fragenden abhängt. Ein Kunde sieht einen anderen Satz Dokumente als ein Mitarbeiter im Kundenservice und dieser wiederum einen anderen als ein Administrator. Das verhindert Datenabflüsse und ordnet die Verantwortung.
Ebenso wichtig ist das Audit der Antworten. Da der Bot Inhalte auf Basis abgerufener Fragmente erzeugt, lohnt es sich zu protokollieren, welche Fragmente in den Kontext gelangt sind und welche Antwort daraus entstand. So lässt sich nach einer Reklamation genau rekonstruieren, woher eine Aussage stammt, und feststellen, ob das Retrieval, die Daten oder das Modell versagt haben. Ohne Quellenprotokollierung agiert das Unternehmen im Blindflug, und jede Kundenbeschwerde wird zur Ermittlung ohne Beweise.
Die zweite Säule sind Integrationen. Ein Chatbot lebt selten im luftleeren Raum. Meist muss er über eine API mit CRM, ERP, einem Dokumentationssystem oder einer Produktdatenbank sprechen. Gut entworfene Integrationen erlauben dem Bot nicht nur zu antworten, sondern auch Aktionen auszuführen: den Status einer Bestellung prüfen, die Verfügbarkeit einer Ware nennen, ein Ticket anlegen. Hier hilft Erfahrung in der Entwicklung von Individualsoftware und im Verbinden bestehender Systeme, denn reale Unternehmensumgebungen sind meist ein Mosaik aus Werkzeugen verschiedener Epochen, die man stabil und fehlerresistent zusammenführen muss.
Der dritte, am häufigsten unterschätzte Bereich ist der Betrieb. RAG ist kein Projekt, das man einmal umsetzt und dann vergisst. Die Wissensbasis braucht regelmäßige Aktualisierung, weil sich Angebot und Abläufe ändern. Die Antwortqualität muss überwacht werden, damit ein Rückgang der Treffsicherheit nach dem Hinzufügen neuer Dokumente rechtzeitig auffällt. Wir achten auch auf die Kosten, denn jede Anfrage an das Modell und jeder Suchvorgang haben ihren Preis, und bei hohem Verkehr kann die Rechnung überraschen.
Tipp: Schon in der Entwurfsphase lohnt es sich, auf Unternehmensseite einen Verantwortlichen für die Wissensbasis zu bestimmen. Das technisch beste System verfällt binnen weniger Monate, wenn niemand für die Aktualität der Inhalte zuständig ist. Eine Person oder ein Team für Aktualisierungen und Qualitätsprüfungen zu benennen ist günstiger, als später die Glaubwürdigkeit des Bots zu retten, wenn er Kunden veraltete Informationen nennt.
Wie man die Antwortqualität eines RAG-Chatbots misst
Ohne Messung lässt sich nichts verbessern. Deshalb behandeln wir die Qualität eines RAG-Chatbots als messbare Größe und nicht als Frage des Eindrucks. Die Basismetrik ist Groundedness, also der Grad, in dem eine Antwort tatsächlich auf den abgerufenen Daten beruht und nicht auf der Fantasie des Modells. Hohe Groundedness bedeutet, dass der Bot das sagt, was aus den Quellen folgt. Daneben verfolgen wir die Treffsicherheit, also ob die abgerufenen Fragmente die Frage wirklich beantwortet haben, sowie Kohärenz und Sicherheit, die vor in sich widersprüchlichen oder unzulässigen Antworten schützen.
Moderne Evaluationsplattformen können generierten Text und abgerufene Fragmente automatisch nach Dimensionen wie Kohärenz, Flüssigkeit, Verankerung in den Daten, Sicherheit oder Qualität der Fragebeantwortung bewerten. Ein Teil der Metriken vergleicht die Antwort mit einer zuvor erstellten Musterantwort, was einen harten Bezugspunkt liefert. Eine solche Evaluation zu etablieren liefert ein Ausgangsniveau der Qualität, von dem aus man sich nach oben abstoßen kann. So wird aus einem subjektiven funktioniert gut eine konkrete Zahl, die sich über die Zeit verfolgen lässt.
Der Ansatz ist iterativ und datenbasiert. Wir messen, finden die Schwachstellen und optimieren konkrete Elemente: die Konfiguration der Suche, die Kuratierung der Quelldaten, die Art, wie das Layout der Dokumente geparst wird, die Chunking-Strategie oder die Präzisierung der Frage vor der Suche. Dieser Ansatz, manchmal RAG Ops genannt, besteht darin, sich Schritt für Schritt zu hoher Qualität hochzuarbeiten, statt einen einmaligen großen Umbau zu machen. Jede Änderung wird an Metriken überprüft, man sieht also, ob sie tatsächlich geholfen hat.
Was kostet die Umsetzung eines RAG-Chatbots für ein Unternehmen?
Die Kosten hängen vor allem vom Zustand der Daten, der Zahl der Integrationen und dem geforderten Sicherheitsniveau ab. Eine geordnete, kleine Wissensbasis mit einer Integration ist ein deutlich günstigeres Projekt als eine Umsetzung mit Berechtigungstrennung, Audit und Anbindung an mehrere Systeme. Deshalb beginnen wir mit einem Gespräch über Daten und Ziele und stützen das Angebot auf den realen Umfang statt auf eine starre Preisliste.
Wie lange dauert die Umsetzung?
Eine MVP-Version, die die Kernfragen auf einem geordneten Wissensausschnitt bedient, lässt sich meist in wenigen Wochen starten. Eine vollständige Einführung mit Integrationen, Zugriffskontrolle und Qualitätsmonitoring braucht mehr Zeit. Wir empfehlen bewusst den Start mit einem MVP, weil sich der Nutzen so schnell an echtem Verkehr überprüfen lässt, bevor wir in die volle Größenordnung investieren.
Was sind die größten Risiken eines RAG-Projekts?
Das häufigste Risiko ist eine schlechte Qualität der Quelldaten, die die Treffsicherheit unabhängig von der Technologie untergräbt. Das zweite ist das Fehlen eines Verantwortlichen für die Wissensbasis, wodurch das System schnell veraltet. Das dritte sind unkontrollierte Kosten bei hohem Verkehr. Alle drei lassen sich durch guten Entwurf und Monitoring ab dem ersten Tag begrenzen.
Fazit: wann ein einfacher Bot und wann RAG
Die Wahl zwischen einem einfachen Bot und RAG ist keine Modefrage, sondern eine Frage der Passung von Werkzeug und Problem. Ein einfacher regelbasierter Bot reicht völlig aus, wenn der Fragenbereich eng und vorhersehbar ist, sich das Wissen selten ändert und das Ziel vor allem Navigation und die Bedienung einiger typischer Szenarien ist. In solchen Fällen wäre eine ausgebaute Lösung ein Überbau ohne Nutzen und ein unnötiger Kostenfaktor. Nicht jedes Unternehmen braucht ein fortgeschrittenes System, und das sagen wir Kunden ehrlich.
RAG wird dann unverzichtbar, wenn der Bot inhaltlich auf Fragen zu Produkten, Preisen, Dokumentation und Abläufen antworten soll, wenn die Wissensbasis groß ist und sich häufig ändert und wenn Halluzinationen oder veraltete Antworten real Geld kosten. Wenn Reklamationen wegen erfundener Informationen auftauchen, die Eskalationen an Berater zunehmen und die Pflege des Wissens in Prompts nicht mehr machbar ist, dann ist das ein Zeichen, dass Sie reif für eine ernsthaftere Architektur sind. Das ist eine natürliche Entwicklungsstufe und kein Scheitern der früheren Lösung.
Als Web Systems, ein seit 2006 tätiger software house aus Łódź, gehen wir das aus der Sicht eines Umsetzers an, der die realen Probleme in Projekt, Integration und Betrieb kennt. Wir entwerfen Web- und Mobilanwendungen, B2B-Systeme, API-Integrationen, Automatisierungen, E-Commerce sowie Lösungen auf Basis Künstlicher Intelligenz (KI). In RAG-Projekten beginnen wir bei den Daten und den Geschäftszielen, achten auf Sicherheit und messbare Qualität und behandeln das System als Produkt, das gepflegt werden muss, nicht als einmalige Einführung. So dient die Lösung jahrelang und nicht nur bis zur ersten größeren Änderung im Angebot.
Wenn Sie sich fragen, ob in Ihrem Fall ein einfacher Bot genügt oder ob RAG nötig ist, helfen wir Ihnen gern unverbindlich bei der Einschätzung. Sprechen wir über ein MVP, die Integration mit Ihren Systemen, eine KI-Einführung, Automatisierung oder die Modernisierung einer bestehenden Lösung – schreiben Sie uns, und wir stimmen gemeinsam einen Umfang ab, der zu Ihrem realen Bedarf und Budget passt.
