Los agentes de IA deberían invocar modelos

El artículo de MLAT describe un piloto en producción donde un agente invoca un modelo de precios XGBoost como herramienta, logra R^2 = 0.807 en datos apartados para prueba, reporta un error absoluto medio de 3688 USD y reduce la generación de propuestas de horas a menos de 10 minutos.¹

La idea útil no es el modelo de precios exacto. La idea útil es el límite: cuando una tarea necesita un puntaje, pronóstico, precio, estimación de riesgo, ranking, clasificador o detector, el agente debería invocar el modelo entrenado para ese trabajo. No debería improvisar una respuesta estadística en prosa fluida.

Un modelo entrenado pertenece al registro de herramientas del agente. El LLM puede decidir cuándo invocarlo, explicar el resultado, pedir entradas faltantes y enrutar excepciones. El modelo ajustado debe producir la estimación numérica, la señal de confianza, el resultado versionado y la traza de evidencia.

Resumen

Los agentes LLM son buenos para la orquestación. Los modelos estadísticos y de aprendizaje automático suelen ser mejores para predicciones acotadas. El patrón Machine Learning as a Tool trata un modelo de ML ajustado como una herramienta invocable dentro de un flujo de trabajo de agentes, junto con búsqueda, bases de datos, APIs y otras herramientas.¹

Ese patrón les da a los equipos una regla operativa clara: deja que el agente coordine el trabajo, pero haz que los modelos especializados realicen la inferencia especializada. El resultado debería incluir la versión del modelo, el esquema de entrada, el esquema de salida, notas de calibración y un registro de llamada trazable. Sin ese límite, el LLM puede sonar seguro mientras reemplaza en silencio un modelo por una conjetura.

Ideas clave

• Para quienes crean agentes: expón modelos entrenados como herramientas tipadas, con esquemas, versiones y modos de falla.
• Para equipos de ML: trata al agente como un invocador, no como reemplazo de la evaluación, la persistencia o la disciplina de registro del modelo.
• Para equipos de producto: muestra si un número vino de una llamada a un modelo, una regla, una base de datos o una explicación del LLM.
• Para equipos de seguridad: aplica a las herramientas de modelo la misma lógica de autoridad acotada de Las claves de agentes necesitan presupuestos de riesgo.
• Para revisores: exige la llamada al modelo, la versión del modelo, las entradas, la salida y los límites de confianza antes de confiar en la respuesta.

¿Por qué los agentes deberían invocar modelos en vez de imitarlos?

Un LLM puede hablar de un precio. Un modelo de precios puede estimarlo a partir de las características que aprendió. Un LLM puede resumir riesgo. Un modelo de riesgo puede puntuarlo desde un conjunto probado de características. Un LLM puede describir la pérdida de clientes. Un modelo de pérdida de clientes puede devolver una probabilidad vinculada a un proceso de entrenamiento.

Son trabajos distintos.

Las herramientas de agente ya permiten hacer esa separación. La documentación de OpenAI Agents SDK describe herramientas de función con parámetros de JSON Schema, manejadores de invocación de herramientas y salida estructurada de herramientas.² La documentación de uso de herramientas de Anthropic describe a Claude invocando herramientas del lado del cliente y funciones externas con entradas definidas mediante JSON Schema.³ El agente puede pedir una predicción de modelo con el mismo patrón de herramientas que usa para búsqueda, actualizaciones de calendario, comandos de shell o consultas a bases de datos.

La falla central aparece cuando los equipos omiten esa separación. Le piden al LLM una estimación porque el LLM puede producir una. La respuesta llega rápido. La prosa parece razonable. La interfaz no muestra ninguna pista visible de que el número salió de una completación de patrones y no de un estimador ajustado.

Ese contrato es débil. El usuario no sabe qué produjo el resultado. El revisor no puede inspeccionar la versión del modelo ni las características de entrada. El operador no puede reproducir la llamada. El producto no puede explicar por qué cambió la respuesta.

La puerta de evidencia aplica aquí: la confianza no es evidencia. Una llamada a un modelo puede producir evidencia. Una conjetura en prosa, por lo general, no.

¿Qué agrega el patrón MLAT?

MLAT significa Machine Learning as a Tool. El artículo presenta un modelo de ML entrenado como una herramienta de primera clase que un agente LLM puede invocar cuando la conversación necesita estimación cuantitativa.¹

El sistema piloto del artículo, PitchCraft, usa dos agentes. Un agente de investigación recopila contexto del prospecto mediante llamadas paralelas a herramientas. Un agente de borrador invoca un modelo de precios XGBoost y luego escribe una propuesta mediante salidas estructuradas.¹ El modelo de ML se encarga del precio. El LLM se encarga del contexto, el ensamblaje y la explicación.

Esa división importa porque evita dos malos diseños:

El agente sigue siendo importante. Puede decidir cuándo la entrada de precios está incompleta. Puede pedirle al usuario los campos faltantes. Puede invocar herramientas de búsqueda o CRM antes de invocar el modelo. Puede explicar que la estimación vino de un modelo, no de su propia autoridad.

Esa es la división correcta del trabajo: el LLM orquesta; el modelo ajustado predice.

¿Qué debería devolver una herramienta de modelo?

Una herramienta de modelo no debería devolver un número suelto. Una herramienta de modelo seria debería devolver un objeto de evidencia.

Esa forma de salida vuelve las herramientas de modelo compatibles con Las trazas de ejecución de agentes son el contrato del entorno de ejecución. Si un agente invoca un modelo de precios, la traza debería mostrar la llamada al modelo. Si un agente omite el modelo y escribe un número de todos modos, la traza debería hacer evidente esa ausencia.

La misma lógica sostiene Los paquetes de revisión son la nueva respuesta final. Una respuesta final con un precio es débil. Una respuesta final con un registro de llamada al modelo, versión del modelo, instantánea de características y nota de confianza le da al revisor algo que inspeccionar.

¿Dónde encajan los registros de modelos?

Envolver herramientas no reemplaza MLOps. Expone MLOps al entorno de ejecución del agente.

La documentación del registro de modelos de MLflow describe linaje, versionado, alias, etiquetas de metadatos e información de ciclo de vida para modelos.⁴ Esa capa de registro importa porque un flujo de trabajo de agentes solo puede citar una versión de modelo si la plataforma rastrea versiones desde el inicio.

La documentación de persistencia de modelos de scikit-learn plantea un punto relacionado desde el lado del servicio: las decisiones de persistencia tienen compromisos de seguridad y portabilidad, y ONNX puede servir modelos sin un entorno Python, mientras que las rutas basadas en pickle requieren confiar en la fuente.⁵ Una herramienta de modelo no debería introducir a escondidas un artefacto de modelo inseguro en un agente solo porque el agente pidió una predicción.

La pila operativa mínima se ve así:

Los equipos suelen colapsar esas capas en un solo endpoint llamado predict. Ese atajo funciona para demos. Falla cuando el agente empieza a encadenar predicciones en correos a clientes, propuestas comerciales, notas de evaluación de riesgo, planes de infraestructura o borradores de triaje médico.

El producto necesita un contrato de modelo, no un endpoint mágico.

¿Cómo deberían los productos mostrar la salida de un modelo?

La UI debería decirle al usuario cuándo una respuesta vino de una herramienta de modelo.

Un mal texto de interfaz oculta la procedencia:

Un mejor texto nombra la ruta de producción:

Esa distinción protege la dignidad del usuario. Los usuarios no deberían tener que adivinar si un número vino de un modelo probado, una ficha de modelo, una regla de negocio o una completación de modelo de lenguaje. El diseño agéntico es diseño de superficies de control sostiene que los productos con agentes necesitan superficies de supervisión y control. La procedencia del modelo es una de esas superficies.

Las fichas de modelo ayudan con el mismo problema en la capa de documentación. El artículo Model Cards propone reportes estructurados sobre características del modelo, uso previsto, métricas y contexto de evaluación.⁶ Las interfaces de agentes pueden tomar prestada esa idea en tiempo de ejecución: toda respuesta de modelo debería llevar suficiente contexto para que un usuario o revisor entienda qué tipo de afirmación hizo el modelo.

¿Qué deberían rechazar los agentes?

Un agente consciente de los modelos debería rechazar varios atajos tentadores.

Debería rechazar inventar una salida de modelo cuando la herramienta de modelo no está disponible. Puede decir que el modelo de precios falló. Puede preguntar si el usuario quiere una estimación aproximada etiquetada como humana. No debería reemplazar el modelo en silencio.

Debería rechazar ampliar el dominio del modelo sin evidencia. Un modelo de pérdida de clientes entrenado con datos de SaaS para empresas medianas no debería convertirse en un oráculo universal de salud empresarial porque la instrucción lo pide amablemente.

Debería rechazar ocultar la incertidumbre. Si un modelo devuelve un intervalo, la respuesta no debería reducirlo a un solo número confiado, salvo que el producto tenga una regla clara de visualización.

Debería rechazar invocar una herramienta de modelo con características faltantes o fabricadas. El agente puede recopilar entradas, hacer preguntas de seguimiento o marcar campos como desconocidos. No debería llenar el vector de características con ficción conveniente.

Debería rechazar tratar la autoridad del modelo como autoridad para actuar. Un modelo puede estimar riesgo de fraude. Eso no significa que el agente pueda congelar una cuenta. La acción sigue necesitando la disciplina de claves acotadas de Las claves de agentes necesitan presupuestos de riesgo.

La regla de decisión

Usa esta regla al crear un flujo de trabajo de agentes:

Esa regla le da al LLM un trabajo valioso sin permitirle hacerse pasar por todos los demás sistemas. Puede coordinar el flujo de trabajo, explicar salidas, redactar el mensaje y hacer mejores preguntas. No puede convertirse en el modelo de precios, modelo de riesgo, modelo de fraude, modelo de ranking o motor de políticas solo por sonar fluido.

Los mejores productos con agentes no le pedirán a un solo modelo que finja ser toda la empresa. Construirán una superficie de herramientas donde cada sistema haga el trabajo que puede demostrar.

FAQ

¿Esto es solo para modelos tradicionales de aprendizaje automático?

No. El mismo patrón aplica a cualquier estimador o puntuador especializado: modelos de gradient boosting, clasificadores, sistemas de ranking, modelos de pronóstico, motores de reglas, puntuadores de recuperación y detectores específicos de dominio. El punto no es el algoritmo. El punto es el contrato alrededor de la salida.

¿Por qué no dejar que el LLM estime directamente?

A veces una estimación cualitativa aproximada está bien. Un producto debería decirlo con claridad. Cuando el usuario necesita un precio, puntaje de riesgo, pronóstico o decisión de elegibilidad, la respuesta debería venir de un modelo probado o de una ruta de reglas con entradas y límites trazables.

¿Una herramienta de modelo vuelve automáticamente correcta la respuesta?

No. Una herramienta de modelo todavía puede estar desactualizada, sesgada, mal calibrada, mal usada o fuera de su dominio válido. La herramienta de modelo mejora la capacidad de inspección. No elimina la necesidad de evaluación, monitoreo y revisión humana.

¿Cuál es el contrato mínimo viable de una herramienta de modelo?

Empieza con esquema de entrada, esquema de salida, versión del modelo, predicción, confianza o salvedad, forma del error, tiempo de espera e ID de traza. Agrega nombres de características, enlace al registro, referencia a la ficha de modelo y notas de calibración cuando el modelo afecte dinero, acceso, seguridad o decisiones de cara al cliente.

¿Cómo cambia esto la UX de agentes?

La interfaz debería etiquetar la fuente de las salidas importantes. Los usuarios deberían ver si una respuesta vino de una llamada a un modelo, un documento recuperado, una regla de negocio, una aprobación humana o síntesis del LLM. Esa procedencia cambia cuánta confianza merece la respuesta.

Referencias