Ich baute eine Demo, um einen berühmten KI-Fehler zu reproduzieren. Meine Baseline weigerte sich, ihn zu machen.

Der Fehler, den ich nicht provozieren konnte

Ich begann diesen Build mit dem Wunsch, einen konkreten, gut dokumentierten Fehler nachzustellen. Patienten-Matching-KI liest eine klinische Notiz als Text, und so verwechselt sie Wörter, die ähnlich aussehen, in der Medizin aber Unterschiedliches bedeuten. Das kanonische Beispiel ist klar: Eine Phase-III-Studie zu einem Antikoagulans schließt Patienten mit einer früheren Herzkatheteruntersuchung aus, in der Notiz eines Patienten steht Anlage eines zentralen Venenkatheters, ein Ähnlichkeits-Matcher sieht zwei kardiovaskuläre Katheterverfahren, bewertet sie als nah beieinander und schließt einen Patienten aus, der tatsächlich geeignet war. Veröffentlichte Evaluierungen bestätigen, dass echte Modelle genau diesen Fehler machen (Fierce Biotech, 2025). Ich wollte, dass meine Demo zeigt, wie er passiert – und dann, wie meine Engine ihn abfängt.

Also schrieb ich eine faire Baseline, die den Bösewicht spielen sollte. Entity-Level-TF-IDF-Kosinusähnlichkeit, Wort- plus Zeichen-3-bis-5-Gramme, eine echte Vektorähnlichkeitsmethode. Ich gab ihr sogar ein großzügiges Setup und kreuzvalidierte die Entscheidungsschwelle zu ihren Gunsten (stratifizierte 3-fache ROC, Youden's J, Seed 13, landet bei t = 0,6932), denn eine Strohmann-Baseline beweist nichts. Dann ließ ich den Herzkatheter-Fall laufen und wartete auf den unrechtmäßigen Ausschluss.

Er kam nicht. Die Baseline bewertete die beiden Katheterphrasen deutlich unter ihrer eigenen kreuzvalidierten Schwelle und gab geeignet zurück. Der Fehler, um den herum ich die ganze Demo gebaut hatte, ließ sich schlicht nicht reproduzieren.

Ich hatte mich daran gemacht, einen berühmten Fehler zu inszenieren, und entdeckte, dass mein ehrlicher Bösewicht zu schwach war, ihn zu begehen.

Der Grund entpuppte sich als lehrreich, und ich will präzise sein, denn man verkauft das leicht über. Eine sparsame lexikalische Baseline erzeugt genau diesen falschen Ausschluss nicht. Sie braucht dichte semantische Embeddings, um diese beiden Phrasen nah genug zusammenzuziehen, damit die Schwelle überschritten wird. Ein schwergewichtiges Embedding-Modell hätte die Demo zu etwas aufgeblasen, das man nicht mit einem Befehl offline laufen lassen kann, also traf ich eine Entscheidung: die Baseline ehrlich und sparsam halten und aufhören so zu tun, als begehe sie ein Verbrechen, das sie nicht begehen kann. Diese Entscheidung hat das gesamte Stück, das ich baue, neu organisiert. Wenn Sie es selbst ausprobieren wollen, liegt es unter veriprajna.com/de/demos/reasoning-engine-fur-die-eignungsprufung-in-klinischen-studien.

Was ist ein zentraler Venenkatheter wirklich?

Ich behielt den Herzkatheter-Fall trotzdem, denn er erwies sich als Beweis für etwas Besseres als einen ertappten Fehler. Er beweist, warum die Antwort meiner Engine überhaupt vertrauenswürdig ist. Beide Konzepte hier haben echte, überprüfbare SNOMED-CT-Kennungen. Zentralvenöse Katheterisierung ist 392230005. Herzkatheteruntersuchung ist 41976001. Sie können beides in jeden öffentlichen SNOMED-Browser einfügen und bestätigen, dass sie auf unterschiedlichen Ästen der Hierarchie sitzen. Es gibt keinen is-a-Pfad vom einen zum anderen. Ein zentraler Venenkatheter ist keine Herzkatheteruntersuchung, und das weiß nur eine Hierarchie.

Das ist die ganze These in einer einzigen Kante eines Graphen. Ein Ähnlichkeits-Score kann "is-a" nicht darstellen. Er kann nur darstellen "diese Zeichenketten sehen ähnlich aus", und ähnlich aussehen ist nicht dasselbe wie denselben Sinn zu tragen. Wenn meine Engine den Ausschluss "keine frühere Herzkatheteruntersuchung" auswertet, bewertet sie nichts. Sie stellt eine strukturelle Frage: Ist die verifizierte Tatsache des Patienten vom verbotenen Konzept subsumiert? Sie wandert durch die Ontologie, findet keinen Subsumtionspfad und meldet geeignet – mit einer dreistufigen Trace, die beide Konzept-IDs und die geprüfte Graphkante nennt.

Als ich diese Trace zum ersten Mal gerendert sah, war es nicht das Urteil, das mich traf. Es war die Quittung darunter. Die Box der Baseline auf demselben Bildschirm zeigt eine Ähnlichkeitszahl ohne Provenienz und ohne Reproduzierbarkeit. Die Box meiner Engine nennt die beiden SCTIDs und die genaue is-a-Frage, die sie gestellt hat. Die eine kann ein Regulator zu den Akten legen. Die andere ist eine Zahl mit einem Achselzucken. Dieser Kontrast – nicht ein ertappter Fehler – ist das, was der Herzkatheter-Fall tatsächlich einbringt.

Der Patient, den der Matcher tatsächlich verwarf

Ich brauchte trotzdem einen wirklich verlorenen Patienten, also suchte ich, wo meine ehrliche Baseline echt scheitert, und fand es in einem Wort: nicht. Die synthetische Heldenakte P-074 trägt die Notizzeile "No evidence of diabetes." Einer der Ausschlüsse des Onkologieprotokolls lautet "keine Diagnose Diabetes mellitus." Die Vektor-Baseline sieht das Token "diabetes" direkt neben dem "diabetes" des Kriteriums und bewertet sie mit Ähnlichkeit 1,0. Ein perfekter Score. Sie hat kein Modell von Negation, also liest sie einen Satz, der Diabetes ausschließt, so als hätte er Diabetes eingeschlossen, und sie schließt einen Patienten aus, der geeignet war.

Das ist der Patient, den der Matcher verwirft, und das ist der Beat, den ich ursprünglich vom Herzkatheter-Fall erwartet hatte. Negation ist der Ort, an dem eine sparsame Baseline ehrlich bricht – an ihrer eigenen besten Schwelle, ohne Manipulation.

Ich denke immer wieder darüber nach, wie leise dieser Fehler ist. Keine Fehlermeldung, kein Low-Confidence-Flag, kein Signal, dass etwas schiefging. Der Score ist 1,0 – der höchstmögliche, so sicher, wie das System jemals sein kann. Die Baseline ist nie sicherer als in genau dem Moment, in dem sie am meisten falschliegt. Ein Koordinator, der eine Warteschlange solcher Fälle prüft, hat keine Chance zu wissen, dass genau dieser perfekte Match ein Patient ist, der hätte eingeschlossen werden sollen. Multiplizieren Sie das über ein Protokoll hinweg, und Sie verstehen, warum 80 % der Studien ihre Rekrutierungsfristen verfehlen (Branchenkonsens, 2025) und warum jeder Screening-Fehlschlag im Schnitt etwa 1.200 $ kostet (Antidote.me, 2025).

Die Baseline war nie sicherer als in genau dem Moment, in dem sie am meisten falschlag. Das ist kein Bug, den man wegtunen kann. Es ist ein Kategorienfehler.

Warum lebt das Urteil außerhalb des Modells?

Ich traf früh eine architektonische Entscheidung, die ich heute für die einzige halte, die zählte: das Sprachmodell ganz vom Urteil fernzuhalten. Es gibt genau einen probabilistischen Schritt in der gesamten Pipeline. Ein Provider-austauschbares Modell, nur beratend, liest den chaotischen Fließtext und schlägt Kandidaten-Fakten vor – jeder mit dem wörtlichen Span, aus dem er den Fakt gelesen hat, und einer Kandidaten-Konzept-ID aus einem kleinen geschlossenen Vokabular. Das ist das eine, worin ein Modell wirklich gut ist: Lesen. Es bekommt keine Stimme darüber, wer geeignet ist.

Alles danach ist deterministischer Code, den ich auditieren kann. Bevor ein vorgeschlagener Fakt eine Entscheidung erreicht, stellt ein adversarieller Verifier ihn gegen die wörtliche Notiz mit drei Prüfungen in Frage: Ist der Span tatsächlich vorhanden, ist er negiert, und ist das Subjekt der Patient und nicht ein Familienmitglied. Der Fakt "No evidence of diabetes" scheitert an der Negationsprüfung und erreicht die Engine nie. In derselben Akte scheitert "Family history of breast cancer" an der Subjektprüfung, weil diese Vorgeschichte zu einem Familienmitglied und nicht zum Patienten gehört, und er wird als REJECTED markiert – mit der gescheiterten Prüfung benannt.

Über den gesamten Gold-Set hinweg hat dieser Verifier 7 Faktinstanzen, 3 verschiedene schlechte Fakten verworfen (eine negierte Diabetes-Erwähnung, eine Familienanamnese-Zuschreibung Brustkrebs und ein eingepflanztes halluziniertes Medikament ohne unterstützenden Span), verteilt über 4 der 13 bewerteten Fallläufe – alle, bevor sie ein Urteil berühren konnten. Wenn Leute mich fragen "wie vertraue ich dem, was der Agent aus meinen Notizen gezogen hat", ist dieses Panel die ganze Antwort. Ich bitte Sie nicht, ihm zu vertrauen. Ich zeige Ihnen, was er vorgeschlagen hat, was rausgeflogen ist und warum.

Dann ist das Urteil selbst schlichtes Python außerhalb des Agent-Frameworks: eine deontische Logik-Engine, die Verbote, temporale Ausnahmen und Anforderungen über die Ontologie und etwas Datumsarithmetik auswertet. Ein Modell kann dieses Gate nicht überstimmen, denn das Modell ist nicht im Raum, wenn das Gate läuft. Das ist auch, was die Engine reproduzierbar macht. Wenn die Logik deterministischer Code über einer festen Ontologie ist, erzeugt ein erneuter Lauf derselben Akte dieselbe Antwort – Byte für Byte, jedes einzelne Mal.

Das Modell liest. Es stimmt nicht ab. Diese eine Grenze ist es, die einen erneuten Lauf byte-identisch macht.

Die einzige Zahl, die meinem Clinical-Ops-Leser wichtig war

Ich verbrachte Wochen damit, Metriken zu optimieren, über die – das gab ich mir schließlich zu – der Käufer nachts nicht wachliegt. Entscheidungsgenauigkeit ist eine Leaderboard-Zahl. Die Person, die bei einem Sponsor oder einer CRO die Machbarkeit verantwortet, vergleicht keine Leaderboard-Scores. Sie sieht, wie ein Rekrutierungszeitplan verrutscht, und jeder Tag Verrutschen ist teuer. Der Tufts-CSDD-Impact-Report (2024) setzt die Kosten einer Rekrutierungsverzögerung auf grob 800.000 $ pro Tag an entgangenen Verschreibungsumsätzen an, und höher in den therapeutischen Gebieten, die diese Demo berührt: etwa 840.000 $ am Tag in der Onkologie und 1,4 Mio. $ am Tag im kardiovaskulären Bereich. Die Protokollkomplexität ist seit 2005 um 139 % bei Studienprozeduren gestiegen (IQVIA, 2026), was mehr Kriterien, mehr Klauseln und mehr Stellen bedeutet, an denen ein Text-Matcher einen falsch machen kann.

Also hörte ich auf, mit Genauigkeit zu führen, und begann mit der Zahl zu führen, die diesen Schmerz wirklich abbildet: geeignete Patienten, die Sie nicht verloren haben. Auf einem festen, gelabelten Gold-Set von 13 Fällen aus 7 synthetischen Patienten über 2 synthetische Protokolle verliert meine Engine 0 geeignete Patienten. Die faire Baseline verliert 3. Dasselbe Set, dieselbe Schwelle, zu Gunsten der Baseline kreuzvalidiert.

Ich will genau sagen, was diese Zahlen sind und was nicht. Sie sind der eigene Output des Harness auf diesem einen festen 13-Fälle-Set, kein Open-World-Versprechen. Die 100 % bedeuten "100 % auf diesem Gold-Set", nie "immer richtig". Ich werde Ihnen nicht sagen, TrialProof sei nie falsch, denn dafür habe ich die Daten nicht, und ich würde niemandem glauben, der das behauptet. Was ich sagen kann, ist enger und, finde ich, nützlicher: Auf diesem Set verliert die Engine null geeignete Patienten, jede Entscheidung trägt eine reproduzierbare Trace, zwei Entscheidungen haben sicher mit NEEDS-REVIEW abstiniert, als ein erforderliches Labor oder Vitalzeichen fehlte, statt zu raten, und der erneute Lauf des gesamten Sets war byte-identisch, 13 von 13. Alle Patienten, Notizen und Protokolle sind synthetische Fixtures, nirgends echte Akten. Sie können jeden dieser Läufe unter veriprajna.com/de/demos/reasoning-engine-fur-die-eignungsprufung-in-klinischen-studien ansehen.

Die Zahl, die mir wichtig ist, ist nicht Genauigkeit. Es sind die geeigneten Patienten, die ich nicht verworfen habe. Auf diesem Set sind das null Verluste gegen die drei der Baseline.

Es gibt auch eine regulatorische Form dazu, und ich werde sie sorgfältig benennen. Die Clinical-Decision-Support-Guidance der FDA vom Januar 2026 ist der relevante Rahmen für eine Human-in-the-Loop-Matching-Hilfe wie diese. Jede Entscheidung, die die Engine ausgibt, kann als CDISC-SDTM-IE-Datensatz exportiert werden – eine Zeile pro Patient und Kriterium, mit Urteil, Reasoning-Trace, Konzept-IDs und deontischer Operation. Das ist keine Zulassung, und ich behaupte keine. Es ist Ausrichtung und Richtung. Aber es bedeutet: Die Trace ist keine Debugging-Bequemlichkeit. Sie ist ein aktenfähiges Artefakt, und sie existiert konstruktionsbedingt bei jeder Entscheidung, nicht als Nachgedanke.

Worauf ich immer wieder zurückkomme

Ich kehre immer wieder zu dem Moment zurück, in dem mein Bösewicht seine Rolle verweigerte, denn er hat die Frage verändert, die ich stellte. Seit drei Jahren fragt das Feld, wie man das Modell besser darin macht zu entscheiden, wer geeignet ist. Bessere Prompts, größerer Kontext, mehr Retrieval – alles darauf ausgerichtet, ein probabilistisches System vertrauenswürdig genug zu machen, über die Einschreibung eines Patienten zu urteilen. Den ersten Abschnitt dieses Builds verbrachte ich auch in diesem Framing und versuchte, ein Modell bei einem Fehler zu ertappen, damit ich das Modell reparieren konnte.

Was schließlich klickte, war, dass es die falsche Schicht war. Ein Ähnlichkeits-Score kann "is-a" nicht darstellen, kann "nicht" nicht darstellen und kann "es sei denn, die Therapie wurde mehr als zwölf Monate vor der Randomisierung abgeschlossen" nicht darstellen. Kein noch so großes Prompting fügt das hinzu, denn das sind keine Sprachprobleme. Es sind Logikprobleme. Der souveräne Zug ist also nicht, das Modell vertrauenswürdig zu machen. Es ist, Vertrauen überflüssig zu machen. Lassen Sie das Modell das eine tun, worin es gut ist: Fließtext lesen und Fakten mit dem Span vorschlagen, aus dem es sie gelesen hat. Dann lassen Sie einen Verifier wegwerfen, was die Notiz nicht stützt, und lassen Sie schlichten, auditierbaren Code über einer medizinischen Ontologie das Urteil berechnen.

Eignung sollte berechnet, nicht vorhergesagt werden. Was ich am Anfang nicht erwartet hatte: Der Payoff würde sich gar nicht wie ein Benchmark anfühlen. Er fühlt sich wie eine Quittung an. Dieselbe Akte gibt jedes Mal dieselbe Antwort, die Antwort nennt die Konzept-ID und die Graphkante, die sie entschieden hat, und die Zahl, über die ein Feasibility-Lead tatsächlich nachts nicht schläft, geht auf null verworfene geeignete Patienten.

Und wenn Sie es lieber ansehen als von mir beschreiben lassen: Hier läuft das Ganze von Ende zu Ende.

Also hier ist die Frage, die ich nicht aufhöre zu wälzen, und ich würde wirklich gerne wissen, wie Sie sie beantworten. Wenn die Einsätze die Chance eines realen Menschen auf eine Studie sind – wo wollen Sie Ihr Vertrauen ansiedeln: in einem Modell, das Sie glauben müssen, oder in Code, den Sie lesen können?