GraphGen : générer des données de fine-tuning à partir d'un graphe de connaissances
GraphGen: Enhancing Supervised Fine-Tuning for LLMs with Knowledge-Driven Synthetic Data Generation
En bref
- De quoi s’agit-il ?
- GraphGen construit un graphe de connaissances fin depuis un corpus, mesure les lacunes du modèle avec l'expected calibration error, puis génère des paires question-réponse ciblées. Le dépôt est actif, sous Apache-2.0, mais la qualité dépend entièrement du graphe produit en amont.
- À qui s’adresse-t-il ?
- GraphGen convient aux équipes qui disposent déjà d'un corpus textuel dense et vérifiable, et qui acceptent de payer la construction du graphe avant de voir une seule paire QA. Il ne convient pas à qui cherche un générateur de données immédiat à partir d'une poignée de PDF, ni à qui n'a pas de quoi faire tourner un LLM local ou distant à l'échelle du corpus.
- 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 30 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 jeux SFT qui répètent ce que le modèle sait déjà
Un jeu de données de supervised fine-tuning vaut ce que valent ses exemples rares. Générer des questions à partir d'un corpus par simple découpage produit beaucoup de paires faciles, redondantes, et le modèle n'apprend presque rien de plus qu'avec son pré-entraînement. GraphGen part d'un constat différent : ce qui manque à un modèle, c'est le savoir de longue traîne, celui que le corpus contient mais que le modèle restitue mal. Le framework est présenté comme une manière de cibler ces zones plutôt que de couvrir uniformément le texte source. Le public visé est donc assez précis : des équipes qui préparent du SFT sur un domaine technique ou scientifique, disposent d'un corpus conséquent, et veulent un signal de sélection des exemples autre que le hasard ou la longueur. Le dépôt porte d'ailleurs des topics qui tracent ce positionnement : ai4science, knowledge-graph, sft-data, question-answering. Ce n'est pas un outil pour augmenter un petit jeu de données de quelques centaines de lignes.
Le graphe d'abord, les questions ensuite
L'architecture décrite dans le README suit un ordre strict. Première étape, la construction d'un graphe de connaissances fin à partir du texte source. Deuxième étape, l'identification des lacunes du modèle à l'aide de l'expected calibration error, une métrique d'écart entre confiance déclarée et exactitude. Ce sont ces lacunes qui déterminent quelles paires QA méritent d'être générées : le framework priorise la connaissance à forte valeur et de longue traîne. Troisième étape, un échantillonnage de voisinage multi-hop pour capturer les relations complexes entre entités, puis une génération contrôlée par le style pour diversifier les formulations. Cette chaîne explique pourquoi le coût d'entrée est élevé : rien ne sort tant que le graphe n'existe pas. Le graphe n'est pas un sous-produit, c'est l'index qui rend la sélection possible. Depuis le 14 août 2025, une détection de communautés par l'algorithme de Leiden est également présente, avec pour objectif la synthèse de données Chain-of-Thought. Le 26 décembre 2025, des métriques d'évaluation du graphe ont été ajoutées : exactitude des entités et relations, détection de conflits pour la cohérence, robustesse structurelle face au bruit, à la connectivité et à la distribution des degrés. Ces métriques sont un point de contrôle utile, car elles permettent de juger le graphe avant de juger les données générées.
Backends d'inférence et stockage : ce que le dépôt liste réellement
GraphGen ne fournit pas de modèle. Il faut brancher le sien. Le README cite plusieurs clients et backends ajoutés au fil des versions : un Ollama_client, un http_client générique, un wrapper HuggingFace Transformers, un wrapper SGLang, et depuis le 16 décembre 2025 un support vllm pour l'inférence locale. Côté stockage, la même date marque l'ajout de rocksdb comme backend clé-valeur et de kuzudb comme base de graphes. La même mise à jour mentionne une refonte du pipeline de génération autour de ray pour l'exécution distribuée et la gestion des ressources. Cette accumulation de backends est une bonne nouvelle pour l'intégration, et un point de vigilance pour la maintenance : chaque backend est une surface de configuration supplémentaire, et le README ne donne pas de tableau comparatif de leurs performances respectives. Côté entrée, le support du PDF passe par MinerU depuis le 21 octobre 2025, et le support de HuggingFace Datasets comme source de données date du 4 février 2026. Le 1er décembre 2025, des recherches sur NCBI et RNAcentral ont été ajoutées, ce qui confirme l'orientation bioinformatique de certains usages.
Mise en route : ce que le dépôt donne comme points d'entrée
Le paquet s'installe depuis PyPI sous le nom graphg (le badge du README pointe vers pypi.org/project/graphg/). Le README renvoie à un cookbook hébergé sur GitBook pour la documentation détaillée, et à un issue du dépôt référencé comme best practice (open-sciencelab/GraphGen issue 17) pour un exemple de mise en œuvre. Un script est cité explicitement pour la génération de données de Visual Question Answering : bash scripts/generate/generate_vqa.sh. C'est le seul chemin de commande concret présent dans le matériel fourni. Le reste, notamment la configuration du graphe, le choix du backend d'inférence et les paramètres de génération, se trouve dans la documentation externe, pas dans le README. Il faut donc compter une phase de lecture du cookbook avant de lancer quoi que ce soit. Deux démos en ligne existent, une sur Hugging Face Spaces et une sur ModelScope, mises à jour automatiquement depuis le 29 septembre 2025. Elles permettent de voir le comportement sans installer, mais elles ne remplacent pas un essai sur votre propre corpus, qui est précisément l'endroit où le coût se concentre.
Le graphe comme point de défaillance unique
La limite principale tient à la dépendance en amont. Si l'extraction d'entités et de relations est bruitée, l'étape d'identification des lacunes s'appuie sur une carte fausse, et la génération cible des zones qui n'existent pas ou rate celles qui comptent. Le README ne décrit pas de mécanisme de correction automatique de cette dérive. Les métriques d'évaluation du graphe ajoutées en décembre 2025 (exactitude, détection de conflits, robustesse structurelle) sont précisément l'outil pour repérer ce cas, mais elles sont des mesures, pas des garde-fous. Autre contrainte : l'expected calibration error suppose d'interroger le modèle sur des éléments du graphe pour estimer sa confiance. Cela implique un volume d'appels au LLM qui n'est pas anecdotique, et un backend d'inférence suffisamment rapide pour que l'opération reste praticable. Sur un corpus de quelques milliers de documents, la facture peut devenir le facteur limitant. Enfin, GraphGen est un mauvais choix si votre besoin est de générer des instructions générales ou des conversations créatives sans ancrage documentaire : le graphe n'apporterait rien, et vous paieriez une étape de construction inutile.
Face à une génération directe par LLM
L'alternative la plus évidente est un pipeline de génération directe : on découpe le corpus en segments et on demande à un LLM de produire des questions à partir de chaque segment, sans graphe ni mesure de lacune. C'est plus simple, plus rapide, et cela ne demande aucune infrastructure de stockage. La différence d'approche est nette. La génération directe traite chaque segment de façon isolée, ce qui rend difficile la production de questions multi-hop reliant deux passages éloignés du corpus, et elle n'offre aucun critère pour choisir quels segments méritent d'être transformés en questions. GraphGen répond à ces deux points par construction : l'échantillonnage de voisinage multi-hop fournit le matériau relationnel, et l'ECE fournit le critère de sélection. Le prix à payer est l'étape de graphe, avec son stockage (rocksdb, kuzudb) et son exécution distribuée (ray). Si votre corpus est petit ou si vos questions cibles sont mono-document, la génération directe reste plus rationnelle.
Maintenance, licence et coût de mise à jour
Le dépôt n'est pas archivé et le dernier push date du 17 août 2026. Le rythme des mises à jour documentées dans le README est soutenu : PDF via MinerU en octobre 2025, support NCBI et RNAcentral en décembre 2025, refonte ray et backends rocksdb/kuzudb/vllm le même mois, métriques de graphe fin décembre 2025, synthèse de benchmarks éducatifs en janvier 2026, entrée HuggingFace Datasets en février 2026. Deux versions sont listées : v0.1.0.post20250930 (30 septembre 2025) et 20250422 (22 avril 2025). Cette cadence signifie que les interfaces de configuration bougent, et qu'un pipeline écrit contre une version antérieure peut demander des ajustements lors d'une montée de version. Le paquet est publié sous Apache-2.0, ce qui autorise l'usage commercial et la modification, avec les obligations habituelles de conservation de la notice de licence et d'état des modifications. Le matériel fourni ne précise pas la licence des corpus d'entrée ni celle des modèles utilisés pour la génération : ce sont deux points à vérifier séparément, car ils ne relèvent pas de la licence du framework. Rien dans le README ne permet d'estimer un coût de calcul par document, et je ne peux pas en avancer un.
Conclusion éditoriale
GraphGen convient aux équipes qui disposent déjà d'un corpus textuel dense et vérifiable, et qui acceptent de payer la construction du graphe avant de voir une seule paire QA. Il ne convient pas à qui cherche un générateur de données immédiat à partir d'une poignée de PDF, ni à qui n'a pas de quoi faire tourner un LLM local ou distant à l'échelle du corpus. Avant d'adopter, vérifier deux choses concrètes : le format d'entrée accepté (texte brut, PDF via MinerU, ou HuggingFace Datasets depuis le 4 février 2026) et le backend d'inférence configuré, car le dépôt mentionne vllm, SGLang, HuggingFace Transformers, Ollama et un client HTTP générique, et le coût de génération change du tout au tout selon celui qui est retenu.
Notes de la communauté