Du texte long aux variables prédictives : LLM-BlockFE, ingénierie de variables par recherche de programmes

Les systèmes industriels de contrôle des risques reposent sur des modèles de données structurées, et pour de bonnes raisons : ils sont rapides, peu coûteux à servir, faciles à surveiller et compatibles avec les chaînes d'approbation et d'audit de la finance réglementée. Pourtant, une part considérable de l'information utile se trouve hors de ces tables, enfouie dans de longs textes non structurés : dossiers de demande, historiques d'échanges, descriptions libres. Pour l'exploiter, on a longtemps compté sur l'ingénierie manuelle des variables : des experts écrivent des règles et des scripts d'extraction, les testent, recommencent. Le travail est lent et sa couverture dépend de l'imagination des experts. L'alternative évidente, confier chaque texte entrant à un grand modèle de langage (LLM) au moment de l'inférence, bute souvent sur la latence, le débit, le coût et la stabilité d'un pipeline temps réel. Un article déposé sur arXiv le 8 octobre 2026, « Long Text to Predictive Features », propose une troisième voie nommée LLM-BlockFE.

L'idée centrale tient en une phrase : utiliser le LLM uniquement hors ligne, et lui faire produire non pas une prédiction mais un programme exécutable. LLM-BlockFE construit un programme de variables en ajoutant des blocs de code l'un après l'autre, et chaque bloc, une fois écrit, est immuable. Après chaque ajout, les variables candidates sont évaluées par un modèle aval, de sorte que la recherche est guidée par un gain prédictif mesuré et non par l'opinion du LLM sur son propre travail. Une fois la recherche terminée, les programmes sont gelés puis déployés : ils extraient des variables structurées à partir du texte long, et le modèle aval existant les consomme comme avant. Aucun appel au LLM n'a lieu en ligne. L'intelligence coûteuse est payée une seule fois, pendant la recherche, puis amortie sur toutes les requêtes. Le LLM passe du rôle de moteur d'inférence à celui d'ingénieur de variables, et le chemin de production reste aussi léger et prévisible qu'auparavant.

La difficulté réside dans la recherche elle-même. Les programmes croissent bloc par bloc, et une recherche gloutonne classique conserve ce qui paraît meilleur à l'étape courante. Cette habitude est fragile ici : un bloc précoce peut sembler utile tout en orientant tous les suivants vers une mauvaise région, sans que la méthode puisse revenir en arrière. Les auteurs introduisent donc un mécanisme de retour arrière au niveau des blocs, piloté par une attribution de crédit calibrée selon la profondeur. L'intuition est que le gain final d'un programme ne se répartit pas uniformément entre ses blocs : les blocs initiaux influencent tout ce qui suit, et une attribution naïve les juge mal. Calibrer le crédit selon la profondeur vise à corriger ce biais, pour identifier le vrai responsable d'une dégradation et ramener le programme juste avant lui. Le résumé nomme le mécanisme et son but, mais ne donne ni la formule de calibration ni les seuils : il faut les lire dans l'article complet, sans les deviner.

Le second choix de conception concerne le passage à l'échelle. LLM-BlockFE fait avancer plusieurs trajectoires de recherche indépendantes, de façon entrelacée. Plusieurs trajectoires réduisent le risque qu'un seul chemin malchanceux domine le résultat, mais une version naïve gaspille le budget, car chaque trajectoire peut redécouvrir les mêmes idées. L'article limite cette redondance en partageant une description fixe de la direction d'exploration de chaque trajectoire. Chacune voit où vont les autres, et l'effort se répartit au lieu de s'empiler. Un texte court et stable joue ainsi le rôle de signal de coordination. Cela compte, car chaque appel au LLM coûte de l'argent, et une exploration répétée est un appel qui n'a rien appris. Le retour arrière règle le problème vertical du chemin bloqué ; l'entrelacement avec descriptions partagées règle le problème horizontal des collisions. Ensemble, ils forment une discipline de recherche assez complète pour un espace où chaque évaluation est chère.

Les résultats portent sur deux jeux de données publics et deux jeux privés. Dans la comparaison sur jeux complets, LLM-BlockFE améliore l'AUC de 0,0069 à 0,0358 en valeur absolue par rapport à la meilleure base de référence de chaque jeu. La preuve la plus parlante vient du déploiement : sur cinq applications financières de contrôle des risques en production, le suivi après lancement montre des gains absolus de KS de 0,02 à 1,56 point de pourcentage par rapport à la stratégie conçue manuellement. En crédit et en lutte contre la fraude, un petit gain de pouvoir de classement se traduit par de vrais écarts de pertes ou de taux d'acceptation ; ces valeurs ne sont donc pas anodines. Elles ne sont pas uniformes non plus : la borne basse est faible, ce qui suggère que le bénéfice dépend beaucoup de la quantité de signal exploitable dans le texte. Deux limites s'imposent : les jeux privés ne sont pas reproductibles hors des organisations des auteurs, et un suivi après lancement face à une stratégie existante n'équivaut pas à une expérience contrôlée.

Plusieurs propriétés rendent l'approche séduisante en milieu réglementé. La sortie est du code exécutable, que l'on peut relire, versionner, tester et rejouer : une variable en production n'est plus le résultat opaque d'un appel de modèle, mais un programme qu'un auditeur peut lire et qu'un ingénieur peut relancer sur l'historique. Le gel des programmes après la recherche garantit un comportement stable, et la dérive se surveille avec des outils ordinaires. Comme le LLM ne touche jamais le trafic réel, les textes sensibles n'ont pas à quitter l'environnement de service vers un point d'accès tiers, et une panne du fournisseur de modèle ne peut pas interrompre la décision. Des questions restent ouvertes, et ce sont les plus intéressantes. Comment maintenir les programmes gelés quand la distribution des textes évolue, et à quelle fréquence relancer la recherche ? Une logique d'extraction écrite par un LLM peut-elle laisser fuiter l'étiquette ou encoder un biais, et comment le détecter avant le lancement ? Les variables trouvées pour un modèle aval se transfèrent-elles à un autre ? Quelle part du gain vient de la machinerie de recherche, et quelle part du simple fait d'offrir de nombreux essais à un LLM avec un signal de notation fiable ? Le résumé n'y répond pas, et les études d'ablation de l'article compteront. La leçon générale reste claire : pour les domaines contraints par la latence et la conformité, le rôle le plus déployable d'un grand modèle est peut-être celui de constructeur hors ligne de composants auditables, plutôt que de juge en ligne. LLM-BlockFE en offre un exemple concret, appuyé par des preuves, qui mérite l'attention de quiconque gère un pipeline de variables.