Mein RAG-System erfand eine Durchwahl. Aufgefallen ist das nicht mir, sondern dem Prüfstand.

Im August habe ich hier beschrieben, wie ein RAG-System das Erfahrungswissen eines Kollegen auffindbar macht, der zum Jahresende in Rente geht. Chunking, Embeddings, hybride Suche, Reranking, Wissensgraph. Alles Stand der Technik, alles plausibel.

Plausibel ist keine Messung. Also habe ich das System gebaut: rund 750 Zeilen Python, vier einzeln zuschaltbare Ausbaustufen, vollständig lokal auf einem gewöhnlichen Arbeitsrechner. Dazu ein Testkorpus aus 58 Dokumenten und ein Prüfset mit 40 Fragen.

Das Ergebnis hat mich in einem Punkt überrascht, und zwar unangenehm.

Eine Vorbemerkung zur Redlichkeit: Gemessen habe ich an Betriebsunterlagen aus der Instandhaltung, nicht an Praxisdokumenten, weil ich einen Korpus ohne Patientenbezug veröffentlichen wollte. Die Fragetypen sind dieselben, die im Praxisalltag auflaufen. Die Praxisbeispiele im Folgenden sind Übersetzungen, keine Messergebnisse aus einer Praxis.

Warum das eine Frage der Praxisorganisation ist

Jede Praxis und jede Abteilung hat einen Wissensbestand, den niemand geordnet hat. QM-Handbuch, Hygieneplan, Gerätebücher, Dienstanweisungen, Vertretungsregelungen, dazu die Mail der Medizintechnik von vor zwei Jahren, in der stand, welches Desinfektionsmittel das Endoskop verträgt und welches die Dichtungen angreift.

Das Wissen ist dokumentiert. Die Frage ist, ob es jemand wiederfindet, der neu ist, der Nachtdienst hat oder der die Praxis gerade übernommen hat. Bei der Nachfolge wird daraus ein wirtschaftliches Problem: Was der abgebende Arzt über seine Geräte, die Abrechnung und die Absprachen mit dem Labor weiß, steht zwar irgendwo. Auffindbar ist es deshalb noch lange nicht.

Die vier Stufen und was jede repariert

Reine Vektorsuche scheitert genau an den Fragen, die am häufigsten vorkommen. „Welche Aufbereitungsstufe gilt für das Instrument mit der Nummer ST-4711-B?" enthält als wichtigste Information eine Kennung. Ein Bedeutungsvektor behandelt sie nicht als exakten Schlüssel, sondern als vages Etwas in der Nähe anderer Kennungen. Die Trefferliste zeigt dann irgendwelche Instrumente. Dasselbe gilt für Gerätenummern, Pharmazentralnummern, EBM-Ziffern und Eigennamen.

Stufe zwei stellt der Bedeutungssuche deshalb eine klassische Stichwortsuche zur Seite, BM25, und mischt beide Ranglisten per Reciprocal Rank Fusion. Kein zusätzlicher Modellaufruf, kaum Laufzeit, sofort sind Kennungen und Namen wieder erstklassige Suchbegriffe. Von allen vier Stufen hat diese das mit Abstand beste Verhältnis von Aufwand zu Wirkung. Ich würde sie in keinem produktiven System mehr weglassen.

Stufe drei, das Reranking, prüft die Kandidatenliste ein zweites Mal gegen die konkrete Frage. Ähnlichkeit ist eben nicht Relevanz. Ein Absatz kann der Frage nahe kommen und sie trotzdem nicht beantworten, weil er die Aufbereitung eines anderen Gerätetyps beschreibt. Im Hygienekontext ist das ein Haftungsrisiko.

Stufe vier, der Wissensgraph, setzt dort an, wo jede Textsuche endet. „Wen rufe ich an, wenn das Blutgasgerät ausfällt?" verlangt eine Kette über vier Dokumente hinweg: Gerät, Wartungsvertrag, Servicefirma, Ansprechpartnerin. Kein einzelnes Textstück enthält die ganze Kette.

Der unangenehme Befund

Das Reranking per Sprachmodell, also die naheliegende Umsetzung von Stufe drei, schadet netto.

Es verdrängte wiederholt ausgerechnet das Kontaktdokument aus dem Kontext und war mit rund 25 Sekunden je Frage der langsamste Baustein im System. In einem Lauf erfand es eine Telefonnummer, die nirgends im Korpus steht.

Im Klinikalltag wäre das die Nummer des Bereitschaftsdienstes, nachts, am ausgefallenen Gerät.

Aufgefallen ist mir das nicht beim Draufschauen. Die Antwort sah gut aus. Sie sah sogar besonders gut aus, weil sie eine konkrete Durchwahl nannte. Gefangen hat den Fehler erst der Negativfall-Check, also jene sechs Prüffragen, deren Antwort absichtlich nicht im Korpus steht und bei denen das System ehrlich sagen muss, dass es die Antwort nicht hat.

Genau dafür ist ein Prüfstand da. Er widerlegt nebenbei die bequeme Annahme, mehr Ausbaustufen wären automatisch besser.

Der Ersatz stand noch am selben Tag: ein spezialisierter Cross-Encoder statt des allgemeinen Sprachmodells, lokal betrieben wie alles andere. Er bewertet zwölf Kandidaten in 0,16 statt 25 Sekunden, das ist Faktor 150. Er verdrängt keine richtigen Quellen mehr, halluziniert nicht und hebt die mittlere Position der richtigen Quelle auf 1,0. Sie steht also praktisch immer ganz oben.

Die Zahlen

Gemessen wurde zweierlei: ob die erwartete Quelldatei im Kontext landet, und ob die erzeugte Antwort inhaltlich stimmt.

Der Wissensgraph zeigt ein differenziertes Bild. Ohne Cross-Encoder verbessert er die Antwortquote messbar, vor allem bei Fragen über Dokumentgrenzen hinweg. Mit Cross-Encoder dreht der Effekt auf diesem Prüfset leicht ins Minus, weil der Graph auch generische Hintergrundartikel in den Kontext zieht. Er bleibt deshalb zuschaltbare Option für verkettete Fragen, nicht Teil der Standardkonfiguration. Dazu kommt der Preis: Die Extraktion der Beziehungen kostet rund 13 Sekunden je Textabschnitt beim Einlesen. Das lohnt für QM-Handbuch, Hygieneplan und Gerätebücher, nicht für den Massenimport von Fachliteratur.

Erfreulich: Alle Pipelines ohne das Sprachmodell-Reranking bestehen sämtliche sechs Negativfälle und antworten ehrlich, statt zu raten. Für ein System, das im Behandlungsumfeld Auskunft gibt, ist das die wichtigste Eigenschaft.

Zwei Fehlklassen bleiben offen

Bei umgangssprachlichen Fragen schieben sich generische Hintergrundartikel vor die Betriebsdokumente. Wer nach „dem großen Sterilisator" fragt statt nach dem Gerätenamen, bekommt womöglich einen Lehrbuchabsatz statt der hauseigenen Anweisung. Und Sammelfragen der Art „alle Geräte, in die Frau Dr. Ahrens eingewiesen hat" scheitern über alle Ausbaustufen hinweg an der Zusammenführung mehrerer Fundstellen. Das ist kein Retrieval-Problem mehr, sondern eines der Antwortsynthese. Einweisungsnachweise nach Medizinprodukterecht sind aber genau solche Sammelfragen.

Ich schreibe das hier hin, weil ein Prüfstand seinen Wert verliert, sobald man nur die guten Zeilen zeigt.

Alles lokal, null laufende Kosten

Im Gesundheitswesen ist das keine Geschmacksfrage. Dienstpläne mit Namen, Gerätebücher mit Durchwahlen und Übergabenotizen mit Patientenbezug haben in einer fremden Cloud nichts verloren.

Das System schickt deshalb kein einziges Byte an einen Cloud-Dienst. Sprachmodell, Embedding-Modell und Reranker laufen über LM Studio auf einem normalen Arbeitsrechner, der Index liegt als Dateien daneben.

Das senkt zugleich die Einstiegshürde auf null laufende Kosten und macht das System vorführbar, bevor irgendein Freigabeprozess anläuft. Wer je versucht hat, in einer Klinik ein Cloud-Werkzeug an Datenschutz, Betriebsrat und IT vorbeizubekommen, weiß, was das wert ist. Die Modellanbindung spricht die verbreitete OpenAI-kompatible Schnittstelle, hinter der später genauso ein Server im eigenen Rechenzentrum stehen kann.

Zur Sorge, so etwas skaliere nicht: Beim Aufblasen des Korpus auf das 5,6-Fache, also 1.358 Textabschnitte aus 308 Dokumenten, blieb die Trefferquote der hybriden Suche unverändert. Die Suche braucht dabei 18,5 Millisekunden im 95. Perzentil bei 103 MB Arbeitsspeicher, hochgerechnet bliebe sie selbst bei 200.000 Abschnitten unter 20 Millisekunden. Der QM-Bestand einer großen Praxis liegt weit darunter.

Was ich daraus mitnehme

Die wichtigste Empfehlung aus diesem Projekt ist keine technische. Bauen Sie den Stufenvergleich und das Prüfset, bevor Sie die Erweiterungen bauen.

In meinem Fall hat genau das eine plausibel klingende Erweiterung als schädlich entlarvt und ihren Ersatz binnen eines Tages belegt. Ohne Prüfset hätte ich das Sprachmodell-Reranking eingebaut, es für einen Fortschritt gehalten und die erfundene Telefonnummer erst gefunden, wenn jemand sie gewählt hätte.

Für den eigenen Einstieg reichen 15 bis 30 echte Fragen aus dem eigenen Haus, zu jeder hinterlegt, aus welchem Dokument die Antwort stammen muss. Nehmen Sie die Fragen, die Ihnen neue Kolleginnen und Kollegen in der Einarbeitung wirklich stellen. Das beantwortet die im Alltag entscheidende Frage: Hat die letzte Änderung das System besser oder schlechter gemacht?

Dieselbe Prüfhaltung gehört vor jedes zugekaufte KI-Werkzeug: Ein Anbieter, der keine Fehlerquote nennt, hat entweder nicht gemessen oder nicht gern gemessen.

Und die Grenze aus dem Augustbeitrag gilt unverändert. RAG macht auffindbar, was dokumentiert ist. Der Handgriff, den nie jemand aufgeschrieben hat, bleibt verloren, mit oder ohne KI. Die Übergabenotizen sind die eigentliche Wertschöpfung, das System sorgt nur dafür, dass sie nicht im Dateisystem versinken.

Alle Messwerte, den Aufbau der vier Stufen und die offenen Fehlklassen habe ich im Whitepaper Erweitertes Retrieval-Augmented Generation (RAG) aufgeschrieben, zum Nachlesen und Herunterladen.

Woran messen Sie eigentlich, ob Ihre KI-Werkzeuge besser werden? Ich freue mich auf den Austausch.

Whitepaper „Erweitertes RAG. Vier Ausbaustufen auf dem Weg zu verlässlichen Antworten aus dem eigenen Betriebswissen" (Steven Breuer, September 2026). Der Prüfkorpus besteht aus fiktiven Betriebsunterlagen der Instandhaltung, alle genannten Firmen, Personen und Kennungen sind erfunden; die Praxisbeispiele in diesem Beitrag sind Übertragungen der dort gemessenen Fragetypen. Eingesetzte Modelle: qwen3-vl-8b als Chat-Modell, bge-m3 für Embeddings, bge-reranker-v2-m3 als Reranker, alle frei verfügbar und lokal betrieben.

#RAG #Wissensmanagement #Praxisorganisation #LokaleKI #Datenschutz #KünstlicheIntelligenz