Duas pessoas com o mesmo nome na base de clientes parece um detalhe cadastral até o dia em que o assistente de IA envia o histórico de compras de uma pessoa para outra. O mesmo vale para empresas com razão social parecida, para e-mails institucionais que repetem endereço e para transcrições de reunião em que dois “Fernandos” falam na mesma hora. Desambiguar entidades é uma etapa obrigatória antes de dar autonomia a qualquer agente.
Este guia trata de homônimos como entidades de sistema, não como assunto de gramática. Você vai ver por que a confusão acontece, quais sinais usar para separar registros, como montar um conjunto de teste com casos homônimos e onde entra a exigência de confirmação humana.
Resumo rápido
- O modelo trabalha com texto, não com identidade. Se dois registros têm o mesmo nome e o prompt não traz outro sinal, a confusão é esperada.
- Nunca use nome sozinho como chave de busca. Sempre acompanhe de um identificador estável.
- Os melhores sinais são os que não se repetem: documento, e-mail completo, matrícula, número de contrato.
- Teste com um conjunto próprio de homônimos antes de liberar o agente. Sem esse teste, você descobre o erro em produção.
- Quando a entidade estiver ambígua, o comportamento correto é perguntar, não escolher a mais provável.
- Tratar dado pessoal na checagem exige finalidade definida e base legal, mesmo quando a finalidade é só desambiguar.
Por que a confusão acontece
Um modelo de linguagem não tem tabela de entidades. Ele recebe uma sequência de tokens e prevê a continuação. O nome completo de uma pessoa é tokenizado em pedaços, e “Ana Paula Souza” e “Ana Paula de Souza” podem compartilhar quase todos os pedaços. Do ponto de vista do modelo, os dois são praticamente o mesmo texto.
Some a isso a busca por similaridade. Um sistema de recuperação que usa vetor semântico devolve o registro mais parecido com a consulta, e o mais parecido costuma ser justamente o homônimo. A armadilha é sutil: o resultado parece correto, porque o nome bate.
Os sinais que separam registros
A qualidade da desambiguação depende de usar o sinal certo. A tabela abaixo ordena os sinais do mais forte para o mais fraco.
| Sinal | Força para desambiguar | Cuidado |
|---|---|---|
| Identificador interno (matrícula, contrato) | Muito alta, é único por construção | Não é conhecido pelo usuário final, exige mapeamento |
| CPF ou CNPJ | Alta, mas exige cuidado de privacidade | Dado pessoal sensível ao tratamento; não deve ir ao modelo sem necessidade |
| E-mail completo | Alta quando é único | E-mails institucionais podem ser compartilhados por setor |
| Telefone com DDD | Média, bom quando a base é pequena | Pode mudar de dono com o tempo |
| Data de nascimento ou fundação | Média | Combina bem com nome, sozinha repete |
| Cargo e unidade | Média | Muda com promoção e mudança de área |
| Cidade e endereço | Baixa a média | Muito repetitivo em bairro grande |
| Nome completo | Baixa | É o ponto de partida da confusão |
A regra de ouro: nome é filtro de busca, nunca chave de decisão. Use o nome para trazer candidatos e o identificador para escolher entre eles.
Tratamento na entrada, antes do modelo
A solução mais barata é impedir que a ambiguidade chegue ao modelo. Se a consulta do usuário traz só um nome, o sistema deve retornar a lista de candidatos e pedir o desempate com um segundo dado. Quando traz o e-mail, o sistema resolve sozinho.
Isso é engenharia de fluxo, não de prompt. Um prompt que manda o modelo “não confundir homônimos” falha porque o modelo continua sem saber qual registro é o certo.
Tratamento no prompt, quando necessário
Quando precisar enviar candidatos ao modelo, mande a lista com os identificadores e instrua explicitamente: se mais de um candidato corresponder, não escolha, devolva a pergunta. Isso reduz muito a taxa de escolha arbitrária, embora não elimine o problema. A proteção de verdade está na validação posterior, não na instrução.
Montando um teste com casos homônimos
Antes de liberar o agente, monte um conjunto de casos que reproduza a sua realidade. Ele não precisa de centenas de itens para começar. Precisa cobrir os padrões de confusão que existem na sua base.
Um conjunto inicial bem montado cobre:
- nome idêntico com dois registros reais;
- nome com partícula diferente, do tipo “de” e “da”;
- nome com acento e sem acento;
- nome com sobrenome abreviado;
- empresas com a mesma razão social em cidades diferentes;
- empresas com razão social parecida e mesmo sócio;
- e-mail institucional repetido em duas unidades;
- transcrição de áudio em que o nome foi grafado errado pelo reconhecimento de fala.
Para cada caso, escreva a resposta correta esperada. O resultado do teste divide-se em três desfechos: acertou, perguntou e errou. O desfecho “perguntou” é considerado aceitável em caso ambíguo, e isso muda a leitura do resultado. Um agente que nunca pergunta tem resultado pior do que um que pergunta nos casos realmente duvidosos.
O que medir
Evite tratar o teste como um único percentual. Separe dois números: taxa de escolha errada em caso ambíguo, que é o erro grave, e taxa de pergunta desnecessária em caso trivial, que é atrito de uso. A primeira precisa ser próxima de zero. A segunda pode existir em alguma medida.
Quando exigir confirmação humana
Alguma desambiguação não deve ser automatizada em nenhum cenário. Trate como obrigatória a confirmação humana quando a ação tiver consequência difícil de desfazer.
| Situação | Automatizar | Exigir humano |
|---|---|---|
| Responder uma dúvida de status a um cliente identificado por e-mail único | Sim | Não |
| Enviar histórico de compras quando o nome tem dois candidatos | Não | Sim |
| Emitir documento fiscal para empresa com razão social parecida | Não | Sim |
| Atualizar endereço de entrega de um cadastro | Não | Sim |
| Recusar atendimento por inadimplência | Não | Sim |
| Gerar resumo interno de reunião com dois participantes de mesmo nome | Sim, com marcação de dúvida | Só se o resumo tiver efeito formal |
A marcação de dúvida é um recurso simples e subestimado. O agente escreve “há dois participantes com este nome, atribuição incerta” em vez de escolher. O leitor humano resolve em cinco segundos, e o erro não se propaga.
Privacidade: desambiguar também trata dado pessoal
Checar CPF para separar dois homônimos é tratamento de dado pessoal. A Lei 13.709 de 2018, a LGPD, exige finalidade específica, necessidade e segurança. Na prática isso significa algumas decisões de arquitetura.
Primeiro, não mande documento completo ao modelo quando o sistema pode comparar localmente. Uma função determinística resolve o casamento de identificador sem expor o número ao provedor de IA.
Segundo, registre por que o dado foi usado. A finalidade aqui é evitar erro de atribuição, e ela precisa estar descrita na política de tratamento da empresa.
Terceiro, limite quem vê o resultado. O atendente que precisa saber “são duas pessoas diferentes” não precisa ver o CPF de nenhuma delas.
Exemplo: operadora de saúde em Recife
Uma operadora de plano de saúde em Recife tinha dois beneficiários homônimos com nome idêntico e mesma faixa de idade. O assistente de atendimento começou a responder consultas de um usando dados do outro, porque a busca por nome retornava um único resultado depois da deduplicação automática.
A correção não foi trocar o modelo. Foi mudar o fluxo. A busca passou a exigir dois campos, com o número do cartão ou o CPF confirmado por um passo adicional, e o agente deixou de receber pergunta quando havia mais de um candidato. Antes de liberar a nova versão, a equipe montou um conjunto com os homônimos reais da base e mais casos artificiais de partícula e acento.
O primeiro resultado medido foi o fim do envio de dado de um beneficiário para outro. O ganho de tempo no atendimento veio depois, e varia conforme o volume. Este exemplo descreve desenho de processo e não traz número de resultado.
Erros comuns
Confiar em “busque o cliente Fulano”
Instrução genérica não resolve ambiguidade. O modelo não tem como saber qual dos dois é o certo, e tende a escolher o primeiro resultado.
Deduplicar automaticamente por nome
Fusão de cadastros por similaridade de nome é a origem de muitos erros permanentes. Deduplicar exige identificador ou revisão humana, nunca heurística de texto isolada.
Espelhar CPF no prompt sem necessidade
Aumenta exposição e não melhora o resultado, porque a comparação já poderia ocorrer no sistema. Use o mínimo de dado necessário.
Testar só com casos fáceis
Um conjunto sem homônimos reais mede o que já funciona. O valor do teste está nos casos que quebram.
Tratar “perguntou” como falha
Quando o caso é ambíguo, perguntar é o comportamento correto. Punir o agente por perguntar empurra o sistema para a escolha arbitrária.
Perguntas frequentes
Um modelo maior resolve homônimos sozinho?
Melhora a interpretação, mas não cria informação que não existe. Se dois registros têm o mesmo nome e nada os distingue no texto, nenhum modelo escolhe com segurança.
Posso usar apenas data de nascimento para desempatar?
Como sinal combinado com o nome, funciona. Isolada, não, porque data também se repete. A combinação de nome com um identificador é o caminho confiável.
Como lidar com homônimos em transcrição de reunião?
Peça que o agente marque a dúvida em vez de atribuir fala. Na ata, indique “falante 1” quando não houver certeza, e deixe a atribuição para quem participou.
Isso se aplica a empresas com razão social parecida?
Sim, e o risco é maior porque a semelhança costuma ser intencional no mercado. Use CNPJ e identificador interno, e exija confirmação antes de emitir documento fiscal ou cobrança.
Qual é o mínimo de teste antes de liberar?
Não existe número universal. Cubra os padrões de confusão que existem na sua base e valide com quem conhece os cadastros. Se o conjunto não reproduz a realidade, ele mede pouco.
O agente pode pedir desculpas e seguir adiante?
Quando a ação já foi tomada, sim, com correção imediata do registro errado. O problema é que dados enviados a terceiros não voltam. Por isso a confirmação vem antes, não depois.
Fontes e leitura recomendada
- Lei 13.709 de 2018: Lei Geral de Proteção de Dados Pessoais
- ANPD: Autoridade Nacional de Proteção de Dados
- OpenAI: guia oficial de engenharia de prompts
- Anthropic: visão geral de engenharia de prompts
- Google: estratégias de prompt do Gemini API
Para aprofundar a escrita de instruções, veja o guia de engenharia de prompts avançada. Se o assunto é dar autonomia ao agente, comece por o que são agentes autônomos de IA e pelo guia de Model Context Protocol.
