Dolma : le corpus de 3 000 milliards de tokens et la boîte à outils qui l'a produit
Data and tools for generating and inspecting OLMo pre-training data.
En bref
- De quoi s’agit-il ?
- Le dépôt allenai/dolma contient deux objets distincts : un corpus ouvert de 3 000 milliards de tokens publié sur HuggingFace, et un toolkit Python pour filtrer et dédupliquer des corpus de pré-entraînement. Voici ce que le matériel fourni permet réellement d'affirmer sur chacun.
- À qui s’adresse-t-il ?
- Adoptez le toolkit Dolma si vous devez produire un corpus de pré-entraînement reproductible avec des filtres documentés, et si votre équipe accepte d'écrire ses propres taggers Python pour tout ce qui sort du périmètre Gopher, C4 et OpenWebText. Ne l'adoptez pas si vous cherchez un pipeline de nettoyage clé en main avec un catalogue de filtres étendu : le README ne cite que trois familles de taggers intégrés, et rien dans le matériel fourni n'indique un registre plus large.
- 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 22 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
Deux projets dans un seul dépôt
Le nom dolma recouvre deux choses que le README sépare explicitement. D'un côté le Dolma Dataset, un corpus ouvert de 3 000 milliards de tokens mêlant contenu web, publications académiques, code, livres et matériel encyclopédique, distribué sur le HuggingFace Hub à l'adresse huggingface.co/datasets/allenai/dolma. De l'autre le Dolma Toolkit, dont ce dépôt contient le code source, et qui sert à curer des jeux de données pour l'entraînement de modèles. Le corpus a été constitué comme matériau d'entraînement pour OLMo, le modèle d'AI2.
Cette dualité a une conséquence pratique immédiate. Si vous cherchez des données, vous n'avez pas besoin de cloner ce dépôt : le corpus est sur HuggingFace. Si vous cherchez à construire votre propre corpus avec la même méthodologie, c'est le toolkit qu'il faut installer. Les deux objets ne partagent pas la même licence, et le README insiste sur ce point en renvoyant à un billet de blog dédié au passage du corpus sous ODC-BY.
À qui le toolkit s'adresse vraiment
Le problème résolu est celui de la curation à grande échelle. Filtrer des milliards de documents pour n'en garder qu'une fraction utile demande trois choses que le toolkit revendique : de la parallélisation, de la portabilité entre machine unique, cluster et cloud, et des filtres prêts à l'emploi. Le README cite Gopher, C4 et OpenWebText comme taggers intégrés.
Le public visé est donc étroit : des équipes qui pré-entraînent ou préparent le pré-entraînement d'un modèle de langage et qui doivent justifier, documenter et reproduire leurs choix de filtrage. Ce n'est pas un outil d'exploration de données pour analyste, ni une bibliothèque de nettoyage de texte généraliste. La référence à OLMo dans le README n'est pas décorative : le toolkit a été construit pour rendre une recette de corpus reproductible, pas pour offrir un catalogue de transformations variées.
Le mécanisme : taggers, déduplication, parallélisme
Le README décrit quatre mécanismes. Le premier est un ensemble de taggers intégrés, c'est-à-dire des filtres nommés d'après les corpus dont ils proviennent (Gopher, C4, OpenWebText). Le deuxième est une déduplication de documents présentée comme rapide, implémentée avec un Bloom filter écrit en Rust. Le troisième est la parallélisation, qui permet selon le README de traiter des milliards de documents en parallèle. Le quatrième est l'extensibilité : des taggers personnalisés et la prise en charge de stockages compatibles S3.
Ces éléments dessinent une architecture où les documents traversent une chaîne de filtres, avec une étape de déduplication dont le coût mémoire est borné par un filtre probabiliste plutôt qu'un index exact. C'est un choix classique à cette échelle, mais il implique un compromis que le README ne quantifie pas : un Bloom filter peut produire des faux positifs, donc écarter des documents qui n'étaient pas des doublons. Le matériel fourni ne donne ni taux d'erreur, ni paramètres de dimensionnement, ni valeurs par défaut. Sur ce point précis, la documentation publique du dépôt ne permet pas de conclure, et il faudra lire le code ou les pages de docs pour trancher.
Mise en route
L'installation tient en une commande, telle que donnée par le README :
pip install dolma
Le README renvoie ensuite vers le répertoire /docs du dépôt pour l'usage détaillé. C'est une limite du matériel dont je dispose ici : je ne peux pas citer de clé de configuration, de nom de commande CLI ou de fichier YAML précis, parce qu'ils ne figurent pas dans le README nettoyé. Toute description de configuration serait une invention.
Ce que je peux dire, c'est que la disponibilité de dolma sur PyPI via pip est cohérente avec la présence d'un tag v1.2.1 daté du 7 juillet 2025. Rien dans le matériel fourni ne garantit que la version publiée sur PyPI corresponde à ce tag au moment où vous lisez ces lignes. Vérifiez la version installée avant de vous appuyer sur un comportement décrit dans les notes de version.
Le corpus Dolma et sa licence séparée
Le corpus de 3 000 milliards de tokens est publié sous ODC-BY, pas sous Apache-2.0. Le README consacre un lien à cette décision et à son explication. La distinction compte : Apache-2.0 couvre le code du toolkit, ODC-BY couvre les données. Une attribution est requise pour le corpus, et son périmètre exact relève de la lecture du texte de licence, pas de cet article.
Un point pratique souvent négligé : utiliser le toolkit pour produire votre propre corpus ne vous place pas sous ODC-BY pour votre résultat. La licence du corpus Dolma s'applique au corpus Dolma. Le README ne dit rien d'autre sur ce sujet, et je m'en tiens là.
Quand Dolma n'est pas le bon outil
Le toolkit suppose que vous savez déjà quels filtres vous voulez appliquer. Si votre besoin est d'explorer un corpus pour découvrir ce qu'il contient, ou de nettoyer du texte pour une tâche en aval qui n'est pas du pré-entraînement, la mécanique de taggers et de déduplication est un détour.
Deuxième cas défavorable : la dépendance à un Bloom filter en Rust. Elle introduit une contrainte de compilation et un comportement probabiliste. Une équipe qui a besoin d'une déduplication exacte et vérifiable, par exemple pour des raisons de conformité, devra soit accepter les faux positifs, soit contourner cette étape. Le README ne propose pas d'alternative exacte documentée.
Troisième cas : le périmètre des taggers. Trois familles intégrées, c'est peu si votre corpus est multilingue ou non web. Le README mentionne l'extensibilité, donc la sortie existe, mais elle passe par l'écriture de code Python, pas par un fichier de configuration.
Face à un pipeline de filtrage générique
L'alternative la plus directe est un pipeline de traitement de texte généraliste, du type de ceux construits autour de bibliothèques de manipulation de données et de modèles de langage statistiques. La différence d'approche est nette. Un tel pipeline vous donne des primitives : compter des mots, appliquer une expression régulière, calculer un score de perplexité. Vous assemblez vous-même la chaîne de filtres et vous assumez la responsabilité de sa cohérence.
Dolma fait l'inverse. Il embarque des filtres nommés d'après des corpus publiés, ce qui rend vos choix comparables à ceux d'autres équipes et citables dans un article. Le prix est la rigidité : vous héritez des définitions de Gopher ou de C4 telles qu'elles sont implémentées, et adapter un seuil suppose de comprendre le tagger correspondant. Si votre objectif est la reproductibilité et la comparabilité, Dolma est mieux placé. Si votre objectif est la flexibilité maximale sur des données atypiques, un pipeline générique vous coûtera moins de détours.
Coût de maintenance et de mise à jour
Le dépôt n'est pas archivé et le dernier push enregistré date du 24 août 2026, ce qui indique une activité continue. Les versions récentes s'échelonnent entre février 2025 (v1.1.2), juin 2025 (v1.2.0) et juillet 2025 (v1.2.1). Le rythme observé sur ces trois publications est irrégulier : environ quatre mois entre v1.1.2 et v1.2.0, puis un mois avant v1.2.1. Je ne dispose pas des notes de version, donc je ne peux pas dire ce qui a changé ni si des ruptures d'API sont intervenues entre ces versions.
Le coût réel de maintenance se situe ailleurs : dans vos taggers personnalisés. Chaque filtre que vous écrivez devient du code que vous devez suivre au fil des versions du toolkit. Le README ne documente pas de garantie de stabilité d'interface pour l'extension par taggers, et le matériel fourni ne permet pas de l'affirmer. Sur le plan des licences, Apache-2.0 pour le code et ODC-BY pour le corpus sont deux régimes distincts, et l'attribution requise par ODC-BY mérite une lecture directe du texte de licence avant diffusion d'un corpus dérivé.
Conclusion éditoriale
Adoptez le toolkit Dolma si vous devez produire un corpus de pré-entraînement reproductible avec des filtres documentés, et si votre équipe accepte d'écrire ses propres taggers Python pour tout ce qui sort du périmètre Gopher, C4 et OpenWebText. Ne l'adoptez pas si vous cherchez un pipeline de nettoyage clé en main avec un catalogue de filtres étendu : le README ne cite que trois familles de taggers intégrés, et rien dans le matériel fourni n'indique un registre plus large. Avant de vous engager, vérifiez deux points précis : la version de dolma installée par pip par rapport au tag v1.2.1, et les conditions exactes de la licence ODC-BY appliquée au corpus, qui diffèrent de l'Apache-2.0 du code.
Notes de la communauté