ADR-019
Parser por plataforma com expressão regular, e não modelo de linguagem
Modelo de linguagem foi descartado num parser de e-mail, e não por custo: por determinismo. O mesmo e-mail precisa produzir sempre o mesmo cliente, e o que quebra é o formato mudar sem ninguém avisar.
Contexto
Cada uma das três plataformas manda o e-mail no seu próprio formato. O contexto da captura, com o volume, está na ADR-018. O da principal delas é texto plano com pares chave-valor (nome, dois telefones, e-mail, país de origem, país de destino), e um dos telefones vem literalmente como um traço quando não existe. O sistema precisa reconhecer de qual plataforma veio a mensagem e extrair dela os campos que viram cliente.
Critérios que pesaram
Em ordem de peso.
- Determinismo. O mesmo e-mail tem de produzir sempre o mesmo resultado.
- Testabilidade com amostras reais de mensagem.
- Custo por lead, num fluxo que roda continuamente.
- Extensão sem deploy, se possível: plataforma nova não deveria exigir código.
Opções consideradas
- Modelo de linguagem para extrair dados estruturados. Flexível diante de formatos variados, e descartado por três razões registradas: custo por chamada, latência, e resultado não determinístico num fluxo em que o mesmo e-mail precisa produzir sempre o mesmo cliente.
- Navegação no DOM do e-mail com um parser de HTML: preciso para mensagens HTML bem estruturadas, e mais frágil que expressão regular diante de mudança de layout. Descartada.
- Estratégia por plataforma, com expressões regulares de reconhecimento e de extração, cadastradas por plataforma.
Decisão
Cada plataforma é um registro cadastrável que carrega dois conjuntos de expressões regulares: as de reconhecimento, aplicadas a remetente, assunto e corpo (a primeira plataforma cujos padrões casam fica com o e-mail), e as de extração, nomeadas por campo, aplicadas ao corpo. Plataforma nova entra pela tela de administração, sem deploy; só se a especificidade não couber em expressão regular é que se estende o serviço com uma estratégia própria, e a orientação registrada é preferir sempre a expressão regular. O e-mail que nenhuma plataforma reconhece vira registro ignorado; o que é reconhecido mas falha na extração vira erro; o que extrai dados abaixo do mínimo aceitável (nome curto demais, e-mail sem arroba) vira pendente de revisão. Nenhum dos três é descartado, e todos aparecem na tela para tratamento manual.
Consequências
As duas metades pesam igual.
Melhorou
O comportamento é reproduzível e testável com amostras reais, e o custo por lead é zero. Como as expressões são cadastro, ajustar o parser de uma plataforma que mudou o formato não exige publicar versão nova.
Piorou
Expressão regular quebra quando o formato muda, e quem descobre é a taxa de e-mails ignorados subindo; não há alarme para isso. Também há um custo escondido no cadastro: as expressões viraram configuração de produção, então um ajuste malfeito na tela derruba a captura sem passar por revisão de código nem por teste.
Revisitando hoje
Ainda de pé em set/2026, e o descarte do modelo de linguagem envelheceu bem pelo motivo certo, não por custo, que caiu muito desde então, e sim por determinismo: um pipeline que cria cliente a partir do mesmo e-mail precisa produzir o mesmo cliente todas as vezes. O que eu acrescentaria é a peça que falta desde o início: um alerta quando a proporção de e-mails ignorados sair do normal.
Segundo de quatro registros sobre a captura de leads. O anterior decidiu como o e-mail chega; este decide o que fazer com ele.