ML vs LLM: 5 indicaciones que rompen los LLM y cómo la llamada a herramientas de ML los soluciona

TL;DR

• Tu LLM ahora puede ejecutar Python, así que puede realizar cálculos. Sin embargo, aún no puede aprender un modelo que generalice, mantener el estado de cada flujo ni puntuar una transmisión en vivo. El cálculo nunca fue lo difícil.
• Los modelos de aprendizaje automático son precisos en tareas numéricas específicas, pero inútiles para decidir qué hacer con el resultado.
• Un agente de IA útil necesita ambos. A continuación: una matriz de decisión y cinco indicaciones que provocan fallos en un modelo LLM, cada una con la llamada a la herramienta de aprendizaje automático que lo soluciona.

¿Por qué los equipos siguen recurriendo a la herramienta equivocada?

La cuestión de ML frente a LLM surge más que casi cualquier otra en el ámbito de la IA aplicada, y en nueve de cada diez casos el problema no reside en los datos. El problema radica en que un equipo integró un LLM en una tarea que requiere ML, o bien creó un dashboard exclusivamente de ML que necesitaba un LLM para que resultara útil.

Es una trampa fácil. Las demostraciones de LLM son deslumbrantes: se describe un problema en lenguaje sencillo y se obtiene una respuesta coherente. Por lo tanto, el siguiente paso lógico es introducir datos de sensores en ese mismo modelo y pedirle que pronostique la carga del día siguiente, identifique la bomba defectuosa o clasifique las máquinas por riesgo. Funciona a la perfección, al menos en la demostración. Luego llega la producción con ruido, lagunas y desviaciones, y las respuestas supuestamente seguras resultan ser erróneas.

El fallo opuesto es igual de común y más silencioso: puntuaciones de aprendizaje automático precisas en un dashboard que nadie abre. El trabajo interesante se encuentra en la intersección de ambos, que es precisamente donde alguien se resiste:

Espera, ¿acaso los LLM no pueden ejecutar Python ahora?

Un desafío justo. Hace dos años, la respuesta a "¿por qué no preguntarle directamente al LLM?" era "no puede hacer los cálculos". Esa respuesta ya no es válida, y si este artículo aún se basara en ella, un ingeniero perspicaz cerraría la pestaña. Así que seamos precisos sobre qué cambió y qué no.

En una ventana de chat, sí. Tanto la herramienta de análisis de datos avanzados de ChatGPT como la de Claude escriben y ejecutan código Python en un entorno aislado. Sin embargo, ese entorno aislado reside en el producto que envuelve el modelo, no en el modelo en sí.

A través de la API, solo si la conectas. La API es la capa sobre la que se construyen prácticamente todos IoT , y la ejecución de código es opcional. El intérprete de código de OpenAI es una herramienta que se pasa en el de herramientas y se devuelve con un contenedor aprovisionado (aproximadamente$de Anthropic code_execution en la API de mensajes está en fase beta y desactivada por defecto. Llama al endpoint simple con una solicitud y obtendrás tokens, no ejecución.

Dentro de un agente de producción, la forma es incorrecta de todos modos. Incluso habilitado, lo que se obtiene es un entorno de pruebas efímero: se inicia, devuelve un resultado y se elimina. Es una calculadora, no un lugar para entrenar un modelo, mantener una línea base por sensor o ver una transmisión en vivo. Y se ejecuta a ciegas: el código se escribe nuevo en cada llamada, importa lo que esté en la imagen del entorno de pruebas y, a menos que se cree la infraestructura para capturarlo, se ejecuta sin un rastro revisado y reproducible. Para un número que envía a un técnico o activa una alarma de seguridad, "el LLM escribió algo de Python que nunca revisamos" es motivo suficiente para descartarlo.

Así pues, la regla honesta no es que «los modelos de lógica difusa no puedan computar». Es esta: la ejecución de código permite que un modelo de lógica difusa computa; no le permite aprender un modelo que generalice, mantener el estado a través de cientos de flujos de datos ni puntuar un flujo en tiempo real. Ese es el límite, y es precisamente el límite que cruzan las cinco preguntas que aparecen a continuación.

La verdadera línea divisoria: computar versus aprender

El aprendizaje automático aprende un modelo que generaliza; el aprendizaje por lenguaje natural razona sobre el resultado en lenguaje. La ejecución del código permite que el aprendizaje por lenguaje natural calcule, pero no le permite aprender.

ML para inferencia, LLM para razonamiento.

ML es la herramienta adecuada cuando la pregunta es "¿cuál es el número?" — una predicción, una puntuación de anomalía, una estimación de la vida útil restante, una etiqueta de clase. LLM es la herramienta adecuada cuando la pregunta es "¿qué debemos hacer con el número?" — explicarlo, priorizarlo, redactar el mensaje, decidir el siguiente paso, usar la herramienta adecuada.

Tres comprobaciones rápidas de cordura:

• ¿Puede un modelo LLM pronosticar una serie temporal? A veces, y mal. No para cargas de trabajo de producción, donde equivocarse cuesta dinero.
• ¿Puede un modelo de aprendizaje automático escribir un ticket de mantenimiento? No. Devuelve un número. El significado de ese número en contexto es un problema de lenguaje.
• ¿Necesito ambos? Para cualquier flujo de trabajo en el que intervenga un ser humano, sí.

La matriz de decisión

Esta es la tabla comparativa entre ML y LLM que redibujamos constantemente en pizarras blancas para proyectos de IoT e industriales: cuándo usar machine learningtradicional, cuándo usar un LLM y cuándo usar ambos. Guárdala en tus favoritos.

Si tu tarea se encuentra en una fila de la columna izquierda y estás buscando la herramienta equivocada en la columna central, este artículo es para ti.

Cinco preguntas que ponen en riesgo los programas de maestría en derecho (LLM)

Todos los ejemplos siguen la misma estructura: el mensaje que falla — por qué ejecutar Python no lo soluciona — la tarea del aprendizaje automático (con un esbozo de código) — la transferencia que ve realmente el operador.

4.1 Detección de anomalías: vibración en un motor de bomba (fabricación)

La pregunta es: ¿Está a punto de fallar esta bomba?

Si se le entrega la serie de datos sin procesar a un modelo LLM que ejecuta código, este calculará las medias, los máximos y una desviación estándar precisa. Pero "a punto de fallar" no es un cálculo, sino una desviación del aprendido de la normalidad de esta bomba, y el modelo LLM nunca ha visto esta bomba.

La función del aprendizaje automático: entrenar un modelo de aprendizaje automático (un bosque de aislamiento) con datos de 90 días de valores RMS de vibración y temperatura de rodamientos "normales". Registrar nuevas lecturas en tiempo real.

from sklearn.ensemble import IsolationForest import numpy as np # X_normal: forma (n_muestras, 2) — [vibración_rms, temperatura_rodamiento] clf = IsolationForest(contaminación=0.01, estado_aleatorio=42) clf.fit(X_normal) # Las puntuaciones negativas son más anómalas. El umbral de -0.1 funciona para la mayoría de los sensores industriales. puntuaciones = clf.score_samples(X_today) anomalías = X_today[puntuaciones < -0.1]

El modelo devuelve una puntuación por minuto. No tiene ninguna opinión sobre qué hacer con ella.

La función del LLM. Cuando una puntuación supera el umbral, el LLM recupera el historial de órdenes de trabajo de ese activo, verifica la fecha del último servicio, consulta el inventario de piezas y redacta un mensaje para el responsable de mantenimiento.

La transferencia que ve el operador:

La bomba P-103 superó su umbral de anomalía a las 02:14. El último mantenimiento de los rodamientos se realizó hace 7 meses, lo cual está vencido según el plan de mantenimiento semestral. No hay un kit de rodamientos de repuesto en el inventario. Se recomienda enviar un técnico este turno antes de la operación matutina

El modelo de aprendizaje automático generó un número. El modelo de aprendizaje automático lo convirtió en una decisión. Este patrón es la clave para que en la fabricación inteligente sean realmente útiles en la planta de producción.

4.2 Previsión: demanda energética en un edificio (climatización/instalaciones)

La pregunta es: "¿Cuánta energía consumirá este edificio mañana?". Un modelo lineal general (MLG) ejecuta un código que ajusta rápidamente una regresión a los datos que se introducen y devuelve un valor preciso y fiable, sin tener en cuenta el consumo base del edificio. Se basa en la coincidencia de patrones de consumo ,no en su predicción. Esto no es una mera especulación: un artículo de NeurIPS de 2024 reveló que eliminar el MLG de los métodos de predicción más populares no perjudicaba la precisión y, a menudo, la mejoraba.

El trabajo del aprendizaje automático consiste en incorporar características rezagadas (hora del día, día de la semana, retraso de 1 día, retraso de 7 días, pronóstico de temperatura) a un regresor XGBoost, o a Prophet si un ingeniero que no sea experto en aprendizaje automático tiene que mantenerlo.

import xgboost as xgb from sklearn.model_selection import train_test_split # características: hora, dow, lag_1d, lag_7d, pronóstico_temperatura 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)

El traspaso. El LLM convierte la cifra en una instrucción: «Mañana la temperatura será un 14 % superior a la de un miércoles típico, probablemente debido a la ola de calor prevista. Preenfríe el edificio entre las 3 y las 5 de la mañana para desplazar la carga fuera de las horas punta y evitar el cargo por demanda».

4.3 Mantenimiento predictivo: vida útil restante (logística/movilidad)

La pregunta es: "¿Qué camiones necesitan que se les cambie el alternador en los próximos 30 días?". Se trata de un modelo de supervivencia que considera fallos históricos y señales de degradación actuales (deriva de voltaje, frecuencia de reinicio, exposición al calor), clasificando activos que nunca antes había visto. Un modelo LLM no puede extrapolar eso.

from lifelines import CoxPHFitter import pandas as pd # df: una fila por activo, columnas = señales de degradación + 'duración' + 'evento' (1 = fallido) 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)

La transferencia. El LLM clasifica los resultados del modelo en función del contexto empresarial de esta semana (rutas críticas, almacenes que almacenan la pieza, personal de turno) y elabora las cinco órdenes de trabajo principales. Esa es la esencia del IoT : la lista de prioridades por sí sola se ignora; la clasificación, junto con el razonamiento, se pone en práctica.

4.4 Clasificación — alarmas de calidad del agua (servicios públicos / medio ambiente)

La pregunta es: "¿Esta combinación de pH, turbidez y conductividad es una alarma real o ruido del sensor?". La mayoría de los sistemas de monitoreo de infraestructura hídrica aún utilizan umbrales fijos que generan una sobreestimación de tres a cinco veces; un clasificador entrenado con aproximadamente 10 000 lecturas etiquetadas reduce a menos de la mitad los falsos positivos. En cambio, solicitar a un LLM que etiquete manualmente las 50 000 lecturas diarias no garantiza la consistencia entre ejecuciones y cuesta mucho más que un procesamiento por lotes que procesa la información en milisegundos.

from xgboost import XGBClassifier # X: [pH, turbidez, conductividad, hora_del_día, días_de_antigüedad_del_sensor] # y: 1 = alarma real, 0 = ruido 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]

El traspaso. Cuando P(alarma) > 0,7, el LLM obtiene el contexto anterior (lluvias recientes, mantenimiento cercano, sensores vecinos) y decide: enviar una muestra de campo, abrir un ticket o cerrarlo automáticamente como ruido.

4.5 Texto libre → estructurado — notas de turno del técnico (aquel en el que LLM gana rotundamente)

La pregunta es: entre miles de notas técnicas no estructuradas escritas a lo largo de dos años, ¿qué es lo que realmente está sucediendo?

¿Por qué falla el aprendizaje automático en este caso? Necesitarías un conjunto de entrenamiento etiquetado que no tienes, y las categorías cambian con el tiempo a medida que el equipo envejece y aparecen nuevos modos de fallo. Un clasificador supervisado entrenado hace seis meses no detectará el nuevo modo de fallo que empezó a aparecer el trimestre pasado.

El trabajo de LLM. Clasificación de cero o pocos disparos en una lista de categorías estables — "falla eléctrica", "desgaste mecánico", "pérdida de comunicaciones", "error del usuario", "no claro" — además de la extracción de la identificación del activo, la gravedad y cualquier pieza mencionada.

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"""Clasifique esta nota del técnico. Devuelva solo 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)

Sin datos de entrenamiento. Sin sprint de etiquetado. ¡Lánzalo esta semana!.

Aquí, la transferencia se realiza a la inversa. El LLM produce los campos estructurados → SQL simple (o un modelo de aprendizaje automático, si hay suficientes filas) los agrega en un diagrama de Pareto de categorías de fallas por sitio, por clase de activo y por trimestre.

Verificación de la honestidad: si ya tienes 100 000 notas etiquetadas y una taxonomía de categorías estable, ajusta un modelo pequeño; será más rápido y económico por llamada. Si no, el modelo LLM es sin duda el punto de partida adecuado.

Dos más que se rompen, por una razón diferente

“¿Cuáles de mis 400 sensores se están comportando de forma anómala ahora mismo?” El problema no radica en las matemáticas, sino en que son 400 y que se trata de un momento específico. En un LLM no existe ningún mecanismo para mantener una línea base en tiempo real para cada sensor, abarcando 400 flujos de datos, y comparar cada nueva lectura con ella. Eso requiere un estado persistente, y el LLM carece de él.

«Avísame en el momento en que esta lectura se desvíe de lo normal». Un LLM es de solicitud-respuesta. No puede estar en una transmisión MQTT y analizar cada paquete en el milisegundo en que se activa un umbral. Esto no es difícil, es arquitectónicamente imposible; ninguna cantidad de ejecución de código lo cambia.

El patrón arquitectónico

Si lo juntamos todo, el diagrama es el mismo independientemente de la verticalidad:

El LLM es el orquestador. Los modelos de aprendizaje automático son herramientas. Lo mismo ocurre con la base de datos y con Slack. Si se tratan todos de la misma manera —como herramientas invocables que el LLM puede ejecutar—, la arquitectura se mantiene limpia independientemente de la cantidad de modelos o fuentes de datos que se añadan. Esta es la misma arquitectura que sustenta los basados ​​en la nube SCADA y los sistemas de la Industria 4.0 ; la diferencia radica en que la capa de razonamiento ahora es un LLM en lugar de un motor de reglas.

Un aspecto que este diagrama deja claro es que el modelo de aprendizaje profundo (LLM) nunca procesa datos sin procesar. Trabaja con agregados, puntuaciones y resúmenes generados por las herramientas de aprendizaje automático y de datos. Esto es intencional. Un LLM que procesa un resumen de 50 filas es rápido, económico y fiable. Un LLM que procesa 50 000 filas sin procesar —incluso uno que ejecuta su propio Python— es lento, costoso y carece de estado: recalcula desde cero en cada llamada en lugar de consultar un modelo que ya ha aprendido el patrón.

Antipatrones

1. Solicitar al LLM que escriba SQL en tablas grandes. El LLM puede escribir SQL sin problemas. El problema radica en ejecutar una consulta compleja sobre 25 000 filas y devolverlas todas a la ventana de contexto: lento, costoso y propenso a errores. Primero, agregue los datos con una herramienta de "vista preparada" que los condense en las 50 filas relevantes, y luego deje que el LLM procese el resumen.

2. Integrar las reglas de negocio en el modelo de aprendizaje automático. Si el modelo está entrenado para marcar una lectura como alarma según los umbrales de SLA actuales, cada cambio de umbral obliga a volver a entrenarlo. Mantenga las reglas de negocio en la capa de avisos de LLM, donde la edición es un cambio de una sola línea, no un ciclo de reentrenamiento.

3. Tratar una demostración como una prueba de concepto. La demostración funcionó con 10 puntos limpios en un cuaderno. En producción hay 10 000 puntos, marcas de tiempo faltantes, lecturas duplicadas y sensores que fallan durante tres días y regresan con valores obsoletos. Un pipeline entrenado maneja eso; una solicitud, incluso una con un entorno de pruebas de código, no lo hace, porque nunca aprendió cómo es una señal limpia.

Preguntas frecuentes

¿Acaso los LLM no pueden simplemente ejecutar Python ahora? Entonces, ¿por qué necesito ML?
La ejecución de código corrige el cálculo, no el aprendizaje. Y, por lo general, ni siquiera está presente: a través de la API, es una herramienta opcional que la mayoría de las plataformas de agentes nunca integran. Incluso cuando lo está, es un entorno de pruebas efímero: no puede entrenar un modelo que generalice, mantener el estado por flujo ni puntuar en tiempo real, y su código nuevo, no fijo y no determinista no es auditable como debe ser un código de producción. Un LLM puede calcular sobre los datos que se le proporcionan; no puede ser el modelo en sí.

¿Cuándo debería un agente de IA usar ML en lugar de un LLM?
Siempre que la tarea sea "producir un número". La predicción, la puntuación de anomalías, la clasificación y la estimación de la vida útil restante son tareas de ML. Un LLM, incluso con un entorno de prueba, puede calcular un valor puntual, pero no puede ser el modelo: no puede aprender un patrón que se generalice, mantener el estado ni ejecutarse en tiempo real.

¿Puede un modelo lineal generalizado (MLG) realizar pronósticos de series temporales?
En cierto modo, sí: para horizontes temporales muy cortos y patrones sencillos, un MLG que utiliza una herramienta de análisis estadístico puede aparentar realizar un pronóstico. Sin embargo, no realiza el pronóstico; simplemente utiliza la herramienta. Solicitar a un MLG sin procesar que extrapole una secuencia numérica a partir de su contexto producirá resultados estadísticamente erróneos, aunque parezcan fiables. No lo haga en entornos de producción.

¿Puede un modelo de aprendizaje automático detectar anomalías?
No de forma fiable. La detección de anomalías requiere un modelo aprendido del comportamiento "normal" construido a partir de datos históricos: una distribución, una línea base, un umbral calibrado para su equipo específico. Un modelo de aprendizaje automático no dispone de un modelo de este tipo para su equipo específico. Puede inferir una puntuación de anomalía una vez que un modelo de aprendizaje automático la haya calculado.

¿Cuál es la diferencia entre un agente de IA y un machine learning ?
Un modelo de ML es una función: recibe datos estructurados y devuelve un número o una etiqueta. Un agente de IA es un orquestador: recibe un objetivo, decide qué herramientas utilizar (incluidos modelos de ML, bases de datos, API y servicios de mensajería), interpreta los resultados y actúa en consecuencia. El agente sin herramientas de ML es un chatbot. El modelo de ML sin un agente es un dashboard que nadie consulta.

¿Necesito reentrenar mi modelo de aprendizaje automático cuando cambian las reglas de negocio?
No, y este es uno de los beneficios menos valorados de la arquitectura de dos capas. Mantenga las reglas de negocio (umbrales, acuerdos de nivel de servicio, lógica de escalamiento, políticas específicas del cliente) en la capa de mensajes del modelo de aprendizaje automático. Son texto plano; modificarlas lleva solo unos segundos. Reserve el reentrenamiento para cuando cambie la distribución de la señal subyacente: nuevos equipos, nuevos modos de fallo, nuevas condiciones de funcionamiento.

¿Es el ajuste fino de un modelo LLM un sustituto de un modelo ML para tareas numéricas?
Casi nunca. El ajuste fino enseña al modelo LLM a producir texto que se parezca al resultado numérico correcto. No le enseña a calcular. Para cargas de trabajo de producción donde la precisión numérica es importante (pronóstico, puntuación de anomalías, clasificación), un modelo scikit-learn bien ajustado con características limpias superará a un modelo LLM ajustado, se ejecutará más rápido, costará menos y será más fácil de auditar.

Una cosa más

Este patrón —IA en IoT bien implementada— se repite constantemente en Ubidots. Nuestra capacidad de Agentes de IA representa el lado orquestador de LLM en este panorama, y UbiFunctiones donde integras tu propio código Python —scikit-learn, XGBoost, pvlib, tu propio modelo entrenado— como una herramienta ejecutable. La arquitectura es la misma que la del diagrama anterior; simplemente te proporcionamos el entorno de ejecución y los datos del sensor ya integrados: el entorno persistente y auditable que un entorno aislado de LLM efímero jamás podrá ofrecer.