A data engineer needs to extract structured fields (product name, price, and availability) from thousands of unstructured product descriptions and load them into a database. Which prompting strategy most reliably produces machine-parseable output from an LLM for this pipeline?
- AZero-shot chain-of-thought prompting, asking the model to reason step-by-step before naming each field
- BEmbedding each product description and storing the vector, then using cosine similarity to retrieve the closest known structured record
- CFew-shot prompting with plain-text examples separated by delimiter lines, leaving the output format for the model to infer
- DStructured-output prompting with a JSON schema in the system prompt, constraining the model to emit a fixed key-value object per description Correct
Why A is wrong: Chain-of-thought improves reasoning but produces verbose prose, not a consistent machine-parseable format. Downstream parsers would struggle with inconsistent output shapes across thousands of descriptions.
Why B is wrong: Embeddings plus similarity search retrieves similar items but does not extract fields from the source text. This is a search or clustering technique, not an extraction approach.
Why C is wrong: Few-shot examples guide style but do not enforce a schema. Without an explicit format constraint the model may vary its output structure across samples, breaking automated parsing.
Why D is correct: Structured-output prompting binds the model to a declared schema, guaranteeing field names and types. This is the standard approach for LLM-to-database pipelines where downstream code must parse every response identically.