Parser de direcciones en 2026: tokenización, ambigüedad y alternativas

El parseo recupera la estructura que estaba presente en el texto: el código postal, el código de región, la ciudad y la línea de calle, en ese orden de fiabilidad. No puede recuperar información que nunca se escribió. Una cadena sin designador de unidad no contiene un número de unidad, y ninguna cantidad de inferencia debería inventarlo.

Tampoco puede confirmar que los campos sean verdaderos. Parsear "123 Main St, Springfield, IL 62701" produce campos coherentes, y la dirección puede seguir siendo ficticia o la ciudad puede no coincidir con el ZIP. El parseo es una operación de texto. La verificación es una operación de datos, y ambas nunca deberían compartir un nombre de función ni un mensaje de éxito.

La primera etapa es la normalización: recortar, colapsar espacios internos, reemplazar espacios de no separación, normalizar variantes de puntuación y decidir si se pasa a mayúsculas. Mantén el original intacto para la alternativa. La segunda etapa es la segmentación: dividir por comas cuando existan; de lo contrario, dividir según la gramática del país. La tercera etapa es la clasificación: etiquetar cada segmento como postal, región, ciudad, calle o unidad usando el conjunto de reglas del país. La cuarta etapa es la asignación: mapear etiquetas a campos, resolver conflictos y puntuar el resultado.

Mantener las etapas separadas hace que los modos de fallo sean separables. Un error de segmentación se ve distinto de un error de clasificación, y cada etapa se puede probar unitariamente con su propio corpus. También te permite detenerte antes: si el país es desconocido, omite la clasificación por completo y devuelve los segmentos con la confianza por campo marcada como desconocida.

El orden de los campos es la mayor fuente de parseos incorrectos, porque los mismos tokens se mueven de lugar. Estados Unidos, Canadá, el Reino Unido y Australia colocan el código postal después de la ciudad. Alemania, Francia, los Países Bajos y Bélgica lo colocan antes de la ciudad. Japón lo coloca primero, antes de la prefectura. Brasil coloca el código postal después del estado con un separador.

Por eso el parser debe conocer el país antes de clasificar nada. Inferir el país a partir de la propia cadena es circular: el patrón postal puede sugerir uno, pero muchos patrones se solapan. Pide el país desde el formulario, la configuración regional o un selector explícito, y marca el parseo como de baja confianza cuando falte, en lugar de adivinarlo a partir de un token de dos letras que podría ser un estado o un país.

Los designadores de unidad secundaria son la ambigüedad más común. "Apt", "Ste", "Unit", "Fl" y "Rm" son fiables cuando van seguidos de un identificador, pero "Unit 5" también puede ser el nombre de una calle, y "Building 3" puede ser la dirección principal de un campus. Un parser debería extraer una unidad solo cuando el designador va seguido de un número o un token alfanumérico corto y aparece después del número de calle.

Los sufijos de calle son la segunda trampa. Un token como "Way", "Court" o "Park" puede ser un sufijo, un nombre de calle o una ciudad. Los direccionales tienen el mismo problema: "N" puede ser un predireccional, una abreviatura de nombre de calle o una región. Usa la posición relativa al número de casa y la estructura de comas, y cuando dos lecturas sean ambas plausibles, conserva el segmento original y baja la confianza en lugar de elegir.

Puntúa cada campo y luego el registro. Un campo tiene alta confianza cuando coincidió con un patrón anclado del país y su posición concordó con el orden esperado. Tiene confianza media cuando el patrón coincidió pero la posición se infirió, y baja cuando se asignó por eliminación. Un registro solo tiene alta confianza cuando todos los campos obligatorios son de alta confianza y no hay segmentos sin ubicar.

Establece un umbral y hazlo cumplir. Por encima del umbral, acepta y almacena. Por debajo, conserva la cadena original y marca el registro para revisión en lugar de escribir una suposición en las columnas estructuradas. Expón la puntuación y los motivos en la respuesta de la API, porque el revisor necesita saber qué campo falló, no solo que algo falló.

Un resultado de parseo debería tener resultados explícitos, no un booleano. País faltante significa que la gramática no puede ejecutarse. Código postal faltante importa en países que lo tienen y es normal en Hong Kong y los EAU. Un segmento no ubicable significa que la estructura de comas y la gramática no concuerdan, y el registro necesita ojos humanos.

Asigna a cada resultado un código estable para que los llamadores puedan ramificar sin analizar texto libre. Devuelve la entrada normalizada, la entrada original, los valores de los campos con su confianza y la lista de segmentos sin ubicar. Ese payload permite que una interfaz resalte el token exacto que falló en lugar de mostrar un error genérico en la parte superior del formulario.

Empieza con un corpus pequeño verificado a mano, de una a tres direcciones por país, cada una con los valores de campo esperados escritos por alguien que lee el correo de ese país. De veinte a cuarenta casos es suficiente para detectar regresiones estructurales y lo bastante pequeño para revisarlo en una pull request. Guárdalo como datos, no como aserciones enterradas en el código de prueba.

Luego muta cada caso mecánicamente: quita comas, cambia mayúsculas y minúsculas, colapsa espacios dobles, inserta un espacio de no separación, intercambia dos líneas, abrevia un sufijo y añade una unidad. La salida esperada de una mutación no siempre es idéntica, pero debería mantenerse dentro de una tolerancia definida, y la confianza debería bajar en lugar de que los campos cambien en silencio. Registra la precisión y la exhaustividad por campo para que una corrección de ciudad no rompa el postal sin que se note.

No parsees notas de forma libre, instrucciones de entrega ni nada que un humano haya escrito como prosa. "Leave at the side gate, second house after the blue one" no tiene campos, y extraer tokens de ahí produce basura con mucha confianza. Guárdalo como un bloque de texto adjunto al pedido.

No parsees escrituras que tu conjunto de reglas no cubra. Una dirección japonesa en kanji necesita una gramática japonesa; ejecutar un tokenizador de escritura latina sobre ella dividirá en los límites equivocados y perderá la prefectura. No parsees direcciones que no tengan número de calle o que usen un nombre de edificio como localizador principal, lo cual es común en partes de Asia y en direcciones de campus. En todos estos casos, la salida correcta es la cadena original más un estado claro de "no parseado".