Investigadores de UCSB y LinkedIn entrenan agentes de IA para predecir sus propias llamadas a herramientas

Why it matters

Tool latency keeps multi-step agents from feeling interactive. Self-speculation could hide part of that wait without serving a second model, but production gains will depend on exact-match rates, API costs and safeguards for state-changing actions.

Jiabao Ji, Yujian Liu and Li An, tres investigadores de UC Santa Barbara que trabajaban como pasantes en LinkedIn, entrenaron agentes de IA para predecir y preejecutar sus propias llamadas a herramientas siguientes, un intento de eliminar una creciente fuente de demora en sistemas que dependen de motores de búsqueda, bases de datos y APIs externas.

Los investigadores describieron el método en un artículo en arXiv del 28 de julio, escrito junto con los investigadores de LinkedIn Rohit Jain, Gungor Polatkan y Siyu Zhu y el profesor de ciencias de la computación de UCSB Shiyu Chang. DAIR.AI destacó la investigación en X el 30 de julio.

Ji es estudiante de doctorado (Ph.D.) de cuarto año en UCSB, asesorado por Chang. Sus pasantías de investigación previas incluyen Adobe Research, el grupo GenAI Llama de Meta y Apple AI/ML, seguidas por trabajo con el grupo CoreAI de LinkedIn en 2026. Liu, también estudiante de doctorado (Ph.D.) de cuarto año asesorado por Chang, trabajó anteriormente en Adobe Research, el MIT-IBM Watson AI Lab y AMD GenAI. Su nuevo artículo va más allá de entrenar agentes para elegir herramientas correctamente y se enfoca en cuándo se pueden iniciar esas llamadas.

Un modelo, dos trabajos

Los agentes que usan herramientas alternan entre generar texto y esperar a sistemas externos. Una consulta de búsqueda, una consulta a una base de datos o un subagente pueden tardar más que la propia generación de tokens del modelo, dejando inactivo hardware de inferencia costoso y haciendo que un agente, por lo demás capaz, se sienta lento.

La ejecución especulativa de herramientas intenta llenar esa brecha. Mientras el agente continúa razonando, un especulador predice la siguiente llamada estructurada, incluyendo el nombre de la herramienta y los argumentos, y comienza la petición de forma anticipada. Si la predicción coincide exactamente con la llamada que el agente acaba produciendo, el sistema reutiliza el resultado. Una descoincidencia implica que el trabajo especulativo debe descartarse.

Los enfoques previos comúnmente asignaban esa predicción a un modelo borrador más pequeño o recuperaban una acción probable de trazas en caché. Los investigadores de UCSB y LinkedIn sostienen que esos sistemas crean una "brecha especulador-agente": el modelo borrador aproxima lo que el agente podría hacer sin coincidir con precisión con la política desplegada del agente. El modelo adicional también requiere sus propios pesos y su caché KV durante el servicio.

Su diseño de autoespeculación da ambos trabajos a un solo modelo de lenguaje. En modo agente, el modelo razona sobre la tarea y llama a las herramientas normalmente. En modo especulador, recibe una trayectoria parcial más un sufijo corto que le pide predecir la siguiente llamada estructurada. Ambos modos comparten parámetros del modelo y pueden reutilizar la misma caché KV de prefijo.

Los investigadores entrenaron los dos modos mediante actualizaciones alternadas de aprendizaje por refuerzo. Cada lote de ejecuciones del agente produce ejemplos nuevos de las llamadas que el modelo actual eligió realmente. Esas llamadas luego se convierten en objetivos para su entrenamiento de especulación. El programa de entrenamiento final usó cuatro actualizaciones de agente seguidas de ocho actualizaciones de especulador, con el estado del optimizador reiniciado cada vez que el entrenamiento cambiaba de modo.

Esa separación fue trascendental. Un programa de actualización uno a uno produjo una puntuación Hit@1 promedio de 31.8 y un éxito de tarea de 10.3 en los tres benchmarks de búsqueda usados en la ablación. El esquema cuatro a ocho alcanzó 55.2 Hit@1 y 26.1 de éxito en tareas bajo el mismo presupuesto de iteraciones.

Las ganancias en los benchmarks

Los investigadores probaron el método con los modelos Qwen3 y Qwen3.5 de 4 mil millones de parámetros. La evaluación cubrió HotpotQA, MuSiQue y BrowseComp-Plus para búsqueda, junto con los dominios de aerolíneas y retail de tau-bench para uso de API conversacional.

Para Qwen3-4B, el Hit@1 promedio de la siguiente llamada subió de 44.1 tras el fine-tuning supervisado a 61.2 después de la etapa conjunta de aprendizaje por refuerzo. Qwen3.5-4B mejoró de 48.9 a 66.3. Un éxito Hit@1 requirió una coincidencia exacta tanto en el nombre de la herramienta como en el diccionario completo de argumentos.

Los promedios reportados de éxito en tareas posteriores también se mantuvieron o aumentaron ligeramente. Qwen3-4B pasó de 26.6 tras el fine-tuning supervisado a 27.7 tras el aprendizaje por refuerzo, mientras que Qwen3.5-4B pasó de 49.2 a 50.6. Esos promedios combinan tareas con dificultades de referencia sustancialmente diferentes, por lo que establecen que el objetivo adicional de especulación no borró las capacidades existentes del agente en los entornos probados.

Una comparación previa lista para usar mostró por qué los investigadores rechazaron un modelo borrador separado. En MuSiQue, Qwen3-4B prediciendo su propia siguiente llamada alcanzó 25.3 Hit@1 mientras usaba 8.70 GB de memoria GPU y 8.3 segundos de tiempo de reloj real de especulación. Un especulador externo Qwen3-1.7B alcanzó 14.7 Hit@1 mientras la configuración combinada consumía 12.76 GB y 33.1 segundos. Las pruebas se ejecutaron en una sola Nvidia H100 y usaron conmutación explícita entre modelos, por lo que esas mediciones describen la configuración de servicio del artículo más que un costo de producción universal.

Dónde termina la afirmación

Los resultados establecen mayor precisión de predicción y menor sobrecarga de servicio para la configuración de autoespeculación. El artículo no reporta un despliegue de producción de extremo a extremo que muestre cuánto de la latencia visible para el usuario elimina el modelo entrenado cuando las herramientas reales se ejecutan de forma concurrente.

Las coincidencias exactas también ocurrieron en aproximadamente seis a siete de cada diez predicciones después del entrenamiento. Las llamadas especulativas restantes no pudieron reutilizarse, dejando a los operadores sopesar las solicitudes de API y el cómputo desperdiciados frente a la latencia ahorrada por las predicciones correctas.

La seguridad estrecha aún más los casos de uso inmediatos. Una búsqueda web especulativa equivocada puede descartarse. Un pedido erróneo, una actualización de base de datos o un mensaje saliente equivocado puede cambiar el estado externo antes de que el agente se haya comprometido con la acción. Los autores limitan su caso actual a operaciones de solo lectura y sugieren modos de simulación (dry-run), mecanismos de reversión o confirmación humana para herramientas que cambian estado.

Los experimentos usaron modelos de escala 4B y dos familias de tareas. La ejecución de código, el control del navegador, flujos de trabajo de larga duración, sistemas multiagente y modelos de vanguardia más grandes quedan fuera de la evaluación. Incluso dentro de ese límite, el trabajo identifica una elección de diseño práctica para los constructores de agentes: la política desplegada puede ser un mejor predictor de su próxima acción que un modelo más barato entrenado para imitarla.