Diseñar el esquema y extraer datos

«Extrae todos los datos importantes» no es un contrato. Obliga al extractor a decidir qué significa «importante» y produce salidas difíciles de validar, comparar y consumir. En un sistema empresarial, el esquema debe nacer del proceso: qué campos necesita una decisión, qué sistema los recibe y qué ocurre si faltan o son ambiguos.

La extracción puede apoyarse en reglas, modelos preconstruidos, modelos personalizados o modelos generativos. La elección del mecanismo viene después. Primero define con precisión qué salida sería aceptable.

Define cada campo como parte de un contrato

Para cada campo especifica:

• nombre canónico;
• significado empresarial;
• tipo;
• cardinalidad;
• obligatorio, opcional o condicional;
• representación observada;
• representación normalizada;
• evidencia necesaria;
• reglas de validación;
• tratamiento de ausencia;
• consecuencia de error.

Para tablas, define la estructura de filas y columnas, la clave que identifica cada fila y la relación con encabezados. Para entidades repetidas, conserva orden e identidad en lugar de devolver una bolsa de valores sin contexto.

JSON Schema puede utilizarse para expresar requisitos estructurales sobre documentos JSON. Su versión 2020-12 define vocabularios de core y validación. Utilizar un esquema no resuelve la exactitud semántica del dato, pero sí ayuda a impedir que una salida mal formada avance como si fuera válida.

Separa observado, interpretado y normalizado

Una extracción robusta conserva distintos niveles:

• texto observado: lo que aparece en el documento;
• valor interpretado: lo que el extractor propone que significa;
• valor normalizado: la representación que utiliza el sistema;
• evidencia: página y región o fragmento que sostiene el valor;
• estado: pendiente de validación, válido, ambiguo, ausente o rechazado.

Por ejemplo, el documento puede mostrar 1.250,50 €. El valor normalizado puede ser 1250.50 y la moneda EUR. No elimines la representación original: permite revisar la transformación y detectar errores de formato regional.

Representa ausencias y ambigüedad sin inventar

null no debe significar simultáneamente «no aparece», «no pude leerlo», «no aplica» y «el extractor falló». Define estados distintos cuando esas diferencias cambien el proceso.

Si existen dos fechas candidatas, no elijas silenciosamente la que «parece más probable» salvo que exista una regla documentada y evaluada. Devuelve candidatos con evidencia, aplica una regla determinista o deriva a revisión.

Tampoco infieras atributos no presentes como si fueran documentales. Si el país se deduce del dominio del email o del idioma, ese valor es derivado y debe identificarse como tal. No debe sustituir al dato leído del documento.

Elige el método mínimo suficiente por clase y campo

No existe un extractor universal que deba usarse para todas las clases. Una plantilla muy estable puede resolverse con reglas o posiciones. Una factura común puede beneficiarse de un analizador preconstruido. Un documento variable puede requerir un modelo personalizado o una extracción generativa con salida estructurada.

La pregunta relevante no es qué tecnología «parece más inteligente», sino cuál alcanza los requisitos con coste, latencia y operación aceptables.

Puedes incluso combinar métodos: reglas para campos deterministas, un extractor documental para tablas y un modelo generativo para una cláusula variable. La salida debe converger en el mismo contrato y pasar por las mismas validaciones.

Conserva evidencia por campo

Una salida como total = 1250 es difícil de auditar si no puedes mostrar de dónde salió. Conserva página, región o span textual suficiente para que la interfaz de revisión lleve a la persona directamente al fragmento.

La evidencia ayuda a detectar errores sutiles: subtotal confundido con total, fecha de vencimiento confundida con emisión o identificador del receptor tomado como emisor.

No necesitas conservar todo el razonamiento del modelo. Necesitas trazabilidad desde el dato hasta el documento.

Ejemplo: contrato de factura

El esquema puede incluir emisor, identificador fiscal, número, fecha, moneda, líneas, base, impuestos y total. El identificador fiscal se cruza con el maestro de proveedores. El total conserva texto y región. Las líneas tienen cantidad, unidad, descripción, precio e importe.

Si la suma no concuerda, la extracción no se «corrige» por confianza. El valor pasa a estado inconsistente y la capa de validación decide la siguiente acción.

Ejercicio: dos contratos de extracción

Elige dos clases del curso y crea para cada una:

1. esquema tipado;
2. campos condicionales;
3. listas o tablas;
4. estados de ausencia;
5. evidencia requerida;
6. método candidato de extracción;
7. ejemplos válidos;
8. ejemplos ambiguos;
9. versión del esquema;
10. consumidor y consecuencia por campo crítico.

Después prueba el esquema contra documentos reales. Si cada variante obliga a añadir un campo nuevo, quizá estés modelando la plantilla visual y no el significado empresarial.

Qué debes poder demostrar

La extracción está bien especificada cuando diferentes técnicas pueden producir la misma estructura y esa estructura conserva suficiente evidencia para ser validada. En la siguiente lección separarás precisamente esas responsabilidades: normalizar, comprobar reglas y contrastar con fuentes externas antes de convertir una predicción en dato operativo.