Hyper-Extract : extraire des graphes, hypergraphes et relations spatio-temporelles depuis du texte brut

Le problème : du texte non structuré qui doit devenir une structure exploitable

La plupart des documents utiles à une organisation ne sont pas des tables. Ce sont des rapports, des articles, des transcriptions, des PDF de plusieurs dizaines de pages. En tirer une liste d'entités et de relations demande soit d'écrire un pipeline d'extraction sur mesure, soit de choisir un framework et d'en accepter les conventions. Hyper-Extract se positionne sur ce deuxième créneau, avec une différence assumée : la structure de sortie n'est pas figée. Le README annonce 9 structures de connaissances, allant d'un simple corpus de chunks jusqu'aux graphes, hypergraphes et graphes spatio-temporels. Le public visé est donc celui qui a déjà compris qu'un graphe de triplets classique ne suffit pas toujours, par exemple quand une relation implique plus de deux participants. Le projet mentionne aussi des cas d'usage par métier dans le README : chercheur qui transforme un article en graphe de concepts, analyste financier qui extrait entités et métriques d'un rapport de résultats, déploiement local via vLLM. Ces exemples sont des illustrations du README, pas des études de cas vérifiées.

Le mécanisme : un modèle YAML décrit la structure, un moteur l'exécute

L'architecture visible dans le matériel repose sur deux objets. D'un côté, un Template, chargé par exemple avec `Template.create("general/biography_graph")` dans l'API Python, ou désigné par `-t general/biography_graph` en ligne de commande. De l'autre, un moteur d'extraction. Le README annonce 11+ moteurs, dont chunk_rag présenté comme une baseline sans coût, GraphRAG, LightRAG, Hyper-RAG et KG-Gen. Le template décrit donc la forme de la connaissance à produire, et le moteur décide comment le LLM est sollicité pour la remplir. Le README indique que les templates sont au format YAML et qu'il en existe 80+, répartis entre finance, juridique, médical, médecine traditionnelle chinoise, industrie et domaine général. C'est cette séparation qui rend l'outil utilisable sans écrire de code : on choisit un template existant, on pointe un fichier, on obtient une sortie. Le revers est qu'on ne sait pas, à la lecture du README, à quel point un template est contraignant sur le schéma produit ni comment le modifier. La documentation en ligne est citée mais son contenu n'est pas fourni ici.

Configuration : le LLM et l'embedder sont deux choix séparés

Le point de configuration le plus concret est la dissociation entre le modèle de génération et le modèle d'embedding. Le README donne trois chemins. Avec OpenAI, une seule commande : `he config init -p openai -k YOUR_OPENAI_API_KEY`. Avec DeepSeek, il faut deux commandes, parce que DeepSeek ne fournit que le LLM : `he config llm -p deepseek -k YOUR_DEEPSEEK_API_KEY` puis `he config embedder -p openai -k YOUR_OPENAI_API_KEY`. Avec vLLM en local, on précise l'URL, une clé factice et le nom du modèle des deux côtés : `he config llm -p vllm -u http://localhost:8000/v1 -k dummy -m Qwen/Qwen3.5-9B` et `he config embedder -p vllm -u http://localhost:8001/v1 -k dummy -m BAAI/bge-m3`. Le README mentionne aussi Anthropic et Alibaba Bailian, ce dernier fournissant LLM et embeddings avec une seule clé. Cette séparation est un choix de conception qui a un coût : deux modèles à maintenir, deux points de défaillance, et une cohérence sémantique entre les deux qui n'est pas discutée dans le matériel fourni.

Le cycle de vie du corpus : feed, tag, rollback

C'est la partie la plus distinctive. Le README montre `he feed ./output/ updated-tesla.md --source tesla.md` avec la mention que les anciens faits sont retirés automatiquement. Autrement dit, la sortie n'est pas un artefact figé mais un index mis à jour par source. Trois commandes accompagnent ce cycle : `he tag ./output/ --source tesla.md --add biography` pour étiqueter une source, `he search ./output/ "inventions" --tag biography` pour restreindre une recherche à ce périmètre, et `he info ./output/ --sources` pour auditer la contribution de chaque document. Le README mentionne également `he remove --document` pour revenir en arrière. Sur le papier, cela répond à un problème réel : un pipeline d'extraction classique oblige à tout recalculer quand un document change, ou à vivre avec des faits obsolètes. Ici, la granularité est la source. Ce que le matériel ne dit pas, c'est comment le rollback est calculé. Retirer les faits issus d'un document suppose de savoir lesquels lui appartiennent, ce qui dépend de la capacité du moteur à les attribuer correctement. La commande `he info --sources` existe précisément pour rendre cela visible, et c'est la première chose à tester.

Ingestion documentaire : une dépendance optionnelle

La version v0.9.0 est intitulée Rich Document Ingestion & chunk_rag Baseline. Le README précise que PDF, Word, PowerPoint, Excel, HTML et EPUB sont pris en charge, mais pas par défaut : il faut installer l'extra avec `pip install "hyperextract[ingest]"`. C'est un détail qui compte au moment du déploiement, parce qu'il ajoute des dépendances de parsing à une base qui, sinon, reste légère. Les exemples du README utilisent majoritairement des fichiers `.md`, et l'exemple chercheur passe un `paper.pdf`, ce qui suppose l'extra installé. Le projet recommande `uv tool install hyperextract` ou `pipx install hyperextract`, ce qui indique une volonté d'isolation de l'outil plutôt qu'une installation dans un environnement de projet. Pour un usage en bibliothèque, le README donne `uv pip install hyperextract` et l'import `from hyperextract import Template`.

Ce que l'outil ne résout pas

Le coût par page est mentionné pour DeepSeek, autour de 0,001 à 0,005 dollar par page selon le README. Sur un corpus de plusieurs milliers de documents, cela devient un budget à part entière, et rien dans le matériel ne décrit de mécanisme de cache ou de déduplication qui réduirait ce coût lors des passes répétées. Deuxième limite : la seule baseline annoncée comme gratuite, chunk_rag, ne produit pas de graphe, elle produit un corpus de chunks. Si vous voulez un graphe sans payer d'appels LLM, l'outil ne le propose pas. Troisième limite : la licence. Le badge du README indique Apache 2.0, mais le champ de licence du dépôt renvoie NOASSERTION, ce qui signifie que GitHub n'a pas su rattacher automatiquement un texte de licence reconnu. Avant un usage commercial, il faut lire le fichier LICENSE directement plutôt que se fier au badge. Enfin, le README ne documente pas de stratégie d'évaluation : aucune métrique de précision d'extraction n'est fournie, ce qui est cohérent avec le fait que la qualité dépend surtout du LLM choisi.

Face à un pipeline GraphRAG écrit à la main

L'alternative la plus directe est de construire soi-même l'extraction avec un framework comme GraphRAG ou LightRAG, que Hyper-Extract présente d'ailleurs comme des moteurs qu'il peut exécuter. La différence d'approche est nette. Dans un pipeline écrit à la main, vous contrôlez le prompt, le schéma de sortie, la stratégie de résolution d'entités et le format de stockage. Vous payez ce contrôle en code à maintenir. Hyper-Extract déplace ce contrôle dans un fichier YAML et une commande, au prix d'une couche d'abstraction dont le README ne détaille pas les limites. Le second point de différence est le cycle de vie : un pipeline GraphRAG classique se relance sur l'ensemble du corpus, alors que Hyper-Extract expose `he feed` et `he remove --document` avec une attribution par source. Si votre corpus est stable, cet avantage ne vaut rien. S'il bouge souvent, il change l'ordre de grandeur du travail.

Maintenance et versionnement

Le rythme de publication est soutenu : v0.8.1, v0.8.2 et v0.9.0 en l'espace de cinq jours selon les dates de release fournies. Cela suggère un projet actif, mais aussi une surface d'API qui bouge. Le numéro de version reste en 0.x, ce qui est un signal classique : les formats de template et les clés de configuration peuvent changer entre versions mineures. Pour un déploiement, cela implique de figer la version installée plutôt que de suivre `uv tool install hyperextract` sans contrainte, sinon une mise à jour peut modifier le comportement d'un template existant. Le README ne mentionne pas de politique de compatibilité ni de guide de migration entre versions. Sur le plan juridique, le badge Apache 2.0 et le NOASSERTION du dépôt doivent être réconciliés en lisant le fichier LICENSE avant toute redistribution ou usage en entreprise ; je ne peux pas trancher à partir du matériel fourni.

Conclusion éditoriale

À adopter si vous avez besoin de sortir une structure de connaissances d'un corpus documentaire hétérogène sans écrire de pipeline d'extraction vous-même, et si vous acceptez de payer des appels LLM par page. À éviter si vous cherchez un système de recherche en production : la seule baseline gratuite mentionnée, chunk_rag, ne fait pas d'extraction structurée, et les moteurs avancés dépendent entièrement de la qualité du modèle que vous branchez. Avant de vous engager, vérifiez deux choses concrètes : lancez `he info ./output/ --sources` sur un petit corpus pour voir si la traçabilité par source correspond à ce que vous attendez, puis testez `he feed` avec une version modifiée d'un document pour observer le comportement de rollback sur vos propres données.

Sources officielles

1. Issues
2. Project website
3. README
4. Releases
5. yifanfeng97/Hyper-Extract on GitHub