Was RAG-Chatbots leisten und wie man sie sicher betreibt

Am 14. Februar 2024 entschied ein kanadisches Schlichtungsgericht, dass eine Fluggesellschaft ihrem eigenen Chatbot glauben muss. Der Passagier Jake Moffatt hatte nach dem Tod seiner Großmutter auf der Website von Air Canada nach einem Trauerfalltarif gefragt. Der Chatbot versicherte ihm, er könne die Vergünstigung noch innerhalb von neunzig Tagen rückwirkend beantragen, mit einem Link zur echten Richtlinie direkt daneben im Chatverlauf. Das stimmte nicht. Air Canada verweigerte die Erstattung und argumentierte vor Gericht, der Chatbot sei eine Art eigener Akteur, für dessen Auskünfte man nicht hafte, eine bemerkenswerte Form der Exkulpation. Das Gericht sah das anders und verurteilte die Airline zu 812,02 kanadischen Dollar Schadenersatz (1).

Das war kein Einzelfall schlechter Software. Das war das Prinzip, das jeder Website droht, die ihrem Chatbot mehr zutraut, als er halten kann. Eine Organisation haftet für das, was auf ihrer Website steht, auch wenn ein Chatbot es formuliert hat. Für Verbände, Fachgesellschaften und Unternehmen, die gerade über einen eigenen Chatbot nachdenken, lohnt sich deshalb ein Blick auf die Technik dahinter, bevor der erste Prototyp online geht.

Air Canadas Chatbot war, soweit öffentlich bekannt, ein Sprachmodell ohne Anbindung an die eigenen Richtlinienseiten. Er beantwortete die Frage nach dem Trauerfalltarif aus einer Art gelerntem Sprachgefühl heraus, nicht aus dem tatsächlichen Text der Bereavement-Policy, die wenige Klicks entfernt lag. Genau diese Lücke schließt Retrieval-Augmented Generation, kurz RAG: ein System, das eine Frage aus den eigenen, aktuellen Dokumenten einer Organisation beantwortet, statt aus antrainiertem Allgemeinwissen zu raten.

Der Unterschied zu einem klassischen, regelbasierten Chatbot mit vorprogrammierten Antwortbäumen liegt woanders, aber ebenso deutlich: Ein Regelwerk kennt nur das, was jemand vorab explizit hinterlegt hat, und scheitert an der ersten Formulierung, die niemand vorausgesehen hat. Ein RAG-System liest bei jeder Anfrage neu. Ändert sich die Beitragsordnung eines Verbands, ändert sich die Antwort automatisch mit, ohne dass jemand den Chatbot neu programmiert.

Der Name beschreibt tatsächlich, was passiert, nur in zwei technischen Schritten. Im Retrieval-Schritt durchsucht das System die hinterlegten Inhalte, Satzung, Beitragsordnung, FAQ-Seiten, Leitlinien-PDFs, nach den Passagen, die zur gestellten Frage passen. Im Generation-Schritt formuliert ein Sprachmodell aus diesen Fundstellen eine zusammenhängende Antwort. Das Modell rät hier nicht ins Blaue. Es übersetzt vorhandenen Text in eine Antwort.

Bei Air Canada wäre der Retrieval-Schritt auf genau die Bereavement-Policy-Seite gestoßen, die im Chatverlauf ohnehin verlinkt war, und hätte sie zur Grundlage der Antwort gemacht, statt sie nur als Fußnote danebenzustellen.

Der Nutzen zeigt sich dort, wo viele ähnliche Fragen auf belegbare, dokumentierte Antworten treffen. Bei einem Verband sind das typischerweise Mitgliedsbeiträge, Kündigungsfristen, Veranstaltungstermine. Bei einer Fachgesellschaft, wie wir sie seit vielen Jahren begleiten, kommen Fragen zu Leitlinien, Fortbildungspunkten und Kongressunterlagen dazu, verteilt über Dutzende PDF-Dokumente, die kaum noch jemand vollständig im Kopf hat. Bei einem mittelständischen Unternehmen sind es Produktfragen, Supportfälle, interne Richtlinien, die in einem Intranet verstauben.

Wichtiger als die Organisationsgröße ist das Verhältnis von Anfragevolumen zu vorhandener Dokumentation. Eine kleine Geschäftsstelle mit wenigen, aber ständig wiederkehrenden Fragen profitiert oft mehr als ein großes Unternehmen mit unstrukturierten Inhalten. Für komplexe Einzelfälle bleibt der persönliche Kontakt die richtige Antwort. Ein gut eingerichtetes System erkennt solche Fälle und leitet sie weiter, statt eine Antwort zu erzwingen, wo eigentlich ein Mensch gefragt ist.

Ein RAG-System ist gegen Fehler nicht immun, obschon das Risiko geringer ist als bei einem frei antwortenden Modell. Auch aus korrekten Fundstellen kann ein Sprachmodell etwas Ungenaues zusammensetzen, und wo die hinterlegten Inhalte selbst veraltet oder widersprüchlich sind, konfabuliert das Modell weiter, nur auf schlechterer Grundlage. Die Qualität der Antworten ist am Ende eine Funktion der Qualität der Inhalte, nicht des Modells.

Das ist die unbequeme Seite eines an sich guten Werkzeugs: Der Aufwand, die eigene Dokumentation zu ordnen und aktuell zu halten, verschwindet nicht, er verlagert sich nur nach vorn. Er bringt außerdem eine zweite, stillere Form von Automatisierungsbias mit sich, subtiler als bei Air Canada: Wer einem System, das meistens richtig antwortet, irgendwann keine Fragen mehr stellt, merkt einen Fehler erst, wenn er teuer wird. Bei rechtlich sensiblen Themen, Beitragsstreitigkeiten etwa oder medizinischen Detailfragen, gehört ein Verweis auf die zuständige Ansprechperson deshalb zur Grundausstattung, nicht zur Kür.

Wer über einen solchen Chatbot nachdenkt, landet früh bei einer Frage, die im ersten Konzeptgespräch gern übersprungen wird: Wo verarbeitet der Anbieter die Daten? Für gemeinnützige Organisationen, Fachgesellschaften und öffentliche Institutionen ist das selten eine akademische Frage, sondern eine, die ein Vorstand tatsächlich stellt, bevor er unterschreibt. Es geht um den Verarbeitungsort, einen Auftragsverarbeitungsvertrag, die Speicherung erfasster Kontaktdaten, und darum, dass Nutzende erkennen können, mit einem System zu sprechen statt mit einem Menschen.

Die meisten gängigen Angebote beantworten diese Fragen nur zögerlich, weil sie am Ende auf einen internationalen Hyperscaler verweisen, dessen Datenflüsse sich von außen kaum prüfen lassen. Wir betreiben unsere KI-Infrastruktur deshalb selbst, auf eigener Hardware in einem Tier-3-Rechenzentrum in München, mit einem Kontextfenster von bis zu 256.000 Token für lange Dokumente und ohne Nutzung von Kundendaten für Training. Davon hängt ab, ob ein Gremium in einer Sitzung zustimmt oder das Thema monatelang prüft.

Ein Punkt wird in der Planung solcher Systeme regelmäßig übersehen: Die Oberfläche selbst muss zugänglich sein. Tastaturbedienbarkeit, eine Struktur, die Screenreader korrekt vorlesen, ausreichende Kontraste, das ist seit dem Barrierefreiheitsstärkungsgesetz für viele Organisationen ohnehin Pflicht, unabhängig vom Chatbot-Projekt (2). Ein Chatbot kann Barrierefreiheit ergänzen, gerade für Menschen, die sich in verschachtelten Seitenstrukturen schwertun. Ersetzen kann er sie nicht.

Air Canadas Problem war am Ende kein technisches. Es war ein Ordnungsproblem, das erst durch einen Chatbot sichtbar wurde: zwei widersprüchliche Aussagen auf derselben Website, von denen niemand gemerkt hatte, dass sie sich widersprechen, bis eine Kundschaft dazwischenstand. Ein RAG-Chatbot deckt solche Lücken auf, weil er jede Anfrage gegen den tatsächlichen, aktuellen Bestand prüft, ohne die Nachsicht, mit der Menschen einander gewöhnlich begegnen. Wo Inhalte klar strukturiert und aktuell sind, liefert er präzise Antworten. Wo sie es nicht sind, zeigt er es schneller, als es je ein Kundenservice-Team könnte.

Jede Antwort ist auch ein Urteil über die Ordnung, die vorher da war.