Startseite / Artikel / Verringerung von Halluzinationen in einem medizinischen RAG-Chatbot-Pipeline

RAG LLM Vector Search Hybrid Search NLP AI Safety

Verringerung von Halluzinationen in einem medizinischen RAG-Chatbot-Pipeline

Erfahren Sie, wie hybride Suche, Neubewertung der Ergebnisse sowie eine strenge Politik gegen das Erfinden von Inhalten zusammenwirken, um einen zuverlässigeren Chatbot für medizinische Forschung im RAG-Format zu schaffen.

1960 Wörter

Das Projekt begann mit einem einfachen Ziel.

Man wollte einen Chatbot entwickeln, der in der Lage ist, Fragen auf der Grundlage wissenschaftlicher Arbeiten aus dem medizinischen Bereich zu beantworten.

Das sollte doch einfach genug sein, oder?

Es stellte sich jedoch als nicht so einfach heraus.

Die anfängliche Umsetzung folgte einem recht konventionellen RAG-Ansatz: Die Dokumente wurden eingeholt, Embeddings erzeugt, in einer Vektordatenbank gespeichert, relevante Abschnitte abgerufen und an das LLM übergeben.

Es funktionierte.

Nur nicht zuverlässig.

Und im medizinischen Kontext ist „nicht zuverlässig“ ein ernsthafter Mangel.

Ein Chatbot, der selbstbewusst, aber falsch antwortet, ist weitaus gefährlicher als einer, der zugibt: „Ich habe nicht genügend Informationen, um diese Frage zu beantworten.“

Diese Erkenntnis führte dazu, dass der Abrufprozess kontinuierlich weiterentwickelt wurde.

Das erste Problem: Halluzinationen

Das dringendste Problem, das gelöst werden musste, waren Halluzinationen.

Sprachmodelle sind außergewöhnlich gut darin, Antworten zu erzeugen, die überzeugend klingen – manchmal sogar zu überzeugend.

Falls die Dokumente keine Antwort enthielten, füllte das Modell oft die Lücke mit seinem eigenen internen Wissen, anstatt Unsicherheit einzugestehen.

Dieses Verhalten musste geändert werden.

Die Antworten des Chatbots durften ausschließlich aus dem bereitgestellten Forschungsmaterial stammen, nicht aus der Vorstellungskraft des Modells.

Daher änderte sich die zugrundeliegende Philosophie.

Anstatt das LLM als Autorität für Fakten zu betrachten, wurden die abgerufenen Dokumente zur eigentlichen Quelle der Wahrheit.

Die Rolle des LLM beschränkte sich darauf, diesen abgerufenen Kontext zu interpretieren und ihn in eine kohärente Antwort zu formen.

Und wenn der Kontext unzureichend war?

Das System sollte darauf verzichten, zu raten.

Ausgangspunkt: Grundlegender RAG

Die erste Version der Architektur sah einfach aus:

Dies repräsentiert das Standard-RAG-Muster.

Ein großes Dokument wird in kleinere Abschnitte aufgeteilt, wobei jeder dieser Abschnitte eingebettet und in einer Vektordatenbank gespeichert wird.

Jedes Mal, wenn ein Benutzer eine Frage einreicht, wird auch diese Frage eingebettet.

Dann sucht das System nach Abschnitten, deren Vektoren semantisch nahe beieinander liegen.

Theoretisch ganz einfach.

Doch schnell zeigte sich ein Problem.

Semantische Nähe garantiert keine tatsächliche Relevanz.

Warum Vektorabfrage nicht ausreichte

Stellen Sie sich vor, ein Benutzer fragt:

"Welche Auswirkungen hat Insulinresistenz?"

Semantische Suche ist gut darin, die allgemeine Absicht hinter dieser Frage zu erfassen.

Das ist nützlich.

Allerdings sind medizinische Texte voller präziser Fachbegriffe.

Begriffe wie:

Insulinresistenz
HbA1c
Hyperglykämie
Metformin
Zuckerbelastungstest

Diese spezifischen Begriffe haben große Bedeutung.

Mannchmal braucht man ein Verständnis des allgemeinen Sinns.

Andernfalls muss das System den genauen Begriff selbst finden.

Warum sich mit nur einer Funktion zufriedengeben?

Die Lösung bestand darin, beides zu kombinieren.

Hybride Suche

Daher wurde die hybride Suche zu einem zentralen Bestandteil des Designs.

Anstelle einer rein vektorbasierten Suche wurde die semantische Suche mit einer schlagwortbasierten Suche kombiniert.

Die Logik dahinter ist recht intuitiv.

Bei der semantischen Suche wird im Grunde gefragt:

„Welcher Inhalt hat eine ähnliche Bedeutung?“

Bei der schlagwortbasierten Suche wird hingegen gefragt:

„Wo tauchen die Schlüsselbegriffe tatsächlich auf?“

Jede Methode hat ihre eigenen Stärken.

Auch jede hat ihre eigenen Schwachstellen.

Zusammen decken sie ein breiteres Spektrum an Abfragen ab.

Der resultierende Ablauf sah so aus:

User Query
                        ↓
              ┌─────────┴─────────┐
              ↓                   ↓
        Vector Search       Keyword Search
              ↓                   ↓
              └─────────┬─────────┘
                        ↓
                  Combined Results
                        ↓
                     Reranker
                        ↓
                 Best Context
                        ↓
                       LLM
                        ↓
                      Answer

Diese Veränderung prägte von da an die Herangehensweise bei der Suche.

Ein weiteres Problem blieb bestehen.

Dass etwas gefunden wird, bedeutet nicht, dass es das Beste ist

Nehmen wir an, der hybride Suchschritt liefert 20 Blöcke.

Das klingt vielversprechend.

Aber sind alle diese Blöcke wirklich nützlich?

Nicht unbedingt.

Einige Blöcke könnten sehr themenbezogen sein.

Andere teilen möglicherweise nur ein überlappendes Vokabular.

Weitere könnten nur indirekt verwandt sein, ohne die eigentliche Frage zu beantworten.

Alles direkt an das LLM weiterzuleiten, ist keine ideale Lösung.

Mehr abgerufener Kontext führt nicht automatisch zu besseren Antworten.

Tatsächlich kann das das Ergebnis sogar verschlechtern.

Dadurch entstehen mehr Token, mehr irrelevanter Lärm und mehr Verzögerung.

Deshalb wurde eine weitere Stufe eingeführt.

Neubewertung der Ergebnisse.

Warum die Neubewertung der Ergebnisse einen Unterschied macht

Die Rolle des Abrufsystems lässt sich wie folgt zusammenfassen:

Mögliche Kandidaten aufzeigen.

Die Rolle des Neubewertungssystems ist anders:

Ermitteln, welche dieser Kandidaten tatsächlich relevant sind.

Anstelle der einfachen Kette:

Query → Search → LLM

entwickelte sich der Prozess zu:

Query
 ↓
Hybrid Search
 ↓
20 Candidate Chunks
 ↓
Reranker
 ↓
Top Relevant Chunks
 ↓
LLM

Diese Trennung der Aufgaben ist wichtig.

Die erste Abrufstufe kann die Vollständigkeit priorisieren und ein breites Netz auswerfen.

Die Neubewertungsstufe kann sich dann gezielt auf Relevanz und Genauigkeit konzentrieren.

Für einen Chatbot für medizinische Forschung erwies sich diese Unterscheidung als besonders wertvoll, da ein Abschnitt, der lediglich die richtige Terminologie enthält, nicht immer derjenige ist, der tatsächlich die Frage des Nutzers beantwortet.

Der wichtigste Aspekt: Auf Fälschungen verzichten

Neben dem Abrufen und Neuranking wurden auch beim Generierungsprozess strenge Einschränkungen eingeführt.

Die Kernanweisung ließ sich auf Folgendes reduzieren:

Use the provided context to answer.

Do not invent information.If the context doesn't contain enough information,
say that there isn't enough information available.

Das sieht fast zu einfach aus, um wirklich wichtig zu sein.

Doch es verändert deutlich das Verhalten des Chatbots.

Anstatt das Modell dazu zu zwingen, unter allen Umständen eine Antwort zu liefern, gibt dieser Ansatz ihm einen Ausweg, wenn einfach nicht genügend Material vorhanden ist.

Diese Ausweichmöglichkeit stellt sich als unerlässlich heraus.

Mannchmal lautet die ehrliche Antwort etwa:

„Ich konnte in den bereitgestellten Forschungsmaterialien keine ausreichenden Informationen finden.“

Nicht jede Frage verdient eine zuversichtliche Antwort.

Wurden Halluzinationen somit vollständig beseitigt?

Nicht wirklich.

Das wurde während des Aufbaus des Systems klar.

RAG verringert tatsächlich Halluzinationen und hält die Antworten enger an echte Quellen gebunden.

Aber zu behaupten, es gäbe keine Halluzinationen mehr, wäre übertrieben.

Es bleiben zahlreiche Fehlerquellen bestehen.

Der Informationsabrufmechanismus könnte den falschen Teil der Daten heranziehen.

Das Aufteilen in Teile könnte wichtigen Kontext entfernen.

Die Neubewertungsfunktion könnte die Relevanz falsch einschätzen.

Die zugrunde liegenden Dokumente könnten von vornherein fehlende Informationen enthalten.

Auch wenn alles vorherige funktioniert, kann das große Sprachmodell dennoch falsch interpretieren, was es abgerufen hat.

Daher ist das eigentliche Ziel nicht:

„Einen Chatbot zu entwickeln, der niemals falsch liegt.“

Sondern eher:

„Erstellen Sie ein System mit weniger Möglichkeiten zum Fehlschlagen und eines, das die Grenzen dessen erkennt, was es tatsächlich weiß.“

Das ist ein weitaus erreichbareres Ziel.

Die Bedeutung des Blöckenkonzepts

Eine wichtige Erkenntnis: Die Aufteilung von Dokumenten in Blöcke ist kein einmalig konfigurierter, unbedeutender Vorausverarbeitungsschritt.

Zu große Blöcke beinhalten unverwandte Inhalte.

Zu kleine Blöcke können den umgebenden Kontext entfernen, auf den eine Aussage angewiesen ist.

Es hilft, jeden Block als eigenständige Wissenseinheit statt als willkürlichen Textabschnitt zu betrachten.

Gut gestaltete Blöcke führen direkt zu einer besseren Abruffähigkeit.

Und eine bessere Abruffähigkeit führt in der Regel zu besseren Endantworten.

Die Beschleunigung des Prozesses

Richtigkeit war nur die eine Hälfte der Herausforderung; die Reaktionszeit war die andere.

Eine einzige RAG-Anfrage kann mehrere unterschiedliche Operationen auslösen:

User Query
   ↓
Embedding
   ↓
Vector Search
   ↓
Keyword Search
   ↓
Merge Results
   ↓
Reranking
   ↓
LLM

Das strikte Abwickeln all dieser Schritte nacheinander verlangsamt alles.

Deshalb wurden unabhängige Abrufschritte soweit wie möglich asynchron ausgeführt.

Der überarbeitete Ablauf sah ungefähr so aus:

User Query
                     ↓
              ┌──────┴──────┐
              ↓             ↓
        Vector Search   Keyword Search
              ↓             ↓
              └──────┬──────┘
                     ↓
                  Rerank
                     ↓
                    LLM

Dadurch verringerte sich das unnötige Warten zwischen Schritten, die eigentlich nicht voneinander abhängig waren.

Allein die Genauigkeit ist nicht alles für ein gutes RAG-System.

Benutzer möchten nicht untätig warten, bis eine Antwort kommt.

Die resultierende Architektur

Nach mehreren Verbesserungsrunden nahm der Ablaufprozess ungefähr diese Form an:

Medical Research Documents
                         ↓
                  Document Processing
                         ↓
                      Chunking
                         ↓
                     Embeddings
                         ↓
                   Vector Database
                         ↓
                      User Query
                         ↓
              ┌──────────┴──────────┐
              ↓                     ↓
       Semantic Search        Keyword Search
              ↓                     ↓
              └──────────┬──────────┘
                         ↓
                    Result Fusion
                         ↓
                      Reranker
                         ↓
                Relevant Context
                         ↓
                 Grounded Prompt
                         ↓
                       LLM
                         ↓
                 Final Response

Jeder Komponente in diesem Diagramm obliegt eine spezifische Aufgabe.

Diese Trennung wurde zu einer der wertvollsten Lektionen des Projekts.

Die Vektordatenbank dient nicht dazu, Fragen zu beantworten.

Der Retriever dient nicht dazu, Antworten zu generieren.

Das LLM weiß standardmäßig nicht alles.

Jeder Bestandteil übernimmt eine bestimmte Aufgabe.

Und idealerweise erledigt er diese Aufgabe gut.

Lektionen aus der Entwicklung

Die wichtigste Erkenntnis aus dieser ganzen Übung ist, dass RAG weitaus mehr bedeutet als nur das Koppeln eines LLMs mit einer Vektordatenbank. Es gibt mehrere Komponenten, und jede von ihnen erfordert Aufmerksamkeit.

Die Qualität der Informationsabrufung ist unverzichtbar

Selbst das stärkste Sprachmodell kann mangelnden Kontext nicht ausgleichen. Liefern Sie ihm schwache Ergebnisse der Informationsabrufung, erhalten Sie auch schwache Antworten. Es handelt sich dabei um ein einfaches Prinzip von „Gut kommt nur aus Gut“.

Hybride Suchverfahren sind lohnenswert

Semantische Suche ist hervorragend darin, Bedeutung und Absicht zu erfassen. Schlüsselwortsuche ist dann am besten geeignet, wenn präzise Begriffe entscheidend sind. Da die medizinische Forschung voller exakter Begriffe und spezifischer Formulierungen ist, erwies sich die Kombination beider Ansätze als richtige Entscheidung.

Reranking verdient mehr Anerkennung

Es ist eine Herausforderung, zwanzig mögliche Ergebnisse zu liefern. Diese auf die fünf besten einzuschränken, ist eine völlig eigene Herausforderung. Reranking befindet sich zwischen diesen beiden Schritten und überbrückt die Lücke.

Höhere Kontextfenster garantieren keine besseren Ergebnisse

Früher ging man davon aus, dass mehr zurückgegebener Inhalt die Ergebnisse von selbst verbessern würde. Diese Annahme hat sich nicht bewahrheitet. In der Praxis übertrafen oft fünf eng passende Abschnitte zwanzig mittelmäßige.

Ungewissheit zuzugeben, ist eine Stärke – keine Schwäche

Dies könnte die wichtigste Lektion von allen sein. Ein zuverlässiges System sollte sich nicht verpflichtet fühlen, unter allen Umständen eine Antwort zu liefern. Wenn die relevanten Informationen einfach nicht verfügbar sind, sollte das System bereit sein, dies zu sagen.

Was kommt als Nächstes?

Es gibt noch viel Raum für Verbesserungen. Bereiche, die weiter erforscht werden sollten, sind:

Stärkere Methoden zur Bewertung der Informationsauswahl
Umformulierung von Abfragen
Filtern von Metadaten
Bessere Modelle zur Neubewertung der Ergebnisse
Antworten mit Quellenangaben
Vertrauensbewertung und Logik zur Auslassung von Antworten
Bessere Übersicht über den Informationsabrufprozess
Automatisierte Bewertungssammlungen
Weitere Verbesserungen bei Caching und Latenzzeiten

Der Aufbau einer ordentlichen Bewertungspipeline hat besondere Priorität, da die manuelle Überprüfung einiger Chatbot-Ausgaben keine zuverlässige Methode zur Beurteilung der Qualität ist. Zu den Fragen, die es zu bewerten gilt, gehören, ob ursprünglich die richtigen Informationen abgerufen wurden, ob die erzeugte Antwort tatsächlich auf diesem abgerufenen Material beruht und wie häufig das System versagt, den richtigen Kontext überhaupt bereitzustellen. Solche Metriken sind weitaus wichtiger als ein subjektives Gefühl dafür, ob eine Antwort „richtig klingt“.

Zusammenfassung

Was ursprünglich als einfacher RAG-Chatbot begann, entwickelte sich zu einer viel tiefgreifenderen Lektion darüber, wie Retrieval-Systeme tatsächlich funktionieren. Die Diskussionen über KI-Anwendungen konzentrieren sich oft auf das Sprachmodell, doch in einer RAG-Struktur übernimmt die Retrieval-Pipeline im Hintergrund den größten Teil der Arbeit.

Eine minimale Konfiguration könnte so aussehen, dass Dokumente in eine Vektordatenbank und anschließend in ein LLM fließen. Eine zuverlässigere Variante sieht eher so aus, dass die Dokumente zunächst in Blöcke aufgeteilt werden, dann mithilfe einer hybriden Suche verarbeitet, neu rangiert und schließlich als fundierter Kontext dem LLM zur Verfügung gestellt werden. Selbst dieser Ablauf lässt noch Verbesserungsmöglichkeiten zu.

Das ist letztendlich das, was den Aufbau von RAG-Systemen so reizvoll macht: Es geht nicht nur darum, ein Sprachmodell dazu zu bringen, Texte zu erzeugen. Es geht darum sicherzustellen, dass dieser Text vor dem Sprechen des Modells auf den richtigen Informationen beruht.

Hinweis: Dieses Projekt dient ausschließlich zu technischen Forschungs- und Experimentierzwecken. Es ersetzt keine professionellen medizinischen Beratungen, Diagnosen oder Behandlungen.