LLMs não tornam pipelines de machine learning obsoletos

Elas tornam mais difícil justificar cada etapa deles.

Há alguns meses, venho desenvolvendo um sistema para analisar comentários de redes sociais em um domínio no qual o significado de um texto depende de muito mais do que as palavras presentes nele.

Classificar um comentário como positivo, negativo ou neutro é apenas o começo.

Um texto pode ter tom linguístico negativo e, ainda assim, expressar uma posição favorável em relação ao objeto analisado. "Corrupto desde sempre, mas pelo menos não é ele" é claramente negativo, e claramente um voto de confiança em outra pessoa. Um comentário pode elogiar alguém mencionado de passagem sem demonstrar apoio direto ao assunto principal. Pode parecer neutro para um modelo genérico, mas carregar um significado bastante claro dentro de um contexto específico.

Ironia, negação, referências externas e múltiplos alvos na mesma frase tornam essa separação ainda mais difícil.

Foi por isso que o sistema começou a crescer em camadas.

Na base, um modelo especializado em linguagem de redes sociais realiza a classificação inicial. Os casos de baixa confiança, ambiguidade ou ironia seguem por outros caminhos, apoiados por heurísticas e por informações que o comentário isolado não consegue fornecer.

O conteúdo original também entra na análise quando necessário. Em textos mais longos, uma representação resumida preserva o contexto sem ultrapassar os limites do modelo.

A classificação de stance acontece em uma etapa separada do sentimento linguístico: o sentimento descreve o tom do texto; o stance identifica a posição em relação ao objeto analisado.

Já o label que chega ao produto pertence a uma terceira camada: uma resolução controlada entre modelos, contexto, correções humanas e versões explicitamente aprovadas.

Unificar tudo em uma única classificação seria mais simples, e semanticamente errado.

          comentário
              │
              ▼
┌─────────────────────────────┐
│ 1 · sentimento linguístico  │  tom do texto (pos / neu / neg)
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ 2 · stance                  │  posição relativa ao objeto
└─────────────┬───────────────┘
              │
              ▼
┌─────────────────────────────┐
│ 3 · label de produto        │  resolução + gate de promoção
└─────────────────────────────┘

A descoberta de tópicos

Além de classificar os comentários individualmente, o sistema precisa identificar os principais assuntos presentes na conversa.

Os textos viram vetores de 768 dimensões; a dimensionalidade é reduzida antes da clusterização para tornar a estrutura semântica mais tratável. Em seguida, um método baseado em densidade agrupa os pontos, com parâmetros ajustados para cada conjunto de dados.

Os resultados não são aceitos apenas porque o algoritmo conseguiu separar alguns grupos. A qualidade da estrutura é avaliada sob mais de um critério: coesão dentro de cada grupo, distância entre grupos e o equilíbrio entre essas duas forças. Grupos semanticamente próximos são comparados e, quando necessário, fundidos. O objetivo é que o produto não mostre três tópicos que são, na prática, a mesma conversa com sotaques diferentes.

Comentário e conteúdo original também recebem pesos diferentes na representação final, para que um texto curto não seja interpretado sem a informação à qual ele responde.

Nem toda janela sustenta essa sofisticação. Quando a amostra é pequena, forçar uma clusterização produz uma precisão artificial, e o sistema precisa reconhecer essa limitação e aplicar um comportamento determinístico mais simples.

Por fim, uma LLM transforma os grupos encontrados em rótulos compreensíveis. Ela não decide como os comentários serão agrupados; recebe uma estrutura já formada e ajuda a convertê-la em linguagem útil para quem consulta o produto.

Gerar vetores e rodar um algoritmo de clusterização, sozinho, não basta. Cada etapa carrega uma decisão: como representar o texto, quando fundir grupos quase iguais, quando a amostra é pequena demais para forçar estrutura, e se a coesão entre clusters passa de "matematicamente ok" para "útil no painel". Só depois disso a LLM entra, e só para rotular o que já foi formado.

O notebook é a parte fácil

Nada disso vive isolado em um notebook.

O pipeline processa diariamente comentários de diferentes redes sociais, em volumes que variam bastante entre entidades, plataformas e períodos.

O processamento é incremental. Comentários já analisados não precisam passar novamente por todas as etapas.

Classificação e clusterização também possuem ciclos independentes. Assim, é possível recalcular os tópicos de uma janela específica sem reprocessar o sentimento de todo o histórico.

Essa separação é necessária porque as janelas importam.

Os principais assuntos de uma semana não são necessariamente os mesmos de um mês. A conversa de uma plataforma pode ser completamente diferente daquela encontrada em outra. Um agrupamento global e permanente perderia justamente a variação temporal e demográfica que torna os tópicos relevantes.

Cada job precisa saber exatamente qual entidade, plataforma e período está processando.

Também precisa conviver com filas persistentes, concorrência, idempotência, recuperação de execuções interrompidas, limites de custo, circuit breaker, canary, versionamento de imagem e rollback.

São preocupações que raramente aparecem em uma demonstração.

O que acontece quando o provedor de LLM falha?

Como o sistema reage quando a resposta vem fora do schema?

O que ocorre quando o orçamento termina no meio da execução?

Como impedir que duas instâncias processem o mesmo comentário?

O que fazer quando um job é interrompido depois de já ter realizado chamadas externas?

Como garantir que uma nova versão do modelo não altere silenciosamente aquilo que o usuário enxerga?

Essas perguntas pararam de ser retóricas numa madrugada em que o provedor de LLM ficou lento sob concorrência. Cada execução, isolada, respondia em poucos segundos. O problema apareceu quando várias execuções passaram a rodar ao mesmo tempo, cada uma abrindo suas próprias chamadas externas, disputando o mesmo provedor até ele engasgar: uma tarefa que levava cerca de cinco segundos passou a levar mais de um minuto, sob uma carga que antes era trivial.

A correção foi tirar essas chamadas do caminho principal e concentrá-las em um único processo, que faz fila e absorve a contenção sozinho, em vez de trocar de modelo.

antes                              depois
─────                              ──────

job A ──┐                          job A ──┐
job B ──┼──► provedor llm          job B ──┼──► fila ──► drain ──► provedor
job C ──┘    (contenção)           job C ──┘         (1×)

Nada disso aparece numa demo. Aparece às sete da manhã, quando alguém pergunta por que o painel ainda não atualizou.

Há ainda uma restrição operacional bastante concreta: os dados precisam estar disponíveis dentro de uma janela definida.

Isso transforma tempo de conclusão, recuperação de falhas e tamanho do backlog em requisitos de produto, não apenas em detalhes de infraestrutura.

Uma solução pode funcionar perfeitamente em uma amostra e ainda assim ser inadequada em produção.

A pergunta desconfortável

Foi justamente depois de construir tudo isso que surgiu uma pergunta difícil de ignorar:

Se eu estivesse começando hoje, faria tudo novamente?

Ou simplesmente enviaria os comentários para uma LLM e pediria:

"Encontre os principais tópicos, agrupe os comentários e explique cada grupo"?

A resposta honesta é que, em uma demonstração, uma LLM chegaria perto. Talvez produzisse tópicos até mais interessantes em alguns recortes, com menos código e um custo direto comparável ao custo computacional de algumas execuções do pipeline.

Essa possibilidade precisa ser levada a sério. Entretanto, no dia seguinte os problemas aparecem: o mesmo prompt, com o mesmo input, devolve um output diferente; às vezes simplesmente ignora o schema de structured output definido no prompt, ou qualquer outra tentativa de camada determinística no fluxo com a LLM. Falta aí a reprodutibilidade metodológica e o determinismo matemático que, em muitos cenários, são o grande diferencial do pipeline.

Depois de investir meses em uma solução, é fácil começar a defendê-la pelo esforço que ela exigiu. A complexidade vira motivo de orgulho, e decisões que deveriam continuar sendo hipóteses técnicas passam a ser tratadas como patrimônio pessoal. Mas dificuldade de construção não é vantagem competitiva, e orgulho técnico é um péssimo critério de permanência arquitetural.

Se uma chamada de LLM entregar a mesma qualidade, com menor custo total, menor latência e risco operacional aceitável, a decisão correta é substituir o que existe.

Não importa quantas métricas, heurísticas ou noites de trabalho tenham sido necessárias para construir a versão anterior.

O problema é que resultado visualmente parecido não significa sistema equivalente.

Uma boa resposta não é o mesmo que um sistema confiável

Uma nuvem de tópicos razoável em uma amostra não demonstra que os resultados serão estáveis entre execuções, nem que os grupos continuarão comparáveis entre períodos, nem que o comportamento será reproduzível depois de uma mudança de modelo.

Uma demonstração dificilmente responde como a solução se comportará quando o volume crescer, quando o contexto mudar ou quando uma única entidade concentrar milhares de comentários a mais do que as outras. Também não explica como recuperar o trabalho depois de uma falha, impedir custo duplicado, auditar decisões antigas ou separar uma versão experimental daquela efetivamente aprovada para o produto.

Esse ponto costuma desaparecer quando comparamos uma arquitetura inteira com uma chamada isolada de API.

A LLM pode entregar uma excelente resposta. O sistema precisa entregar essa resposta de forma repetível, observável, economicamente previsível e recuperável: bem numa segunda-feira de manhã, com backlog, sem ninguém olhando. São problemas diferentes.

O custo não está apenas na inferência

Comparar o preço de uma chamada de API com o consumo de CPU e memória do processamento em nuvem é insuficiente. O custo real inclui inferência, engenharia, observabilidade, recuperação, auditoria e risco operacional: execução duplicada, backlog que atrasa entrega, classificação incorreta que altera um relatório, investigação quando ninguém explica o resultado, respostas inválidas no meio de milhares de processamentos, e a dependência de um comportamento externo que pode mudar sem que o restante da arquitetura esteja preparado.

Uma solução aparentemente mais barata pode se tornar cara quando exige reprocessamento, revisão manual constante ou investigação recorrente de inconsistências.

Da mesma forma, um pipeline complexo também pode se tornar caro quando ninguém consegue mais justificar a permanência de cada etapa.

Por isso, a comparação precisa considerar o custo total do sistema, e não apenas o preço unitário de uma inferência.

O valor não está no algoritmo

Foi aí que minha visão sobre o valor do pipeline mudou. Algoritmo de clusterização, redução de dimensionalidade, heurísticas, pesos e métricas são peças substituíveis. O que permanece, e o que de fato importa, é o contrato construído ao redor do problema.

Esse contrato aparece em decisões concretas. Sentimento linguístico, stance e o label do produto são três classificações distintas, cada uma com versão e histórico próprios. Uma versão nova só chega ao usuário depois de um gate explícito de benchmark, canary e comparação com a versão anterior. Enquanto isso não acontece, o produto continua mostrando a versão já aprovada. O experimental fica de fora até provar que merece entrar.

O mesmo vale para os tópicos: cada janela pode ser recalculada sem reprocessar o histórico inteiro, e um trabalho interrompido não paga duas vezes pela mesma análise. Chamadas, tokens e custo têm teto por operação e por execução; quando o provedor principal falha, a contenção entra dentro de limites conhecidos.

Nesse desenho, a LLM vira um componente probabilístico dentro de um sistema que controla quando, por que e sob quais condições ela pode decidir. Ela deixa de ser tratada como a entidade que recebe um texto e devolve a verdade.

Daí a conclusão: o valor do pipeline está nesse contrato. O algoritmo pode mudar. Qualquer substituto precisa competir com o sistema inteiro, não só com o resultado mais visível dele. A pergunta útil deixa de ser "qual abordagem gera os tópicos mais bonitos?" e passa a cobrir qualidade semântica, estabilidade temporal, custo por volume processado, latência, cobertura, taxa de abstenção, reprodutibilidade, auditabilidade, capacidade de recuperação e impacto de uma falha sobre o produto.

A arquitetura já é híbrida

Depois dessa reflexão, parei de tratar ciência de dados tradicional e LLMs como abordagens concorrentes.

No sistema atual, um modelo especializado resolve rapidamente a maior parte dos comentários. A LLM entra nos casos em que a incerteza e a complexidade semântica justificam seu custo.

Na clusterização, os métodos numéricos encontram estrutura no espaço vetorial. A LLM ajuda a transformar essa estrutura em linguagem compreensível.

Na classificação contextual, informações determinísticas e outputs estruturados delimitam o espaço em que o modelo pode decidir.

Na operação, filas, budgets, circuitos, versões e gates de promoção impedem que a capacidade probabilística da LLM se transforme em imprevisibilidade para o produto.

A arquitetura deixou de ser "modelo clássico ou LLM" e passou a ser roteamento por workload.

                 ┌──────────────────────┐
 volume alto ──> │ modelo especializado │ escala · custo previsível
 repetibilidade  └──────────────────────┘
                 ┌──────────────────────┐
 ambiguidade ──> │ llm                  │ interpretação contextual
 contexto        └──────────────────────┘
                 ┌──────────────────────┐
 promoção ─────> │ gates · budgets ·    │ o que chega ao usuário
 falha           │ filas · versões      │
                 └──────────────────────┘

Métodos especializados onde precisamos de escala, repetibilidade e custo previsível.

LLMs onde a interpretação contextual vale mais do que o determinismo.

E critérios objetivos para substituir qualquer uma dessas partes quando surgir uma alternativa melhor.

O que realmente precisa ser defendido

A maturidade está menos em defender a solução que deu mais trabalho, ou em colocar uma LLM em tudo porque ela representa o estado atual da tecnologia, do que em compreender o problema, medir os trade-offs e saber por que cada componente continua dentro da arquitetura.

Uma etapa merece permanecer enquanto entregar valor mensurável, não porque foi difícil de construir. Da mesma forma, uma LLM deve entrar quando melhora o equilíbrio entre qualidade, custo, velocidade e risco, não só porque parece moderna, elegante ou simples.

Os métodos especializados continuam onde entregam consistência e eficiência. As LLMs entram onde a interpretação contextual realmente amplia a capacidade do sistema.

No fim, construí um sistema que sabe quando usar LLMs, não um pipeline para competir com elas.