Volver a Noticias
InnovaciónAI Understanding sesión informativa

Los nuevos informes preimpresos se benefician de los modelos de lenguaje en bucle en la llamada de herramientas de varios pasos

Un estudio de arXiv evalúa modelos de lenguaje convencional y en bucle en tres puntos de referencia de llamadas de herramientas, reportando resultados más sólidos en flujos de trabajo que requieren múltiples llamadas API dependientes y un enfoque de computación adaptativa potencialmente más eficiente.

Por 6 min read
Unlabeled network appliances linked by colored cables on a workbench in a university computing laboratory
La versión corta

Un estudio de arXiv evalúa modelos de lenguaje convencional y en bucle en tres puntos de referencia de llamadas de herramientas, reportando resultados más sólidos en flujos de trabajo que requieren múltiples llamadas API dependientes y un enfoque de computación adaptativa potencialmente más eficiente.

que paso

Los investigadores Andrei Cristian Popescu, Haitz Sáez de Ocáriz Borde y Pietro Liò informan experimentos con modelos de lenguaje en bucle nativos y modernizados para la llamada de herramientas de composición. El estudio compara modelos con y sin bucle entrenados con recetas de ajuste supervisadas coincidentes en API-Bank, BFCL y NESTful. Su resumen dice que el cálculo recurrente generalmente mejora el uso de herramientas de varios pasos que tienen en cuenta la dependencia, mientras que la inferencia adaptativa puede asignar cálculo adicional solo cuando sea necesario.

El artículo, titulado “Los modelos de lenguaje en bucle mejoran la llamada de herramientas de composición”, se envió a arXiv el 17 de agosto de 2026 y se identifica en la página fuente proporcionada como la versión 1. Su pregunta central es si los modelos de lenguaje en bucle, que utilizan computación recurrente, pueden mejorar el uso de herramientas agentes. Los autores se centran en configuraciones de composición en lugar de llamadas aisladas: es posible que un modelo necesite invocar varias API, transmitir estados intermedios y preservar las dependencias entre interacciones sucesivas de herramientas. La fuente presenta esto como un área cuyo potencial ha sido comparativamente poco explorado, no como un producto terminado o un anuncio de implementación. La evaluación compara modelos nativos con bucle y modelos adaptados con bucle con modelos sin bucle. El resumen dice que los modelos fueron entrenados bajo recetas de ajuste supervisadas, un control importante destinado a hacer que la comparación arquitectónica sea más significativa.

Los investigadores varían la profundidad recurrente en el momento de la inferencia, lo que permite que los modelos realicen diferentes cantidades de cálculo recurrente. Prueban los sistemas en tres puntos de referencia nombrados: API-Bank, BFCL y NESTful. El resumen proporcionado no proporciona las tareas individuales, el recuento de parámetros del modelo, los datos de entrenamiento, las puntuaciones de referencia ni el protocolo de evaluación detallado. El patrón informado es más fuerte para el uso de herramientas de varios pasos. Según los autores, la computación recurrente generalmente beneficia las llamadas a herramientas de composición y de dependencia. La mejora se describe como más pequeña y más dependiente del modelo particular cuando la tarea implica solo una invocación API aislada. El resumen también informa que la precisión en el uso de herramientas de varios pasos generalmente aumenta a medida que aumenta la profundidad recurrente. Esto indica que darle a un modelo más cálculo interno puede ayudarlo a coordinar una secuencia de llamadas, pero la fuente no dice que cada modelo o cada punto de referencia haya mejorado, ni identifica una única profundidad que funcione mejor.

El artículo destaca la inferencia adaptativa como una compensación más favorable entre el rendimiento y la computación que aplicar el mismo cálculo adicional en todas partes. En la descripción de los autores, la inferencia adaptativa asigna cálculos adicionales cuando es necesario en lugar de aumentar uniformemente la profundidad recurrente. La fuente proporcionada no explica cómo el sistema decide cuándo es necesario realizar más cálculos ni cuantifica el costo y la latencia resultantes. Tampoco indica si hay disponible código, puntos de control del modelo o una implementación orientada al usuario. Por lo tanto, la evidencia disponible aquí es el resumen y el registro bibliográfico de los autores, en lugar de una replicación independiente o un sistema de producción demostrado.

Lea la fuente principal: arxiv.org

Por qué es importante

Los sistemas de llamada de herramientas a menudo deben coordinar varias llamadas API, preservar el estado intermedio y mantener intactas las dependencias. El estudio sugiere que agregar computación recurrente puede ayudar a los modelos a gestionar estos flujos de trabajo, aunque la fuente proporcionada no establece qué tan grandes son las ganancias, si se transfieren a sistemas activos o si el enfoque es más barato en general.

La importancia práctica se deriva del tipo de tarea que se evalúa. Un modelo que utiliza herramientas y debe realizar una llamada resuelve un problema más limitado que un sistema que tiene que recuperar información, utilizar ese resultado en una segunda solicitud y mantener el estado correcto durante toda la secuencia. Los errores en dichas cadenas pueden surgir al seleccionar la herramienta incorrecta, usar información intermedia obsoleta o incompleta o romper una dependencia entre llamadas. Los beneficios informados por el estudio son relevantes porque abordan este problema de coordinación directamente, en lugar de tratar cada invocación de herramienta como una acción independiente.

El resultado arquitectónico, si se mantiene más allá de la configuración probada, podría afectar la forma en que los desarrolladores asignan el cálculo del modelo. El aumento de la profundidad recurrente parece mejorar la precisión de varios pasos en los experimentos de los autores, mientras que la inferencia adaptativa se presenta como una forma de reservar cálculos adicionales para casos más difíciles. Esa combinación podría ser útil para sistemas que enfrentan una combinación de solicitudes simples y complejas: las llamadas directas no necesariamente incurrirían en el costo total de un procesamiento más profundo, mientras que los flujos de trabajo dependientes podrían recibir más cálculos. La fuente no establece que el enfoque reduzca los costos operativos totales; una compensación favorable en un experimento no es lo mismo que una ventaja económica comprobada en su implementación.

Los hallazgos no muestran por sí solos que los modelos en bucle sean, en términos generales, agentes más confiables. La fuente menciona tres puntos de referencia, pero no proporciona resultados detallados, intervalos de confianza, análisis de fallas ni comparación con los sistemas de producción actuales. No proporciona evidencia sobre errores de autorización, incidentes de privacidad, acciones de herramientas dañinas, respuestas de API con formato incorrecto, límites de velocidad, servicios no disponibles o revisión humana. Tampoco muestra que una mayor precisión de los puntos de referencia conduzca a mejores resultados para los consumidores, los trabajadores o las organizaciones. Esas limitaciones son importantes porque las fallas en las llamadas a herramientas pueden tener efectos fuera del modelo de lenguaje, dependiendo de los permisos que proporcionen las herramientas conectadas.

El trabajo se entiende mejor como el resultado de una investigación arquitectónica con posibles implicaciones para futuros sistemas de agentes. Se diferencia de los elementos de archivo interno enumerados porque el candidato proporcionado se centra en el cálculo recurrente para el uso de API de composición, no en la certificación de agentes, el cambio de adaptadores, las omisiones de seguridad, la consulta de datos empresariales u otro ángulo fáctico enumerado. El registro arXiv establece que los autores realizaron y describieron este estudio; no establece de forma independiente la superioridad general de los modelos en bucle o su preparación para el uso práctico.

Qué ver a continuación

El documento completo debe aclarar las puntuaciones informadas, los tamaños de los modelos, la implementación recurrente, los costos de inferencia y la política de inferencia adaptativa. Se necesita más evidencia sobre herramientas invisibles, llamadas API fallidas o conflictivas, flujos de trabajo prolongados, latencia, reproducibilidad y si las mejoras en los puntos de referencia se traducen en agentes implementados más seguros y confiables.

La primera prioridad es el conjunto completo de resultados cuantitativos. Los lectores deben buscar puntuaciones desglosadas por punto de referencia, duración de la tarea, estructura de dependencia, familia de modelos y profundidad recurrente. Será importante determinar si la tendencia general informada es estadísticamente sólida o está impulsada por un subconjunto de modelos o tareas. La redacción del resumen (“generalmente” beneficiosa y “más dependiente del modelo” para llamadas aisladas) ya indica que el efecto no es uniforme. Las categorías de error exactas mostrarían si el bucle mejora la planificación, el seguimiento del estado, la selección de herramientas, la construcción de argumentos o varios de estos a la vez.

La historia de la computación también necesita un examen detenido. Los pases recurrentes adicionales pueden aumentar el tiempo de inferencia, el uso de la memoria o el consumo de energía incluso cuando mejoran la precisión. El método adaptativo podría cambiar ese equilibrio, pero la fuente suministrada no identifica su regla de decisión ni informa sus gastos generales. La evidencia de seguimiento útil incluiría distribuciones de latencia, costos de tokens y aceleradores, la cantidad de pasos recurrentes utilizados por tarea y resultados bajo un presupuesto de computación fijo. Las comparaciones también deberían probar si un modelo convencional más grande, un contexto más largo u otro método de tiempo de inferencia logra ganancias similares con una complejidad operativa más baja.

La generalización es otra cuestión abierta. Es posible que los puntos de referencia nombrados no capturen condiciones reales, como comportamientos de API no documentados, límites de autenticación y permisos, fallas parciales, resultados de herramientas conflictivas, esquemas cambiantes, límites de velocidad o cadenas muy largas. Las pruebas con API invisibles y flujos de trabajo interrumpidos deliberadamente ayudarían a establecer si el modelo aprendió una capacidad de coordinación transferible o se adaptó a las convenciones de referencia. Las evaluaciones de seguridad deben examinar qué sucede cuando una herramienta devuelve instrucciones maliciosas, cuando se presiona a un modelo para que eluda una restricción o cuando una secuencia aparentemente válida produciría una acción externa no deseada.

Finalmente, se debe evaluar la reproducibilidad y la confirmación externa de la investigación. La fuente proporcionada es una página de resumen de arXiv versión 1 y no indica si los autores publicaron el código, los puntos de control o las configuraciones completas. Implementaciones independientes que utilicen la misma configuración de ajuste fino podrían probar si el efecto depende de un modelo en particular, una receta de entrenamiento o una interpretación de referencia. Hasta que esos detalles estén disponibles, la conclusión defendible es limitada: los autores reportan evidencia comparativa prometedora de que la computación recurrente puede mejorar algunas tareas de llamada de herramientas de composición, mientras que la escala, el costo, la durabilidad y la seguridad de la mejora en el mundo real siguen siendo desconocidas.

Guías y cuestionarios relacionados

¿Encontró esto útil?
El informe semanal

Obtenga las historias de IA que realmente importan.

Un correo electrónico útil a la semana: qué cambió en la IA, por qué es importante, además de herramientas, guías, oportunidades y formas prácticas de actuar.

Gratis · Sin spam · Darse de baja en un clic