feat: generate an exact number of rows matching a declared criterion

オープン
  • 何か問題がありますか？
#790 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

  • #817 @nabinchha による — マージされずにクローズ

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
静か
技術スタック
python
領域
backend, data-engineering

調査の方向性

設計の信頼できる唯一の情報源、アーキテクチャ図、実装フェーズ、テスト計画、Definition of Doneが記載されている plans/790/engine-native-record-selection.md から始めます。通常の DataDesigner.create() の実行で、候補バッチ、受け入れられた行、チェックポイント、再開時の動作がどのように処理されるかを追跡します。完了とは、一覧にある V1 の受け入れ基準を満たすことを意味します。これには、正確なターゲット、上限付きの枯渇、受け入れ数がゼロのバッチの永続化、再開の正確性、受け入れられた行のみの処理が含まれます。

索引モデルが issue の本文から書いたものです。

説明

enhancement

Problem

DataDesigner users can generate candidate rows and filter them afterward, but they cannot declaratively request an exact number of rows that satisfy a quality or validation criterion. Doing this today requires user-managed loops across multiple create() calls, including candidate budgeting, artifact extension, trimming, and resume behavior.

Examples include generating 5,000 answers above a judge threshold, 10,000 policy-compliant conversations, or a fixed number of successful tool-use traces.

Proposed feature

Add engine-native record selection to a normal DataDesigner.create() run. A user declares a boolean predicate column and a hard candidate limit. When selection is configured, num_records means the desired number of accepted output rows:

builder.with_record_selection(
    dd.RecordSelectionConfig(
        predicate_column="meets_criteria",
        max_candidate_records=20_000,
        on_exhausted="raise",
    )
)

results = data_designer.create(builder, num_records=5_000)

The engine generates immutable candidate batches, evaluates the predicate, checkpoints accepted rows, and continues until the target is met or the candidate budget is exhausted.

V1 scope

  • Treat num_records as the accepted-row target when record selection is enabled.
  • Require an explicit boolean predicate column and hard max_candidate_records bound.
  • Support raise and return_partial exhaustion behavior.
  • Preserve deterministic candidate ordering and trim final overshoot exactly.
  • Track candidate attempts separately from accepted output.
  • Persist candidate-batch completion markers so zero-acceptance batches and resume are correct.
  • Preserve normal DAG generation, processors, profiling, plugins, and model-usage accounting.
  • Run one candidate batch at a time while retaining the scheduler's normal within-row-group concurrency.

Out of scope

  • Concurrent candidate batches.
  • Early cancellation of downstream row work after predicate rejection.
  • Exporting every rejected candidate.
  • Unbounded generation based on an expected acceptance rate.
  • Row-count-changing after-generation processors.

These are optional performance or expansion ideas, not requirements for a complete V1.

Acceptance criteria

  • A single create() call can reliably return exactly X matching rows.
  • Generation is bounded and exhaustion behavior is explicit.
  • Candidate progress is independent of accepted parquet row counts.
  • Runs resume after any committed candidate batch without repeating candidate offsets or accepted output.
  • Zero-acceptance candidate batches remain durably complete.
  • Output processing and profiling operate on accepted rows only, while usage metadata includes rejected work.
  • Default-buffer behavior works when the target is reached only after three or more candidate batches.
  • Documentation explains cost, bounds, partial exhaustion, and resume semantics.

Investigation and context

PR #773 explored workflow-level repetition. Real-run testing showed that extending a static row-group plan can stall when small increments remain inside the same buffer boundary, and that an interrupted append flow can request a target smaller than persisted output. Record selection therefore needs engine-owned candidate progress rather than repeated public create() orchestration.

Detailed plan

The source-of-truth design, architecture diagrams, implementation phases, test plan, and definition of done are in plans/790/engine-native-record-selection.md.

主要言語
Python
スター
2.4k
フォーク
243
平均マージ
1日 3時間
マージ済み PR（30日）
88

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NVIDIA-NeMo/DataDesigner のほかの issue

NVIDIA-NeMo/DataDesigner の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。