Schema Design

Lo schema che passi a /extract è anche un prompt. Ogni nome di campo, descrizione e suggerimento di tipo viene letto dal modello. Uno schema ben strutturato migliora drasticamente l'accuratezza.

Naming dei campi

Usa nomi che si leggano come l'inglese. Il modello è molto migliore con productName rispetto a pn o name1.

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

Descrizioni dei campi

Aggiungi description a tutto ciò che è ambiguo. "price" potrebbe essere MSRP, attuale o per unità — sii esplicito:

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

Required vs optional

Marca come required solo i campi di cui hai veramente bisogno. I campi required fanno fallire l'intera estrazione se il modello non riesce a trovarli — usali con parsimonia.

Annidamento

Preferisci un livello di annidamento dove utile (address.city). L'annidamento profondo (3+ livelli) tende a peggiorare la qualità dell'estrazione.

Insidie comuni

• Usare tipi ambigui (string per numeri come "$19.99") — preferisci number e lascia che il modello faccia il parsing
• Enum vaghi senza descrizioni
• Campi required che in realtà non sono presenti su ogni pagina

Questa pagina è in fase di ampliamento con un cookbook di schema — torna a controllare presto.