Pruebas y evaluación de LLM API: pipeline de CI/CD (2026)

El 3.2% aparece primero en el reporte de auditoría —3,200 payloads JSON malformados por cada 100,000 llamadas de API, cada uno un fallo silencioso de lógica de negocio.

Lo causó un solo cambio en el string del modelo. Ningún dashboard lo detectó. El HTTP sigue en verde mientras los outputs estructurados se degradan silenciosamente, y terminas rastreando los escombros tres sprints atrás.

Un eval integrado en CI detecta regresiones semánticas en el pull request —con la misma fuerza con que los unit tests bloquean punteros nulos.

Este pipeline abarca desde verificaciones deterministas hasta el scoring con LLM-as-Judge, con un ciclo cerrado que convierte los fallos de hoy en casos de test de CI para mañana.

Por qué “se ve bien” escala hasta ~50 reviews —y luego falla

Por qué “¿se ve bien?” no escala

Un reviewer humano mirando outputs de LLM no es confiable de tres maneras específicas y medibles:

1. Fatiga. La precisión cae bruscamente después de ~50 reviews consecutivas. El juicio número 51 es notablemente peor que el número 5 —y no notarás la degradación.
2. Inconsistencia. La confiabilidad entre evaluadores de dos reviewers humanos sobre el mismo conjunto de outputs de LLM típicamente cae por debajo de 0.6 —lo que significa que dos personas calificadas no se ponen de acuerdo sobre “¿esto es correcto?” el 40% de las veces.
3. Costo y latencia. 1,000 outputs a 90 segundos por review = 25 horas de tiempo humano. Eso son $750-2,500 por cada ejecución de eval —y agendar toma días.

La evaluación automática es consistente, instantánea y casi gratis. Pero “evaluación automática” no es una sola cosa —es una pila de tres primitivas que combinas según lo que estés probando.

Las tres primitivas de evaluación

Capa 1: Verificaciones deterministas. Microsegundos. Cero costo de API. Validación de JSON Schema. Coincidencia exacta de strings. Conteo de éxito/fallo de llamadas a herramientas. Verificación de existencia de citas. Coincidencia con regex de rechazo. Estas detectan aproximadamente el 50% de los fallos del mundo real —y son la única capa que puede ejecutarse en cada request sin preocuparte por el presupuesto. Empieza aquí.

Capa 2: Métricas basadas en embedding. Milisegundos. ~$0.001 por verificación. BERTScore. Similitud coseno con una respuesta de referencia. Útil cuando tienes respuestas “gold” y necesitas un juicio de similitud tolerante a paráfrasis. No útil para generación de tipo abierto donde existen múltiples respuestas válidas.

Capa 3: LLM-as-Judge. Cientos de milisegundos. $0.01-0.10 por verificación. Un LLM capaz puntúa outputs contra rúbricas usando razonamiento de cadena de pensamiento. Detecta fallos semánticos que las verificaciones deterministas no ven —resúmenes infieles, respuestas inútiles, rechazos incorrectos. Requiere calibración contra etiquetas humanas y mitigación activa de sesgos (sesgo de posición, sesgo de verbosidad, sesgo de auto-mejora).

El stack de evaluación de producción de 6 capas

Dataset —Metrics/Rubrics —Judge —CI Gate —Production Observation —Closed Loop

Rompe cualquier eslabón y la evaluación se convierte en un reporte offline que nadie lee. El dataset se muestrea de producción, ponderado hacia los fallos. Las rúbricas definen “correcto” en términos medibles. El juez puntúa de forma consistente y a escala. El CI gate bloquea regresiones antes del merge. La observación de producción detecta lo que el CI se pierde. El ciclo cerrado convierte el fallo de producción de hoy en un caso de test de CI para mañana. Seis capas. Un pipeline. Sin huecos.

Por qué el testing sistemático lo cambia todo

El costo oculto de la regresión

El 3.2% de respuestas JSON silenciosamente malformadas significa 3,200 outputs rotos por cada 100,000 llamadas de API. Si esos outputs impulsan acciones posteriores, tienes 3,200 fallos de lógica de negocio —y no los descubrirás hasta que la conciliación financiera no cuadre, lo que podrían ser semanas.

Un pipeline de eval detecta el 3.2% en CI, antes de que el cambio en el string del modelo llegue a producción. El costo de montar el pipeline es menor que el costo de un solo incidente.

Detección de deriva de prompts

Los bumps menores de versión de modelo —gpt-5.5-2026-07-01 a gpt-5.5-2026-07-15 —no vienen con notas de cambios de comportamiento. El changelog dice “mejora en el seguimiento de instrucciones”. Tu precisión de extracción estructurada bajó 4 puntos. No lo sabrás a menos que estés ejecutando la misma suite de eval contra cada versión de modelo.

El problema de la evaluación multi-proveedor

Si enrutas entre modelos —y deberías, por costo y confiabilidad —necesitas resultados de eval para cada modelo de tu pool de enrutamiento. No solo el primario. Un endpoint de API unificado te permite ejecutar la misma suite de eval contra todos los modelos a través de una sola integración. Mismo formato de request. Mismos casos de test. Mismo modelo juez. La única variable que cambia es model: "...".

Antes de construir tu suite de eval, entiende los perfiles de rendimiento y costo de cada modelo de tu pool de enrutamiento. Nuestra comparación de benchmarks entre proveedores proporciona datos por modelo para fundamentar tus prioridades de testing.

Cómo construir tu pipeline de evaluación

Paso 1: Construye tu dataset de eval

El dataset es el paso más difícil y el que la mayoría de los equipos menos cuida. Un mal dataset te da puntuaciones precisas sobre las cosas equivocadas. Un buen dataset se muestrea de producción, se pondera hacia el fallo y se refresca semanalmente.

El proceso de construcción:

1. Muestrea aleatoriamente 200-500 requests de los logs de producción. No de tu entorno de test. Los usuarios reales hacen preguntas que los autores de tests nunca imaginan.
2. Anota manualmente cada uno: ¿cuál era la respuesta correcta? ¿Qué haría incorrecta la respuesta? ¿Qué casos límite debería manejar el modelo?
3. Estratifica por dificultad: un tercio fácil, un tercio medio, un tercio difícil. Si tu set de eval son solo queries fáciles, tus puntuaciones estarán infladas.
4. Refresca semanalmente: muestrea datos nuevos de los últimos 7 días de logs de producción. Reemplaza el 20% más antiguo de tu set de eval. Esto mantiene tu eval alineado con lo que los usuarios realmente preguntan —que deriva con el tiempo.

La regla que evita el error más común: al menos el 20% de tu set de eval debe provenir de fallos históricos. Si tu set de eval solo contiene queries de happy path, estás probando si el modelo funciona en condiciones ideales —no si falla con elegancia en las condiciones que realmente ocurren en producción.

Paso 2: Define rúbricas, no solo “¿es bueno?”

Cuatro rúbricas bien calibradas superan a 15 ruidosas. Cada rúbrica necesita:

• Una definición precisa: “faithfulness = cada afirmación factual de la respuesta está respaldada por el contexto recuperado”
• Una escala de puntuación: 1-5 o 0-1
• Un umbral de aprobación: “faithfulness ≥ 0.85”
• Dos o tres ejemplos puntuados como referencias de calibración para tu modelo juez

El conjunto de rúbricas central para la mayoría de las aplicaciones de LLM API: faithfulness (¿los hechos son correctos?), answer relevance (¿la respuesta atiende la query?), context precision (¿los chunks recuperados son realmente relevantes?), task completion (¿el modelo hizo lo que se le pidió?), refusal correctness (¿el modelo rechazó cuando debía —y no rechazó cuando no debía?).

Paso 3: Elige y calibra tu juez

GPT-4 es el LLM juez más usado —su acuerdo con anotadores humanos supera el 80% en MT-Bench y el 85%+ en G-Eval. Pero un juez sin calibrar te da números que parecen precisos y son sistemáticamente incorrectos.

El proceso de calibración: toma 50 ejemplos anotados por humanos. Pásalos por tu modelo juez. Calcula la correlación entre las puntuaciones del juez y las humanas. Si la correlación está por debajo de 0.75 para cualquier rúbrica, el prompt del juez para esa rúbrica necesita trabajo —o necesitas un modelo juez distinto.

Tres sesgos que deben mitigarse:

• Sesgo de posición. El juez prefiere la respuesta que aparece primero. Solución: aleatoriza el orden de las respuestas en cada evaluación.
• Sesgo de verbosidad. El juez puntúa más alto las respuestas más largas sin importar la calidad. Solución: puntúa relevancia y completitud como dimensiones separadas.
• Sesgo de auto-mejora. El juez infla las puntuaciones de outputs generados por la misma familia de modelo. Solución: usa una familia de modelo distinta como juez que la que usas en producción. Si producción corre sobre Claude, juzga con GPT-4. O usa un modelo juez dedicado. Para el aislamiento de claves de API y los controles de acceso que mantienen tu juez y tus modelos de producción separados de forma segura, consulta la guía de mejores prácticas de seguridad.

La regla más pasada por alto: fija la versión de tu modelo juez. Cuando actualizas el juez de GPT-4 a GPT-4o, cada puntuación histórica se vuelve incomparable. No puedes saber si tu modelo de producción mejoró o tu juez se volvió más estricto. O mantienes constante la versión del juez, o recalibras contra tus 50 ejemplos anotados por humanos después de cada actualización del juez y estableces un mapeo de puntuaciones entre el juez viejo y el nuevo.

Paso 4: Configura el gating de CI

Dos herramientas, dos filosofías:

• Promptfoo. Código abierto. Integrado con Git. Configuración declarativa en YAML. Mejor para equipos que quieren el eval como código, viviendo junto a sus prompts en el mismo repo.
• DeepEval. Nativo de Python. Más de 30 métricas integradas. Integración CI/CD basada en decoradores. Mejor para equipos que quieren el eval profundamente integrado en su suite de tests de Python.

La lógica del CI gate, sin importar la herramienta:

tests:
  - path: eval_dataset.jsonl
    asserts:
      - type: python
        value: |
          def check_regression(output, context):
              baseline = context['baseline_scores']
              current = compute_scores(output)
              for rubric, score in current.items():
                  if baseline[rubric] - score > 2:
                      return False, f"{rubric} dropped {baseline[rubric] - score:.1f} points"
              return True, "All rubrics within threshold"

Cualquier rúbrica que baje más de 2 puntos respecto a la línea base —CI falla —merge bloqueado. Esto no es opcional. Un cambio de prompt que degrade la calidad en 3 puntos sobre una rúbrica crítica nunca debería llegar a producción. Tus unit tests bloquean una excepción de puntero nulo. Tus eval gates deberían bloquear una regresión semántica con la misma fuerza. El flujo de optimización de prompts que alimenta el gating de CI está cubierto en nuestra guía de producción de prompt engineering.

Paso 5: Observación de producción + ciclo cerrado

La evaluación en CI detecta regresiones previas al deploy. No detecta cambios de distribución, entradas adversariales ni casos límite que tu set de eval no cubre. Para eso necesitas evaluación continua sobre trazas de producción.

Adjunta las puntuaciones de eval a tus spans de OTel. Cualquier rúbrica que sostenga una caída de 2-5 puntos en una ventana deslizante dispara una alerta. La metodología de calibración del juez y el flujo de optimización de prompts que alimenta el gating de CI están cubiertos en los pasos anteriores de esta guía. La metodología de evaluación con cadena de pensamiento referenciada aquí fue establecida por el paper G-Eval (Liu et al., 2023). Las trazas fallidas se agrupan automáticamente por tipo de error, versión de prompt y modelo. Los problemas nombrados con fallos representativos se promueven de vuelta a tu dataset de eval offline —esta vez anotados manualmente, con el patrón de fallo específico documentado.

Este ciclo cerrado es la diferencia entre una puntuación de eval que tiende a la baja con el tiempo y una que sigue mejorando. Sin él, tu set de eval se vuelve obsoleto, tu modelo deriva y tu CI gate se convierte en una formalidad que pasa mientras la calidad de producción se degrada.

Patrones de testing para escenarios específicos de API

Testing de salida estructurada

La validación de JSON Schema por sí sola detecta ~70% de los fallos de salida estructurada. Agrega verificaciones de reglas de negocio para el 30% restante: “el precio no puede ser negativo”, “el email debe coincidir con el regex”, “el total debe ser igual al subtotal más el impuesto”. Verificaciones de consistencia entre campos: “si payment_method es ‘credit_card’, last_four no debe ser null”.

La trampa específica de proveedor: OpenAI devuelve function.arguments como un string JSON. Anthropic devuelve tool_use.input como un objeto JSON. Tu parser debe manejar ambos —y tu suite de eval debe probar ambos. Mockea ambos formatos de respuesta en CI.

Para la referencia completa de formatos de request y response entre proveedores —incluyendo salida estructurada, llamadas a herramientas y streaming —consulta la documentación de la API de chat completions.

Testing de llamadas a herramientas

Cuatro verificaciones, ordenadas por frecuencia de fallo: (1) el nombre de la herramienta coincide con el schema. (2) Los argumentos requeridos están presentes y correctamente tipados. (3) Las llamadas a herramientas en paralelo no interfieren entre sí. (4) Después de un error de herramienta, el modelo reintenta con argumentos corregidos —o escala —no hace loops.

Establece un límite de loop duro en el testing: la misma herramienta llamada más de tres veces consecutivas —el test falla. El modelo debería reconocer el patrón, no repetirlo.

Testing de calidad RAG

Tres dimensiones: relevancia del contexto (¿los chunks recuperados tratan sobre lo que preguntó el usuario?), fidelidad de la respuesta (¿cada afirmación de la respuesta está respaldada por un chunk recuperado?), precisión de citas (¿cada cita apunta a un chunk que realmente contiene la información citada?). Umbral mínimo: precisión de cita top-1 —90%. Por debajo de eso, los usuarios perderán confianza —rápido.

Por qué la mayoría de los pipelines de eval de LLM fallan en 3 meses

Probar solo happy paths

Tu set de eval contiene “¿Cuál es la política de devolución?” y “¿Cómo restablezco mi contraseña?” —queries limpias, amigables y bien formadas. Producción contiene “i cant log in wtf???” y “URGENT: my refund still hasn’t processed and it’s been TWO WEEKS” —con typos, enojo y contexto faltante. Si tu set de eval no incluye casos límite tipo producción, tu puntuación de eval del 95% no significa nada.

Solución: muestrea de los logs de producción. Asegúrate de que al menos el 20% de tu set de eval provenga de fallos históricos —queries que previamente produjeron respuestas incorrectas, rechazos o alucinaciones.

No fijar la versión del modelo juez

Actualizaste tu juez de GPT-4 a GPT-4o. Todas tus puntuaciones de eval subieron 3 puntos. Tu equipo celebró la “mejora de calidad”. Nada cambió en producción. El juez simplemente se volvió más indulgente.

Solución: bloquea la versión del modelo juez. Si debes actualizar, recalibra contra tus 50 ejemplos anotados por humanos y establece un mapeo de puntuaciones. Sin eso, tu historial de puntuaciones de eval es ruido.

Optimizar sobre el set de eval

Ajustaste tu prompt contra tu set de eval. 95% de precisión. Desplegado. Precisión en producción: 68%. El set de eval contenía los patrones para los que optimizaste. Producción contiene todo lo demás.

Solución: división train/eval/test (70/15/15). El optimizador ve el set de entrenamiento. El CI corre contra el set de eval. El test set se reserva —lo ejecutas una vez antes del release, y la puntuación que reporta es la estimación más cercana del rendimiento de producción que obtendrás antes de desplegar.

Una vez que tus eval gates pasan en CI, patrones de deploy como canary rollouts y cadenas de fallback te protegen de los cambios de distribución en producción. Consulta la guía de optimización de producción para estrategias de rollout y configuración de failover de modelos.

Lectura adicional. Amplía el lado de salida estructurada de tu suite de tests con nuestra comparación de JSON mode y salida estructurada, que cubre el manejo de formatos específico de proveedor que tu pipeline de CI necesita validar. Para la metodología de optimización de prompts, consulta el Paso 4; para estrategias de rollout y configuración de failover de modelos, consulta la guía de optimización de producción de arriba.

FAQ

¿Cuántos casos de test necesito para empezar?

Cincuenta es el mínimo para retroalimentación direccional —suficiente para saber si un cambio mejoró o empeoró las cosas, pero demasiado ruidoso para el gating de CI. De cien a 500 casos te dan significancia estadística —un fallo aislado en un caso límite no puede mover tus puntuaciones más de unos pocos puntos. Empieza en 50. Agrega 20-30 casos nuevos semanalmente de los logs de producción. Si eres nuevo en el testing programático de LLM y quieres primero los fundamentos de API, nuestra guía para principiantes de LLM APIs cubre la estructura del request antes de que construyas una suite de eval.

LLM-as-Judge vs. evaluación humana —¿qué tan grande es la brecha?

El juez GPT-4 coincide con los anotadores humanos más del 80% de las veces en tareas factuales y de seguimiento de instrucciones. La brecha es más grande en dimensiones subjetivas (creatividad, calidad estilística). Para dimensiones objetivas —faithfulness, cumplimiento de formato, completitud de tarea —los LLM judges igualan o superan a los anotadores humanos individuales, porque eliminan la fatiga y la inconsistencia.

¿Debería usar el mismo modelo como juez que el que uso en producción?

No. El sesgo de auto-mejora es real y medible —los modelos inflan las puntuaciones de outputs de la misma familia de modelo en un 5-10%. Usa una familia de modelo distinta o un modelo juez dedicado. Si tu stack de producción corre Claude, evalúa con GPT-4.

¿Cómo evalúo respuestas en streaming?

Evalúa la respuesta completa concatenada, no tokens individuales. Agrega aserciones de rendimiento: TTFT (time-to-first-token) por debajo de tu umbral objetivo, latencia entre tokens P95 dentro del presupuesto. Los bugs específicos de streaming —como saltos de línea sin escapar en datos de eventos SSE que rompen el parser —necesitan verificaciones deterministas dedicadas.

¿Cómo ejecuto la misma suite de eval en tres proveedores sin escribir tres adaptadores?

Envía casos de test idénticos a través de una sola URL base, cambiando solo el parámetro model entre gpt-5.5, claude-sonnet-4-20250514 y gemini-3.1-pro. Un formato de request. Un pipeline de eval. La única variable que cambia es qué modelo procesa el prompt —que es exactamente lo que tu suite de eval está diseñada para medir. Para tu primer request de eval unificado a través de una sola URL base, sigue la guía de inicio rápido.

La evaluación de LLM no es una fase que completas. Es infraestructura que mantienes. El stack de 6 capas —dataset, rúbricas, juez, CI gate, observación de producción, ciclo cerrado —es el sistema mínimo viable para saber si tus funciones impulsadas por LLM están mejorando o empeorando.

Empieza con 50 casos de test y verificaciones deterministas. Ejecútalos en CI esta semana. Agrega 20 casos a la semana de los logs de producción. En un mes tendrás un set de eval estadísticamente significativo y un CI gate que detecta regresiones antes que los usuarios.

Tu suite de eval no debería necesitar un adaptador específico de proveedor para cada modelo que pruebes. Empieza a probar en TokSpan —ejecuta los mismos 50 casos de test contra GPT, Claude y Gemini a través de un único punto de integración.