Diseño de Schema

El Schema que pasas a /extract es también un prompt. Cada nombre de campo, descripción y pista de tipo es leída por el modelo. Un Schema bien diseñado mejora la precisión drásticamente.

Nombres de campo

Usa nombres que se lean como inglés. El modelo es mucho mejor con productName que con pn o name1.

{ "type": "object", "properties": {
  "productName": { "type": "string" },
  "currentPrice": { "type": "number" }
} }

Descripciones de campo

Añade description a cualquier cosa ambigua. "price" podría ser MSRP, actual o por unidad — sé explícito:

{ "currentPrice": {
  "type": "number",
  "description": "Final price after discount, in USD"
} }

Required vs opcional

Marca solo los campos que realmente necesitas. Los campos required hacen que toda la extracción falle si el modelo no los encuentra — úsalos con moderación.

Anidamiento

Prefiere un nivel de anidamiento donde sea útil (address.city). Anidamientos más profundos (3+ niveles) tienden a degradar la calidad de la extracción.

Errores comunes

• Usar tipos ambiguos (string para números como "$19.99") — prefiere number y deja que el modelo lo parsee
• Enums vagos sin descripciones
• Campos required que no están realmente presentes en cada página

Esta página se está ampliando con un recetario de Schemas — vuelve pronto.