spacy-llm : brancher un LLM dans un pipeline spaCy sans entraîner de modèle
🦙 Integrating LLMs into structured NLP pipelines
En bref
- De quoi s’agit-il ?
- spacy-llm ajoute un composant llm sérialisable aux pipelines spaCy, avec des tâches et des modèles déclarés dans la config. Le paquet se présente comme expérimental, et cette étiquette compte dans la décision d'adoption.
- À qui s’adresse-t-il ?
- spacy-llm convient aux équipes déjà engagées sur spaCy qui veulent des sorties structurées sans jeu de données annoté, en acceptant une interface instable et des appels réseau dans le pipeline. À éviter si vous ne pouvez pas auditer une config non fiable ou si vous avez besoin d'une inférence locale sans dépendance à un 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 173 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 problème : des sorties structurées sans données d'entraînement
Le README pose le décor sans détour. Un modèle supervisé entraîné sur quelques centaines à quelques milliers d'exemples reste, selon le projet, plus efficace, plus fiable et plus contrôlable qu'un prompt, et généralement plus précis. Le problème n'est donc pas la qualité en production, mais le démarrage : annoter un corpus prend du temps, et toutes les tâches ne méritent pas cet investissement. spacy-llm vise ce moment précis où l'on veut une étiquette, une entité ou un résumé tout de suite, puis arbitrer plus tard. Le public visé est celui qui connaît déjà spaCy : le paquet s'installe dans le même environnement virtuel que spaCy et s'utilise via nlp.add_pipe. Il ne remplace pas spaCy, il s'y greffe.
Une tâche, un modèle, et la config spaCy comme chef d'orchestre
Le mécanisme repose sur deux familles de fonctions enregistrées dans le registre spaCy : les tâches, qui gèrent le prompt et l'analyse de la réponse, et les modèles, qui gèrent l'appel au fournisseur. Le composant llm est sérialisable, ce qui signifie que la configuration du pipeline décrit à la fois la tâche et le modèle. Les tâches fournies couvrent la reconnaissance d'entités nommées, la classification de texte, la lemmatisation, l'extraction de relations, l'analyse de sentiment, la catégorisation de spans, le résumé, la liaison d'entités et la traduction. L'exécution de prompt brut est également disponible pour les cas hors catalogue. Côté modèles, le README liste les API OpenAI, Cohere, Anthropic, Google PaLM et Microsoft Azure AI, plus des modèles ouverts hébergés sur Hugging Face : Falcon, Dolly, Llama 2, OpenLLaMA, StableLM et Mistral. LangChain est aussi intégré, ce qui élargit l'accès à ses modèles. Pour les textes trop longs, une approche map-reduce découpe le prompt et fusionne les résultats. Un point de conception mérite d'être noté : la séparation tâche/modèle rend le fournisseur remplaçable sans réécrire le parsing, à condition que le format de sortie attendu reste le même.
Démarrer en trois lignes, puis passer à la config
L'installation se fait avec python -m pip install spacy-llm, dans l'environnement où spaCy est déjà présent. Le README précise que le paquet sera installé automatiquement dans de futures versions de spaCy. Pour un essai rapide, depuis la version 0.5.0, on peut écrire : import spacy, puis nlp = spacy.blank("en"), llm = nlp.add_pipe("llm_textcat"), llm.add_label("INSULT"), llm.add_label("COMPLIMENT"), et enfin doc = nlp("You look gorgeous!"). La sortie affichée dans le README est {"COMPLIMENT": 1.0, "INSULT": 0.0}. La factory llm_textcat sélectionne la dernière version de la tâche et le modèle GPT-3-5 par défaut d'OpenAI. Dès que l'on quitte l'expérimentation, on passe par le système de config de spaCy pour régler les paramètres du pipeline llm. Les clés API se placent dans des variables d'environnement, avec une section dédiée de la documentation. C'est un point à ne pas négliger : un pipeline qui fonctionne en local avec une clé exportée dans le shell peut échouer silencieusement dans un conteneur où la variable n'a pas été transmise.
Ce que le paquet ne promet pas
Le README est explicite : le paquet est encore expérimental, et des changements d'interface cassants peuvent survenir entre versions mineures. Cette phrase change la nature du risque. Une montée de version mineure n'est pas une simple correction de bug, elle peut exiger de retoucher la config. Les journaux de version confirment ce rythme : la v0.7.3 a sandboxé Jinja pour empêcher l'exécution de code depuis des configs non fiables, et la v0.7.4 a migré vers Pydantic v2 tout en ajoutant le support de Python 3.14. Une migration Pydantic n'est jamais cosmétique dans un écosystème Python. Autre limite structurelle : chaque document traité déclenche un appel réseau vers un fournisseur, avec la latence et le coût associés. Pour un pipeline qui traite des millions de documents, c'est un changement d'échelle, pas un détail. Enfin, la qualité dépend du prompt et du modèle, pas du paquet : spacy-llm fournit le cadre, pas la garantie de sortie.
L'alternative que le projet recommande lui-même
Le README ne cache pas la comparaison : un modèle supervisé qui tient sur un seul GPU reste, pour une tâche à sortie bien définie, un meilleur choix en production. La différence d'approche est nette. D'un côté, un entraînement sur quelques centaines à quelques milliers d'exemples labellisés, une inférence locale, un comportement stable et un contrôle total. De l'autre, un prompt envoyé à un service distant, une sortie à parser, et une précision qui, selon le projet, sera généralement inférieure. La position défendue par spacy-llm est celle du prototypage puis de la substitution progressive : on démarre avec des composants LLM, on ajoute des composants classiques à côté, et on remplace au fur et à mesure. C'est un argument honnête, mais il suppose que vous restiez dans spaCy. Si votre pile est ailleurs, l'intégration LLM de LangChain couvre un terrain plus large, sans le composant spaCy sérialisable ni le registre de factories.
Coût de maintenance et licence
Le paquet est publié sous licence MIT, ce qui autorise l'usage commercial et la modification, sans garantie fournie par les auteurs. Attention toutefois : cette licence couvre spacy-llm, pas les modèles que vous appelez. Un modèle ouvert téléchargé depuis Hugging Face conserve sa propre licence, et un service comme OpenAI, Anthropic ou Cohere impose ses conditions d'utilisation et sa facturation. Vérifiez chaque modèle séparément. Sur la maintenance, les versions récentes indiquent un projet suivi : support de Python 3.14, migration Pydantic v2, correctifs liés à Torch. Mais le statut expérimental annoncé signifie que vous devrez lire les notes de version avant chaque mise à jour, en particulier pour les changements de config et les dépendances comme Pydantic. Le coût réel n'est pas l'installation, c'est le suivi des ruptures d'interface.
Conclusion éditoriale
spacy-llm convient aux équipes déjà engagées sur spaCy qui veulent des sorties structurées sans jeu de données annoté, en acceptant une interface instable et des appels réseau dans le pipeline. À éviter si vous ne pouvez pas auditer une config non fiable ou si vous avez besoin d'une inférence locale sans dépendance à un fournisseur. Vérifiez d'abord les clés API, le bloc [components.llm] et les factories de tâches dans la documentation.
Notes de la communauté