Por qué los modelos de IA son más confident cuando están más equivocados
Un eval harness contra ground truth sintético revela que los LLMs son más seguros exactamente cuando más se equivocan. Por qué la revisión cualitativa no basta y cómo medir precisión real.
Si has usado un modelo de lenguaje grande (LLM) en producción, probablemente ya lo has notado: a veces la IA te responde con una seguridad absoluta sobre algo completamente falso. Y lo peor es que no hay forma obvia de distinguir esas respuestas confidently wrong de las correctas.
Un artículo de VentureBeat describe exactamente este problema a través de la experiencia de un arquitecto empresarial que construyó un sistema de explicación de derivas en pipelines de datos. Su conclusión: la confianza expresada por los modelos no se correlaciona con su precisión. De hecho, son más confident cuando están más equivocados.
Por qué la evaluación cualitativa no detecta esto
El flujo de trabajo estándar para validar herramientas basadas en LLMs en empresas es cualitativo: alguien revisa una muestra de respuestas, las compara con su intuición sobre lo que parece razonable, y si todo suena bien, se aprueba.
Ese método detecta Outputs obviously wrong, mal formateados o fuera de tema. Pero no detecta respuestas que suenan autoritarias, usan un razonamiento plausible, identifican la causa raíz equivocada, y sin embargo son completamente incorrectas.
"Suena razonable" no es "es correcto". Son propiedades diferentes, y la revisión cualitativa no puede distinguirlas.
El problema con ground truth sintético
La solución propuesta es construir un eval harness: un sistema de evaluación que puntúa las respuestas del modelo contra ground truth con etiqueta conocida.
Para crear ese dataset de referencia, el autor introduce causas conocidas y controladas en un pipeline de datos de prueba: cambios de schema, bugs en lógica de transformación, cambios de comportamiento en sistemas origen. Luego registra exactamente qué introdujo y compara la explicación del modelo contra la causa real.
Los escenarios sintéticos deben parecerse lo suficiente a la realidad. Versiones iniciales eran demasiado limpias: la señal de drift era obvia de formas que los eventos de producción no son. Agregar ruido realista, señales superpuestas y casos con múltiples causas plausibles simultáneas fue lo que hizo el dataset predictivo.
La scoring function importa
Correcto/incorrecto binario no es suficiente cuando el modelo produce una lista ordenada de causas probables, no una única respuesta. El sistema de scoring evalúa dos dimensiones:
Presencia: ¿apareció la respuesta correcta en el output?
Rango: ¿cuán prominentemente fue rankeada la respuesta correcta frente a candidatos incorrectos?
Estas dos dimensiones se combinan en un weighted score que recompensa tanto encontrar la respuesta correcta como rankearla adecuadamente.
Qué se encontró
Los resultados fueron reveladores:
Escenarios de cambio de schema: funcionaban bien. El modelo identificaba cambios de schema upstream de forma fiable cuando la evidencia estaba presente y era distintiva.
Bugs en lógica de transformación: eran más difíciles. El modelo identificaba consistentemente la categoría correcta pero atribuía mal el cambio específico que causó el problema, especialmente cuando múltiples cambios ocurrían cerca.
Escenarios con señales superpuestas: los más difíciles. Cuando dos causas diferentes ocurrían cerca en el tiempo, producían la mayor tasa de explicaciones confidently wrong.
La implicación práctica
Para equipos desplegando herramientas basadas en LLMs en contextos empresariales — particularmente herramientas que influyen en cómo la gente investiga problemas, hace triage de alertas o toma decisiones de routing — la pregunta clave antes de producción es:
¿Hemos medido la precisión contra casos donde conocemos la respuesta correcta, o solo hemos revisado si los outputs nos parecen razonables?
Si la respuesta es la segunda opción, la herramienta ha sido testeada por fluidez y coherencia, pero no por corrección.
La construcción del dataset de ground truth sintético es la parte difícil y la que más vale la pena invertir. Obliga a definir precisamente qué significa "correcto" para un caso de uso específico, lo cual es un ejercicio útil independiente de la evaluación en sí. Sin esa definición, estás midiendo algo diferente a lo que intentas garantizar.