Usar elementos de grupo para buscar objetos es lo más eficiente, porque agrupar elementos reduce el número de hipótesis de un elemento y acelera la búsqueda de la hipótesis resultante para todo el FlexiLayout. Además, si la agrupación de los elementos refleja la lógica del documento, ayuda a optimizar la estructura del FlexiLayout y a hacerla más explícita.
Agrupar varios elementos en un único elemento de grupo permite que el programa trate este conjunto de elementos como un todo con su propia hipótesis (compuesta por hipótesis individuales de los elementos del grupo). El análisis de las hipótesis y de sus elementos tiene lugar dentro del elemento de grupo, y solo el número de mejores hipótesis especificado por el usuario (1 de forma predeterminada) se usa en la búsqueda posterior de otros elementos.
Todo el árbol de elementos puede considerarse un elemento de grupo, cuya mejor hipótesis es el resultado del emparejamiento del FlexiLayout.
Estudiemos el proyecto GroupSample.fsp (carpeta %public%\ABBYY\FlexiCapture\12.0\Samples\FLS\Tips and Tricks\Group\Project1) para ver cómo se pueden usar los elementos de grupo. Aquí tenemos una imagen en la que queremos detectar campos con el número de factura, la fecha de la factura y el importe de la factura.
Como puede verse en la imagen (y esto suele ocurrir en todos los documentos financieros), el número y la fecha del documento son campos contiguos. Aunque la disposición de los campos en otro documento sea diferente, seguirán estando cerca entre sí. Además, están relacionados por la lógica del documento, ya que describen determinados datos bancarios y forman un bloque lógico. Para hacer más explícita la estructura del FlexiLayout, los agruparemos en un elemento de grupo llamado InvoiceRequisiteGroup.
Antes de agrupar los elementos, creamos un elemento identificador especial. (Los elementos identificadores se describen en detalle en la sección “Identificación y procesamiento de FlexiLayouts en ABBYY FlexiCapture”). Este elemento se creó únicamente para ilustrar la “ramificación” del árbol de hipótesis provocada por la presencia o ausencia de elementos de grupo en él. Supongamos que todos los elementos del árbol, excepto el elemento identificador, son opcionales, y que sus hipótesis nulas tienen la calidad predeterminada de 0.97.
Aquí no describimos la configuración de los elementos. Puede consultarla directamente en el proyecto.
El árbol de hipótesis consta de una sola cadena. La calidad del Grupo coincide con la calidad de la mejor cadena del Grupo.
Haga doble clic en InvoiceRequisiteGroup para abrir su cuadro de diálogo de propiedades, donde podremos ver qué hipótesis se generaron para sus subelementos, qué cadena del Grupo resultó ser la mejor y por qué.
Vemos que hay tres hipótesis para el elemento InvoiceNumHeader, igual que el número de cadenas “invoice” detectadas. La calidad de la hipótesis que nos interesa es inferior (aproximadamente 0.99), porque su área en la imagen tiene ruido y el programa solo pudo reconocer “INVOIC” en lugar de “INVOICE”. La calidad de las otras dos hipótesis, en cambio, es máxima (Chain quality = 1).
Al crear el elemento InvoiceNum especificamos que el número de factura puede tener cualquier cantidad de dígitos y debe buscarse a la derecha del nombre. En nuestra imagen, estas condiciones se cumplen en los tres casos, lo que permitió al programa seguir creando una cadena de hipótesis para cada una de las hipótesis del nombre del campo “Número de factura”. Cabe señalar que, aunque la Pre-search quality de cada una de las hipótesis del elemento InvoiceNum es 1, la cadena que consideramos correcta sigue siendo la peor. Esto ocurrió porque la calidad de la cadena se evalúa multiplicando las calidades de todas las hipótesis que forman la cadena. Para el nombre obligatorio, esta calidad es de aproximadamente 0.99. Si el Grupo no tuviera ningún otro elemento, la elección final en esta etapa sería incorrecta.
No especificamos Post-search relations para ninguno de los elementos, por lo que para cada uno de ellos la Post-search quality = 1, y podemos juzgar la calidad de cualquier hipótesis por su Pre-search quality.
La búsqueda de la mejor hipótesis se realiza dentro del Grupo. Se analizan y comparan las calidades de todas las cadenas. La calidad del Grupo vendrá determinada por la calidad de la mejor cadena del Grupo.
Como señalamos antes, en las propiedades del elemento InvoiceDateHeader especificamos que debía buscarse debajo de la línea con el número de factura. Sin embargo, ninguna de las cadenas con la mejor calidad (Chain quality = 1) produjo una hipótesis para el nombre del campo de fecha. En consecuencia, se formaron hipótesis nulas en estas cadenas para el elemento InvoiceDateHeader. Como no cambiamos la calidad predeterminada de una hipótesis nula, la Chain quality resultante de las cadenas correspondientes bajó a 0.97. Al mismo tiempo, el elemento correspondiente al nombre del campo de fecha se encontró para la cadena que tenía la calidad más baja. La calidad de su hipótesis es de aproximadamente 0.993. Es inferior a 1 porque la imagen en el área del nombre tiene ruido, lo que provocó un error de reconocimiento y una coincidencia incompleta entre el texto reconocido y el valor especificado en las propiedades del elemento InvoiceDateHeader. Como resultado, la hipótesis encontrada fue penalizada y su calidad final es de aproximadamente 0.98 (el resultado de multiplicar 0.99 por 0.993). No obstante, la calidad final de esta hipótesis es superior a la de las demás (0.97), por lo que en esta etapa esta cadena es la mejor.
Para detectar el campo de fecha, creamos el elemento de grupo DateGroup, que especifica que al menos uno de los elementos no puede encontrarse si el otro se ha encontrado (se utilizó la función Dontfind). Como resultado de las características del diseño del documento y de las propiedades especificadas para el elemento InvoiceDateAsString (su alfabeto permite dígitos), el programa logró encontrar el campo de fecha para todas las cadenas, aunque en realidad solo una de las tres hipótesis es correcta.
Como en cada Grupo se ha encontrado uno de los elementos mientras que el otro no, la calidad final de la cadena en cada uno de los grupos DateGroup es 0.97 (1 multiplicado por 0.97, la calidad predeterminada de la hipótesis nula). En este ejemplo, la calidad final de las cadenas de DateGroup no afectará al “equilibrio” entre las hipótesis en el momento de detectar el elemento InvoiceDateHeader; es decir, la calidad de cada una de las cadenas simplemente volverá a multiplicarse por 0.97.
Al final, el programa generó una sola hipótesis para el elemento de grupo InvoiceRequisiteGroup, que corresponde a la mejor cadena del Grupo. Su calidad es de aproximadamente 0.953; es decir, el “enfoque de grupo” ayudó a que se impusiera la hipótesis correcta, aunque su calidad inicial era menor.
Para ilustrar cómo se vería el árbol de hipótesis sin elementos de grupo en FlexiLayout, creamos el proyecto GroupSample.fsp (carpeta Group\Project2). El árbol puede verse en la figura siguiente. Como se aprecia claramente en la figura, después de detectar el elemento FormID, el árbol de hipótesis se ramificó porque se generan varias hipótesis para el elemento InvoiceNumHeader. Como resultado, el programa tiene que comparar los valores de calidad de cada una de las cadenas, comenzando cada vez por su primer elemento y descendiendo hasta el último. Además, para cualquier documento con un diseño más complejo que el de este ejemplo, un FlexiLayout sin elementos de grupo producirá un árbol de hipótesis con demasiadas ramas, lo que dificultará el emparejamiento de FlexiLayout.
No se recomienda colocar todos los elementos buscados en un único grupo raíz. Esto solo es adecuado para FlexiLayouts muy simples con menos de 10 elementos, algo muy poco frecuente en tareas reales. Un aumento del número de elementos en el grupo raíz provoca un crecimiento masivo del número de hipótesis, hasta alcanzar el límite de 10.000 o agotar toda la memoria asignada al árbol de hipótesis. En cualquiera de los dos casos, el emparejamiento del FlexiLayout puede fallar.
Un árbol de hipótesis sin agrupar tiene demasiadas ramas y resulta difícil de analizar visualmente.
Además, dado que la calidad de la cadena final se calcula multiplicando los valores de calidad de todas las hipótesis de esa cadena, el volumen de cálculos puede ser mucho mayor en un árbol con demasiadas ramas, lo que hará que el emparejamiento de FlexiLayout sea más lento. 