Vom Langtext zu Prädiktoren: LLM-BlockFE betreibt Feature Engineering per Programmsuche

Industrielle Risikokontrollsysteme laufen aus gutem Grund auf Modellen für strukturierte Daten: Sie sind schnell, im Betrieb günstig, leicht zu überwachen und passen in die Freigabe- und Prüfketten der regulierten Finanzwelt. Dennoch steckt ein großer Teil der wertvollen Information außerhalb dieser Tabellen, versteckt in langen unstrukturierten Texten wie Antragsbeschreibungen, Kommunikationsprotokollen und freien Schilderungen. Um sie nutzbar zu machen, verließ man sich lange auf manuelles Feature Engineering: Fachleute schreiben Regeln und Extraktionsskripte, testen sie und beginnen von vorn. Das ist langsam, und die Abdeckung hängt davon ab, woran die Fachleute denken. Die naheliegende Alternative, jeden eingehenden Langtext zur Inferenzzeit einem großen Sprachmodell (LLM) vorzulegen, scheitert in Echtzeit-Pipelines häufig an Latenz, Durchsatz, Kosten und Stabilität. Ein am 8. Oktober 2026 auf arXiv veröffentlichter Beitrag, „Long Text to Predictive Features“, schlägt mit LLM-BlockFE einen dritten Weg vor.

Der Kerngedanke lässt sich in einem Satz sagen: Das LLM arbeitet nur offline, und seine Ausgabe ist kein Vorhersagewert, sondern ein ausführbares Programm. LLM-BlockFE baut ein Feature-Programm auf, indem es Codeblöcke nacheinander anhängt, und jeder Block ist nach dem Schreiben unveränderlich. Nach jedem Anhängen bewertet ein nachgelagertes Modell die neu entstandenen Kandidatenmerkmale. Die Suche folgt damit einem gemessenen Vorhersagegewinn und nicht der Selbsteinschätzung des LLM. Ist die Suche beendet, werden die Programme eingefroren und ausgerollt. Sie ziehen strukturierte Merkmale aus dem Langtext, und das bestehende Folgemodell verarbeitet sie wie gewohnt. Online fällt kein einziger LLM-Aufruf an. Die teure Intelligenz wird einmal während der Suche bezahlt und dann auf alle späteren Anfragen verteilt. Das LLM wechselt von der Rolle der Inferenzmaschine in die eines Feature-Ingenieurs, und der Produktionspfad bleibt so günstig und berechenbar wie zuvor.

Schwierig ist die Suche selbst. Programme wachsen Block für Block, und die übliche Greedy-Suche behält, was im aktuellen Schritt am besten aussieht. Das ist hier anfällig: Ein früher Block kann nützlich wirken und doch alle späteren Blöcke in eine schlechte Region lenken, ohne dass das Verfahren umkehren kann. Die Autoren führen deshalb einen Rollback-Mechanismus auf Blockebene ein, gesteuert durch eine tiefenkalibrierte Zuweisung von Credit. Die Intuition: Der Endgewinn eines Programms verteilt sich nicht gleichmäßig auf seine Blöcke. Frühe Blöcke prägen alles Folgende, und eine naive Zuweisung beurteilt sie falsch. Die Kalibrierung nach Tiefe soll diese Verzerrung ausgleichen, damit das System den eigentlichen Verursacher einer Verschlechterung erkennt und das Programm unmittelbar davor zurücksetzt. Die Kurzfassung nennt den Mechanismus und seinen Zweck, nicht aber Kalibrierungsformel oder Schwellenwerte. Diese gehören in den Volltext und sollten nicht geraten werden.

Die zweite Entwurfsentscheidung betrifft die Skalierung. LLM-BlockFE treibt mehrere unabhängige Suchtrajektorien verschränkt voran. Mehrere Trajektorien senken das Risiko, dass ein einzelner unglücklicher Pfad das Ergebnis bestimmt. Eine naive Umsetzung verschwendet jedoch Budget, weil jede Trajektorie dieselben Ideen neu entdecken kann. Der Beitrag verringert diese Redundanz, indem die Trajektorien eine feste Beschreibung der jeweiligen Explorationsrichtung teilen. Jede sieht, wohin die anderen laufen, und der Aufwand verteilt sich, statt sich zu stapeln. Ein kurzer, stabiler Text dient so als Koordinationssignal. Das zählt, denn jeder LLM-Aufruf kostet Geld, und eine wiederholte Erkundung ist ein Aufruf ohne neuen Erkenntnisgewinn. Der Rollback löst das vertikale Problem, auf einem schlechten Pfad festzuhängen. Das Verschränken mit geteilten Beschreibungen löst das horizontale Problem sich überschneidender Pfade. Zusammen ergeben sie eine recht vollständige Suchdisziplin für einen Raum, in dem jede Bewertung teuer ist.

Die berichteten Ergebnisse umfassen zwei öffentliche und zwei private Datensätze. Im Vergleich auf den vollständigen Datensätzen verbessert LLM-BlockFE die AUC absolut um 0,0069 bis 0,0358 gegenüber der jeweils stärksten Baseline. Aussagekräftiger ist der Praxisbeleg: In fünf produktiven Anwendungen der Finanzrisikokontrolle zeigt das Monitoring nach dem Start absolute KS-Verbesserungen von 0,02 bis 1,56 Prozentpunkten gegenüber der bisherigen manuell entworfenen Strategie. Bei Kredit- und Betrugsmodellen schlagen kleine Gewinne an Trennschärfe in echten Unterschieden bei Verlust- oder Genehmigungsquoten nieder, daher sind Werte dieser Größe nicht trivial. Sie sind aber auch nicht einheitlich: Die untere Grenze ist klein, was nahelegt, dass der Nutzen stark davon abhängt, wie viel verwertbares Signal ein Textfeld trägt. Zwei Grenzen sind zu beachten: Die privaten Datensätze lassen sich außerhalb der Organisationen der Autoren nicht reproduzieren, und ein Monitoring nach dem Start gegen eine bestehende Strategie ist kein kontrolliertes Experiment.

Mehrere Eigenschaften machen den Ansatz für regulierte Umgebungen attraktiv. Die Ausgabe ist ausführbarer Code, den man prüfen, versionieren, testen und wiederholen kann. Ein Merkmal in Produktion ist dann nicht mehr das undurchsichtige Ergebnis eines Modellaufrufs, sondern ein Programm, das Prüfer lesen und Ingenieure auf historischen Daten erneut ausführen können. Das Einfrieren nach der Suche sorgt für stabiles Verhalten, und Drift lässt sich mit gewöhnlichen Werkzeugen überwachen. Da das LLM nie den Live-Verkehr berührt, müssen sensible Texte nicht an einen Drittanbieter-Endpunkt gesendet werden, und ein Ausfall des Modellanbieters kann den Entscheidungspfad nicht stoppen. Offene Fragen bleiben, und sie sind die interessantesten. Wie pflegt man eingefrorene Programme, wenn sich die Verteilung der Eingabetexte verschiebt, und wie oft sollte die Suche neu laufen? Kann vom LLM geschriebene Extraktionslogik Label-Information durchsickern lassen oder unerwünschte Verzerrungen kodieren, und wie erkennt man das vor dem Start? Lassen sich für ein Folgemodell gefundene Merkmale auf ein anderes übertragen? Welcher Teil des Gewinns stammt aus der Suchmaschinerie, und welcher daraus, dass ein LLM mit verlässlichem Bewertungssignal viele Versuche erhält? Die Kurzfassung beantwortet das nicht, und die Ablationsstudien des Beitrags werden wichtig sein. Die allgemeine Lehre bleibt klar: In Domänen, die durch Latenz und Compliance begrenzt sind, ist die am besten einsetzbare Rolle eines großen Modells womöglich die des Offline-Erbauers prüfbarer Bausteine statt die eines Online-Richters. LLM-BlockFE ist dafür ein konkretes, belegtes Beispiel und verdient die Aufmerksamkeit aller, die eine Feature-Pipeline verantworten.