Utiliser les LLM comme features plutôt que classifieurs directs
En bref
- Un LLM utilisé directement pour classer des données souffre de problèmes d'étalonnage, de seuils mal contrôlables et d'interprétabilité insuffisante.
- La meilleure approche consiste à traiter la sortie du LLM comme une feature d'entrée pour un classifieur classique (régression logistique, XGBoost).
- Cette approche hybride retrouve les propriétés attendues d'un bon modèle : calibration, intégration de données structurées, et interprétabilité du processus décisionnel.
Ce que dit la source
L'auteur affirme que les LLM appliqués directement comme classifieurs (prompt + contexte = label) posent plusieurs problèmes pratiques : les verdicts sont des labels binaires non calibrés, les probabilités de confiance déclarées ne sont pas fiables, l'incorporation de données structurées reste imprévisible (impossible de savoir si le LLM les a réellement utilisées), et l'interprétabilité du processus décisionnel interne reste opaque. Bien que les LLM performent souvent "décemment" en pratique, leur absence de mécanisme d'ajustement des seuils précision/rappel les rend insuffisants pour des usages en production exigeants.
- Le problème central : un LLM-classifieur n'offre pas de probabilités calibrées permettant d'ajuster le seuil décision selon les besoins en précision ou rappel.
- Les LLM ignorent le contexte de distribution des données (classe positive rare ou sur-échantillonnée) et n'ont aucun moyen fiable d'en tenir compte dans leur jugement.
- La solution proposée : envelopper la sortie du LLM dans une régression logistique entraînée sur des données labelisées retrouve tous les avantages attendus (calibration, probabilités réelles, ajustement des seuils).
- Cette approche hybride permet d'ajouter d'autres features structurées au modèle, contrairement au LLM seul qui n'a aucun mécanisme pour les intégrer de manière fiable.
- Pour améliorer les performances, les approches standards du ML s'appliquent : collecter plus de données d'entraînement, concevoir de meilleures features (via plusieurs exécutions du LLM, log-probabilités), ou changer l'architecture du modèle (XGBoost, arbres).
- Test d'application sur la détection d'ironie : l'article démontre que la régression logistique sur des features LLM surpasse le LLM utilisé seul.
Dans les commentaires
Débat partagé : le fil se divise entre ceux qui valident l'approche (utilisateurs en production confirmant qu'elle fonctionne bien) et ceux qui jugent l'article peu novateur ou qui proposent des améliorations au LLM directement plutôt qu'un changement d'architecture.
- Plusieurs commentateurs contestent la pertinence de la découverte : l'idée qu'un système général peut être utilisé comme étape d'un système plus sophistiqué n'est pas nouvelle (un routeur calcule l'accessibilité, une algèbre informatique fait aussi de l'arithmétique simple).
- Un argument pour optimiser le LLM directement : une "megaprompt" bien construite incluant les propriétés à évaluer et demandant au LLM d'expliquer son raisonnement avant de donner un verdict final pourrait atteindre les performances de la régression logistique sans complexité supplémentaire et avec meilleure généralisation hors-distribution.
- Objection sur la structuration du test : un commentateur souligne que le test d'ironie pose d'abord une question binaire (ironie ou non) puis demande des features ; l'ordre inverse serait plus logique.
- Critique mathématique : la formulation du modèle manque de clarté sur ce que représente LLM(x) (une probabilité ? un token logit ?) et comment exactement le modèle s'améliore par rapport au LLM seul dans des conditions de faible données d'entraînement.
- Point technique sur les sorties structurées : les constraints imposées par Google (blocage de certains tokens avec -inf) modifient la distribution sous-jacente du modèle, si bien que le dernier token généré ne reflète pas vraiment l'intention originale du LLM.
Notre lecture
L'article décrit une approche pragmatique et reconnue en pratique : traiter un LLM comme extracteur de features plutôt que comme classifieur final retrouve les propriétés ML usuelles. C'est particulièrement utile si vous avez des données structurées à intégrer ou si vous avez besoin de contrôler précision/rappel. En revanche, l'article sous-estime le coût réel : vous n'échappez pas à l'étiquetage manual (construire un jeu d'entraînement pour la régression logistique). Et l'idée de combiner un modèle simple sur les sorties d'un modèle complexe n'est pas nouvelle, même si sa systématisation ici pour les LLM a du mérite. À tester en production si vous cherchez à maîtriser votre pipeline de classification, mais pas une révélation conceptuelle. Le débat HN soulève aussi qu'une meilleure ingénierie du prompt direct (incorporer les critères dans la promulgation) pourrait suffire et éviter la complexité ajoutée.