Documento - La verdad fundamental de la IA más allá del OCR: orden de lectura, tablas, campos y relaciones entre páginas

Los sistemas de Document AI hacen más que OCR: necesitan recuperar la estructura y las relaciones que hacen que una página sea utilizable. Para los equipos que crean conjuntos de datos de entrenamiento para IA, un modelo puede transcribir cada palabra correctamente y aun así fallar en el flujo de trabajo para el que fue creado.

Una factura puede contener el importe correcto, pero tenerlo asignado a la línea de detalle equivocada. Un informe a dos columnas puede contener todas las frases, pero tener las columnas unidas en el orden incorrecto. Una tabla puede conservar el valor de cada celda, pero tener un valor bajo el encabezado equivocado. Estos son errores de comprensión de documentos que las tasas de error de caracteres o de palabras, por sí solas, no pueden detectar.

Por eso, los datos de referencia (ground truth) de Document AI deben ir más allá del texto verificado. Si la aplicación depende del orden de lectura, la topología de la tabla, las relaciones entre campos o la continuidad entre páginas, el conjunto de datos de referencia necesita etiquetas para esas relaciones, de modo que cada una pueda evaluarse por separado.

La distinción no radica en que el OCR moderno esté limitado al texto plano. Los sistemas actuales, como Google Cloud Document AI, pueden devolver texto OCR, coordenadas y señales de maquetación. La distinción más útil es entre la precisión del reconocimiento de texto y la precisión estructural: una métrica de transcripción puede indicar si las palabras se reconocieron, pero no si se reconstruyeron correctamente las relaciones del documento necesarias para la tarea.

Los datos de referencia (ground truth) de Document AI consisten en datos de referencia verificados que se utilizan para entrenar o evaluar sistemas que convierten documentos en información estructurada. Según la tarea, pueden incluir texto OCR y regiones de diseño, orden de lectura, estructura de tablas, campos con nombre, relaciones clave-valor, clases de documentos, límites de página y enlaces entre páginas.

Los datos de referencia deben coincidir con la salida que se evalúa. Si se espera que un modelo recupere una jerarquía de tablas, empareje un campo con su valor o recupere una tabla que se extiende a través de un salto de página, la transcripción verificada es necesaria pero no suficiente. El conjunto de evaluación debe registrar la relación en sí.

Esto también explica por qué la expresión “precisión del OCR” requiere cuidado. La tasa de error de caracteres (CER) y la tasa de error de palabras (WER) miden el texto reconocido con respecto a una transcripción de referencia. Son útiles para la calidad del OCR, pero no indican si un importe reconocido correctamente se asignó al campo correcto ni si los bloques reconocidos correctamente se colocaron en la secuencia correcta.

El orden de lectura parece trivial en una carta de una sola columna. Se convierte en un problema de anotación independiente en cuanto una página contiene dos columnas, una barra lateral, una cita destacada, una nota al pie, un pie de foto flotante o un formulario con varios grupos alineados.

Por lo tanto, los datos de referencia necesitan una unidad explícita de ordenación. Un proyecto podría ordenar bloques, regiones, líneas u otra unidad de maquetación, pero la regla debe fijarse antes de que comience la anotación de producción. De lo contrario, dos revisores cuidadosos pueden discrepar mientras ambos creen que están siguiendo el “orden de lectura natural”.

La investigación reciente considera el orden de lectura como una tarea medible en lugar de un subproducto informal de la detección de maquetación. LaTeX2Layout, publicado en AAAI 2026, recupera tanto las regiones de maquetación como el orden de lectura a partir de trazas del compilador y evalúa la concordancia de la secuencia mediante la tau de Kendall, por separado del anclaje de elementos. ROOR también anota el orden de lectura como relaciones de ordenación explícitas en lugar de suponer que las cajas de región implican una secuencia.

La misma tendencia se observa en benchmarks más recientes de documentos visualmente ricos. MosaicDoc, también publicado en AAAI 2026, combina anotaciones de OCR, orden de lectura y localización, así como preguntas y respuestas sobre documentos en maquetaciones complejas de periódicos y revistas. La lección útil no es una puntuación concreta de un benchmark: localizar las regiones correctas y ordenar esas regiones son capacidades diferentes, por lo que un conjunto de evaluación no debería tratarlas como intercambiables.

Si la secuencia importa para la tarea posterior, la secuencia necesita sus propias etiquetas de referencia.

La extracción de tablas tiene al menos dos modos de fallo distintos. Un modelo puede leer mal el texto dentro de una celda, o puede leerlo correctamente pero asignar la celda a una fila incorrecta, una columna incorrecta o una jerarquía visual de encabezados incorrecta. Una única cifra de precisión combinada hace que esos fallos sean difíciles de diagnosticar.

La similitud basada en la distancia de edición de árboles (TEDS), introducida con PubTabNet, compara una representación de tabla predicha con la de referencia como un árbol. Las variantes centradas solo en la estructura, que suelen reportarse como TEDS-Struct o TEDS-S, ignoran el texto de las celdas para que los errores de transcripción no dominen la puntuación estructural. Los benchmarks actuales de 2026 para la extracción de tablas siguen reportando TEDS y TEDS-S por separado exactamente por esta razón.

Esta separación es útil desde el punto de vista operativo. Si el rendimiento cae tras un cambio en el modelo, un equipo necesita saber si la regresión se debió al OCR, a una celda combinada no detectada, a un límite de columna desplazado o a una relación encabezado-cuerpo incorrecta. Esos problemas requieren soluciones diferentes.

El dominio del conjunto de datos también importa. PubTabNet se construyó a partir de tablas de artículos científicos, mientras que FinTabNet se creó a partir de documentos financieros. Un modelo que funciona bien con una población puede tener dificultades cuando cambia la gramática del diseño, especialmente en torno a encabezados anidados, subtotales, celdas combinadas y formatos financieros densos.

Supongamos que un formulario contiene tres apariciones de la etiqueta “Date”: fecha de factura, fecha de vencimiento y fecha de entrega. Un modelo puede localizar cada etiqueta y cada valor de fecha, transcribir correctamente los seis fragmentos y aun así fallar si los empareja incorrectamente.

Por eso, la extracción de campos a menudo necesita etiquetas de relación en lugar de solo cajas. El conjunto de datos original FUNSD hace explícita esta distinción: etiqueta las entidades semánticas, como preguntas y respuestas, y registra por separado los vínculos entre esas entidades. La anotación no solo indica “este texto existe aquí”, sino también “estas dos piezas van juntas”.

La parte difícil es definir la unidad que se puede vincular. Una dirección de varias líneas podría ser un solo valor, varias líneas o un conjunto de campos anidados. Un esquema vago permite que cada anotador tome una decisión diferente, lo que convierte el desacuerdo en ruido en la verdad de referencia.

Ese riesgo no es teórico. Los investigadores que revisaron FUNSD documentaron etiquetas inconsistentes y revisaron el conjunto de datos para la detección de pares clave-valor. Los trabajos posteriores de reetiquetado han seguido destacando inconsistencias de granularidad y de vinculación. La lección práctica es sencilla: defina los límites de las entidades y las reglas de vinculación usando ejemplos difíciles antes de que un equipo grande de anotación comience.

El preetiquetado asistido por modelos puede reducir el trabajo repetitivo. Un modelo puede proponer cajas, campos, tablas o vínculos, y un revisor puede corregirlos. Pero la propuesta debe seguir siendo una propuesta: hay que capacitar a los revisores para que busquen errores estructurales que parezcan plausibles, en lugar de asumir que la salida con alta confianza de un modelo ya es la verdad de referencia.

Un vínculo faltante no es el mismo defecto que un campo faltante. La etiqueta y el valor pueden estar presentes y perfectamente transcritos mientras que la relación entre ellos es incorrecta.

Una página no siempre es la unidad de evaluación adecuada. Una tabla puede empezar en la página 4 y continuar en la página 5. Un lote escaneado puede contener tres facturas consecutivas porque llegaron en un solo PDF. Una referencia en el cuerpo puede apuntar a un apéndice varias páginas más adelante. Un encabezado de sección puede establecer una jerarquía que continúa a través de los saltos de página.

Esas relaciones necesitan etiquetas a nivel de documento si la aplicación depende de ellas. Algunos ejemplos útiles son:

• Continuación de tabla: si dos fragmentos pertenecen a la misma tabla lógica y cómo debe unirse la continuación.

• Límites de documentos: dónde termina un documento lógico y dónde comienza el siguiente dentro de un escaneo o paquete combinado.

• Referencias cruzadas: a qué figura, tabla, sección o nota apunta realmente una referencia.

• Estructura jerárquica: cómo se anidan los encabezados, subencabezados y secciones del cuerpo a lo largo de todo el documento.

Esto es más difícil de anotar de forma consistente que dibujar recuadros en páginas aisladas. Los revisores necesitan suficiente contexto para comprender todo el documento, y el trabajo es más difícil de repartir entre varias personas sin perder la continuidad.

Los benchmarks públicos reflejan cada vez más esa realidad. DUDE se diseñó en torno a documentos visualmente ricos, de varias páginas y de varios dominios, mientras que VRDU hace hincapié en esquemas ricos, plantillas complejas, campos repetidos y anidados, y diversidad de maquetación en documentos empresariales. La cuestión para un conjunto de datos de producción no es imitar un benchmark, sino decidir de qué relaciones entre páginas depende la aplicación real y etiquetar esas relaciones de forma deliberada.

Las métricas separadas no son una simple labor de mantenimiento académico. Permiten diagnosticar los fallos.

Imagina que un sistema de extracción de campos empeora tras una actualización del modelo. Si el único resultado es “92% de precisión”, la cifra no indica al equipo dónde buscar. La regresión podría provenir del reconocimiento de texto, el orden de lectura, la estructura de tablas, la vinculación de campos, los límites del documento o varios de ellos a la vez.

Un conjunto de evaluación útil mantiene esas señales lo bastante diferenciadas como para investigarlas. Eso no significa que todos los proyectos necesiten una docena de métricas en el panel. Significa que la métrica reportada debe corresponder a la afirmación que se hace. Si el objetivo es la transcripción, reporta una métrica de transcripción. Si el objetivo es la estructura de tablas, reporta una métrica de estructura. Si el objetivo es la extracción de pares clave-valor, define cómo se puntúan tanto la detección como la vinculación de entidades.

Si dos errores requieren correcciones diferentes, normalmente deben seguir siendo distinguibles en la evaluación. Una puntuación resumida puede seguir siendo útil, pero no debería sustituir las medidas de los componentes necesarias para diagnosticar qué cambió.

Una métrica de calidad sin su método de medición no es evidencia. “95% de precisión” solo resulta útil cuando quien lee sabe qué se consideró correcto, qué etiquetas de referencia se usaron y cómo se resolvieron los casos ambiguos.

Las mismas palabras pueden dar lugar a un problema de comprensión de documentos muy distinto cuando cambia la maquetación. Eso hace que la variación controlada del diseño sea una forma útil de comprobar si un modelo ha aprendido la estructura del documento o solo plantillas conocidas.

Un experimento práctico consiste en mantener el contenido constante y cambiar una variable de maquetación a la vez:

• texto a una sola columna frente a dos columnas;
• un valor de campo colocado junto a su etiqueta frente a uno alineado a cierta distancia;
• un encabezado de tabla simple frente a encabezados combinados o anidados;
• un pie de foto directamente debajo de una imagen frente a una llamada flotante;
• una tabla que se mantiene en una página frente a la misma tabla que continúa en una segunda página.

Ejecute las variantes con el mismo flujo de procesamiento de documentos mediante OCR/IA y puntúe por separado la transcripción y la estructura. Si las palabras siguen siendo correctas mientras el orden de lectura, la topología de la tabla o los vínculos entre campos se deterioran, la prueba ha aislado un problema de generalización de la maquetación en lugar de un problema de OCR.

Para una publicación centrada en el diseño, este es un enfoque informativo más creíble que otra lista genérica de beneficios de la IA para documentos. Convierte el diseño de página en una variable controlada que se puede medir. No publique hallazgos numéricos a menos que el experimento se haya ejecutado realmente y su metodología esté documentada.

Un proyecto no necesita todas las capas de forma predeterminada. Necesita las capas que corresponden a decisiones reales posteriores. Es posible que un sistema de clasificación de documentos no necesite etiquetas de tabla a nivel de celda. Probablemente un sistema de automatización de facturas sí las necesite. El objetivo no es lograr la máxima densidad de anotación; se trata de contar con datos de referencia suficientes para evaluar las tareas que realmente importan.

Los errores costosos suelen ocurrir antes de que se etiquete el primer lote de producción. Un flujo de trabajo viable es el siguiente:
1. Defina el esquema primero. Decida qué cuenta como campo, tabla, unidad de orden de lectura y límite de documento. Incluya ejemplos difíciles en lugar de solo páginas ideales.

2. Ejecute un lote piloto. Utilice una muestra pequeña pero variada para encontrar desacuerdos en las directrices antes de que se propaguen por miles de páginas.

3. Mida el desacuerdo donde la ambigüedad importa. No toda etiqueta necesita una estadística formal de acuerdo entre anotadores, pero el desacuerdo recurrente debería desencadenar un cambio en las directrices o una regla de adjudicación, en lugar de promediar en silencio.
4. Utilice el preetiquetado asistido por modelo de forma selectiva. La automatización es útil para propuestas repetitivas, mientras que la atención humana debería concentrarse en las relaciones y los casos límite en los que equivocarse resulta costoso.
5. Puntúe el contenido y la estructura por separado. Mantenga separadas la transcripción, la topología de tablas, la vinculación de entidades y las relaciones entre páginas, lo suficiente como para diagnosticar regresiones.
6. Versione el esquema y preserve la procedencia. Un equipo debería poder saber qué versión de las directrices produjo una etiqueta, cómo se revisó y por qué se aceptó una excepción.

Un esquema mínimo útil es mejor que un esquema elaborado que nadie pueda aplicar de forma consistente. Defina solo las etiquetas que respondan a preguntas reales del modelo o del producto, y luego haga que esas etiquetas sean reproducibles.

Si va a licenciar, encargar o aprobar un conjunto de datos de documentos, haga preguntas que revelen la estructura que hay detrás de la cifra de exactitud destacada:
• ¿Cuál es la unidad de anotación del orden de lectura: palabras, líneas, bloques o regiones?
• ¿Se evalúan por separado la estructura de la tabla y el texto de las celdas?
• ¿Las relaciones clave-valor se etiquetan explícitamente o se infieren por proximidad?
• ¿Cómo se manejan los campos repetidos, anidados y de varias líneas?
• ¿Están disponibles las etiquetas de continuación y de límite de documento en todas las páginas?
• ¿Qué casos ambiguos se documentan en las directrices de anotación?
• ¿Hubo una prueba piloto y un proceso de adjudicación para resolver los desacuerdos entre revisores?
• ¿Se puede rastrear la versión del conjunto de datos hasta una versión del esquema y un lote de producción?
• ¿Qué métricas se reportan y qué se considera exactamente una predicción correcta?

Esas preguntas suelen revelar más sobre la idoneidad del conjunto de datos que una única cifra agregada de exactitud.

Si todavía está en la etapa anterior de obtención de datos, la guía de DesignWizard para encontrar conjuntos de datos profesionales para proyectos de aprendizaje automático aborda el descubrimiento y la obtención de conjuntos de datos desde una perspectiva más amplia. Este artículo comienza un paso después, cuando la pregunta pasa a ser qué deben contener las propias etiquetas de referencia.

Para los equipos que encargan datos de documentos, la página de Wavebreak Media sobre conjuntos de datos de documentos para el entrenamiento de IA abarca conjuntos de datos de documentos con licencia y personalizados para OCR, comprensión del diseño, extracción de campos, tablas y metadatos estructurados. Para proyectos comerciales, su guía sobre licencias de conjuntos de datos de IA también abarca los derechos de uso, la procedencia, las autorizaciones y la documentación de respaldo. Un proyecto de IA para documentos debe seguir definiendo su propio esquema estructural y sus criterios de aceptación, en lugar de suponer que la palabra “anotado” cubre las relaciones que necesita.

¿Qué es la verdad fundamental de la IA para documentos?

La verdad fundamental de la IA para documentos es un conjunto de datos de referencia verificados que se utilizan para entrenar o evaluar sistemas que interpretan documentos. Según la tarea, puede incluir transcripción, orden de lectura, estructura de tablas, relaciones entre campos, límites de documentos y enlaces entre páginas.

¿Cuál es la diferencia entre la precisión del OCR y la precisión de la IA para documentos?

Las métricas de OCR, como CER y WER, miden si el texto se reconoció correctamente. La evaluación de la IA para documentos también puede necesitar medir si las regiones se ordenaron correctamente, si las tablas se reconstruyeron correctamente, si los campos se vincularon con los valores correctos y si se conservaron las relaciones entre páginas.

¿Qué anotaciones necesita un conjunto de datos de IA para documentos?

Solo las anotaciones que requiere la tarea posterior. Un extractor de formularios puede necesitar vínculos clave-valor y reglas de campos repetidos; un sistema de tablas puede necesitar anotaciones de filas, columnas, combinaciones de celdas y encabezados; un flujo de trabajo de varias páginas puede necesitar límites de documentos y etiquetas de continuación.

¿Cómo se evalúa el orden de lectura en un documento?

Primero defina la unidad que se va a ordenar, como bloques o regiones, y luego compare la secuencia predicha con una secuencia de referencia. Los benchmarks de investigación utilizan medidas de ordenación como la tau de Kendall, pero la métrica adecuada depende de la anotación y de la tarea.

¿Cómo se mide la precisión de la estructura de una tabla por separado del OCR?

Métricas como TEDS-Struct o TEDS-S comparan la estructura de la tabla sin incluir el texto de las celdas. Eso permite evaluar por separado los errores estructurales, como la pertenencia incorrecta a una fila o columna o las combinaciones de celdas omitidas, frente a los errores de transcripción.

¿Se puede reutilizar un conjunto de datos de OCR existente para la evaluación de la IA para documentos?

A veces, pero normalmente solo para las capas que ya etiqueta. Si la aplicación depende del orden de lectura, la estructura de tablas, los vínculos entre campos o las relaciones entre páginas, es posible que esas etiquetas deban añadirse antes de que el conjunto de datos pueda evaluar la tarea completa.

¿Cómo se evalúan los sistemas de IA para documentos de varias páginas?

Utilice referencias a nivel de documento para las relaciones que cruzan los límites de las páginas: continuación de tablas, límites de documentos, secciones jerárquicas y referencias cruzadas. La precisión por página por sí sola no puede mostrar si se conservaron esas relaciones.

¿Qué debe comprobar un comprador antes de encargar la anotación de documentos?

Pregunte qué relaciones están etiquetadas explícitamente, cómo se definen los casos difíciles, cómo resuelven los revisores los desacuerdos, qué proceso de control de calidad se utiliza y qué mide realmente cada métrica reportada.

En la IA documental, el error más fácil de medir es un carácter incorrecto. Muchos de los fallos costosos ocurren después de que los caracteres ya son correctos.

Una celda de tabla queda bajo el encabezado incorrecto. Un valor se vincula con la etiqueta incorrecta. Dos columnas se leen en el orden incorrecto. Una continuación de tabla se trata como una tabla nueva porque el conjunto de evaluación nunca registró que las páginas pertenecían a la misma tabla.

Una verdad de referencia bien construida hace visibles esas relaciones. La precisión del texto indica qué se reconoció; la verdad estructural de referencia indica si la salida se organizó como requiere la tarea.

Esa es la línea divisoria útil para la evaluación: si una decisión posterior depende de una relación, la especificación del conjunto de datos debería indicar cómo se representa, se revisa y se puntúa esa relación.