El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
Una respuesta de geocodificación que devuelve una puntuación de confianza de 0.87 parece más rigurosa que una que solo devuelve si hay coincidencia o no. Tiene decimales. Da a entender que detrás hay un modelo calibrado con algo medible. A veces es exactamente eso. A menudo, el número se parece más a una heurística disfrazada con un formato que suena científico, y desde fuera es difícil distinguir una cosa de la otra.
El problema de una puntuación de confianza sin más es que responde a una pregunta que nadie formuló en esos términos. Un desarrollador que crea un formulario de direcciones no necesita una probabilidad entre cero y uno. Necesita saber algo más concreto: si se encontró el número de la calle o solo la calle. Si se encontró el código postal o solo la ciudad. Si es una coincidencia a nivel de edificio o un recurso al centroide de una zona más amplia. Un único número decimal reduce todo ese detalle útil y accionable a una cifra que parece precisa y te dice menos que una descripción sencilla.
Creemos que la versión honesta es describir lo que realmente coincidió, en términos sencillos, en lugar de comprimirlo en una puntuación que sugiere más certeza de la que el método subyacente puede respaldar. Esto importa todavía más porque la geocodificación directa e inversa es justo el tipo de función en la que exagerar la precisión causa daños reales más adelante. Una dirección que se resuelve en el lado equivocado de una ciudad porque una puntuación de confianza por encima de cierto umbral dejó pasar discretamente una mala coincidencia no es un error de redondeo. Es un envío mandado al lugar equivocado, o una comprobación de zona de servicio que incluye a un cliente que en realidad está fuera de ella.
No vamos a afirmar que nuestra geocodificación directa, nuestra geocodificación inversa o nuestro autocompletado ya gestionen cada patrón de dirección con una precisión verificada en todos los casos, porque esa afirmación sería exactamente el tipo de exageración que describimos aquí. Lo que sí podemos decir con claridad es qué hacen los endpoints y cómo están construidos, sin envolver la descripción en un número diseñado para que la confianza parezca mayor de lo que la realidad respalda.
Una puntuación de confianza no es deshonesta en sí misma. Bien usada, puede resumir de verdad algo real sobre una coincidencia, sobre todo cuando está documentada con la claridad suficiente para que un desarrollador vea a partir de qué se calcula realmente el número. El problema surge cuando la puntuación se convierte en toda la respuesta, presentada como prueba de precisión en lugar de mostrarse como una señal entre varias, sin explicar el método subyacente. Un número sin explicación no es más preciso que las palabras. Simplemente es más difícil de rebatir, que es algo completamente distinto.
La solución no es complicada, aunque quede menos favorecedora en una página de marketing. Describe lo que coincidió, en lenguaje sencillo, y deja que el desarrollador decida por sí mismo si ese nivel de detalle es suficiente para lo que está creando. Una coincidencia a nivel de calle descrita con claridad es más útil que una puntuación de 0.91 sin ninguna explicación detrás, porque el lenguaje sencillo te dice qué comprobar a continuación y un número sin más no.