Auditoría de fugas en cuatro canales: que las tasas de aprobación reflejen capacidad

Una tasa de aprobación es un recibo, no una promesa. Si tu función de IA se lanza porque la suite de evals pasa, necesitas saber qué hizo realmente el modelo en esa sala. La sala puede estar amañada por respuestas ocultas, tareas rotas o un corrector que no coincide con el prompt.

SWE-Bench Pro expuso material de solución oculto a los agentes e incluyó tareas mal redactadas. La corrección revisó 102 tareas y eliminó 17 de la división pública de 731 instancias. En esa división, la tasa de aprobación de GLM-5.2 cayó del 78,80 por ciento al 59,51 por ciento tras la corrección. La puntuación de DeepSeek-V4-Pro cambió solo 0,05 puntos entre las evaluaciones originales y corregidas. Ese contraste es la advertencia: un benchmark puede medir el acceso a respuestas en lugar de la capacidad.

Cierra los canales de fuga antes de confiar en el número

La auditoría de SWE-Bench Pro identificó cuatro canales de fuga anti-hacking. Ejecútalos como una auditoría de evals de agentes, no como un pensamiento tardío de seguridad. Cada comprobación es pequeña, pero juntas cambian lo que significa el número.

• Inicia la tarea desde un checkout fresco del repositorio en el commit previo a la corrección, sin archivos de solución en caché.
• Mantén el parche de referencia, el parche de pruebas y los artefactos de solución generados fuera del espacio de trabajo del agente.
• Filtra metadatos que nombren el issue, el pull request, el repositorio o la corrección esperada antes de que el modelo vea la tarea.
• Bloquea los hosts de código salientes durante la ejecución, usando la misma lista de dominios bloqueados que utilizó el entorno corregido de SWE-Bench Pro: GitHub, GitLab, Gitee, Bitbucket, Codeberg y GitCode.
• Pasa una corrección alternativa válida por el corrector y compara el resultado con los criterios de éxito del prompt.

El checkout fresco establece la línea base. Las imágenes de tarea que ya contienen la corrección hacen que el modelo recupere en lugar de resolver. Compara la instantánea de la tarea con el commit base antes de ejecutar el agente, y reconstruye la tarea desde el estado previo a la corrección cuando un archivo de solución aparezca en el espacio de trabajo.

El ocultamiento de artefactos gestiona los archivos tentadores. Los parches y las salidas generadas pueden estar en el mismo contenedor que el modelo. Muévelos fuera del sistema de archivos del agente, no solo fuera del prompt. Los archivos nombrados según la corrección esperada se convierten en parte de la tarea cuando el agente puede leerlos.

El filtrado de metadatos detecta la fuga menos visible. Los títulos de issues, las etiquetas, los nombres de archivo y los mensajes de commit pueden codificar el parche previsto. Redáctalos antes de que el modelo vea la tarea. Los manifiestos de tarea limpios deben describir el problema visible para el usuario, no la respuesta de ingeniería.

El bloqueo de red cubre la ruta saliente. Los modelos con acceso saliente pueden buscar la corrección en hosts públicos de código. Bloquea los hosts que la tarea no necesita. Las descargas de paquetes requeridos pueden tener una lista corta de hosts permitidos y un registro de solicitudes.

La consistencia entre prompt y corrector detiene el reward hacking, donde un modelo engaña al corrector en lugar de resolver la tarea. Pasa una corrección alternativa correcta por el corrector. Una corrección correcta que falla muestra que el corrector mide estilo, no comportamiento. Añade pruebas del corrector para correcciones alternativas válidas antes de tratar la tasa de aprobación como señal de capacidad.

El corrector debe defender la tarea

Las auditorías de fugas no bastan cuando el código de puntuación es frágil. 75 de las 102 tareas corregidas tenían pruebas demasiado estrechas para aceptar una corrección correcta. Los correctores frágiles convierten correcciones correctas en falsos fallos, y los correctores laxos convierten correcciones rotas en falsos éxitos. El prompt dice hazlo funcionar, y el corrector dice hazlo funcionar exactamente así.

Convierte la tasa de aprobación en una señal de regresión

Una vez cerrados los canales y verificado el corrector, la tasa de aprobación puede señalar una regresión en los evals. Las ganancias deben provenir de un razonamiento mejor, no de entornos más laxos. Las caídas deben significar que la función empeoró, no que el eval por fin dejó de filtrar.

Guarda los artefactos de auditoría junto a la puntuación. Almacena el manifiesto de tarea limpio, el registro de red y los resultados de pruebas del corrector junto a cada tasa de aprobación. Cuando cambie la versión del modelo, compárala contra el mismo conjunto limpio. Los cambios de entorno requieren una auditoría fresca antes de comparar puntuaciones.