Por que assistentes de IA alucinam endereços (e como dados geo verificados resolvem)

TL;DR: Assistentes de IA inventam endereços plausíveis, porém errados, com taxas que vão de 6 % para hotéis de rede a 38 % para aluguéis de temporada independentes. A solução não é corrigir o modelo. 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.

Auditoria amostral: taxas de alucinação por tipo de consulta

Rodamos 500 consultas de localização por três assistentes de IA líderes em abril de 2026. Cada consulta pedia o endereço de um estabelecimento específico. As respostas foram comparadas com o endereço verificado do local, registrado no MapAtlas GeoEnrich.

A tabela abaixo mostra a parcela das respostas com pelo menos um erro material no endereço (rua errada, número errado, CEP errado ou cidade errada). Os números são direcionais e específicos desta amostra.

Tipo de consulta	ChatGPT	Perplexity	Gemini
Hotel de rede	6%	4%	7%
Hotel boutique independente	19%	14%	22%
Aluguel de temporada	38%	29%	41%
Restaurante independente	24%	18%	27%
Ponto turístico ou atração	9%	5%	8%

Fonte: auditoria amostral da MapAtlas, abril de 2026, n=500 consultas.

Dois padrões saltam aos olhos. Primeiro, a taxa de alucinação escala com o quão esparsa e inconsistente é a pegada web do estabelecimento. Aluguéis de temporada, que muitas vezes existem em uma única plataforma de listing sem site próprio independente, sofrem mais. Segundo, Perplexity consistentemente alucina menos, provavelmente porque sua camada de retrieval ancora mais respostas em fontes ao vivo em vez de memória paramétrica.

Um exemplo prático

Uma consulta feita em abril de 2026: "Qual é o endereço da pousada Casa do Vale, no Porto?"

Resposta alucinada de um assistente líder:

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

Resposta verificada pelos registros da própria propriedade e pelo MapAtlas Geocoding:

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 nas auditorias que fizemos:

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?

Em uma auditoria amostral da MapAtlas conduzida em abril de 2026, sobre 500 consultas de localização abrangendo hotéis, aluguéis de temporada, restaurantes e pontos turísticos, as taxas de alucinação no nível do endereço variaram de aproximadamente 6% para redes hoteleiras bem conhecidas a 38% para aluguéis de temporada independentes. Consultas sobre pontos turísticos genéricos tiveram o melhor desempenho; consultas long-tail de listing, o pior. A taxa é direcional e varia conforme o modelo, o idioma e a atualidade dos dados subjacentes, mas o padrão é consistente: quanto menos dado estruturado um local expõe, mais o modelo inventa.

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.