ES
Cómo el contexto del agente de programación cambia el trabajo del servidor
The Physical Cost of Context: Quality-Constrained Resource Accounting for Coding Agents · arXiv:2610.34763
En palabras sencillas
Cada vez que un agente de programación pide al modelo que actúe, le envía información sobre el proyecto. Un mensaje más corto todavía puede exigir más trabajo si editar mensajes anteriores impide que el servidor reutilice información ya procesada.
El artículo presenta un método que comprueba la calidad de las tareas y cuenta tanto las llamadas al modelo como los datos de entrada que el servidor debe procesar de nuevo. En pruebas separadas de localización, proporcionar antes el código recuperado superó la comprobación de calidad y usó menos llamadas y menos energía de GPU medida que buscar a partir únicamente del problema descrito.
La investigación
Cuando los agentes de programación envían repetidamente contexto del proyecto, ¿recortar sus solicitudes reduce de forma fiable el trabajo que hace el servidor?
La respuesta puede depender de si se puede reutilizar la entrada anterior y de si una política cambia el número de solicitudes que realiza el agente.
Los autores presentan un método de contabilización con umbral de calidad que separa el tamaño de las solicitudes del trabajo del servidor y evalúan cómo la recuperación de código, las ediciones del historial y la caché modifican ese trabajo.
Los autores comparan Grep, que inicia la localización a partir de un problema descrito, con Eager, que proporciona diez fragmentos de código recuperados antes del primer turno; ambos conservan todo el historial.
En 450 problemas de Python, el Recall@5 de Eager fue de 0.478 frente a 0.470 para Grep, y su diferencia de calidad emparejada superó el umbral de no inferioridad de cinco puntos.
En una cohorte separada de recursos, sin reutilización de caché, Eager usó menos llamadas y menos energía de GPU estimada por tarea intentada.
En conjunto, estos resultados respaldan que proporcionar evidencia de antemano puede reducir el trabajo medido en esta configuración, mientras que la contabilización muestra por qué el total de tokens de una solicitud no basta para establecer que hubo ahorro.
Las mediciones de calidad y los resultados detallados de recursos para localización proceden de cohortes distintas, y el estudio de generación de parches usó un presupuesto fijo de 32 llamadas.
Las pruebas cubrieron cuatro políticas fijas en un dispositivo, atendiendo una solicitud a la vez; no permiten establecer resultados para procesamiento por lotes, GPU en la nube ni otros diseños de políticas.
Qué muestran las pruebas
- Precisar qué trabajo se ahorra
El artículo presenta un protocolo de contabilización de recursos con un umbral de calidad para comparar políticas de contexto en agentes de programación. La pregunta es si las solicitudes más cortas implican de forma fiable menos trabajo cuando los agentes hacen peticiones repetidas y los servidores pueden reutilizar entradas anteriores.
El protocolo comprueba la calidad de las tareas antes de comparar los costos de recursos y luego mide las llamadas al modelo, el procesamiento de entradas no almacenadas en caché, la ocupación de la caché, el tiempo y un indicador indirecto de energía de la GPU.
- Comprobar el umbral de calidad
En la tarea de localización, Grep parte únicamente del problema descrito, mientras que Eager proporciona diez fragmentos de código recuperados antes del primer turno del agente; ambos conservan todo el historial. Hay éxito cuando la función o clase objetivo aparece entre los cinco bloques de código devueltos.
En 450 problemas de Python de repositorios distintos, la puntuación de Eager fue de 0.478, frente a 0.470 para Grep. La diferencia de calidad emparejada de Eager superó el umbral de no inferioridad de cinco puntos definido por los autores.
- Medir el costo de localizar código
Los autores midieron los recursos en una cohorte separada de localización con 100 tareas, sin reutilización de prefijos y contabilizando las tareas fallidas. En esa cohorte, Eager usó menos llamadas exitosas al servidor y menos energía de GPU estimada por tarea intentada que Grep.
Esto respalda la interpretación de que, en esta comparación, proporcionar evidencia de antemano redujo el trabajo al evitar algunas llamadas de búsqueda; las mediciones de calidad y costo no proceden de las mismas tareas.
- Evaluar la reutilización y los cambios del historial
Otras dos comparaciones muestran por qué la longitud de la solicitud no basta para estimar el trabajo. Al mantener Eager sin cambios, activar la reutilización de prefijos dejó el volumen lógico de solicitudes estadísticamente parecido y redujo mucho el prefill no almacenado en caché.
En otra configuración de generación de parches, Mask-5 acortó las solicitudes, pero no superó el umbral de calidad y aumentó mucho el prefill no almacenado en caché y la energía de GPU medida. Los resultados muestran que la reutilización y el comportamiento del agente pueden alterar la relación entre el tamaño de la solicitud y el trabajo ejecutado.
Detalles
- Autores del paper original
- Zhongming Yu, Yitong Ma, Hengjia Yu, Boqin Yuan, Xiangye Lin
- Enviado a arXiv
- Licencia
- arXiv non-exclusive