Bespoke Curator : construire des jeux de données synthétiques pour le post-entraînement

Le vide que Curator prétend combler

Écrire un pipeline de génération de données synthétiques à la main, c'est assembler soi-même la gestion des appels asynchrones, la mise en cache des réponses, la reprise après un échec réseau et la validation du format de sortie. Le README présente Curator comme la réponse à ce travail répétitif : une bibliothèque Python qui prend en charge ces couches pour que l'utilisateur se concentre sur le prompt et le schéma de données. La cible est double. D'un côté les équipes qui préparent du post-entraînement, distillation ou instruction-tuning, et qui ont besoin de volumes importants d'exemples générés. De l'autre, celles qui veulent extraire des données structurées à partir de textes et qui ont besoin d'un format de sortie fiable. Le README mentionne aussi un viewer pour suivre la génération en cours, ce qui suppose un usage interactif et non uniquement des exécutions par lots lancées en arrière-plan.

Ce que le dépôt laisse voir de l'architecture

Le README ne décrit pas l'architecture interne. Il indique que l'accès aux modèles passe par LiteLLM, vLLM et plusieurs API de traitement par lots, ce qui suggère une couche d'abstraction au-dessus des fournisseurs plutôt qu'un client dédié à un seul service. Les optimisations annoncées portent sur trois points : les opérations asynchrones, la mise en cache et la reprise sur erreur. Le README les présente comme intégrées et fonctionnant à toute échelle, sans donner de détail sur la granularité du cache ni sur la politique de nouvelle tentative. Un composant CodeExecutor est mentionné dans les notes de version, avec quatre backends : local (multiprocessing), Ray, Docker et e2b. Cela signifie que le projet ne se limite pas à produire du texte : il peut exécuter le code généré, ce qui déplace la question de la validation vers celle de l'isolation. Le README ne précise pas les garanties de sécurité de chacun de ces backends, et c'est un point à vérifier dans la documentation avant de faire tourner du code produit par un modèle sur une machine de production.

Installation et premiers pas

L'installation tient en une commande : pip install bespokelabs-curator. Le paquet publié sur PyPI s'appelle bespokelabs-curator, tandis que le module importé est curator. Le README renvoie à la documentation en ligne pour les tutoriels et la référence de l'API, sans inclure d'exemple de code complet dans l'extrait fourni. On y trouve en revanche une liste d'exemples dans le dépôt : extraction de caractéristiques produit, analyse de sentiment aspectuelle, RAFT pour le RAG spécialisé, génération de poèmes avec LoRA fine-tuning, et fine-tuning managé sur Fireworks AI. Les intégrations de fine-tuning mentionnées dans les notes de version incluent un FireworksTrainer et un TinkerTrainer, décrits comme partageant la même interface. Le README ne documente pas les clés de configuration attendues ni les variables d'environnement pour les fournisseurs. Cette information se trouve vraisemblablement dans la référence de l'API, mais elle est absente du matériel fourni, et il serait imprudent d'affirmer quoi que ce soit sur la façon dont les identifiants sont lus.

Le traitement par lots, argument central et source de contraintes

Les notes de version reviennent plusieurs fois sur le support des API par lots, présenté comme un moyen de réduire les coûts de moitié. C'est le mécanisme économique du projet : au lieu d'envoyer les requêtes une par une, Curator les regroupe et exploite les remises consenties par les fournisseurs sur les traitements différés. La contrepartie n'est pas mentionnée dans le README. Un traitement par lots implique des délais de retour plus longs et une granularité d'erreur différente : un lot qui échoue peut invalider plusieurs requêtes d'un coup. La reprise sur erreur annoncée doit donc gérer ce cas, mais la documentation fournie ne décrit pas la stratégie. Autre point, le support par lots dépend du fournisseur : le README cite OpenAI, Anthropic, Gemini et des API compatibles. Si le modèle visé n'expose pas d'API par lots, l'avantage de coût disparaît et il reste la couche asynchrone et le cache.

Limites visibles et cas où Curator n'est pas le bon outil

La première limite tient à la dépendance à une API d'inférence externe. Curator ne fait pas tourner de modèle lui-même : il orchestre des appels. Sans clé d'API et sans budget, la bibliothèque ne produit rien. Pour un projet qui doit fonctionner hors ligne ou sur un cluster isolé, l'intégration vLLM mentionnée dans le README est la seule piste, et le matériel fourni ne dit pas à quel point elle est complète par rapport aux fournisseurs cloud. La deuxième limite concerne le versionnement. La version publiée est v0.1.27, ce qui place le projet en phase initiale. Les notes de version montrent une cadence irrégulière : v0.1.25 en mai 2025, v0.1.26 en juillet 2025, puis v0.1.27 en mars 2026. Une API qui bouge à ce rythme impose de figer les versions dans un pipeline de production. Troisième limite : le README ne dit rien sur la qualité des données produites. Générer un jeu de données synthétique ne garantit pas qu'il soit utile pour l'entraînement, et Curator ne prétend pas évaluer cet aspect. Enfin, pour une extraction structurée ponctuelle sur quelques centaines de lignes, la bibliothèque ajoute une couche d'abstraction et un ensemble de dépendances qui ne se justifient pas face à un script d'appel direct.

Ce qui distingue Curator d'un simple client LLM

Un client comme le SDK officiel d'OpenAI ou d'Anthropic sait envoyer des requêtes et recevoir des réponses. Il ne sait pas décider quelles requêtes ont déjà été exécutées, ni reprendre un lot interrompu, ni exécuter le code produit. Curator se place au niveau au-dessus : il gère l'état du pipeline. La différence est concrète quand un job de plusieurs milliers de générations s'interrompt à mi-parcours. Avec un client brut, il faut relancer et payer à nouveau les requêtes déjà effectuées, à moins d'écrire soi-même la logique de cache. Le README affirme que Curator intègre cette mise en cache, ce qui est l'argument principal face à un script maison. L'autre différence est le CodeExecutor, absent des SDK classiques, qui ajoute une capacité d'exécution et donc une surface de risque supplémentaire. Sur le plan de la licence, Apache-2.0 autorise l'usage commercial et la modification, avec obligation de conserver les mentions de copyright et le texte de licence, et une clause de brevets. Cela reste une description du texte de licence, pas un avis juridique.

Coût de maintenance et suites à donner

Le coût de maintenance se lit à deux niveaux. Le premier est le coût d'inférence, qui dépend entièrement du fournisseur et du volume généré. Le second est le coût de suivi des versions de Curator lui-même. Avec une API en v0.1.x et des publications espacées, il faut prévoir de relire les notes de version à chaque mise à jour et de tester le pipeline après chaque changement. Le README ne mentionne pas de politique de compatibilité ascendante. Pour un projet en production, épingler la version dans requirements.txt est la seule protection évidente. La question à trancher avant de s'engager porte sur le fournisseur d'inférence : si le modèle retenu n'a pas d'API par lots et que le volume est important, l'économie annoncée ne se matérialise pas, et l'intérêt de Curator se réduit à sa couche de cache et de reprise. C'est cette vérification, faite sur la documentation de l'API concernée et non sur celle de Curator, qui détermine si l'adoption se justifie.

Conclusion éditoriale

Curator convient aux équipes qui disposent déjà d'un budget d'inférence LLM et veulent générer des jeux de données de post-entraînement reproductibles en Python. Il ne convient pas à qui cherche une interface graphique ou un service hébergé sans code. Avant d'adopter, vérifier le support du fournisseur d'inférence visé dans la documentation et confirmer que la version publiée sur PyPI correspond bien à v0.1.27.

Sources officielles

1. bespokelabsai/curator on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases