En los últimos años, la evaluación de sistemas basados en inteligencia artificial se ha convertido en un pilar de la toma de decisiones empresariales. Equipos de producto, investigadores y directores de tecnología se apoyan en dashboards que muestran tasas de acierto, puntuaciones medias o porcentajes de aprobados para decidir si un nuevo modelo, un prompt ajustado o una actualización de un agente IA es mejor que la versión anterior. Sin embargo, existe un error metodológico muy extendido que puede convertir esos números en una trampa: comparar dos promedios como si fueran muestras independientes cuando en realidad provienen del mismo conjunto de ítems de prueba. Lo que parece una mejora sólida puede ser ruido, y lo que parece un empate puede esconder una regresión silenciosa en un subconjunto concreto de datos.
Imaginemos el escenario típico: tenemos 500 preguntas o casos de prueba. Ejecutamos el sistema A y obtenemos un 71,4 % de aciertos. Ejecutamos el sistema B y obtenemos un 74,0 %. La conclusión inmediata es que B es mejor. Sin embargo, ese razonamiento ignora el hecho crucial de que ambos sistemas respondieron exactamente a las mismas preguntas. Las respuestas no son independientes; están correlacionadas porque la dificultad de cada ítem es compartida. Una pregunta compleja, ambigua o con contexto extenso hará fallar a ambos sistemas con frecuencia. Esa correlación positiva reduce la varianza de la diferencia entre los dos sistemas, y si no se tiene en cuenta, se sobrestima la incertidumbre o, peor aún, se malinterpretan intervalos de confianza superpuestos como señal de que no hay diferencia significativa.
Este problema no es nuevo en el campo de la estadística, pero sorprende verlo repetido en informes de evaluación de IA, incluso en empresas con equipos de datos maduros. El origen está en tratar dos ejecuciones sobre el mismo conjunto de pruebas como si fueran dos experimentos con muestras distintas. La solución es tan elegante como simple: emparejar los resultados por ítem y analizar directamente las diferencias. Para evaluaciones binarias (aprueba/no aprueba), el test adecuado es el de McNemar, que se concentra únicamente en los ítems donde los sistemas discrepan. Si el sistema A acierta y B falla en 40 casos, y B acierta y A falla en 53, la pregunta estadística es si esa división 40-53 es compatible con una moneda equilibrada. Un test binomial exacto revelará si la diferencia observada es creíble o simplemente fruto del azar. En muchas ocasiones, esa brecha de 2,6 puntos porcentuales resulta no ser significativa.
Para evaluaciones con puntuaciones continuas (una nota de 0 a 1, una valoración en escala Likert, un tiempo de respuesta), el enfoque recomendado es el bootstrap emparejado. Se calcula la diferencia de cada ítem (B menos A), y luego se remuestrean esas diferencias con reemplazo para obtener intervalos de confianza sobre la media de la diferencia. Este método no asume normalidad y respeta la estructura de dependencia entre las dos mediciones. Lo importante es remuestrear los pares, no las columnas por separado, porque de lo contrario se rompe el emparejamiento y se vuelve al error de independencia.
Más allá del procedimiento técnico, hay una implicación cultural en los equipos de producto: la tentación de tomar decisiones mirando dos números uno al lado del otro es enorme. Los dashboards invitan a ello. Pero cuando se está evaluando un cambio que puede afectar a la experiencia de miles de usuarios, o cuando se decide si desplegar un nuevo agente IA en producción, la precisión estadística no es un lujo académico. Es una necesidad para evitar falsos positivos que lleven a invertir en cambios que no aportan valor, o falsos negativos que impidan detectar mejoras reales.
Un caso concreto que ilustra este riesgo lo viví al revisar una regresión en un proyecto de software a medida para un cliente del sector logístico. Se había modificado el prompt de un asistente conversacional para responder consultas sobre envíos. El nuevo prompt mostraba un 68,9 % de aciertos frente al 69,7 % del anterior. Al ver que los intervalos de confianza se solapaban, el equipo descartó la diferencia como ruido y siguió adelante con el cambio. Semanas después, los usuarios reportaban respuestas incorrectas en un subconjunto concreto de consultas sobre rutas internacionales. Al reanalizar los datos con un test emparejado, se descubrió que la diferencia no solo era significativa, sino que el intervalo de confianza de la delta estaba completamente por debajo de cero. El nuevo prompt era sistemáticamente peor en ese segmento, pero la media global lo ocultaba. Si desde el principio se hubiera aplicado un análisis emparejado, se habría detectado la regresión antes de llegar a producción.
El problema se agrava cuando se comparan múltiples métricas a la vez. En las evaluaciones modernas de ia para empresas no solo se mide la tasa de acierto, sino también la fidelidad, la seguridad, la latencia, el cumplimiento de formato, y varios criterios de rúbrica. Cada métrica recibe su propio test, y si no se corrige por comparaciones múltiples, la probabilidad de encontrar al menos un falso positivo crece de forma dramática. Con doce métricas y un umbral alfa de 0,05, la probabilidad de tener un falso positivo es aproximadamente del 46 %. Por eso es recomendable aplicar procedimientos como el de Benjamini-Hochberg para controlar la tasa de falsos descubrimientos, reservando correcciones más estrictas para las métricas que actúan como puertas de lanzamiento.
En Q2BSTUDIO, cuando desarrollamos aplicaciones a medida con componentes de inteligencia artificial, incorporamos estas buenas prácticas desde la fase de evaluación. Sabemos que un cliente que confía en un dashboard mal construido puede tomar decisiones erróneas que afecten a su operativa. Por eso, en nuestros proyectos de servicios cloud aws y azure, donde desplegamos modelos y agentes IA, aseguramos que los pipelines de evaluación incluyan tests emparejados y corrección por comparaciones múltiples. También aplicamos este rigor en proyectos de servicios inteligencia de negocio con power bi, donde la comparación de indicadores antes y después de un cambio debe hacerse con metodologías estadísticas sólidas.
La ciberseguridad tampoco escapa a esta problemática. Al evaluar la efectividad de un sistema de detección de intrusiones entrenado con aprendizaje automático, se comparan tasas de acierto sobre el mismo conjunto de tráfico de prueba. Si no se emparejan los resultados, se corre el riesgo de seleccionar un modelo que no mejora realmente la detección, o de descartar uno que sí lo hace. En este ámbito, un error estadístico puede traducirse en vulnerabilidades no detectadas.
El artículo original que inspiró esta reflexión (usado únicamente como referencia conceptual) expone con claridad que la clave está en tratar los datos como pareados cuando comparten ítems. Aconseja reportar el tamaño del efecto y un intervalo de confianza sobre la diferencia, no dos promedios independientes. Y recuerda que incluso el bootstrap emparejado tiene limitaciones cuando los ítems no son independientes entre sí (por ejemplo, varias preguntas extraídas del mismo documento). En esos casos, la solución es remuestrear a nivel de grupo o usar modelos mixtos, aunque la práctica aún no está estandarizada.
En mi experiencia trabajando con equipos que desarrollan agentes IA para atención al cliente o automatización de procesos, la recomendación práctica es clara: almacenar siempre los resultados a nivel de ítem para cada ejecución. No basta con guardar la media. La pareja (resultado de A, resultado de B) para cada caso es la materia prima del análisis correcto. Y cuando eso no es posible, hay que ser honesto sobre la limitación y considerar cualquier decisión basada en promedios no pareados como incierta.
Si quieres profundizar en cómo aplicar estas técnicas en tus propios sistemas de evaluación, te recomiendo explorar cómo en Q2BSTUDIO integramos estas metodologías en soluciones de inteligencia artificial para empresas, donde el rigor en la medición es tan importante como la potencia del modelo. También cubrimos aspectos de desarrollo de aplicaciones a medida que requieren evaluaciones fiables para tomar decisiones de despliegue con confianza.
En definitiva, comparar evaluaciones por su tasa media de acierto asumiendo independencia es un error que puede costar caro. La buena noticia es que la solución existe, es bien conocida y no es compleja de implementar. Solo requiere un cambio de mentalidad: dejar de mirar dos números sueltos y empezar a analizar la diferencia dentro de cada par. El salto de calidad en la toma de decisiones lo merece.
