La prueba de simetría: implementar una corrección en el prompt que no puedes reproducir

No siempre puedes demostrar que una corrección en el prompt funciona. Algunos fallos de producción solo aparecen con el contexto completo que los produjo, y ningún fixture local los reproduce. Cuando eso ocurre, la pregunta honesta no es "¿la corrección tiene éxito?", sino "¿mi cambio es distinguible de la varianza aleatoria del modelo entre ejecuciones?". Si la respuesta es no, el cambio es lo suficientemente seguro como para implementarse, aunque nunca hayas visto que corrija el error. Llamamos a esta verificación prueba de simetría, y es cómo un cambio en el prompt que nunca pudimos hacer fallar superó nuestro control de calidad.

Todo lo que sigue proviene de una evaluación interna, fechada el 2026-07-09, realizada con GLM-5.2, el modelo que usamos para el chat: una suite de regresión ciega A/B sobre toda la superficie de chat. Las métricas son nuestras, medidas en nuestros propios fixtures, en esa fecha.

El error que no se reproducía

En una semana, observamos dos defectos en la generación de documentos en la salida de políticas en alemán. En el primero, el asistente entregó una política cuyas secciones de nivel superior estaban numeradas del 2 al 6, sin sección 1. En el segundo, un archivo adjunto referenciado nunca llegó al modelo, y en lugar de indicarlo, el asistente fabricó una versión "revisada" distorsionada que el lector interpretó como una enorme truncación, sin revelar que en realidad no había visto el documento.

Escribimos una regla para cada caso en el prompt: una invariante de numeración (las secciones de nivel superior comienzan en 1 y no tienen huecos) y una regla anti-fabricación (si el documento referenciado no está presente, solicítalo; no lo inventes). Luego intentamos reproducir los fallos originales con el antiguo prompt para ver si las nuevas reglas los corregían.

El defecto de numeración no se reprodujo. En más de veinte generaciones con el antiguo prompt, incluyendo la forma del mensaje de producción que desencadenó el informe, GLM-5.2 comenzó siempre en 1. El fallo no aparecía sin el contexto más completo que llevaba la sesión en producción: memorias acumuladas del usuario, un hilo largo de múltiples turnos y el modo de razonamiento activado. Nuestra interpretación es que uno o varios de estos elementos son necesarios para desencadenarlo. El arnés de una sola ejecución local no los incluía, y el error simplemente no estaba allí.

Esta es la trampa. Teníamos una corrección para un error que no podíamos invocar. No podíamos demostrar que la corrección mejoraba nada, porque no había nada roto que mejorar en el arnés. Implementar por fe no es evidencia. Bloquear indefinidamente porque no puedes recrear el fallo no implementa nada. Ambas opciones son incorrectas.

Replanteamiento: delimitar el radio de impacto, no perseguir la corrección

La regla reside en el prompt del sistema en cada turno de chat, por lo que su radio de impacto no es la "numeración de documentos". Es cada comportamiento que tiene el asistente: preguntas-respuesta sobre marcos normativos, mapeo entre marcos, descargos legales, negativas, salida multilingüe, tono. Una edición en el prompt dirigida a un modo de fallo puede silenciosamente dañar uno no relacionado. Ese es el riesgo que merece ser medido, y a diferencia del error original, es medible en entorno local.

Así que dejamos de intentar demostrar que la corrección funcionaba y empezamos a intentar delimitar el riesgo que conllevaba el cambio. El diseño: una evaluación de regresión ciega A/B sobre toda la superficie de chat, comparando el antiguo prompt con el nuevo en entradas idénticas.

• 42 fixtures que abarcan preguntas-respuesta sobre cumplimiento, asesoramiento, mapeo entre marcos, redirecciones de servicio, negativas de seguridad, descargos legales, salida en alemán y francés, tono, generación de documentos y fixtures dinámicos que incluyen las secciones de instrucciones personalizadas y archivos anclados que tienen los usuarios reales.
• 252 generaciones, formando 126 pares antiguo-versus-nuevo (tres muestras por fixture), todas con GLM-5.2, 2026-07-09.
• Cegado. Cada par se presenta como A/B con una etiqueta aleatorizada por semilla. Un manifiesto contiene el mapeo real antiguo/nuevo y nunca se muestra a los evaluadores.
• Dos capas de evaluación. Una capa determinista verifica condiciones debe y no debe en los fixtures controlados (las redirecciones al centro de ayuda se activan, los descargos legales se activan, los intentos de extracción del prompt son rechazados, las umlauts se conservan, se cumplen las longitudes mínimas). Una capa cualitativa ciega hace que los evaluadores lean cada par sin saber qué brazo es cuál ni qué cambió, y clasifican como equivalente, A mejor o B mejor con una etiqueta de materialidad.

La capa determinista salió limpia: cero respuestas fallidas en ambos brazos, cero fallos asimétricos. Nada de lo que la regla pretendía proteger se rompió en ningún lado.

La capa cualitativa es donde está el movimiento interesante.

La prueba de simetría

Los evaluadores ciegos calificaron 118 de los 126 pares como equivalentes. De los 8 restantes, 7 presentaban una diferencia material y 1 una diferencia menor no material. En una lectura ingenua, siete divergencias en una evaluación de seguridad es un fallo.

Es una lectura incorrecta, y la razón es la dirección. Una diferencia material tiene un signo: o el nuevo brazo era peor o el antiguo brazo era peor. Si tu cambio en el prompt está causando regresiones, las diferencias materiales se inclinan en una dirección, hacia nuevo peor. Si son simplemente la varianza aleatoria del modelo y no tienen nada que ver con tu cambio, caen en ambos brazos a tasas aproximadamente iguales. Por lo tanto, no solo cuentes las diferencias materiales. Des-ocúltalas y cuenta la dirección.

Lo hicimos. Los siete se dividieron en tres nuevo peor, cuatro antiguo peor. Tres contra cuatro es lo más cercano a un empate que siete puede ser, el patrón que esperarías de la varianza aleatoria entre ejecuciones en lugar de una regresión direccional. Ninguno de los siete tenía una conexión plausible con una regla de numeración de documentos:

Diferencia material	Brazo peor	Lo observado
Identidad de cláusula ISO 27001	nuevo	A.8.2 leída como un control de evaluación de riesgos (correcto en las otras dos muestras de este fixture)
Segmentación PCI DSS	nuevo	segmentación sobrevalorada como estrictamente requerida
Segmentación PCI DSS	antiguo	un "Apéndice A1 requisito de segmentación" fabricado
Documento en alemán (fuga CJK)	antiguo	un token chino suelto en texto de cierre en alemán
Documento en alemán (fuga CJK)	antiguo	caracteres chinos en una sección de resumen en alemán
Instrucción de concisión	nuevo	rompió una instrucción personalizada "extremadamente concisa"
Instrucción de concisión	antiguo	rompió una instrucción personalizada "extremadamente concisa"

El más vívido, nuestro único ejemplo persistente, son las fugas CJK: en dos de nuestros fixtures en alemán, la salida contenía un token chino suelto (en un caso los caracteres para "información de seguridad") en un documento de otro modo en alemán. Ese comportamiento de fuga de tokens ha aparecido en ambos brazos en nuestras ejecuciones en alemán. Aquí ambas instancias cayeron en el brazo antiguo. Si la nueva regla estuviera degradando la salida en alemán, esperarías que estuvieran en el brazo nuevo; no lo estaban.

Los casos de precisión regulatoria apuntan en la misma dirección. En ISO/IEC 27001:2022 (publicado el 25 de octubre de 2022), el control A.8.2 del Anexo A es "Derechos de acceso privilegiado"; una muestra del brazo nuevo lo leyó como un control de evaluación de riesgos, y lo hizo correctamente en las otras dos muestras de ese fixture. Según PCI DSS v4.0 (PCI Security Standards Council, marzo de 2022), la segmentación de red no es un requisito absoluto, es una técnica de reducción de alcance que el Consejo describe como una forma de sacar sistemas del alcance de evaluación, no un control obligatorio; una muestra del brazo nuevo sobrevaloró la segmentación como requerida, y una muestra del brazo antiguo inventó que el "Apéndice A1" es un requisito de segmentación. El Apéndice A1 en realidad son los requisitos adicionales para proveedores de servicios multiinquilino. Estos son los tipos de fluctuaciones factuales que un modelo probabilístico produce en preguntas de dominio complejo, y en esta ejecución cayeron en ambos brazos, no concentrados en el nuestro.

Mientras tanto, los comportamientos que el cambio pretendía corregir se mantuvieron en ambos brazos a lo largo de toda la evaluación: cada par de archivo faltante pidió el documento en lugar de fabricarlo, y cada par de numeración produjo una estructura sin huecos. En toda la evaluación, los 126 pares ciegos más los barridos deterministas sobre la misma superficie, no encontramos ningún fallo atribuible al cambio.

Qué esto prueba y qué no prueba

Sé preciso con la afirmación, porque es fácil exagerar. La evaluación muestra ninguna regresión direccional en este tamaño de muestra, no que la corrección funcione. Nunca demostramos que la regla de numeración corregía el error de numeración, porque el error necesita el contexto de producción que no pudimos recrear. La regla se implementa sobre dos pilares: la forense de producción que hace legible el fallo y una señal de no regresión que muestra que el cambio no perturba nada más. Esa es una afirmación más débil que "reproducimos el error y vimos que la corrección lo eliminaba", y es la afirmación más sólida que permite la situación.

Los límites son reales y vale la pena enunciarlos claramente. Un sesgo direccional grosero se mostraría con tres muestras por fixture; uno sutil no, ya que un sesgo de 55/45 se oculta en este tamaño de muestra, y tres muestras por 42 fixtures están agrupadas, no son 126 ensayos independientes. No ejecutamos un brazo de control antiguo-versus-antiguo, por lo que la división tres-cuatro es nuestra mejor estimación de ruido basal, no una medición basal, y sin un margen de equivalencia establecido de antemano esto es una señal de no regresión direccional, no una prueba formal de no inferioridad. Los fixtures son de un solo turno, por lo que una interacción entre la nueva regla y un hilo largo de producción queda fuera de alcance, que es exactamente el contexto que necesitaba el error original. Una división simétrica es evidencia de que el cambio no empujó las salidas en una dirección, no prueba de que sea inocuo. Lo que la prueba te da es una lectura concreta del radio de impacto cuando la alternativa era una corazonada.

La lista de verificación portátil

Cuando tengas una corrección en el prompt para un error de producción que no puedes reproducir en entorno local, no lo implementes por fe y no lo congeles. Delimita el cambio en su lugar:

• Separa las dos preguntas. "¿La corrección funciona?" necesita el error que no puedes recrear. "¿El cambio es seguro?" no. Responde la que puedas.
• Dimensiona el radio de impacto con honestidad. Una regla en un prompt del sistema compartido toca cada comportamiento, no solo el objetivo. Construye fixtures que abarquen toda la superficie, incluyendo las variantes de instrucciones personalizadas y contexto anclado que tienen los usuarios reales.
• Ejécútalo ciego y en pares. Mismas entradas, antiguo versus nuevo, etiquetas A/B aleatorizadas por semilla y un manifiesto que los evaluadores nunca ven. El cegado es lo que evita que puntúes el brazo que esperas que gane.
• Cuenta la dirección, no solo la diferencia. Des-oculta las diferencias materiales y verifica el signo. Asimétrico hacia nuevo peor es una regresión. Una división aproximadamente equilibrada entre ambos brazos es el patrón que aprueba un cambio con este nivel de evidencia.
• Añade un control repetido si el margen es ajustado. Un brazo antiguo-versus-antiguo mide la varianza basal directamente, por lo que estás comparando tu cambio contra un número en lugar de una suposición.
• Mantén un suelo determinista. Empareja la lectura cualitativa con verificaciones duras de debe y no debe sobre los comportamientos que nunca deben romperse, para que un veredicto de ruido simétrico no tape un invariante realmente roto.
• Declara la afirmación que realmente ganaste. Di "no hay regresión medible", no "la corrección funciona", cuando la no regresión es todo lo que demostraste.

El instinto cuando un error no se reproduce es seguir intentando recrearlo hasta que aparezca. A veces nunca lo hará, y el esfuerzo se gasta en la pregunta equivocada. Si la corrección se implementa depende de si tu cambio es más fuerte que la varianza propia del modelo. Mide eso directamente, y una edición en el prompt que nunca pudiste ver que tuviera éxito se convierte en una que aún puedes estar seguro de que es segura.