Extracción de documentos con campos faltantes bajo control

Empieza por el contrato de salida, no por el prompt

La primera decisión consiste en definir exactamente qué debe devolver el sistema. Una solicitud como «extrae los datos del proveedor» deja ambigüedades sobre nombres, formatos, campos obligatorios y tratamiento de la información ausente. El contrato debe redactarse antes de elegir el modelo, porque convierte una tarea abierta en una operación verificable.

Para un registro hipotético de proveedores, el contrato puede exigir razón social, nombre comercial, identificación fiscal, dirección, ciudad, estado, correo electrónico, teléfono, datos bancarios y categoría de suministro. Cada campo necesita un tipo, un formato esperado, una condición de obligatoriedad y una regla de ausencia. Por ejemplo, la identificación fiscal debe ser una cadena normalizada, mientras que la fecha de vencimiento debe seguir un patrón definido por la empresa.

También conviene separar el valor extraído, el estado del campo y la evidencia. Un objeto conceptual puede contener valor, presente, confianza_operativa y fragmento_origen. La confianza no debe tratarse como verdad automática. Sirve para priorizar validaciones, mientras que el fragmento de origen permite investigar por qué un dato fue completado o quedó vacío.

• Define campos obligatorios, opcionales y prohibidos para cada tipo de documento.
• Elige formatos canónicos para fechas, números, identificadores y teléfonos.
• Usa valores nulos o un estado explícito para indicar ausencia, en lugar de texto inventado.
• Registra la página o el fragmento que respalda cada valor cuando sea posible.

Modela la ausencia como un resultado válido

Un campo faltante no es lo mismo que un campo ilegible, contradictorio o que no corresponde. Esta distinción cambia el flujo operativo. Si el contrato acepta solamente un valor o un nulo, el equipo pierde información importante. Una estructura más útil emplea estados como encontrado, ausente, ilegible, contradictorio y no aplicable, acompañados de una observación breve.

Considera un proveedor que envía el acta constitutiva sin datos bancarios. El sistema debe devolver datos_bancarios con el estado ausente, y no intentar completar la información a partir de patrones o de otro proveedor. Si aparecen dos identificaciones fiscales en páginas diferentes, el estado debe ser contradictorio, con los valores candidatos conservados para una decisión posterior. Esta regla reduce el riesgo de convertir un documento incompleto en un registro aparentemente completo.

La salida también debe distinguir entre «no localizado» y «no informado». El primero describe un problema de localización o lectura. El segundo indica que el documento fue examinado, pero no contiene el campo. Esta diferencia ayuda a decidir entre mejorar el OCR, solicitar una página adicional o pedir un documento complementario. El comportamiento recomendado aquí es una decisión de arquitectura, no una garantía ofrecida por el modelo.

• Crea una enumeración de estados antes de escribir instrucciones para el modelo.
• No permitas que el sistema complete vacíos mediante inferencias sin una regla explícita.
• Conserva varios candidatos cuando el documento presente valores contradictorios.
• Define qué estados bloquean el registro y cuáles solamente generan una incidencia.

Fuentes y referencias: [2]

Valida el registro en capas independientes

La validación debe realizarse después de la extracción y no depender únicamente del texto generado. Primero, valida el esquema: tipos, campos permitidos, valores nulos y enumeraciones. Después, aplica reglas de dominio, como cantidad de dígitos, formato de la identificación fiscal, abreviatura del estado, formato del correo electrónico y coherencia entre municipio y unidad federativa. Por último, compara el resultado con datos internos autorizados, cuando esa comparación forme parte del proceso.

En el ejemplo hipotético, una identificación fiscal con caracteres adicionales puede normalizarse sin alterar sus dígitos, pero una identificación con una cantidad incorrecta de dígitos debe recibir un error de validación. Un teléfono sin código de área puede aceptarse como incompleto, si esa es una regla del negocio. En cambio, una cuenta bancaria extraída de una imagen borrosa debe marcarse como ilegible, no corregirse mediante aproximaciones.

Estas capas deben producir motivos comprensibles para cada incidencia. «Campo inválido» es menos útil que «la identificación fiscal contiene una cantidad incorrecta de dígitos» o «el estado no corresponde a la lista permitida». Los mensajes específicos facilitan corregir el documento de entrada y permiten medir qué campos generan más problemas. La aplicación puede entonces dirigir solamente las excepciones, sin tratar toda extracción como un caso manual.

• Realiza la validación estructural antes de aplicar cualquier regla de negocio.
• Mantén la normalización separada de la corrección para conservar el valor original.
• Asocia cada fallo con un código y un mensaje que permita actuar.
• Bloquea los registros cuando falte un campo esencial o exista un conflicto crítico.

Prueba casos reales, incompletos y adversariales

Una demostración con documentos limpios no prueba el riesgo principal. Construye una colección de evaluación con contratos completos, páginas faltantes, fotografías inclinadas, tablas, sellos, abreviaturas, documentos en formatos variados y campos deliberadamente contradictorios. Para cada archivo, escribe la salida esperada y las condiciones de aprobación. El conjunto debe representar la distribución que el proceso recibe realmente, no solo los ejemplos más sencillos.

Evalúa cada campo por separado y también el registro completo. Las métricas de presencia correcta, valor exacto, formato válido, estado de ausencia y detección de contradicciones revelan fallos diferentes. Una salida puede acertar la razón social y aun así ser inadecuada porque inventó datos bancarios. En tareas estructuradas, las pruebas de clasificación, comparación y aprobación o rechazo suelen ser más útiles que una evaluación subjetiva del texto completo.

La evaluación debe continuar después de la implementación, porque los cambios en el prompt, el analizador, el OCR o el modelo pueden modificar el comportamiento. Registra entradas, salidas, validaciones y motivos de incidencia conforme a las reglas de gobernanza de la empresa. La documentación sobre evaluación recomienda pruebas específicas para la tarea, casos límite, registro sistemático y seguimiento continuo, en lugar de confiar en la impresión de que el sistema parece funcionar.

• Separa conjuntos de desarrollo, validación y prueba para evitar conclusiones frágiles.
• Incluye documentos sin campos obligatorios y documentos con valores contradictorios.
• Mide los falsos completados, no solamente los campos extraídos correctamente.
• Repite la evaluación después de cada cambio relevante en el flujo de procesamiento.
• Usa ejemplos de fallos para mejorar el contrato y las reglas, no únicamente el prompt.

Fuentes y referencias: [1]

Elige un flujo operativo que conserve el contexto

La extracción no tiene que terminar en un registro aprobado. Un flujo más seguro guarda el resultado estructurado, el origen de cada campo, los errores de validación y el estado del registro. Cuando falta un campo obligatorio, el sistema puede crear una incidencia con una solicitud específica, como «envía la página que contiene los datos bancarios». Cuando existe una contradicción, debe pedir aclaración sobre el valor, sin escoger silenciosamente un candidato.

Los documentos pueden contener instrucciones textuales que no forman parte de los datos, incluido contenido creado para influir en el comportamiento del sistema. Por eso, el texto extraído debe tratarse como un dato no confiable, no como una instrucción de ejecución. Las salidas estructuradas con nombres de campos fijos, listas cerradas y límites de tamaño ayudan a impedir que el contenido del documento llegue a etapas posteriores, como consultas, notificaciones o cambios en los registros.

Como ejemplo hipotético, una empresa podría comenzar solamente con razón social, identificación fiscal, dirección y correo electrónico, dejando los datos bancarios fuera de la primera versión. El flujo tendría tres resultados: registro listo, incidencia por información faltante y contradicción para análisis. Reducir el alcance hace que el contrato sea más fácil de probar y permite añadir campos solamente cuando existan reglas claras para extracción, validación, ausencia y actualización.

• Define estados del proceso además de aprobado y rechazado.
• Aísla el texto del documento de las instrucciones destinadas al sistema.
• Limita los campos que pueden alimentar integraciones o cambios automáticos.
• Conserva una trazabilidad técnica suficiente para reproducir la decisión del flujo.

Fuentes y referencias: [2][1]