A developer needs a foundation model to label support tickets using a niche internal scheme of five status codes. A plain instruction that lists the five codes still produces free-text summaries and invented codes instead of the exact labels. No training data is available to fine-tune. Which prompt engineering technique most directly teaches the model the precise output the team wants?
- AAdd a few worked examples to the prompt, each pairing a sample ticket with its correct status code, so the model infers the exact output format from the demonstrations. Correct
- BRaise the temperature so the model explores a wider range of possible status codes before committing to one of the five.
- CIncrease the maximum output token limit so the model has enough room to write out the full status code rather than truncating it.
- DMove the model to a larger context window so the entire list of five status codes fits inside a single request alongside the ticket.
Why A is correct: Correct: few-shot prompting supplies in-context examples that show the model the precise input-to-label mapping, which is the most direct way to pin down a bespoke output format without fine-tuning.
Why B is wrong: Tempting because sampling settings feel like an obvious lever, but a higher temperature increases variety and would make the model more likely to invent codes, not less, so it works against the goal of exact labels.
Why C is wrong: Plausible because token limits do cause truncation, but the problem is the model choosing the wrong content, not running out of space, so raising the limit does nothing to enforce the five-code scheme.
Why D is wrong: Tempting because context window is a real selection criterion, but five short codes and one ticket already fit comfortably, so a larger window addresses a capacity problem that does not exist here.