Pruebas de regresión automatizadas para LLM personalizados en 2026

Notas del ciclo de releases — Parte 7

El viernes a las 4:47 PM lanzaste un ajuste de un carácter en un prompt. La puntuación agregada de la evaluación pasó de 0.873 a 0.871 — bien dentro del piso de ruido. El lunes por la mañana tu cola de soporte está en llamas por una clase de consultas que dejaste de mirar hace seis meses porque eran estables.

Nada en el modelo regresionó. El modelo es el mismo modelo. La evaluación se desplazó debajo de ti. Seis meses de crecimiento lento en un segmento de clientes nunca llegaron al dataset dorado, el prompt del juez se calibró por última vez contra humanos en octubre, y el índice de recuperación se reconstruyó silenciosamente el miércoles pasado sobre un modelo de embedding actualizado.

Esto es lo que señalaba la entrada 6 — el modelo es la respuesta correcta aproximadamente una alerta de cada siete. Lo que significa que tu suite de regresión tiene que detectar deriva en sí misma, no solo en el modelo. Esta entrada es la suite.

¿Qué son realmente las pruebas de regresión para un LLM personalizado?

Las pruebas de regresión de software afirman output == expected para entradas fijas. Funcionan porque la función es determinista.

Un modelo de lenguaje no es una función en el mismo sentido. El mismo prompt a temperatura > 0 produce una distribución de completaciones válidas, y “válido” es multidimensional: ¿respondió la pregunta?, ¿está la respuesta fundamentada en el contexto recuperado?, ¿se mantuvo dentro del marco de seguridad?, ¿volvió dentro del presupuesto de latencia? Entonces, hacer pruebas de regresión a un LLM personalizado significa medir la distribución del comportamiento contra una distribución base congelada — a través de los segmentos que te importan, con jueces calibrados contra humanos, sobre entradas que se parezcan a tu tráfico de producción.

Tres cosas tienen que estar en su sitio antes de que cualquiera de estas sea significativa:

1. Un dataset dorado que se parezca a producción a nivel de segmento, no en agregado.
2. Un juez calibrado — no “usamos GPT-5 como juez”, sino “medimos Spearman ρ ≥ 0.7 frente a tres evaluadores humanos, refrescado la semana pasada”.
3. Un manifiesto base — los pesos exactos del modelo, la plantilla del prompt, el índice de recuperación y la versión del juez que produjeron las puntuaciones registradas. Sin esto no puedes saber si la puntuación se movió porque cambió el modelo o porque cambió la regla.

Divinci ejecuta las tres como objetos de primera clase, encadenados por hash, puntuados en cada commit. El resto de esta entrada es cómo ensamblarlos.

Por qué la mayoría de las suites de regresión de LLM no detectan regresiones reales

El modo de fallo dominante en 2026 para LLM personalizados es lo que el equipo de Sigma Inference de Tianpan llamó la Mentira de Semver en su postmortem de abril de 2026^[1]: una métrica agregada se mantiene plana o mejora, mientras uno o dos segmentos de producción regresionan silenciosamente. El segmento estaba por debajo del 5% del tráfico cuando se diseñó la prueba, así que nunca entró en el dataset dorado; seis meses después es el 12% del tráfico, el modelo se degradó sobre él, y el número agregado nunca iba a notarlo.

Hemos revisado todos los postmortem públicos de releases de LLM de los últimos dieciocho meses y el patrón se repite: la suite estuvo en verde porque estaba puntuando lo equivocado. Concretamente:

• El dataset dorado fue escrito a mano por el equipo en el lanzamiento y nunca se re-estratificó frente a distribuciones de tráfico desplazadas.
• El prompt LLM-as-judge se fijó una vez y nunca se recalibró contra etiquetas humanas. El acuerdo del juez decayó silenciosamente^[2].
• Las puntuaciones base se almacenaron como números crudos, no como tuplas (model_sha, prompt_sha, judge_sha, dataset_sha, score) — así que cuando algo regresionó, nadie podía decir cuál de los cuatro se había movido.

Una suite de regresión que no resuelve las tres es solo un paso de CI que se pone verde al hacer deploy y te da confianza falsa. La solución no es “más casos”. La solución es medición consciente de segmentos, anclada a versión, con juez calibrado, en cada release.

Construye un dataset dorado que sobreviva al análisis consciente de segmentos

La composición de cuatro buckets que enviamos por defecto — muestras de producción 60%, adversarial 15%, casos extremos seleccionados por expertos 15%, replays de fallos 10% — es un punto de partida razonable. Lo que hace que efectivamente detecte regresiones son los metadatos de segmento adjuntos a cada caso.

Cada entrada del dataset lleva: entrada, comportamiento esperado (rúbrica, no cadena exacta), contexto de recuperación (si lo hay) y una etiqueta slice — dominio, segmento de usuario, intención de la consulta, idioma, bucket de longitud, las descomposiciones que importen para tu producto. La suite puntúa por segmento, y cualquier segmento que caiga por debajo de su umbral bloquea el release, incluso si la puntuación agregada subió.

Dos reglas operativas que hemos aprendido a hacer cumplir:

Remuestrea trimestralmente. Las distribuciones de tráfico de producción cambian más rápido que lo que la mayoría de los equipos miden. Re-estratificamos el bucket de muestra de producción contra los últimos 90 días de tráfico cada trimestre; si algún segmento creció por encima del 5% del tráfico y estaba por debajo del 2% del dataset dorado, se rellena antes de que se lance el siguiente release.

Cada postmortem añade un caso. Una regresión que llegó a producción y no fue detectada es un caso que faltaba en el dataset. Lo añadimos al bucket de replays dentro de las 48 horas posteriores al postmortem y lo etiquetamos con el segmento que lo sacó a la superficie.

¿Cómo detectas la deriva antes que los usuarios?

Existen cuatro tipos distintos de deriva, y una suite de regresión que solo vigila el último es una suite de regresión que se pierde la mayoría de las regresiones.

La deriva de calidad es la que la mayoría de las suites miden; las otras tres son donde las regresiones del viernes por la tarde suelen esconderse. Divinci hace seguimiento a las cuatro contra el manifiesto base, con el desglose de puntuación por segmento expuesto en cada PR y un job semanal de calibración del juez que marca la deriva antes de que se acumule.

Evaluación multidimensional — puntúa cuatro cosas a la vez, por segmento

Una sola puntuación compuesta es una señal peor que cuatro puntuaciones escalares. Aplicamos compuertas sobre cuatro dimensiones:

• Completitud de tarea — ¿la respuesta realmente respondió la pregunta?, puntuada por un juez calibrado contra una rúbrica. Consciente de segmentos.
• Fidelidad — para cualquier respuesta que haya referenciado contexto recuperado, ¿cada afirmación está fundamentada en ese contexto? La alucinación aparece aquí primero.
• Seguridad — corrección del rechazo, resistencia a jailbreak, exposición de PII / política. Casi siempre con compuerta en tasa de aprobación ≥ 0.99; la seguridad es un muro firme, no un compromiso flexible.
• Presupuesto de latencia — p95 dentro del SLA del segmento. Un cambio de prompt que duplicó los tokens por respuesta es una regresión incluso si la calidad subió.

Cada dimensión tiene su propia base por segmento y su propio umbral por segmento. Nunca las combinamos en un único escalar ponderado en el momento de la compuerta; las exponemos como cuatro puntuaciones por segmento y bloqueamos sobre la que primero cruza su umbral. Un modelo que ganó 4 puntos de completitud de tarea a costa de 1 punto de fidelidad en el segmento médico sigue siendo una regresión.

¿Qué compuertas deberían bloquear el despliegue de un LLM personalizado?

Ejecutamos una arquitectura de tres capas, cada capa con compuertas en una etapa diferente del pipeline (ver la entrada 1 para la taxonomía de etapas).

Capa 1 — Smoke (cada commit, ~90 segundos). Veinte a treinta casos críticos extraídos de los segmentos de mayor impacto. Detecta regresiones catastróficas antes de que la suite completa gaste cómputo. Si smoke falla, el resto no se ejecuta.

Capa 2 — Suite completa (cada PR, ~12 minutos). El dataset dorado completo, puntuado por segmento en las cuatro dimensiones. Spearman ρ consciente de segmentos contra el manifiesto base. La violación de umbral bloquea el merge. El comentario del PR lista exactamente qué segmento en qué dimensión se movió y cuánto, con cinco casos de fallo de ejemplo.

Capa 3 — Comparación base (release candidates, ~25 minutos). El modelo candidato se reproduce contra los últimos 14 días de trazas de producción — el replay de trazas de producción de bucle cerrado que lanzamos en la entrada 1. El mismo juez calibrado que puntúa el dataset dorado también puntúa las salidas del replay. Cualquier segmento cuyas puntuaciones de replay diverjan de las puntuaciones offline más allá de su umbral bloquea el release. Esta capa es la que detecta deriva que el dataset dorado aún no conoce.

Calibra tu juez antes de confiar en una sola puntuación que produzca

LLM-as-judge es lo que hace que cualquier cosa de esto escale más allá de unos pocos cientos de casos. También es donde una suite de regresión deja de funcionar silenciosamente, porque el juez no tiene ninguna obligación de mantenerse calibrado a medida que se actualiza o a medida que la distribución de tus datos se mueve.

Calibramos cada prompt de juez contra un conjunto de auditoría humano-etiquetado congelado de al menos 100 casos estratificados a través de los mismos segmentos que el dataset dorado, y re-ejecutamos la calibración semanalmente. El listón con el que enviamos es Spearman ρ ≥ 0.7 contra la mediana de los evaluadores humanos, con κ de Cohen ≥ 0.6 sobre juicios binarios de seguridad. Ambos están por encima del umbral en el que se ha demostrado que jueces estilo MT-Bench siguen a los evaluadores humanos al nivel de acuerdo interhumano^[2].

Cuando la calibración semanal cae por debajo del umbral, el juez se retira automáticamente y se localiza al ingeniero de evaluación de guardia. El pipeline de release mantiene los candidatos abiertos en lugar de aplicarles compuertas sobre un juez que ya no está midiendo lo que solía medir.

# Ejecuta el job semanal de calibración del juez
curl -X POST https://api.divinci.ai/v1/regression/judges/calibrate \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "judge_id":     "rubric-v7",
    "audit_set":    "human-labels-2026-04",
    "min_spearman": 0.70,
    "min_kappa":    0.60,
    "on_fail":      "retire_judge_and_page"
  }'

El diferenciador de Divinci — replay de trazas de producción en bucle cerrado

La compuerta de capa 3 es la parte que la mayoría de las suites de regresión no tienen. El flujo es el mismo flujo que lanzamos en la entrada 1, con una especialización para pruebas de regresión: cada release candidate ve comparada su puntuación en el dataset dorado offline, segmento por segmento, con su puntuación en una ventana de 14 días de trazas de producción reproducidas. El dataset dorado mide lo que esperábamos que el modelo hiciera. El replay mide lo que el modelo habría hecho realmente la semana pasada.

Cuando esas dos puntuaciones divergen más allá del presupuesto de brecha por segmento, el release se bloquea. El desajuste es la señal: o bien el dataset dorado ya no es representativo (deriva de cobertura), o el candidato se comporta de forma diferente sobre trazas moldeadas por el preprocesamiento y la recuperación de producción (deriva de producción). De cualquier manera, te enteras antes que los usuarios.

El juez que puntúa la ejecución offline es el mismo juez que puntúa la ejecución de replay. El registro de auditoría guarda ambos conjuntos de puntuaciones, ambas versiones del juez, los IDs de traza que se reprodujeron y la brecha que disparó el bloqueo. La brecha en sí misma es la señal diagnóstica más útil que tenemos, y es lo que se entrega a quien continúe con el árbol diagnóstico de la entrada 6.

Ancla el dataset dorado con un recibo vindex

Cada puntuación en la suite carece de significado si no puedes reproducirla más tarde. Hasheamos el dataset dorado en cada release y encadenamos ese hash en un recibo vindex junto con el SHA del modelo, el SHA del prompt, el SHA del juez y el registro de calibración. El recibo es anclable externamente — los auditores pueden reproducir nuestra ejecución exacta de regresión seis meses después y verificar las puntuaciones que reportamos.

{
  "release_id": "rel_3f1a-2026-05-26",
  "model": { "sha": "0c1f9…", "weights_uri": "r2://models/custom-v7.2", "open_weights": true },
  "prompt": { "sha": "c4a8e…", "template_id": "support-v3.4" },
  "retrieval": { "index_sha": "b21f0…", "embedder": "e5-mistral-7b-instruct" },
  "judge": { "sha": "d8e21…", "rubric_id": "rubric-v7", "spearman_vs_humans": 0.74 },
  "dataset": { "sha": "a90b1…", "n": 512, "slices": 17, "stratified_at": "2026-04-30" },
  "scores": { "aggregate": 0.872, "by_slice": { "/* … */": "/* escalares por segmento */" } },
  "replay": { "trace_window_days": 14, "n_traces": 8430, "max_gap": 0.018 },
  "vindex_anchor": "sha256:f0bfd2…",
  "verifiable_at": "https://vindex.divinci.ai/rel_3f1a-2026-05-26"
}

Advertencia open-weights. El recibo de arriba lleva procedencia de pesos solo cuando el modelo es open-weights — vindex ancla los bytes reales de los pesos. Para backings de modelos cerrados de API (modelos gestionados de OpenAI / Anthropic / Google), el recibo aún lleva la cadena de decisión — cada puntuación de compuerta, cada resultado de juez, el registro de calibración — pero el campo de pesos está vacío, y no puedes verificar de forma independiente el artefacto del modelo. Lo decimos en el recibo y en la documentación de cumplimiento para que los auditores no se queden con una impresión falsa. Los releases que más se benefician de una cadena vindex completa son aquellos en los que tú controlas los pesos.

Una cronología de implementación en cuatro fases que hemos enviado realmente

Los equipos que intentan enviar la arquitectura completa en la semana uno se atascan en herramientas. El orden de abajo es el orden que funciona.

Fase 1 — Base (semana 1). Extrae una muestra estratificada de los últimos 30 días de trazas de producción. Que dos ingenieros etiqueten a mano la completitud de tarea sobre 100 casos cada uno. Calcula el acuerdo entre evaluadores (objetivo κ de Cohen ≥ 0.6). El número que obtengas es tu línea base humana de partida; todo lo demás se calibra contra esto.

Fase 2 — Harness (semanas 2–3). Levanta el harness de evaluación sobre el dataset de 100 casos. Añade un juez calibrado contra tus etiquetas humanas. Verifica que el harness reproduce las puntuaciones humanas dentro de ρ ≥ 0.7. La mayoría de los equipos descubren que su primer prompt de juez falla esto y lo reescriben dos veces — esto es normal.

Fase 3 — Compuertas (semanas 3–4). Cablea el harness en CI como advertencia, no como bloqueo. Obsérvalo durante dos semanas. Los umbrales que descubres observando las tasas de falsos positivos son los únicos umbrales que sobreviven. Promueve a bloqueante solo cuando la tasa de falsos positivos esté por debajo del 5%.

Fase 4 — Bucle de replay (continuo). Una vez que las compuertas estén bloqueando de forma fiable, habilita la capa de replay de trazas de producción. Aquí es donde aparece la brecha de cobertura por segmentos, y donde cada postmortem empieza a añadir casos de vuelta al dataset dorado.

Qué no resuelve esto

Tres limitaciones honestas, de la misma manera que las hemos enmarcado en cada entrada de esta serie.

1. La deriva de la suite es trabajo sin fin. Las pruebas de regresión son infraestructura, no un proyecto. El dataset dorado tiene que re-estratificarse cada trimestre, el juez recalibrarse cada semana, los presupuestos de umbral re-ajustarse cada postmortem. No hay versión de esto en la que envías una suite y te alejas.
2. Un juez perfectamente calibrado sigue siendo un modelo. Spearman ρ = 0.74 contra evaluadores humanos significa que aproximadamente una cuarta parte de las llamadas del juez discrepan con la mediana humana. Ese desacuerdo residual es el piso de ruido en cada puntuación. Lo exponemos explícitamente en cada informe de release; los equipos que olvidan que está ahí se sorprenderán por él eventualmente.
3. Los backings cerrados de API limitan cuánto puedes verificar. Con un modelo cerrado de API, la suite de regresión mide comportamiento pero no puede verificar la procedencia de los pesos. Si necesitas reproducibilidad completa — industrias reguladas, despliegues auditados — la compensación está en la elección del modelo, no en la suite.

Próximamente

La entrada 8, la última de esta serie, cierra el bucle del interior de CI. Mientras esta entrada y la entrada 5 fueron sobre lo que se ejecuta en las compuertas, la siguiente trata sobre la capa de CI que produce los candidatos que las compuertas puntúan en primer lugar — evaluación pre-merge, pruebas de contrato para plantillas de prompt y cómo dimensionar la flota de CI para una suite de evaluación de 12 minutos sin reventar el presupuesto. Es la capa de ingeniería que está debajo de todo lo que hemos escrito hasta ahora.

FAQ

¿Cuál es la diferencia entre evaluación de LLM y pruebas de regresión de LLM?

La evaluación mide si un modelo cumple un listón de calidad en un punto del tiempo, contra una rúbrica absoluta. Las pruebas de regresión miden si un candidato se comporta igual que una línea base congelada, por segmento, a través de múltiples dimensiones. La línea base es lo que la convierte en pruebas de regresión — Divinci envía ambas, y el modo de regresión fija (model_sha, prompt_sha, judge_sha, dataset_sha) para que una puntuación movida identifique qué entrada se movió.

¿Cuántos casos debería tener un dataset dorado?

Menos de los que crees, mejor estratificados de lo que crees. Hemos enviado cobertura útil de regresión con 200 casos sobre cinco segmentos bien definidos y hemos visto datasets de 5.000 casos que se perdieron todo lo que importaba porque no estaban estratificados. Empieza en 200, estratificados, luego haz crecer el bucket de replay caso a caso desde los postmortem.

¿Debería usar revisores humanos o LLM-as-judge?

Ambos, con humanos calibrando al juez. Los humanos no pueden seguir el ritmo del volumen que necesita puntuar una compuerta de CI en ciclo de release. El juez cubre el volumen, los humanos calibran al juez — medido semanalmente con Spearman ρ ≥ 0.7. Cualquiera por sí solo es un modo de fallo.

¿Cómo pruebo salidas no deterministas?

Puntúa la distribución, no la cadena. Puntúa con una rúbrica que el juez pueda aplicar a través de distintas formulaciones, y ejecuta cada entrada de tres a cinco veces a temperatura > 0 para que la puntuación consciente de segmentos sea sobre una distribución de completaciones en lugar de una única muestra. Aprieta la temperatura solo para casos que genuinamente necesiten salida determinista (llamadas a herramientas con salida estructurada, clasificación).

¿Qué métricas debería priorizar para la primera compuerta de calidad en CI?

Completitud de tarea y una compuerta de seguridad. Ambas por segmento. Añadir más dimensiones antes de que las dos primeras estén calibradas produce ruido; los equipos que envían más suelen terminar aplicando compuertas sobre el ruido. Añade fidelidad a continuación cuando enciendas la recuperación; añade latencia una vez que las dos primeras estén estables.

Referencias

1. Pan, Tianpan. "The Semver Lie: how a minor LLM update broke production." 29 de abril de 2026. El modo de fallo nombrado en 2026 para el análisis de regresión consciente de segmentos; las puntuaciones agregadas se mantienen planas mientras un segmento de bajo volumen regresiona silenciosamente.
2. Zheng et al. "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685. Evidencia empírica de que jueces LLM fuertes coinciden con evaluadores humanos aproximadamente al nivel de acuerdo interhumano (≈ 80%) en tareas abiertas, con modos de fallo reportados que las auditorías calibrar-contra-humanos están diseñadas para detectar.
3. Kirkpatrick et al. "Overcoming catastrophic forgetting in neural networks." PNAS / arXiv:1612.00796. El resultado fundacional sobre olvido catastrófico en redes neuronales con fine-tuning — por qué un LLM personalizado con fine-tuning tiene que probarse en regresión para detectar pérdida de capacidad general, no solo ganancia en la tarea objetivo.
4. Amazon Web Services. "SageMaker Deployment Guardrails — blue/green deployments and canary monitoring." El contraste con API cerrada: compuertas sobre métricas de infraestructura (latencia, errores, CPU) en lugar de sobre calidad semántica por segmento.
5. Spearman, C. "The proof and measurement of association between two things." American Journal of Psychology, 15(1):72–101, 1904. El coeficiente de correlación por rangos que ancla la compuerta consciente de segmentos — robusto frente a deriva de escala de puntuación en el juez, que es la propiedad que necesitábamos.
6. DORA / Google Cloud. "Accelerate State of DevOps — change-failure-rate and time-to-restore-service metrics." La línea base entre industrias para "con qué frecuencia los deploys causan incidentes" y "qué tan rápido te recuperas". Las suites de regresión que bloquean en la compuerta mueven la primera métrica hacia abajo; el rollback instantáneo ([entrada 5](/es/blog/automated-llm-ci-cd-pipelines-with-instant-rollback/)) mueve la segunda.