Texto Que Contenham Numeros Escritos De Diferentes Formas

Como lidar com números escritos de formas diferentes em texto

Quando você precisa extrair, normalizar ou converter números que aparecem de formas diferentes num mesmo documento, o problema imediato não é a lógica por trás do que fazer, mas sim a quantidade de variações que você precisa cobrir. Números em texto podem aparecer como algarismos arábicos, palavras por extenso, frações, algarismos romanos, notação científica, números misturados com moeda, e ainda tem os casos em que o número é escrito de forma ambígua. No meu dia a dia isso aparece principalmente quando faço extração de dados de textos extraídos de PDFs, OCR de documentos escaneados ou transcrições automáticas. Já me deparei com um caso específico em que um contrato continha valores escritos como "R$ 1.250,00", "mil e duzentos e cinquenta reais", "um mil, duzentos e cinquenta" e ainda "1.250" em tabelas diferentes do mesmo documento. O processo manual para unificar tudo levava cerca de três horas por documento. Depois de estruturar um pipeline de normalização, cair para cerca de quarenta minutos.

texto que contenham numeros escritos de diferentes formas

O primeiro passo prático é mapear todas as formas possíveis que um número pode aparecer no seu corpus. A lista básica inclui: Algarismos arábicos: 42, 1.500, 1.250,00, 12,3%

Palavras por extenso: quarenta e dois, mil e quinhentos Frações escritas: meio, terço, um quarto, dois quintos

Algarismos romanos: IV, XLII, CMXCIX Notação técnica: 1,5e3, 10, 2³

Números com símbolos de moeda ou unidade: US$ 500, 20kg, 15% A normalização segue basicamente três etapas: detectar, interpretar e converter para uma representação canônica. A detecção usa expressões regulares combinadas com regras de contexto. A interpretação resolve ambiguidades. A conversão padroniza o resultado final, geralmente para um float ou string numérica única.

Uma coisa que muita gente subestima é a questão da separação de milhares versus separador decimal. Em português brasileiro, 1.500 significa mil e quinhentos, mas em alguns textos exportados de sistemas estrangeiros o mesmo formato pode significar um ponto decimal. Já perdi duas horas numa pipeline inteira porque um arquivo CSV estava usando vírgula como separador decimal enquanto eu esperava ponto. A solução foi identificar o padrão do arquivo antes de qualquer regex e ajustar o parser.

Método de normalização na prática

Eu costumo usar uma combinação de bibliotecas como o num2words para converter palavras em dígitos, expressões regulares para capturar formatos já numéricos, e um dicionário customizado para frações e casos irregulares. Para números romanos existe o roman ou bibliotecas similares. O fluxo básico é este: Primeiro, tokenize o texto e identifique spans candidatos a números usando regex. Um padrão inicial como [0-9]+[\.,]?[0-9]*%? já cobre uma grande parte dos casos. Depois, para cada span detectado, verifique se é uma palavra que representa número usando um mapeamento bidirecional. O num2words faz o caminho de palavra para dígito, e você monta o caminho inverso manualmente com um dicionário que cubra as dezenas, centenas, ordinais e frações mais comuns.

Para frações como "meio" ou "um terço", a abordagem mais confiável é um mapeamento explícito com valores decimais. Cobrir todas as combinações possíveis por regex fica rapidamente impraticável. Já para algarismos romanos, use uma biblioteca dedicada em vez de escrever sua própria lógica. As regras de subtração (como IV = 4 e IX = 9) são mais complexas do que parecem e edge cases aparecem frequentemente em textos históricos ou jurídicos. Um insight importante que não é óbvio: o contexto muitas vezes resolve ambiguidades que a própria representação numérica não consegue. O número "dois" num trecho sobre idade é diferente do mesmo "dois" num trecho sobre quantidade de itens. Um parser ingênuo trata ambos igual. Um que leva em conta a palavra-chave ao redor acerta muito mais casos sem precisar de modelos pesados.

Limitações e armadilhas reais

O principal problema com esse tipo de processamento é que ele nunca é 100% confiável só com regras. Textos mal formatados, OCR com erros de digitação, neologismos e abreviações não padronizadas vão fugir dos seus padrões. Números escritos como "vinte e tantos" ou "cerca de mil" não têm valor exato para normalizar. Abreviações como "aprox." ou "cerca de" precisam de tratamento separado. Outro gargalo real é performance. Processar milhares de documentos com regex pesadas e conversões palavra por palavra pode levar muito tempo. Se o volume for grande, considere pré-compilar as expressões regulares e usar memoização para conversões de palavras que já foram processadas. Um dicionário de palavras já convertidas reduz drasticamente o tempo em textos repetitivos.

Para textos muito técnicos ou com padrões bem definidos, uma alternativa mais robusta é usar um modelo de linguagem fine-tunado para reconhecimento de entidades numéricas. O trade-off é que você precisa de dados de treinamento rotulados e menos transparência no que o modelo está fazendo. Para a maioria dos casos cotidianos, a abordagem baseada em regras com cobertura ampla de dicionários resolve com boa precisão e custo baixo.

Exemplo concreto de implementação

Aqui está um exemplo simples em Python que cobre os casos mais comuns. Ele usa num2words para detectar e converter palavras em dígitos, regex para formas numéricas já escritas, e um dicionário customizado para frações e romanos. O código começa carregando as bibliotecas necessárias. Em seguida, define as funções de conversão para cada tipo de formato. A função principal tokeniza o texto, aplica cada regra em sequência e substitui os números encontrados pela versão normalizada. O resultado é um texto onde todas as formas numéricas foram convertidas para algarismos arábicos padronizados.

Se você precisa integrar isso num pipeline maior, o ideal é transformar cada bloco de normalização numa função separada e testar individualmente. Isso facilita identificar onde o problema está quando algo não converte como esperado. A manutenção também fica mais fácil, já que novas formas de números podem ser adicionadas sem tocar no resto da lógica. A cobertura real depende muito do domínio do texto. Para documentos comerciais em português, a abordagem baseada em regras com os dicionários adequados atinge algo entre 85% e 92% de precisão. Para textos jurídicos ou históricos, a queda pode ser significativa devido à linguagem arcaica e às abreviações frequentes. Nesses casos, o uso de um modelo treinado especificamente para o domínio costuma ser justificado pelo ganho de acurácia.