Google hat die Funktion What People Suggest für medizinische Anfragen stillschweigend zurückgezogen. Die offizielle Begründung lautet „Qualität der Antworten“. Aber dahinter steckt ein konkretes architektonisches Problem: Das Retrieval-System zog semantisch ähnliche, aber klinisch inkompatible Fragmente – und das Modell synthetisierte daraus technisch fundierte, aber gefährliche Antworten.
Hauptthese: Es geht hier nicht um Medizin und nicht um die Verantwortung von Unternehmen. Es ist ein öffentlicher Fall dafür, wie die RAG-Architektur scheitert, wenn der Datenbestand die Anforderungen der Aufgabe nicht erfüllt. Die Lektion ist auf jeden Pipeline anwendbar – vom Rechts-Bot bis zur Unternehmenssuche.
Warum die Aggregation von Nutzermeinungen keine gültige Stichprobe ist
Die Funktion What People Suggest basierte auf einer logischen, aber fehlerhaften Prämisse: Wenn genügend Menschen eine ähnliche Erfahrung beschreiben, nähert sich das aggregierte Ergebnis der Wahrheit an. In der Medizin bricht dieses Modell auf der Ebene der Stichprobe selbst zusammen.
Für Restaurantempfehlungen oder Hotelbewertungen funktioniert die Aggregation – die Stichprobe ist groß genug und repräsentativ. Ein medizinisches Forum ist eine andere Population. Hier kommen Menschen mit atypischem Krankheitsverlauf, unzufrieden mit der Standardbehandlung, oder diejenigen, die eine Bestätigung für eine bereits getroffene Entscheidung suchen.
Validierungsverzerrung als strukturelle Eigenschaft von UGC-Plattformen
Plattformen wie Reddit oder Quora haben eine eingebaute Validierungsverzerrung: Diejenigen, die etwas zu sagen haben – also diejenigen, deren Erfahrungen vom Normalen abweichen – veröffentlichen. Eine Person, die Ibuprofen eingenommen hat und sich nach einem Tag besser fühlt, schreibt keinen Beitrag. Eine Person, die eine ungewöhnliche Reaktion hatte – schreibt.
Das ist kein Problem spezifischer Plattformen – es ist eine mathematische Eigenschaft jedes freiwilligen Inhalts. Forscher nennen dies Survivor Bias in umgekehrter Richtung: In der Stichprobe dominieren Extremfälle, nicht typische Fälle.
Wie die UGC-Verteilung in der Praxis aussieht
Stellen Sie sich ein hypothetisches medizinisches Forum mit 10.000 Beiträgen über Nebenwirkungen von Ibuprofen vor. Davon beschreiben 8.500 ungewöhnliche oder negative Reaktionen – genau deshalb kamen die Leute, um eine Antwort zu suchen oder Erfahrungen auszutauschen. Weitere 1.200 sind Anfragen wie „Ist es normal, dass…“. Und nur 300 Beiträge im Stil von „genommen, geholfen, danke“ – denn diese Person hatte keinen Grund mehr, ins Forum zurückzukehren.
Nun indiziert das RAG-System diesen Korpus und erhält eine Anfrage: „Ist Ibuprofen sicher?“ Die Ähnlichkeitssuche findet die 20 relevantesten Chunks. 17 davon beschreiben Komplikationen. Nicht, weil Ibuprofen gefährlich ist – sondern weil sichere Fälle im Korpus einfach unterrepräsentiert sind.
Medizinisches Forum vs. Klinische Studie: Unterschied in der Stichprobe
Eine klinische Studie basiert auf einer kontrollierten Stichprobe: definierte Population, Randomisierung, Kontrollgruppe. Das Ergebnis spiegelt die Verteilung in der realen Patientenpopulation wider.
Ein medizinisches UGC-Forum ist das Gegenteil:
- Stichprobe nicht randomisiert – diejenigen kommen, die etwas zu sagen haben
- Keine Kontrollgruppe – keine Stimme derer, bei denen „alles normal verlief“
- Bestätigungsverzerrung verstärkt das Signal – Beiträge mit ungewöhnlichen Erfahrungen erhalten mehr Antworten und Upvotes, steigen höher, landen in mehr Chunks
- Zeitliche Verschiebung – ältere Beiträge mit veralteten Behandlungsprotokollen sind semantisch gleichwertig mit neuen
Für einen Entwickler, der RAG baut, bedeutet das eines: Wenn der Korpus aus UGC besteht, entspricht die Verteilung der Meinungen darin nicht der realen Verteilung der Fälle in der Population. Das Modell lernt von den Rändern, nicht vom Zentrum der Verteilung.
Analogie für Entwickler
Stellen Sie sich vor, Ihre Empfehlungsmaschine lernt nur aus 1-Sterne- und 5-Sterne-Bewertungen – 3-Sterne-Bewertungen gibt es fast keine im Korpus. Das Modell wird sicher empfehlen oder ablehnen, wird aber kein Verständnis für „normal“ haben.
Machen Sie nun einen Schritt weiter: Stellen Sie sich vor, 1-Sterne-Bewertungen erhalten 10-mal mehr Likes und Kommentare als 5-Sterne-Bewertungen – und dominieren deshalb in den Suchergebnissen. Das System „kennt das Normale“ nicht nur nicht – es ist aktiv auf Anomalien trainiert. Genau das passiert, wenn ein RAG-System Forum-UGC als Hauptquelle für medizinische oder andere YMYL-Anfragen verwendet.
Das Prinzip Garbage In, Garbage Out verschwindet nicht mit der Erhöhung der Modellparameter. Eine komplexere Architektur synthetisiert eine verzerrte Stichprobe überzeugender – macht sie aber nicht repräsentativ.
Wo genau RAG versagt: Chunk-Kollision und Verlust des klinischen Kontexts
Retrieval-Augmented Generation ist eine Architektur, bei der ein Modell zuerst relevante Fragmente aus einem Korpus abruft und dann eine Antwort auf deren Grundlage synthetisiert. Der Ausfallpunkt ist nicht die Generierung. Der Ausfallpunkt ist das Retrieval.
Zerlegen wir das anhand eines konkreten Beispiels. Ein Benutzer gibt eine Anfrage ein: „Diät bei Bauchspeicheldrüsenkrebs“.
Schrittweiser Ausfallmechanismus
- Embedding. Die Anfrage wird in einen Vektor im semantischen Raum umgewandelt.
- Ähnlichkeitssuche. Das System sucht nach Chunks mit der höchsten Kosinus-Ähnlichkeit. „Nähe“ wird durch statistische Wortähnlichkeit bestimmt – nicht durch klinischen Kontext.
- Chunk-Kollision. Zwei Fragmente gelangen in das Kontextfenster: eines über „fettarme Diät bei Pankreatitis“, das andere über „Ernährung während der Chemotherapie“. Beide sind semantisch nah an der Anfrage. Beide sind klinisch in diesem Kontext unvereinbar.
- Synthese. Das Modell formuliert eine Antwort, die technisch durch die Quellen begründet ist, aber klinisch falsch ist: Die Ernährungsprotokolle während der Chemotherapie unterscheiden sich grundlegend von den allgemeinen Empfehlungen bei Erkrankungen der Bauchspeicheldrüse.
Wie das auf der Ebene der Retrieval-Anfrage aussieht
Um den spezifischen Ausfall zu verstehen, schauen wir uns an, was das System tatsächlich „sieht“. Ein vereinfachtes Beispiel für ein Retrieval-Ergebnis für die Anfrage „Diät bei Bauchspeicheldrüsenkrebs“:
Query: "Diät bei Bauchspeicheldrüsenkrebs"
Retrieved chunks (top-3 by cosine similarity):
[chunk_id: 4821] score: 0.91
source: forum_post, date: 2021-08
"Bei Pankreatitis empfehlen Ärzte eine fettarme Diät –
nicht mehr als 40g Fett pro Tag. Die Bauchspeicheldrüse kann Fett nicht gut verarbeiten, daher ist die Einschränkung kritisch..."
[chunk_id: 2203] score: 0.88
source: health_blog, date: 2022-03
"Während der Chemotherapie ist es wichtig, die Kalorienzufuhr aufrechtzuerhalten.
Patienten wird oft eine kalorienreiche Ernährung empfohlen,
einschließlich Fetten – um das Körpergewicht zu erhalten..."
[chunk_id: 7734] score: 0.85
source: forum_post, date: 2020-11
"Nach einer Bauchspeicheldrüsenresektion ändert sich die Diät radikal.
In den ersten Monaten – minimal Fett, dann schrittweise Erweiterung..."
Das Modell erhält drei Chunks mit einer Kosinus-Ähnlichkeit von 0,85–0,91 – alle „relevant“ nach Metrik. Aber Chunk 4821 beschreibt chronische Pankreatitis, Chunk 2203 – Krebs unter Chemotherapie, Chunk 7734 – postoperativen Zustand. Das sind drei verschiedene klinische Kontexte mit gegensätzlichen Empfehlungen bezüglich Fetten.
Das System hat keinen Mechanismus, sie zu unterscheiden – und synthetisiert eine „ausgewogene“ Antwort aus widersprüchlichen Quellen.
Warum Kosinus-Ähnlichkeit den klinischen Kontext nicht erkennt
Kosinus-Ähnlichkeit misst den Winkel zwischen zwei Vektoren in einem mehrdimensionalen Raum. Je kleiner der Winkel – desto „näher“ die Dokumente. Aber was genau wird in diesem Raum kodiert?
Das Embedding-Modell lernt, Wörter aus dem Kontext vorherzusagen (oder umgekehrt). Es lernt, dass „Bauchspeicheldrüse“, „Diät“, „Fette“, „Chemotherapie“, „Pankreatitis“ – semantisch verwandte Wörter sind. Daher erhalten Dokumente, die diese Wörter enthalten, nahe Vektoren.
Aber das Embedding versteht nicht, dass „Fette einschränken“ und „Kalorienzufuhr durch Fette erhöhen“ – entgegengesetzte medizinische Anweisungen für verschiedene Zustände desselben Organs sind. Für den Vektor sind das nur zwei Dokumente über die Bauchspeicheldrüse und die Diät.
Mehr über die Grenzen von Embedding-Modellen bei domänenspezifischen Aufgaben – in der Studie RAGAS (2023).
Visuelle Darstellung: Was im Kontextfenster passiert
Benutzeranfrage
│
▼
┌───────────────────┐
│ Embedding model │ → Anfragevektor
└───────────────────┘
│
▼
┌───────────────────┐
│ Vector store │ Ähnlichkeitssuche
│ (gesamter Korpus) │ → Top-K Chunks
└───────────────────┘
│
├── Chunk A: Pankreatitis + fettarme Diät (Score: 0.91)
├── Chunk B: Chemotherapie + kalorienreich (Score: 0.88) ← KOLLISION
└── Chunk C: Postoperativer Zustand (Score: 0.85)
│
▼
┌───────────────────┐
│ LLM │ synthetisiert Antwort aus A + B + C
│ (Generierung) │ ← Modell „weiß nicht“, dass A und B unvereinbar sind
└───────────────────┘
│
▼
Antwort technisch
durch Quellen begründet,
aber klinisch falsch
Warum das gerade in YMYL-Nischen passiert
Google definiert YMYL (Your Money or Your Life) als eine Kategorie von Anfragen, bei denen eine falsche Antwort echten Schaden verursachen kann. Medizin, Recht, Finanzen. Detailliert, wie YMYL-Nischen aus SEO-Sicht funktionieren, haben wir in einem separaten Artikel behandelt – YMYL-Nischen: Vollständige Anleitung für SEO. Im Kontext der RAG-Architektur ist das Problem der Chunk-Kollision in diesen Nischen aus zwei Gründen am kritischsten:
- Hohe Domänenspezifität. Medizinische Begriffe haben enge Bedeutungen, die der allgemeine Embedding-Raum nicht unterscheiden kann. „Pankreatitis“ und „Bauchspeicheldrüsenkrebs“ – für das Modell sind es verwandte Themen, für den Kliniker – prinzipiell unterschiedliche Pathologien mit unterschiedlichen Protokollen.
- Fehlerkosten sind unverhältnismäßig. Eine ungenaue Restaurantempfehlung – ein schlechtes Mittagessen. Eine ungenaue medizinische Empfehlung kann schwerwiegendere Folgen haben.
Mehr über YMYL-Kriterien im Kontext der Suchqualitätsbewertung – in den Search Quality Rater Guidelines von Google.
