O Que É Uma Palavra Polissêmica

Polissemia e a dor real da tradução automática

Hoje pela manhã revisei uma tradução técnica onde a palavra "banco" apareceu de forma inconsistente. O tradutor automático havia usado "banco" em três momentos e "assento" em outros dois dentro do mesmo parágrafo. O cliente final ficou confuso. Isso acontece porque o sistema não entendeu o contexto -- e é exatamente esse problema que a polissemia provoca em escala. Uma palavra polissêmica é aquela que possui mais de um significado relacionado entre si. A diferença crucial em relação à homonímia é que os sentidos compartilham uma origem comum. "Banco" como instituição financeira e "banco" como assento vêm de uma raiz etimológica ligada ao conceito de "barril" ou "monte" -- originalmente se referia a um bloco de madeira, que era usado tanto como assento quanto como cofre de valores. É essa conexão semântica que separa polissemia de homonímia pura. Outro exemplo comum: "chave". A ferramenta para abrir coisas, o instrumento musical, a resposta de um problema, a característica principal de uma pessoa. Todos esses sentidos estão ligados pela ideia de "algo que desvenda, que abre, que resolve". Se você tentar explicar a polissemia para alguém usando apenas dicionários, vai perder informações importantes. O dicionário lista os significados isoladamente, mas não mostra como eles se relacionam -- e é exatamente essa relação que importa quando você trabalha com processamento de linguagem.

O que é uma palavra polissêmica, na minha experiência, deixa de ser uma definição teórica quando você começa a lidar com corpus reais. A palavra "corrente" em textos de engenharia pode ser elétrica, marinha ou cronológica. Sem o contexto técnico adequado, qualquer sistema de NLP vai vacilar. O mesmo vale para "fio" -- pode ser têxtil, elétrico, anatômico ou até genealógico. Os três primeiros parecem sem relação, mas todos derivam do conceito de "linha alongada e flexível".

Como identificar polissemia em um texto técnico

O método mais confiável que eu uso envolve dois passos simples. Primeiro, extraio todas as ocorrências da palavra-alvo no corpus. Segundo, verifico os vizinhos -- as palavras que aparecem dentro de uma janela de cinco termos para cada ocorrência. Os vizinhos revelam o sentido mais provável. Por exemplo, se "banco" aparece junto com "agência", "taxa" e "empréstimo", é claramente o financeiro. Se aparece com "praça", "rua" e "público", é o assento. O problema é que textos mal estruturados ou traduções ruins podem colocar esses vizinhos errados, e aí seu método de disambiguação falha. Já perdi duas horas num projeto assim porque o corpus de treinamento vinha de artigos científicos mal indexados -- a palavra "seda" estava sendo associada a tecidos em alguns trechos e ao inseto em outros, mas sem distinção clara nos metadados. Uma técnica complementar que funciona bem é verificar a co-ocorrência com preposições. Em português, "em banco" tende ao sentido financeiro enquanto "no banco" pode ser ambos, mas "sentar no banco" quase sempre é o assento. Preposições são marcadores contextuais baratos e eficientes que a maioria dos sistemas descartam.

Armadilhas que ninguém menciona

A primeira armadilha é assumir que todos os significados de uma palavra polissêmica têm a mesma probabilidade de ocorrência. Na prática, um ou dois sentidos dominam. "Pena" como pena de prisão e pena de ave são os mais frequentes. "Pena" no sentido de "lástima" é muito menos comum em textos técnicos, mas aparece em traduções literárias e confunde filtros baseados em frequência. Se você treinar um modelo com corpus generalista, ele vai dar peso igual a todos os sentidos -- e isso gera erros sistemáticos em domínios específicos. A segunda armadilha é ignorar que polissemia e ambiguidade estrutural se alimentam. Quando uma palavra muda de sentido dentro de um parágrafo, o sistema precisa perceber a mudança, não apenas escolher o sentido mais provável globalmente. Eu trabalhei num projeto de análise de contratos onde "valor" alternava entre "preço" e "significado" ao longo do mesmo documento. Um modelo de WSD (Word Sense Disambiguation) padrão escolhia o sentido mais frequente e aplicava uniformemente -- o que tornava trechos inteiros incompreensíveis. A solução foi segmentar o texto por cláusulas e tratar cada segmento como um contexto independente. Existe ainda o problema dos neologismos e gírias. Palavras que estão ganhando novos sentidos rapidamente -- como "cloud" em português técnico, que agora carrega o sentido de computação em nuvem além do sentido meteorológico -- frequentemente não aparecem em recursos lexicais atualizados. WordNet, BabelNet, até os dicionários online mais tradicionais ficam defasados. O workaround que funcionou para mim foi criar um glossário setorial personalizado, alimentado com extração de padrões de co-ocorrência dos documentos mais recentes da área, e usar esse glossário como fallback quando os recursos padrão falhavam.

Limitações que valem a pena saber

Sistemas automáticos de desambiguação de sentido atingem cerca de 80-85% de precisão em línguas com bons recursos, como inglês e português. Para línguas menos representadas, cai para 60-65%. O ganho marginal depois de 85% é muito caro -- cada ponto percentual adicional exige mais dados anotados manualmente e arquitetura mais complexa. Em produção, isso significa que você nunca vai confiar 100% em automação para polissemia. O custo de anotar dados para WSD é outra limitação prática. Um anotador humano letrado leva em média 4-6 minutos por occurrence para marcar o sentido correto em português. Para um corpus de 10.000 ocorrências de palavras polissêmicas, isso são entre 66 e 100 horas de trabalho especializado. A alternativa semi-supervisionada -- usar regras heurísticas e propagação de rótulos -- reduz o tempo, mas a precisão cai para a faixa dos 70%. Não existe configuração que entregue velocidade e precisão simultaneamente. Se o seu objetivo é apenas identificar palavras polissêmicas num texto sem precisar desambiguá-las automaticamente, uma abordagem mais prática é usar embeddings contextualizados como BERT ou modelos similares. Eles capturam o sentido de cada ocorrência individualmente, sem depender de léxicos estáticos. O problema é que esses modelos são pesados e caros para rodar em escala. Para processos internos de revisão, pode valer a pena; para pipelines de produção com milhões de documentos, não.

O que fica é que polissemia não é um bug -- é uma característica estrutural do idioma. Tratar ela como algo a ser eliminado em vez de gerenciado é o erro mais comum que eu vejo em projetos de PLN. A solução não é melhor modelo, é melhor compreensão de quando o modelo não precisa ser perfeito.