ContextGem : décrire ce qu'on veut extraire plutôt que d'écrire le prompt

Le problème visé : le prompt d'extraction comme dette

Extraire des données d'un contrat ou d'un rapport avec un LLM revient souvent à écrire un prompt, à définir un modèle de validation à côté, puis à faire correspondre à la main chaque valeur extraite avec l'endroit du document qui la justifie. Ce dernier point est celui qui coûte le plus cher en maintenance, parce qu'il faut le refaire dès que le format des documents change. Le README de ContextGem présente ce constat comme la motivation du projet : l'auteur décrit une chaîne qui comprend la rédaction des prompts, la conception des modèles de validation, le rattachement des sorties aux sources, l'orchestration de pipelines en plusieurs étapes et le suivi de la consommation des modèles. Le public visé est donc l'ingénieur qui écrit ce genre de code en Python, pas l'utilisateur final. Les thèmes déclarés du dépôt confirment cette orientation : analyse de contrats, legaltech, extraction de données non structurées. La promesse tient en une phrase : décrire ce qu'on veut extraire en langage naturel, laisser le cadre décider comment.

Aspects et concepts : la grammaire du cadre

Le vocabulaire du projet repose sur deux notions. Un aspect identifie une partie ou un thème du document, par exemple une clause ou une catégorie. Un concept est une valeur à extraire : entité, fait, conclusion, évaluation. La documentation indique que les concepts peuvent être imbriqués dans les aspects, et que les aspects peuvent eux-mêmes être hiérarchiques. C'est cette imbrication qui distingue ContextGem d'un simple appel de fonction avec un schéma : on ne demande pas au modèle de remplir un objet plat, on lui demande d'abord de repérer les zones pertinentes, puis d'en extraire des valeurs à l'intérieur. Le README cite l'exemple d'une extraction d'anomalies dans un document juridique, présenté comme un concept complexe qui exige une compréhension contextuelle. Ce découpage a un coût : plusieurs appels au modèle par document au lieu d'un seul, donc plus de latence et plus de jetons consommés. Le projet ne publie pas de chiffre sur ce point dans les éléments dont je dispose, et il faut le mesurer soi-même sur son propre corpus.

Ce que le cadre génère à votre place

Les fonctions mises en avant dans le README sont la génération dynamique des prompts et la génération automatique des modèles de données. Autrement dit, vous décrivez une extraction en langage naturel et le cadre produit le prompt correspondant ainsi que la structure de validation, construite sur Pydantic v2 d'après les badges du dépôt. Le rattachement des références est présenté comme descendant au paragraphe et à la phrase. C'est la partie la plus intéressante du projet, parce que c'est exactement ce que les équipes réimplémentent mal. Deux réserves. D'abord, ce rattachement suppose que le document possède une structure interne de paragraphes et de phrases ; sur un PDF mal converti ou un scan, la référence pointera vers un texte déjà dégradé. Ensuite, la génération automatique du prompt déplace le problème plutôt qu'elle ne le supprime : quand une extraction échoue, il faut comprendre ce que le cadre a réellement envoyé au modèle. Le dépôt mentionne un stockage unifié et sérialisable des documents, ce qui laisse penser qu'un document traité peut être conservé puis réutilisé sans repasser par l'analyse initiale.

Mise en route : deux commandes et un exemple

L'installation tient en une ligne. Avec uv, que le README recommande : uv add contextgem. Avec pip : pip install -U contextgem. Les versions de Python prises en charge sont 3.10, 3.11, 3.12, 3.13 et 3.14, d'après le badge correspondant. Le README renvoie ensuite vers un exemple de démarrage rapide dont l'extrait fourni s'arrête au milieu d'une phrase et ne montre pas le code complet. Je ne peux donc pas reproduire ici l'API exacte telle qu'elle apparaît dans la documentation. Ce qui est vérifiable depuis le dépôt : le projet utilise Hatch comme outil de construction, Ruff pour le formatage et l'analyse statique, ty pour la vérification de types, pre-commit et deptry pour les dépendances. Pour un lecteur qui évalue le coût d'intégration, ces choix signifient que le paquet s'installe proprement dans un environnement Python moderne, mais ils ne disent rien de la compatibilité avec un projet plus ancien resté sur des outils différents.

Où le cadre devient le mauvais outil

La dépendance à un fournisseur de LLM est le point faible le plus visible. Le projet se décrit comme un cadre d'extraction par LLM, et la qualité du résultat dépend donc du modèle branché derrière, pas du cadre. Un changement de modèle peut modifier les sorties sans qu'aucune ligne de votre code n'ait bougé, et rien dans les éléments disponibles n'indique qu'un jeu de tests de non-régression sur les extractions soit fourni. Deuxième cas défavorable : les documents sans structure fiable. Le rattachement au paragraphe et à la phrase, qui est l'argument principal du projet, perd sa valeur sur des entrées déjà bruitées. Troisième cas : si vous avez besoin d'une extraction déterministe et auditable au sens réglementaire, un pipeline fondé sur un modèle génératif reste un pipeline probabiliste, et le cadre ne change pas cette propriété. Enfin, la cadence de publication observée (v0.25.1 en juin 2026, v0.26.0 en juillet, v0.27.0 en août) suggère un projet en évolution rapide : c'est bon signe pour la maintenance, moins bon pour la stabilité de l'API si vous épinglez une version ancienne.

Face à InstructLab et aux cadres de génération synthétique

L'alternative la plus proche dans l'écosystème open source n'est pas un autre extracteur mais InstructLab, qui prend le problème par l'autre bout : au lieu de décrire une extraction et de laisser un modèle la réaliser, on génère un jeu de données synthétique pour ajuster un modèle sur la tâche. La différence d'approche est nette. ContextGem reste à l'inférence : aucun entraînement, les documents sont traités à la volée, et la qualité dépend du modèle choisi. InstructLab déplace le coût vers la préparation des données et l'ajustement, avec l'espoir d'un modèle plus petit et plus spécialisé à l'arrivée. Pour une équipe qui doit traiter un flux de contrats variés sans pouvoir constituer un corpus d'entraînement, ContextGem est plus directement applicable. Pour une équipe qui répète la même extraction sur des milliers de documents au format homogène, l'ajustement peut devenir plus économique à l'usage, au prix d'un travail initial beaucoup plus lourd. Le choix se joue donc sur la variabilité des documents, pas sur la qualité intrinsèque des deux projets.

Licence, maintenance et coût de mise à jour

Le dépôt est publié sous Apache-2.0, une licence permissive qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver les mentions de copyright et le texte de la licence, et qui inclut une clause de brevets. Rien dans les éléments fournis n'indique de clause additionnelle. Attention toutefois : cette licence couvre le code de ContextGem, pas les modèles que vous appellerez depuis votre pipeline, dont les conditions d'utilisation vous incombent. Le dépôt dispose d'un workflow dédié à la compatibilité des licences, ce qui suggère une vigilance sur les dépendances tierces, mais je ne peux pas en déduire le détail des licences embarquées. Sur la maintenance, le dernier envoi de code daté du 13 août 2026 et une version publiée le même jour indiquent un projet actif à cette date. La contrepartie est un rythme de versions rapproché : prévoyez de relire les notes de version avant chaque montée, en particulier si vous dépendez du format de sérialisation des documents, qui est présenté comme unifié et donc susceptible d'évoluer avec le cadre.

Conclusion éditoriale

ContextGem convient aux équipes Python qui extraient déjà des données de documents avec un LLM et qui passent leur temps à réécrire des prompts et des modèles de validation : la description déclarative et le rattachement des sorties au texte source répondent directement à ce coût. Il ne convient pas à qui veut un pipeline stable sans dépendance à un fournisseur de LLM, ni à qui doit traiter des documents sans structure interne exploitable, puisque le rattachement paragraphe et phrase suppose cette structure. Avant d'adopter, vérifier deux points dans le dépôt : la liste des fournisseurs réellement pris en charge par la couche d'appel, et le contenu du fichier de licence ainsi que celui des licences tierces, car l'Apache-2.0 du projet ne dit rien des modèles que vous brancherez dessus.

Sources officielles

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. shcherbak-ai/contextgem on GitHub