Record Linkage: ¿Qué hacer cuando tienes registros diferentes que refieren a la misma persona?

¿Te ha pasado que tienes una base de datos donde una sola persona aparece registrada con diferentes identificadores únicos? ¿O que manejas varias bases que posiblemente tienen a las mismas personas, pero no estás seguro de cómo comprobarlo? ¿O tal vez los nombres están escritos de forma distinta —con o sin acentos, con errores tipográficos— y no sabes si realmente se trata del mismo registro? Y no solo ocurre con personas: también puede pasar con nombres de organizaciones, empresas, direcciones, consignatarios o clientes que aparecen duplicados o escritos de formas ligeramente diferentes en bases separadas o en la misma base. 

Estos escenarios son comunes cuando integramos información de distintas fuentes. El mismo individuo puede aparecer con un apellido abreviado, un nombre incompleto, una fecha en formato distinto o un identificador con dígitos faltantes. En este blog te voy a hablar de Record Linkage, un proceso que nos ayuda a identificar y vincular registros que representan la misma entidad, aunque los datos no coincidan de manera exacta.

¿Qué es Record Linkage? 

El Record Linkage —o vinculación de registros— es un conjunto de técnicas diseñadas para integrar información dispersa que proviene de diferentes fuentes. Su objetivo es identificar cuándo dos o más registros hacen referencia a la misma entidad, ya sea una persona, una empresa o cualquier otra unidad de análisis, incluso cuando existen pequeñas diferencias entre los campos. 

En muchas organizaciones, los datos sobre un mismo individuo pueden encontrarse repartidos en distintas fuentes: con nombres escritos de manera diferente, con identificadores incompletos o con información registrada de manera inconsistente. Record Linkage permite unir esas piezas y construir una visión más completa y coherente. Además, ayuda a detectar duplicados —deduplicación—, es decir, registros que refieren a la misma entidad, aunque aparezcan bajo variaciones distintas. 

Para aplicar Record Linkage de manera efectiva, es indispensable entender el contexto de los datos: cómo se recolectaron, qué transformaciones han sufrido y qué tan confiables son las variables que se utilizarán para vincular los registros. Este conocimiento contextual permite diseñar reglas de comparación adecuadas y evaluar de mejor manera los resultados. 

Consideraciones éticas, de protección de datos y de seguridad antes de continuar 

Record Linkage involucra trabajar con información sensible y, por tanto, requiere una gran responsabilidad ética y legal. Además de contar con acuerdos de confidencialidad y controles de seguridad robustos, es esencial garantizar privacidad, trazabilidad y transparencia, tanto en los procesos técnicos como en las decisiones derivadas de ellos. 

En muchos proyectos, los conjuntos de datos no incluyen nombres o direcciones para proteger la identidad de las personas. Sin embargo, esos campos suelen ser los más útiles para vincular registros entre bases. El desafío está en equilibrar la necesidad de identificar coincidencias con la obligación de preservar la privacidad. Existen estrategias para lograrlo, como recurrir a instituciones neutrales que realizan el linkage y devuelven únicamente resultados anonimizados, o emplear métodos criptográficos que permiten comparar identificadores sin exponerlos directamente (Tokle & Bender, 2021). 

En el Centro de Ciencia de Datos e IA, recientemente implementamos un proceso bajo ese principio: la comparación entre registros se llevó a cabo dentro de la organización propietaria de los datos, mientras que el Centro solo tuvo acceso a resultados intermedios —valores de similitud que no revelan información original—. Con esa base establecida, podemos pasar al lado práctico del proceso. 

Enfoques para Record Linkage 

No existe un único método para vincular registros. En la práctica, los enfoques se agrupan en tres grandes familias. 

El enfoque determinístico se basa en reglas y scores ponderados. Se definen manualmente las métricas de similitud, los pesos de cada atributo y los umbrales de decisión. Es transparente, interpretable y no requiere datos etiquetados. Su principal limitación es que depende del criterio del analista para calibrar parámetros y puede requerir iteración si los datos son ruidosos. 

El enfoque probabilístico parte del modelo de Fellegi y Sunter (1969), que calcula la probabilidad de que un par de registros sea una coincidencia real. Para cada atributo se estiman dos pesos: el m-weight (probabilidad de observar esa similitud si los registros sí coinciden) y el u-weight (probabilidad de observarla si no coinciden). Estos pesos suelen estimarse mediante Expectation-Maximization (EM) y producen un score probabilístico con fundamento estadístico explícito. Herramientas como Splink (MOJ Analytical Services) implementan este enfoque de forma escalable. 

El enfoque basado en machine learning aprende a clasificar pares como “match” o “no match” a partir de ejemplos etiquetados. Puede lograr alto desempeño, pero requiere un conjunto de entrenamiento cuidadosamente construido y mayor infraestructura computacional. 

La elección entre enfoques depende de la disponibilidad de etiquetas, los recursos computacionales y el nivel de interpretabilidad requerido. En el CCD implementamos un enfoque determinístico basado en scores ponderados, cuyo pipeline describimos a continuación. 

Pipeline de Record Linkage 

El flujo —o pipeline— que seguimos combina etapas estadísticas y lógicas que permiten identificar cuándo distintos registros se refieren a la misma entidad. En la Figura 1, se muestra el panorama general: el trabajo inicia con dos fuentes de información y pasa por bloqueo, cálculo de similitud, construcción de score, filtros, emparejamiento con grafos y validación. 

Image

Bloqueo 

Uno de los principales retos en Record Linkage es el costo computacional de comparar cada registro contra todos los demás. Si una base tiene n registros, el número de comparaciones posibles crece cuadráticamente (n²). En proyectos con miles o millones de observaciones, esto resulta costoso de procesar. 

Para hacer el proceso eficiente, aplicamos una técnica llamada bloqueo, que consiste en restringir las comparaciones únicamente a pares de registros que probablemente estén vinculados (Tokle & Bender, 2021). El bloqueo actúa como un filtro previo: reduce el espacio de búsqueda y permite concentrar el cómputo en candidatos plausibles. 

Existen distintas estrategias de bloqueo y su diseño depende del contexto. En nuestras implementaciones, por ejemplo, hemos utilizado reglas simples como agrupar por las primeras letras del nombre o por combinaciones de iniciales. Estas reglas son fáciles de implementar y, con buena normalización de texto, suelen capturar una proporción importante de coincidencias. 

Image

Este paso es crucial porque un bloqueo demasiado estricto puede omitir coincidencias reales, mientras que un bloqueo demasiado laxo puede aumentar innecesariamente el costo computacional. Cuando el volumen es muy grande o el ruido es alto, pueden emplearse estrategias más avanzadas (por ejemplo, variantes por vecindad ordenada o hashing aproximado), pero el principio central se mantiene: reducir comparaciones sin perder matches relevantes. 

Además, en proyectos reales suele ser útil aplicar bloqueo en más de una pasada. Por ejemplo, una primera pasada puede bloquear por inicial de apellido y otra por inicial de nombre; después se unen los candidatos de ambas pasadas. Este multi-pass blocking ayuda a recuperar coincidencias que se perderían si dependiéramos de una sola regla, especialmente cuando hay errores de captura o cuando las personas alternan entre usar un segundo apellido y omitirlo. La contraparte es que incrementa el número de comparaciones, por lo que conviene monitorear el tamaño de los bloques y, cuando sea necesario, introducir reglas de partición adicionales para mantener el costo computacional bajo control. 

Similitud 

Una vez que hemos reducido el número de comparaciones mediante el bloqueo, el siguiente paso es medir qué tan parecidos son los registros dentro de cada bloque. Esta etapa también suele conocerse como fuzzy matching: se usan métricas de coincidencia aproximada en lugar de exigir igualdad exacta. 

Antes de comparar, es necesario realizar un preprocesamiento: eliminar caracteres especiales, convertir a minúsculas, normalizar acentos y limpiar ruido. Después, para decidir si dos registros representan a la misma entidad, no solo se comparan los nombres: también pueden usarse CURP, RFC, edad, género, nacionalidad o dirección, según la disponibilidad y calidad. 

Entre las métricas de similitud de texto más comunes se encuentran la distancia de Levenshtein (ediciones necesarias para transformar una cadena en otra), los trigramas (comparación de secuencias de tres caracteres) y Jaro/Jaro–Winkler, útil para nombres por su tolerancia a transposiciones y peso a prefijos. Para variables numéricas como edad o fecha de nacimiento, se puede usar diferencia absoluta o tolerancias; para atributos categóricos, coincidencia exacta. 

El resultado de esta etapa es una tabla de comparaciones, donde cada fila representa un par de registros y cada columna muestra la similitud en algún atributo. 

Un punto que suele definir el desempeño del linkage es cómo tratamos valores faltantes y atributos inestables. Si un campo clave está vacío en uno de los registros, no necesariamente debemos penalizarlo igual que una discrepancia; muchas implementaciones separan explícitamente “missing” de “no match”. También conviene estandarizar representaciones antes de comparar: nombres compuestos, abreviaturas comunes, prefijos y formatos de fecha. Estas decisiones parecen menores, pero pueden mover muchos casos del rango “gris” hacia coincidencias claras o descartes más seguros. 

En la siguiente etapa, estas métricas se combinan para generar un score final. 

Score 

Una vez calculadas las métricas individuales, el siguiente paso es combinarlas para obtener una medida global de similitud entre dos registros: el score. El score resume la evidencia de que dos registros se refieren a la misma entidad, considerando varios atributos al mismo tiempo. 

Una forma práctica de construirlo es asignar pesos según la confiabilidad y capacidad discriminativa de cada atributo. Coincidencias fuertes en variables clave elevan el score; discrepancias en atributos relevantes lo reducen. El resultado es un valor continuo entre 0 y 1, flexible e interpretable, que permite ordenar y priorizar pares candidatos. 

Image

Filtro de scores 

Una vez calculado el score, el siguiente paso es depurar y seleccionar vínculos confiables. Un primer filtro consiste en definir un umbral mínimo (por ejemplo, 0.8) y conservar solo los pares que lo superan. Si el umbral se fija demasiado alto, se pierden coincidencias reales; si se fija demasiado bajo, aumentan falsos positivos. Por eso conviene ajustar el umbral con base en la distribución de scores y el contexto del proyecto. 

Incluso tras aplicar el umbral, un registro puede quedar vinculado con varios otros. Para priorizar las coincidencias más sólidas, se ordenan los vínculos de cada registro de mayor a menor score y se conserva solo un número pequeño de candidatos (por ejemplo, top-2). Con estos filtros se obtiene un conjunto de relaciones de alta confianza que puede representarse como un grafo. 

Emparejamiento 

Una vez que el grafo ha sido filtrado, llega el momento de agrupar registros que probablemente pertenecen a la misma entidad. Este paso se conoce como emparejamiento y busca identificar componentes conectados: grupos de nodos unidos directa o indirectamente por relaciones de alta similitud. 

En términos simples, si el registro A se vincula con B y B se vincula con C, el algoritmo puede concluir que A, B y C forman parte del mismo grupo, aunque A y C no estén conectados directamente. En el CCD hemos usado DSU (Union-Find) con compresión de caminos por su eficiencia; BFS y DFS son alternativas válidas en grafos moderados. 

Un riesgo importante es el cierre transitivo: cadenas de registros conectadas por eslabones débiles pueden terminar en el mismo grupo. Para mitigarlo, pueden aplicarse restricciones adicionales, como exigir que los pares dentro de un grupo superen un umbral mínimo, limitar el tamaño máximo de los grupos y revisar manualmente componentes inusualmente grandes (ver Figura 2). 

Image

Validación de resultados 

Una vez que se han formado los grupos vinculados, el paso final es validar que los enlaces sean correctos. Record Linkage nunca es perfecto: los datos suelen contener errores de captura, valores faltantes o formatos inconsistentes, por lo que siempre existe incertidumbre. Por esta razón, los resultados deben evaluarse desde distintos ángulos. 

Una estrategia común es la validación manual o cualitativa, especialmente en etapas tempranas. Esto puede implicar revisar ejemplos, inspeccionar casos ambiguos (scores cercanos al umbral) y detectar patrones de error. Esta revisión no solo sirve para aceptar o rechazar coincidencias, sino también para ajustar pesos, umbrales y estrategias de comparación. 

Cuando se cuenta con algunos datos etiquetados, también es posible una validación cuantitativa, calculando precisión, recall y F1-score. Cuando no existen etiquetas completas, una alternativa útil es seleccionar una muestra aleatoria de pares o grupos y revisarla manualmente. En la práctica, etiquetar entre 200 y 500 pares suele ofrecer estimaciones informativas sobre la calidad del proceso. En proyectos aplicados, la pregunta guía suele ser: ¿qué pasa si este enlace está mal? La respuesta define el rigor necesario. 

En contextos donde el enlace tiene implicaciones operativas o legales, es común incorporar una etapa de clerical review: un conjunto pequeño de casos seleccionados deliberadamente (por ejemplo, los scores cercanos al umbral o grupos grandes) se revisa por personal con conocimiento del dominio. Esta revisión puede usarse para ajustar umbrales y, si se desea evolucionar a un enfoque supervisado, para construir un conjunto inicial de entrenamiento. También es buena práctica documentar decisiones (pesos, umbrales y reglas de bloqueo) y fijar una versión del pipeline, de modo que el proceso sea reproducible y auditable. 

Conclusiones 

El Record Linkage es mucho más que un conjunto de técnicas para unir registros: es un proceso analítico, iterativo y contextual. Involucra decisiones técnicas —bloqueo, similitud, score, filtros y grafos—, pero también consideraciones éticas, legales y prácticas sobre el uso de los datos y las consecuencias de los resultados. 

A lo largo de este blog vimos que no existe una receta única ni un proceso perfecto. Cada proyecto requiere adaptar el pipeline al contexto: elegir atributos relevantes, definir estrategias de similitud, calibrar pesos y umbrales, y validar con el rigor apropiado. Si trabajas con datos que podrían beneficiarse de esta técnica, probablemente ya diste el primer paso: reconocer que el problema existe y que puede abordarse de manera controlada y reproducible.