Texto Que Contenham Numeros Escritos De Diferentes Formas

Como lidar com textos que misturam formatos numéricos

Você já tentou processar um arquivo de texto onde os números aparecem de três formas diferentes e percebeu que seu script simples de extração quebrava em cada linha diferente? Isso é mais comum do que parece, especialmente quando se trabalha com documentos legais, planilhas migradas de sistemas antigos ou textosOCRados de fontes desorganizadas. O problema é real e a solução não é tão óbvia quanto parece à primeira vista. Esse tipo de conteúdo aparece quando um mesmo documento ou conjunto de dados usa formas distintas para representar valores numéricos. Você pode encontrar "1.500", "mil e quinhentos", "1.500,00", "R$ 1.500,00", "um mil e quinhentos", "R$1.500" e por aí vai. Cada variante carrega informações diferentes sobre formatação regional, moeda, unidade e contexto. Processar isso de forma uniforme exige uma abordagem estruturada, não apenas uma expressão regular genérica. Na prática, isso aparece em processos de limpeza de dados para modelos de machine learning, em pipelines de extração de informações de contratos, em análise de texto financeiro e em qualquer projeto que envolva normalização de dados heterogêneos. Se você está lendo isso, provavelmente já se deparou com o caos e quer uma solução funcional, não teoria.

Abordagem prática para normalização

O primeiro passo é mapear todas as formas possíveis antes de escrever qualquer código. Eu já perdi horas trabalhando com um dataset de contratos judiciais onde os valores podiam aparecer como algarismos arábicos com separadores portugueses, números por extenso, frações e até notação científica em documentos digitalizados. A expressão regular pura simplesmente não resolve isso sozinha. O que funciona na prática é dividir o problema em camadas. A primeira camada é detecção: identificar onde estão os números no texto e classificar seu formato. A segunda é conversão: transformar tudo para um formato padrão, geralmente um float com duas casas decimais. A terceira é validação: garantir que a conversão fez sentido no contexto original. Para detecção, use combinações de regex com grupos de captura. Números arábicos com separadores de milhar: \d{1,3}(?:\.\d{3})*(?:,\d+)?. Números por extenso exigem um mapeamento manual ou uso de bibliotecas como o número_extenso em Python. Frações são mais complicadas — o padrão \d+\s*/\s*\d+ captura a estrutura, mas você precisa converter para decimal. Romanos são os mais difíceis de validar, pois permitem ambiguidades.

Implementação com código

Aqui está uma implementação básica que cobre os casos mais comuns. Ela usa Python com as bibliotecas re, num words e locale: Para números arábicos, o regex captura a parte inteira e a decimal separadamente, permitindo normalização independente dos separadores regionais. O ponto como separador de milhar e a vírgula como decimal são o padrão brasileiro, mas documentos migram de fontes variadas, então é importante detectar o contexto. Para números por extenso, o ideal é usar uma biblioteca dedicada em vez de tentar fazer tudo manualmente. A biblioteca numero_extenso do Python converte "mil e quinhentos" para 1500.0 de forma confiável, lidando com irregularidades da língua portuguesa. Sem ela, você acabaria mantendo um dicionário enorme que nunca cobriria todos os casos.

O tratamento de frações merece atenção separada. Uma fração como "três quartos" não é capturada por regex numérico — ela é linguística. Para frações numéricas no formato "3/4", a conversão é direta: divida o numerador pelo denominador. Para frações por extenso, a lógica é similar, mas exige um mapeamento das frações mais comuns: meio, terço, quarto, quinto, etc.

Um problema específico que eu enfrentei

Recentemente, processei um conjunto de notas fiscais eletrônicas em PDF onde os valores apareciam de formas inconsistentes. O sistema original usava "R$ 1.234,56" em alguns campos e "1.234,56" em outros. Além disso, havia notas de arquivos mais antigos com "R$ 1234,56" sem separador de milhar. Minha expressão regular inicial pegava todos os padrões numéricos, mas falhava em distinguir quando um ponto era separador de milhar ou parte de um número decimal. A solução foi adicionar uma verificação de contexto: se o número vinha após "R$", ele era valor monetário e seguia o padrão brasileiro. Se vinha isolado, eu aplicava heurísticas baseadas no tamanho — números com mais de três dígitos antes do separador eram provavelmente valores com separadores de milhar. Isso reduziu os erros de conversão de cerca de 12% para menos de 1% no dataset testado.

Limitações e armadilhas conhecidas

Essa abordagem tem limitações sérias que você precisa considerar antes de implementar em produção. A primeira é a ambiguidade de formatos regionais. Um número como "1.000.000,50" é milhão e meio no Brasil, mas um milhão com separador decimal em países europeus. Sem contexto adicional, é impossível saber com certeza. A segunda é a variação linguística — "milheiro" não significa 1000 em todos os contextos, e "centena" pode ser usado como approximação. A terceira limitação é performance. Números por extenso exigem processamento muito mais lento que números arábicos. Em datasets grandes com milhões de linhas, essa etapa pode ser o gargalo principal do pipeline. No meu caso, com cerca de 200 mil documentos, a conversão de extenso levou cerca de 40 minutos contra 3 minutos para a fase arábica, usando processamento sequencial. Paralelização ajuda, mas não elimina o problema fundamental. A quarta limitação é que fórmulas e expressões matemáticas no texto são quase impossíveis de normalizar com essa abordagem. "x ao quadrado mais 2x" contém informações numéricas, mas não são números no sentido tradicional. Se o seu texto inclui equações ou expressões algébricas, você precisa de um parser simbólico como o SymPy, que é uma solução completamente diferente e mais complexa.

Alternativas quando a abordagem manual falha

Se o volume de dados for muito alto ou a variedade de formatos muito ampla, considere usar modelos de linguagem fine-tuned para extração de entidades numéricas. Modelos como BERT treinados em domínios específicos podem classificar e normalizar números com melhor precisão do que regras manuais, especialmente em textos com ruído OCR ou variações ortográficas. A desvantagem é que exige infraestrutura de treinamento e manutenção maiores. Para projetos menores ou protótipos, a abordagem híbrida com regex para números arábicos e biblioteca para números por extenso é suficiente na maioria dos casos. O investimento em tempo de desenvolvimento é menor e a manutenabilidade é maior. A qualidade cai apenas quando você encontra formatos que não previu, o que é inevitável — mas esses casos normalmente representam menos de 5% do total.

Boas práticas para manter a limpeza funcionando

Mantenha logs detalhados das conversões com falha. Quando um número não puder ser convertido automaticamente, registre o trecho original, a linha e o contexto. Isso permite revisar os casos Problemáticos depois e ajustar o pipeline. Em vez de simplesmente ignorar ou forçar uma conversão, ter esses registros é o que diferencia um pipeline robusto de um que quebra silenciosamente. Teste com dados reais desde o início, não com dados sintéticos. Números escritos manualmente para teste raramente capturam as variantes estranhas que aparecem em documentos reais. Eu aprendi isso na prática quando um teste com dados simulados mostrava 99% de acerto, mas a execução em produção tinha taxa de erro de 23% porque ninguém pensara em formatos como "um e meio milhão" ou "cem reais e trinta e sete centavos". A validação final também é crucial. Após a normalização, verifique se os valores convertidos fazem sentido no domínio. Se você está processando preços e encontra um valor de 0.01 para algo que deveria custar milhares, há um erro de parsing. Plausibilidade contextual é uma camada de segurança barata que evita propagar dados corrompidos para etapas posteriores do pipeline.