Wie wir einen KI-FAQ-Chatbot für den Kundensupport entwickelt haben

Künstliche Intelligenz ist längst keine Zukunftsvision mehr, sondern fester Bestandteil der Unternehmenspraxis. Heute zählt KI in vielen Bereichen zu den strategisch wichtigen Technologien — von der Datenanalyse bis hin zur Verbesserung der Customer Experience durch einen effizienteren Kundensupport.

Mit dem Wachstum eines Unternehmens wächst der Kundensupport jedoch nur selten im gleichen Tempo. Die Zahl der Anfragen steigt, Produktdokumentationen ändern sich laufend und Support-Teams verbringen immer mehr Zeit damit, dieselben Fragen wiederholt zu beantworten.

Eine manuell gepflegte FAQ-Seite kann zunächst Abhilfe schaffen, lässt sich mit zunehmender Komplexität jedoch immer schwerer aktuell halten. Neue Produktfunktionen führen zu neuen Fragen, bestehende Antworten veralten und relevante Informationen verteilen sich auf Dokumentationsseiten, Hilfe-Center und interne Ressourcen.

Genau vor dieser Herausforderung standen wir bei dem Projekt, das wir bei SCAND entwickelt haben: einem KI-FAQ-Chatbot für den Kundensupport, der Kundenfragen auf Grundlage der bereits vorhandenen Wissensbasis des Unternehmens beantwortet — anstatt sich auf eine manuell gepflegte Liste aus Fragen und Antworten zu stützen.

In diesem Artikel zeigen wir, wie wir an diese Aufgabe herangegangen sind, warum wir uns für eine RAG-Architektur entschieden haben, wie das System seine Wissensbasis mit der Website des Kunden synchron hält und welche Technologien wir für die Umsetzung eingesetzt haben.

Das Problem: Warum statische FAQ-Bereiche nicht mitwachsen

Klassische FAQ-Bereiche funktionieren gut, solange ein Produkt überschaubar ist und sich die zugehörige Dokumentation nur selten ändert. Schwierigkeiten entstehen, sobald Umfang und Komplexität der Informationen zunehmen. Statische FAQs bringen dann typischerweise mehrere Herausforderungen mit sich:

• Support-Teams beantworten immer wieder dieselben Fragen. Kunden erkundigen sich beispielsweise nach Preisen, Funktionen, Integrationen, Kontoeinstellungen, Problemlösungen oder Richtlinien — obwohl diese Informationen bereits dokumentiert sind.
• Die Pflege der FAQs wird zum manuellen Aufwand. Neue Fragen müssen identifiziert, Antworten formuliert, bestehende Inhalte überprüft und Aktualisierungen veröffentlicht werden.
• Informationen veralten. Eine Produktseite kann bereits aktualisiert worden sein, während eine FAQ-Antwort weiterhin auf eine frühere Funktion, einen alten Ablauf oder eine nicht mehr aktuelle Richtlinie verweist.
• Kunden formulieren ihre Fragen nicht immer so, wie sie in den FAQs stehen. Ein Kunde könnte beispielsweise fragen: „Kann ich mein Abonnement nach einem Upgrade noch ändern?“, während in der Dokumentation ganz andere Begriffe verwendet werden.
• Eine einzelne FAQ-Seite kann nicht die gesamte Wissensbasis abbilden. Relevante Informationen verteilen sich häufig auf Dokumentationen, Support-Artikel, Produktseiten und weitere Ressourcen.

Klassische FAQ-Software ist darauf ausgelegt, häufig gestellte Fragen zu verwalten und bereitzustellen. Das eigentliche Problem — relevante Informationen zuverlässig zu finden — löst sie jedoch nicht zwangsläufig.

Wir benötigten daher einen Chatbot, der eine Kundenfrage verstehen, die relevantesten Informationen in einer sich kontinuierlich verändernden Wissensbasis — also auf der laufend aktualisierten Website — finden und auf Grundlage dieses Kontexts eine passende Antwort generieren konnte. Dafür war eine technisch anspruchsvollere Chatbot-Entwicklung erforderlich.

Was ist ein RAG-basierter FAQ-Chatbot?

Ein RAG-basierter FAQ-Chatbot kombiniert eine semantische Vektorsuche mit einem Large Language Model (LLM). Dabei ruft das System zunächst relevante Informationen aus einer Wissensbasis ab und nutzt diese anschließend, um eine kontextbezogene Antwort auf die Frage des Nutzers zu generieren.

Im Unterschied zu klassischer FAQ-Software, die in der Regel auf einer vorab definierten Sammlung von Fragen und Antworten basiert, kann ein RAG-Chatbot vor der Antwort eine deutlich umfangreichere Wissensbasis durchsuchen. Als Datenquelle können dabei unterschiedlichste Dokumentformate dienen — etwa TXT-, Word-, Excel- oder PDF-Dateien.

Aus Sicht des Kunden funktioniert die Lösung wie ein FAQ-Chatbot — sie beantwortet typische Supportfragen. Technisch ist sie jedoch nicht darauf beschränkt, eine Nutzereingabe mit einer festen FAQ-Liste abzugleichen.

Für Unternehmen, die eine solche Lösung entwickeln möchten, bildet die RAG-Entwicklung die technische Grundlage, um unternehmensinterne Wissensquellen mit KI-gestützter Informationssuche und Antwortgenerierung zu verbinden.

FAQ-Chatbot vs. Wissensdatenbank-Chatbot

Die Begriffe FAQ-Chatbot und Wissensdatenbank-Chatbot werden häufig synonym verwendet, stehen jedoch für etwas unterschiedliche Ansätze bei der Organisation und Bereitstellung von Informationen. Beide können den Kundensupport unterstützen — sie unterscheiden sich jedoch darin, wie sie auf Informationen zugreifen und diese nutzen.

Ein FAQ besteht in der Regel aus einer redaktionell zusammengestellten Sammlung häufig gestellter Fragen und den dazugehörigen Antworten:

Frage → vordefinierte Antwort

Eine Wissensdatenbank ist deutlich umfassender. Sie kann Produktdokumentationen, Anleitungen zur Fehlerbehebung, Richtlinien, Tutorials, Funktionsbeschreibungen sowie weitere strukturierte und unstrukturierte Informationen enthalten:

Nutzerfrage → relevantes Wissen → generierte Antwort

Bei unserem Chatbot dient die Wissensdatenbank als zentrale und maßgebliche Informationsquelle. Diese Unterscheidung ist für die Architektur entscheidend. Anstatt den Chatbot auf einer statischen FAQ-Liste aufzubauen, haben wir eine Verarbeitungspipeline entwickelt, die bestehende Inhalte von allen Seiten der offiziellen Website des Kunden erfasst, sie in durchsuchbare Repräsentationen umwandelt, relevante Kontextinformationen abruft und diesen Kontext anschließend an ein LLM übergibt.

Das Ergebnis ist ein KI-FAQ-Chatbot, der Fragen auch dann beantworten kann, wenn deren genaue Formulierung im Ausgangsmaterial nicht vorkommt. Im Gegensatz zu klassischen FAQ-Chatbots, die häufig auf vordefinierten Fragen und Antworten basieren, kann dieser Ansatz ein deutlich breiteres Spektrum an Kundenanfragen erfassen und relevantere Antworten liefern.

Ein weiterer entscheidender Vorteil: Die Wissensdatenbank muss nicht auf einem festen Stand bleiben. Änderungen auf der Website des Kunden werden erkannt und anschließend in den Vektorspeicher übernommen, sodass die Informationen des Chatbots mit den ursprünglichen Inhalten synchron bleiben. Dadurch ähnelt die Lösung zunehmend einem KI-Agenten für den Kundensupport, der kontinuierlich auf aktuelles Unternehmenswissen zugreifen und dieses für seine Antworten nutzen kann.

Dieser Ansatz steht auch in engem Zusammenhang mit unserer Arbeit an einem KI-Wissensassistenten für die Dokumentensuche, bei dem KI eingesetzt wird, um große Mengen geschäftsrelevanter Informationen einfacher durchsuchbar und zugänglich zu machen.

Unser Ansatz: Die Architektur des Chatbots

Wir haben die Lösung als RAG-basierten Chatbot entwickelt, der die bestehende Wissensbasis des Kunden mit einem LLM verbindet. Anstatt ein Modell auf einer festen Sammlung von FAQs zu trainieren, ruft das System bei jeder Kundenanfrage relevante Informationen aus der jeweils aktuellen Wissensbasis ab und nutzt diesen Kontext, um eine passende Antwort zu generieren.

Die Architektur umfasst fünf zentrale Schritte — das Erkennen neuer Informationen, die Erfassung und Strukturierung der Ausgangsinhalte, die Vektorisierung und Suche nach relevanten Informationen, die Antwortgenerierung mithilfe eines LLM sowie die Synchronisierung der Wissensbasis mit Änderungen auf der Website des Kunden.

Aufbereitung der Wissensbasis

Im ersten Schritt erkennt das System neue Inhalte wie Artikel oder Seiten. Dazu werden Änderungen auf der WordPress-Website in regelmäßigen Abständen über eine API abgefragt. Wird eine neue Seite, ein neuer Artikel oder eine Änderung an bestehenden Inhalten erkannt, werden die betreffenden Daten an den nächsten Verarbeitungsschritt übergeben.

Im zweiten Schritt werden bestehende oder neu hinzugefügte Inhalte des Kunden in strukturierte, maschinenlesbare Daten umgewandelt. Da Wissensdatenbanken und Websites unterschiedliche Inhaltstypen enthalten können — darunter Überschriften, Absätze, Listen, Tabellen und Links — reicht es für eine zuverlässige Informationssuche nicht aus, lediglich den Rohtext zu extrahieren.

Für die Analyse und Strukturierung der Ausgangsinhalte haben wir Docling eingesetzt. Dabei bleiben sowohl die Dokumenthierarchie als auch die semantischen Zusammenhänge erhalten. Anschließend werden die aufbereiteten Inhalte in sinnvolle, dynamische und sich überlappende Abschnitte aufgeteilt, die unabhängig voneinander indexiert und bei einer Suchanfrage abgerufen werden können.

Die Verarbeitungspipeline lässt sich wie folgt zusammenfassen:

Website und Dokumentation des Kunden → Docling → strukturierte Inhalte → Dokumentabschnitte → Vektorisierung

Durch diesen Ansatz kann der Chatbot direkt mit den bereits vorhandenen Informationen des Kunden arbeiten — das Support-Team muss keine separate Datenbank mit speziell für den Chatbot erstellten Fragen und Antworten pflegen.

Vektorisierung und semantische Suche

Nachdem die Inhalte strukturiert wurden, bestand der nächste Schritt darin, sie nicht nur anhand exakter Schlüsselwörter, sondern auch anhand ihrer Bedeutung durchsuchbar zu machen.

Dazu wandelt das System die Inhalte der Wissensbasis in Vektorrepräsentationen um und speichert sie für die semantische Suche. Stellt ein Kunde eine Frage, wird auch diese Anfrage vektorisiert. Anschließend sucht das System nach den Inhalten, die der tatsächlichen Intention des Nutzers am besten entsprechen.

Ein Kunde könnte beispielsweise fragen: „Kann ich mein Abonnement ändern, bevor der aktuelle Abrechnungszeitraum endet?“

In der Wissensbasis befindet sich möglicherweise ein Artikel mit dem Titel „Abonnement verwalten“. Obwohl sich die Formulierungen unterscheiden, kann die semantische Suche den passenden Abschnitt erkennen und ihn dem Chatbot als relevanten Kontext zur Verfügung stellen.

Der Abruf relevanter Informationen folgt dabei diesem Ablauf:

Nutzerfrage → Vektorisierung der Anfrage → semantische Suche → relevante Inhalte aus der Wissensbasis → Kontext für das LLM

Diese Abrufschicht ist ein zentraler Bestandteil des KI-FAQ-Chatbots — sie ermöglicht es dem System, auch Fragen zuverlässig zu beantworten, die anders formuliert sind als die ursprünglichen Inhalte der Dokumentation.

Antwortgenerierung

Nachdem die relevantesten Informationen abgerufen wurden, übergibt das System sowohl die Kundenfrage als auch den ausgewählten Kontext an ein LLM.

Für dieses Projekt haben wir Groq und Ollama als LLM-Infrastruktur eingesetzt. Groq ermöglicht eine besonders schnelle Inferenz und sorgt damit für kurze Reaktionszeiten im Kundendialog. Ollama bietet zusätzlich die Möglichkeit, kompatible Modelle lokal oder in einer selbst gehosteten Umgebung auszuführen.

Das LLM erhält die Anweisung, seine Antwort auf die abgerufenen Informationen zu stützen, anstatt sich ausschließlich auf sein allgemeines Wissen zu verlassen. Dadurch bleiben die Antworten eng an den tatsächlichen Produkten, Richtlinien und Dokumentationen des Kunden ausgerichtet.

Vereinfacht lässt sich der Ablauf so darstellen:

Kundenfrage + abgerufener Kontext + Systemanweisungen → LLM → Antwort für den Kunden

Die Trennung von Informationsabruf und Antwortgenerierung macht die Architektur zugleich flexibel. Die zugrunde liegende Wissensbasis und die Retrieval-Pipeline können unverändert bleiben, während das eingesetzte LLM je nach Anforderungen an Leistung, Kosten, Datenschutz oder Bereitstellung ausgetauscht werden kann.

Synchronisierung der Wissensbasis

Ein wesentlicher Bestandteil unseres Ansatzes ist, dass der Chatbot nicht auf einen einmaligen Import der Kundendokumentation angewiesen ist.

Websites und Wissensdatenbanken verändern sich laufend. Neue Funktionen kommen hinzu, bestehende Anleitungen werden aktualisiert und veraltete Informationen entfernt. Werden diese Änderungen nicht in den Daten des Chatbots berücksichtigt, kann selbst ein technisch ausgereifter KI-Assistent veraltete Antworten liefern.

Um das zu vermeiden, haben wir einen Synchronisierungsprozess implementiert, der Änderungen auf der Website des Kunden über eine API erkennt und den Vektorspeicher entsprechend aktualisiert.

Vereinfacht lässt sich der Prozess so darstellen:

Änderungen auf der Website → Erkennung aktualisierter Inhalte → Inhaltsanalyse → erneute Vektorisierung → Aktualisierung des Vektorspeichers

Wird eine relevante Seite geändert, können die aktualisierten Inhalte verarbeitet und neu indexiert werden, ohne die gesamte Wissensbasis von Grund auf neu aufbauen zu müssen.

Für einen FAQ-Chatbot im Kundensupport ist diese Synchronisierung besonders wichtig — die Qualität der Antworten hängt unmittelbar davon ab, wie aktuell die zugrunde liegende Dokumentation ist. Dadurch fungiert der Chatbot als dialogorientierte Schnittstelle zu einer dynamischen Wissensbasis und nicht als statische Sammlung vordefinierter FAQ-Antworten.

Unser Technologie-Stack

Für die Entwicklung eines KI-FAQ-Chatbots reicht es nicht aus, ein LLM mit einer Liste aus Fragen und Antworten zu verbinden. Erforderlich ist eine vollständige Verarbeitungskette für die Aufbereitung von Dokumenten, den Abruf relevanter Informationen, die Orchestrierung der einzelnen Abläufe, die Datenspeicherung und die Generierung von Antworten.

Für dieses Projekt haben wir einen Technologie-Stack gewählt, mit dem sich die Architektur flexibel, kosteneffizient und mit überschaubarem Aufwand an unterschiedliche Kundenumgebungen anpassen lässt.

LangChain und LangGraph

LangChain stellt die grundlegenden Bausteine bereit, um Dokumentenabruf, Prompts, Modelle und weitere Komponenten miteinander zu verbinden. LangGraph eignet sich wiederum für die Orchestrierung komplexerer Abläufe, bei denen der Chatbot klar definierte Verarbeitungsschritte und eine Zustandsverwaltung benötigt.

Gemeinsam bilden beide Technologien eine flexible Grundlage für eine RAG-Architektur — ohne dass sämtliche Systemkomponenten in einer monolithischen Lösung gebündelt werden müssen.

PostgreSQL

PostgreSQL bietet eine zuverlässige, dauerhafte Speicherung von Anwendungsdaten und kann mit passenden Erweiterungen wie pgvector auch in Architekturen für die Vektorsuche eingesetzt werden. Durch den Einsatz von PostgreSQL bleibt die Datenebene der Anwendung vertraut und gut administrierbar — zugleich lassen sich die Retrieval-Anforderungen einer KI-Anwendung abdecken.

Docling

Docling übernimmt die Aufbereitung und Verarbeitung der Dokumente für das System. Besonders wertvoll ist das Tool, wenn die Ausgangsmaterialien komplexer aufgebaut sind als eine einfache Sammlung von Textdateien. Durch die zuverlässige Erkennung und Übernahme der Dokumentstruktur erhält das nachgelagerte Retrieval-System sauber aufbereitete und besser nutzbare Informationen.

Groq und Ollama

Wir haben Groq und Ollama eingesetzt, um unterschiedliche Szenarien für die Ausführung von LLMs abzudecken. Groq eignet sich besonders dann, wenn eine schnelle Inferenz im Vordergrund steht. Ollama bietet dagegen die Möglichkeit, kompatible Modelle lokal oder in einer selbst gehosteten Umgebung auszuführen.

Da Informationsabruf und Antwortgenerierung voneinander getrennt sind, kann die LLM-Schicht unabhängig weiterentwickelt oder ausgetauscht werden — ohne die gesamte Architektur zur Aufbereitung und Einbindung der Wissensbasis neu aufbauen zu müssen.

Ergebnisse: Was die Lösung erreicht hat

Das zentrale Ergebnis war eine kosten- und ressourceneffiziente Architektur für den Kundensupport, mit der sich eine bestehende Wissensbasis in eine dialogorientierte Benutzeroberfläche überführen lässt. Anstatt Hunderte von Chatbot-Antworten manuell zu erstellen und zu pflegen, nutzt das System die Informationen, die der Kunde bereits in seinen bestehenden Wissensquellen verwaltet.

Die Architektur bietet darüber hinaus mehrere praktische Vorteile:

• Weniger manueller Aufwand bei der FAQ-Pflege: Support-Inhalte können weiterhin in den bereits vorhandenen Wissensquellen des Kunden gepflegt werden.
• Schnellerer Zugriff auf Informationen: Nutzer können ihre Fragen in natürlicher Sprache stellen, anstatt sich durch mehrere Dokumentationsseiten navigieren zu müssen.
• Besserer Umgang mit natürlicher Sprache: Kunden müssen ihre Fragen nicht exakt so formulieren, wie sie in den ursprünglichen FAQ- oder Dokumentationsinhalten stehen.
• Synchronisierte Wissensbasis: Änderungen auf der Website des Kunden können automatisch in die Retrieval-Schicht übernommen werden.
• Flexible Bereitstellung von Modellen: Für die Antwortgenerierung können sowohl cloudbasierte Inferenzdienste als auch lokal bereitgestellte Modelle eingesetzt werden.
• Wiederverwendbare Architektur: Das zugrunde liegende Konzept lässt sich an unterschiedliche Wissensbasen und Support-Szenarien anpassen.

Allgemeingültige Angaben zur Genauigkeit oder zu möglichen Kosteneinsparungen lassen sich für dieses Projekt ohne verifizierte Messwerte des Kunden nicht seriös nennen. Die tatsächliche Leistungsfähigkeit eines KI-gestützten Support-Systems hängt unter anderem von der Qualität der Ausgangsdokumentation, der Konfiguration des Retrievals, der Wahl des Modells und der verwendeten Evaluierungsmethodik ab.

Wann eine Standardlösung ausreicht — und wann eine individuelle Chatbot-Lösung sinnvoll ist

Nicht jedes Unternehmen benötigt einen individuell entwickelten KI-FAQ-Chatbot. Für manche Unternehmen bieten Standardlösungen oder klassische FAQ-Software bereits alle notwendigen Funktionen, um häufige Kundenanfragen zu automatisieren und einfache Fragen zuverlässig zu beantworten.

Bei anderen Unternehmen zeigen sich die Grenzen vorgefertigter Lösungen jedoch schnell — insbesondere dann, wenn die Wissensbasis umfangreicher wird, komplexe Integrationen erforderlich sind oder höhere Anforderungen an Sicherheit und Datenschutz bestehen. Welche Lösung besser geeignet ist, hängt vor allem vom Umfang der Wissensbasis, dem erforderlichen Grad der Individualisierung und davon ab, wie tief der Chatbot in bestehende Systeme und die Prozesse des Kundenservice integriert werden soll.

Wann eine Standardlösung ausreicht

Ein fertiger Chatbot oder eine Standardlösung für FAQs ist oft die bessere Wahl, wenn die Anforderungen überschaubar sind. Eine solche Lösung bietet sich insbesondere an, wenn:

• Ihre FAQ nur eine relativ geringe Anzahl an Fragen umfasst;
• sich die Inhalte nur selten ändern;
• der Chatbot möglichst schnell eingeführt werden soll;
• Standardintegrationen ausreichen;
• keine individuelle Retrieval-Logik oder spezifische Geschäftslogik erforderlich ist;
• die Rollenverteilung einfach gehalten ist — beispielsweise mit Inhaltsadministratoren und Nutzern;
• eine grundlegende Chat- und Nachrichtenhistorie ausreicht;
• die Infrastruktur und die KI-Modelle des jeweiligen Anbieters genutzt werden können.

Ein kleines SaaS-Unternehmen mit einigen Dutzend häufig gestellten Fragen benötigt beispielsweise nicht zwangsläufig eine individuelle RAG-Architektur. Ein fertiger FAQ-Chatbot lässt sich vergleichsweise schnell konfigurieren und kann ohne größeren Entwicklungsaufwand für eine gute Nutzererfahrung im Kundenservice sorgen.

Standardlösungen können außerdem ein sinnvoller Einstieg sein, um wiederkehrende Kundenanfragen zu automatisieren, bevor in ein technisch anspruchsvolleres System investiert wird. Wenn ein Großteil der Support-Anfragen aus einfachen und vorhersehbaren Fragen besteht, kann ein fertiger Chatbot bereits ausreichend Mehrwert bieten und die Support-Teams spürbar entlasten.

Wann eine individuelle Chatbot-Lösung sinnvoller ist

Eine individuell entwickelte Lösung bietet vor allem dann Vorteile, wenn der Chatbot mit der bestehenden IT-Infrastruktur eines Unternehmens arbeiten und auf eine Wissensbasis zugreifen soll, die sich kontinuierlich verändert. Ein maßgeschneiderter KI-FAQ-Chatbot ist insbesondere dann sinnvoll, wenn folgende Anforderungen bestehen:

• Integration in eine bestehende Wissensbasis oder Website;
• differenzierte Rollen- und Berechtigungskonzepte sowie die gezielte Bereitstellung von Informationen für unterschiedliche Nutzergruppen;
• automatische Synchronisierung von Änderungen in der Dokumentation;
• individuelle Verarbeitung und Aufbereitung von Dokumenten;
• erweiterte semantische oder hybride Suche;
• Integration in interne Unternehmenssysteme;
• private oder selbst gehostete Bereitstellung von LLMs;
• individuelle Authentifizierungs- und Zugriffskontrollen sowie die Integration in bestehende unternehmensweite Authentifizierungssysteme;
• Kontrolle über den Retrieval- und Antwortgenerierungsprozess;
• Kontrolle über den Token-Verbrauch;
• Protokollierung und Auswertung von Nutzeraktivitäten sowie Analyse häufig behandelter Themen;
• Unterstützung komplexer oder spezialisierter Abläufe.

Individuelle Lösungen sind besonders dann geeignet, wenn das System unterschiedlich formulierte Kundenanfragen verstehen soll, anstatt lediglich vordefinierte Formulierungen abzugleichen.

Technologien wie Natural Language Processing und maschinelles Lernen ermöglichen es dem Chatbot, verschiedene Formulierungen derselben Frage zu erkennen und gezielt die Informationen abzurufen, die der tatsächlichen Intention des Nutzers am besten entsprechen.

Ein individueller Chatbot kann darüber hinaus mit Kundendaten, Support-Plattformen und weiteren Unternehmenssystemen verbunden werden. So lassen sich beispielsweise Informationen aus früheren Support-Tickets oder Kundeninteraktionen als zusätzlicher Kontext nutzen — vorausgesetzt, geeignete Datenschutz- und Zugriffskontrollen sind implementiert.

Auf diese Weise lässt sich die Kundenkommunikation stärker personalisieren, während sich Support-Mitarbeiter auf komplexe Fälle konzentrieren können, bei denen menschliche Unterstützung erforderlich ist.

Standardlösung vs. individueller Chatbot: Die wichtigsten Unterschiede

FAQ-Chatbot für Mitarbeiter

Dieselbe Architektur lässt sich nicht nur im Kundensupport, sondern auch intern einsetzen. Ein FAQ-Chatbot für Mitarbeiter bietet Beschäftigten einen dialogorientierten Zugang zu internen Informationen aus Bereichen wie Personalwesen, IT und betrieblichen Abläufen.

Anstatt mehrere interne Portale durchsuchen zu müssen, können Mitarbeiter ihre Fragen direkt stellen und erhalten Antworten auf Grundlage der jeweils aktuellen Richtlinien und Prozesse des Unternehmens.

Typische Fragen könnten beispielsweise sein:

• „Wie beantrage ich Urlaub?“
• „Wie läuft der Austausch meines Laptops ab?“
• „Wo finde ich die Richtlinie des Unternehmens zu Reisekosten und Ausgaben?“
• „Wie erhalte ich Zugriff auf einen bestimmten internen Dienst?“

Die zugrunde liegende RAG-Architektur bleibt dabei weitgehend unverändert — interne Dokumente werden erfasst und indexiert, für jede Anfrage werden relevante Informationen abgerufen und ein LLM generiert auf Grundlage dieses Kontexts die passende Antwort.

Der wesentliche Unterschied liegt in den verwendeten Wissensquellen und den damit verbundenen Zugriffsrechten. Ein öffentlich zugänglicher FAQ-Chatbot für Kunden sollte ausschließlich öffentliche Informationen bereitstellen. Ein interner Chatbot für Mitarbeiter muss dagegen möglicherweise mit vertraulichen Dokumenten arbeiten und rollenbasierte Zugriffsrechte berücksichtigen.

Für anspruchsvollere interne Assistenten, die Informationen aus mehreren Systemen zusammenführen, Zusammenhänge analysieren und selbstständig Aktionen ausführen können, lässt sich der Funktionsumfang durch die Entwicklung von KI-Agenten über die reine Beantwortung von Fragen hinaus erweitern.

Unternehmen mit hohen Anforderungen an Datenschutz oder Compliance können zudem Private-LLM-Entwicklungsservices in Betracht ziehen, um mehr Kontrolle über die Bereitstellung der Modelle und den Umgang mit sensiblen Unternehmensdaten zu erhalten.

Beispiele für FAQ-Chatbots

Die folgenden Beispiele zeigen, welche Arten von Fragen ein RAG-basierter Support-Assistent bearbeiten kann. Die Beispiele sind bewusst verallgemeinert und stellen keine wörtlich übernommenen Kundengespräche dar.

Beispiel 1: Kontoverwaltung

Kunde:
„Wie kann ich die E-Mail-Adresse in meinem Konto ändern?“

Chatbot:
„Um die E-Mail-Adresse Ihres Kontos zu ändern, öffnen Sie Ihre Profileinstellungen und aktualisieren Sie die Adresse unter ‚Kontoinformationen‘. Möglicherweise müssen Sie die neue E-Mail-Adresse bestätigen, bevor die Änderung wirksam wird.“

Der Kunde muss dabei nicht exakt dieselben Formulierungen verwenden wie in der Dokumentation. Der Chatbot erkennt die relevanten Informationen zur Kontoverwaltung und gibt sie in einer verständlichen, dialogorientierten Form wieder.

Beispiel 2: Abonnement

Kunde:
„Kann ich meinen Tarif während des laufenden Abrechnungszeitraums wechseln?“

Chatbot:
„Ein Tarifwechsel ist gemäß den geltenden Abonnementbedingungen möglich. Welche Optionen verfügbar sind und wie die Abrechnung erfolgt, hängt von Ihrem aktuellen Tarif ab.“

Ein produktiv eingesetzter Chatbot würde auf die jeweils aktuelle Abonnementdokumentation des Kunden zugreifen und auf dieser Grundlage die konkreten Bedingungen und erforderlichen Schritte nennen.

Beispiel 3: Fehlerbehebung

Kunde:
„Meine Integration funktioniert nicht mehr, seit ich die API-Einstellungen geändert habe. Was sollte ich überprüfen?“

Chatbot:
„Prüfen Sie zunächst die API-Zugangsdaten und die Konfiguration, die von der Integration verwendet werden. Wenn diese Angaben korrekt sind, sollten Sie die Verbindungs- und Authentifizierungsanforderungen der Integration im Leitfaden zur Fehlerbehebung überprüfen.“

Diese Beispiele zeigen, warum eine Liste mit Chatbot-Fragen und -Antworten nicht zwingend manuell erstellt werden muss. Die Quelldokumentation liefert die fachlich relevanten Inhalte, während die KI-Schicht diese an die jeweilige Formulierung der Nutzerfrage anpasst.

Häufig gestellte Fragen (FAQs)