Yapılandırılmış Çıktılar

This makes integration easier, but structural validity does not establish factual correctness. A valid object can still contain an invented value or an inappropriate decision.

Key takeaways

• Define missing-value and versioning rules.
• Handle incomplete or refused outputs.
• Check factual relationships after schema validation.

Specify the fields, types, allowed values, and missing-value behavior before generating output. A date string, a numerical amount, and a list of source identifiers need different validation. Define whether additional fields are accepted and whether an absent value differs from an explicit null. Providers vary in how they enforce structure. Some constrain generation against a supported schema; others rely on prompting and validation afterward. Check the supported schema features and still handle refusals, truncation, timeouts, and malformed responses at the application boundary. Validate meaning after shape. An extracted total should agree with the document and any applicable arithmetic. A cited source identifier must refer to a source actually supplied. A schema cannot ordinarily decide these relationships by type checking alone. Keep the schema version with stored outputs and define compatibility rules before changing it. Downstream systems should reject or explicitly adapt incompatible versions. Avoid silently substituting fabricated defaults when a required piece of evidence is absent.

1. Use an invented receipt with subtotal 50, tax 5, and total 55. A model returns a valid object containing total: 550.
2. The value passes a numerical type check but fails comparison with the source and the subtotal-plus-tax relationship.
3. Flag it for correction and preserve the supporting text instead of accepting schema validity as proof.

The exercise distinguishes structural validation from evidence-based validation.