ML vs LLM: 5 prompts que quebram os LLMs — e como a chamada de ferramentas de ML os corrige

Resumindo:

• Seu LLM agora consegue executar Python, então consegue computar. Mas ainda não consegue aprender um modelo que generalize, manter o estado de cada fluxo ou pontuar uma transmissão ao vivo. A computação nunca foi a parte difícil.
• Os modelos de aprendizado de máquina são precisos em tarefas numéricas específicas, mas inúteis para decidir o que fazer com o resultado.
• Um agente de IA útil precisa de ambos. Abaixo: uma matriz de decisão e cinco instruções que quebram um modelo de aprendizado de máquina, cada uma com a chamada da ferramenta de aprendizado de máquina que a corrige.

Por que as equipes continuam escolhendo a ferramenta errada?

A questão ML versus LLM surge mais do que quase qualquer outra no trabalho de IA aplicada — e nove em cada dez vezes o problema não são os dados. É que uma equipe conectou um LLM a uma tarefa que precisa de ML, ou construiu um dashboard exclusivamente baseado em ML que precisava de um LLM para ser legível.

É uma armadilha fácil. As demonstrações do LLM são deslumbrantes: descreva um problema em linguagem simples e obtenha uma resposta coerente. Então, o próximo passo natural é inserir dados de sensores nesse mesmo modelo e pedir que ele preveja a carga de amanhã, sinalize a bomba com defeito ou classifique as máquinas por risco. Funciona perfeitamente — na demonstração. Mas quando chega a produção, surgem ruídos, lacunas e desvios, e as respostas confiantes silenciosamente se mostram equivocadas.

O fracasso oposto é igualmente comum e mais silencioso: resultados precisos de aprendizado de máquina em um dashboard que ninguém abre. O trabalho interessante está na interseção entre os dois — e é exatamente aí que surge a resistência:

Espera aí — os LLMs não podem simplesmente executar Python agora?

Desafio justo. Há dois anos, a resposta para "por que não perguntar ao mestrado em Direito?" era "ele não consegue fazer os cálculos". Essa resposta agora está errada — e se este artigo ainda se baseasse nela, um engenheiro perspicaz fecharia a aba. Portanto, vamos ser precisos sobre o que mudou e o que não mudou.

Em uma janela de bate-papo, sim. Tanto a Análise Avançada de Dados do ChatGPT quanto a ferramenta de análise do Claude escrevem e executam código Python em um ambiente isolado (sandbox). Mas esse ambiente isolado reside no produto que envolve o modelo — não no próprio modelo.

Através da API, somente se você a configurar. A API é a camada sobre a qual quase todos IoT são construídos, e nela a execução de código é opcional. O Code Interpreter da OpenAI é uma ferramenta que recebe um de ferramentas e um contêiner provisionado (aproximadamente$0,03 cada); code_execution na API de Mensagens está em versão beta e desativada por padrão. Chame o endpoint padrão com um prompt e você receberá tokens, não execução.

Dentro de um agente de produção, o formato é inadequado. Mesmo habilitado, o que você obtém é um ambiente de testes efêmero: é iniciado, retorna um resultado e é encerrado. É uma calculadora, não um local para treinar um modelo, manter uma linha de base por sensor ou monitorar uma transmissão ao vivo. E funciona às cegas — o código é escrito do zero a cada chamada, importa o que estiver presente na imagem do ambiente de testes e, a menos que você construa a infraestrutura para capturá-lo, é executado sem nenhum rastreamento revisável e reproduzível. Para um número que aciona um técnico ou dispara um alarme de segurança, a simples constatação de que "o gerente de projeto escreveu um código Python que nunca analisamos" já é um fator desqualificante.

Portanto, a regra honesta não é "MLs não conseguem computar". É a seguinte: a execução de código permite que uma ML compute; ela não permite que ela aprenda um modelo que generalize, mantenha o estado em centenas de fluxos ou avalie um feed em tempo real. Essa é a linha divisória — e é exatamente a linha que os cinco prompts abaixo cruzam.

A verdadeira linha divisória: computar versus aprender

O aprendizado de máquina (ML) aprende um modelo que generaliza; o modelo de linguagem (LLM) raciocina sobre o resultado em linguagem. A execução do código permite que o LLM compute — não permite que ele aprenda.

Aprendizado de máquina (ML) para inferência, aprendizado de máquina de lógica de cadeia de suprimentos (LLM) para raciocínio. O ML é a ferramenta certa quando a pergunta é "qual é o número?" — uma previsão, uma pontuação de anomalia, uma estimativa de vida útil restante, um rótulo de classe. O LLM é a ferramenta certa quando a pergunta é "o que devemos fazer com o número?" — explicá-lo, priorizá-lo, redigir a mensagem, decidir o próximo passo, acionar a ferramenta adequada.

Três verificações rápidas de sanidade:

• Um modelo de aprendizado de máquina (LLM) consegue prever uma série temporal? Às vezes — e mal. Não para cargas de trabalho de produção, onde erros custam caro.
• Um modelo de aprendizado de máquina pode criar um chamado de manutenção? Não. Ele retorna um número. O que esse número significa no contexto é um problema de linguagem.
• Preciso de ambos? Para qualquer fluxo de trabalho que envolva um ser humano, sim.

A matriz de decisão

Esta é a tabela de comparação entre aprendizado de máquina (ML) e modelagem de aprendizado de máquina (LLM) que redesenhamos constantemente em quadros brancos para projetos IoT e industriais — quando usar machine learningtradicional, quando usar uma LLM e quando usar ambas. Salve esta página nos seus favoritos.

Se a sua tarefa é preencher uma linha na coluna da esquerda e você está procurando a ferramenta errada na coluna do meio, este artigo é para você.

Cinco dicas que atrapalham os LLMs

Cada exemplo segue o mesmo formato: o prompt que falha — por que executar o Python não salva o erro — a tarefa do aprendizado de máquina (com um esboço de código) — a transferência de informações que o operador realmente vê.

4.1 Detecção de anomalias — vibração em um motor de bomba (fabricação)

A pergunta é: Esta bomba está prestes a falhar?

Entregue a série bruta a um LLM (Modelo de Aprendizado de Liderança) que executa um código e ele calculará médias, máximos e um desvio padrão preciso. Mas "prestes a falhar" não é um cálculo — é um desvio de um aprendido do comportamento normal dessa bomba, e o LLM nunca viu essa bomba.

A função do ML. Treinar um modelo de aprendizado de máquina — uma Floresta de Isolamento — com base em 90 dias de vibração RMS "normal" e temperatura do rolamento. Registrar novas leituras em tempo real.

from sklearn.ensemble import IsolationForest import numpy as np # X_normal: shape (n_samples, 2) — [vibration_rms, bearing_temp] clf = IsolationForest(contamination=0.01, random_state=42) clf.fit(X_normal) # Pontuações negativas = mais anômalas. O limite de -0,1 funciona para a maioria dos sensores industriais. scores = clf.score_samples(X_today) anomalies = X_today[scores < -0.1]

O modelo retorna uma pontuação por minuto. Ele não tem opinião sobre o que fazer com ela.

A função do LLM é a seguinte: quando uma pontuação ultrapassa o limite, o LLM consulta o histórico de ordens de serviço daquele ativo, verifica a data da última manutenção, consulta o estoque de peças e redige uma mensagem para o responsável pela manutenção.

A transição que o operador vê:

"A bomba P-103 ultrapassou o limite de anomalia às 02h14. A última manutenção dos rolamentos foi realizada há 7 meses — atrasada de acordo com o plano de manutenção semestral. Não há kit de rolamentos sobressalentes em estoque no local. Recomenda-se o envio de um técnico neste turno antes da operação da manhã."

O modelo de aprendizado de máquina gerou um número. O modelo de aprendizado de máquina o transformou em uma decisão. Esse padrão é a essência do que torna na manufatura inteligente realmente úteis no chão de fábrica.

4.2 Previsão — demanda de energia em um edifício (HVAC / instalações)

A pergunta é: “Quanta energia este edifício consumirá amanhã?” Um modelo de regressão logística (LLM) que executa o código fará uma regressão rápida com base nos dados inseridos e retornará um número preciso e confiável — sem se lembrar do consumo de energia inicial do seu edifício. Ele identifica padrões de consumo ,não os prevê. Isso não é especulação — um artigo da NeurIPS de 2024 descobriu que remover o LLM de métodos populares de previsão baseados em LLM não prejudica a precisão e, muitas vezes, a melhora.

Tarefa do ML. Incorporar variáveis ​​de atraso (hora do dia, dia da semana, atraso de 1 dia, atraso de 7 dias, previsão de temperatura) em um regressor XGBoost — ou Prophet, caso a manutenção seja feita por um profissional sem conhecimento em ML.

import xgboost as xgb from sklearn.model_selection import train_test_split # features: hour, dow, lag_1d, lag_7d, temp_forecast X_train, X_test, y_train, y_test = train_test_split(features, target, test_size=0.2) model = xgb.XGBRegressor(n_estimators=200, learning_rate=0.05) model.fit(X_train, y_train) tomorrow_forecast = model.predict(tomorrow_features)

A transferência de responsabilidade. O gerente de linha de crédito transforma o número em uma instrução: “Amanhã a temperatura estará 14% acima da média de uma quarta-feira, provavelmente devido à onda de calor prevista. Pré-resfrie o prédio das 3h às 5h da manhã para transferir a carga para horários fora do pico e evitar a taxa de demanda.”

4.3 Manutenção preditiva — vida útil restante (logística/mobilidade)

A pergunta: “Quais caminhões precisam ter o alternador substituído nos próximos 30 dias?” Esse é um modelo de sobrevivência ajustado a falhas históricas, além de sinais de degradação atuais — deriva de tensão, frequência de reinicialização, exposição ao calor — classificando ativos que ele nunca viu. Um LLM não consegue extrapolar isso.

from lifelines import CoxPHFitter import pandas as pd # df: uma linha por ativo, colunas = sinais de degradação + 'duração' + 'evento' (1 = falha) cph = CoxPHFitter() cph.fit(df, duration_col='duration', event_col='event') risk_scores = cph.predict_partial_hazard(current_fleet_signals) ranked_fleet = current_fleet_signals.assign(risk=risk_scores).sort_values('risk', ascending=False)

A transição. O LLM classifica os resultados do modelo em relação ao contexto de negócios desta semana — rotas críticas para a missão, quais depósitos têm a peça em estoque, quem está de plantão — e elabora as cinco principais ordens de serviço. Essa é a essência da IoT : a lista classificada por si só é ignorada; a classificação, juntamente com a justificativa, é o que gera a ação.

4.4 Classificação — alarmes de qualidade da água (serviços públicos/ambientais)

A pergunta é: “Essa combinação de pH/turbidez/condutividade é um alarme real ou ruído do sensor?” A maioria dos sistemas de monitoramento de infraestrutura hídrica ainda utiliza limiares fixos que disparam alarmes de três a cinco vezes mais do que o necessário; um classificador treinado com cerca de 10 mil leituras rotuladas reduz os falsos positivos em mais da metade. Solicitar a um sistema de classificação de aprendizado de máquina (LLM) que rotule manualmente todas as 50 mil leituras diárias não é consistente entre as execuções e custa muito mais do que um sistema que realiza a pontuação em milissegundos.

from xgboost import XGBClassifier # X: [pH, turbidity, conductivity, hour_of_day, sensor_age_days] # y: 1 = alarme real, 0 = ruído clf = XGBClassifier(n_estimators=100, use_label_encoder=False, eval_metric='logloss') clf.fit(X_train, y_train) p_alarm = clf.predict_proba(X_today)[:, 1]

A transferência. Quando P(alarme) > 0,7, o LLM obtém o contexto a montante — precipitação recente, manutenção próxima, sensores vizinhos — e decide: enviar uma amostra de campo, abrir um chamado ou fechar automaticamente como ruído.

4.5 Texto livre → estruturado — notas de turno do técnico (aquele em que o LLM vence de lavada)

A questão é: em meio a milhares de anotações técnicas não estruturadas escritas ao longo de dois anos, o que realmente está emergindo?

Por que o aprendizado de máquina perde aqui? Você precisaria de um conjunto de treinamento rotulado, que você não tem, e as categorias mudam com o tempo à medida que o equipamento envelhece e novos modos de falha aparecem. Um classificador supervisionado treinado há seis meses não detectará o novo modo de falha que começou a aparecer no último trimestre.

Tarefa do LLM. Classificação com zero ou poucos exemplos em uma lista de categorias estável — "falha elétrica", "desgaste mecânico", "perda de comunicação", "erro do usuário", "inconclusivo" — além da extração do ID do ativo, da gravidade e de quaisquer peças mencionadas.

import anthropic client = anthropic.Anthropic() def parse_note(note_text: str) -> dict: response = client.messages.create( model="claude-sonnet-4-6", max_tokens=256, messages=[{ "role": "user", "content": f"""Classifique esta nota técnica. Retorne apenas JSON. Nota: {note_text} Esquema: {{ "category": "electrical_fault|mechanical_wear|comms_loss|user_error|unclear", "severity": "low|medium|high", "asset_id": "string or null", "parts_mentioned": ["list of strings"] }}""" }] ) import json return json.loads(response.content[0].text)

Sem dados de treinamento. Sem sprint de rotulagem. Entregar esta semana.

A transferência de informações ocorre aqui na ordem inversa. O LLM gera os campos estruturados → o SQL simples (ou um modelo de aprendizado de máquina, se houver linhas suficientes) os agrega em um gráfico de Pareto de categorias de falhas por local, por classe de ativo e por trimestre.

Sendo sincero: se você já tem 100 mil notas rotuladas e uma taxonomia de categorias estável, ajuste um modelo pequeno — será mais rápido e mais barato por chamada. Caso contrário, o LLM é, sem dúvida, o ponto de partida ideal.

Mais duas quebram — por um motivo diferente

“Quais dos meus 400 sensores estão apresentando comportamento anormal neste momento?” O problema aqui não é a matemática — são 400 sensores e o “neste momento”. Não há como manter uma linha de base em tempo real para cada sensor em 400 fluxos de dados e comparar cada nova leitura com essa linha de base. Isso exige estado persistente, e o sistema de monitoramento contínuo de dados não o possui.

"Avise-me no momento em que esta leitura se desviar do normal." Um LLM é baseado em requisição-resposta. Ele não pode ficar aguardando em um fluxo MQTT e pontuar cada pacote no milissegundo em que um limite é atingido. Isso não é difícil, é arquiteturalmente impossível — nenhuma quantidade de execução de código muda isso.

O padrão arquitetônico

Juntando tudo, o diagrama é o mesmo, independentemente da vertical:

O LLM é o orquestrador. Os modelos de ML são ferramentas. O banco de dados também. O Slack também. Trate todos da mesma forma — como ferramentas que o LLM pode invocar — e a arquitetura permanece organizada, independentemente da quantidade de modelos ou fontes de dados adicionadas. Essa é a mesma arquitetura que está no cerne dos modernos baseados em nuvem SCADA e da Indústria 4.0 — a diferença é que a camada de raciocínio agora é um LLM em vez de um mecanismo de regras.

Uma coisa que este diagrama deixa óbvia: o LLM nunca acessa dados brutos. Ele trabalha com agregados, pontuações e resumos produzidos pelas ferramentas de aprendizado de máquina e de dados. Isso é intencional. Um LLM que raciocina sobre um resumo de 50 linhas é rápido, barato e confiável. Um LLM direcionado a 50.000 linhas brutas — mesmo um executando seu próprio código Python — é lento, caro e sem estado: ele recalcula tudo do zero a cada chamada, em vez de consultar um modelo que já aprendeu o padrão.

Antipadrões

1. Solicitar ao LLM que escreva SQL em tabelas grandes. O LLM consegue escrever SQL sem problemas. O problema é executar uma consulta complexa em 25 mil linhas e retornar tudo para a janela de contexto — lento, custoso e propenso a erros. Primeiro, agregue os dados com uma ferramenta de "visualização preparada" que reduza os dados brutos às 50 linhas relevantes e, em seguida, deixe o LLM analisar o resumo.

2. Incorporar regras de negócio ao modelo de aprendizado de máquina. Se o modelo for treinado para sinalizar uma leitura como um alarme com base nos seus limites de SLA atuais, cada alteração de limite exigirá um novo treinamento. Mantenha as regras de negócio na camada de prompts do LLM, onde a edição consiste em uma alteração de uma única linha, e não em um novo ciclo de treinamento.

3. Tratar uma demonstração como prova de conceito. A demonstração funcionou com 10 pontos limpos em um notebook. Em produção, há 10.000 pontos, registros de data e hora ausentes, leituras duplicadas e sensores que param de funcionar por três dias e retornam com valores desatualizados. Um pipeline treinado lida com isso; um prompt — mesmo com um sandbox de código — não, porque nunca aprendeu como é o seu sinal limpo.

Perguntas frequentes

Os LLMs não podem simplesmente executar Python agora? Então, por que eu preciso de aprendizado de máquina?
A execução de código resolve problemas de computação, não de aprendizado. E geralmente nem está em uso: por meio da API, é uma ferramenta opcional que a maioria das plataformas de agentes nunca implementa. Mesmo quando está, é um ambiente efêmero — não consegue treinar um modelo que generalize, manter o estado por fluxo ou pontuar em tempo real, e seu código novo, não fixado e não determinístico não é auditável da mesma forma que um número de produção. Um LLM pode calcular sobre os dados que você fornece; ele não pode ser o modelo.

Quando um agente de IA deve usar aprendizado de máquina (ML) em vez de um modelo de aprendizado de máquina (LLM)?
Sempre que a tarefa for "produzir um número". Previsão, pontuação de anomalias, classificação e estimativa de vida útil restante são todas tarefas de ML. Um LLM — mesmo com um ambiente de teste de código — pode calcular um valor pontual, mas não pode ser o modelo em si: ele não consegue aprender um padrão que se generalize, manter um estado ou ser executado em tempo real.

Um modelo de lógica latente (LLM) pode fazer previsões de séries temporais?
Em um sentido limitado, sim — para horizontes muito curtos em padrões simples, um LLM com uma chamada de ferramenta para um modelo estatístico pode parecer fazer previsões. Mas ele não está fazendo a previsão; está apenas chamando a ferramenta. Pedir a um LLM bruto para extrapolar uma sequência numérica a partir do contexto produzirá resultados aparentemente confiáveis, mas estatisticamente incorretos. Não faça isso em produção.

Um LLM consegue detectar anomalias?
Não de forma confiável. A detecção de anomalias requer um modelo aprendido de comportamento "normal" construído a partir de dados históricos — uma distribuição, uma linha de base, um limiar calibrado para o seu equipamento específico. Um LLM não possui esse modelo específico para o seu equipamento. Ele pode inferir uma pontuação de anomalia depois que um modelo de aprendizado de máquina a calcular.

Qual a diferença entre um agente de IA e um machine learning ?
Um modelo de aprendizado de máquina é uma função: recebe uma entrada estruturada e retorna um número ou um rótulo. Um agente de IA é um orquestrador: recebe um objetivo, decide quais ferramentas utilizar (incluindo modelos de aprendizado de máquina, bancos de dados, APIs, serviços de mensagens), interpreta os resultados e executa uma ação. O agente sem ferramentas de aprendizado de máquina é um chatbot. O modelo de aprendizado de máquina sem um agente é um dashboard que ninguém lê.

Preciso treinar novamente meu modelo de aprendizado de máquina quando as regras de negócio mudam?
Não — e este é um dos benefícios mais subestimados da arquitetura de duas camadas. Mantenha as regras de negócio (limiares, SLAs, lógica de escalonamento, políticas específicas do cliente) na camada de prompts do LLM. Elas são texto simples; alterá-las leva segundos. Reserve o treinamento para quando a distribuição de sinais subjacente mudar — novos equipamentos, novos modos de falha, novas condições operacionais.

O ajuste fino de um modelo de aprendizado de máquina (ML) substitui um modelo de aprendizado de máquina tradicional em tarefas numéricas?
Quase nunca. O ajuste fino ensina o ML a produzir texto que se pareça com a saída numérica correta. Não o ensina a computar. Para cargas de trabalho de produção onde a precisão numérica é importante — previsão, detecção de anomalias, classificação — um modelo scikit-learn bem ajustado com recursos limpos terá um desempenho superior a um ML ajustado, será executado mais rapidamente, custará menos e será mais fácil de auditar.

Mais uma coisa

Esse padrão — IA na IoT feita da maneira correta — aparece constantemente no que construímos na Ubidots. Nossa capacidade de Agentes de IA é o lado orquestrador do LLM nesse cenário, e UbiFunctiono é onde você integra seu próprio código Python — scikit-learn, XGBoost, pvlib, seu próprio modelo treinado — como uma ferramenta invocável. A arquitetura é a mesma do diagrama acima; nós apenas fornecemos o ambiente de execução e os dados do sensor já integrados — o ambiente persistente e auditável que um sandbox efêmero do LLM jamais será.