PDE - Ingesting and Processing Data - Section 2.3

Apply AI and ML for data enrichment during ingestion and processing, and integrate new data sources.

Use Vertex AI models and LLM prompting within ingestion pipelines to enrich incoming data with classifications, entity extractions, or generated attributes. Recognise when AI enrichment should occur at ingest time versus as a separate downstream processing step.

Vertex AILLM promptingData enrichment

Practice question for this objective

Free sampleIngesting and Processing Datamedium

A customer support team wants to enrich support tickets with a structured priority field and a short suggested next action, generated by a Vertex AI large language model during ingestion. The prompt currently contains only the ticket body, and outputs are inconsistent in format across tickets, which breaks the downstream BigQuery loader. Which prompting change is most likely to produce reliably structured enrichment without retraining the model?

  • ALower the temperature to zero and keep the same free-text instruction, trusting that deterministic decoding will force the model to emit the same JSON shape on every ticket.
  • BAdd a system instruction that names the output keys, gives two or three full input output examples in the required JSON shape, and asks the model to respond with JSON only. Correct
  • CSend each ticket twice in the same prompt, once asking for a priority and once asking for a next action, then merge the two free text answers in the pipeline using string parsing rules.
  • DMove the ticket body into the system role and leave the user role empty, on the assumption that system role content is treated as more authoritative and therefore produces more structured output.
Use a schema instruction plus few shot examples to make an LLM emit reliably structured enrichment during ingestion. Large language models follow patterns that are present in their prompt. Combining an explicit instruction that names the keys with a small number of input output examples in the target shape is the documented way to constrain output format, and asking for JSON only suppresses surrounding prose. This is more effective than tuning decoding parameters alone because the model needs both a target schema and a signal to stick to it.

Why A is wrong: Lowering temperature reduces randomness in token choice but does not teach the model what shape the output should take. With no schema or example in the prompt the model can still emit prose, lists, or differently named keys, so the loader will continue to break on edge cases.

Why B is correct: A clear instruction plus a small set of in context examples is the standard few shot pattern for steering an LLM to a fixed schema, and asking explicitly for JSON only reduces stray prose. This makes downstream parsing reliable without any fine tuning, which is exactly what the team needs at ingestion time.

Why C is wrong: Duplicating the call doubles cost and latency while still leaving each answer as free text that the pipeline must parse with brittle regular expressions. It treats a prompt design problem as an engineering problem, which is why prepared candidates sometimes pick it.

Why D is wrong: Putting content in the system role does not change how the model formats its output, only the relative weight of instructions. Without a schema description or examples in either role, the model has no reason to emit a particular JSON shape, so structure remains inconsistent.

See more PDE practice questions, answers explained.

More in this domain

Back to all Ingesting and Processing Data objectives, or the PDE cert hub.

Examworthy is not affiliated with or endorsed by Google Cloud. Original, blueprint-aligned practice material only.