Wie baue ich einen Chatbot für meine Organisation? Ein Praxisbericht am Beispiel einer Kommune
Acht Konzepte für einen Organisations-Chatbot, der lieber nachfragt als rät: Vertrauensreihenfolge der Quellen, deterministische Netze und sichere Ausfallpfade.
Ein Chatbot für die eigene Organisation steht und fällt nicht mit dem Sprachmodell, sondern mit allem, was drumherum passiert. Die härteste Anforderung lautet: Eine falsche Antwort ist schlimmer als keine Antwort. Daraus folgen acht Konzepte, die ich beim Bau von chat-weyhe.de für die Gemeinde Weyhe umgesetzt habe: Struktur beim Einsammeln bewahren, Quellen in eine feste Vertrauensreihenfolge bringen, Zuständigkeit und Folgefragen vorgelagert prüfen, exakte Fakten deterministisch statt per Ähnlichkeitssuche beantworten, Wissenslücken aktiv erkennen, riskante Inhalte aus dem Kontext entfernen statt sie im Prompt zu verbieten, und jeden Ausfall in die sichere Richtung fallen lassen. Dieser Beitrag beschreibt die Konzepte, nicht die Werkzeuge.
Ein Bürger fragt: „Wann wird das Altpapier abgeholt?" Der Bot antwortet freundlich, präzise und vollkommen falsch. Er liefert den Abfuhrkalender der Pappelstraße. Der Bürger wohnt in der Häfkerstraße.
Was ist passiert? Eine Ähnlichkeitssuche hat gefunden, was ähnlich klingt. Papier, Pappel, passt schon. Für die Mathematik ein Treffer. Für den Bürger eine falsche Auskunft. Und für das Vertrauen in den Bot der Anfang vom Ende.
Ich habe in den letzten Monaten einen Chatbot für eine Kommune gebaut: chat-weyhe.de beantwortet Fragen von Bürgerinnen und Bürgern der Gemeinde Weyhe. Öffnungszeiten, Ausweise, Kitas, Abfuhrtermine, Vereine, Ortsgeschichte. In diesem Artikel geht es nicht um Tools oder Frameworks. Es geht um die Konzepte dahinter. Denn die wichtigste Lektion des Projekts lautet: Das Sprachmodell ist der einfachste Teil. Die eigentliche Arbeit steckt in allem, was drumherum passiert.
Die acht Konzepte im Überblick
| # | Konzept | Kernregel |
|---|---|---|
| 1 | Wissen einsammeln | Struktur retten statt verflachen, laute Fehler statt stiller |
| 2 | Vertrauensreihenfolge | Fünf Quellen in fester Rangfolge, geprüfte oben |
| 3 | Türsteher | Zuständigkeit klären, bevor Teures passiert |
| 4 | Folgefragen | Frage erst eigenständig machen, dann suchen |
| 5 | Deterministische Netze | Exakte Schlüssel exakt abfragen, ohne KI |
| 6 | Ähnlichkeit ist kein Wissen | Lücke per Prüfschritt feststellen, nicht per Schwellwert |
| 7 | Weglassen statt ermahnen | Was nicht im Kontext steht, kann nicht falsch zitiert werden |
| 8 | Sichere Ausfallrichtung | Jeder Fehlerpfad endet konservativ, nie im Raten |
Das Ziel: Vertrauen, nicht Technikschau
Das Ziel eines Organisations-Chatbots ist nicht „Wir haben jetzt auch KI". Das Ziel ist: Menschen bekommen schnell eine richtige Antwort. Rund um die Uhr, ohne Warteschleife, ohne Verwaltungsdeutsch.
Das entscheidende Wort ist „richtig". Daraus folgt die härteste Anforderung des ganzen Projekts: Eine falsche Antwort ist schlimmer als keine Antwort. Erfundene Öffnungszeiten, ein falscher Abfuhrtermin, eine ausgedachte Telefonnummer. Jeder dieser Fehler kostet Vertrauen, und Vertrauen ist die einzige Währung, in der so ein Bot bezahlt wird. Deshalb zieht sich ein Leitmotiv durch die gesamte Architektur: Der Bot darf lieber nachfragen als raten. Und er darf ehrlich sagen, dass er etwas nicht weiß.
Was mir wichtig war
Vier Dinge standen für mich fest, bevor die erste Zeile Code entstand.
Korrektheit vor Eloquenz. Sprachmodelle formulieren wunderbar. Das ist ihr Charme und ihre Gefahr, denn eine falsche Antwort klingt genauso überzeugend wie eine richtige. Die Architektur muss dafür sorgen, dass das Modell nur über Dinge sprechen kann, die es tatsächlich weiß.
Ehrlichkeit als Feature. „Das weiß ich nicht, frag bitte im Bürgerbüro nach" ist keine Schwäche. Es ist eine der wertvollsten Antworten, die der Bot geben kann.
Souveränität als Architekturentscheidung. Bürgerfragen sind sensibel. Deshalb: ein europäisches Sprachmodell, eine selbst betriebene Suchmaschine, eine eigene Datenbank, keine gespeicherten IP-Adressen. Souveränität steht bei diesem Projekt nicht in den Datenschutzhinweisen. Sie steht im Code.
Der Ton macht die UX. Der Bot hat eine klare Persona: ein guter Freund, der sich im Ort auskennt. Er duzt, er ist warm im Ton und trotzdem sachlich. Und er ist transparent: Jede Antwort zeigt ihre Quellen, und ein Hinweis macht klar, dass hier eine KI antwortet.
Konzept 1: Wissen einsammeln, ohne es zu zerstören
Ein Chatbot ist nur so gut wie seine Wissensbasis. Die Grundidee ist unter dem Namen Retrieval Augmented Generation (RAG) bekannt und schnell erklärt: Inhalte aus den eigenen Quellen werden gesammelt, in kleine Abschnitte zerlegt und so gespeichert, dass sie sich nach Bedeutung durchsuchen lassen. Bei einer Frage werden die passendsten Abschnitte herausgesucht und dem Sprachmodell als einzige Grundlage mitgegeben.
Klingt einfach. Ist es nicht. Denn das Einsammeln ist vor allem Fehlerarbeit. Mein teuerster Bug: Beim Bereinigen der Seiten sollten Cookie-Banner entfernt werden. Ein Content-Management-System markiert den sichtbaren Cookie-Hinweis aber ausgerechnet am äußersten Rahmen der Seite. Die Bereinigung löschte deshalb nicht den Banner, sondern die komplette Seite. Acht von neun Infoseiten eines Entsorgers kamen leer an, darunter ausgerechnet die Sperrmüll-Anmeldung. Die landete damit selbst im Sperrmüll. Und niemand hat es gemerkt, weil leere Seiten stillschweigend übersprungen wurden.
Daraus habe ich drei Prinzipien abgeleitet:
- Laute Fehler statt stiller. Eine Seite, aus der nichts extrahiert wurde, ist ein Fehler und kein Achselzucken.
- Sicherheitsstopps. Liefert ein Durchlauf plötzlich nur noch die Hälfte der bisherigen Inhalte, wird nichts gelöscht und nichts ersetzt. Ein abgebrochener Lauf darf niemals einen guten Datenbestand wegräumen.
- Struktur retten statt verflachen. Ein Abfuhrkalender ist kein Fließtext, sondern eine Tabelle mit einem Schlüssel, nämlich der Straße. Wer diese Struktur beim Einsammeln als Metadaten bewahrt, kann später exakt abfragen statt ungefähr suchen. Genau das rettet den Bürger aus der Pappelstraße.
Und weil es eine Kommune ist, gilt beim Einsammeln außerdem: höflich bleiben. Regeln der Websites respektieren, Pausen zwischen den Abrufen, ein ehrlicher Absender. Man crawlt hier schließlich die Nachbarschaft, nicht das Internet.
Konzept 2: Nicht ein Weg zur Antwort, sondern eine Vertrauensreihenfolge
Der Bot hat fünf Wege zu einer Antwort, und sie sind streng geordnet:
| Rang | Quelle | Beispiel | Verlässlichkeit |
|---|---|---|---|
| 1 | Deterministische Fakten | Abfuhrkalender je Straße | exakt, kein „ungefähr" |
| 2 | Kuratierte Fakten | kanonische Kontaktdaten der Gemeinde | handgepflegt, überlebt jeden Neuimport |
| 3 | Wissensbasis | eingesammelte Inhalte der Websites | gut, aber ähnlichkeitsbasiert |
| 4 | Live-Daten | Wetter | aktuell, nie aus der Datenbank |
| 5 | Freies Internet | alles Übrige | Notlösung, sichtbar als „nicht amtlich" markiert |
Ganz oben stehen harte Fakten, die deterministisch abgefragt werden. Hier gibt es kein „ungefähr". Darunter liegen kuratierte Fakten: handgepflegte Dokumente für Dinge, die auf keiner Website sauber stehen. Sie überleben jeden automatischen Neuimport. Dann folgt die eigentliche Wissensbasis aus den eingesammelten Inhalten. Daneben gibt es Live-Daten: Das Wetter kommt nie aus der Datenbank, denn gespeichertes Wetter ist wie eine Zeitung von gestern, nur aufwendiger. Und ganz unten, nur als Notlösung, steht das freie Internet. Es wird nur befragt, wenn die eigene Basis die Frage nachweislich nicht beantworten kann, und jede Antwort daraus trägt ein deutliches Warnschild: nicht amtlich.
Diese Reihenfolge ist eine Vertrauensordnung, und sie zieht sich bis in die Antwort durch. Geprüfte Quellen stehen im Kontext oben, Internetfunde unten und markiert.
Konzept 3: Ein Türsteher vor der teuren Technik
Bevor irgendetwas Aufwendiges passiert, prüft der Bot, ob die Frage überhaupt zu ihm gehört. Gestaffelt von billig nach teuer: erst einfache Muster (nein, er schreibt keine Gedichte und löst keine Mathe-Hausaufgaben), dann eine Liste lokaler Schlüsselwörter, dann erlaubte Allgemeinfragen, und erst ganz am Ende eine semantische Prüfung. Der Bot klärt also zuerst seine Zuständigkeit. Für einen kommunalen Bot ist das fast schon rührend authentisch.
Wichtig dabei: Jede Ablehnung wird mit Grund und Konfidenz protokolliert. Die Grenzfälle von heute sind das Material, mit dem die Regeln von morgen besser werden.
Konzept 4: Folgefragen sind ein eigenes Problem
„Und wann Papier?" Ohne Gesprächsverlauf ist diese Frage sinnlos. Mit ungeprüftem Verlauf wird sie gefährlich, denn alte Themen und womöglich alte Fehler verunreinigen die Suche. Auf die Frage nach dem Bürgermeister von 1997 kann schließlich ein komplett neues Thema folgen.
Deshalb entscheidet ein vorgeschalteter, bewusst günstiger Schritt zwei Dinge: Ist das eine Folgefrage oder ein Themenwechsel? Und wie lautet die Frage als eigenständige, vollständige Suchanfrage? Aus „Und wann kommt Papier?" wird so „Wann wird das Altpapier in der Häfkerstraße abgeholt?". Erst diese Frage geht in die Suche.
Konzept 5: Deterministische Netze unter dem Sprachmodell
Für Fakten mit exakter Schlüsselstruktur ist eine exakte Abfrage der Ähnlichkeitssuche haushoch überlegen. Also werden Straßennamen normalisiert (Straße, Strasse und Str. sind dasselbe Wort), Tippfehler tolerant behandelt (die „Häferkstraße" findet trotzdem die Häfkerstraße), und wenn gar keine Straße genannt wurde, übernimmt der Bot die zuletzt von der Person genannte Straße aus dem Verlauf.
Ein Detail daran ist mir besonders wichtig: Übernommen wird nur, was die Person selbst geschrieben hat, niemals etwas aus den Antworten des Bots. Der zählt nämlich gern fremde Straßen auf, und die dürfen sich nicht als „Deine Straße" festsetzen. Dieses ganze Netz ist bewusst reiner, langweiliger Code ohne jede KI. Gerade weil das Modell hier gelegentlich falsch läge und der Fehler teuer wäre.
Konzept 6: Ähnlichkeit ist kein Wissen
Die unbequemste Erkenntnis des Projekts: Ein Ähnlichkeitswert sagt nicht, ob eine Frage beantwortbar ist. Alles, was halbwegs nach der Region klingt, bekommt hohe Werte. Echte Wissenslücken schneiden dabei teils besser ab als eindeutige Treffer. Ein Schwellwert kann die beiden Fälle schlicht nicht trennen.
Die Lösung ist unspektakulär und wirksam: ein zweiter, sehr günstiger Prüfschritt, der genau eine Frage beantwortet. Steht die konkret gesuchte Information wirklich in dem, was gefunden wurde? Erst wenn die Antwort Nein lautet, darf das Internet aushelfen.
Dieselbe Einsicht kenne ich aus meiner Wissensdatenbank Destille: Ein Vektorindex ist gut im Wiederfinden und in der Recherche. Ob das Gefundene die Frage tatsächlich beantwortet, entscheidet er nicht.
Konzept 7: Weglassen ist stärker als ermahnen
Man kann einem Sprachmodell im Prompt verbieten, den Kalender einer fremden Straße zu nennen. Oder man sorgt dafür, dass dieser Kalender gar nicht erst im Kontext steht. Das Zweite funktioniert. Kann keine Straße bestimmt werden, fliegen sämtliche Kalenderdaten aus dem Kontext, und der Bot fragt freundlich nach. Prompt-Regeln sind die zweite Verteidigungslinie, nicht die erste.
Dazu passt die Geschichte mit den Links. Der Bot hat sich anfangs Webadressen zusammengereimt, plausibel klingend und falsch. Verschwunden ist das nicht durch strengere Ermahnungen im Prompt, sondern dadurch, dass die echten Adressen überhaupt erst in den Kontext kamen. Halluzinationen entstehen oft aus Lücken im Kontext, nicht aus Bosheit des Modells.
Konzept 8: Jeder Fehler fällt in die sichere Richtung
Alles fällt irgendwann aus. Die Frage ist nur, wohin. Bei diesem Bot führt jeder Fehlerpfad in die sichere Richtung:
- Fällt die Folgefragen-Erkennung aus, wird nur die aktuelle Frage verwendet, der Verlauf bleibt aber erhalten.
- Fällt der Prüfschritt aus, gilt der eigene Kontext als ausreichend, statt unnötig das Internet zu befragen.
- Ist ein externer Dienst nicht erreichbar, läuft der Chat ohne dieses eine Feature weiter.
Nichts bricht die Antwort ab, aber nichts rät ins Blaue.
Was Du mitnehmen kannst
Wenn Du für Deine Organisation einen Chatbot planst, egal ob Kommune, Hochschule oder Unternehmen: Fang nicht beim Modell an. Fang bei diesen fünf Fragen an.
- Welche Antworten müssen exakt sein, und wie bewahre ich ihre Struktur?
- In welcher Reihenfolge vertraue ich meinen Quellen?
- Woran merke ich, dass mein Wissen Lücken hat?
- Was passiert, wenn ein Baustein ausfällt?
- Und traut sich mein Bot, „Ich weiß es nicht" zu sagen?
Das Sprachmodell ist austauschbar. Das Konzept ist es nicht. Das ist derselbe Punkt, den ich in AI-Dev#1 für Entwicklungsteams beschrieben habe: Die Werkzeuge sind selten das Problem, die Ordnung darum herum ist es. Wie ich das in Projekten begleite, steht auf der Seite zur KI-gestützten Entwicklung.
Zum Schluss eine Frage an Dich: Welche Frage müsste ein Chatbot in Deiner Organisation als Allererstes fehlerfrei beantworten können? Ich tippe auf die Öffnungszeiten. Es sind erstaunlich oft die Öffnungszeiten.
Häufige Fragen
Nicht beim Sprachmodell anfangen, sondern bei der Wissensbasis und den Regeln darum herum. In der Praxis heißt das: Inhalte einsammeln, ohne ihre Struktur zu zerstören; eine feste Reihenfolge festlegen, in welcher Reihenfolge Quellen vertraut wird; exakte Fakten deterministisch abfragen statt per Ähnlichkeitssuche; Zuständigkeit, Folgefragen und Wissenslücken jeweils vorgelagert prüfen; und jeden Ausfall in die sichere Richtung fallen lassen. Das Modell selbst ist der austauschbarste Teil des Systems.
Weil eine Ähnlichkeitssuche findet, was ähnlich klingt, nicht was stimmt. Fragt jemand nach der Altpapierabfuhr in der Häfkerstraße, liefert die Vektorsuche bereitwillig den Kalender der Pappelstraße: Papier, Pappel, mathematisch ein Treffer. Für Fakten mit exakter Schlüsselstruktur wie Straßen, Terminen oder Aktenzeichen ist deshalb eine deterministische Abfrage über Metadaten der Ähnlichkeitssuche deutlich überlegen. Die Struktur muss dafür schon beim Einsammeln der Inhalte erhalten bleiben.
Durch Weglassen statt Ermahnen. Ein Verbot im Prompt, den Abfuhrkalender einer fremden Straße zu nennen, wirkt unzuverlässig; ihn gar nicht erst in den Kontext zu legen, wirkt zuverlässig. Kann keine Straße bestimmt werden, fliegen alle Kalenderdaten aus dem Kontext und der Bot fragt nach. Umgekehrt gilt dasselbe: Erfundene Webadressen verschwanden erst, als die echten Adressen im Kontext standen. Halluzinationen entstehen meist aus Lücken im Kontext, nicht aus Bosheit des Modells. Prompt-Regeln sind die zweite Verteidigungslinie, nicht die erste.
Eine feste Rangfolge, in der ein Chatbot seine Quellen befragt und im Kontext anordnet. Bei chat-weyhe.de sind das fünf Stufen: deterministische Fakten wie der Abfuhrkalender, kuratierte Fakten wie kanonische Kontaktdaten, die eingesammelte Wissensbasis, Live-Daten wie das Wetter und als Notlösung das freie Internet. Geprüfte Quellen stehen im Kontext oben, Internetfunde unten und mit dem Hinweis 'nicht amtlich' markiert. So wird aus einer Suchreihenfolge eine Vertrauensordnung, die bis in die Antwort sichtbar bleibt.
Über einen vorgeschalteten, bewusst günstigen Schritt, der zwei Dinge entscheidet: Ist das eine Folgefrage oder ein Themenwechsel? Und wie lautet die Frage als eigenständige, vollständige Suchanfrage? Aus 'Und wann kommt Papier?' wird so 'Wann wird das Altpapier in der Häfkerstraße abgeholt?'. Erst diese Frage geht in die Suche. Ohne Gesprächsverlauf wäre die Folgefrage sinnlos, mit ungeprüftem Verlauf verunreinigen alte Themen und alte Fehler die Suche.
Weil ein Ähnlichkeitswert nicht misst, ob eine Frage beantwortbar ist. Alles, was halbwegs nach der Region klingt, bekommt hohe Werte; echte Wissenslücken schneiden dabei teils besser ab als eindeutige Treffer. Ein Schwellwert kann die beiden Fälle nicht trennen. Wirksam ist stattdessen ein zweiter, sehr günstiger Prüfschritt mit genau einer Frage: Steht die konkret gesuchte Information wirklich in dem, was gefunden wurde? Erst wenn die Antwort Nein lautet, darf eine externe Quelle aushelfen.
Dass die Architektur die Zusagen einlöst, nicht die Datenschutzerklärung. Bei chat-weyhe.de heißt das konkret: ein europäisches Sprachmodell, eine selbst betriebene Suchmaschine, eine eigene Datenbank und keine gespeicherten IP-Adressen. Bürgerfragen sind sensibel, weil aus ihnen Lebenslagen ablesbar sind, von der Kita-Anmeldung bis zur Sozialberatung. Souveränität ist damit eine Architekturentscheidung, die vor der ersten Zeile Code fällt und sich hinterher kaum nachrüsten lässt.