Coste en SWE-bench: cómo calcular el precio por incidencia resuelta sin ocultar fallos, reintentos ni evaluación

La cifra engañosa: el precio por incidencia resuelta no se explica solo

Expresar el resultado de un agente como «coste por incidencia resuelta» parece convertir una evaluación técnica en una decisión económica sencilla. Sin embargo, esa cifra es una razón entre variables que pueden haberse definido de formas muy distintas. El numerador puede contener sólo tokens de una llamada final, o bien todas las llamadas iniciadas durante una trayectoria. El denominador puede ser el número de parches que superan el verificador, el número de incidencias inicialmente seleccionadas o un resultado elegido entre varios intentos. Sin esas definiciones, dos cifras iguales no describen necesariamente operaciones comparables.

La distinción importa especialmente en SWE-bench. La tarea parte de incidencias reales asociadas a repositorios y exige producir un cambio que pueda ser verificado en un entorno preparado para ello. El coste observable no se limita, por tanto, a redactar un parche. Un sistema puede inspeccionar archivos, pedir contexto adicional, ejecutar herramientas, reiniciar una estrategia o agotar un límite sin generar una solución válida. Todos esos eventos pueden consumir recursos aunque la instancia no cuente como resuelta.

La pregunta económica correcta depende de la decisión. Para presupuestar una ejecución completa interesa el coste medio por incidencia intentada. Para valorar el rendimiento de un flujo que sólo entrega cambios verificados puede interesar el coste total dividido por los éxitos estrictos. Para decidir si merece la pena una configuración más cara, la comparación relevante suele ser el coste adicional por éxito adicional respecto de una línea base. Y si se autorizan varias trayectorias y se conserva una de ellas, hay que medir el coste de la política completa, no sólo el de la trayectoria seleccionada.

Esto no implica que una métrica resumida sea inútil. Implica que debe leerse como la portada de una ficha de costes. La ficha ha de indicar la versión del conjunto, el subconjunto realmente ejecutado, las exclusiones, el número de intentos, la regla de selección, el protocolo de parada, las categorías de consumo y qué parte de la infraestructura de evaluación se incluyó. Sin esos elementos, la cifra puede ser una observación interna válida, pero no una base suficiente para comparar agentes o estimar una automatización.

Qué se paga durante una ejecución

El primer componente es la inferencia. En una API, el registro de consumo debe separar tokens de entrada y salida cuando el proveedor los facture de forma distinta. Si la plataforma informa de entrada en caché o de tokens de razonamiento facturables, esas categorías también deben aparecer por separado. La documentación de OpenAI, aplicable únicamente a sistemas que utilicen esa API, distingue estas categorías y señala que solicitar múltiples completions consume tokens adicionales. No debe extrapolarse automáticamente esa terminología, ni su estructura de precios, a otros proveedores.

El segundo componente son las llamadas auxiliares y las herramientas. Un agente puede realizar búsquedas, resumir archivos, generar pruebas, revisar diffs o pedir nuevas completions tras ejecutar comandos. Algunas herramientas no tienen precio directo de API, pero aumentan el contexto de las llamadas posteriores o emplean cómputo propio. Si una herramienta externa cobra por uso, debe figurar como partida independiente. Si no se le asigna un coste monetario, al menos debe registrarse su número de invocaciones y los recursos que consume para que otra organización pueda valorarlos con su propia tarifa.

El tercer componente es la evaluación. El arnés de SWE-bench prepara imágenes Docker, aplica parches y ejecuta pruebas con límites de tiempo por instancia. Su documentación también contempla requisitos de CPU, memoria, almacenamiento y mecanismos de caché. Construir o recuperar imágenes, ejecutar contenedores y conservar artefactos puede representar un coste material, sobre todo en campañas amplias, aunque no sea coste de inferencia. Mezclarlo sin desglose impide saber si una mejora procede del agente o de la infraestructura; omitirlo de un presupuesto operativo puede infravalorar el gasto real.

También conviene separar el coste amortizado del coste marginal. Preparar una imagen compartida para muchas instancias no cuesta lo mismo por ejecución que reconstruirla desde cero. Del mismo modo, una caché de resultados puede evitar trabajo posterior. Estas eficiencias son legítimas si se documentan, pero no deben presentarse como si cada incidencia hubiera requerido el mismo gasto marginal. Una ficha sólida ofrece ambos planos: el coste de la campaña observada y las reglas empleadas para atribuir costes compartidos.

Cuatro denominadores para cuatro preguntas distintas

La primera métrica es el coste medio por incidencia intentada: coste total de la campaña dividido por todas las incidencias para las que se inició el protocolo. Es la medida más adecuada para estimar el gasto de procesar una cola de trabajo parecida, porque incluye éxitos, fallos, trayectorias inválidas y casos agotados por límites. Debe quedar claro si una incidencia excluida antes de iniciar el agente forma parte del universo o no. Una exclusión posterior a la ejecución no debería borrar su coste.

La segunda métrica es el coste por éxito estricto: coste total de las trayectorias incluidas en la política dividido por el número de incidencias cuyo parche supera el proceso de verificación definido. Describe cuánto gasto fue necesario, en promedio, para obtener un resultado validado bajo ese protocolo. Puede crecer incluso si el coste por intento disminuye, cuando cae la tasa de resolución; por eso no debe publicarse sin ambas cantidades de base.

La tercera es el coste incremental de elevar la resolución. Si una configuración B resuelve más incidencias que una configuración A, se calcula como la diferencia de coste total entre B y A dividida por la diferencia de éxitos. Esta razón responde a una decisión marginal: cuánto cuesta obtener cada éxito adicional con una configuración más ambiciosa. Sólo es interpretable si ambos sistemas se ejecutan sobre el mismo conjunto, con criterios de éxito y recursos de evaluación equivalentes.

La cuarta corresponde a políticas con varios intentos por incidencia. Si se permite pass@k, reintentos o selección posterior, el coste debe sumar las trayectorias generadas para cada incidencia, incluidas las no elegidas. Informar el coste de la mejor trayectoria encontrada equivale a informar un resultado condicional que no reproduce el gasto de encontrarla. La publicación debe aclarar si se ejecutó una sola trayectoria por instancia, varias independientes o un árbol de decisiones adaptativo.

El protocolo cambia la factura y el significado del resultado

Un límite de pasos, de tiempo, de llamadas o de presupuesto monetario forma parte de la intervención evaluada. Aumentarlo puede permitir que algunas incidencias difíciles reciban más exploración, pero también puede concentrar una fracción importante del gasto en una cola larga de casos sin resolver. Por ello, además de la media, conviene publicar mediana, percentiles y distribución por instancia. Una media baja puede coexistir con pocos casos excepcionalmente caros que resulten inaceptables en producción.

La política de parada debe ser explícita. Puede detenerse una ejecución al obtener un parche, al no encontrar archivos relevantes, al superar un presupuesto, tras fallar pruebas o tras alcanzar un número de iteraciones. Cada opción modifica tanto el coste como la probabilidad de éxito. Los reintentos requieren la misma precisión: debe indicarse qué los activa, si heredan contexto, si reutilizan caché y si se contabilizan los intentos descartados. Llamar «un intento» a una secuencia de reinicios internos puede ocultar una diferencia material de consumo.

Pass@1 y pass@k contestan preguntas diferentes. Pass@1 se aproxima al rendimiento de una única oportunidad bajo una configuración fijada. Pass@k describe la posibilidad de que al menos una de varias oportunidades produzca un éxito, pero no equivale a un coste de una oportunidad. Cuando hay selección posterior, debe documentarse la señal usada para seleccionar, si la selección consumió modelo o cómputo adicional y si tuvo acceso a resultados de pruebas. Una selección informada por el verificador puede ser útil para investigar, pero no debe confundirse con una política disponible antes de verificar.

La comparación más informativa suele fijar restricciones comunes: mismo conjunto de instancias, mismo arnés, mismos límites de evaluación y, cuando el objetivo es económico, un presupuesto máximo comparable por incidencia. Después pueden mostrarse curvas de coste frente a resolución. Esa presentación deja ver si la ganancia de resolución aparece a un coste gradual o depende de una minoría de trayectorias muy caras. También evita atribuir a la calidad del agente lo que podría deberse a haberle permitido gastar más.

Inferencia y evaluación: separarlas no significa ignorar ninguna

Separar inferencia y evaluación permite responder dos preguntas que una sola cifra mezcla. La primera es cuánto cuesta al agente proponer un cambio. La segunda es cuánto cuesta determinar si ese cambio supera el protocolo del benchmark. En SWE-bench, la evaluación requiere aplicar la predicción y ejecutar pruebas en un entorno de repositorio. El arnés documenta preparación de imágenes, ejecución con contenedores, límites temporales y opciones de caché; por ello, tratar la verificación como una operación gratuita sería metodológicamente incompleto.

La separación no obliga a escoger una única convención. Para investigación de modelos puede ser razonable informar primero el coste de inferencia y, junto a él, el coste de evaluación de la campaña. Para planificar un servicio de reparación automatizada, el coste total de propiedad es más pertinente: inferencia, orquestación, herramientas, cómputo de pruebas, almacenamiento y revisión humana cuando forme parte del flujo. La clave es no sumar unas partidas para un agente y omitirlas para otro.

Hay una incertidumbre práctica: los costes de infraestructura dependen de la región, el proveedor, la capacidad reservada, la concurrencia y la política de retención. Las fuentes disponibles describen componentes del arnés, pero no establecen una tarifa universal para ejecutarlos. Por eso una publicación rigurosa debe aportar unidades físicas, como tiempo de contenedor y recursos asignados, además de cualquier conversión monetaria local. Así, otra organización puede recalcular el importe con sus propios contratos.

Los artefactos de experimentos resultan esenciales para esta separación. El repositorio de experimentos de SWE-bench contempla predicciones, registros de ejecución, trazas y resultados por instancia. Compartir o resumir esos artefactos con una estructura consistente permite comprobar qué parches se evaluaron, detectar instancias sin resultado y reconciliar los totales de coste con las trayectorias. La auditabilidad no exige revelar credenciales, prompts confidenciales o datos protegidos; sí exige que las exclusiones y agregaciones no impidan revisar la contabilidad.

La ficha mínima de publicación y la decisión operativa

La ficha debería comenzar por la identidad del experimento: variante y revisión del conjunto, número de instancias elegibles, intentadas y excluidas, junto con los motivos de exclusión. Esto es relevante porque SWE-bench ofrece varias variantes y la documentación del proyecto identifica SWE-bench Verified como un conjunto de 500 instancias. Nombrar únicamente «SWE-bench» no basta para saber qué población se evaluó. También deben conservarse el identificador del arnés, las imágenes o configuración pertinente y las reglas de verificación.

A continuación deben constar el modelo, proveedor o endpoint, región si altera el precio, fecha de consulta de precios y moneda. La contabilidad ha de mostrar tokens de entrada, salida, caché y razonamiento cuando esas categorías existan para el proveedor utilizado, además de las llamadas auxiliares. Debe incluir el límite por incidencia, la política de parada, los reintentos y el método de selección. Las medias deben acompañarse de distribución por instancia y de recuentos de trayectorias fallidas, agotadas, inválidas o no verificables.

La ficha termina con dos totales: inferencia y evaluación. Para cada uno debe indicar qué partidas incorpora, qué se excluye y cómo se atribuyen los costes compartidos. Si se publica una cifra por éxito, el total del numerador debe reconciliarse con las partidas previas y el denominador con los éxitos estrictos observados. Si hay varias muestras por instancia, el coste informado tiene que ser el de generar y escoger entre todas ellas, no el de la muestra ganadora.

Para explorar modelos en una fase temprana, el coste por incidencia intentada y una curva de resolución bajo presupuestos fijos suelen ser las métricas más útiles. Para optimizar un agente, interesa añadir coste incremental por éxito adicional y distribución de casos caros. Para presupuestar automatización, la referencia es el coste total de propiedad por incidencia entrante, incluyendo verificación y la intervención humana que el proceso realmente requiera. Ninguna de estas medidas sustituye a las otras: cada una responde a un riesgo diferente.

La conclusión prudente es que un agente no reduce necesariamente el coste de resolver incidencias por obtener una tasa de resolución mayor o por mostrar un importe bajo asociado a sus éxitos. Puede desplazar gasto hacia más trayectorias, más contexto, más cómputo de pruebas o una selección posterior. La comparación defendible declara ese desplazamiento. Con una ficha completa, un equipo puede decidir si paga por más éxitos, si limita la exposición a casos caros o si adopta una configuración que ofrece una economía más predecible.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.