NeMo Data Designer を採用する前に読む: 列指向の合成データ生成パイプライン

LLM に丸投げしない合成データ生成という立場

合成データ生成の多くは、プロンプトを書いてモデルに投げ、返ってきたテキストを集めるという形を取る。この方法は少量なら十分だが、量が増えると困ることが出てくる。カテゴリの分布を意図通りにしたい、ある列の値に応じて別の列の内容を変えたい、生成結果を機械的に検証したい。プロンプトだけでは、こうした制御はモデルの気分に依存する。Data Designer はここを設定オブジェクトで明示する方向に振っている。README では「diverse statistical distributions, meaningful correlations between fields, or validated high-quality outputs」を扱えると説明されており、対象読者は評価用データセット、ファインチューニング用コーパス、エージェントのツール呼び出しトレースなどを継続的に作り直す必要があるエンジニアである。

列を積み上げる: DataDesignerConfigBuilder の構造

中心にあるのは DataDesignerConfigBuilder で、これに列を追加していく。README の例では、まず SamplerColumnConfig で product_category という列を作り、SamplerType.CATEGORY と CategorySamplerParams の values で取りうる値を列挙している。次に LLMTextColumnConfig で review 列を追加し、prompt の中で {{ product_category }} を参照する。つまり列は独立ではなく、後から定義した列が前の列の値をテンプレート変数として受け取る。依存関係はこの参照によって表現され、生成順序もそこから決まる。サンプラ、LLM、画像モデル、既存のシードデータセットが列の供給元として並列に扱われる点が、単一の生成関数を呼ぶライブラリとの差である。検証も列の概念の上に載っており、Python、SQL、カスタムバリデータ、LLM ジャッジがドキュメントで案内されている。

インストールから preview() までの実際の手順

導入は pip install data-designer で行う。ソースから入れる場合は git clone の後に make install を実行する。次にモデルプロバイダの API キーを環境変数で渡す。README が挙げているのは NVIDIA_API_KEY、OPENAI_API_KEY、OPENROUTER_API_KEY の三つで、いずれか一つ以上を設定する。ここで注意すべきは、モデルのエイリアスがコード中で文字列として参照される点だ。例では model_alias="nvidia-text" が使われており、この名前がどの実モデルに対応するかは設定側で決まる。CLI には data-designer config providers、data-designer config models、data-designer config list が用意されており、対話的にプロバイダとモデルを登録し、現在の設定を確認できる。生成の前に preview(config_builder=config_builder) を呼び、display_sample_record() でサンプルを目視する流れが README に示されている。

エージェント経由のスキーマ設計とその依存関係

このリポジトリはコーディングエージェント向けの skill を配布しており、npx skills add NVIDIA-NeMo/DataDesigner でインストールする。README によれば Claude Code と Codex でテストされている。skill を入れると、欲しいデータセットを自然言語で説明するだけでスキーマ設計、検証、生成までをエージェントが進めるという。ただしこれは利便性の話であって、生成の再現性を担保するのはあくまで設定オブジェクトである。エージェントが組み立てた DataDesignerConfigBuilder の中身を読まずに本番投入すると、どの列がどの順で生成されたのかを後から追えなくなる。設定をコードとして保存し、レビューの対象にする運用が前提になる。

テレメトリとライセンスの実務的な扱い

README にはテレメトリの節があり、どのモデルが合成データ生成に使われたかの集計を収集し、コミュニティと共有すると書かれている。個人の行動追跡には使わないという説明だが、送信を止めたい場合は NEMO_TELEMETRY_ENABLED=false を設定する。ライセンスは Apache-2.0 で、リポジトリの LICENSE を参照する形になっている。加えて README の注記が重要で、このプロジェクトは追加のサードパーティ製オープンソースソフトウェアをダウンロードしてインストールするため、利用前にそれぞれのライセンス条項を確認するよう求めている。生成物そのものの権利や、利用するモデルプロバイダの規約はこのライセンスとは別の論点であり、ここで判断できる材料は提供されていない。

向かない場面: モデル依存と検証コスト

制約はいくつかある。第一に、生成品質は接続先モデルに強く依存する。README が既定として挙げるのは NVIDIA Build API、OpenAI、OpenRouter の三つで、社内のセルフホストモデルを使う場合に何が必要かは提供資料からは読み取れない。第二に、依存関係を持つ列設計は、列を一つ足すたびに他の列への影響を考える作業を伴う。数十件のテキストを一度作って終わりという用途では、この設計コストは回収できない。第三に、バリデータや LLM ジャッジを挟むほど生成一件あたりの計算が増える。大量生成の前に、検証をどこまで必須にするかを決めておかないと、パイプライン全体の所要時間が読めなくなる。README には性能に関する数値の記載はなく、この点は実測するしかない。

代替手段との違い: テンプレート生成とファインチューニング

比較対象として分かりやすいのは、Faker のようなルールベースのテンプレート生成である。あちらは乱数と辞書で決定的に値を埋めるため高速で、依存関係も自分でコードに書く。代わりに、自然文のレビューやツール呼び出しの引数のように、文脈に応じた文章を作ることはできない。Data Designer はその部分を LLM 列に任せ、統計的な分布や列間の相関はサンプラ側で制御する。もう一つの比較対象は、実データに対するファインチューニングやデータ拡張である。既存データを少し変形して増やす手法は分布のずれが小さいが、そもそも存在しないカテゴリやレアケースを意図的に作り出すことは難しい。Data Designer はシードデータから出発するモードも持つため、実データを土台にしつつ足りない領域を補うという中間の使い方ができる。どちらが優れているという話ではなく、ゼロから作る必要があるかどうかで選ぶ。

導入判断の前に確認しておくこと

最初に確かめるべきは、利用予定のプロバイダが data-designer config providers で登録できるかどうかである。ここが通らなければ以降の話は進まない。次に、生成したデータセットの配布や再学習利用が、接続するモデルの規約と自組織のポリシーの両方で許されるかを確認する。README の注記が求めているサードパーティライセンスの確認もこの段階で行う。最後に、preview() で数件を出し、意図した分布と依存関係が実際に再現されるかを見る。リリースは v0.9.x 系が続いており、0.x の間は設定 API が動く可能性がある。設定ファイルをバージョン管理下に置き、アップグレード時に差分を確認できる形にしておくことが、この段階で取れる最も具体的な備えである。

編集部の結論

既存のデータセットに近い統計的性質を持つ合成データを、列単位で制御しながら再現可能な形で量産したいチームに向く。逆に、単発のプロンプトでテキストを数十件生成したいだけなら、DataDesignerConfigBuilder と列タイプを覚えるコストに見合わない。導入前に確認すべきは、使用予定のモデルプロバイダが data-designer config providers で設定可能か、そして生成したデータを自社の用途で再配布できるかというライセンス条件である。検証は preview() で数件を目視するところから始め、NEMO_TELEMETRY_ENABLED=false を設定するかどうかを組織のポリシーで先に決めておく。

公式情報源

1. License: Apache-2.0
2. NVIDIA-NeMo/DataDesigner on GitHub
3. Project website
4. README
5. Releases