Design de Schema

O schema que você passa para /extract é também um prompt. Cada nome de campo, descrição e dica de tipo é lido pelo modelo. Um schema bem desenhado melhora drasticamente a precisão.

Nomenclatura de campos

Use nomes que se leiam como inglês. O modelo é muito melhor com productName do que com pn ou name1.

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

Descrições de campos

Adicione description em qualquer coisa ambígua. "price" pode ser MSRP, atual ou por unidade — seja explícito:

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

Obrigatório vs opcional

Marque apenas os campos que você realmente precisa. Campos obrigatórios fazem a extração inteira falhar se o modelo não os encontrar — use com parcimônia.

Aninhamento

Prefira um nível de aninhamento quando útil (address.city). Aninhamento mais profundo (3+ níveis) tende a prejudicar a qualidade da extração.

Armadilhas comuns

• Usar tipos ambíguos (string para números como "$19.99") — prefira number e deixe o modelo fazer o parse
• Enums vagos sem descrições
• Campos obrigatórios que não aparecem em todas as páginas

Esta página está sendo expandida com um cookbook de schemas — volte em breve.