Module 83: Prompt Engineering

Why each option is right or wrong

• “So the model uses fewer tokens when it gives its reply” (Incorrect): Saving tokens isn't the aim; preventing made-up answers is.
• “So the model writes longer, more detailed explanations” (Incorrect): This instruction is about honesty when unsure, not answer length.
• “Because the API returns an error without this instruction” (Incorrect): APIs don't require it; it's a choice that improves reliability.
• “Otherwise it may invent an answer” is correct.

  Models are trained to produce helpful-sounding replies, so when the information isn't there, they often fill the gap with something plausible. Telling it exactly what to do instead, such as "If the documents don't say, reply: I don't know", gives it an honest way out.

  • Make it specific: give the exact words or value to use.
  • Test it: include questions the material can't answer.

📖 Revise: Lesson 1: Instructions and context

Why each option is right or wrong

• “Because AI APIs reject prompts that have no tags” (Incorrect): APIs accept plain text; tags help the model, not the API.
• “Because tags make the model respond more quickly” (Incorrect): Tags add a few tokens; they don't speed anything up.
• “So the prompt is easier for the user to read on screen” (Incorrect): Users usually don't see the prompt; the labels are for the model.
• “So the model can tell instructions from content” is correct.

  When instructions and pasted material run together, the model can mistake part of a document for an instruction, or miss where the task ends. Clear labels, like <document> tags or headings, show what to follow and what to work on.

  • Security bonus: helps against instructions hidden in user content.
  • Example: <email>...</email> then "Summarise the email above."

📖 Revise: Lesson 1: Instructions and context

Why each option is right or wrong

• “The model's own name and which company made it” (Incorrect): Examples teach the task's pattern, not facts about the model.
• “New facts that are permanently added to the model's knowledge” (Incorrect): Examples guide one request; they don't change what the model knows.
• “How to browse the internet for more information” (Incorrect): Examples don't give a model browsing; that needs tools.
• “The exact format, tone and edge-case handling” is correct.

  Instructions describe what you want; examples show it. A few worked input-and-output pairs teach the model the precise layout, the voice, and how to handle tricky cases, often more reliably than a paragraph of rules.

  • Use 2 to 5: that cover different situations.
  • Combine: short instructions plus examples.

📖 Revise: Lesson 2: Few-shot examples

Why each option is right or wrong

• “So the model learns to ignore the examples and follow the rules” (Incorrect): Models lean heavily on examples; they don't learn to ignore them.
• “Because APIs reject prompts with repeated examples” (Incorrect): APIs don't check this; the model simply copies patterns.
• “Because varied examples use fewer tokens than similar ones” (Incorrect): Token count depends on length, not variety.
• “The model copies them, mistakes included” is correct.

  Models imitate examples closely. A typo, a wrong value, or an odd habit in an example tends to reappear in the output. If every example looks the same, such as all short or all positive, the model may treat that as a rule too.

  • Vary: length, topic and edge cases.
  • Check: each example as carefully as real output.

📖 Revise: Lesson 2: Few-shot examples

Why each option is right or wrong

• “Because null is shorter than writing "unknown"” (Incorrect): Length isn't the point; honesty about missing values is.
• “Because JSON doesn't allow empty strings in fields” (Incorrect): JSON allows empty strings; null just signals missing more clearly.
• “Because null fields make the response arrive faster” (Incorrect): The speed difference is tiny; the benefit is avoiding invented data.
• “It gives the model an honest option instead of inventing” is correct.

  If every field must be filled, the model may guess a phone number or date that isn't in the text. Allowing null, and saying when to use it, lets it report "not found", and your code can handle that case properly.

  • Say it in the prompt: "Use null if the value isn't stated."
  • In code: treat null as missing, not as an error.

📖 Revise: Lesson 3: Structured output

Why each option is right or wrong

• “Validation feedback trains the model to improve” (Incorrect): Your code's checks don't change the model's weights.
• “It's only needed in development, not in production” (Incorrect): Production is where unexpected inputs appear, so validation matters most there.
• “Code can't read JSON at all without validating first” (Incorrect): Code can parse JSON without a schema; validation checks it's correct.
• “The model can still produce invalid output” is correct.

  Even with careful prompts and JSON modes, a model can miss a field, use the wrong type, or return a value outside the allowed list. Checking it with a schema, for example with Zod, catches problems before they reach your database or users.

  • On failure: retry once, or fall back safely.
  • Log: failures, to improve the prompt.

📖 Revise: Lesson 3: Structured output

Why each option is right or wrong

• “Because AI regulations require a version number on every prompt” (Incorrect): There's no such general rule; it's for your own traceability.
• “So each new version can be longer and more detailed” (Incorrect): Versioning tracks changes; it doesn't make prompts longer.
• “So users can't see that the prompt has changed” (Incorrect): It's the opposite: versions make changes visible and traceable.
• “To know which prompt produced each answer and roll back” is correct.

  Prompts change behaviour as much as code does. Giving each template a version, and recording it with each answer, lets you trace a bad answer to the prompt that caused it, compare versions in tests, and go back if a change makes things worse.

  • Store prompts: in Git, like code.
  • Log: the version with every request.

📖 Revise: Lesson 4: Templates

Why each option is right or wrong

• “So the model uses fewer tokens for user content” (Incorrect): Tags add tokens; the goal is safety, not saving them.
• “So the model translates user input into English first” (Incorrect): Marking sections doesn't trigger translation.
• “So the model gives user requests higher priority than your rules” (Incorrect): The aim is the reverse: your instructions stay in charge, and user text is treated as data.
• “They're untrusted material, not instructions” is correct.

  Users or document authors might write text like "Ignore your instructions". Placing that content inside clear tags, and telling the model to treat it as data, reduces the chance it's followed as a command. It's one layer of protection against prompt injection, not a complete fix.

  • Also: limit what tools the model can use.
  • Still untrusted: check outputs before acting on them.

📖 Revise: Lesson 4: Templates

Why each option is right or wrong

• “The first try is usually wrong, so the second is the real test” (Incorrect): The first try isn't special; the issue is how many cases you test.
• “Providers change their models every hour, so results expire” (Incorrect): Models change occasionally, not hourly; the issue is varied inputs.
• “It is enough, as long as the answer looked correct” (Incorrect): One correct-looking answer can hide failures on other inputs.
• “Other inputs and randomness give different results” is correct.

  One good answer shows the prompt can work, not that it usually does. Different inputs, unusual cases, and the randomness in generation can all produce failures. A test set of varied inputs, run several times, shows how reliable it really is.

  • Include: normal, tricky and out-of-scope inputs.
  • Measure: how many pass, not just whether one did.

📖 Revise: Lesson 5: Testing prompts

Why each option is right or wrong

• “Double the temperature to match the new model's style” (Incorrect): Temperature isn't tied to a model switch; tests show what needs changing.
• “Delete the old prompts, since they won't work any more” (Incorrect): Old prompts often still work; test them before deciding.
• “Nothing, because newer models work better with every prompt” (Incorrect): Newer models can behave differently, sometimes worse for your case.
• “Re-run your prompt tests” is correct.

  Different models, and even newer versions of the same one, can respond differently to the same prompt: better on some cases, worse on others. Running your saved tests shows what changed before users see it.

  • Compare: pass rates, costs and speed.
  • Adjust: prompts if needed, then re-test.

📖 Revise: Lesson 5: Testing prompts