Die KI kannte mein System. Der Chatbot verstand die Fragen nicht.
Eine Wissensbasis, die Supportfragen beantworten konnte, und ein Chatbot, der daran scheiterte: Was mich ein gescheiterter RAG-Versuch über Kontext, Dokumentation und die Notwendigkeit von Messinstrumenten gelehrt hat.
Im Juli 2026 wollte ich aus einer funktionierenden Wissensbasis einen funktionierenden Chatbot machen. Das schien ein überschaubarer Schritt.
Es wurde aber eine ziemlich frustrierende Erfahrung.
Über Monate hatte ich für DabuSoft Pro eine Single Source of Truth aufgebaut, kurz SSOT: Markdown-Dateien, in denen Tabellen, Module, Regeln und Zusammenhänge an einem definierten Ort beschrieben sind. Sie hatte von Anfang an zwei Aufgaben: mich beim Programmieren zu unterstützen und Fragen zum System zu beantworten, auch die Fragen der Anwender.
Beides funktionierte. Wenn ich zusammen mit einer KI arbeite, liest sie darin nach, folgt Verweisen und zieht weitere Dokumente hinzu. So hilft sie mir beim Programmieren und beantwortet auch Supportanfragen ziemlich gut.
Also sollte doch ein Chatbot für die Anwender das ebenfalls können. Dieselben Informationen, ein Sprachmodell, eine Suche davor. RAG eben.
Dachte ich. Die KI, mit der ich daran arbeitete, war übrigens auch hell begeistert von dieser Idee.
Der Unterschied war grösser, als ich erwartet hatte
RAG steht für Retrieval-Augmented Generation. Vereinfacht gesagt: Ein System sucht zu einer Frage passende Textabschnitte aus einer Wissensbasis und gibt sie einem Sprachmodell als Grundlage für seine Antwort.
Ich bereitete die SSOT dafür auf, zerlegte sie in sogenannte Chunks und stellte die ersten Fragen.
Die Antworten gingen aber mehrheitlich an den Fragen vorbei.
Was mich daran besonders ärgerte: Ich wusste, dass die Informationen vorhanden waren. Ich hatte mit genau diesem Material gearbeitet und gesehen, welche Antwortqualität damit möglich war. Und jetzt sass da ein Chatbot, der aus derselben Grundlage massiv schlechtere Antworten produzierte.
Diese Diskrepanz hat mich mehr beschäftigt als das Scheitern selbst.
Wie konnte eine Wissensbasis in einem Arbeitsablauf so hilfreich sein und in einem anderen so enttäuschen?
Wir haben nicht nur eine Chunk-Grösse ausprobiert
Natürlich haben wir an den üblichen Stellschrauben gedreht.
Andere Chunk-Grenzen. Mehr Kontext. Weniger Kontext. Zusätzliches Umgebungswissen. Unterschiedliche Sprachmodelle.
Es wäre schön gewesen, wenn eine dieser Änderungen den entscheidenden Durchbruch gebracht hätte. Das tat sie nicht. Jedenfalls nicht so, dass aus dem Versuch ein brauchbarer Anwender-Chatbot geworden wäre.
Genau deshalb greift mir die Erklärung «Die Chunks waren eben falsch geschnitten» zu kurz.
Die Aufteilung war ein wichtiger Teil des Problems. Aber hinter ihr lag eine grundsätzlichere Frage: Welches Wissen braucht das Modell für diese konkrete Anwenderfrage – und bekommt es dieses Wissen tatsächlich in einer verständlichen, zusammenhängenden Form?
Eine andere Zahl bei der Chunk-Grösse beantwortet diese Frage noch nicht.
Die SSOT konnte die Fragen beantworten. Der Chatbot nicht.
Die KI half mir mit dieser SSOT nicht nur beim Programmieren. Sie konnte damit sogar Supportanfragen gut beantworten. Also genau das, was später der Chatbot leisten sollte.
Das machte die schlechten Ergebnisse noch ärgerlicher: Die Aufgabe war nicht grundsätzlich zu schwierig, und das nötige Wissen war vorhanden. Ich hatte bereits erlebt, dass daraus hilfreiche Antworten entstehen konnten.
Im Chatbot gelang das trotzdem nicht.
Der Unterschied lag damit nicht einfach zwischen Entwicklerwissen und Anwenderfragen. Mein Verdacht richtete sich deshalb darauf, wie das Wissen erschlossen und dem Modell zur Verfügung gestellt wurde.
In der direkten Arbeit konnte die KI gezielt nachlesen, Verweisen folgen und weitere Zusammenhänge hinzuziehen. Im RAG musste zunächst die Suche aus der Anwenderfrage die passenden Ausschnitte bestimmen. Mit diesem Ausschnitt sollte das Modell dann auskommen.
Dieselbe Wissensquelle bedeutete offenbar noch lange nicht, dass bei der Antwort dieselbe Wissensgrundlage zur Verfügung stand.
Das war für mich die eigentliche Lektion: Eine SSOT kann für die Beantwortung von Supportfragen geeignet sein, während ein darauf aufgebauter RAG-Chatbot daran scheitert. Die Qualität der Quelle allein sagt noch zu wenig über die Qualität des gesamten Systems aus.
Wo auf diesem Weg die entscheidenden Informationen verloren gingen oder Zusammenhänge fehlten, lässt sich allerdings nicht aus einzelnen schlechten Antworten sicher ableiten. Genau dafür braucht es Messinstrumente.
Der nächste Versuch begann beim Material
Ich brach den ersten Ansatz ab und baute den Chatbot im September 2026 mit dem inzwischen frisch verfassten Handbuch als Grundlage von Grund auf neu.
Dieses Handbuch entstand übrigens mit KI-Unterstützung und meiner Begleitung aus derselben SSOT. Die Wissensgrundlage war also dieselbe, auf die sich bereits der gescheiterte Versuch gestützt hatte.
Die entscheidende Veränderung lag in der Aufbereitung: Das Handbuch beschreibt das Wissen aus Sicht der Anwender. Was sehe ich? Was möchte ich erreichen? Welche Schritte gehören zusammen? Was kann ich tun, wenn etwas nicht funktioniert?
Damit verändert sich auch, welche Zusammenhänge innerhalb eines Abschnitts stehen und welche Begriffe dort vorkommen.
Ob eine solche Aufbereitung die erhoffte Verbesserung bringt, muss sich allerdings an den Antworten noch weisen. Ein Handbuch als Datenquelle ist für sich genommen noch kein Qualitätsnachweis.
Wie daraus ein Handbuch entstand – und wie dieses wiederum die SSOT korrigierte –, erzähle ich gerne in einem weiteren Beitrag.
Ohne Messinstrumente bleibt zu viel Vermutung
Bei den jüngsten RAG-Analysen ist für mich ein Punkt nochmals deutlicher geworden: Wer einen belastbaren RAG aufbauen will, braucht Messinstrumente.
Ein paar überzeugende Antworten reichen nicht. Ein paar schlechte Antworten erklären umgekehrt noch nicht, wo das Problem liegt.
Ich will nachvollziehen können:
- Findet die Suche die Informationen, die für die Frage gebraucht werden?
- Enthalten die gelieferten Abschnitte genug Zusammenhang?
- Fehlt eine entscheidende Voraussetzung oder Ausnahme?
- Nutzt das Modell die vorhandenen Informationen richtig?
- Verbessert eine Änderung das System über mehrere Fragen hinweg?
Sonst drehen wir an Chunk-Grössen, Kontextmengen und Modellen und beurteilen das Ergebnis nach Gefühl. Eine Antwort klingt besser, eine andere schlechter. Aber haben wir das System verbessert? Oder nur ein einzelnes Beispiel?
Die Analysen will ich mit weiteren Daten vertiefen. Über die Methodik und die Erkenntnisse werde ich berichten; die zugrunde liegenden Daten bleiben unveröffentlicht. Die Konsequenz daraus ist für mich klar: Messbarkeit gehört zur Entwicklung eines RAG von Anfang an dazu.
Ärgerlich war es trotzdem
Ich hätte mir einiges an Aufwand gern erspart. Vor allem, weil die Ausgangslage so überzeugend aussah: ordentlich dokumentiertes Wissen und eine KI, die damit bereits gut arbeiten konnte.
Aber genau deshalb lohnt es sich, diesen Versuch zu erzählen.
Etwas kann technisch plausibel sein und in der Praxis trotzdem scheitern. Auch dann, wenn die Daten korrekt sind. Auch dann, wenn man mehrere Varianten ausprobiert. Auch dann, wenn die KI selbst den Ansatz für eine gute Idee hält.
Für mich war das kein Grund aufzugeben. Es war ein Grund, die eigene Annahme genauer zu prüfen.
Die Frage lautet inzwischen für mich nicht mehr nur: «Ist das Wissen in der Datenbasis vorhanden?»
Sondern: «Kommt bei einer echten Anwenderfrage das richtige Wissen im richtigen Zusammenhang beim Modell an – und woran kann ich das erkennen?»