SESSION 2 · ~40M
Structured output
When a model feeds another system, the output must be machine-readable — and that means a contract, not a hope.
Chat answers are for humans. The moment a model's output feeds code — a spreadsheet, a database, another API — you need structured output: JSON that matches a known shape, every time.
The output contract
Define the exact schema you expect: which fields, which types, which enums, what's required versus optional. Give the model the schema in the prompt (or use a provider's native structured-output mode) and ask it to return only valid JSON conforming to it.
- Delimiters: wrap the JSON so you can extract it reliably — e.g., respond between markers like <json> and </json>.
- Enums over free text: 'sentiment: positive | neutral | negative' beats letting the model invent labels.
- Explicit null rules: tell the model what to do when a field is unknown, so it doesn't guess.
Always validate. Parse the JSON and check it against your schema before trusting it — if parsing fails, retry the model with the error message ('your output was missing the required field X'). This retry loop is what turns a flaky demo into a reliable pipeline.
Lower temperature for structured tasks: near-zero temperature makes the model more deterministic, which is exactly what you want when the format matters more than creativity. Reserve high temperature for prose, not for JSON.
TRY IT
Prompt a model to return a JSON object for a made-up product (name, price, in_stock, tags). Validate the result in your head: are the types right? Is anything missing? The friction you find is the friction a schema removes.
CHECK YOUR UNDERSTANDING
When should you use lower temperature for model output?
What does the module recommend when the model's JSON output fails to parse?
Why does the module recommend using enums over free text in structured output schemas?
NOTEBOOKLM
Connect your notebook
Paste a NotebookLM share link to embed your notebook for this module.