LLM learning

Prompting & In-Context Learning

Write prompts as testable contracts with instructions, examples, data, and output rules.

Not started3 min explanation

Visualize, practice, and deep-dive material are optional—use only what helps you learn.

Explanation

A focused 3-minute explanation using the topic's authored material.

Learning goals and prerequisites

After this lesson

  • Separate prompt roles and trust levels
  • Use examples to clarify boundaries
  • Evaluate and version a prompt contract

Helpful before starting

  • LLM generation and decoding
  • Basic application requirements

Mental model

A prompt defines the request contract

Direct answer

A prompt arranges instructions, context, examples, untrusted input, and the expected response shape for one model request. It can steer behavior without changing model weights, but it cannot replace software validation, authorization, or business rules.

Follow the mechanism

  1. State the task and the allowed labels, tools, or sources.
  2. Place user and document content inside an explicit data boundary so it is not confused with privileged instruction.
  3. Add examples only when they clarify a difficult boundary or demonstrate the required format.
  4. Require a response shape, validate it in code, and define what happens when the result is ambiguous, unsupported, or invalid.

Running example

Consider the message “I was charged twice for order 1842.” The vague prompt “Classify this support message and explain” can produce polished prose that downstream software cannot parse. A stronger contract defines the labels billing | technical | other, places the message inside a data field, and requires exactly label and reason. The model can now return {"label":"billing","reason":"The user disputes a charge."}; the application still checks the field names, the allowed label, and the non-empty reason before using it.

What this does not mean

A clear prompt is not a security boundary. Text inside the user message may say “ignore previous instructions”, but identity, access control, payment approval, and irreversible actions must remain outside model persuasion. A schema can prove that output is structurally valid; it does not prove that the classification is semantically correct, so representative evaluation cases are still required.

Key points

  • Task → trust boundaries → examples → output schema → validation is the prompt contract.
  • In-context examples affect the current request without updating model weights.
  • Untrusted text remains data even when it resembles an instruction.
  • Structural validation and semantic evaluation answer different quality questions.
Try it: Predict how the vague prompt will fail

Use the duplicate-charge message before switching from the vague prompt to the contract.

  1. 1.Write the output shape you expect from the vague request and name why software may reject it.
  2. 2.Switch to the contract and identify the exact fields and allowed values the validator can enforce.
  3. 3.Replace the message with an ambiguous or instruction-like input and define the safe failure behavior.

Was this lesson helpful?

Submit to the team when server feedback is available; otherwise this browser keeps a local copy and tells you so.

Back to Topic Library