Kappa de Cohen: cuándo confiar en un revisor IA

Validar un juez de IA no se trata de que el revisor luzca bien, sino de medir cuánto coincide con las decisiones que los humanos ya tomaron. Aquí aprenderás a construir tu propio conjunto de datos, comparar respuestas y decidir, con evidencias, cuándo la IA puede bloquear un PR y cuándo necesita criterio humano. Es contenido clave para quien automatiza revisiones de código con responsabilidad.

Por qué debes reemplazar impresiones por evidencias al validar el revisor

En esta etapa ya tenemos el revisor organizado y estructurado. Se ve muy bien, pero eso no es un criterio. Como ya sabemos hacer, cambiamos las impresiones por evidencias.

En la metodología de Valls, la única forma de confiar en un juez de IA es medir en qué medida coincide con lo que los humanos decidieron antes. Y aquí aparece la parte incómoda: el conjunto de datos con el que vas a validar no existe hasta que tú lo construyas.

Nadie te va a entregar un archivo con los PR marcados con la verdad. Eres tú quien lo crea. Recoges los PR cerrados de tu proyecto, registras lo que los humanos decidieron y eso se convierte en tu criterio de verdad [00:33].

¿Cómo se crea un dataset para validar un juez de IA? Recoges los pull requests cerrados de tu proyecto, registras las decisiones humanas que ya se tomaron y usas ese historial como criterio de verdad para comparar contra la IA.

Qué mide la concordancia simple y el kappa de Cohen

Al comparar las respuestas de la IA con las respuestas humanas, evalúas dos cosas concretas. Y cada una responde una pregunta distinta.

• La concordancia simple: el porcentaje de casos en que la IA y el humano dijeron lo mismo.
• El kappa de Cohen: te dice si la IA entendió realmente el problema o si solo acertó por puro azar.

El kappa de Cohen varía entre cero, que es puro azar, y uno, que representa concordancia perfecta. Como regla general, un kappa inferior a 0,2 es débil y uno superior a 0,8 es muy bueno [01:15].

¿Qué es el kappa de Cohen? Es una métrica que mide si dos evaluadores coinciden más allá del azar. Va de 0 (puro azar) a 1 (concordancia perfecta). Debajo de 0,2 es débil y arriba de 0,8 es muy bueno.

Por qué el revisor no es bueno ni malo en general

Aquí viene lo interesante: el revisor no es bueno o malo en general. Su precisión cambia radicalmente según la categoría del problema.

En cuestiones locales y objetivas, como la falta de una verificación de null, la concordancia con el revisor humano suele ser del 95%, con un kappa altísimo. La IA es muy confiable ahí.

En temas como tests faltantes o estilo, la concordancia ronda el 85%. Pero en categorías difusas y de alto contexto, como decidir si algo es un problema de seguridad, la concordancia baja hasta el 30% [01:50].

Cómo funciona la evaluación paralela entre humano e IA

Como no siempre tenemos 40 PR reales, históricos y etiquetados, en la clase se usa un conjunto creado para Payments YC. La metodología fue directa y replicable.

Se tomó el diff original y se comparó lo que un humano dijo, entre comillas, porque en realidad el humano nunca dijo nada, con lo que la IA dice sobre eso mismo. A eso lo llamamos evaluación paralela [02:35].

Luego se pidió a la IA un resumen de los acuerdos: qué dijo el humano y qué dijo la IA, en el mismo formato definido en la clase anterior. Los PR históricos se agruparon por categoría, aunque cada categoría podría haber quedado como un PR independiente.

Mantener el mismo formato tanto para la IA como para el humano es lo que permite establecer la equivalencia y comparar de forma objetiva.

Cómo genera el script measure agreement el reporte por categoría

Para comparar lo que dijo cada uno hay que hacerlo de forma objetiva. Por eso se preparó un script llamado measure agreement, que compara los dos resúmenes y genera las mediciones [03:30].

Al ejecutarlo obtienes un reporte con la concordancia simple y el kappa por categoría. Tenerlos separados así permite tomar una decisión de política para cada tipo de problema.

• En la categoría test, donde no hay tanta concordancia, la política es que se requiere un humano para decidir.
• En seguridad, que aparece al 100%, la política es block: la IA puede bloquear las detecciones cuando las encuentre.
• Otras categorías resultan mucho más automatizables según cómo hagas tu revisión.

Todo esto depende de tus políticas y de cómo quieras revisar tu propio código.

Qué significan block, warn y human required en tu política de revisión

Estas tres etiquetas convierten la tabla del reporte en una decisión de arquitectura, no en un adorno. Definen qué tanto poder le das a la IA en cada categoría.

1. block: la IA puede bloquear automáticamente las detecciones que encuentre.
2. warn: la IA comenta la detección, pero no bloquea de forma automática.
3. human required: exige una decisión humana antes de hacer cualquier cosa.

Esta decisión se basa en evidencias y es justo lo que necesitarás al integrarlo en el CI [04:40]. Las reglas de kappa alto pueden configurarse para bloquear un PR automáticamente, mientras que las de kappa bajo solo emiten un aviso y piden revisión humana adicional.

Así el revisor deja de ser bueno o malo en general y pasa a tener un mapa de confianza por categoría. La arquitectura responsable hace esa diferencia: no estamos testeando PR con IA, estamos decidiendo cuándo una detección puede bloquear, cuándo solo debe alertar y cuándo necesita, sin excepción, criterio humano.

Con esto cerramos el módulo del revisor. Ya sabes generar tests con rigor y calibrar un evaluador que revisa código con evidencias. En el siguiente módulo cambiamos el enfoque: dejaremos que la IA trabaje sobre código que no conoce, sin pedirle nada específico, para que encuentre bugs y vulnerabilidades sin alucinar, con escepticismo, como un auditor real.

¿Ya empezaste a generar tus propios reportes históricos por categoría? Cuéntame en los comentarios qué políticas aplicarías en tu proyecto.