Métricas de autosanación: cuando una evaluación verde esconde una regresión real
En nuestra evaluación de profundidad en múltiples documentos (2026-06-04, GLM-4.7), una métrica de mapeo de cláusulas obtuvo una puntuación casi perfecta de 1.0, mientras que el análisis por documento del modelo cayó a aproximadamente un tercio de su profundidad independiente. La métrica obvia fue la que mintió.
La cifra más peligrosa en una evaluación es aquella que permanece en verde mientras el producto se rompe. Nosotros tenemos una. En la ejecución exacta en la que la salida por documento del modelo cayó a aproximadamente un tercio de su profundidad independiente, una métrica de paridad obtuvo una puntuación casi perfecta de 1.0. La métrica no era ruidosa ni estaba mal calibrada. Medía algo equivocado, de una manera que el modelo podía satisfacer sin hacer el trabajo. Llamamos a esto una métrica de autosanación, y encontrar la nuestra fue lo más útil que nuestro conjunto de evaluaciones hizo esa semana.
Qué estábamos probando
Una tarea común en nuestro producto es el análisis de múltiples documentos: un usuario sube varios documentos de políticas a la vez y le pide al asistente que mapee cada uno frente a las cláusulas de un marco, por ejemplo, los controles del Anexo A de la norma ISO/IEC 27001:2022. Un cliente nos dijo que analizar varios documentos en una sola solicitud producía resultados más delgados que analizar cada documento por separado. Antes de cambiar nada, construimos una evaluación para reproducir y medir esa brecha (ticket interno ISM-549, ejecución de referencia 2026-06-04).
La configuración fue deliberadamente fiel a la producción. Modelo: GLM-4.7, servido a través de OpenRouter, coincidiendo con la ruta de solicitud evaluada. Fixtures: siete políticas sintéticas y anonimizadas (sin contenido de clientes), diseñadas como el escenario real que desencadenó la queja. La pregunta que la evaluación debía responder era simple: ¿cada documento recibe la misma profundidad analítica cuando se analizan siete juntos que cuando cada uno se analiza por separado?
La primera métrica, y por qué se autosanó
La forma obvia de puntuar "¿se analizó cada documento?" es contar las filas de mapeo de cláusulas. El análisis independiente produce una tabla con una fila por cláusula, por lo que el análisis agrupado también debería hacerlo. Probamos exactamente eso primero.
La paridad de filas regresó en aproximadamente 1.0. Dadas cláusulas numeradas explícitas y una instrucción de "mapear cada cláusula", GLM-4.7 mantiene diligentemente una fila por cláusula incluso cuando se le proporcionan siete documentos a la vez. Según esa métrica, nada estaba mal. La evaluación estaba lista para aprobar.
El producto era visiblemente peor. Las filas estaban presentes; el análisis alrededor de ellas había desaparecido. Por sí sola, cada fila de cláusula incluía una explicación, las fortalezas, las brechas y un resumen breve. Agrupado, el modelo mantuvo el esqueleto y despojó el músculo: la misma forma de tabla, pero mucha menos de los razonamientos por cláusula. La métrica se había autosanado. La salida satisfacía "una fila por cláusula" mientras caía gran parte del análisis por cláusula, y un conteo de filas no puede distinguir un análisis completo de uno vacío.
Lo que mostró una métrica mejor
Así que dejamos de puntuar la estructura y comenzamos a puntuar la sustancia. La métrica principal se convirtió en la paridad de volumen de contenido: caracteres de salida agrupados divididos por la suma de los caracteres de salida independientes, con una puerta de aprobación en 0.6. En la ejecución de referencia del 2026-06-04 (GLM-4.7, dos muestras):
| Medida | Muestra 1 | Muestra 2 |
|---|---|---|
| Paridad de volumen de contenido | 0.34 | 0.35 |
| Caracteres independientes | 48,263 | 47,651 |
| Caracteres agrupados | 16,201 | 16,609 |
| Paridad de filas de mapeo de cláusulas | 1.00 | 0.98 |
| Juez LLM: documentos calificados como no diluidos | 0 de 7 | 0 de 7 |
En la misma ejecución de referencia del 2026-06-04, un proxy de profundidad a nivel de token contó la misma historia: aproximadamente 2,747 tokens de salida para un solo documento, frente a aproximadamente 595 tokens por documento cuando los siete estaban agrupados, una relación por documento de 0.22.
Tres detalles importan aquí. La paridad de volumen de contenido se situó en 0.34, muy por debajo de la puerta de 0.6. Un juez LLM independiente, al que solo se le pidió calificar el análisis de cada documento como diluido o no, calificó 0 de 7 documentos como no diluidos en ambas muestras. La paridad de filas, la métrica que casi enviamos sin darnos cuenta, promedió 0.99 en las dos muestras (de 0.98 a 1.00). Las tres señales de sustancia apuntaron en la misma dirección: paridad de volumen de contenido en aproximadamente un tercio, el proxy de tokens aún más bajo en 0.22 por documento, y el juez calificando cada documento agrupado como diluido. El único instrumento que discrepó fue el conteo estructural de filas.
Por qué ocurre, y los límites de lo que sabemos
Nuestra interpretación de los datos es que GLM-4.7 se autoasigna su esfuerzo entre los documentos en una sola decodificación: al pedirle que realice siete análisis en una sola respuesta, distribuye un presupuesto aproximadamente fijo de manera delgada en lugar de producir siete análisis completos. No instrumentamos los internos del modelo, por lo que esto es una descripción del comportamiento que medimos, no un mecanismo probado, y es específico de este modelo y forma de solicitud. Dos hechos de alcance son fundamentales. La regresión aparece a escala de producción: se manifiesta con siete documentos, no con dos, por lo que una prueba rápida con una entrada pequeña habría aprobado sin problemas. Y no se reprodujo cuando ejecutamos los mismos fixtures contra un modelo de vanguardia en una API directa. La regresión apareció solo en el modelo exacto y la ruta de solicitud que evaluamos y enviamos, lo que es todo el argumento para evaluar la ruta que realmente ejecutas en lugar de un sustituto conveniente.
Por qué esto es peor en cumplimiento que en otros ámbitos
En la mayoría de los productos, "salida más superficial" es un detalle de calidad. En nuestros flujos de trabajo de cumplimiento no es cosmético: una tabla de mapeo de controles con cada fila presente y sin análisis parece completa en una captura de pantalla mientras le da al auditor ninguno de los razonamientos por cláusula que necesitarían para confiar en ella. Eso es lo que hace que una métrica de autosanación sea realmente peligrosa en nuestro dominio. No solo era imprecisa. Era verde precisamente en el modo de fallo que más importa en nuestro ámbito: un entregable que parece confiable con la sustancia eliminada en silencio.
La solución que surge de esto es darle a cada documento su propia pasada de profundidad completa en lugar de agrupar los siete en una sola decodificación, y la evaluación pasa una vez que lo hace. Pero la solución es la parte fácil. No podríamos haberla construido mientras nuestra métrica principal insistía en que nada estaba roto. El cambio de métrica tuvo que llegar primero, porque no puedes reparar lo que no puedes ver.
Cómo detectar una métrica de autosanación
Una métrica de autosanación es cualquier métrica que un modelo puede satisfacer sin realizar el trabajo subyacente. Las métricas estructurales son las más propensas a ello: conteos de filas, conteos de elementos, "JSON válido", "todos los campos requeridos presentes", encabezados de sección. Son baratas de calcular y fáciles de engañar, a menudo por el modelo en lugar de por ti. Antes de confiar en una, realiza estas verificaciones:
- Punta la sustancia, no solo la forma. Si una métrica solo verifica la estructura (filas, campos, encabezados), combínala con una que verifique el contenido (caracteres, tokens o un juez que califique la exhaustividad). La forma es necesaria, pero nunca suficiente.
- Añade un instrumento independiente. Un juez LLM económico que califique la calidad y discrepe con tu métrica principal es la señal que buscas. La concordancia es corroboración; una discrepancia significa que tu métrica estructural probablemente se está autosanando.
- Prueba a escala de producción. Una regresión que solo aparece con siete documentos aprobará con dos. Dimensiona tus fixtures como la entrada real, no como una prueba unitaria.
- Prueba el modelo y la ruta que envías. Nuestra dilución no se reprodujo en un modelo diferente ni en una API directa. Un proxy más fácil de ejecutar es un proxy que puede perder el error que solo tiene tu ruta de producción.
- Pregunta cuál es la salida más barata para aprobar. Si un modelo puede satisfacer tu métrica haciendo casi nada del trabajo real, asume que eventualmente lo hará. Diseña la métrica de manera que la forma más barata de aprobar sea realizar realmente la tarea.
La evaluación hizo su trabajo al final, pero solo después de dejar de confiar en la cifra halagüeña. Cuando una métrica está en verde, la pregunta más útil no es "¿estamos aprobando?" sino "¿podría el modelo aprobar esto sin hacer el trabajo?". Si la respuesta es sí, la métrica se está autosanando, y lo seguirá haciendo hasta que sea un cliente quien lo note.
Las cifras anteriores son de nuestra línea base interna de paridad de profundidad en múltiples documentos, ejecutada el 2026-06-04 con GLM-4.7 a través de OpenRouter, y son puntuales según esa fecha. Contexto del marco: ISO/IEC 27001:2022, Anexo A.