Geocodificación vs. búsqueda de lugares

Geocodificación vs. búsqueda de lugares es la primera separación en una consulta de ubicación: una llamada resuelve un objeto geográfico y la otra descubre lugares candidatos. Una dirección, una coordenada o un identificador de lugar pertenecen a la geocodificación. Una solicitud de empresas, puntos de referencia u otros lugares con nombre pertenece a la búsqueda de lugares. Después, una consulta espacial prueba la geometría que la aplicación ya posee, y la búsqueda vectorial compara significado sin demostrar que un registro esté cerca o sea elegible.

¿Qué responde cada consulta de ubicación?

Cada método responde una pregunta distinta, y que el menú de un proveedor los agrupe en una misma familia de productos no elimina la diferencia. La geocodificación resuelve identidad. La búsqueda de lugares descubre candidatos en el índice de un proveedor o en un índice privado. Una consulta espacial aplica una relación geométrica a registros que la aplicación ya almacena. La búsqueda vectorial recupera registros cuyos embeddings son cercanos en significado. Una decisión de producción suele necesitar más de una de esas respuestas, en un orden que determina la propia pregunta.

Las cuatro tarjetas separan resolver, descubrir, filtrar por geografía y comparar significado. Cada tarjeta empareja una entrada con una salida: una dirección con una coordenada, una categoría con puntos de interés, una relación geométrica con registros coincidentes y un concepto con vecinos semánticos. La dirección postal, la coordenada, la consulta de cafetería y el número de lugares dentro del polígono son etiquetas de ejemplo en la figura. Esas etiquetas no proceden de una consulta en vivo contra un índice de Kaleidr.

La tabla es la regla de selección. Un equipo que empiece por el nombre del endpoint, en lugar de por la pregunta, pedirá a un geocodificador una recomendación o a un índice vectorial una prueba de contención. Ambos errores producen una respuesta segura a una pregunta que el sistema nunca ejecutó. El resto de esta guía mantiene separados los cuatro trabajos y después muestra dónde debe unirlos una canalización.

¿Qué consulta encaja con la pregunta?

Las primeras palabras de la solicitud suelen indicar el método. «¿Dónde está esta dirección?» empieza con geocodificación. «¿Qué lugares coinciden con este texto o categoría?» empieza con búsqueda de lugares. «¿Cuáles de nuestros registros satisfacen esta relación geográfica?» empieza con una consulta espacial. «¿Qué registros significan algo parecido a esto?» es el caso de la búsqueda vectorial, y solo después de fijar los límites geográficos y empresariales estrictos. Una solicitud que mezcle esas preguntas necesita un enfoque híbrido, no un único ganador.

El árbol empieza con la pregunta que el solicitante intenta responder y luego se ramifica hacia resolver una dirección, descubrir empresas, filtrar por geografía los registros propios del solicitante o encontrar registros con significado similar. Una quinta franja inferior combina los cuatro métodos cuando una sola consulta no basta. La dirección de ejemplo, las tarjetas de cafetería, el radio de un kilómetro y la frase entre comillas sobre una cita son etiquetas de la figura. Las marcas de verificación describen el trabajo de cada método, no una puntuación de calidad medida.

Un enfoque híbrido es el caso normal para un asistente de mapas con IA, no una excepción reservada para una versión posterior. «Café cerca de 20 W 34th St» sigue necesitando resolver la dirección antes de ejecutar una búsqueda cercana. «Una cafetería tranquila cerca del hotel, abierta después de las nueve» añade un filtro empresarial y una preferencia semántica sobre esa resolución. Las secciones de la canalización que siguen mantienen esos pasos en un orden que un revisor puede probar.

¿Qué resuelve la geocodificación?

La geocodificación convierte una ubicación textual en una representación geográfica, y la geocodificación inversa convierte una coordenada o un identificador de lugar de vuelta en una dirección legible. La descripción general de Geocoding API de Google define el servicio como uno que acepta una dirección, latitud y longitud o un Place ID, y convierte una dirección en coordenadas y un Place ID, o convierte coordenadas o un Place ID en una dirección (Google, 2026). La misma página usa «1600 Amphitheatre Parkway, Mountain View, CA» como ejemplo de geocodificación directa y menciona entregas y recogidas entre los usos de la geocodificación inversa. La salida de una llamada correcta es un objeto que el mapa puede ubicar, no un conjunto clasificado de empresas.

La frontera del producto está cambiando, pero sigue siendo importante nombrar el trabajo de recuperación. La descripción general de Geocoding API v4 de Google enumera geocodificación directa, geocodificación inversa, geocodificación de lugares y un método de búsqueda de destinos que acepta una dirección, un Place ID o coordenadas (Google, 2026). También separa canales generalmente disponibles, preview y experimentales, e indica a quienes llaman que usen el canal experimental para funciones de destino que no están en la ruta generalmente disponible. Una consulta de destino puede enriquecer una ubicación que la aplicación ya resolvió. Una consulta de destino no se convierte en un índice de descubrimiento de lugares, y un canal experimental no promete que todos los campos estén listos para un contrato de producción.

La geocodificación es la herramienta correcta cuando la aplicación debe representar una dirección, normalizarla antes de almacenarla, centrar un mapa, hacer geocodificación inversa de la ubicación de un dispositivo o resolver un punto de entrega antes de una consulta posterior. La geocodificación no elige el mejor restaurante cercano, no lee inventario privado, no prueba un polígono privado de área de servicio ni clasifica resultados por intención del cliente. Esos trabajos empiezan solo después de que exista un objeto. Trazar lugares en un mapa cubre el paso de dirección a marcador que sigue a una resolución correcta.

¿En qué difiere la geocodificación vs. búsqueda de lugares?

La búsqueda de lugares descubre entidades geográficas con nombre: restaurantes, tiendas, estaciones, puntos de referencia y otros puntos de interés. Mapbox marca explícitamente la línea de producto en la Geocoding API actual. Esa API realiza geocodificación directa e inversa, y Geocoding v6 API ya no proporciona datos de puntos de interés (Mapbox, 2026). Mapbox dirige la búsqueda de puntos de interés a Search Box API, que admite consultas interactivas e independientes de direcciones, lugares y puntos de interés, incluida la búsqueda por categoría (Mapbox, 2026). La familia de endpoints pertenece a un proveedor. Los trabajos siguen siendo dos.

La Places API actual de Google hace la misma separación dentro de la propia búsqueda de lugares. Text Search (New) devuelve lugares para una cadena de texto y los ejemplos documentados incluyen «shoe stores near Ottawa» y «123 Main Street», por lo que una cadena con forma de dirección puede entrar en una llamada de búsqueda de lugares (Google, 2026). Nearby Search (New) recibe uno o más tipos de lugar y devuelve lugares coincidentes dentro de un área especificada (Google, 2026). Por ello, Text Search puede parecer geocodificación cuando la cadena es una dirección, y Nearby Search puede parecer una consulta espacial cuando el área es un círculo. El resultado sigue siendo un conjunto de candidatos del índice de ese proveedor. El estado de apertura, el inventario, la autorización y el tiempo de viaje siguen siendo pruebas posteriores. La misma página de Text Search también dice que el servicio no está pensado para consultas ambiguas, incluidas formas de direcciones postales que no están representadas como lugares.

El panel izquierdo pregunta dónde está una dirección y muestra una única identidad de ubicación. La dirección y la coordenada de ese panel coinciden con el ejemplo de la referencia de geocodificación directa de Kaleidr, y los nombres de cafeterías, distancias y valoraciones con estrellas de la derecha son etiquetas de ejemplo, no una respuesta de búsqueda de lugares en vivo. El pie recorre «coffee near 20 W 34th St» geocodificando la dirección y después buscando café. La conclusión de la derecha denomina al resultado conjunto de candidatos, que es el punto correcto para detenerse antes de la elegibilidad y el ranking.

Una aplicación robusta usa ambas cuando el ancla es una dirección y el objetivo es una categoría. Geocodifica «20 W 34th St», busca después café cerca del punto resuelto, calcula luego el tiempo a pie y clasifica solo los lugares que sigan siendo elegibles. Un mapa de lugares cercanos es la superficie de descubrimiento para ese segundo paso. El orden del proveedor es una comodidad de recuperación. El orden del producto es una decisión posterior.

¿Qué prueba una consulta espacial?

Una consulta espacial filtra registros que la aplicación ya posee mediante una relación entre geometrías. Las relaciones habituales incluyen dentro de una distancia, dentro de un polígono, interseca, contiene y vecino más cercano. Los registros y su geometría existen antes de la consulta. La consulta pregunta cuáles de esos registros satisfacen la relación. Una API de búsqueda de lugares responde otra pregunta porque el conjunto de candidatos procede del índice del proveedor y no de la tabla del solicitante.

Los paneles muestran dentro de una distancia, dentro de un polígono, una ruta que interseca una zona y la entidad más cercana. El radio de un kilómetro, el contorno del área de servicio y la etiqueta de distancia son geometría de ejemplo, no un área de servicio medida. El panel de más cercano también marca una entidad como excluida. Esa exclusión es un ejemplo de una comprobación de elegibilidad posterior. El predicado de distancia por sí solo no prueba si un lugar está abierto.

PostGIS define ST_DWithin como una prueba de si dos geometrías están dentro de una distancia dada, y la llamada incluye una comparación de bounding box que usa cualquier índice espacial disponible en las geometrías (PostGIS, 2026). Para el tipo geography, la distancia se expresa en metros. Por tanto, una tabla de tiendas con una columna geography puede mantener «dentro de cinco kilómetros» como predicado en lugar de como frase que deba interpretar un modelo de lenguaje.

SELECT store_id, name
FROM stores
WHERE ST_DWithin(stores.geog, user_location, 5000);

La contención pertenece a la misma clase de predicado. ST_Within devuelve true cuando cada punto de la primera geometría se encuentra en la segunda y los interiores comparten un punto, y la función también usa los índices espaciales disponibles (PostGIS, 2026). ST_Within(A, B) es el inverso de ST_Contains(B, A). Una pregunta de entrega como «¿esta dirección está dentro del área de servicio?» consiste en geocodificar, después hacer una prueba de contención y después aplicar la regla operativa. Un índice vectorial no sustituye al polígono, y una búsqueda pública de lugares no sustituye a la geometría del área de servicio que dibujó la empresa.

La nota sobre el índice es una restricción de arquitectura, no una nota menor de tuning. Una expresión de distancia que no pueda usar un índice comparará muchas más filas que ST_DWithin en la misma tabla. La regla práctica para un asistente sensible a la ubicación es filtrar geográficamente antes de que cualquier modelo vea el conjunto. Si solo una pequeña parte de un catálogo grande puede satisfacer la geometría, el modelo de lenguaje debería recibir esa parte junto con la razón por la que se descartaron las demás. Enviar el resto consume contexto en registros que el predicado ya excluyó.

¿Qué compara la búsqueda vectorial?

La búsqueda vectorial recupera registros cuyos embeddings están cerca de la consulta en un espacio vectorial. pgvector, la extensión de Postgres usada habitualmente para ese trabajo, realiza búsqueda exacta de vecinos más cercanos de forma predeterminada y puede añadir un índice HNSW o IVFFlat para búsqueda aproximada (pgvector, 2026). La misma documentación enumera distancia L2, producto interno, distancia coseno y otras medidas. La búsqueda exacta es la referencia base de recall. Un índice aproximado intercambia parte de ese recall por velocidad, y las consultas pueden devolver vecinos distintos después de crear el índice. Esa propiedad importa cuando un equipo compara un prototipo que usaba búsqueda exacta con una consulta de producción que usa el índice.

La búsqueda vectorial merece su coste cuando las palabras de la solicitud no son las palabras del registro. Una descripción que dice «vinoteca íntima con luz tenue» puede ser un vecino útil de «lugar tranquilo para una primera reunión», aunque las cadenas no coincidan. Las descripciones de lugares, notas de servicios y textos de destino son entradas habituales cuando la licencia permite convertir el texto en embeddings. Una marca conocida, un número de tienda, un código de aeropuerto o una categoría explícita suelen ser mejor trabajo para búsqueda por palabras clave o estructurada. Los embeddings añaden un sistema que operar y deberían incorporarse cuando la pérdida semántica sea real.

La similitud vectorial no registra distancia geográfica, tiempo de ruta, contención en un área de servicio, inventario actual, horario, autorización ni si el texto embebido sigue siendo verdadero. Un vecino cercano en el espacio de embeddings puede estar a cientos de kilómetros del solicitante. Un lugar al otro lado de la calle puede ser una coincidencia semántica pobre y aun así ser la respuesta operativa correcta. Los dos resultados no están en conflicto. Proceden de espacios distintos y la canalización debe decir qué espacio puede rechazar un candidato.

¿Por qué son distintas la distancia geográfica y la distancia vectorial?

Ambos sistemas usan la palabra distancia, y esa palabra oculta un cambio de objeto. La distancia geográfica es separación sobre la Tierra o a lo largo de un recorrido: longitud en línea recta, caminata, trayecto en coche o resultado de contención. La distancia vectorial es separación en un espacio de embeddings: distancia coseno, distancia euclidiana o una puntuación de producto interno. Una distancia vectorial pequeña no coloca dos lugares cerca geográficamente. Una caminata corta no hace que dos descripciones signifiquen lo mismo.

El panel izquierdo mide separación física y muestra una caminata de ejemplo entre dos lugares etiquetados. Las etiquetas de kilómetros y minutos son ejemplos, no un trayecto calculado. El panel derecho coloca palabras en un diagrama de embeddings y marca coffee como distante en significado de train. Esa indicación de coseno ilustra los dos espacios y no es un embedding medido de un índice de Kaleidr. La etiqueta central resume el punto de la figura: la misma palabra, distancia, nombra ambas cantidades.

La colisión de nombres aparece en el texto del producto. Una pantalla que diga «más cercano» puede significar más cercano en el índice de embeddings, más cercano en metros en línea recta o el que añade menos minutos de desvío. Esos tres órdenes difieren con suficiente frecuencia como para que la interfaz deba nombrar la cantidad. Un ranker puede usar más de una. No debería sumar una puntuación coseno a un valor en kilómetros y tratar la suma como una única distancia.

¿Cómo debería ordenar el trabajo una canalización híbrida?

Una búsqueda de ubicación en producción suele ser una canalización porque la solicitud mezcla un objeto, una categoría, un límite geográfico, una regla empresarial y una preferencia. Un orden viable es interpretar la solicitud, resolver el ancla, recuperar candidatos, aplicar el filtro espacial, aplicar la elegibilidad empresarial y después usar similitud semántica solo dentro del conjunto elegible. El routing y otros enriquecimientos se ejecutan sobre los supervivientes. El ranking ordena esos supervivientes. La explicación y la acción del mapa usan los mismos identificadores que usaron los filtros. Ingeniería de contexto espacial es la pregunta complementaria sobre qué parte de esa canalización puede llegar al modelo de lenguaje.

Las etapas están etiquetadas con el método propietario de cada una: geocodificación, búsqueda de lugares, una consulta espacial, datos empresariales y búsqueda vectorial, seguidos de enriquecimiento, ranking y acción en el mapa. Los nombres de lugares, valoraciones con estrellas, barras de puntuación, el embudo «100K+» y la afirmación «top 3–5» son etiquetas ilustrativas. La figura es un esquema de referencia del orden del trabajo, no un benchmark de Kaleidr ni un formato de solicitud. La columna de filtros empresariales muestra reglas de ejemplo como abierto ahora y una valoración mínima, que pertenecen a los datos del host y no al índice público de lugares.

El orden cambia el recall. Buscar primero en todo el índice de embeddings y después probar la geografía sobre una lista semántica corta puede perder un lugar local válido que nunca entró en esa lista corta. Restringir primero el conjunto de candidatos con la geografía estricta y las reglas empresariales estrictas, y luego clasificar por significado dentro de ese conjunto, mantiene la frontera. Cuando la base de datos puede aplicar ambos filtros en una sola consulta, se mantiene el mismo principio: la similitud semántica no puede borrar un límite geográfico obligatorio.

Las notas de filtrado de pgvector son la advertencia práctica. Con un índice aproximado, el filtro se aplica después del escaneo del índice y el ejemplo de la documentación usa una condición que coincide con el 10 por ciento de las filas bajo el ef_search predeterminado de HNSW de 40, lo que deja unas cuatro filas de media. Los escaneos iterativos del índice, que la documentación introduce para esta insuficiencia, continúan hasta que quedan suficientes filas. Un equipo debería probar el recall filtrado con datos realistas en lugar de asumir que la consulta elegante es la consulta de producción.

¿Por qué deben ejecutarse los filtros estrictos antes de la similitud?

La recuperación pregunta qué candidatos pueden entrar en consideración. El ranking pregunta en qué orden deben aparecer los candidatos válidos. Mezclar ambos permite que un lugar cerrado, no autorizado o sin stock gane porque es conveniente o semánticamente cercano. La guía de ranking de lugares de Kaleidr mantiene autorización, disponibilidad, capacidad requerida y área de servicio como filtros antes de puntuar, en lugar de como penalizaciones débiles (Kaleidr, 2026). Una penalización puede perder frente a un término de conveniencia grande. Un filtro no.

La columna izquierda enumera cuatro puertas booleanas y termina eliminando candidatos no válidos. La columna derecha muestra puntuaciones de similitud de ejemplo para tranquilo, apto para familias y apto para trabajar, y clasifica solo los lugares que pasaron. Las fotografías y las tres puntuaciones son etiquetas de ejemplo, no valoraciones medidas ni una puntuación de Kaleidr. La flecha muestra el orden: elegibilidad, después similitud.

Las puertas estrictas siguen siendo booleanas. Autorizado, en stock, abierto a la llegada y dentro del área de servicio son condiciones, no pesos. Las señales semánticas pueden seguir siendo puntuaciones y se aplican a los lugares que conservaron las puertas. La misma separación cubre una regla obligatoria de accesibilidad o un límite de tenant. Un hecho obligatorio que sea desconocido debe seguir siendo desconocido. Tratar una consulta no disponible como false convierte una lectura de inventario ausente en un seguro «sin stock», que es un error diferente y peor.

¿Por qué buscar «de camino» no es buscar por radio?

«Cerca de mí» y «de camino a casa» describen geometrías diferentes. Un radio alrededor del origen devuelve lugares a una distancia del punto de partida, incluidos lugares en la dirección equivocada. Una consulta de corredor de ruta devuelve lugares que añaden poco desvío a un viaje que el servicio de routing ya ha planificado. La distancia en línea recta es un filtro legítimo cuando la pregunta es realmente radial. Es la cantidad incorrecta cuando la decisión depende del trayecto. Dos kilómetros en línea recta pueden ser un viaje largo en coche, y una distancia en línea recta mayor puede corresponder al viaje más corto.

El panel izquierdo es un radio simple y muestra farmacias de ejemplo dentro y fuera de un anillo de una milla. El panel derecho sigue una ruta de ejemplo del trabajo a casa y etiqueta farmacias con minutos de desvío. Los valores en millas, los minutos de desvío y los nombres de lugares son etiquetas de ejemplo, no una ruta en vivo. El punto de la figura es la relación: un desvío bajo de la ruta no es el mismo predicado que un círculo alrededor del origen.

El servicio de routing debería calcular el desvío y el ranker debería recibir ese resultado. Un modelo de lenguaje que estime los minutos a veces contradirá la ruta que el servicio acaba de devolver. La llamada de ruta pertenece después de la resolución y después de la selección de candidatos. La llamada de ruta no es una búsqueda de lugares, y una ruta inexistente debe seguir siendo un fallo visible en lugar de una línea inventada en el mapa.

¿Dónde encaja Kaleidr en esta canalización?

La Platform API pública de Kaleidr expone un endpoint de geocodificación directa creado para un cuadro de búsqueda o un campo From/To, no para un índice empresarial privado. GET /retrieval/geocode/forward acepta q como nombre de lugar, una dirección postal con número o una latitud y longitud escritas, además de near_lat y near_lng opcionales usados juntos, limit y un mode de viaje (Kaleidr, 2026). La misma referencia documenta una ruta entre coordenadas que el solicitante ya posee, con perfiles de conducción, caminata, ciclismo y transporte público, y una ruta que no puede planificarse vuelve con un estado HTTP correcto y un error en el cuerpo en lugar de una trayectoria. Los resultados incluyen atribución que el solicitante debe transmitir, y un resultado de dirección postal puede incluir un identificador que permanece estable entre actualizaciones de datos. Una lista results vacía significa que no hay nada que mostrar, incluido el caso de un fallo interno de consulta, por lo que una lista vacía no demuestra que la dirección sea inválida.

Los parámetros documentados no incluyen el catálogo privado de un cliente. La geocodificación pública no se convierte en un sistema de inventario por estar montada en el mismo mapa. Un solicitante que necesite tiendas privadas o inventario debe leer directamente esos sistemas y después unirlos a un lugar resuelto mediante un identificador estable. La respuesta de geocodificación es el objeto público y el registro empresarial sigue siendo el registro empresarial.

El detalle de lugar tiene un sucesor actual y la ruta antigua no debería ser donde se base una nueva integración. La referencia de endpoints marca GET /retrieval/poi/enrich como obsoleto y dirige el trabajo nuevo a POST /spot, que responde qué hay en un punto y puede añadir contenido descriptivo y fotos. La ruta obsoleta puede retirarse después de 2027-01-15.

El enriquecimiento sigue sin decidir la elegibilidad privada. Horarios, fotos y una categoría de una fuente pública son hechos públicos, con la atribución que esa fuente exige. El stock, el permiso de cuenta y un área de servicio dibujada por el cliente permanecen en los sistemas que los poseen. Spatial AI fundamentada para datos empresariales es la guía para esa frontera.

La columna izquierda separa direcciones y lugares con nombre de tiendas privadas, inventario y áreas de servicio. La columna central nombra la geocodificación directa de Kaleidr, un paso de detalle de lugar y la propia base de datos espacial y los sistemas empresariales del host. El cuadro de detalle de lugar es el trabajo ahora documentado como POST /spot. El endpoint antiguo de enrich es el predecesor obsoleto, no la integración con la que empezar. La columna derecha muestra lo que ocurre después de la recuperación: una ruta entre coordenadas conocidas, un ranking de lugares elegibles, una explicación y una acción en el mapa. La advertencia de la figura coincide con la referencia de endpoints. Una API pública de geocodificación o lugares no indexa las ubicaciones privadas, el inventario ni las áreas de servicio del solicitante.

Los datos específicos de la organización siguen el límite del plan, no el mapa. La documentación de cuenta de Kaleidr dice que cargar los propios datos empresariales de una organización para respuestas de IA es exclusivo de Enterprise, y que el scope de clave que permite que las respuestas usen esos datos cargados también es exclusivo de Enterprise (Kaleidr, 2026). La referencia pública actual de endpoints no documenta un endpoint de búsqueda vectorial de propósito general. Un equipo que necesite recuperación semántica sobre sus propias descripciones debería tratar ese índice como parte del diseño del host o de Enterprise, y confirmar el contrato actual en lugar de llamar a una ruta que este artículo no cita. Cómo crear un asistente de IA consciente del mapa cubre las acciones del mapa que siguen a un identificador de lugar validado.

¿Qué debería medir un equipo por separado?

Cada capa falla a su manera y una única puntuación de relevancia ocultará qué capa falló. La geocodificación falla con una dirección ambigua, una unidad ausente, una coordenada invertida o una coincidencia solo a nivel de calle. La búsqueda de lugares falla cuando la cobertura, categoría o frescura del proveedor no encaja con el producto. Una consulta espacial falla con geometría inválida, una referencia de coordenadas que no coincide o un polígono que ya no corresponde a la operación.

La búsqueda vectorial falla con un embedding débil, texto obsoleto o un índice aproximado que devuelve demasiado poco después de un filtro. Los datos empresariales fallan cuando el inventario es desconocido, el registro no está autorizado o los horarios están obsoletos. Un registro útil nombra la capa. «Search failed» no lo hace.

Evalúa la capa según su trabajo y después evalúa la decisión. La geocodificación necesita calidad de coincidencia e identificadores estables. La búsqueda de lugares necesita recall de candidatos, precisión de categoría y una tasa de lugares obsoletos. Las consultas espaciales necesitan corrección geométrica y evidencia de que la consulta usó el índice. La búsqueda vectorial necesita relevancia semántica y recall filtrado frente a una línea base de búsqueda exacta. La comprobación de extremo a extremo pregunta si se recuperó un lugar elegible, si «sin resultados» fue el resultado honesto y si la acción usó el identificador que aprobaron los filtros. Un fallo de autorización o de contención no debería desaparecer dentro de una tasa media de clics.

¿Dónde debería empezar el stack?

Elige el método que pueda demostrar la cláusula que pidió el usuario. La geocodificación demuestra dónde está un objeto. La búsqueda de lugares demuestra qué lugares conocidos coinciden con un texto, categoría o área de ese índice. Una consulta espacial demuestra una relación geométrica sobre registros que posee la aplicación. La búsqueda vectorial demuestra similitud de significado, y solo dentro del conjunto que conservaron los filtros estrictos. Los sistemas empresariales demuestran el hecho actual. Un servicio de routing demuestra el trayecto. Un ranker ordena lo que queda. El modelo de lenguaje explica ese resultado y no debería ser la fuente de la distancia, la prueba de contención ni el recuento de inventario.

Los datos públicos de lugares son la fuente adecuada cuando el trabajo es el descubrimiento público. Las tiendas privadas, el inventario y la elegibilidad permanecen en los sistemas que los poseen, con identificadores estables que unen el lugar del proveedor, la ubicación de inventario y el marcador del mapa. La similitud semántica no borra una frontera geográfica y un radio no responde una pregunta «de camino». Explora Kaleidr Enterprise cuando la recuperación deba ejecutarse sobre datos específicos de la organización y lee los endpoints de Platform API para los contratos de geocodificación directa, spot y ruta citados anteriormente.

Nota: Kaleidr utiliza herramientas asistidas por IA para la creación de imágenes, el refinamiento de contenidos y la investigación en sus flujos creativos y de desarrollo.

Preguntas frecuentes

¿Cuál es la diferencia entre geocodificación y búsqueda de lugares?

La geocodificación resuelve una dirección, una coordenada o una referencia de lugar conocida en una identidad geográfica. La búsqueda de lugares descubre empresas, puntos de referencia, estaciones y otros lugares con nombre que coinciden con texto, una categoría o un área cercana. Una devuelve un objeto. La otra devuelve candidatos.

¿La búsqueda de puntos de interés es lo mismo que la geocodificación?

No. Algunas APIs de proveedores pueden aceptar tanto una dirección como una consulta de lugar. Por contraste, la Geocoding v6 API de Mapbox ya no proporciona datos de puntos de interés en absoluto. La búsqueda de puntos de interés descubre candidatos. La geocodificación resuelve una ubicación.

¿Qué es una consulta espacial?

Una consulta espacial filtra registros geográficos por una relación geométrica como dentro de una distancia, dentro de un polígono, interseca o vecino más cercano. Los registros y su geometría ya pertenecen a la aplicación. El predicado es determinista.

¿Qué es la búsqueda vectorial?

La búsqueda vectorial recupera registros cuyos embeddings están cerca del embedding de consulta. El método es útil para significado y para formulaciones que no coinciden con el texto fuente. No demuestra distancia, contención ni elegibilidad.

¿Puede la búsqueda vectorial sustituir a una consulta espacial?

No. La similitud en un espacio de embeddings no demuestra distancia geográfica, contención, ajuste de ruta ni pertenencia a un área de servicio. Usa un predicado espacial para la verdad geográfica y búsqueda vectorial para relevancia semántica dentro del conjunto que ese predicado permite.

¿Debe la geografía filtrar el conjunto antes de la búsqueda vectorial?

Sí, cuando la geografía es un límite estricto. Buscar en un índice global de embeddings y después comprobar la ubicación en una lista corta puede descartar lugares locales válidos que nunca entraron en esa lista. La base de datos y el índice deciden la implementación. El límite no cambia.

¿Debe un equipo geocodificar antes de una búsqueda cercana?

Sí, cuando el ancla es una dirección u otra ubicación no resuelta. Resuelve el ancla y luego ejecuta recuperación de lugares o una consulta espacial alrededor del punto resuelto. Una búsqueda por categoría sin ancla ya es una pregunta de búsqueda de lugares.

¿Debería un producto usar una Places API o su propia base de datos?

Usa una Places API para descubrimiento público cuando la cobertura, la licencia y la atribución encajen con el producto. Usa la base de datos propia del producto para tiendas de primera parte, inventario, instalaciones privadas, elegibilidad y estado empresarial actual. Un registro público de lugar puede identificar una tienda. No debería ser la autoridad sobre lo que esa tienda tiene hoy.

¿Qué es la búsqueda híbrida de ubicaciones?

La búsqueda híbrida de ubicaciones combina dos o más de estos métodos para una decisión. Una cadena típica resuelve un ancla, recupera candidatos de lugares, aplica un predicado espacial y una regla empresarial y después clasifica cualquier preferencia semántica dentro del conjunto elegible. El modelo de lenguaje explica los supervivientes.

¿Documenta Kaleidr un endpoint público de búsqueda vectorial?

La referencia de endpoints de Platform API citada aquí no documenta un endpoint de búsqueda vectorial de propósito general. Las superficies de recuperación documentadas usadas en este artículo son geocodificación directa, POST /spot para saber qué hay en un punto y la llamada de ruta entre coordenadas ya disponibles. Confirma el contrato actual de Enterprise antes de incorporar un índice semántico al plan de producto.

References

1. Google Maps Platform. Geocoding API overview. The service accepts an address, coordinates, or a Place ID, and converts an address into coordinates and a Place ID, or coordinates or a Place ID into an address. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/overview
2. Google Maps Platform. Geocoding API v4 overview. Documents forward geocoding, reverse geocoding, place geocoding, and destination search, and separates generally available, preview, and experimental channels. Accessed October 27, 2026. https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview
3. Mapbox. Geocoding API. Forward and reverse geocoding. The Geocoding v6 API no longer provides point-of-interest data and directs that job to the Search Box API. Accessed October 27, 2026. https://docs.mapbox.com/api/search/geocoding/
4. Mapbox. Search Box API. Interactive and stand-alone search for addresses, places, and points of interest, including category search. Accessed October 27, 2026. https://docs.mapbox.com/api/search/search-box/
5. Google Maps Platform. Text Search (New). Returns places for a text string. Documented examples include "shoe stores near Ottawa" and "123 Main Street." Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/text-search
6. Google Maps Platform. Nearby Search (New). Takes one or more place types and returns matching places within a specified area. Accessed October 27, 2026. https://developers.google.com/maps/documentation/places/web-service/nearby-search
7. PostGIS. ST_DWithin. Tests whether two geometries are within a given distance. The call includes a bounding-box comparison that uses available spatial indexes. Geography distance is in meters. Accessed October 27, 2026. https://postgis.net/docs/ST_DWithin.html
8. PostGIS. ST_Within. Tests whether every point of one geometry lies in another and the interiors share a point. The function uses available spatial indexes. Accessed October 27, 2026. https://postgis.net/docs/ST_Within.html
9. pgvector. pgvector. Exact and approximate nearest-neighbor search in Postgres, including HNSW and IVFFlat indexes, cosine and other distances, and iterative scans when a filter leaves too few approximate results. Accessed October 27, 2026. https://github.com/pgvector/pgvector
10. Kaleidr Developer Docs. Platform API endpoints. Documents forward geocoding for a search box or From/To field, POST /spot as the successor to the deprecated POI enrich endpoint, and a route call between known coordinates. Accessed October 27, 2026. https://docs.kaleidr.com/platform-api/endpoints
11. Kaleidr. Place Ranking API for Customer Intent. Hard filters such as authorization, availability, required capability, and service area run before scoring. Accessed October 27, 2026. https://kaleidr.com/blog/place-ranking-api
12. Kaleidr Developer Docs. How Kaleidr works. Uploading an organization's own business data for AI answers is Enterprise only, as is the key scope that lets answers draw on that data. Accessed October 27, 2026. https://docs.kaleidr.com/concepts/how-kaleidr-works
13. Kaleidr. Plot Places on a Map. A related guide for turning resolved places into markers. Accessed October 27, 2026. https://kaleidr.com/blog/plot-places-on-a-map
14. Kaleidr. How to Build a Nearby Places Map for Near Me Search. A related guide for nearby discovery. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-nearby-places-map-for-near-me-search
15. Kaleidr. Spatial Context Engineering for Map-Aware AI. A related guide for what reaches the model after retrieval. Accessed October 27, 2026. https://kaleidr.com/blog/spatial-context-engineering
16. Kaleidr. Grounded Spatial AI for Business Data. A related guide for keeping business facts in the systems that own them. Accessed October 27, 2026. https://kaleidr.com/blog/grounded-spatial-ai-business-data
17. Kaleidr. Map-Aware AI Assistant: How to Build One. A related guide for map actions around a validated place. Accessed October 27, 2026. https://kaleidr.com/blog/how-to-build-a-map-aware-ai-assistant

References in BibTeX

@misc{google_geocoding_overview_2026,
  title  = {Geocoding API overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/overview}
}

@misc{google_geocoding_v4_overview_2026,
  title  = {Geocoding API v4 overview},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/geocoding/geocoding-v4-overview}
}

@misc{mapbox_geocoding_api_2026,
  title  = {Geocoding API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/geocoding/}
}

@misc{mapbox_search_box_api_2026,
  title  = {Search Box API},
  author = {{Mapbox}},
  year   = {2026},
  url    = {https://docs.mapbox.com/api/search/search-box/}
}

@misc{google_places_text_search_2026,
  title  = {Text Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/text-search}
}

@misc{google_places_nearby_search_2026,
  title  = {Nearby Search (New)},
  author = {{Google Maps Platform}},
  year   = {2026},
  url    = {https://developers.google.com/maps/documentation/places/web-service/nearby-search}
}

@misc{postgis_st_dwithin_2026,
  title  = {ST_DWithin},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_DWithin.html}
}

@misc{postgis_st_within_2026,
  title  = {ST_Within},
  author = {{PostGIS}},
  year   = {2026},
  url    = {https://postgis.net/docs/ST_Within.html}
}

@misc{pgvector_2026,
  title  = {pgvector},
  author = {{pgvector}},
  year   = {2026},
  url    = {https://github.com/pgvector/pgvector}
}

@misc{kaleidr_platform_api_endpoints_2026,
  title  = {Platform API endpoints},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/platform-api/endpoints}
}

@misc{kaleidr_place_ranking_api_2026,
  title  = {Place Ranking API for Customer Intent},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://kaleidr.com/blog/place-ranking-api}
}

@misc{kaleidr_how_kaleidr_works_2026,
  title  = {How Kaleidr works},
  author = {{Kaleidr}},
  year   = {2026},
  url    = {https://docs.kaleidr.com/concepts/how-kaleidr-works}
}