Normalização Unicode em buscas com embeddings: acentos e caracteres visualmente semelhantes

Para tratar acentos em buscas com embeddings, padronize a representação Unicode antes de gerar os vetores e aplique a mesma política às consultas. Comece avaliando NFC, preserve o texto original e trate remoção de acentos e detecção de caracteres visualmente semelhantes como decisões separadas. Nenhuma dessas operações garante, sozinha, que a busca encontrará o documento certo.

O cuidado central é definir quais diferenças podem desaparecer sem alterar o significado que importa para seu negócio. Encontrar um cadastro digitado sem acento é diferente de declarar que dois cadastros pertencem à mesma pessoa. Uma chave tolerante para recuperação pode ajudar na primeira tarefa e ser inadequada para a segunda.

Resumo rápido

• NFC aproxima representações canonicamente equivalentes, sem remover acentos.
• NFKC também resolve equivalências de compatibilidade e exige avaliação do domínio.
• Accent folding e comparação de caracteres confundíveis têm objetivos próprios.
• Documentos e consultas precisam seguir a mesma política de transformação.
• Guarde originais, identificadores e versões para conseguir auditar e migrar.

O que muda entre NFC, NFKC, acentos e confundíveis

Unicode permite que um caractere percebido pelo leitor seja representado por sequências diferentes. Um exemplo é a letra é composta ou a sequência de e com acento combinante. A especificação Unicode Normalization Forms define equivalência canônica e formas de normalização. NFC decompõe canonicamente e recompõe quando isso é possível. Assim, representações canonicamente equivalentes convergem sem transformar café em cafe.

NFKC considera também equivalências de compatibilidade. Pode aproximar certas ligaturas e formas tipográficas de suas representações usuais. Isso é útil em alguns campos, mas pode apagar distinções relevantes em outros. Não adote NFKC globalmente apenas porque seu nome parece indicar uma limpeza mais completa. Defina primeiro o que aquele campo representa.

Accent folding é uma política de busca, não uma quinta forma Unicode. Case folding, que trata diferenças de caixa, também é uma transformação separada. Descrever todas como normalização impede saber qual etapa criou uma colisão. Dê nomes próprios às operações e registre sua ordem no processamento.

A FAQ oficial sobre normalização ajuda a distinguir equivalência canônica de compatibilidade. Use essas definições como fundamento; a escolha de campos, testes e tolerâncias apresentada aqui é uma recomendação de arquitetura, não uma obrigação imposta pelo padrão.

Por que o embedding não substitui uma política de entrada

Embedding é uma representação vetorial usada para comparar conteúdo. A introdução sobre embeddings em busca e recomendação explica essa base. Para seu sistema, entretanto, não presuma que entradas visualmente iguais terão vetores idênticos ou a mesma posição no ranking. Isso depende do modelo e do processamento efetivamente utilizado.

A recomendação é definir um contrato explícito de entrada: decodificação válida, política Unicode, tratamento de caixa, espaços e campos especiais. Se um documento passa por NFC antes da vetorização, a consulta deve passar por NFC antes de ser vetorizada também. Faça o mesmo para qualquer transformação adicional aprovada. Simetria significa aplicar a mesma regra, não concatenar campos diferentes ou remover informações de maneira indiscriminada.

Não confunda padronização textual com normalização matemática do vetor. Alterar o comprimento de um vetor ou sua métrica de distância não corrige caracteres. Esses procedimentos atuam em etapas diferentes e precisam ter testes separados. Da mesma forma, um índice vetorial bem configurado não recupera uma grafia que foi destruída no processamento de entrada.

Considere ainda o caminho lexical da busca híbrida. Se o índice de palavras usa uma chave sem acentos e o índice vetorial recebe o original em NFC, documente essa diferença intencional. Os dois caminhos não precisam usar exatamente o mesmo texto, mas cada caminho precisa manter coerência entre documentos e consultas. O guia sobre combinação de BM25 e busca vetorial complementa essa decisão.

Como preservar originais e separar campos de busca

Mantenha uma representação original para exibição e auditoria, uma representação canônica para o processamento definido e, se os testes justificarem, uma representação auxiliar tolerante. Relacione todas por um identificador estável do registro. Esse identificador deve continuar independente da grafia, inclusive quando o nome do cliente ou o título do documento mudar.

Em um cadastro de pessoas, por exemplo, o nome exibido permanece como foi validado no atendimento. A chave tolerante pode ajudar a localizar candidatos quando alguém digita Joao em vez de João. O aplicativo deve apresentar os candidatos e os campos de confirmação autorizados. A chave de busca não deve substituir uma regra de identificação nem autorizar a fusão automática de registros.

Há recursos documentados que podem compor essa solução. O filtro asciifolding do Elasticsearch oferece a opção preserve_original para emitir tokens originais e transformados. Isso descreve um comportamento do filtro lexical; não significa preservar automaticamente o documento completo nem modificar embeddings gerados em outro componente.

No PostgreSQL, a extensão unaccent utiliza regras de substituição para retirar diacríticos e pode expandir ligaturas conforme suas regras. Inspecione as regras e os exemplos relevantes para seu conjunto de dados. Não assuma que o resultado coincide com qualquer implementação caseira que simplesmente remove marcas combinantes.

Como desenho recomendado, registre também a versão da política de texto, o modelo de embedding e a origem do conteúdo. Em documentos divididos em trechos, mantenha a associação com o documento original e com a posição correspondente. Transformações podem mudar comprimentos; por isso, calcular destaques usando posições da cópia transformada pode selecionar caracteres errados no original.

Caracteres parecidos exigem um tratamento próprio

Uma letra latina pode se parecer com uma letra de outro sistema de escrita sem ser o mesmo caractere. NFC e NFKC não são mecanismos gerais para transformar qualquer caractere visualmente parecido em uma letra latina. A especificação Unicode Security Mechanisms trata confundíveis e descreve comparação por skeleton, uma representação usada nesse contexto de detecção.

A recomendação é usar um sinal de confundibilidade para inspeção ou busca de candidatos, sem substituir silenciosamente nomes, domínios, códigos ou identificadores. Um resultado parecido pode ser uma grafia legítima em outro idioma, uma entrada acidental ou uma tentativa de imitação. O sinal sozinho não permite concluir qual situação ocorreu.

Separe a recuperação de conteúdo da segurança de identidade. Um assistente pode sugerir uma página com nome semelhante, mas não deve afirmar que é a página oficial apenas por essa semelhança. Em um catálogo de fornecedores, preserve a grafia recebida, apresente a origem e confirme o identificador empresarial pelo fluxo autorizado antes de consolidar registros.

Evite bloquear qualquer texto que misture sistemas de escrita sem compreender seu público. Documentos multilíngues e marcas comerciais podem conter combinações legítimas. Defina campos que exigem regras restritas e campos que aceitam texto livre. Uma regra útil para um identificador interno não precisa ser aplicada ao corpo de um contrato ou à descrição de um produto.

Exemplo: distribuidora de peças em Curitiba

Considere uma distribuidora fictícia em Curitiba que pesquisa manuais e cadastros de fornecedores. Parte dos arquivos foi copiada de páginas web, parte veio de planilhas e parte foi extraída de PDFs. O caso é ilustrativo: não representa uma implantação nem apresenta ganhos medidos. O objetivo é mostrar decisões verificáveis antes de modificar a base.

A equipe começa separando nomes de pessoas, descrições de peças e códigos de fabricante. Para textos descritivos, testa NFC na entrada do índice e da consulta. Para nomes, acrescenta uma busca auxiliar sem acentos, mantendo a exibição original. Para códigos, preserva caracteres e consulta a especificação do fabricante antes de permitir equivalências de compatibilidade.

O teste contém João, José, Conceição, Luís e Luísa, além de variações sem diacríticos e representações decompostas. Também inclui registros diferentes com nomes semelhantes. O resultado esperado é definido por consulta: encontrar o documento correto entre candidatos não equivale a fundir pessoas. Casos com sobrenomes comuns exigem o mesmo cuidado que grafias menos frequentes.

Um nome de fornecedor com letra visualmente semelhante recebe sinalização para revisão. O sistema não altera o cadastro apenas porque uma chave auxiliar coincidiu. No atendimento, a tela mostra o nome original e a referência interna adequada. A decisão de confirmar um fornecedor segue o processo da empresa, sem delegar identidade à distância vetorial.

Como avaliar e migrar sem misturar políticas

Monte um conjunto de consultas com documentos relevantes rotulados por pessoas que conhecem a base. Inclua acentos ausentes, acentos combinantes, cedilha, maiúsculas, termos estrangeiros, nomes próprios e códigos que precisam permanecer distintos. Acrescente exemplos negativos: duas entradas que não podem ser tratadas como equivalentes, mesmo quando uma transformação aproxima suas grafias.

Compare a configuração atual com alternativas isoladas. Primeiro teste a representação canônica; depois avalie a chave tolerante; por último, experimente mudanças de compatibilidade em campos selecionados. Mudar várias operações simultaneamente dificulta explicar uma melhora ou uma regressão. Observe a posição dos resultados relevantes e as inclusões indevidas, não apenas a semelhança entre vetores.

Analise os resultados por tipo de consulta e por campo. Uma média geral pode esconder piora em nomes portugueses ou em termos técnicos pouco frequentes. Registre consultas em que um resultado correto desapareceu e consultas em que um candidato incorreto ganhou destaque. A revisão deve considerar tanto encontrar mais documentos relevantes quanto evitar confundir entidades.

Para migrar, reconstrua uma representação derivada a partir dos originais preservados e gere os vetores correspondentes ao novo contrato. Evite atualizar somente a consulta enquanto documentos antigos continuam na política anterior. Use um índice separado para comparar resultados e planeje uma troca reversível. A discussão sobre migração de embeddings e índices ajuda a organizar essa etapa.

Antes da troca, verifique se todos os registros esperados foram processados e se seus identificadores continuam associados às fontes corretas. Teste também a atualização de um registro já existente e a exclusão de outro. Esses cenários revelam referências antigas que uma consulta bem-sucedida isolada pode não mostrar. Defina como voltar à política anterior se surgirem colisões relevantes.

Erros comuns

Chamar remoção de acento de NFC. Isso produz documentação incorreta e testes insuficientes. Descreva exatamente a função aplicada. Usar o texto transformado como identificador. Uma colisão de busca não comprova identidade. Substituir originais. Sem eles, fica mais difícil explicar resultados ou aplicar uma política nova sem perda acumulada.

Aplicar NFKC a todos os campos. A escolha exige avaliação do domínio. Tratar caracteres parecidos como fraude comprovada. A sinalização exige contexto. Medir apenas consultas fáceis. Inclua distinções que precisam sobreviver. Normalizar somente na importação. Consultas, atualizações e reprocessamentos também precisam seguir o contrato definido.

Perguntas frequentes

NFC tira os acentos dos nomes?

Não. NFC uniformiza representações canonicamente equivalentes e preserva a distinção entre uma letra acentuada e uma letra sem acento. Uma busca que aproxima João de Joao precisa de uma política adicional, avaliada conforme o campo.

NFKC é sempre melhor para embeddings?

Não existe essa garantia. A forma de compatibilidade pode ser conveniente para determinados textos e inadequada para códigos ou notações. Compare resultados em consultas reais e mantenha a decisão registrada por campo, junto da política de processamento.

Posso usar a chave sem acento para deduplicar clientes?

Use-a, no máximo, como sinal para encontrar candidatos à revisão. A identificação precisa considerar os critérios autorizados do cadastro. Grafias que convergem após uma transformação não demonstram que os registros representam a mesma pessoa.

É preciso gerar os embeddings novamente?

Se o texto enviado ao modelo mudou, os vetores existentes não representam essa nova entrada. Planeje sua regeneração e a comparação em índice separado. Alterações restritas ao caminho lexical devem ser avaliadas conforme a arquitetura efetivamente usada.

Fontes e leitura recomendada

• Unicode: formas de normalização, definições normativas.
• Unicode: perguntas sobre normalização, distinções conceituais.
• Unicode: mecanismos de segurança, confundíveis.
• Elastic: filtro asciifolding, configuração lexical.
• PostgreSQL: unaccent, regras de substituição.