Ein Wissensbot ist nur so gut wie das, was er findet. Wir gehen die RAG-Kette durch: Dokumente sinnvoll zerteilen, in Embeddings überführen, in einer Vektordatenbank suchen und das Modell streng an die Fundstellen binden. Plus: wie du Halluzinationen erkennst und misst.
Was RAG löst
Ein Sprachmodell weiß nichts über deine interne Urlaubsregelung, deinen Produktkatalog oder das Onboarding-Handbuch. Fragst du es trotzdem, rät es, oft überzeugend und falsch. Das ist der gefährlichste Zustand: eine Antwort, die richtig klingt, aber frei erfunden ist.
RAG steht für Retrieval Augmented Generation und löst genau das. Bevor das Modell antwortet, sucht ein Retrieval-Schritt die passenden Stellen aus deinen Dokumenten und legt sie dem Modell vor. Das Modell antwortet dann aus dem mitgelieferten Material, nicht aus dem Gedächtnis. Aus "ich rate plausibel" wird "ich fasse zusammen, was hier steht".
Der Effekt ist, dass der Bot auf interne Fragen verlässlich antwortet, mit Bezug auf echte Dokumente, statt zu fabulieren. Die ganze Kunst liegt darin, dass der Retrieval-Schritt wirklich die richtigen Stellen findet. Ein Bot, der schlecht sucht, antwortet auch mit dem besten Modell schlecht. Deshalb steckt der größte Teil der Arbeit nicht im Modell, sondern im Davor.
Chunking: Dokumente sinnvoll zerteilen
Du kannst kein ganzes Handbuch auf einmal durchsuchen. Stattdessen zerlegst du es in Stücke, sogenannte Chunks. Die Größe ist eine Abwägung. Zu kleine Chunks reißen den Zusammenhang auseinander, sodass ein Treffer ohne seinen Kontext dasteht. Zu große verwässern die Suche, weil ein Chunk dann mehrere Themen mischt und bei keinem davon klar trifft.
Gutes Chunking respektiert die Struktur des Dokuments. Du schneidest an Überschriften, Absätzen oder Abschnitten, nicht stur alle fünfhundert Zeichen mitten im Satz. Eine leichte Überlappung zwischen benachbarten Chunks hilft, damit ein Satz, der genau an der Grenze steht, nicht verloren geht.
Dazu gehört auch, Ballast zu entfernen: Kopf- und Fußzeilen, Seitenzahlen, Navigationsreste aus exportierten Webseiten. Solcher Müll landet sonst in den Embeddings und verzerrt die Suche. Diese Vorarbeit entscheidet über die halbe Qualität des Systems. Wir investieren bewusst Zeit hier, statt sie am Ende mit einem teureren Modell wieder reinholen zu müssen, siehe KI-Agents.
Embeddings und die Vektordatenbank
Jeder Chunk wird in einen Vektor übersetzt, eine lange Zahlenreihe, die seine Bedeutung abbildet. Das nennt man Embedding. Texte mit ähnlicher Bedeutung bekommen ähnliche Vektoren, auch wenn sie andere Wörter benutzen. "Wie viele Urlaubstage habe ich" und "Anspruch auf Jahresurlaub" liegen nah beieinander, obwohl kaum ein Wort übereinstimmt.
Diese Vektoren landen in einer Vektordatenbank. Kommt eine Frage herein, wird auch sie zum Vektor, und die Datenbank liefert die ähnlichsten Chunks zurück. Das ist der Retrieval-Schritt, das Herzstück jedes RAG-Systems. Die Datenbank muss dabei schnell genug sein, damit der Bot ohne spürbare Verzögerung antwortet, auch wenn der Index aus zehntausenden Chunks besteht.
In der Praxis kombinieren wir oft die Vektorsuche mit klassischer Stichwortsuche, weil reine Vektorsuche bei exakten Begriffen wie Artikelnummern, Eigennamen oder Paragrafen schwächelt. Die Vektorsuche versteht Bedeutung, die Stichwortsuche trifft das exakte Wort. Zusammen sind sie deutlich treffsicherer als jede für sich.
Retrieval und die Antwort
Beim Beantworten holt das System die besten Treffer, hängt sie an den Prompt und weist das Modell an, ausschließlich daraus zu antworten. Der System-Prompt ist hier streng: "Antworte nur anhand der folgenden Auszüge. Steht die Antwort nicht drin, sag, dass du es nicht weißt." Diese eine Anweisung verhindert einen Großteil der Halluzinationen.
Wie viele Treffer du mitgibst, ist eine Abwägung. Zu wenige, und die richtige Stelle fehlt vielleicht. Zu viele, und du verwässerst den Kontext mit Irrelevantem und zahlst unnötig Token. In der Praxis sind eine Handvoll gut ausgewählter Chunks meist besser als zwanzig mittelmäßige.
Dazu lässt du das Modell die Quelle nennen, aus der es geantwortet hat, idealerweise mit Dokumentname und Abschnitt. So kann der Nutzer nachschlagen und prüfen. Ein Wissensbot ohne Quellenangabe ist ein Vertrauensrisiko, einer mit Quellen ist ein Werkzeug, dem man begründet glauben kann. Welche Modellseite wir nutzen, steht unter Claude im Stack.
Halluzinationen vermeiden
Halluzinationen entstehen meist nicht im Modell, sondern im Retrieval. Findet die Suche nichts Passendes, liefert sie trotzdem die ähnlichsten Chunks, und das Modell baut daraus eine plausible, aber falsche Antwort. Deshalb arbeitest du mit einer Schwelle: Liegt der beste Treffer unter einer Mindestähnlichkeit, antwortet der Bot ehrlich, dass er nichts gefunden hat, statt zu raten.
Der zweite Hebel ist der strikte Prompt, der das Erfinden untersagt, plus die Pflicht zur Quellenangabe. Wenn das Modell jede Aussage belegen muss, fällt es ihm schwerer, frei zu fabulieren. Der dritte Hebel ist sauberes Chunking, damit die richtige Stelle überhaupt findbar ist. Diese drei zusammen drücken die Fehlerrate deutlich.
Eine Null-Halluzination-Garantie gibt niemand seriös, das sagen wir offen. Aber ein Bot, der bei Unsicherheit lieber "weiß ich nicht" sagt, ist im Betrieb hundertmal wertvoller als einer, der bei jeder Frage etwas erfindet. Lieber eine ehrliche Lücke als eine überzeugende Falschauskunft, die jemand ungeprüft weitergibt.
Eval: messen statt hoffen
Ein Wissensbot, den niemand misst, driftet unbemerkt ab. Deshalb gehört zu jedem RAG-System ein Eval-Set: eine Liste echter Fragen mit den erwarteten Antworten oder den erwarteten Fundstellen. Nach jeder Änderung am Chunking, am Prompt oder am Modell lässt du dieses Set durchlaufen und siehst sofort, ob die Qualität steigt oder fällt.
Das Eval-Set baust du am besten aus echten Fragen deiner Mitarbeiter, nicht aus ausgedachten. So misst du, was im Alltag wirklich gefragt wird, statt was leicht zu beantworten ist. Schon dreißig bis fünfzig gut gewählte Fragen geben ein belastbares Bild, und du lässt die Liste über die Zeit wachsen, wann immer eine neue knifflige Frage auftaucht.
Ohne Eval optimierst du im Blindflug und jede Änderung ist ein Glücksspiel. Mit Eval wird aus Bauchgefühl eine Zahl, die du verbessern kannst. Wir liefern das Eval-Set als Teil des Moduls mit, damit du auch nach der Übergabe selbst prüfen kannst, ob Änderungen helfen oder schaden.
Wie wir das bauen
Wir setzen den Wissensbot als abgegrenztes Modul auf: Anbindung deiner Dokumentenquellen, Chunking, Index, Retrieval mit Schwelle, strenger Antwort-Prompt mit Quellen und ein Eval-Set zur Kontrolle. Der Index lässt sich aktualisieren, wenn sich Dokumente ändern, ohne jedes Mal von vorn zu beginnen.
Wir achten auch auf Berechtigungen: Wer welche Dokumente sehen darf, muss sich im Bot widerspiegeln, sonst leakt der Index Inhalte an die falschen Leute. Das planen wir von Anfang an mit ein, statt es nachträglich aufzusetzen.
Der Code und der Index gehören dir, du bist an keinen Anbieter gebunden. Wir arbeiten zum Festpreis pro Modul statt mit laufendem Retainer. Welche Quellen wir anbinden, steht unter Integrationen. Die Spanne findest du unter Preise, und ein Erstgespräch buchst du über Kontakt.