Frase Com Substantivo Proprio

Processando frases com substantivo próprio em pipelines de NLP

A maioria dos tutoriais que você encontra na internet trata substantivos próprios como um problema resolvido. Na prática, não é. A extração e manipulação de uma frase com substantivo próprio em dados reais de produção costuma ser muito mais bagunçada do que os exemplos didáticos sugerem. Você precisa pensar no fluxo em três etapas: identificação, normalização e contextualização. A etapa de identificação é onde 80% dos erros acontecem. Usar apenas regex para capturar nomes próprios é pedir para ver resultados errados. Um SP pode significar São Paulo, Service Pack, ou até Special Project dependendo do domínio. Sem contexto, o regex não tem como distinguir. O método que eu uso em produção combina um modelo de NER treinado com regras heurísticas pós-processamento. O modelo propõe candidatos, e as regras filtram falsos positivos baseados no domínio do texto. Por exemplo, em documentos jurídicos, nomes de cidades aparecem com frequência elevada, mas em artigos técnicos de TI, a proporção muda completamente. Ignorar essa diferença gera ruído que escala rapidamente.

Depois da identificação, a normalização é crítica. "Rio de Janeiro", "rio de janeiro" e "RIO DE JANEIRO" precisam convergir para a mesma entidade. Eu aplico uma camada de lematização específica para nomes próprios antes de qualquer agregação, usando um dicionário de variações conhecidas do domínio. Isso resolve o problema de entidades fragmentadas que aparecem quando você só normaliza por lowercase.

Um problema específico que eu enfrentei

No projeto para uma empresa de logística, tínhamos que extrair frases com substantivo próprio de notas fiscais eletrônicas em lote. O problema era que o sistema de NER padrão taggeava "BR" como país (Brazil) em 40% das ocorrências, quando na verdade se tratava de abreviação de "brita", um tipo de agregado mineral. O filtro que eu implementei foi cruzar a tag do NER com um dicionário setoriais de sinônimos. Se a palavra aparecesse em listas de materiais de construção, a tag de localização era sobrescrita. O resultado foi uma redução de falso positivo de 40% para cerca de 3%. O custo foi manter o dicionário atualizado conforme novos termos entravam no vocabulário operacional da empresa. A principal limitação de qualquer abordagem baseada em modelo é a dependência do domínio de treino. Modelos gerais como o disponível no spaCy ou no Hugging Face performam bem em textos jornalísticos e literários, mas caem feio em documentação técnica, transcrições de atendimento ou textos com muita variação ortográfica não padronizada. Se o seu corpus não se parece com o que o modelo viu durante o treino, a precisão despencaa. Nesse caso, o fine-tuning com dados anotados do domínio é quase obrigatório, e isso significa ter pelo menos alguns milhares de exemplos rotulados manualmente. Outro problema prático é a velocidade. Processar uma frase com substantivo próprio com um modelo transformer robusto leva de 50 a 200 milissegundos por instância, dependendo do hardware e do tamanho do texto. Para batches pequenos, isso é aceitável. Para processing em tempo real com milhares de requisições por minuto, a coisa muda de figura. Nesses cenários, eu recomendo uma arquitetura híbrida: um classificador rápido (como um TF-IDF com log regression) faz o primeiro filtro, e só os casos borderline passam pelo modelo pesado. Isso reduz o custo computacional em cerca de 60% sem perda significativa de recall.

Se o seu objetivo é apenas detecção básica e não precisa de alta precisão, vale a pena considerar alternativas mais simples. O padrão NLTK com um listão de stopwords e capitalização já cobre muitos casos comuns. Para uso em scripts rápidos e testes, é suficiente. A desvantagem é que a taxa de erro em textos complexos fica na casa dos 25% a 35%, o que pode ser inaceitável dependendo do uso final.

Considerações finais sobre a escolha da ferramenta

Não existe solução única. A definição de "frase com substantivo próprio" varia conforme a aplicação: para análise de sentimento, você talvez precise focar apenas em nomes de pessoas e organizações. Para extração de informações de contratos, municípios e estados são tão importantes quanto nomes próprios de indivíduos. Definir claramente o escopo antes de escolher a stack técnica evita retrabalho. A parte mais demorada do processo nunca é a implementação em si, e sim a limpeza e padronização dos dados de entrada.