Resumen Técnico: Auditando la Auditoría – Cinco Modos de Fallo en las Auditorías de Validez de Benchmarks

1. Planteamiento del Problema

Los marcos de gobernanza (p. ej., la Ley de IA de la UE, el NIST AI RMF, el GB/T 45654 de China) exigen cada vez más que los proveedores de IA suministren evidencia de evaluación documentada, a menudo en forma de auditorías de validez de constructo basadas en perturbaciones. Estas auditorías aplican ediciones controladas a los ítems de los benchmarks para verificar que las métricas de rendimiento de un modelo cambien solo cuando el constructo subyacente cambia (p. ej., un giro semántico) y permanezcan estables bajo reescrituras de superficie.

El artículo argumenta que estos procesos de auditoría son, en sí mismos, sistemas de medición frágiles. Sus conclusiones pueden ser fabricadas silenciosamente por detalles de implementación invisibles en los números reportados. Un defecto en el proceso de auditoría no solo corrompe una puntuación de benchmark; desactiva la salvaguarda destinada a detectar fallos en el benchmark, sin dejar rastro en las métricas finales porque el lector confía en dichas métricas para decidir si confía en el benchmark. El problema central es que la evidencia de gobernanza actual carece de un protocolo para verificar la confiabilidad del propio proceso de auditoría.

2. Metodología

Los autores realizan un estudio de caso de auto-auditoría para demostrar que los procesos de auditoría son propensos a fallos silenciosos.

• Alcance: Dos modelos de pesos abiertos de 7B con ajuste de instrucciones (Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3) evaluados frente a cinco benchmarks de seguridad (TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest).
• Diseño: 10 celdas (2 modelos × 5 benchmarks), 200 ítems por benchmark, decodificación determinista, semilla única.
• Perturbaciones: Tres familias por ítem (formato, semántica, atributo) con tres perturbaciones cada una.
• Métrica: Ratio de Selectividad de Contraste (CSR), definido como $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$. Esto mide si las perturbaciones de atributos inducen cambios de puntuación mayores que las perturbaciones de superficie.
• Proceso: Los autores ejecutaron un proceso "legado", identificaron fallos, los repararon para crear un proceso "canónico" y volvieron a ejecutar la auditoría. Crucialmente, rastrearon toda la cronología de errores, incluyendo uno (F3c) introducido durante la fase de reparación.

3. Contribuciones Clave

A. Los Cinco Modos de Fallo (F1–F5)

El artículo propone una taxonomía no exhaustiva de fallos a nivel de proceso que son silenciosos (invisibles en los números reportados), realizados (encontrados en la práctica) y controlables (detectables mediante verificaciones específicas). Se categorizan en dos capas:

Capa de Aseguramiento de Software (Detectables mediante revisión de ingeniería):

1. F1: Perturbaciones de no-operación (no-op) silenciosas: La perturbación escribe en un campo que el evaluador no lee (p. ej., editar una cadena de pregunta mientras el evaluador solo lee las probabilidades de elección). Esto resulta en $\Delta = 0$ para la perturbación, inflando artificialmente las métricas de ratio.
2. F2: Artefactos de extracción por Regex: Usar regex para analizar la generación de texto libre mide la robustez de la regex en lugar del comportamiento del modelo. Si las perturbaciones alteran el estilo de generación, la capacidad de análisis (parseability) cae, y $\Delta_{fmt}$ rastrea la cobertura de la regex, no el comportamiento del modelo.
3. F4: Ruptura de emparejamiento de Bootstrap: El remuestreo independiente de los ítems originales y perturbados rompe el acoplamiento por ítem, inflando los intervalos de confianza y las estimaciones de varianza.

Capa de Fidelidad de Medición (Requiere razonar sobre el constructo del benchmark):
4. F3: Puntuación no fiel: El evaluador no implementa el protocolo previsto del benchmark.
* F3a (Convención invertida): Tratar una oración estereotípica como "correcta" debido a una carga ingenua (p. ej., CrowS-Pairs).
* F3b (Orden del Harness): Sesgo posicional en los cargadores (p. ej., TruthfulQA MC2 devolviendo índices correctos como $[0, \dots, k-1]$).
* F3c (Truncamiento del evaluador): Los tokens objetivo caen fuera de los log-probabilidades top-$k$ (p. ej., ToxiGen), causando que el evaluador recurra por defecto a una clase mayoritaria y produzca artefactos de $\Delta = 0$.
5. F5: Desajuste de Arquetipo de Métrica: Aplicar una métrica diagnóstica (diseñada para detectar giros) a un benchmark de invarianza (diseñado para no girar). Un CSR bajo en un benchmark de invarianza es ambiguo (¿benchmark roto o modelo justo?) y no puede resolverse mediante reparaciones de puntuación.

B. El Filtro de Debida Diligencia de Seis Puntos (G1–G6)

Un protocolo jerárquico para determinar la elegibilidad de la evidencia de auditoría. Una celda es solo "confirmatoria" si pasa los seis controles. El filtro incluye:

• G1: Auditoría fiel al evaluador (tasa de no-operación silenciosa < 20%, parseability $\ge$ 0.95).
• G2: Puntuación original por encima de la línea base.
• G3: Denominador no trivial (deltas de superficie $\ge$ 0.02).
• G4: Incertidumbre emparejada (bootstrap emparejado a nivel de ítem).
• G5: Divulgación de arquetipo (benchmark etiquetado como diagnóstico, de invarianza o mixto).
• G6: Control de regresión de reparación (inspección por celda y pruebas unitarias para las correcciones).

C. Protocolo de Cronología de Auto-Auditoría

Los autores proponen un protocolo de "retención y divulgación" que requiere que las auditorías publiquen una cronología de auto-auditoría (Recuadro 1) detallando cada error encontrado, su método de descubrimiento, la solución y el delta antes/después. Esto distingue un proceso "limpio" de uno donde los errores fueron absorbidos silenciosamente.

4. Resultados

En el estudio de caso de 10 celdas, cero celdas alcanzaron el estatus de "confirmatorio". El desglose fue:

• 3 No elegibles: Debido a F1 (CrowS-Pairs) o F5 (BBQ).
• 3 No validados por el evaluador: Debido a la falta de validación externa para los evaluadores de ToxiGen y XSTest.
• 2 Fallaron G2–G4: Debido a que no superaron los umbrales numéricos (puntuación base o umbrales de denominador).
• 2 Exploratorios: Pasaron G1–G4 pero se mantuvieron como no confirmatorios porque G5 y G6 fueron "propuestos" (no implementados aún como filtros obligatorios en esta entrega).

Hallazgo clave: Un fallo (F3c, truncamiento del evaluador) fue auto-introducido durante la reparación de F1. Solo se detectó tras inspeccionar los meta log-probabilidades por celda. Sin esta inspección, el proceso habría producido números plausibles y publicables que eran enteramente artefactos del error.

5. Significado y Reivindicaciones

El artículo posiciona sus contribuciones como suplementarias a la evidencia clásica de validez de constructo (estudios convergentes/discriminantes), no como un reemplazo.

• Reivindicación modesta: Los autores no pretenden demostrar que cualquier benchmark sea inválido o que F1–F5 sea una taxonomía completa. Declaran explícitamente que la taxonomía es "deliberadamente no exhaustiva".
• Argumento central: La principal contribución es un protocolo de retención. La evidencia de gobernanza no debe aceptarse como "de grado de aseguramiento" a menos que el propio proceso de auditoría haya pasado un filtro de debida diligencia y publicado una cronología de auto-auditoría.
• Implicación: Un número "limpio" en un reporte no garantiza un proceso confiable. Sin el filtro y la cronología propuestos, un proceso silenciosamente roto es indistinguible de uno robusto.

El artículo concluye con una única petición accionable: Cualquier auditoría que produzca evidencia basada en benchmarks para uso de gobernanza debe publicar su cronología de auto-auditoría (como mínimo los ocho campos del Recuadro 1) junto con sus números.