Scikit-LLM : des classifieurs à base de LLM dans l'API scikit-learn
Seamlessly integrate LLMs into scikit-learn.
En bref
- De quoi s’agit-il ?
- La bibliothèque expose des estimateurs qui respectent fit/predict de scikit-learn mais délèguent le calcul à un modèle de langage. Le README s'arrête à l'exemple de classification zero-shot, et c'est cette limite documentaire qu'il faut mesurer avant d'adopter.
- À qui s’adresse-t-il ?
- À adopter si vous avez déjà des pipelines scikit-learn et voulez y insérer un classifieur zero-shot sans réécrire le code d'orchestration. À éviter si vos données sont sensibles, si vous avez besoin de reproductibilité stricte ou d'un budget d'inférence prévisible : chaque appel part chez le fournisseur.
- Puis-je l’utiliser commercialement ?
- Oui. MIT est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 15 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le vide que comble une classe compatible fit/predict
Un pipeline scikit-learn classique suppose que l'entraînement produit un objet persistant : vectoriseur ajusté, coefficients, arbres. Un appel à un LLM ne produit rien de tel. Il n'y a pas de paramètres à sauvegarder, seulement une consigne envoyée à un service distant et une réponse à parser. Brancher ce second monde dans le premier casse tout ce qui repose sur l'état du modèle : GridSearchCV, cross_val_score, joblib.dump, Pipeline.
Scikit-LLM contourne le problème en fournissant des classes qui respectent l'interface des estimateurs. Le README donne l'exemple de ZeroShotGPTClassifier, importé depuis skllm.models.gpt.classification.zero_shot. On appelle fit(X, y) puis predict(X), exactement comme avec un classifieur supervisé ordinaire. Le public visé est donc précis : des équipes qui ont déjà du code scikit-learn en production et qui veulent tester une approche par LLM sans changer de structure de code. Ce n'est pas une bibliothèque pour construire des chaînes de prompts, ni un client API générique.
Ce que fit() fait réellement quand il n'y a rien à entraîner
Dans l'exemple du README, fit(X, y) reçoit les données et les étiquettes. Pour un classifieur zero-shot, il n'y a pas de descente de gradient. Les étiquettes servent à cadrer la tâche : elles indiquent au modèle quelles catégories sont attendues, et le README précise que le jeu de démonstration chargé par get_classification_dataset() porte les labels positive, negative et neutral.
Le mécanisme réel se joue donc à la prédiction. Chaque appel à predict(X) envoie le texte au modèle distant, accompagné de la consigne et de la liste des étiquettes possibles, puis convertit la réponse en une étiquette du jeu fourni. Le coût est proportionnel au nombre d'échantillons, pas à la taille d'un entraînement préalable. C'est une différence structurelle avec un classifieur classique : là où une régression logistique paie une fois puis prédit gratuitement, ici chaque prédiction est facturée. Le choix du modèle se fait à la construction, via le paramètre model, que le README illustre avec model="gpt-4".
Mise en route : clé, organisation, estimateur
L'installation tient en une commande : pip install scikit-llm. La configuration des identifiants passe par un objet statique, SKLLMConfig, importé depuis skllm.config. Deux appels suffisent selon le README : SKLLMConfig.set_openai_key("<YOUR_KEY>") et SKLLMConfig.set_openai_org("<YOUR_ORGANIZATION_ID>").
Le fait que ces valeurs soient posées sur une classe statique plutôt que passées à l'instanciation de l'estimateur a des conséquences pratiques. Un objet SKLLMConfig global se comporte mal dans un processus qui sert plusieurs locataires, et il faut vérifier comment il interagit avec les workers d'un ordonnanceur parallèle : si chaque processus doit recevoir la clé, la configuration devient une étape d'initialisation à part entière. Le README ne traite pas ce point. Il ne documente pas non plus les variables d'environnement, les autres fournisseurs, ni les paramètres de température ou de nombre de tentatives. Toute la documentation complémentaire est renvoyée vers skllm.beastbyte.ai, que je n'ai pas consulté ici.
Le cas où l'outil est le mauvais choix
Un classifieur qui appelle un service distant à chaque prédiction introduit trois propriétés que scikit-learn n'a jamais promises. La première est le coût variable : un cross_val_score avec cinq plis multiplie les appels par cinq, et rien dans l'interface ne signale cette dépense avant exécution. La deuxième est la non-déterminisme : à moins que le fournisseur garantisse une sortie stable, deux exécutions du même predict(X) peuvent diverger, ce qui rend les métriques de validation instables pour des raisons qui n'ont rien à voir avec le modèle.
La troisième est la confidentialité. Chaque échantillon de X quitte votre infrastructure. Pour un jeu de données clients, de dossiers médicaux ou de documents internes, cette seule caractéristique disqualifie l'approche, quelle que soit sa qualité. Il faut aussi noter que la bibliothèque ne fait aucune distinction, dans l'exemple fourni, entre entraînement et inférence : le même appel réseau sert les deux. Si votre besoin est un classifieur déterministe, peu coûteux et auditable, scikit-llm n'apporte rien qu'un TfidfVectorizer suivi d'un LinearSVC ne fasse déjà.
Face à un pipeline Transformers classique
L'alternative la plus directe n'est pas un concurrent de la même catégorie, mais l'usage direct de transformers avec un modèle de classification de séquences. La différence d'approche est nette. Avec transformers, vous téléchargez des poids, vous les exécutez localement, et vous ajustez éventuellement le modèle sur vos étiquettes. Le coût est fixe, la latence dépend de votre matériel, et rien ne sort de votre réseau. En échange, il faut gérer le tokenizer, la longueur maximale, le dispositif d'accélération et le stockage des poids.
Scikit-LLM déplace tout cela derrière l'API scikit-learn, mais en déléguant le calcul à un fournisseur externe. Vous gagnez la mise en œuvre, vous perdez la maîtrise. Le bon critère de choix n'est donc pas la performance brute, que le README ne revendique nulle part, mais la nature de vos données et la variabilité acceptable de vos sorties. Un prototype interne sur des textes publics et un système de traitement de réclamations clients n'ont pas la même réponse à cette question.
Licence MIT et rythme des versions
Le dépôt est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright. Cette licence couvre le code de la bibliothèque. Elle ne couvre évidemment pas les conditions d'utilisation du fournisseur de modèle que vous appelez, ni le traitement des données que vous lui transmettez. Ces deux aspects relèvent d'accords distincts et doivent être vérifiés séparément.
Sur le rythme de publication, les notes de version fournies montrent v1.4.1 en novembre 2024, v1.4.2 en septembre 2025, puis v1.4.3 en janvier 2026, avec un dernier push sur la branche main en septembre 2026. Le projet n'est pas archivé. L'écart entre v1.4.1 et v1.4.2, environ dix mois, suggère un rythme irrégulier plutôt qu'un flux continu de correctifs. Cela n'indique rien sur la qualité du code, mais cela compte pour planifier une montée de version : les correctifs de compatibilité avec les API des fournisseurs, qui évoluent vite, peuvent arriver tard. Le README ne décrit ni politique de support ni engagement de compatibilité entre versions mineures.
Ce qu'il faut vérifier avant de s'engager
Le README ne couvre qu'un seul estimateur et un seul fournisseur. Il ne liste pas les autres classes du paquet, ne décrit pas le format attendu pour X et y au-delà du jeu de démonstration, et ne dit rien de la gestion des erreurs réseau ni des limites de débit. Ces informations se trouvent peut-être dans la documentation hébergée sur skllm.beastbyte.ai, mais elles ne figurent pas dans le matériel fourni ici.
Concrètement, la première vérification à faire est un appel sur un jeu de quelques dizaines d'exemples avec un compteur d'appels réseau, pour confirmer combien de requêtes un fit suivi d'un predict déclenche réellement. La deuxième est un test de stabilité : exécuter deux fois le même predict sur le même X et comparer les étiquettes obtenues. Si les résultats divergent, aucune métrique de validation croisée n'est interprétable. Ces deux mesures se font en quelques minutes et déterminent si le reste de l'évaluation vaut la peine.
Conclusion éditoriale
À adopter si vous avez déjà des pipelines scikit-learn et voulez y insérer un classifieur zero-shot sans réécrire le code d'orchestration. À éviter si vos données sont sensibles, si vous avez besoin de reproductibilité stricte ou d'un budget d'inférence prévisible : chaque appel part chez le fournisseur. Avant tout engagement, vérifiez d'abord sur la documentation publiée quels estimateurs existent au-delà de ZeroShotGPTClassifier et quels paramètres de configuration sont exposés par SKLLMConfig.
Notes de la communauté