GitHub ha lanzado el estándar abierto ReviewBench para evaluar agentes de revisión de código, en un intento de abordar un problema fundamental de las herramientas de revisión basadas en inteligencia artificial: la dificultad de comparar los errores que detectan, los que pasan por alto y la cantidad de ruido que generan. El estándar está disponible para investigadores y equipos que desarrollan sistemas de revisión de código, y también permite introducir un sistema personalizado y compararlo con otros sistemas.
Un estándar basado en solicitudes de incorporación de cambios reales
GitHub diseñó el conjunto ReviewBench basándose en el análisis de la distribución de más de 103,9 millones de solicitudes de incorporación de cambios en la plataforma. El conjunto incluye 219 solicitudes de incorporación de cambios de 187 repositorios públicos con licencias de código abierto, cubre 19 lenguajes de programación y mantiene la distribución de lenguajes y tamaños de repositorios alineada con el patrón general de GitHub. No obstante, se volvió a ponderar el tamaño de los cambios para favorecer las solicitudes de tamaño mediano y grande que se pueden revisar, en lugar de concentrarse excesivamente en cambios pequeños en un solo archivo.
Lo que GitHub denomina «conjunto de verdad» no depende de una única fuente. Los posibles resultados se recopilaron a partir de revisores humanos, cambios posteriores realizados por los autores de las solicitudes, herramientas de análisis estático y varios modelos lingüísticos avanzados. Después de eliminar los resultados con solapamiento semántico, se evaluaron según un criterio unificado que establece que el resultado correcto debe ser correcto, relevante y no marginal. GitHub utiliza el modelo Claude Sonnet 5 como evaluador lingüístico y publica el rubric y la configuración de evaluación con el objetivo de reforzar la auditabilidad y la reproducibilidad.
Métricas que no penalizan el descubrimiento de errores nuevos
ReviewBench distingue entre dos familias de métricas. Las métricas grounded precision, grounded recall y grounded F1 miden la capacidad del sistema para detectar problemas ya presentes en el conjunto de verdad, lo que proporciona una comparación directa entre sistemas. Por su parte, las métricas augmented precision, augmented recall y augmented F1 también examinan los resultados que no coinciden con ningún problema conocido y otorgan crédito al sistema si el evaluador demuestra que se trata de un problema válido.
Esta distinción es importante porque un conjunto estático de errores no puede estar necesariamente completo; un agente nuevo podría detectar un problema que los autores del estándar no hayan identificado. GitHub utiliza grounded recall como indicador principal para comparar sistemas, mientras que las métricas ampliadas ofrecen un diagnóstico adicional de cada sistema.
Evaluación ajustable y auditable
Los resultados pueden dividirse según la gravedad y la categoría del problema, como corrección, seguridad, fiabilidad, mantenibilidad y pruebas. El estándar Fβ también permite cambiar el peso entre recall y precisión, de modo que el usuario puede priorizar una cobertura más amplia o un número menor de comentarios más precisos. Antes del lanzamiento, ingenieros sénior que no habían participado en la creación de los datos volvieron a etiquetar todos los resultados, y la tasa de acuerdo con los juicios de ReviewBench alcanzó el 96,6 %. GitHub afirma que fija las versiones de los datos, del evaluador y de la herramienta de coincidencia utilizadas en cada proceso de evaluación.
¿Qué demuestra en la práctica?
GitHub utilizó ReviewBench para evaluar versiones sucesivas de Copilot Code Review y afirmó que la tendencia de mejora o retroceso en las pruebas sin conexión coincidió con los experimentos de producción. En un experimento con un sistema de revisión que combina varias ejecuciones de distintos modelos, el estándar predijo un aumento de la precisión, el recall y el número de comentarios, así como una reducción del coste de revisión. La prueba A/B en producción siguió la misma dirección: la tasa de comentarios que llevaron a una modificación del código aumentó un 8,0 %, el recall un 13,6 % y el volumen de comentarios un 61 %, mientras que el coste por revisión disminuyó un 8,0 % frente al grupo de control. El estándar también predijo un aumento del 227 % en los comentarios críticos, frente al 262 % observado en producción.
La lectura editorial de certi.news: el valor más importante de ReviewBench no es el lanzamiento de una herramienta nueva, sino el intento de convertir la evaluación de los agentes de revisión de código en un proceso comparable y auditable, reconociendo que «más comentarios» no significa necesariamente una mejor revisión. No obstante, la propia fuente admite que los experimentos de producción siguen siendo la medida definitiva del impacto para el usuario, y que la dependencia de una parte de la evaluación de un evaluador lingüístico deja abierta la cuestión de los límites de la coherencia del juicio automatizado.
GitHub ofrece una versión de investigación inicial del estándar, con los datos, la metodología, la configuración del evaluador y una herramienta de ejecución autónoma. Los agentes pueden probarse con un conjunto de 25 solicitudes de incorporación de cambios y, posteriormente, ejecutar la evaluación completa sobre 219 solicitudes mediante tres rondas antes de solicitar la publicación del resultado en la clasificación.