Cuando se utiliza una herramienta de calidad de datos, usualmente se utilizan algoritmos y reglas de matching que nos permiten determinar si dos o más registros son o no un match.
Esto es usualmente útil cuando necesitamos determinar clientes, productos, personas duplicadas o personas, clientes que compartan por ejemplo el mismo domicilio.
Con una búsqueda por igual, tal cual podemos ejecutar en una herramienta de ETL o sobre cualquier motor de base de datos no vamos a poder alcanzar el nivel de exactitud y certeza que necesitamos ya que usualmente nos encontraremos con nombres y apellidos de personas mal escritos, errores de tipeo, diferentes formas de escribir una dirección. Esto hace que la búsqueda por igual no sirva para resolver esta problematica.
Es en este punto donde los algoritmos probabilísticos son realmente útiles. Estos algoritmos permiten elevar el grado de exactitud en el matching y permiten ponderar con pesos (positivos y negativos) los errores enunciados anteriormente, pudiéndose determinar si dos o más registros son los mismos.
Pero no todo es tan sencillo como suena ya que hay un conjunto de condiciones que hay que manejar y que son un desafío importante para quien desarrolla una regla de matching.
Las distintas herramientas de calidad difieren en como asignan los pesos para determinar si dos o más registros son o no un match pero en general hay tres resultados posibles en este proceso:
- Registros sin Relación (llamados Residuales en QualityStage)
- Match
- Sospechoso (llamados Clericals en QualityStage)
En términos generales si la suma de los pesos generados al comparar dos registros son positivos esto es un Match, por lo contrario, si los pesos son cero o negativos es un Residual.
Ahora bien… ¿y cuando se generan registros Sospechosos o Clericals?
Para ser más estricto y complicar un poco el tema, no siempre que se genere un peso positivo va indicar que dos registros son un match. Hay veces que el peso es muy cercado a cero y difiere mucho de la media de los pesos de los registros que si son efectivamente un match. Es en estos casos donde es posible configurar la herramienta para modificar el comportamiento default de la misma y tratar a esos registros como Sospechosos o directamente Residuales (No Match).
Este proceso es un proceso iterativo que requiere mucho de prueba y ajuste de la regla de matching para evitar errores en el proceso o lo que se conoce como falsos positivos y falsos negativos, es decir registros que dieron Match pero no lo son o registros que no dieron Match pero si lo son.
Las herramientas de calidad de datos brindan interfases para ayudar a “tunear” la regla para hacerla más exacta y eficiente.
A continuación se ve la interfaz del Match Designer de QualityStage desde donde podemos definir la regla de match así como probarla, ajustarla y definir los umbrales de No Match, Clerical y Match.
De lo anteriormente explicado, queda claro que todo proceso de matching se va a componer de registros que serán procesados automáticamente (Match y Residuales) y también registros que requerirán un tratamiento manual. Tal es el caso de los Clericals o Sospechosos.
Para estos registros la herramienta no ha podido determinar automáticamente si son o no un match y es por ello que requiere revisión manual.
En este punto el desafío mas importante para el diseñador y desarrollador de la regla es ajustar la misma lo más posible para limitar la cantidad de sospechosos pero teniendo en cuenta de no cometer errores de matching (falsos positivos y negativos). Otro punto muy importante a tener en cuenta es definir claramente un procedimiento para el tratamiento de estos registros sospechosos.
Muchas de las herramientas también brindan funcionalidades que permiten analizar y procesar manualmente, de una manera sencilla, estos registros a fin de que luego se conviertan definitivamente en un Match o no.
