When To Use Examples
Examples are most valuable inOutputMode::Json and OutputMode::MdJson modes, where
the model relies on the prompt to understand the expected output shape. In OutputMode::Tools,
the schema itself provides strong guidance, but examples can still help clarify edge cases
or normalize output style.
Keep examples short and representative. They should clarify the task, not replace the prompt.
The Example Class
Each example pairs an input with the expected output. The input is a string describing
the scenario, and the output is an array representing the correct extraction result:
Factory Methods
TheExample class provides several factory methods for different input formats:
fromText() - String Input
The most common form. Equivalent to the constructor:
fromChat() - Chat Messages
Use when you want to demonstrate a multi-turn conversation as input:
fromData() - Structured Data
Accepts any data type as input. Objects and arrays are automatically serialized to JSON:
Using The Fluent API
You can also set examples with the fluentwithExamples() method:
Custom Templates
By default, Instructor formats each example using a built-in template. You can override this with a custom template string that uses{input} and {output} placeholders:
Best Practices
- Use one or two examples for most tasks. More is rarely better — it adds tokens without proportional improvement.
- Make examples diverse. Show different edge cases rather than repeating similar inputs.
- Match the real task. Examples should reflect the actual complexity and format of your production data.
- Keep output arrays minimal. Include only the fields relevant to the extraction to avoid confusing the model.