LangExtract : l'extraction structurée ancrée dans le texte source
Une bibliothèque Python pour extraire des informations structurées à partir de texte non structuré à l'aide de LLM avec une mise à la terre précise et une visualisation interactive.
En bref
- De quoi s’agit-il ?
- Une bibliothèque Python de Google qui fait extraire par des LLM des entités liées à leur position exacte dans le texte, avec visualisation HTML interactive et support Gemini, OpenAI et Ollama.
- À qui s’adresse-t-il ?
- LangExtract s'adresse aux équipes qui veulent transformer des textes non structurés, notes cliniques, rapports, littérature, en données structurées vérifiables : chaque extraction porte sa plage de caractères source, filtrable via char_interval, et une visualisation HTML autonome permet la revue. Le démarrage passe par pip install langextract, une clé Gemini dans LANGEXTRACT_API_KEY et le model_id gemini-3.5-flash recommandé par défaut.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 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 2 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
L'ancrage dans le texte source comme principe central
LangExtract est une bibliothèque Python qui emploie des LLM pour extraire des informations structurées de textes non structurés, selon des instructions définies par l'utilisateur, notes cliniques ou rapports par exemple. Sa promesse distinctrice est l'ancrage : chaque extraction est mappée à son emplacement exact dans le texte source, ce qui permet un surlignage visuel et une vérification. La bibliothèque impose aussi un schéma de sortie cohérent, dérivé des exemples few-shot fournis, avec génération contrôlée dans les modèles qui le soutiennent comme Gemini. Le README liste sept atouts, de la gestion des documents longs à la visualisation interactive, et reste lucide sur le septième : l'usage des connaissances du modèle dépend de sa qualité, de la tâche, de la clarté de l'invite et des exemples. Le projet affiche 38 500 étoiles.
Trois étapes : invite, extract, visualisation
Le démarrage rapide tient en trois gestes. D'abord la définition de la tâche : une invite décrivant ce qu'il faut extraire, puis des exemples de haute qualité via lx.data.ExampleData, dont le texte d'extraction doit être verbatim et suivre l'ordre d'apparition, des avertissements d'alignement étant émis sinon. Ensuite l'appel à lx.extract avec le texte d'entrée, l'invite, les exemples et un model_id, par défaut gemini-3.5-flash selon la recommandation du README. Enfin la sortie : lx.io.save_annotated_documents écrit un JSONL, et lx.visualize produit un fichier HTML autonome pour relire les entités dans leur contexte. Un détail de robustesse mérite l'attention : les extractions que le modèle a reprises des exemples plutôt que de l'entrée reçoivent char_interval à None, et le README montre le filtre exact pour ne garder que les ancrées.
Documents longs : découpage, parallélisme, passages multiples
Le traitement des longs documents repose sur trois paramètres documentés dans l'exemple Roméo et Juliette : extraction_passes=3 pour plusieurs passages, max_workers=20 pour le parallélisme et max_char_buffer=1000 pour des contextes réduits, la combinaison visant un meilleur rappel sur le défi de l'aiguille dans la botte de foin. Le texte source peut d'ailleurs être chargé directement depuis une URL, comme le texte intégral de la pièce sur Project Gutenberg, 147 843 caractères, d'où des centaines d'entités extraites. Pour les volumes importants, le README décrit le batch Vertex AI via language_model_params avec vertexai=True, project, location et une configuration batch, afin de réduire les coûts. Aucun benchmark n'est publié, les chiffres s'arrêtent aux centaines d'entités de l'exemple.
Modèles : Gemini par défaut, OpenAI et Ollama en local
Le choix du modèle est documenté avec ses arbitrages. gemini-3.5-flash est le défaut recommandé pour la qualité d'extraction sous contrainte de schéma, gemini-3.1-flash-lite pour les charges sensibles au coût, et un modèle Gemini Pro pour les tâches complexes ; un palier payant est suggéré en production pour le débit et les limites de taux. Le README rappelle aussi le cycle de vie des modèles Gemini, avec dates de retrait à suivre dans la documentation officielle. OpenAI est soutenu via une dépendance optionnelle, avec sorties structurées ou mode JSON. En local, Ollama fonctionne avec model_id gemma2:2b et model_url http://localhost:11434, sans clé API ; le mode JSON y est disponible, mais output_schema n'y est pas pris en charge.
Fournisseurs personnalisés et gestion des clés
L'architecture prévoit un système léger de plugins pour les fournisseurs LLM : enregistrement avec @router.register, publication d'un point d'entrée, fabrique branchée via create_model, et un registre séparé recense les plugins communautaires. Les clés API des modèles cloud, Gemini via AI Studio ou Vertex AI, OpenAI via sa plateforme, se configurent par variable d'environnement, par fichier .env à ajouter à .gitignore, ou en passant la clé directement à lx.extract, pratique que le README déconseille en production. Un Dockerfile est fourni, la clé étant passée en variable LANGEXTRACT_API_KEY au conteneur. Pour Vertex AI, les comptes de service passent par les mêmes language_model_params avec project et location.
Exemples de domaine : Shakespeare, médicaments, RadExtract
Trois exemples cadrent les usages. L'extraction intégrale de Roméo et Juliette montre le gros volume et le chargement par URL. L'extraction de médicaments depuis des textes cliniques démontre un cas professionnel, avec un avertissement exprès du README : l'exemple est illustratif, pas un avis médical, et l'usage santé relève des conditions Health AI Developer Foundations. RadExtract enfin, une démo interactive hébergée sur HuggingFace Spaces, structure des rapports de radiologie. Une démo générale tourne aussi dans le navigateur sur google-langextract.hf.space, sans installation. Ces exemples partagent la même mécanique : quelques exemples few-shot bien choisis suffisent à définir une tâche de domaine, sans fine-tuning.
Maintenance, disclaimer et licence
Le rythme de versions est soutenu : v1.4.0 le 15 mai 2026, v1.5.0 le 20 mai, v1.6.0 le 2 juillet. L'outillage qualité est documenté : tests pytest, tox exécutant pylint et pytest sur Python 3.10 et 3.11, formatage isort et pyink, hooks pre-commit. Les contributions exigent la signature d'un accord de licence de contributeur. La citation académique passe par une entrée BibTeX avec DOI Zenodo. Le disclaimer mérite d'être rappelé tel quel : LangExtract n'est pas un produit officiellement pris en charge par Google. La licence Apache 2.0 autorise usage commercial, modification et redistribution, avec la concession de brevets habituelle et sans garantie. Pour une équipe, ces éléments délimitent un outil à intégrer avec un plan de repli sur les modèles, dont le cycle de vie bouge.
Conclusion éditoriale
LangExtract s'adresse aux équipes qui veulent transformer des textes non structurés, notes cliniques, rapports, littérature, en données structurées vérifiables : chaque extraction porte sa plage de caractères source, filtrable via char_interval, et une visualisation HTML autonome permet la revue. Le démarrage passe par pip install langextract, une clé Gemini dans LANGEXTRACT_API_KEY et le model_id gemini-3.5-flash recommandé par défaut. Le README prévient que ce n'est pas un produit Google officiellement pris en charge, que l'usage santé relève de conditions spécifiques et que la précision dépend du modèle comme de la qualité des exemples few-shot.
Notes de la communauté