RAG-System gegen KI-Halluzination: Wie meine Suche ‚weiß ich nicht‘ sagen lernte

Ich habe meiner Suche eine Frage gestellt, auf die sie keine Antwort haben kann: „Wie koche ich Spaghetti Carbonara?“ Durchsucht hat sie die Dokumentation von Scrapling, einem Werkzeug zum Abholen von Webseiten. Über Nudeln steht da nichts drin. Die Suche hat trotzdem fünf Abschnitte geliefert. Und der beste bekam denselben Spitzenwert wie bei einer echten Frage: 0,5.

Genau da fängt ein RAG-System an, Antworten zu erfinden. Die Suche findet immer etwas. Das Sprachmodell dahinter bekommt dann Text über Webseiten und soll Carbonara erklären. Ob es ehrlich sagt „steht hier nicht drin“, hängt am Modell. Wenn du KI misstraust, dann wahrscheinlich wegen so einer Antwort: klingt sicher, stimmt nicht. Das nennt man KI-Halluzination. Einen Überblick über die Forschung dazu gibt die Übersichtsarbeit von Huang u. a. (2023).

Warum die Suche das nicht merkt, ist schnell erklärt. Der Wert 0,5 sagt nicht, wie gut ein Abschnitt passt. Er entsteht, indem mehrere Ranglisten miteinander verrechnet werden. Das Verfahren heißt Reciprocal Rank Fusion, auf Deutsch Rangfusion, beschrieben von Cormack, Clarke und Büttcher (2009). Platz 1 bleibt Platz 1, auch wenn nichts passt. So eine Suche kann also gar nicht sagen: Dazu habe ich nichts.

Also habe ich ihr das beigebracht. Gemessen habe ich alles am 15.10.2026.

Was ist RAG?

RAG steht für Retrieval Augmented Generation. Der Begriff stammt aus der Arbeit von Lewis u. a. (2020). Auf Deutsch ungefähr: erst nachschlagen, dann antworten. Ein Sprachmodell weiß nur, was in seinem Training war. Deine Handbücher und deine Webseite kennt es nicht. Also hängt man eine Suche davor. Damit wird die eigene Webseite zur Datenquelle für KI. Was dabei zählt, steht in Webseite für KI optimieren: Was ChatGPT lesen kann. Wie gut KI eine bestimmte Seite lesen kann, lässt sich mit dem LLM-Checker kostenlos testen.

Die RAG-Pipeline läuft so: Die Texte werden in Abschnitte zerlegt. Jeder Abschnitt wird in eine lange Zahlenreihe übersetzt, die seine Bedeutung abbildet. Diese Zahlen liegen in einer Vektordatenbank, dieselbe Sorte, die ich auch beim Gedächtnis für meine KI-Agenten verwendet habe. Kommt eine Frage, wird sie genauso übersetzt. Die Datenbank sucht die Abschnitte, die am nächsten dran liegen. Die besten fünf gehen mit der Frage an das Sprachmodell, und das schreibt die Antwort.

Das klappt gut, solange die Antwort in den Daten steht. Steht sie nicht drin, merkt die Suche das nicht.

Erst die Sitemap, dann die Seiten

Für den Test habe ich die Doku von Scrapling genommen. Scrapling ist ein Python-Werkzeug zum Abholen von Webseiten. Wer schon mit Scrapy gearbeitet hat, kennt die Aufgabe.

Bevor ich irgendwas abhole, hole ich die Sitemap. Das ist die Liste aller Adressen einer Webseite. Die kommt ordentlich in eine kleine Datenbank, SQLite, und dann weiß ich, was es gibt, ohne schon alles geladen zu haben. Ich hab mir kurz vorgestellt, wie ich bei einer großen Seite einfach mal eine Million Seiten runterlade. Nein. Erst die Übersicht, dann entscheiden.

Aus dieser Liste lässt sich vorher aussortieren, was ich nicht brauche: Übersetzungen, Änderungslisten, Rechtliches, Anmeldeseiten. Vieles erkennt eine einfache Regel am Pfad. Für den Rest frage ich Jev, dazu gleich mehr. Hochgerechnet auf eine Million Adressen würde dieses Vorsortieren etwa 20 Dollar kosten.

Danach holt Scrapling die Seiten, macht Markdown daraus und legt sie in der Datenbank ab. Die Abschnitte wandern in die Vektordatenbank. Am Ende waren es 39 Seiten mit 711 Abschnitten.

Dann der Test: 30 Fragen, bei denen feststeht, auf welcher Seite die Antwort steht. 15 auf Deutsch, 15 auf Englisch. Dazu fünf Spaßfragen, auf die die Doku keine Antwort hat. Carbonara war eine davon.

Mein RAG-System: Suche, Ja/Nein-Modell, Entscheidungsmodell

Mir ging es von Anfang an um eine Kombination. Es gibt Modelle, die selbst nichts entscheiden, aber ein Entscheidungsmodell mit Ja und Nein unterstützen können. Die wollte ich zusammenbringen.

Die Suche sammelt. Sie holt zu jeder Frage 20 Kandidaten, schnell und grob.

Dann kommt das Ja/Nein-Modell, das Fachwort dafür ist Reranker. Es bekommt die Frage und einen Abschnitt und gibt einen Wert, wie gut der Abschnitt auf die Frage passt. Das macht es für alle 20 und sortiert danach neu. Ich habe dafür bge-reranker-v2-m3 genommen (Modellkarte). Das läuft bei mir auf dem iMac, nur auf dem Prozessor, rund 3,8 Sekunden pro Frage, und kostet nichts.

Am Ende entscheidet Jev. Jev ist ein Entscheidungsmodell. Es schreibt keinen Text, es wählt aus einer festen Liste von Antworten und sagt dazu, wie sicher es ist. Was das genau ist, habe ich in einem eigenen Artikel aufgeschrieben: Typisierte Entscheidungen statt Fließtext, was Jev ist.

Jev bekommt die Frage und die besten fünf Abschnitte und hat sechs Möglichkeiten: Abschnitt 1 bis 5 oder „nichts davon“. Dieses „nichts davon“ ist der ganze Trick. Damit kann das System zum ersten Mal sagen: weiß ich nicht.

Ergebnis: von 15 auf 25 Treffer auf Platz 1

Die Suche allein kam in zwei Messläufen auf 15 und 16 Treffer auf Platz 1. Die richtige Seite war aber meistens unter den ersten fünf. Das Ja/Nein-Modell holt sie nach vorn, auf 25 von 30. Jev schafft dasselbe, auch 25. Das hätte ich nicht erwartet: Das kleine Modell auf meinem Rechner sortiert so gut wie Jev.

Bei den deutschen Fragen war der Sprung am größten. Die Doku ist englisch, die Suche arbeitet mit einem deutschen Modell, und das passt schlecht zusammen. Nur 5 von 15 deutschen Fragen landeten auf Platz 1. Mit dem Ja/Nein-Modell waren es 11 von 15.

Beim „weiß ich nicht“ trennen sich die Wege. Die Werte vom Ja/Nein-Modell streuen. Eine Spaßfrage bekam 0,71, eine echte Frage 0,01. Da trennt eine feste Grenze schlecht. Mit einem Wert unter 0,01 als Grenze hat es 3 der 5 Spaßfragen erwischt.

Jev mit seinem „nichts davon“ trennt klarer. Allein hat er 4 der 5 Spaßfragen abgelehnt, ohne eine echte Frage wegzuwerfen. Durchgerutscht ist eine Frage zum Export nach PostgreSQL, da lag Jev genau bei 0,5. Ich hätte die Schwelle hochdrehen können. Bei 0,6 lehnt Jev alle fünf ab, wirft dafür aber sechs echte Fragen weg. Das ist ein schlechter Tausch.

Mit beiden zusammen lehnt das System alle fünf Spaßfragen ab. Platz 1 stimmt in 24 von 30 Fällen, und zweimal hat es bei einer echten Frage abgewunken. Das ist die Arbeitsteilung, die ich wollte: Das Ja/Nein-Modell sortiert lokal und kostenlos, Jev sagt am Ende „diese Antwort oder keine“.

Was das kostet: 0,003 Dollar für alle 35 Fragen. Jev braucht rund eine halbe Sekunde pro Frage.

Der Umweg, den ich nicht bestellt hatte

Bevor diese Kette stand, gab es einen Umweg. Der erste Aufbau ließ Jev über jeden der 711 Abschnitte einzeln urteilen: Fachinhalt, Quelltext, Werbung, Navigation. Was sicher Müll war, sollte aus der Suche verschwinden. Das war nicht meine Entscheidung, jeden einzelnen Abschnitt so abzufragen.

Die Urteile selbst waren sauber. 113 Abschnitte wurden ausgeblendet, 16 Prozent. Von 25 davon, die nachgeprüft wurden, waren alle 25 zu Recht draußen.

Besser gefunden wurde danach aber nichts. Platz 1 blieb bei 16 von 30, unter den ersten fünf bei 27 von 30. Der Müll hatte vorher nur 8 von 175 Plätzen unter den ersten fünf belegt. Danach waren es null. Weniger Müll im Material, das später ans Sprachmodell geht, das schon. Bessere Treffer gab es keine.

Gebracht hat der Umweg trotzdem was. Jev hat das Muster gefunden. Fast der ganze Müll kam aus einem einzigen Baustein der Doku-Software, den Kästen „Source code in …“ in der API-Referenz. Die kann man schon beim Abholen der Seiten weglassen, mit einer einfachen Regel, einem sogenannten Selektor. Danach waren es 480 statt 711 Abschnitte, die Treffer blieben gleich, und die Regel kostet nichts. Jev noch mal über alle Abschnitte laufen zu lassen hätte bei jedem Abholen 0,015 Dollar gekostet.

Daraus nehme ich mit: Das Modell findet das Muster einmal. Danach gehört es als Regel ins Skript. Jev setze ich dort ein, wo eine Regel nicht weiterkommt. Ob ein Abschnitt eine Frage beantwortet, kann keine Regel entscheiden.

Grenzen: ein Lauf, 35 Fragen, eine Doku

Das ist eine kleine Messung. Jede Messung lief nur einmal. 35 Fragen, eine Doku mit 39 Seiten. Die Fragen hat ein KI-Agent aus den Überschriften der Doku abgeleitet. Gezählt wurde, ob die richtige Seite vorne liegt, nicht der richtige Abschnitt.

Und manchmal war die Vorgabe zu eng. Zweimal wählte Jev die deutsche README. Die beantwortet die Frage inhaltlich, nur war eine andere Seite als richtig eingetragen. Das zählt in der Tabelle als Fehler, obwohl die Antwort gestimmt hätte.

Ob das auf andere Texte übertragbar ist, weiß ich erst, wenn ich es dort messe.

Was das für „Frag Steven“ heißt

Als Nächstes kommt das auf meine eigene Webseite. „Frag Steven“ soll eine Suche über meine eigenen Texte werden. Da gilt dieselbe Regel: Eine Antwort gibt es nur, wenn sie in meinen Texten belegt ist. Wenn nicht, sagt das System, dass ich dazu nichts geschrieben habe.

Zwei Fehlalarme bei 30 echten Fragen nehme ich dafür in Kauf. Lieber einmal zu oft „weiß ich nicht“ als eine erfundene Antwort mit meinem Namen drunter.

Und wenn du von KI nicht viel hältst: So ein System lässt sich so bauen, dass es zugibt, wenn es nichts weiß. Ob es das tut, sieht man allerdings erst, wenn man es mit Fragen prüft, auf die es keine Antwort gibt.

Den Aufbau nehme ich so mit: Suche, Ja/Nein-Modell und Jev mit dem Ausweg „nichts davon“. Die Regel gegen die Quelltext-Kästen brauche ich dort wahrscheinlich nicht. Meine Seiten haben keine API-Referenz.

Quellen

• Lewis u. a. (2020): Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

• Huang u. a. (2023): A Survey on Hallucination in Large Language Models

• Cormack, Clarke, Büttcher (2009): Reciprocal Rank Fusion

• Modellkarte bge-reranker-v2-m3

• Scrapling-Dokumentation

• Scrapy-Dokumentation

• Webseite für KI optimieren: Was ChatGPT lesen kann (in48stunden.de)

• LLM-Checker: LLM-Readability kostenlos testen (CodeBack)

• Typisierte Entscheidungen statt Fließtext: was Jev ist

• Wie ich meinen KI-Agenten ein Gedächtnis gebaut habe

Alle Messwerte: eigene Messung vom 15.10.2026, je ein Lauf.