AI Interview Questions

Structured output generation is the ability to produce model outputs in a predefined format, such as JSON, XML, or type-safe objects, rather than free-form text. This ensures outputs can be reliably parsed, validated, and used by downstream systems without error-prone string manipulation.

Structured outputs are achieved through: 1) Prompt engineering - instructing the model to output specific formats with examples. 2) Function calling APIs - models can output structured tool calls with defined schemas. 3) Constrained decoding - techniques that force token generation to follow a grammar (JSON, Pydantic models). 4) Output parsers - post-processing to extract and validate structured data. The model generates text that conforms to the expected structure, which is then parsed into native data structures (dictionaries, objects).

Production systems need reliability. Free-form text is unpredictable - missing fields, extra text, format variations cause parsing errors and crashes. Structured outputs guarantee that the model's response can be integrated into automated workflows. For applications like data extraction, API calling, and multi-step agents, structured outputs are essential. They reduce errors, simplify code, and enable type safety.

User asks: 'Extract flight information from this email: "Your flight UA123 departs JFK at 10:00 AM on March 15."' Unstructured output: 'The flight number is UA123, from JFK, at 10am on 3/15.' Hard to parse reliably. Structured output: {"flight_number": "UA123", "origin": "JFK", "departure_time": "2024-03-15T10:00:00", "airline": "United"}. Downstream system can immediately use this JSON. Production-ready.

JSON mode is a feature in LLM APIs (OpenAI, Anthropic, etc.) that constrains the model to generate valid JSON output. It ensures the response is parseable JSON, though it doesn't guarantee the JSON matches a specific schema.

When JSON mode is enabled, the API sets parameters that bias the model toward generating JSON: 1) System prompt includes instructions to output JSON. 2) Temperature may be set lower for more deterministic outputs. 3) The model is guided to produce well-formed JSON with proper brackets, quotes, and commas. However, JSON mode doesn't enforce a specific schema - the model decides what keys to include. The output is guaranteed to be parseable JSON, but may not have expected fields. Developers still need to validate against expected schema.

JSON mode simplifies integration by eliminating parse errors. Without it, models might add explanatory text before or after JSON, or produce malformed JSON. With JSON mode, you can reliably json.parse() the response. This is especially valuable for applications that need to process many responses programmatically.

Request with JSON mode: 'Extract name, age, and city from: "John is 30 and lives in NYC." Return as JSON.' Response: {"name": "John", "age": 30, "city": "NYC"}. Perfect. Without JSON mode, might get: 'Here's the JSON: {"name": "John", "age": 30, "city": "NYC"}. Let me know if you need anything else!' - extra text that breaks parsing. JSON mode ensures clean, parseable output.

Constrained decoding is a technique that forces LLM token generation to follow a specific grammar or schema, guaranteeing that the output is syntactically valid. For JSON, it ensures the output is not only parseable but conforms to a predefined structure.

At each generation step, constrained decoding computes which tokens are valid given the grammar and already generated tokens. For JSON, this means: after '{', only valid keys or '}' allowed; after key, only ':' allowed; after ':', only values of expected type allowed. Libraries like Outlines, Guidance, and LMQL implement this by building finite-state machines from JSON schemas or context-free grammars. The model's logits are masked to only allow valid tokens, then sampled. This guarantees 100% compliance with the grammar.

Standard JSON mode doesn't guarantee schema compliance - the model might omit required fields or add unexpected ones. Constrained decoding guarantees both syntax and structure. This is critical for production systems where missing fields cause errors. It also reduces hallucination by restricting outputs to valid possibilities. The trade-off is slight latency increase and reduced flexibility.

Schema: {"name": string, "age": integer}. Constrained decoding ensures: after '{', only '"name"' or '}' allowed. After '"name"', only ':' allowed. After ':', only string tokens allowed. After string, only ',' or '}' allowed. If ',' chosen, then only '"age"' allowed. This guarantees perfect schema compliance every time. No missing fields, no extra fields, no type errors.

OpenAI's function calling API allows the model to intelligently choose to call one or more functions, generating structured arguments that adhere to provided schemas. It's designed for building agents and tool-using applications.

Functions are defined in the API request using JSON Schema: each function has name, description, and parameters object describing the expected arguments with types, descriptions, and required fields. Example: { "name": "get_weather", "description": "Get current weather", "parameters": { "type": "object", "properties": { "location": { "type": "string", "description": "City name" }, "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] } }, "required": ["location"] } }. The model may respond with a function_call containing name and arguments (JSON string). The developer executes the function and returns the result to the model for continued conversation.

Function calling provides a standardized way for LLMs to use tools. It's more reliable than having the model generate function calls in free text. The schema ensures the model understands what parameters are needed and their types. This API powers thousands of agent applications and is the foundation of OpenAI's assistant API.

User: 'What's the weather in Paris?' Model sees function definition, decides to call get_weather. Returns: { "function_call": { "name": "get_weather", "arguments": "{\"location\": \"Paris\", \"unit\": \"celsius\"}" } }. Developer executes, gets result, sends back. Model then responds: 'The weather in Paris is 15°C and sunny.' This seamless integration makes function calling reliable.

Anthropic's tool use API (introduced in Claude 3) allows models to interact with external tools by generating structured tool_use content blocks. It's similar to OpenAI's function calling but with some differences in implementation and philosophy.

In Anthropic's API, tools are defined in the request with tools parameter, similar to OpenAI. Each tool has name, description, and input_schema (JSON Schema). During generation, Claude may output a tool_use block containing name and input (the arguments). The API doesn't execute tools - it returns the tool call to the client, which executes and sends back results with a tool_result block. Claude then continues. Key differences: 1) Explicit tool_use and tool_result blocks make parsing clear. 2) Claude supports parallel tool calls. 3) The API design emphasizes developer control - execution is always client-side. 4) Claude's strong reasoning often leads to more thoughtful tool selection.

Both APIs serve the same purpose but have different ergonomics. Anthropic's approach gives developers more visibility into the tool use process with explicit content blocks. Some developers find Claude's tool use more reliable for complex multi-step tasks. Choice often depends on model strengths and integration preferences.

Request to Claude with tools. Claude responds with: { "type": "tool_use", "name": "get_weather", "input": {"location": "Paris"} }. Client executes, returns: { "type": "tool_result", "tool_use_id": "...", "content": "15°C, sunny" }. Claude continues: 'The weather in Paris is 15°C and sunny.' This clear protocol makes tool use straightforward to implement.

Pydantic is a Python library for data validation using Python type hints. It's widely used in LLM applications to define expected output schemas and validate that model responses conform to them, providing type safety and clear error messages.

Developers define Pydantic models representing the expected structured output: class FlightInfo(BaseModel): flight_number: str; origin: str; destination: str; departure_time: datetime. After receiving LLM output (JSON), they parse it with FlightInfo.model_validate(json_data). Pydantic automatically: 1) Validates all fields exist and have correct types. 2) Converts strings to appropriate types (e.g., "2024-03-15" to datetime). 3) Provides detailed errors if validation fails. This ensures the data is correct before use. Pydantic models can also be used to generate JSON schemas for function calling or constrained decoding.

LLM outputs are never 100% reliable. Pydantic validation catches errors early, preventing downstream crashes. It also documents the expected structure clearly. For production systems, validating every LLM output with Pydantic is essential. It turns unpredictable model outputs into trustworthy data.

LLM returns: {"flight_number": "UA123", "origin": "JFK", "destination": "SFO", "departure_time": "2024-03-15T10:00:00"}. Pydantic validates: all fields present, flight_number string, departure_time converted to datetime. If model returned {"flight": "UA123"} (missing fields), validation fails with clear error. This prevents using incomplete data. If model returned {"departure_time": "tomorrow"}, datetime conversion fails. Validation catches this.

Instructor is a Python library that simplifies extracting structured data from LLMs by combining prompting, function calling, and validation into a clean, type-safe interface. It works with multiple model providers and uses Pydantic for schema definition and validation.

Instructor patches the LLM client (OpenAI, Anthropic, etc.) to add a response_model parameter. You define a Pydantic model and pass it to client.chat.completions.create(response_model=MyModel). Instructor handles: 1) Converting the Pydantic model to a function schema or prompt. 2) Making the API call with appropriate parameters. 3) Parsing the response. 4) Validating with Pydantic. 5) Retrying with feedback if validation fails. It also supports streaming, partial responses, and complex nested models. This reduces boilerplate and makes structured extraction trivial.

Without Instructor, extracting structured data requires manually creating schemas, parsing responses, writing validation logic, and handling errors. Instructor abstracts all this, letting developers focus on defining the data they want. It's become the standard for structured extraction in Python, used in thousands of projects.

class Person(BaseModel): name: str; age: int. person = client.chat.completions.create( model="gpt-3.5-turbo", response_model=Person, messages=[{"role": "user", "content": "John is 30"}] ). Returns Person(name='John', age=30). One line, validated, type-safe. Without Instructor, would need schema definition, prompt engineering, response parsing, validation - 10+ lines. Instructor makes structured extraction effortless.

Outlines is a library for structured text generation that uses grammar-based constrained decoding to force LLM outputs to follow a specific format, such as JSON, regular expressions, or context-free grammars. It guarantees that outputs are syntactically valid.

Outlines works with Hugging Face models by intercepting the generation loop. At each step, it computes which tokens are valid given the desired structure (e.g., JSON schema, regex) and the tokens generated so far. It builds a finite-state machine from the grammar and masks the model's logits to only allow valid tokens. This ensures 100% compliance. Outlines supports: 1) JSON schemas (via Pydantic). 2) Regular expressions. 3) Context-free grammars. 4) Python types. It works with any Hugging Face model and can be faster than unconstrained generation because it reduces the search space.

Outlines provides the strongest guarantee of structured output: the output is guaranteed to match the specified format, not just likely to. This is essential for applications where format errors are unacceptable. It also enables generating outputs that would be impossible with prompting alone, like complex nested JSON with specific constraints.

Generate a list of 5 random numbers between 1 and 100 as JSON array. With Outlines, define schema: List[int] with constraints (1-100). Generation is forced to produce valid JSON array with integers in range. No chance of getting strings, objects, or out-of-range values. This reliability is invaluable for data generation tasks.

Even with structured output techniques, failures can occur: schema violations, missing fields, type errors, or logical inconsistencies. Understanding these failure modes helps in designing robust systems with appropriate error handling and fallbacks.

Common failure modes: 1) Schema violation - model outputs JSON that doesn't match expected schema (missing required fields, extra fields, wrong structure). 2) Type errors - string where number expected, invalid date format. 3) Value errors - values outside allowed range or enum. 4) Incomplete output - generation cut off mid-structure. 5) Hallucinated fields - model adds fields that don't make sense. 6) Semantic errors - output is syntactically valid but semantically wrong (e.g., extracting wrong date). 7) Recursion errors - for complex nested structures, model may nest incorrectly. 8) Language mixing - model may include explanatory text despite instructions.

These failures can crash downstream systems or cause incorrect decisions. Mitigation strategies: 1) Validation - always validate against schema. 2) Retry with feedback - feed validation errors back to model. 3) Fallback values - provide defaults for missing optional fields. 4) Human review - for critical applications. 5) Constrained decoding - prevents syntactic errors but not semantic ones. Understanding failure modes helps build resilient systems.

Extracting flight info, model returns {"flight": "UA123", "date": "03/15/24"} but schema expects flight_number and departure_time with ISO date. Schema violation (wrong keys) and type error (date format). Validation catches this. Retry with feedback: 'Expected keys flight_number and departure_time. Date should be ISO format.' Model corrects. Without handling, downstream system crashes. Good error handling prevents this.

Schema evolution refers to changing the expected output structure over time as requirements evolve. This is challenging for production systems because old prompts and models may not adapt to new schemas, and existing data may need migration.

Strategies: 1) Versioned schemas - define different schema versions (v1, v2). Maintain both in parallel during transition. Route requests based on date or explicitly specify version. 2) Backward compatibility - design new schemas to be backward compatible: add optional fields, never remove required ones. 3) Migration period - run dual output for a period: generate both old and new format, compare, gradually shift. 4) Data migration - for stored data, write migration scripts to transform old format to new. 5) Prompt versioning - maintain different prompts for different schema versions. 6) Model updates - when changing schema significantly, may need to fine-tune or use different model.

Production systems can't break when schemas change. A sudden schema change without migration breaks all downstream consumers. Careful evolution ensures continuity. For LLM applications, this is especially important because models are stateless - they don't automatically adapt to new schemas.

Initially, extract Person with name, age. New requirement: add email (optional) and change age to birth_date (breaking). Strategy: create v2 schema with name (required), birth_date (required), email (optional). Keep v1 running. For new users, use v2. For existing data, migrate: compute birth_date from age (approximate). Run dual extraction for a month to validate. Then deprecate v1. This smooth evolution prevents disruption.

Tool use (function calling) is designed for the model to invoke external functions, with the output being a structured specification of which tool to call and with what arguments. Structured output is about the model generating data in a specific format for direct consumption, not necessarily to trigger actions.

Tool use: model outputs a function_call or tool_use block containing tool name and arguments. This is intended to be executed by the system, with results fed back. The focus is on taking actions. Structured output: model generates JSON (or other format) that is directly used as data. No execution expected. The focus is on data extraction. Some APIs (OpenAI) support both: function calling for tools, and JSON mode for structured data. The underlying mechanism is similar (structured generation), but the intent and usage differ.

Using tool use when you just need data extraction adds unnecessary complexity - you have to define dummy tools and handle fake execution. Using structured output for tool use doesn't work because you need the action loop. Understanding the distinction helps choose the right API for your use case.

Data extraction: need to get person details from text. Use structured output (JSON mode). Define schema, get JSON back, done. Tool use: need agent that can search web and answer. Define search tool, model calls it with query, you execute, return results, model continues. Different patterns, different APIs. Mixing them causes confusion.

Extracting structured information from unstructured text involves identifying entities, relationships, and attributes and formatting them according to a predefined schema. This is a common task for LLMs, powering applications from data entry to knowledge base construction.

Process: 1) Define schema - what entities and attributes to extract (e.g., Person, Organization, Date, with fields). 2) Design prompt - instruct model to extract information according to schema, with examples. 3) Use structured output techniques - function calling, JSON mode, or constrained decoding to ensure format. 4) Validate output - use Pydantic to check schema compliance. 5) Handle errors - retry with feedback if validation fails. 6) Post-process - resolve coreferences, normalize values. For complex extraction, may use multi-step: first identify entities, then extract relationships.

Unstructured text (emails, articles, reports) contains vast amounts of information locked in human-readable form. Structured extraction unlocks this data for databases, analytics, and automation. It's essential for knowledge management, research, and business intelligence.

Email: 'Hi, I'm John Smith from Acme Corp. My number is 555-0123. We discussed the project deadline of March 15.' Extract schema: Contact with name, organization, phone, and Project with deadline. LLM extracts: {"name": "John Smith", "organization": "Acme Corp", "phone": "555-0123", "project_deadline": "2024-03-15"}. This data can now be stored in CRM, trigger reminders, etc. Unstructured email becomes actionable data.

JSON Schema is a vocabulary that allows you to annotate and validate JSON documents. It describes the structure, data types, and constraints for JSON data. For LLM structured outputs, it defines exactly what the model should generate.

JSON Schema uses keywords: type (object, array, string, number, boolean), properties (for objects), items (for arrays), required, enum, minimum/maximum, pattern (regex for strings), format (date-time, email). For nested outputs: define objects within objects, arrays of objects. Example: { "type": "object", "properties": { "person": { "type": "object", "properties": { "name": {"type": "string"}, "age": {"type": "integer", "minimum": 0} }, "required": ["name"] }, "contacts": { "type": "array", "items": { "type": "object", "properties": { "type": {"type": "string", "enum": ["email", "phone"]}, "value": {"type": "string"} } } } } }.

JSON Schema provides a precise, machine-readable specification for expected output. It can be used for validation (Pydantic), for generating prompts, and for constrained decoding. For complex nested data, it ensures the model produces correctly structured output that matches application requirements.

Extracting resume information: need nested structure with personal info, education history (array), work experience (array), skills. JSON Schema defines exactly how this should look: education items have degree, institution, year; work items have company, title, dates. This guides the model and enables validation. Without schema, model might produce inconsistent structures.

Optional fields (may be present or absent) and nullable values (explicitly null) are common in real-world data. LLM structured outputs must handle these correctly, distinguishing between missing data and explicitly null values.

In JSON Schema, optional fields are simply not listed in required. The model may omit them. For nullable, use type: ["string", "null"] to allow null. In prompts, instruct model: 'If information is not available, omit the field (for optional) or set to null (for nullable).' Challenge: models may struggle with this distinction, sometimes omitting when should be null, or providing placeholder values. Constrained decoding can enforce nullability rules. Post-processing can convert empty strings to null.

Correct handling of missing data is crucial for downstream systems. Optional fields omitted is different from field present with empty string. Null indicates explicitly unknown, while omission may mean not applicable. Confusing these leads to incorrect processing. For analytics, distinction matters.

Extracting person data: {"name": "John"} (age optional, omitted). Another record: {"name": "Jane", "age": null} (age explicitly unknown). Different meanings. If model always includes age with 0 when unknown, that's wrong. Good prompt: 'Include age only if mentioned. If mentioned but value unknown, use null.' This distinction preserves information.

Testing structured output schemas involves verifying that the LLM consistently produces valid, correctly formatted outputs across a wide range of inputs, including edge cases like missing data, ambiguous inputs, and unusual formats.

Testing approach: 1) Create test dataset with diverse inputs covering normal cases, edge cases (missing fields, ambiguous values, extreme lengths), and adversarial cases. 2) Define expected outputs for each (or validation rules). 3) Run schema against test set, collect outputs. 4) Validate each output against schema (using Pydantic). 5) Measure success rate, error types. 6) For failures, analyze: schema violations, type errors, missing fields. 7) Iterate on prompt or schema based on findings. 8) Use property-based testing: generate random valid inputs, verify output schema compliance.

Edge cases are where schemas fail. A schema that works for 90% of cases may fail on the 10% that matter. Testing reveals these failures, allowing fixes before deployment. For production, comprehensive testing is essential to ensure reliability.

Testing person extraction schema on 500 examples. Results: 95% valid, 5% failures. Analysis shows failures on: names with punctuation (O'Malley) causing JSON escape issues, ages expressed as 'thirty' instead of number, missing email field when not in text. Fix prompt to handle these cases. Retest: 99% valid. Without testing, would deploy and fail on real user data with apostrophes.

Constrained decoding and post-processing represent different approaches to structured output with different latency profiles. Constrained decoding adds overhead during generation; post-processing adds overhead after generation. Understanding trade-offs helps choose the right approach.

Constrained decoding: at each token step, computes valid token mask based on grammar. Adds 10-30% latency per token due to mask computation and reduced sampling options. But guarantees valid output. Post-processing: generate freely, then parse and validate. May need retries if invalid, adding significant latency (2-3x). For high reliability, retries compound. For simple schemas, constrained decoding may be faster overall because it eliminates retries. For complex schemas, mask computation overhead may be higher. Also, constrained decoding can be faster per token because reduced vocabulary (only valid tokens) can speed up sampling.

Latency affects user experience. For real-time applications, minimizing latency is critical. If post-processing with retries leads to variable latency, constrained decoding may provide more consistent performance. For batch processing, latency less critical. Testing on your specific schema and model is essential.

JSON extraction with 95% success rate via prompting. Post-processing: 1x 100ms for 95% of requests, but 5% fail and retry (200ms) → average 105ms. Constrained decoding: always 120ms, no retries. For 95% of requests, post-processing faster; for 5%, slower. But constrained decoding provides consistent latency, which may be preferable for user experience. Also, if schema complex and success rate lower, constrained decoding wins.

Multi-step structured output involves generating structured data across multiple agent interactions, where each step produces part of the final structure, often with dependencies. This is common in complex data extraction, form filling, and research tasks.

Approaches: 1) Sequential generation - agent generates part of structure, then next step based on that. Example: first extract entities, then for each entity, extract relationships. 2) Hierarchical - top-level structure generated first, then details filled in by sub-agents. 3) Iterative refinement - generate full structure, then refine based on validation. 4) State management - maintain partially built structure in agent's memory, update as new info available. 5) Tool use - use structured output tools as steps in agent loop. Each step's output validated and passed to next.

Complex real-world data often requires multi-step extraction. A single prompt may not capture all relationships or may exceed context. Multi-step approach breaks down complexity, improves accuracy, and enables human-in-the-loop at key points. It also allows using specialized models for different steps.

Extracting financial data from annual report. Step 1: Extract table of contents, identify sections. Step 2: For each section, extract key metrics (revenue, profit). Step 3: Extract notes and footnotes. Step 4: Validate totals match. Step 5: Structure as nested JSON. Each step builds on previous, with validation between. This produces high-quality structured data impossible in one pass. Multi-step structured output makes it possible.

XML-based structured output uses XML tags to structure data, rather than JSON. While less common in modern APIs, XML is still preferred in some domains (enterprise, legacy systems, document processing) where schemas, namespaces, and attributes are important.

XML output uses tags like <person><name>John</name><age>30</age></person>. Advantages over JSON: 1) Attributes - can store metadata in tags (<price currency="USD">100</price>). 2) Namespaces - avoid naming conflicts. 3) Schema validation - XSD schemas more powerful than JSON Schema. 4) Mixed content - text with markup. 5) Comments. 6) Processing instructions. Many enterprise systems still use XML. LLMs can generate XML with prompting or constrained decoding using XML grammars.

For integration with legacy enterprise systems, XML is often required. JSON may not be accepted. XML's richer semantics can also be beneficial for complex documents. While JSON is simpler and more common for web APIs, XML remains important in certain domains.

Generating an invoice for enterprise system that expects XML: <invoice number="INV-001"> <customer id="123">Acme Corp</customer> <items> <item sku="A100"> <description>Widget</description> <quantity>2</quantity> <price currency="USD">10.00</price> </item> </items> <total currency="USD">20.00</total> </invoice>. Attributes and nested structure captured. JSON equivalent possible but may not match legacy system's expectations. XML output necessary.

An invoice data extraction pipeline uses structured outputs to convert unstructured invoice documents (PDFs, scans, emails) into structured data (JSON) that can be ingested into accounting systems. This is a classic RAG + structured output application.

Pipeline design: 1) Document ingestion - extract text and layout from invoice (using OCR, PDF parser). 2) Pre-processing - clean text, identify key sections (header, line items, totals). 3) Schema definition - define structured output schema for invoices: Invoice with fields: vendor_name, invoice_number, date, due_date, line_items (array of description, quantity, unit_price, total), subtotal, tax, total. 4) Extraction prompt - instruct LLM to extract data according to schema, with examples. Use function calling or JSON mode. 5) Validation - use Pydantic to validate extracted data against schema. 6) Error handling - if validation fails, retry with specific feedback (e.g., 'missing line items'). 7) Post-processing - calculate derived fields, format dates. 8) Output to accounting system.

Manual invoice processing is slow and error-prone. Automating it saves time and money. A well-designed pipeline can handle varied invoice formats, extract data accurately, and integrate with existing systems. Structured outputs make the extracted data usable immediately.

Invoice PDF ingested. Pipeline extracts: {"vendor": "Acme Supplies", "invoice_number": "INV-2024-001", "date": "2024-03-15", "line_items": [{"description": "Widgets", "quantity": 10, "unit_price": 5.00, "total": 50.00}, {"description": "Gadgets", "quantity": 5, "unit_price": 10.00, "total": 50.00}], "subtotal": 100.00, "tax": 8.00, "total": 108.00}. Validated, then sent to accounting system. Invoice processed in seconds, not minutes. This pipeline scales to thousands of invoices.

Communicating structured output requirements involves clearly specifying to the LLM what format the response should take, including field names, data types, constraints, and examples. This can be done through system prompts, user prompts, or API parameters like function calling schemas.

Methods: 1) Natural language instructions in prompts - 'Return a JSON object with fields: name (string), age (integer), and email (string).' Include examples. 2) Function calling/tool use - define structured schema via API parameters (OpenAI, Anthropic), which the model uses to generate structured calls. 3) JSON Schema in prompts - include the actual JSON Schema in the prompt for complex structures. 4) Type hints - use libraries like Instructor that convert Pydantic models to schemas automatically. 5) Few-shot examples - provide examples of desired output format. Best practices: be explicit about required vs optional fields, specify data formats (ISO dates, enum values), and include instructions for handling missing information (omit field, use null).

Poorly communicated requirements lead to inconsistent outputs, parsing errors, and unreliable applications. Clear specification ensures the model understands exactly what you need. Different providers have different mechanisms - OpenAI uses function calling, Anthropic uses tool use, and both can also work with prompt instructions. Choosing the right method and crafting clear instructions directly impacts success rate.

Poor prompt: 'Give me the person's details.' Model might respond with free text. Good prompt: 'Extract the person's information as JSON with fields: name (string), age (integer), and email (string). If age not mentioned, omit the field. Use ISO date format for any dates. Example: {"name": "John Doe", "age": 30, "email": "john@example.com"}. Input: "Jane Smith, 25, jane@email.com"' This clarity ensures reliable structured output. For complex schemas, use function calling: define the exact schema in API parameters, leaving no ambiguity.