easy-dataset : fabriquer des jeux de données à partir de documents, avec un LLM dans la boucle
A powerful tool for creating datasets for LLM fine-tuning 、RAG and Eval
En bref
- De quoi s’agit-il ?
- Easy Dataset transforme des PDF, Markdown ou DOCX en jeux de données structurés pour le fine-tuning, le RAG et l'évaluation. L'interface fait le gros du travail, mais elle suppose un accès à une API de modèle et certaines fonctions restent à vérifier dans la documentation.
- À qui s’adresse-t-il ?
- À adopter si vous partez de documents métier existants et que vous voulez produire des paires question-réponse ou des jeux d'évaluation sans écrire de pipeline vous-même. À éviter si vous avez besoin d'un traitement entièrement hors ligne ou si vos segments doivent rester reproductibles à l'octet près : la génération passe par une API de modèle.
- Puis-je l’utiliser commercialement ?
- À vérifier. La licence de ce dépôt n’entre pas dans les catégories que nous classons automatiquement : lisez son fichier LICENSE avant tout usage commercial.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 137 jours.
- En quel langage est-il écrit ?
- Principalement JavaScript, 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 documents, pas des paires question-réponse
Un manuel interne, une documentation produit, un rapport de plusieurs centaines de pages. Vous voulez en tirer un jeu de données pour affiner un modèle ou alimenter un RAG. La chaîne habituelle demande d'extraire le texte, de le découper, de formuler des questions, de rédiger des réponses, puis de nettoyer le tout. Chaque étape est un script à maintenir, et la relecture humaine arrive souvent trop tard, une fois les données déjà au format final.
Easy Dataset vise exactement cet intervalle. Le README décrit une application qui convertit des documents de domaine en jeux de données structurés, pour le fine-tuning, le RAG et l'évaluation. Le public visé n'est pas seulement l'ingénieur qui écrit des scripts : l'interface est présentée comme utilisable par des profils non techniques, et des clients de bureau existent pour Windows, macOS et Linux. C'est un choix de positionnement qui a des conséquences sur la suite, notamment sur la reproductibilité.
Le pipeline : découpage, arbre de labels, questions, réponses
Le mécanisme se lit dans l'ordre des fonctionnalités du README. Un document est d'abord analysé (PDF, Markdown, DOCX, TXT, EPUB), puis découpé selon l'algorithme choisi : structure Markdown, séparateurs récursifs, longueur fixe, ou découpage sensible au code. Le découpage est présenté comme personnalisable visuellement, ce qui laisse supposer une étape de vérification manuelle des segments avant de continuer.
Vient ensuite la construction d'un arbre de labels de domaine, dérivé de la structure du document, avec auto-étiquetage. Les questions sont extraites des segments, avec des modèles de questions et une génération par lots. Les réponses sont produites par appel à une API de modèle, avec possibilité de générer une chaîne de raisonnement. Une passe de nettoyage retire le bruit.
Le point d'architecture à retenir : le LLM intervient à plusieurs endroits distincts (questions, réponses, nettoyage, étiquetage), et chaque prompt est modifiable au niveau du projet. Le README mentionne aussi une génération de paires Genre-Audience pour diversifier les données, et un mode distillation qui produit arbre de labels et questions directement depuis un sujet, sans document source. Ce dernier mode change la nature du résultat : vous ne partez plus d'un corpus, vous partez d'une intention.
Formats de sortie et intégration dans une chaîne d'entraînement
L'export se fait en Alpaca, ShareGPT ou Multilingual-Thinking, en JSON ou JSONL. Un export équilibré permet de fixer un nombre d'éléments par tag, ce qui répond à un problème réel : un arbre de labels produit naturellement des catégories très inégales, et un jeu de données déséquilibré se voit à l'entraînement.
Deux intégrations sont documentées. La génération d'un fichier de configuration LLaMA Factory en un clic, et l'envoi direct vers Hugging Face Hub. La première est la plus intéressante pour un utilisateur de LLaMA Factory : elle évite de retraduire les chemins et les noms de colonnes à la main. La seconde mérite une vérification de votre côté, car elle implique un jeton d'accès et une décision sur la visibilité du jeu de données.
Le README liste aussi des types de jeux de données qui ne sont pas de simples paires : dialogues multi-tours avec rôles et scénarios configurables, et jeux de questions sur images avec plusieurs modes d'import (répertoire, PDF, ZIP). Ces formats supposent des modèles compatibles avec la vision, ce que le README rattache à Gemini et Claude.
L'évaluation, ajoutée en version 1.7.0
La version 1.7.0 apporte la génération de jeux d'évaluation et l'exécution de tâches d'évaluation multi-dimensionnelles. Le README cite cinq types de questions : vrai/faux, choix unique, choix multiple, réponse courte et question ouverte. L'évaluation automatique repose sur un modèle juge, avec des règles de notation personnalisables. S'y ajoute un test à l'aveugle entre deux modèles, présenté comme double aveugle.
C'est la partie la plus discutable du projet, et le README ne permet pas de trancher. Un modèle juge qui note des réponses produites par un modèle introduit un biais que la documentation ne décrit pas. Le test à l'aveugle est justement la réponse à ce biais, mais le README ne précise pas comment les deux modèles sont exposés à l'évaluateur, ni comment les résultats sont agrégés. Si vous comptez vous appuyer sur ces scores pour décider d'un déploiement, lisez la documentation en ligne avant, pas après.
Installation : deux chemins, dont un que je ne peux pas confirmer
Le README propose de télécharger un client depuis la page des releases : un Setup.exe pour Windows, une version Intel pour macOS, et une entrée Linux. C'est le chemin le plus court et il ne demande aucune dépendance locale.
L'autre chemin est l'exécution locale depuis les sources. Le README contient une section Local Run, mais l'extrait fourni s'arrête au tableau de téléchargement des clients. Je ne peux donc pas citer ici les commandes exactes d'installation, ni les clés de configuration attendues. Le dépôt est en JavaScript, la branche par défaut est main, et la documentation en ligne se trouve à l'adresse docs.easy-dataset.com, avec une version anglaise sous /ed/en. C'est là qu'il faut chercher la procédure réelle.
Ce que le README confirme en revanche, c'est la compatibilité des modèles : toute API au format OpenAI, plus des fournisseurs nommés (OpenAI, MiniMax, Ollama, Zhipu AI, Alibaba Bailian, OpenRouter). Ollama est le seul de la liste qui permette de garder les données sur votre machine. Les autres impliquent d'envoyer vos segments de documents à un service tiers, ce qui est un point de conformité, pas un détail technique.
Ce que le projet ne fera pas pour vous
Première limite, et elle est structurelle : la qualité du jeu de données dépend du découpage, et le découpage dépend du format source. Un PDF sans structure exploitable donnera des segments arbitraires, et aucune génération de questions ne rattrape un segment qui coupe une phrase au milieu. Le README propose plusieurs algorithmes, ce qui est une reconnaissance du problème plutôt qu'une solution.
Deuxième limite : la reproductibilité. Le pipeline appelle un LLM à plusieurs étapes. Deux exécutions sur le même document ne produiront pas le même jeu de données, sauf si le fournisseur garantit une génération déterministe, ce que le README n'aborde pas. Pour un jeu d'évaluation publié ou comparé dans le temps, c'est un obstacle réel.
Troisième limite : le coût. Une fonction de suivi de la consommation de tokens et des appels API existe, ce qui indique que le projet sait que la facture compte. Générer des questions puis des réponses sur un corpus volumineux multiplie les appels. Le mode distillation, qui part d'un sujet au lieu d'un document, réduit ce coût mais éloigne le résultat de votre corpus.
Enfin, Easy Dataset n'est pas un outil d'entraînement. Il produit des fichiers. Tout ce qui vient après, l'entraînement, l'indexation pour le RAG, la mesure de l'effet réel sur le modèle, se passe ailleurs.
Face à un pipeline de scripts maison
L'alternative la plus directe n'est pas un autre produit, c'est un ensemble de scripts : un parseur, un découpeur, un client d'API, un formatteur. Vous perdez l'interface, l'arbre de labels, le suivi de consommation et l'export équilibré. Vous gagnez le contrôle total sur les prompts, la possibilité de versionner chaque étape, et l'absence de dépendance à un projet unique.
La différence d'approche est nette. Easy Dataset place la relecture humaine au centre : découpage visualisable, prompts modifiables par projet, test à l'aveugle, tableau de bord. Un pipeline de scripts place la reproductibilité au centre et repousse la relecture à la fin. Les deux sont défendables, mais ils ne s'adressent pas aux mêmes contraintes. Si votre corpus change souvent et que vous devez régénérer le jeu de données à l'identique, les scripts gagnent. Si vous découvrez un domaine et devez juger la qualité segment par segment, l'interface gagne.
Un point de comparaison concret : le format d'export. Easy Dataset cible Alpaca, ShareGPT et Multilingual-Thinking, et génère une configuration LLaMA Factory. Un pipeline maison produit ce que vous lui demandez, mais vous devez écrire et maintenir chaque conversion.
Maintenance, licence et ce qu'il faut vérifier avant d'adopter
Le rythme de publication est régulier : 1.7.1 en janvier 2026, 1.7.2 en février, 1.7.3 en avril, avec un dernier push sur main en mai 2026. Un projet qui publie des versions mineures tous les un à deux mois implique une charge de mise à jour. Les clients de bureau se mettent à jour par téléchargement, mais une instance locale exécutée depuis les sources demandera de suivre les changements de schéma et de configuration entre versions. Le README ne documente pas de politique de compatibilité entre versions.
La licence demande une vérification. Le badge du README indique AGPL-3.0, alors que les métadonnées du dépôt renvoient NOASSERTION, c'est-à-dire une licence non reconnue automatiquement. L'AGPL-3.0 est une licence à copyleft fort avec une clause de mise à disposition du code pour les services en réseau. Si vous envisagez d'intégrer Easy Dataset dans un service accessible à des utilisateurs, lisez le fichier LICENSE du dépôt et faites trancher la question par qui de droit. Je ne donne pas d'avis juridique ici, je signale seulement que les deux sources se contredisent.
Un dernier élément à ne pas ignorer : le README renvoie à une prépublication arXiv (2507.04009). C'est une source à lire si vous voulez comprendre les choix méthodologiques du projet, plutôt que de vous fier aux seules descriptions de fonctionnalités.
Conclusion éditoriale
À adopter si vous partez de documents métier existants et que vous voulez produire des paires question-réponse ou des jeux d'évaluation sans écrire de pipeline vous-même. À éviter si vous avez besoin d'un traitement entièrement hors ligne ou si vos segments doivent rester reproductibles à l'octet près : la génération passe par une API de modèle. Avant de vous engager, vérifiez deux points dans le dépôt : les clés de configuration attendues pour votre fournisseur, et le fichier de licence, puisque le badge du README indique AGPL-3.0 alors que l'API du dépôt renvoie NOASSERTION.
Notes de la communauté