ML clásico vs LLMs: cuándo NO usar IA generativa (y ahorrar hasta 10x en costos)

En los últimos dos años hemos visto una tendencia preocupante: equipos técnicos que, fascinados con las capacidades de GPT, Claude o Gemini, intentan resolver con un LLM problemas que tienen una solución mucho más simple, barata y precisa con modelos clásicos de machine learning. La pregunta correcta no es "¿qué LLM usar?" sino "¿necesitas un LLM?".

Este artículo es un recordatorio honesto: para una buena parte de los casos de uso empresariales en México, un XGBoost bien entrenado, una regresión logística o un modelo de árboles sigue siendo la opción superior. Y la diferencia en costo operativo no es marginal: hablamos de uno o dos órdenes de magnitud.

El cuadro que importa

Empecemos por la comparación que nadie publica con claridad. Para un caso típico de clasificación con 100,000 inferencias diarias:

• XGBoost en una API propia: USD 30 a 80 al mes en compute, latencia de 5 a 20 ms por inferencia, predicciones perfectamente reproducibles.
• LLM vía API (GPT-4o, Claude Sonnet): USD 800 a 3,000 al mes, latencia de 800 a 3,000 ms, respuestas que pueden variar entre llamadas idénticas.

La diferencia es real. Y no incluye el trabajo extra de prompt engineering, validación de salidas, parsing de respuestas y manejo de fallos que un LLM siempre arrastra.

Cuándo gana ML clásico

ML clásico (XGBoost, regresión logística, random forest, kNN, gradient boosting, redes neuronales pequeñas) sigue siendo la opción superior cuando se cumplen estas condiciones:

• Datos tabulares con features bien definidas. Edad, ingreso, historial de pagos, geolocalización, categoría de producto. Si tu input cabe en un CSV ordenado, hay buenas probabilidades de que un modelo clásico te dé mejor resultado.
• Variable objetivo clara y verificable. Pagó o no pagó, fraude o no fraude, comprará o no comprará, churn en 30 días sí o no.
• Alto volumen de inferencias. Cuando procesas millones de transacciones, el costo por predicción importa.
• Latencia crítica. Sistemas de fraude en línea, recomendadores en checkout, pricing dinámico. Un LLM con latencia de segundo no es opción.
• Necesidad de explicabilidad. Para regulación financiera y crediticia, SHAP values sobre un XGBoost explican una decisión. Un LLM no.
• Datos históricos abundantes. Si tienes años de transacciones etiquetadas, un modelo clásico va a aprender mejor de ellos que cualquier LLM con few-shot.

Casos típicos donde recomendamos sin dudar ML clásico:

• Detección de fraude transaccional.
• Scoring de crédito y propensión a default.
• Segmentación de clientes (churn, valor, frecuencia).
• Recomendaciones basadas en comportamiento.
• Predicción de demanda y forecasting.
• Pricing dinámico.
• Mantenimiento predictivo en industria.
• Clasificación de imágenes con categorías cerradas (defectos en línea de producción, clasificación de productos).

Cuándo gana LLM

Los LLMs son superiores, y a veces insustituibles, cuando:

• El input es lenguaje natural no estructurado. Correos, conversaciones, documentos legales, comentarios libres.
• La tarea requiere comprensión contextual y matiz. Análisis de sentimiento sutil, detección de intención, resúmenes ejecutivos, traducción.
• Hay alta variabilidad en los inputs. No puedes definir features de antemano porque cada caso es distinto.
• El volumen es bajo o medio. Cientos o miles de inferencias al día, no millones.
• No hay datos etiquetados suficientes para entrenar un modelo clásico decente.
• La salida es texto generativo. Respuestas, redacciones, código, traducciones.

Casos donde tiene sentido usar LLM:

• Extracción de datos de contratos o facturas no estandarizadas.
• Atención a clientes vía chat con consultas variables.
• Resúmenes de llamadas o reuniones.
• Generación de respuestas a correos.
• Análisis cualitativo de feedback abierto.
• Code assistants y generación de queries SQL.
• Clasificación con muy pocas etiquetas o categorías cambiantes.

La trampa más común que vemos

El error que se repite: equipos que tienen 50,000 transacciones etiquetadas como fraude o no fraude, y deciden mandar cada nueva transacción a GPT-4 con un prompt tipo "evalúa si esta transacción es sospechosa, considera estos factores...". Costo mensual: USD 4,000. Performance: peor que un XGBoost de fin de semana entrenado por un becario con scikit-learn. Latencia: 30 veces mayor.

El otro lado de la moneda también pasa: equipos que insisten en construir un modelo clásico para extraer datos de PDFs heterogéneos. Pasan tres meses con OCR, regex, reglas, y obtienen 78% de precisión. Un LLM con un prompt razonable habría llegado a 94% en una tarde.

La solución no es elegir un bando. Es diseñar arquitecturas híbridas donde cada componente usa la herramienta correcta para su tarea.

Cinco preguntas para decidir

Cuando un cliente nos plantea un caso, aplicamos esta heurística simple. Si la mayoría de respuestas se inclinan hacia ML clásico, esa es la ruta. Si se inclinan hacia LLM, ese es el camino. Si están mezcladas, conviene una arquitectura híbrida.

1. ¿Mi input es estructurado (campos definidos) o no estructurado (texto libre)? Estructurado tiende a ML clásico. Libre tiende a LLM.
2. ¿Cuántas inferencias necesito al día? Más de 50,000: gana ML clásico por costo. Menos de 5,000: el costo de un LLM es manejable.
3. ¿Tengo datos etiquetados históricos? Si sí, abundantes y de calidad: ML clásico. Si no: LLM o un proceso híbrido para empezar.
4. ¿Necesito explicar la decisión a un regulador o cliente? Si sí: ML clásico con SHAP/LIME. LLMs son cajas negras peores que muchos clásicos.
5. ¿La latencia importa más de 200 ms? Si sí: ML clásico. LLMs por API casi nunca bajan de 500 ms.

Arquitectura híbrida: lo mejor de ambos mundos

En la mayoría de proyectos serios que vemos, la solución no es uno u otro. Es un LLM en la capa de entrada para normalizar inputs no estructurados y un modelo clásico en la capa de decisión para hacer la predicción rápida y barata.

Ejemplo real: un proceso de validación de solicitudes de crédito. El LLM lee el documento PDF del solicitante, extrae los campos relevantes (ingresos, historial, garantías) y los pasa estructurados a un XGBoost que decide aprobación. El LLM se llama una vez por solicitud, el XGBoost responde en milisegundos. Costo total controlado, performance alta, decisión explicable.

Esa arquitectura es la que recomendamos por defecto cuando hay componentes de texto en el flujo.

La pregunta detrás de la pregunta

Cuando un cliente nos pide "queremos meter IA generativa en X proceso", la conversación honesta empieza con: ¿qué queremos lograr y cuál es la mejor herramienta para lograrlo? La IA generativa es poderosa, pero no es la única forma de IA. Y en muchos casos, la mejor forma de hacer un proyecto sostenible y rentable es elegir la herramienta menos llamativa pero más adecuada. Eso es ingeniería, no nostalgia.

---

Agenda 30 min para evaluar tu caso (gratis). Conversemos sobre tu caso específico y te decimos con honestidad si lo que necesitas es un LLM, un modelo clásico o una arquitectura híbrida. Sin agenda comercial.