Endereços alucinados por IA: por que surgem e como dados geo corrigem

TL;DR: Assistentes de IA inventam endereços plausíveis, porém errados, e estabelecimentos independentes com presença web escassa e inconsistente são os mais afetados. A solução: publique uma ground truth inequívoca com marcação Schema.org Place, coordenadas verificadas e um identificador externo canônico, e mantenha essa verdade consistente em cada plataforma onde o negócio aparece.

Pergunte ao ChatGPT o endereço de um hotel três estrelas no Porto e ele provavelmente vai responder com nome de rua, número e CEP. A resposta soará confiante. Para as grandes redes, costuma estar correta. Para o boutique independente a duas ruas dali, há uma probabilidade relevante de a resposta estar errada.

Não é um edge case raro. É um output previsível de como modelos de linguagem geram texto, e tem consequências diretas para qualquer negócio que dependa de ser encontrado em uma localização específica.

A mecânica de uma alucinação de localização

Um modelo de linguagem não armazena um banco de endereços. Ele armazena uma distribuição estatística sobre tokens. Quando recebe a pergunta pelo endereço, ele prevê uma sequência de tokens que se pareça com um endereço para aquele tipo de estabelecimento, naquela cidade.

Se o dado de treino continha o endereço real muitas vezes, de forma consistente e em fontes autoritativas, a previsão converge para a string correta. Se o endereço aparecia pouco, de forma inconsistente ou simplesmente não aparecia, o modelo interpola. Escolhe uma rua que soa adequada para o bairro, um número que cabe no quarteirão, um CEP que bate com o padrão local.

O output é gramaticalmente válido, geograficamente plausível e, muitas vezes, completamente errado.

O risco é maior para estabelecimentos com presença web esparsa ou inconsistente. Um aluguel de temporada que existe em uma única plataforma de reservas dá ao modelo muito menos pontos de ancoragem do que um hotel de rede listado com o mesmo endereço em centenas de fontes.

Um exemplo prático

Uma consulta ilustrativa, com nome e endereço da propriedade inventados: "Qual é o endereço da pousada Casa do Vale, no Porto?"

Uma resposta alucinada típica:

A Casa do Vale fica na Rua de Santa Catarina 142, 4000-442 Porto, Portugal.

O endereço correto neste exemplo:

Casa do Vale, Rua do Vale 38, 4200-512 Porto, Portugal.

Rua errada, CEP errado, lado oposto da cidade. A resposta alucinada joga o hóspede em uma zona comercial a três quilômetros da pousada real. O erro não é aleatório. A Rua de Santa Catarina é a rua comercial mais famosa do Porto e aparece muito nos dados de treino para consultas sobre hospedagem na cidade. O modelo caiu no prior estatístico mais forte associado ao Porto.

Por que dados estruturados mudam o resultado

Uma página de listing com um bloco JSON-LD de Place ou LodgingBusiness bem formado dá ao modelo algo a extrair, em vez de inventar.

{
  "@context": "https://schema.org",
  "@type": "LodgingBusiness",
  "name": "Casa do Vale",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Rua do Vale 38",
    "postalCode": "4200-512",
    "addressLocality": "Porto",
    "addressCountry": "PT"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 41.1621,
    "longitude": -8.5937
  },
  "identifier": {
    "@type": "PropertyValue",
    "propertyID": "wikidata",
    "value": "Q00000000"
  }
}

Três características desse bloco importam para reduzir alucinação:

Campos estruturados. O modelo não precisa parsear uma frase. Rua, CEP, cidade e país são chaves separadas.
Coordenadas que batem com o endereço. Um crawler consegue verificar se a latitude e a longitude caem dentro do polígono do CEP. Quando não batem, o dado é marcado como baixa confiança.
Um identificador externo estável. Wikidata ou um Place ID do Google ligam o listing a uma entidade canônica. O modelo pode reconciliar o endereço contra uma fonte autoritativa em vez de depender da frequência no dado de treino.

Quando as três condições se sustentam, extração substitui geração. A probabilidade de uma resposta alucinada cai drasticamente.

A camada de consistência NAP

Schema na página do listing é necessário, mas não suficiente. Sistemas de IA cruzam o endereço contra outras fontes públicas: Google Business Profile, OpenStreetMap, Yelp, Tripadvisor, plataformas de reserva e a web aberta. Quando essas fontes divergem, a confiança cai e o modelo fica mais propenso a hedge ou a gerar.

Por isso a consistência de Name, Address, Phone (NAP) entre plataformas é um preditor de citação mais forte do que qualquer sinal isolado. Um listing com schema impecável, mas com endereço conflitante no Google Business Profile, ainda vai performar mal. Veja consistência NAP para AI search para a mecânica.

O que costuma reduzir o risco de alucinação

Quatro medidas são as que mais mexem o ponteiro:

1. Publique coordenadas verificadas junto do endereço. Endereço escrito é uma string. Coordenadas são um fato verificável. O Geocoding da MapAtlas converte endereços brutos em latitude e longitude precisas em escala e sinaliza entradas que não resolvem de forma limpa.

2. Envolva os fatos de localização em JSON-LD. Os tipos Place, LodgingBusiness, Hotel, Restaurant e LocalBusiness aceitam campos address, geo e identifier. Campos ausentes são exatamente onde o modelo começa a chutar.

3. Reconcilie com um identificador canônico. Ligue o listing a um QID de Wikidata ou a um Place ID do Google. Isso dá aos sistemas de IA uma chave primária para deduplicar.

4. Enriqueça com contexto próximo. Alucinações não se limitam ao campo de endereço. Os modelos também inventam pontos próximos, paradas de transporte e tempos a pé. Dados de proximidade verificados, gerados pelo GeoEnrich da MapAtlas, ancoram também essas afirmações. FAQs específicas de localização são uma superfície eficaz para expor esse dado.

O custo de negócio de um endereço alucinado

Um endereço errado apresentado por um assistente de IA não só expõe o modelo. Ele manda um hóspede real ao lugar errado. Os efeitos em cadeia se acumulam:

Uma reserva cancelada ou, pior, um no-show.
Uma review negativa que menciona a localização errada, que vira dado de treino para a próxima geração de modelos.
Queda de confiança de citação para o listing daqui para a frente, porque a web pública agora contém sinais contraditórios.

A assimetria importa. Um endereço alucinado prejudica o listing mesmo quando o listing em si é inocente. A solução não é corrigir o modelo diretamente, o que não é possível, e sim deixar o ground truth inequívoco o suficiente para que o modelo não tenha razão para gerar em primeiro lugar.

Como checar sua própria exposição

O AEO Checker da MapAtlas, gratuito, avalia um listing contra 29 sinais estruturados, incluindo schema de endereço, presença de coordenadas, consistência NAP e identificadores externos. Listings que passam nessas verificações têm probabilidade materialmente menor de serem mal representados em respostas de IA. Listings que falham são justamente aqueles em que o modelo precisa chutar.

Alucinações de localização não são uma esquisitice de um assistente específico. São uma consequência previsível do treinamento em uma web aberta onde o mesmo negócio aparece com endereços ligeiramente diferentes em dezenas de fontes. A solução é publicar um ground truth em formato que sistemas de IA consigam extrair, e manter esse ground truth consistente em todos os demais lugares onde o negócio é representado.

Leitura relacionada:

Perguntas frequentes

O que é uma alucinação de endereço em IA?

Uma alucinação de endereço em IA acontece quando um modelo de linguagem retorna uma rua, um CEP ou uma coordenada específica que parece plausível, mas não corresponde à localização real do negócio, ponto turístico ou propriedade descrita. Não é um erro de arredondamento. O modelo sintetizou um endereço que não existe, pertence a outro local ou combina uma rua real com a cidade errada. Para listings isso é especialmente prejudicial: o usuário pode se deslocar até o lugar errado antes de perceber que a resposta foi fabricada.

Por que assistentes de IA alucinam endereços?

Modelos de linguagem geram texto prevendo o próximo token mais provável, não consultando fatos em um banco de dados. Quando um endereço está sub-representado, é inconsistente pela web ou está bloqueado ao rastreamento, o modelo preenche a lacuna com uma string estatisticamente plausível: um nome de rua que soa correto para a cidade, um padrão de CEP que bate com a região, um número que parece típico. Sem uma fonte estruturada de ground truth para ancorar a resposta, o modelo não tem como distinguir um fato memorizado de um gerado.

Com que frequência alucinações de localização acontecem na prática?

Não existe uma taxa única e confiável. Ela varia conforme o modelo, o idioma, o tipo de consulta e a atualidade dos dados subjacentes. O padrão, porém, é consistente: quanto menos dado estruturado e consistente um local expõe, mais o modelo inventa. Redes hoteleiras e grandes pontos turísticos, que aparecem com o mesmo endereço em muitas fontes de referência, costumam receber uma resposta correta. Anúncios de cauda longa, como aluguéis de temporada independentes, hotéis boutique e restaurantes pequenos, se saem pior, porque o modelo encontra pouco dado verificado para extrair e preenche as lacunas por conta própria.

Dados estruturados de Schema.org reduzem alucinações?

Sim, desde que os dados estejam verificados e consistentes entre as fontes. Publicar um bloco JSON-LD do tipo Place ou LodgingBusiness com coordenadas geo precisas, um endereço postal validado e referências cruzadas a identificadores autoritativos como Wikidata ou Place ID do Google dá ao modelo uma âncora de ground truth que ele pode extrair e citar. Schema inconsistente, por exemplo coordenadas que não batem com o endereço escrito, tende a reduzir a confiança em vez de aumentar.

Como audito meus listings em relação ao risco de alucinação?

Rode a URL do listing no AEO Checker gratuito da MapAtlas em mapatlas.eu/ai-seo-checker. O checker avalia 29 sinais estruturados que sistemas de IA usam para ancorar fatos de localização, incluindo coordenadas geo, schema de Place, consistência NAP entre plataformas e presença de campos de contexto próximo. Páginas sem esses sinais pontuam alto em risco de alucinação, porque o modelo precisa adivinhar em vez de extrair.