Token Maxxing ist eine schlechte Angewohnheit — und Biotechs Datenstrukturen machen sie teuer

Es gibt eine bestimmte Gewohnheit, die ich immer wieder bei Teams beobachte, die früh und begeistert große Sprachmodelle eingeführt haben: Sobald eine Aufgabe viele Daten betrifft, lautet der Reflex, so viel wie möglich davon ins Kontextfenster zu kopieren und das Modell den Rest erledigen zu lassen. Kontextfenster sind von wenigen tausend Tokens auf Hunderttausende, teils Millionen gewachsen, und das Marketing rund um dieses Wachstum hat still und leise ein mentales Modell gefördert, in dem ein größeres Fenster bedeutet, dass man sich keine Gedanken mehr über Datenarchitektur machen muss — man schüttet einfach alles hinein.

Ich habe angefangen, das „Token Maxxing" zu nennen, und ich halte es für angebracht, es als schlechte Praxis zu behandeln statt als cleveren Umgang mit einer neuen Fähigkeit. Überall ist es eine schlechte Praxis. In der Biotech, wo die zugrunde liegenden Datenstrukturen groß, dicht und oft entscheidungsrelevant sind, ist es eine schlechte Praxis mit realen Kosten.

Warum „das Modell hatte alle meine Daten" ein falsches Sicherheitsgefühl ist

Aufmerksamkeit verschlechtert sich über lange Kontexte hinweg — und das ungleichmäßig. Unabhängige Auswertungen der Long-Context-Performance — allen voran die „Needle in a Haystack"-Testfamilie — haben durchgängig gezeigt, dass Modelle Informationen am Anfang oder Ende eines langen Kontexts zuverlässiger abrufen und verarbeiten als Informationen, die in der Mitte vergraben sind. Das ist kein Randbefund; er wurde über verschiedene Modellfamilien und Kontextlängen hinweg reproduziert. Ein Modell, das Ihren 200-seitigen Validierungsbericht „im Kontext hat", hat ihn nicht zwangsläufig so gelesen, wie es ein menschlicher Prüfer tun würde. Es hat ihn auf eine Weise verarbeitet, die systematisch manche Teile gegenüber anderen bevorzugt — und die vernachlässigten Teile sind nicht die, die Sie ausgewählt haben, sondern die, an denen das Aufmerksamkeitsmuster der Architektur zufällig an Auflösung verliert.

Ein großes Kontextfenster ist keine Datenbank — es so zu behandeln erzeugt eine bestimmte Art von Selbstüberschätzung. Eine relationale Datenbank oder ein zweckgebundenes Retrieval-System liefert genau die Datensätze, die einer Abfrage entsprechen, mit einer Garantie darüber, was einbezogen wurde und was nicht. Ein Modell, das über ein vollgestopftes Kontextfenster räsoniert, liefert eine Antwort, die umfassend wirkt, weil es Zugriff auf alles hatte — bietet aber keine solche Garantie darüber, was es tatsächlich gewichtet, bemerkt oder stillschweigend verworfen hat. Der Output sieht in beiden Fällen gleich aus — selbstbewusst, flüssig, spezifisch —, was bedeutet, dass der Fehler unsichtbar bleibt, bis ihm etwas Nachgelagertes widerspricht.

Die Kosten skalieren auf eine Weise, die genau bei dem Volumen bestraft, in dem Biotech operiert. Genomische, proteomische und Hochdurchsatz-Screening-Datensätze sind nicht bescheiden dimensioniert. Ein einzelner NGS-Lauf, eine plattenbasierte Screening-Kampagne oder ein longitudinales Patientenregister erzeugt leicht Datenmengen, bei denen „einfach alles reinkopieren" bedeutet, in Tokens und Latenz für einen Brute-Force-Durchgang durch Daten zu bezahlen, die eine gezielte Abfrage zu einem Bruchteil der Kosten gelöst hätte. Teams, die diese Gewohnheit mit wachsendem Datenvolumen hochskalieren, skalieren eine Ineffizienz — keine Fähigkeit.

Warum das eine spezifische Bedrohung für frühe Anwender in der Biotech ist

Frühe KI-Anwender bewegen sich per Definition schneller, als die Governance ihrer Organisation nachziehen kann. Das ist in der frühen Phase der Einführung einer Fähigkeit grundsätzlich ein vertretbarer Kompromiss — aber Token Maxxing verschärft ihn auf eine Weise, die leicht zu übersehen ist, bis der Schaden strukturell wird.

Es entfernt Nachvollziehbarkeit genau in dem Moment, in dem sie am wichtigsten ist. Wenn der Output eines Modells eine Interpretation, eine Go/No-Go-Entscheidung oder einen Berichtsabschnitt beeinflusst hat, braucht die Frage „worauf genau stützte sich das" eine belastbare Antwort. Eine gezielte Retrieval-Pipeline kann Ihnen genau die Datensätze zeigen, die an das Modell übergeben wurden, und sie zitieren. Ein vollgestopftes Kontextfenster kann das nicht — die ehrliche Antwort auf „worauf hat das Modell tatsächlich geachtet" lautet „wir wissen es nicht vollständig", und dieser Satz übersteht kein Audit, keine Due-Diligence-Prüfung und keinen ernsthaften internen Einwand gegen eine wissenschaftliche Schlussfolgerung.

Es erzeugt das falsche Gefühl, dass Datenarchitekturarbeit nicht mehr nötig ist. Das wirklich wertvolle KI-Adoptionsmuster in der Biotech-F&E — eine richtige Retrieval-Schicht über die eigene Literatur und internen Daten bauen, Assay-Metadaten so strukturieren, dass sie abfragbar sind, definieren, was „relevanter Kontext" für eine gegebene Frage bedeutet, bevor man sie stellt — erfordert echten technischen Aufwand. Token Maxxing fühlt sich an, als liefere es dasselbe Ergebnis ohne diesen Aufwand — bis der Datensatz über den Punkt hinauswächst, an dem die Illusion trägt, oder eine subtil falsche Antwort in etwas Wichtiges einfließt. Teams, die die Architekturarbeit überspringen, weil ein größeres Kontextfenster sie optional erscheinen ließ, bauen auf einem Fundament, das nicht mit dem eigenen Datenwachstum mitskaliert.

Es tarnt eine Skalierungsklippe als Skalierungskurve. Die Performance bei vollgestopften Kontextaufgaben verschlechtert sich allmählich und fällt dann steil ab, sobald das Datenvolumen die Schwelle überschreitet, ab der die effektive Aufmerksamkeitsspanne des Modells nicht mehr gut abdeckt — und diese Schwelle wird für einen gegebenen Anwendungsfall weder angekündigt noch getestet noch im Voraus vorhersagbar. Eine Organisation, die durch Token Maxxing bei wachsendem Datensatz „gut genug" wirkende Ergebnisse erhalten hat, hat kein Frühwarnsystem dafür, wann das nicht mehr zutrifft. Der Ausfall zeigt sich als schlechte Entscheidung, nicht als saubere Fehlermeldung.

Wie die Alternative tatsächlich aussieht

Nichts davon ist ein Argument gegen große Kontextfenster — sie sind echt nützlich, insbesondere um Gesprächszustände zu halten oder über eine begrenzte, gut kuratierte Dokumentenmenge zu räsonieren. Das Argument richtet sich gegen Context Stuffing als Ersatz für Datenarchitektur. Die Teams, die nachhaltigen Nutzen aus KI in der Biotech-F&E ziehen, leisten die weniger glamouröse Arbeit: Retrieval-Systeme, die genau die für eine Abfrage relevanten Datensätze abrufen, strukturierte Metadaten, die Assay- und Probendaten abfragbar machen statt ein Modell zu zwingen, sie jedes Mal neu zu parsen, und eine klare Definition dessen, welchen „Kontext" eine gegebene Frage tatsächlich braucht, bevor man zum größten verfügbaren Fenster greift.

Dieser Ansatz ist langsamer aufzusetzen und in einer Demo weniger beeindruckend. Er ist aber auch der einzige, der weiter funktioniert, während der Datensatz — und das, was von einer richtigen Antwort abhängt — weiter wächst.

---

Wenn die KI-Workflows Ihres Teams dadurch gewachsen sind, dass mehr in den Prompt gepackt wurde, statt die darunterliegende Datenschicht zu bauen, ist das ein Skalierungsproblem, das mit jedem Tag Wartezeit teurer wird, es zu beheben. Ich helfe Life-Science-Organisationen, KI-Adoption auf einer Infrastruktur aufzubauen, die tatsächlich skaliert — sprechen Sie mich gerne an, wenn Ihnen das bekannt vorkommt.