El Machine Learning clásico está viviendo un momento de redención que pocos esperaban. 😄
Con el boom de los AI Agents, mucha gente asumió que el trabajo del día a día en esta área sería básicamente escribir prompts, ajustar instrucciones y cruzar los dedos para que el LLM hiciera magia. La narrativa popular decía que los grandes modelos de lenguaje habían vuelto obsoleto todo lo que vino antes de ellos, incluyendo años de conocimiento acumulado en algoritmos, features y pipelines de datos. Parecía que el futuro sería solo un gran modelo conversando con el mundo.
Pero quienes están en la práctica construyendo plataformas agénticas de verdad saben que la historia es muy diferente. El día a día de quien trabaja con sistemas agénticos sofisticados implica mucho más que ajustar el comportamiento de un LLM. Existe toda una capa de lógica, decisión y filtrado que necesita construirse con cuidado, y es justo ahí donde el Machine Learning clásico entra en escena con toda su fuerza.
Hay un texto que circuló recientemente en Towards Data Science que resume bien este giro. Una ingeniera que trabaja con una plataforma de IA agéntica sofisticada contó que pasa buena parte de su tiempo construyendo clasificadores con CatBoost y ajustando isolation forests, y no haciendo prompt engineering como uno podría imaginar. Según ella, colegas a veces se sorprenden cuando escuchan que todavía construye ese tipo de modelo en medio de un stack tan moderno. Esto no es un caso aislado, es un patrón que se está repitiendo en equipos de ingeniería alrededor del mundo, donde la complejidad real de los sistemas agénticos exige una combinación de enfoques, y no una sustitución total de uno por otro.
Esto plantea una cuestión muy interesante: si los AI Agents dependen tanto de herramientas para funcionar, ¿por qué no darles modelos clásicos de ML como herramientas poderosas? La respuesta corta es que tiene todo el sentido, y la respuesta larga es exactamente lo que vamos a explorar aquí, desde lo que define a un AI Agent hasta los dos principales enfoques arquitectónicos para conectar tus modelos al agente, pasando por las razones concretas que hacen que el ML clásico siga siendo indispensable. 🚀
¿Qué es un AI Agent, al fin y al cabo?
Antes de entrar en las arquitecturas y las combinaciones técnicas, vale la pena alinear el concepto. Un AI Agent significa combinar LLMs y otras herramientas de software para crear flujos de trabajo con poca o ninguna intervención humana, orquestando cualquier número de modelos o herramientas. No es simplemente un chatbot con memoria o un asistente virtual con acceso a internet, es un sistema que percibe el contexto, decide qué hacer y ejecuta acciones para alcanzar un objetivo.
Reciba el mejor contenido sobre innovación en su correo electrónico.
Todas las noticias, consejos, tendencias y recursos que buscas, directamente en tu bandeja de entrada.
Al suscribirte al boletín informativo, aceptas recibir comunicaciones de Método Viral. Nos comprometemos a proteger y respetar siempre tu privacidad.
Los LLMs, como GPT, Claude o Gemini, funcionan como la interfaz central de muchos de estos agentes modernos. Son los responsables de traducir prompts humanos al lenguaje de la máquina, interpretar los resultados que las herramientas devuelven y decidir qué herramienta accionar en cada momento. Pero aquí está el punto crucial: el LLM solo no ejecuta nada por su cuenta. Como siempre reforzamos, un LLM es apenas un modelo generador de tokens, prediciendo la siguiente palabra o frase de un texto con base en el contexto que recibió. Necesita herramientas para interactuar con el mundo real, y esas herramientas pueden ser llamadas a API, scripts, búsquedas en bases de datos y, cada vez más, modelos de Machine Learning clásico encapsulados como funciones accesibles para el agente.
Esta arquitectura basada en herramientas es lo que transforma un LLM en un agente funcional. Y vale recordar que incluso los chatbots que usamos a diario, como ChatGPT, Gemini y Claude, dependen de este tipo de encadenamiento, combinando la interfaz del LLM con recuperación de datos, búsqueda en la web, calculadoras matemáticas y otros recursos. El modelo de lenguaje no necesita saber hacer todo por su cuenta, necesita saber cuándo llamar a quién. Esto abre espacio para una división de responsabilidades mucho más eficiente, donde cada componente del sistema hace lo que mejor sabe hacer, y el LLM orquesta esa sinfonía con base en lenguaje natural y razonamiento contextual.
Por qué darle modelos clásicos de ML a tu agente
Un aspecto central de todo el ecosistema de IA agéntica es el Tooling. Tu agente necesita tener acceso a herramientas para poder completar tareas que van más allá de las funciones básicas del LLM. Muchas de esas herramientas hoy, en el entorno corporativo, son de recuperación y organización de datos, bases de grafos, bases de conocimiento RAG, construcción y validación de consultas, y así sucesivamente. Pero existe una categoría de herramienta que mucha gente olvida: los propios Classical Models.
Piensa en un agente diseñado para análisis inmobiliario. Si quieres descubrir el precio justo de mercado de un inmueble, basta con darle la dirección al agente. Él puede usar una herramienta de recuperación vía API para buscar detalles de la propiedad y después pasar esos datos formateados a un modelo de regresión que genera una estimación de precio. Podrías, en teoría, pedirle al LLM que estime el valor por sí solo. Pero eso es cuestionable e incluso riesgoso por varias razones.
- Precisión de los números: un LLM es particularmente malo en cualquier tarea que requiera calcular un número significativo, porque está adivinando, y no haciendo un cálculo basado en evidencias empíricas. Un modelo clásico bien entrenado será mucho más preciso y confiable.
- Interpretabilidad: con el LLM adivinando, tienes muy poca explicabilidad. Sabemos que los LLMs tienden a ser una caja negra, lo que limita mucho la capacidad de evaluar el camino hasta la estimación. Con un modelo clásico, identificas las decisiones tomadas y las validas contra el conocimiento de especialistas.
- Costo: ejecutar un LLM se vuelve caro muy rápido por la cantidad de tokens. Si tienes muchos casos que procesar, los precios se convierten en un problema real. En cambio, ejecutar un clasificador o una regresión es increíblemente ligero y barato, incluso en altos volúmenes.
- Control y ajuste fino: no controlas el entrenamiento ni el tuning del LLM, a menos que hagas fine tuning de un modelo fundacional, lo que exige muchos más datos y habilidades especializadas, y aún así deja problemas de interpretabilidad.
- Control de tus datos: tus datos pueden estar saliendo del entorno controlado y siendo accedidos por un proveedor tercero de LLM, lo que genera riesgo.
- Control de la infraestructura: con un LLM, no tienes autoridad sobre la gestión de infraestructura, así que una caída del proveedor tercero crea riesgo para tu negocio.
Claro que construir un modelo clásico requiere habilidades diferentes a simplemente soltar un LLM en una tarea. Necesitas entender bien tus datos, estar preparado para hacer ingeniería de features con conocimiento de dominio, y tener computación y datos suficientes para entrenar el modelo. Si no tienes datos etiquetados, estarás limitado al aprendizaje no supervisado o tendrás que crear tus propias etiquetas. Afortunadamente, existe mucho material disponible sobre cómo construir estos modelos, evaluarlos con rigor y monitorearlos después del despliegue.
Cómo conectar tu modelo al agente
¿Convencido de probar esta idea? Antes de empezar, hay algunas decisiones de arquitectura que considerar. ¿Cómo van a interactuar tu modelo y tu agente? Existen básicamente dos enfoques principales.
Llamadas directas
Quizás la forma más rápida de poner todo a funcionar sea dejar que el agente tenga el modelo como una herramienta que llama directamente. Es la forma del ejemplo del análisis inmobiliario: el agente acciona el modelo para una inferencia bajo demanda con base en un prompt. Para que esto funcione, tu agente necesita estar preparado para formatear correctamente las solicitudes al modelo clásico. Necesita entender para qué sirve ese modelo, cuándo llamarlo y cuándo usar otra cosa. Esto significa documentar claramente el propósito y las capacidades del modelo, pero si ya construyes IA agéntica, esta es una tarea familiar.
Del lado de la salida, la respuesta del modelo necesita estar estructurada de forma que el agente pueda procesarla bien. Simplemente devolver un resultado numérico puede no resolver, porque el agente va a necesitar información contextual para interpretar aquello y usarlo de la mejor manera. Una buena práctica es usar f-strings para armar descripciones en texto como parte de la inferencia, indicando, por ejemplo, cuáles fueron las features más importantes del modelo, cuál es la probabilidad del resultado y así sucesivamente. Devolver solo una probabilidad limita la capacidad del agente de interpretar la salida y producir una respuesta útil para el usuario final.
Acceso vía base de datos
Otra opción es hacer que el modelo no sea una herramienta directa del agente, sino un proveedor de datos de contexto. Puedes precalcular las inferencias ejecutando tu modelo clásico como un job programado y almacenar esos resultados en la solución de almacenamiento a la que el agente tiene acceso. En vez de que el agente haga una llamada inicial de inferencia directo a una API de modelo, escribe una consulta y la pasa a la base de datos.
Si tienes un conjunto finito de casos para los cuales podrías necesitar la inferencia, esta es una buena solución. Por ejemplo, si tienes 500 individuos en la base de datos y el agente necesita recuperar información de salud financiera sobre ellos, puedes usar un modelo de credit scoring y precalcular la capacidad crediticia de cada uno, dejándolo listo para que el agente lo consulte en tiempo de ejecución junto con los demás datos. Dependiendo de tu infraestructura, esto puede reducir latencia y repetición, funcionando como un caché de resultados.
Este enfoque crea requisitos diferentes para la llamada y la recuperación en relación con la llamada directa de herramienta. Si precalculas las inferencias y las pones a disposición vía base de datos, el agente necesita saber que esos resultados existen. Si no está al tanto de la tabla o del contenido disponible, no los usará cuando sea apropiado. Quizás ya tengas la infraestructura para informar al agente lo que la base contiene en tu prompt engineering, lo que ahorra esfuerzo. Sobre el formato de los resultados, los requisitos son parecidos a los de la llamada directa: tener una descripción en texto es una buena elección, porque el agente necesita interpretar lo que recupera, independientemente del origen.
Tooling: el pegamento que une todo esto
Hablar de integración entre AI Agents, LLMs y Classical Models sin hablar de Tooling es como hablar de construcción sin mencionar las herramientas de la obra. El ecosistema de herramientas disponible hoy para ingenieros que trabajan con sistemas agénticos ha evolucionado mucho en los últimos años, y parte de esa evolución fue justamente en dirección a facilitar la integración de modelos heterogéneos dentro de un mismo pipeline. Frameworks modernos ya ofrecen abstracciones que permiten registrar cualquier función como una herramienta disponible para el agente, lo que significa que un modelo de ML serializado puede convertirse en una herramienta agéntica con pocas líneas de código.
El punto más importante sobre Tooling en este contexto es que no es solo una cuestión técnica, es una decisión de diseño que afecta directamente la capacidad del sistema de evolucionar. Cuando construyes un pipeline agéntico con buenas abstracciones de herramientas, agregar un nuevo modelo de Machine Learning, cambiar un clasificador por una versión más reciente o experimentar con una arquitectura diferente se convierte en una operación incremental y no en una refactorización completa. Esto es especialmente relevante hoy, cuando el ritmo de evolución tanto de los LLMs como de los algoritmos clásicos sigue acelerado y la capacidad de iterar rápido es lo que separa a los equipos que entregan valor de los equipos que se quedan atrapados en deuda técnica. 🛠️
Herramientas que usamos a diario
Lo mejor de ambos mundos
Los modelos clásicos de ML fueron la capacidad de vanguardia en muchas industrias durante más de una década antes de que los LLMs entraran en escena, dándole a las personas insights sobre datos que no habrían conseguido de otra forma. Ese poder no debe descartarse, sino combinarse con las capacidades de los LLMs. Podemos aprovechar las fortalezas del LLM, convirtiendo lenguaje humano en lenguaje de máquina, encadenando diferentes llamadas a herramientas y recuperando resultados de ellas, y aun así usar modelos clásicos dentro de ese framework para hacer el trabajo para el cual un LLM simplemente no es apropiado.
La barrera de entrada es la habilidad de crear modelos clásicos de alta calidad, algo que, desafortunadamente, no es tan glamuroso como buena parte del trabajo relacionado con IA hoy en día. Pero vale el esfuerzo, por las ventajas claras: precisión, interpretabilidad, costo y control. Para quienes quieren cosechar esos resultados en la práctica, vale la pena revisitar herramientas como XGBoost, LightGBM y scikit-learn, además del propio CatBoost, y ver la diferencia con sus propios ojos.
La combinación de AI Agents con LLMs y Classical Models no es una contradicción, es una evolución natural. El campo está aprendiendo, en la práctica, que la inteligencia artificial robusta rara vez proviene de un único enfoque aplicado a todo. Proviene de la combinación inteligente de las herramientas correctas para los problemas correctos, orquestadas por sistemas que saben cuándo usar cada una de ellas.
