IDP Build Schema

Tipo: idp-build-schema · Paquete: IDP Activities v1.18.0 · Salida: object

Traduce una taxonomía al JSON Schema que consume AI Extract. Por cada campo pide dos cosas: el valor interpretado y el texto literal del documento del que sale — que es lo que IDP Ground usa después para localizarlo.

Parámetros requeridos

Parámetro	Editor	Descripción
`taxonomy`	JSON	La taxonomía: la ruta de un `.json` o el objeto.

Salida

Devuelve un object con el JSON Schema, listo para pasárselo tal cual a AI Extract.

La taxonomía

Describe un tipo de documento, no una plantilla. Ahí está el negocio: la capa visual cambia de un hospital a otro, pero la semántica no. Un solo hoja-de-vida-equipo-biomedico.json sirve para todos.

{
  "documentType": "hoja-de-vida-equipo-biomedico",
  "description": "Ficha de un equipo biomédico. El formato varía entre hospitales.",
  "fields": [
    {
      "name": "serie",
      "type": "string",
      "description": "Número de serie del equipo, tal y como aparece impreso",
      "minConfidence": 0.95
    },
    {
      "name": "marca",
      "type": "string",
      "description": "Marca o fabricante del equipo",
      "minConfidence": 0.6
    }
  ]
}

Clave	Obligatoria	Qué es
`documentType`	sí	Identificador del tipo de documento.
`description`	no	Qué es este documento. Se le pasa al modelo como contexto.
`fields[].name`	sí	Nombre del campo en el resultado.
`fields[].type`	no	`string` (por defecto), `number`, `integer`, `boolean`, `date` o `table`.
`fields[].description`	sí	Qué es este campo.
`fields[].minConfidence`	no	Confianza exigida para darlo por bueno. Por defecto `0.8`.
`fields[].fields`	solo en `table`	Las columnas de la tabla.

Tablas: campos que se repiten

Un campo de tipo table es un campo que se repite: una fila por cada aparición en el documento. Es lo que permite extraer un historial de mantenimientos, un listado de repuestos o cualquier cosa con N entradas.

{
  "name": "mantenimientos",
  "type": "table",
  "description": "Historial de mantenimientos del equipo",
  "fields": [
    { "name": "fecha",   "type": "date",   "description": "Fecha del mantenimiento",  "minConfidence": 0.8 },
    { "name": "tipo",    "type": "string", "description": "Preventivo o correctivo",  "minConfidence": 0.7 },
    { "name": "tecnico", "type": "string", "description": "Nombre del técnico",       "minConfidence": 0.7 }
  ]
}

Las columnas se declaran igual que un campo normal, con su propia description y su propio minConfidence — porque una fecha y un nombre de técnico no se leen con la misma fiabilidad. La tabla en sí no lleva minConfidence: no se verifica como un todo, se verifica celda a celda.

Los umbrales van por campo

minConfidence es la confianza mínima para aceptar el campo sin que lo mire una persona. Cuanto más alto, más estricto.

Va por campo a propósito. Un número de serie es alfanumérico y sin redundancia lingüística: es justo donde el OCR falla, y donde equivocarse sale caro — así que se le exige casi certeza (0.95). Una marca se lee siempre bien y el contexto la corrige sola, así que exigirle lo mismo solo mandaría a revisión trabajo que no la necesita (0.6).

Un umbral único para todo el documento manda todo a revisión y mata el ROI.

Ejemplo

IDP Build Schema   taxonomy = = asset("taxonomias/hoja-de-vida.json")   → output: schema
AI Extract         credential = = credential("anthropic-key")
                   prompt     = = doc["text"]
                   schema     = = schema
                   → output: extraccion

Actividades relacionadas

IDP Ground — el paso siguiente: localizar y validar lo extraído.
AI Extract — la llamada al modelo que usa este esquema.