NVIDIANVIDIA-Certified Professional: Agentic AI2026-106.4 Conduct data quality checks, augmentation, and preprocessing.
Enrich sources and validate synthetic additions
Completed by the knowledge check
Learning objective
Enrich data with metadata and augment it with validated synthetic data.
Core idea
Metadata explains how to interpret and select a document. Synthetic data supplies additional examples, phrasings, or task cases. Both can improve an agent’s coverage, but neither turns an unsupported assertion into an authoritative fact.
Keep the original source, attached metadata, generated material, and validation result distinguishable. Source identity and access ownership belong to 6.3.3, while 6.4.2 owns the baseline quality checks. Here you decide which enrichment fields are useful, where generated rows help, and what must be true before those rows enter a training or evaluation dataset.
How it works
Define metadata that changes a decision
NVIDIA RAG Blueprint declares user-defined fields in a collection’s metadata_schema and attaches per-file values through custom_metadata. Each schema entry names its name and type; required makes a field mandatory, array_type specifies array element types, and max_length bounds strings or arrays.
Choose fields from real retrieval distinctions. A returns assistant might need market, product family, policy revision, and effective date because identical words can describe different eligibility rules. A descriptive tag that no query or reviewer uses adds generation and maintenance work without improving selection.
Separate source-derived fields from inferred fields. Populate a policy revision from the source registry; treat a model-generated topic label as a proposal that can be reviewed against the document. A generated label such as “public” must not become the authority for access. Maintain application-defined provenance fields recording how each derived value was produced and checked, and declare them in the metadata schema if you submit them to the Blueprint.
The Blueprint also manages filename and page_number, plus start_time and end_time for applicable audio or video segments. Its type, subtype, and location names are reserved by NeMo Retriever Library and cannot be used in custom metadata schemas. Inventing a field under a reserved name causes a validation problem rather than useful enrichment.
Metadata helps only if consumers use it correctly. In the Blueprint’s Milvus filter syntax, a user-defined value is addressed as content_metadata["field_name"]. Verify a market or revision restriction with known matching and nonmatching records. A plausible description of a filter is weaker than checking the actual selected documents; vector-database optimization itself belongs to 6.2.
Generate additions from explicit seeds
NeMo Curator integrates NeMo Data Designer through DataDesignerStage. The stage accepts either config_builder or data_designer_config_file, takes a DocumentBatch as a seed dataset, calls DataDesigner.preview(), and returns an enriched batch with generated columns and token-usage metrics.
The documented column types separate sources of variation. SamplerColumnConfig generates structured values; ExpressionColumnConfig derives values through Jinja expressions; LLMTextColumnConfig generates text using prompts that can reference other columns. Prefer a deterministic expression when a value is already derivable from a trusted field. Use an LLM where you need linguistic variation, not to invent a policy’s refund window.
Scope the generation request to a known gap, such as paraphrases of a rare but important policy exception. Include the authoritative clause and its revision in the seed row. Preserve application fields such as seed_id, generator_revision, and is_synthetic so generated rows can be traced and separated from observed production cases. Those names describe your dataset design, not reserved Curator metadata.
The data-designer package is supplied through Curator’s sdg_cpu or sdg_cuda12 extras, not its text extras. The local judge workflow described here requires both text_cuda12 and sdg_cuda12; a text-cleaning environment alone does not supply that workflow’s dependencies.
Validate structure, grounding, and usefulness
Apply the baseline checks from 6.4.2 to generated rows as well as real ones. Then verify that generated answers follow the supplied source and that generated questions are answerable from it. A syntactically valid answer can still invent an exception or combine incompatible policy revisions.
Curator’s LLMJudgeWorkflow implements semantic assessment with Jinja prompts and YAML rubrics. It requires Linux, NVIDIA GPUs, and a Hugging Face-format model supported by the installed vLLM version. Curator starts each configured model locally through Dynamo/vLLM; approximate GPU use per model is num_replicas * tensor_parallel_size for the run.
A judge can receive the question, generated answer, and grounding context, then produce structured scores and reasoning. Define the criterion narrowly: whether every eligibility condition is supported by the attached policy clause. A fluent style score is a different axis from factual support.
The workflow’s execution.stages determines judge order. A judge’s scores define allowed rubric options. Top-level filters name a judge, score, operator, and value; they run immediately after the stage that produces the relevant score. For example, operator: eq and value: 1 can retain a team-defined binary support score of 1. The rubric must define that value explicitly; it is not a built-in factuality threshold.
Before filtering a synthetic batch, calibrate its judge against manually reviewed labels (see 3.1.2); accepted yield alone cannot establish that the judge is correct or that the assistant improved.
Keep source families together when dividing training and evaluation examples. A paraphrase of a training seed should not inflate the apparent independence of a held-out evaluation case. Track this split through the retained seed_id; evaluation-dataset design is covered in 3.1.1.
Account for rejected rows and GPU time
DataDesignerStage reports num_input_records, num_output_records, ndd_running_time, and median input and output tokens per record. Compare record counts with the validation results so a high generation volume does not conceal poor accepted yield.
In LLMJudgeWorkflow, fewer output rows can result from explicit filters, malformed structured responses, or truncated completions. NVIDIA recommends inspecting a small retry with with_trace: last_message and checking completion length and rubric output. Repair the prompt, output allowance, or filtering rule that caused loss before scaling the same run.
Place inexpensive deterministic checks before semantic judging, and put a rejecting judge before a later expensive judge when its result makes further work unnecessary. That ordering reduces wasted model calls. Budget generation and validation together; acceptance cost includes the candidates you reject. Rows rejected at a judge’s filters leave before the later, expensive judge runs.
Key distinctions and trade-offs
Choose the enrichment mechanism by the information it contributes:
| Addition | Deciding condition | Mechanism | Cost or failure risk |
|---|---|---|---|
| Source metadata | A trusted value changes document selection | metadata_schema, custom_metadata | Mapping and schema maintenance |
| Derived metadata | A value follows from existing fields | ExpressionColumnConfig | Incorrect derivation propagates systematically |
| Generated examples | Linguistic or task coverage is missing | DataDesignerStage, LLMTextColumnConfig | Generation tokens and unsupported claims |
| Validated synthetic subset | Candidates pass calibrated checks | LLMJudgeWorkflow, filters | Local GPU occupancy, human calibration, correlated errors |
Generating a document label and generating an answer are different enrichment decisions. The former influences what gets retrieved; the latter can teach a model what to say. Review each against the failure it can introduce rather than approving both with one generic quality score.
Architecture / decision scenario
A retailer’s returns assistant serves three markets. A reviewed dataset has 2,000 real examples, but only 40 cover a regional exception. The team limits generation to 600 candidates and allocates two NVIDIA GPUs for one hour to the local judge, with num_replicas=1 and tensor_parallel_size=2. A preflight run must show that loading and judging fit that allocation; these are scenario budgets, not product limits.
A proposed shortcut creates 600 free-form questions and answers from a general returns prompt, then accepts every well-formed row. The retail policy owner rejects it because the exceptions differ by market and revision. Syntax cannot establish the correct refund rule.
Instead, the data team attaches market and revision through declared custom_metadata, seeds generation from approved exception clauses, and varies customer phrasing through LLMTextColumnConfig. A source-grounding rubric checks each candidate against its attached clause. Of 600 candidates, 450 pass structural and semantic review; 150 are excluded and their rejection causes are retained. The owner reviews a sample across all three markets before release. Seed-based splits keep paraphrases out of the held-out source families, and the team evaluates improvement on real cases separately from synthetic coverage.
Common exam traps
- Using a generated metadata label as access authority.
- Writing custom fields under reserved names.
- Assuming text extras install Data Designer.
- Treating synthetic answers as authoritative source updates.
- Equating structured output with factual support.
- Counting rejected or malformed rows as successful augmentation.
- Mixing seed paraphrases across training and held-out evaluation.
What to remember
Metadata must support a real selection or review decision. Generate synthetic rows from explicit, traceable seeds and validate them against their source, not their fluency. Measure accepted yield and total validation cost, and preserve the distinction between generated examples and authoritative knowledge.
Knowledge check
A model assigns each document a sensitivity label such as “public” or “internal”, and the team wants retrieval restricted by allowed_groups. The source registry records each document’s approved access groups. How should allowed_groups be populated?
Seed rows for a Data Designer run contain trusted market and policy_revision columns. Each generated row needs a policy_ref value that joins them, such as EU-r7. Which column configuration fits?
LLMTextColumnConfig with a prompt that references both columnsSamplerColumnConfig that draws from the list of known referencesExpressionColumnConfig with a Jinja template over both columnsLLMTextColumnConfig checked afterwards by an LLMJudgeWorkflow judgeA team generates 600 paraphrased questions from 40 approved exception clauses, each recorded with its seed_id, and wants a held-out evaluation set that measures generalization to unseen clauses. How should it split the rows?
seed_id , keeping each seed’s paraphrases in one splitseed_id makes the evaluation set test clauses the training set never saw; a random, score-based or batch-based split can place paraphrases of one seed on both sides.An LLMJudgeWorkflow run over 600 synthetic candidates returns 380 rows, while the team’s filter was expected to remove about 100. Before scaling the same run to 6,000 candidates, the team wants to find where the extra rows were lost with the fewest judge calls. What should it do?
num_replicas and rerun the same 600 candidateswith_trace: last_message