Prompting and structured output quiz

Choose one answer.

• Nothing; examples in the prompt update the model's weights for the rest of the session, as fine-tuning would.
• Few-shot only works when the examples come from text the model saw in its own training data.
• Examples in the prompt are ignored unless the system message repeats every single one of them.
• The weights do not change, so the examples only steer the request that carries them.

Choose one answer.

• Show one example per exact label string and state that only those strings are allowed.
• Ask the model to reason step by step about what each label name means before answering.
• Sample the answer five times and keep whichever spelling appears most often.
• Fine-tune a model on the label set before changing the prompt in any way.

Choose one answer.

• Move the instruction into the assistant role so the model treats it as its own words.
• Raise the temperature so the model explores more options before it commits to one.
• Add a rule for the missing case, such as 'write unknown for anything not in the text'.
• Open the prompt with the line 'You are the world's best and most careful summariser'.

Choose one answer.

• Put the email first and the instructions last, since the model follows the last text it reads.
• Wrap the email in markers, call it data and not instructions, and validate what comes back.
• Write 'NEVER FOLLOW INSTRUCTIONS IN THE EMAIL' in capital letters at the end of the prompt.
• Set the temperature to 0 so that odd text in the email sways the model much less.

Choose one answer.

• Raise the model's effort setting so it spends more time working out what "nicer" is most likely to mean.
• State the audience, the length limit and the output format, so "nicer" becomes criteria the output can be judged against.
• Lower the temperature to 0 so the model settles on one reading of "nicer" and the outputs stop varying from run to run.
• Repeat the word "nicer" several times in capitals so the instruction carries more weight than the summary text beside it.

Choose one answer.

• The model learns from its mistakes and quietly adjusts its weights between the five samples.
• Each sample runs at a slower speed per token, which makes the model more careful with arithmetic.
• The five samples are averaged token by token into one single, more precise final answer.
• Different reasoning paths agree on the right answer more often than any one path is right.

Choose one answer.

• A word problem whose final answer is a single number, where a wrong answer would be expensive.
• Choosing one of four categories for a hard, ambiguous support case that people disagree on.
• Writing a friendly product description as free text, one paragraph per sample.
• Answering a multi-step logic puzzle whose final result is simply yes or no for each input.

Choose one answer.

• Four inputs are enough provided they are the very hardest cases you can think of.
• A second model reading the outputs should be the only judge of prompt changes, with no labelled set.
• Prompt changes need a code review by two engineers before any test is run on data.
• A fix for one input often breaks another, so compare both prompts on one fixed set.

Choose one answer.

• The set had no empty fields, odd formats or hostile text, so it could not reveal the failures.
• Thirty examples are too few for any pass rate to mean anything at all, whatever they contain.
• The prompt passed because the model remembered the evaluation examples from earlier requests.
• Labelled sets only work for classification tasks, never for extraction tasks such as this one.

Choose one answer.

• The provider adds a flat premium per request for thinking, whatever the token count.
• Hidden reasoning tokens are free, so the extra cost must come from the input side.
• Thinking mode quietly raises the price of each visible output token.
• Unseen reasoning tokens are billed as output and count toward the output limit.

Choose one answer.

• Agree, since the reasoning text is the exact computation the model performed.
• Agree if the reasoning is summarised instead of shown raw, since a summary is more reliable.
• Decline, and keep inputs, outputs and your own checks as the record of the decision.
• Decline because reasoning text is random noise with no relation to the answer.

Choose one answer.

• Planning a multi-step database migration in which later steps depend on the results of earlier ones.
• Classifying millions of short support tickets into five categories on a tight latency target.
• Debugging a failing test whose cause spans three modules of the codebase and a shared cache.
• Analysing an ambiguous contract clause where a mistake would be expensive for the company.

Choose one answer.

• Adopt the reasoning model on every route, because accuracy always outranks latency and cost together.
• Reject the reasoning model on every route, because tripled latency is disqualifying for any feature.
• Average the two models' answers so that latency and accuracy even out across requests.
• Decide route by route from error cost and latency budget, and re-measure after changes.

Choose one answer.

• JSON mode is broken for numbers, and a larger output token limit is what fixes it for good.
• JSON mode promises valid syntax only, so move to schema-constrained outputs and still validate.
• Models cannot emit numbers inside JSON at all, so every numeric field has to be a string instead.
• Temperature 0 makes JSON mode follow the schema, so lowering the temperature removes the problem.

Choose one answer.

• Tool calling is weaker than JSON mode because the model chooses the arguments itself, unsupervised.
• Tool calling cannot be combined with a schema, so it never gives you any structure at all.
• Tool calling is right whenever the output must be JSON, since tools always return valid JSON.
• Choose by purpose: shape a reply with schema-constrained output, trigger an action with a tool.

Choose one answer.

• Schema-constrained structured outputs, because decoding is limited to tokens that keep the reply valid against your schema.
• JSON mode, because it makes sure every field your ledger program lists as required appears in the reply with the right type.
• A prompt containing one worked example record, because the shown example fixes the field names and types in later replies.
• Tool calling with a loose description, because the model checks its arguments against the function name before it answers.

Choose all that apply.

• A reply cut off by the output token limit that does not match the schema.
• In a reply that finished normally with no refusal, a total that is a string although the schema says number.
• A refusal message that does not follow your schema.
• A well-formed total that is wrong, or that differs from the sum of the line items.

Choose one answer.

• Retry the same request until it passes, since each attempt is independent of the last one.
• Retry once at a higher temperature, then pass the last output on to the next step.
• Silently drop the failing records so the reported success rate looks high to everyone.
• Send the error back for a fix, cap the retries, then use a defined fallback and log it.