5 Practical Ways to Improve Large Language Model Output Without Model Changes

# Why small changes to the input matter

# The example used

The article tests each technique against a single, intentionally messy meeting transcript where items are reassigned mid-conversation, sub-tasks get folded into larger items, and one task remains unassigned. The goal: produce a precise list of action items that downstream code can parse and act on.

# Five strategies that consistently improve outcomes

1) Specify structured, machine-parseable output

Ask for JSON (or another strict schema) and show a schema example. The article demonstrates a Pydantic schema for action items and shows that free-form prose—even when accurate—fails automated validation. Concrete benefit: structured requests produce data your pipeline can ingest without human transcription.

Telling the model it should act as a meticulous executive assistant or technical project coordinator narrows the model's focus and encourages consistent formatting and conservative interpretation. This is a low-cost change that improves consistency across runs.

3) Use few-shot examples with edge-case coverage

Provide 2–4 concise examples that map inputs (short, messy transcript fragments) to the exact structured output you expect, including the awkward cases: reassigned tasks, folded sub-tasks, and unresolved owners. Examples teach the model which conventions to follow when the source is ambiguous.

4) Ask for chain-of-thought-style steps when appropriate

When extraction requires reasoning about ownership or due dates, request the model list the extraction steps before the final result. The intermediate steps make errors visible and easier to validate or reject, and can increase correctness for multi-step deductions. Use this selectively—when tasks require disambiguation.

5) Validate and iterate with strict parsing

Run every output through a validation routine that either accepts a fully conformant object or returns a clear error. The article includes code that parses JSON against a schema and returns an explicit validation error instead of silently accepting partial results. Failure modes discovered by validation guide prompt refinements and example updates.

# Practical sequence to apply these strategies

• Start by defining the schema your system needs. Keep it minimal and strict.
• Assign a role/persona in the instruction to stabilize behavior.
• Provide 2–4 few-shot examples that include tricky cases you expect in production.
• For ambiguous inputs, request stepwise justification before the final structured output.
• Automate validation and treat validation failures as test failures to iterate on examples and instructions.

# Expected outcomes

Applying these changes turns plausible-looking prose into reliably parsed data, reduces manual post-processing, and exposes real errors rather than silent misinterpretations. The transcript example in the article shows structured-output plus role assignment and examples parsed cleanly, while a vague instruction produced prose that failed automated parsing.

# Quick checklist before deployment

• Schema defined and codified in your validation library.
• Role/persona included in the instruction text.
• Few-shot examples cover typical and edge cases.
• Chain-of-thought requested only where needed.
• Automated parsing rejects invalid data with clear error messages.