dolma: OLMoの事前学習コーパスを作ったツールキットを、自分のデータで使う
Data and tools for generating and inspecting OLMo pre-training data.
ひと目でわかる
- これは何？
- dolmaは3兆トークンの公開データセットと、そのデータセットを作るために書かれたキュレーションツールキットの二つを指す。ここではツールキット側に焦点を当て、タガー、重複排除、並列実行の仕組みと、採用を決める前に確認すべき点を整理する。
- 誰に向いている？
- すでに大規模なテキスト集合を持ち、GopherやC4のフィルタを自分のパイプラインに組み込みたいチームには向く。逆に、数十GB程度のコーパスを一度きり整形したいだけなら、dolmaの並列実行とBloomフィルタの重複排除は過剰な装備になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 22 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
dolmaという名前が指す二つのもの
リポジトリ名のdolmaは、実は二つの対象を指している。一つはDolma Dataset。ウェブ、学術論文、コード、書籍、百科事典的資料を混ぜた3兆トークンの公開コーパスで、AI2の言語モデルOLMoの学習用に作られた。HuggingFace Hubの huggingface.co/datasets/allenai/dolma から取得でき、ライセンスはODC-BY。もう一つはDolma Toolkitで、こちらがこのリポジトリの中身にあたる。READMEの説明を借りれば、言語モデル向けデータセットのキュレーションを行うためのツールキットであり、データセットそのものではなく、データセットを作るための道具立てだ。両者は同じ名前で呼ばれるが、ライセンスも配布形態も別物なので、最初にどちらが欲しいのかを切り分けておかないと、後で混乱する。
誰のためのツールか: タガーを自作する側と、既製のフィルタで足りる側
このツールキットが解こうとしているのは、生のテキスト集合から学習用コーパスを作る作業の再現性と速度の問題だ。READMEは主要な機能として、並列処理による性能、単一マシンからクラスタ、クラウドまでの可搬性、Gopher・C4・OpenWebTextといった既製のタガー、RustのBloomフィルタによる重複排除、カスタムタガーとAWS S3互換ロケーションへの対応を挙げている。想定読者は、数億文書規模のコーパスを継続的に作り直す必要があるチームだ。逆に、手元の数十GBのテキストを一度だけきれいにしたいだけなら、この道具立ての大半は使わない。タガーという語が示すのは、文書を削るか残すかを判定する関数群であり、その判定基準を自分で設計できることに価値があるかどうかが、採用の分かれ目になる。
タガーとタグ: 文書単位の判定をどう積むか
dolmaの中心にあるのはタガーとタグという考え方だ。タガーは文書を受け取り、何らかの判定結果をタグとして付ける。GopherやC4のタガーは、品質や重複の観点から文書を落とすための基準を実装したものだとREADMEは説明している。パイプラインは複数のタガーを直列に並べ、それぞれの出力タグを見て最終的に残す文書を決める、という流れになる。ここで重要なのは、タガーが単なるフィルタではなく記録装置でもある点だ。どの文書がどの基準で落ちたかを後から追えるため、フィルタの閾値を調整するたびにコーパスの構成がどう変わったかを比較できる。既製のタガーをそのまま使うか、閾値を動かすか、自作のタガーを足すか。この三択を同じ枠組みの中で扱えることが、単発のスクリプトとの差になる。
重複排除をRustのBloomフィルタに任せる設計
重複排除はRust実装のBloomフィルタで行うとREADMEは述べている。Bloomフィルタは確率的データ構造なので、判定には偽陽性が伴う。つまり、実際には重複していない文書が重複と見なされて落ちる可能性がゼロではない。この性質は、厳密な重複排除が必要な用途、たとえば法的に同一性を保証したい文書集合の処理では不利になる。一方で、学習コーパスのように多少の取りこぼしより処理量の方が効いてくる場面では合理的な選択だ。ここは設計上の割り切りであり、dolmaが厳密性より速度を選んだ箇所だと読める。重複排除の結果を監査する必要があるなら、Bloomフィルタ以外の手段を併用する前提で考えるべきで、この点についてREADME以上の保証は読み取れない。
導入手順と実行環境の選び方
インストールはREADMEいわく、ターミナルで pip install dolma を実行するだけ。より詳しい使い方はリポジトリ内の docs ディレクトリに置かれたドキュメントを参照するよう案内されている。実行環境については、単一マシン、クラスタ、クラウドのいずれでも動くとされ、AWS S3互換のロケーションに対応する。つまり入力と出力をローカルディスクに置く構成と、S3に置く構成の両方が想定されている。カスタムタガーを書けば判定基準を自分で足せる。ただし、具体的な設定キーやCLIの引数名、S3接続に必要なパラメータの一覧は、手元にあるREADME本文からは確認できない。導入を決める前に、docs配下の該当ページでサブコマンドと設定項目を実際に確認する必要がある。バージョンはv1.2.1が2025年7月、v1.2.0が2025年6月、v1.1.2が2025年2月にリリースされており、直近はv1.2系だ。
向かない場面: 小規模コーパスと、判定根拠の監査
dolmaが過剰になる場面は二つある。一つは規模の面。並列処理とBloomフィルタによる重複排除は、文書数が数百万を超えて初めて効いてくる。数千から数万文書の整形なら、並列化の設定を考える時間の方が長い。もう一つは厳密性の面だ。前述のとおりBloomフィルタには偽陽性があり、どの文書がどう判定されたかを完全に再現したい用途には向かない。加えて、GopherやC4のタガーは英語圏のウェブテキストを前提に設計された基準であり、日本語を含む他言語のコーパスにそのまま当てると、言語的な特徴を品質低下と誤判定する可能性がある。この点はREADMEに言及がないため、非英語データで使う場合はタガーの閾値を自分で検証する作業が別途必要になる。
datatroveとの違い: パイプラインの組み方
比較対象として挙げやすいのはHuggingFaceのdatatroveだ。どちらも大規模テキストのキュレーションを目的とするが、組み立て方が違う。dolmaはタガーとタグという語彙で処理を表現し、文書に付いたタグを見て残すか落とすかを決める。重複排除はRustのBloomフィルタという単一の実装に寄せている。datatroveは処理をステップの連なりとして記述し、実行基盤を差し替えながら同じパイプラインを回す方向に力を入れている。どちらが優れているという話ではなく、判定基準をタガーという単位で管理したいのか、処理の流れそのものを記述したいのかの違いだ。dolmaを選ぶ理由は、GopherやC4といった既存の基準がすぐ使える状態で入っていることと、OLMoの学習データを作るという実務で使われた経緯があることの二点に集約される。
ライセンスと保守の見取り図
リポジトリのライセンスはApache-2.0。ただしこれはツールキットのソースコードに対するもので、Dolma DatasetにはODC-BYが適用されるとREADMEは明記している。ODC-BYは出典表示を条件とするライセンスであり、データを再配布したり派生物を公開したりする場合は、ツールキットのライセンスとは別にこの条件を満たす必要がある。ここは法的助言ではなく、READMEに書かれている以上のことは判断できない。保守の面では、2025年2月、6月、7月とv1.1.2からv1.2.1まで比較的短い間隔でリリースが続いており、リポジトリはアーカイブされていない。データ処理ツールは入力データの形式が変わると壊れやすいので、バージョンを固定して使うか、更新のたびにタガーの挙動が変わっていないかを確認する運用が要る。
編集部の結論
すでに大規模なテキスト集合を持ち、GopherやC4のフィルタを自分のパイプラインに組み込みたいチームには向く。逆に、数十GB程度のコーパスを一度きり整形したいだけなら、dolmaの並列実行とBloomフィルタの重複排除は過剰な装備になる。導入前に確認すべきは三つ。第一に、pip install dolma で入るバージョンがv1.2.1系かどうか。第二に、対象データに合わせてGopherやC4のタガー設定をどこまで調整する必要があるか。第三に、成果物を再配布する予定があるなら、ツールキットのApache-2.0とDolma DatasetのODC-BYは別物であり、後者には出典表示の条件が付く点。まず小さなサブセットでタガーを一つ通し、どの文書が落ちるかを目で確認するところから始めるのが現実的だ。
コミュニティノート