KI-Chatbot Wissensbasis: Welche Inhalte hineingehören und wie sie aktuell bleiben

Eine Kundin fragt am Freitagabend, ob der Betrieb samstags geöffnet hat. Im Team gibt es dazu drei Auskünfte: Die Website nennt „Mo bis Fr“, ein Aushang in der Tür verspricht „Sa nach Vereinbarung“, und die Kollegin am Empfang weiß, dass im Sommer samstags ohnehin zu ist. Alle drei halten ihre Antwort für richtig. Dieses Szenario ist erfunden, das Muster ist es nicht.

Genau hier setzt ein KI-Chatbot an, und genau hier entscheidet sich, ob er hilft oder schadet. Ein Sprachmodell kennt Ihren Betrieb nicht. Es kennt Sprache, allgemeine Zusammenhänge und plausible Formulierungen. Gibt man ihm nichts anderes, antwortet es mit dem, was in solchen Fällen üblicherweise gilt. Das klingt überzeugend und kann trotzdem falsch sein.

Die Wissensbasis ist deshalb keine Zusatzfunktion, sondern das Fundament. Sie legt fest, was der Bot im Namen Ihres Betriebs sagen darf. Wer sie vernachlässigt, bekommt eine höfliche Maschine mit erfundenem Wissen. Wer sie sorgfältig aufbaut, bekommt einen Assistenten, der nur das weitergibt, was Sie ausdrücklich freigegeben haben, und der die Stelle nennt, an der es steht.

Dieser Text richtet sich an Betriebe, die vor genau dieser Entscheidung stehen: Soll ein Assistent im Namen des Hauses Auskunft geben, und wenn ja, auf welcher Grundlage? Er erklärt, wie wir eine Wissensbasis aufbauen würden, welche Abwägungen dabei anfallen und wo die Grenzen liegen. Die Beispiele sind konstruiert, damit nichts nach einem realen Projekt aussieht, das es nicht gegeben hat.

Das Kernproblem heißt Halluzination: Das Modell erzeugt Text, der zur Frage passt, ohne dass er durch eine Quelle gedeckt wäre. Der Mechanismus ist banal. Ein Sprachmodell berechnet, welches Wort wahrscheinlich folgt. Wahrscheinlich ist nicht dasselbe wie wahr. Für „Was kostet eine Erstberatung?“ gibt es unzählige plausible Antworten, und das Modell wählt eine, wenn es keine konkrete Angabe vorliegen hat.

Dazu kommt das Alterungsproblem. Selbst eine anfangs korrekte Wissensbasis veraltet. Preise ändern sich, ein Mitarbeiter geht, ein Angebot läuft aus, die Praxis schließt zwischen den Jahren. Ein Bot, der den Stand vom Frühjahr wiedergibt, wirkt im Herbst genauso sicher wie am ersten Tag. Der Kunde kann den Unterschied nicht erkennen, und der Betrieb merkt es oft erst, wenn jemand vor verschlossener Tür steht.

Ein drittes Fehlerbild betrifft die Zusagen. Fragt jemand „Kann ich bei Ihnen stornieren?“, geht es nicht um Auskunft, sondern um eine verbindliche Aussage. Antwortet der Bot frei, formuliert er womöglich eine Regel, die es nicht gibt. Deshalb braucht eine Wissensbasis nicht nur Inhalte, sondern auch Grenzen: Welche Themen beantwortet der Bot, und bei welchen übergibt er an einen Menschen?

Bevor irgendetwas technisch gebaut wird, lohnt eine Bestandsaufnahme der Fragen, die Kunden tatsächlich stellen. Die besten Quellen dafür sind der Posteingang, die Notizen vom Telefon, die Suchanfragen auf der Website und die Frage, was das Team zum fünften Mal in einer Woche beantwortet. Aus diesen Fragen ergibt sich, welche Inhalte die Wissensbasis tragen müssen. Nicht jede Information, die im Betrieb existiert, gehört hinein.

Wir würden Inhalte nach zwei Kriterien sortieren: Wie oft wird danach gefragt, und wie teuer ist eine falsche Antwort? Öffnungszeiten werden oft gefragt, und ein Fehler ärgert, richtet aber meist wenig Schaden an. Preisrahmen werden häufig gefragt, ein Fehler erzeugt Erwartungen, die später korrigiert werden müssen. Vertragliche Details werden seltener gefragt, ein Fehler kann aber ernste Folgen haben. Daraus folgt, wie streng die Freigabe sein muss.

Eine Gegenprobe ist ebenso aufschlussreich: Was soll der Bot ausdrücklich nicht beantworten? Individuelle Rechts- oder Gesundheitsfragen, verbindliche Preise für Sonderfälle, Auskünfte über andere Kunden. Diese Grenze ist Teil der Konzeption und gehört schriftlich festgehalten, bevor die erste Zeile Inhalt eingepflegt wird. Sie entscheidet später darüber, ob der Bot in kritischen Momenten sauber übergibt.

Zur Bestandsaufnahme gehört auch ein Blick auf die Form der Quellen. Eine Preisliste als eingescannte Grafik kann der Bot nicht lesen, eine Tabelle mit verbundenen Zellen wird beim Einlesen leicht zerrissen, und ein Foto vom Aushang taugt nur als Erinnerung. Solche Quellen werden vorab in schlichten Text überführt, und genau dabei fallen Unstimmigkeiten auf, die vorher niemand bemerkt hat.

Es gibt grundsätzlich drei Wege, einem Modell Betriebswissen mitzugeben. Der erste ist, alles in die Anweisung zu schreiben, die jeder Anfrage vorangestellt wird. Das funktioniert bei einer Handvoll Absätze und scheitert, sobald der Bestand wächst: Die Anweisung wird unübersichtlich, teuer in jeder Anfrage, und das Modell gewichtet lange Texte nicht zuverlässig. Für einen Betrieb mit zehn Seiten Wissen kann das genügen, mehr sollte man darauf nicht bauen.

Der zweite Weg ist, das Modell nachzutrainieren. Das klingt gründlich, passt aber schlecht zu Betriebswissen. Das Gelernte lässt sich schwer korrigieren, wenn sich ein Preis ändert, und es lässt sich nicht belegen, woher eine Aussage stammt. Nachtraining eignet sich eher für Tonfall und Format als für Fakten, die sich laufend ändern. Für Öffnungszeiten ist es der falsche Hebel.

Der dritte Weg heißt Retrieval, in der Fachsprache Retrieval-Augmented Generation. Der Bot sucht bei jeder Frage zuerst in Ihren eigenen Inhalten, reicht die gefundenen Absätze dem Modell und lässt es nur daraus antworten. Ändert sich ein Preis, ändern Sie ein Dokument, und die nächste Antwort stimmt. Zudem ist jede Aussage auf eine Fundstelle zurückführbar. Das ist unsere Wahl, weil sie Aktualität, Nachvollziehbarkeit und Kontrolle verbindet.

Retrieval ist kein Allheilmittel. Findet die Suche die falsche Stelle, antwortet das Modell zuverlässig aus der falschen Stelle. Die Qualität liegt also in zwei Hälften: in der Suche und in der Anweisung, nur aus Fundstellen zu antworten. Beide Hälften müssen getestet werden, und das ist keine einmalige Aufgabe.

Eine Wissensbasis ist kein Datenablagekorb. Wer einfach alle PDFs, Broschüren und Website-Texte hineinlädt, erhält widersprüchliche Fundstellen und einen Bot, der mal die alte, mal die neue Preisliste zitiert. Besser ist ein kleiner, bewusst gebauter Bestand: eine Seite je Thema, kurz, eindeutig, mit Datum und einer Person, die dafür zuständig ist. Lieber vierzig gepflegte Einträge als vierhundert unklare.

Der Schreibstil ist dabei wichtiger, als man vermutet. Die Suche arbeitet mit Bedeutungsähnlichkeit, deshalb helfen Einträge, die so formuliert sind, wie Kunden fragen. Ein Eintrag mit dem Titel „Stornierung von Terminen“ und dem ersten Satz „Termine können bis 24 Stunden vorher kostenfrei abgesagt werden“ wird besser gefunden als ein Absatz aus den AGB, der dasselbe in Paragraphensprache sagt. Auszüge aus den AGB bleiben als Beleg erhalten, die verständliche Fassung steht daneben.

Jeder Eintrag trägt Metadaten: Thema, Gültigkeit, Stand, Ansprechperson, Sichtbarkeit. Der Hinweis „gültig bis“ erlaubt, Saisonales automatisch auszublenden. Die Sichtbarkeit trennt, was der Bot öffentlich sagen darf, von internen Hinweisen für das Team. Und die Preisangabe steht als Rahmen mit Bedingungen, nicht als Zahl ohne Kontext, damit aus „ab“ nicht versehentlich „genau“ wird.

Zuletzt gehört in die Wissensbasis, was der Bot nicht weiß. Ein Eintrag „Individuelle Preisangebote“ mit dem Inhalt „Dazu gibt der Bot keine Auskunft, sondern vermittelt an das Team“ ist wertvoller als Schweigen. Er macht die Grenze auffindbar und sorgt dafür, dass bei verwandten Fragen die richtige Reaktion gewählt wird.

Widersprüche lösen wir vor dem Einpflegen, nicht danach. Nennt die Website andere Zeiten als die Preisliste, entscheidet eine Person, welche Fassung gilt, und die andere wird korrigiert. Ein Bot, der zwei Wahrheiten kennt, gibt zufällig die eine oder die andere wieder. Dieser Abgleich ist unbequem, deckt aber oft Fehler auf, die auch auf der Website seit Monaten unbemerkt stehen.

Technisch durchläuft jede Anfrage vier Schritte. Zuerst werden die Inhalte vorbereitet: Texte werden in Abschnitte von wenigen Sätzen zerlegt, und jeder Abschnitt wird in eine Zahlenreihe übersetzt, die seine Bedeutung abbildet. Diese Übersetzung, ein sogenanntes Embedding, erlaubt, Ähnlichkeit zu messen. Zwei Sätze mit verschiedenen Wörtern, aber gleichem Sinn liegen dicht beieinander, etwa „Wann haben Sie auf?“ und „Öffnungszeiten“.

Kommt eine Frage, wird sie auf dieselbe Weise übersetzt, und die Suche liefert die ähnlichsten Abschnitte. In der Praxis kombinieren wir die Bedeutungssuche mit einer klassischen Stichwortsuche, weil sie bei Eigennamen, Artikelnummern und Fachbegriffen zuverlässiger ist. Die besten Treffer werden sortiert, und nur Treffer oberhalb einer Mindestähnlichkeit werden weitergereicht. Diese Schwelle ist der wichtigste Regler für das Verhalten bei Unklarheit.

Im dritten Schritt erhält das Sprachmodell die Frage, die gefundenen Abschnitte und eine Anweisung: Antworte nur auf Grundlage dieser Abschnitte, nenne die Quelle, und wenn die Abschnitte die Frage nicht beantworten, sage das. Im vierten Schritt prüft eine Kontrolle, ob die Antwort durch die Abschnitte gedeckt ist, und blockiert Aussagen mit Preisen oder Zusagen, die dort nicht stehen. Diese Kontrollstufe kostet etwas Zeit und spart viel Ärger.

Die schwierigste Eigenschaft eines Chatbots ist nicht Wissen, sondern Zurückhaltung. Menschen verzeihen eine ehrliche Auskunft, dass der Bot etwas nicht weiß, viel eher als eine falsche, die sie später ausbaden müssen. Dennoch neigen Sprachmodelle dazu, hilfsbereit zu wirken. Dieses Verhalten muss man gezielt umlenken: durch die Anweisung, durch die Schwelle der Suche und durch Beispiele für gutes Nichtwissen.

Eine brauchbare Unwissens-Antwort besteht aus drei Teilen: Sie sagt klar, dass der Bot dazu nichts Verlässliches vorliegen hat. Sie bietet den nächsten Schritt an, etwa die Rückfrage an das Team, einen Rückruf oder die Kontaktseite. Und sie nimmt die Frage mit, sodass das Team weiß, worum es ging. Dieser dritte Teil macht aus der Lücke einen Hinweis für die Pflege: Fragen ohne Treffer sind die ehrlichste Liste dessen, was in der Wissensbasis fehlt.

Schwierig sind Grenzfälle, in denen die Suche etwas findet, das nur halb passt. Die Frage lautet „Gibt es einen Rabatt für Vereine?“, die Fundstelle spricht von Mengenrabatt. Hier darf der Bot nicht übertragen. Wir lösen das, indem die Anweisung zwischen „beantwortet“, „teilweise beantwortet“ und „nicht beantwortet“ unterscheidet und bei der mittleren Stufe das Gefundene benennt, ohne die Lücke zu schließen.

Zum Nichtwissen gehört auch das Wissen um die eigene Rolle. Fragt jemand nach einer Zusage, einer Diagnose oder einer Rechtsfrage, soll der Bot nicht raten, sondern zuständige Menschen nennen. Das ist keine Schwäche, sondern der Grund, warum Betriebe einem solchen Assistenten überhaupt ein Fenster auf ihrer Website geben können.

Eine gute Wissensbasis macht den Bot nachvollziehbar, nicht unfehlbar. Realistisch ist der Anspruch, dass die große Mehrzahl alltäglicher Fragen aus den freigegebenen Inhalten richtig beantwortet wird, dass Antworten ihre Quelle nennen und dass der Bot bei Lücken übergibt. Eine Zahl dafür lässt sich seriös erst nach einer Testphase mit echten Fragen nennen, nicht vorher und nicht pauschal.

Messen lässt sich der Nutzen an Größen, die nah an der Ursache liegen. Dazu zählen der Anteil der Fragen, die mit Quelle beantwortet wurden, der Anteil der Übergaben wegen fehlender Treffer, Stichproben, in denen eine Person Antworten gegen die Quelle prüft, und Rückmeldungen der Nutzer per Daumen. Erst danach kommen Größen wie weniger wiederholte Anfragen im Postfach oder kürzere Bearbeitungszeiten, die von vielen weiteren Faktoren abhängen.

Ein Beispiel für die Deutung: Steigt die Zahl der Übergaben wegen fehlender Treffer in den ersten Wochen, ist das kein Rückschritt, sondern der Bot zeigt, wo Inhalte fehlen. Sinkt sie danach, ohne dass die Stichproben schlechter werden, wächst die Abdeckung. Sinkt sie, während die Stichproben schlechter werden, antwortet der Bot vermutlich zu großzügig, und die Schwelle muss strenger werden.

Ebenso klar gehört dazu, was sich nicht versprechen lässt: Keine Wissensbasis garantiert fehlerfreie Antworten, besonders bei missverständlich gestellten Fragen oder widersprüchlichen Quellen. Auch eine bestimmte Entlastung des Teams lässt sich vorab nicht beziffern. Sie hängt davon ab, wie viele Anfragen Ihr Betrieb tatsächlich bekommt, wie standardisiert sie sind und wie konsequent gepflegt wird.

Der häufigste Grund, warum Chatbots nach einigen Monaten enttäuschen, ist keine Technik, sondern fehlende Zuständigkeit. Die Einführung war ein Projekt, die Pflege gehört niemandem. Deshalb legen wir von Beginn an fest, wer für welchen Bereich verantwortlich ist: Preise bei der Geschäftsführung, Öffnungszeiten am Empfang, Leistungsbeschreibungen bei der Fachkraft. Jeder Eintrag hat einen Namen und ein Prüfdatum.

Der Rhythmus besteht aus drei Stufen. Ereignisbezogen wird sofort geändert, wenn sich etwas ändert: neue Preisliste, Betriebsferien, ein Feiertag. Regelmäßig, etwa monatlich, prüft jemand die Liste der unbeantworteten Fragen und der negativen Rückmeldungen und ergänzt Einträge. Zweimal im Jahr durchläuft das Team die gesamte Wissensbasis und löscht, was nicht mehr gilt. Ablaufdaten helfen, indem Einträge mit abgelaufener Gültigkeit automatisch aus den Antworten fallen.

Wichtig ist ein einfacher Weg für Änderungen. Wenn die Anpassung eines Eintrags eine Abstimmung mit der Agentur erfordert, wird sie aufgeschoben. Wir bauen deshalb eine Oberfläche, in der berechtigte Personen Einträge bearbeiten und freigeben, und halten den Verlauf fest. Bei jeder Änderung läuft ein kleiner Satz von Testfragen mit, damit eine neue Formulierung nicht unbemerkt die Antworten auf andere Themen verschiebt.

Die Wissensbasis wird so zu einem lebendigen Dokument, das mehr nützt als der Bot allein. Viele Betriebe stellen fest, dass sie zum ersten Mal schriftlich festhalten, was bei Stornierung, Anfahrt oder Zahlung gilt. Das hilft auch neuen Mitarbeitenden und der Website. Dieser Nebeneffekt ist real, aber kein Ersatz für den Pflegeaufwand, der bleibt.

Ein KI-Chatbot lohnt sich für Betriebe, die ähnliche Fragen oft beantworten und deren Antworten sich in klaren Aussagen festhalten lassen. Seine Qualität hängt an der Wissensbasis: an wenigen, gepflegten Einträgen, an einer Suche, die zuverlässig findet, an der Quelle unter jeder Antwort und an einem Bot, der Lücken eingesteht. Das Modell dahinter ist austauschbar, die Sorgfalt davor nicht.

Der nächste Schritt ist klein und braucht noch keinen Bot. Notieren Sie die zwanzig Fragen, die Ihr Team in den letzten Wochen am häufigsten beantwortet hat, und prüfen Sie, ob die Antworten an einer einzigen, aktuellen Stelle stehen. Fehlt diese Stelle, ist das die eigentliche Aufgabe, und die lohnt sich unabhängig vom Chatbot. Wir schauen uns gern gemeinsam an, wie viel davon bereits vorhanden ist.

Ehrlich gehört auch dazu: Bei sehr kleinen Betrieben mit wenigen, stabilen Fragen reicht eine gut gebaute FAQ-Seite. Der Chatbot spielt seinen Vorteil aus, wenn Fragen vielfältig formuliert werden, wenn rund um die Uhr Antworten erwartet werden und wenn jemand die Pflege übernimmt. Fehlt das Letzte, sollten Sie den Start verschieben.

Wer startet, sollte klein beginnen: mit den fünf bis zehn wichtigsten Themen, einer begleiteten Testphase und der Bereitschaft, anhand echter Fragen nachzubessern. Die Wissensbasis wächst dann mit dem Bedarf, statt vorab Vollständigkeit zu behaupten. Das ist langsamer als ein großer Import, aber die Antworten bleiben prüfbar, und das Team behält den Überblick darüber, was der Bot im eigenen Namen sagt.