AI Engineering Academy · Lección

Creación de un pipeline de evaluación continua

Integre la evaluación mediante LLM-as-judge en su pipeline de CI/CD para que cada cambio en un prompt o modelo se evalúe automáticamente con un conjunto de pruebas de regresión antes del despliegue.

Lección 4 de 413 pasos

Creación de un pipeline de evaluación continua es una lección gratuita de AI Engineering Academy en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de AI Engineering Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de AI Engineering Academy incluye 4 lecciones en total.

Por qué la evaluación debe ser continua

Una evaluación única durante el despliegue no es suficiente. La calidad de los LLM se degrada silenciosamente: los proveedores de modelos actualizan sus modelos, se introducen cambios en el prompt del sistema, la calidad de la recuperación cambia a medida que crece el corpus de documentos y la distribución de las consultas de los usuarios evoluciona con el tiempo. Un flujo de evaluación continua ejecuta el mismo conjunto de evaluaciones con cada cambio y según una programación establecida, de modo que las regresiones de calidad se detecten en horas y no en semanas.

Componentes principales del flujo

Un pipeline de evaluación continua tiene cinco componentes: un conjunto de datos de prueba (preguntas seleccionadas con resultados esperados), un ejecutor del sistema (que llama a su pipeline de LLM para cada pregunta de prueba), un evaluador (que puntúa cada respuesta), un almacén de resultados (una base de datos o almacén de series temporales para las métricas históricas) y una capa de informes (paneles y alertas). Cada componente puede actualizarse de forma independiente.

# Pipeline architecture:
#
# test_dataset.json
#       |
#       v
# system_runner.py  --> calls your LLM pipeline
#       |
#       v
# judge.py          --> scores each (question, answer) pair
#       |
#       v
# results_db        --> stores timestamped metric history
#       |
#       v
# dashboard + alert --> Grafana / Slack notification

Estructuración del conjunto de datos de prueba

Almacene su conjunto de pruebas de evaluación como un archivo JSON o YAML versionado en su repositorio. Cada entrada contiene una pregunta, la categoría (factual, procedimental, fuera de alcance) y, opcionalmente, una respuesta de referencia. Versione el conjunto de pruebas por separado del código: añadir nuevos casos de prueba es un cambio compatible con versiones anteriores, mientras que eliminar casos puede ocultar regresiones. Procure tener entre 200 y 500 casos de todas las categorías relevantes.

# eval/test_set_v3.json
# {
#   'version': '3.0',
#   'created': '2026-06-01',
#   'cases': [
#     {
#       'id': 'faq_001',
#       'category': 'factual',
#       'question': 'What is the cancellation policy?',
#       'reference': 'Cancellations must be made 24 hours in advance.',
#       'min_correctness': 4
#     },
#     ...
#   ]
# }

Ejecución de la suite de evaluación

El ejecutor de evaluación llama a su sistema de producción (o a una versión de staging) para cada caso de prueba y registra la respuesta y los metadatos. Etiquete cada ejecución de evaluación con un ID de ejecución único, el SHA del commit que la desencadenó, la marca de tiempo y la versión del conjunto de pruebas. Esto permite comparar ejecuciones con exactitud y diagnosticar qué cambio en el código causó una regresión.

import asyncio
import uuid
from datetime import datetime

async def run_eval_suite(system, test_set: list, commit_sha: str) -> dict:
    run_id = str(uuid.uuid4())
    results = []
    for case in test_set:
        response = await system.answer(case['question'])
        score = await judge(case['question'], response, case.get('reference'))
        results.append({
            'run_id': run_id,
            'commit_sha': commit_sha,
            'case_id': case['id'],
            'category': case['category'],
            'response': response,
            'score': score.model_dump(),
            'evaluated_at': datetime.utcnow().isoformat()
        })
    return {'run_id': run_id, 'results': results}

Almacenamiento y consulta de métricas históricas

Conserve el resultado de cada ejecución de evaluación en una base de datos. Una tabla eval_results sencilla con los campos run_id, commit_sha, case_id y score es suficiente. Consulte las puntuaciones agregadas por run_id para calcular las métricas de cada ejecución. Compare la ejecución actual con la última ejecución correcta en la rama principal para detectar regresiones. Una base de datos de series temporales como InfluxDB funciona bien para la supervisión continua.

-- PostgreSQL schema
CREATE TABLE eval_runs (
    run_id UUID PRIMARY KEY,
    commit_sha TEXT NOT NULL,
    test_set_version TEXT NOT NULL,
    triggered_by TEXT,  -- 'ci', 'scheduled', 'manual'
    started_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE eval_results (
    id SERIAL PRIMARY KEY,
    run_id UUID REFERENCES eval_runs(run_id),
    case_id TEXT NOT NULL,
    category TEXT,
    correctness INT,
    overall INT,
    response TEXT
);

CREATE INDEX idx_run_id ON eval_results(run_id);

Detección automática de regresiones

Después de cada ejecución de evaluación, compare las puntuaciones agregadas con la línea base (la última ejecución de la rama principal aprobada manualmente). Se define una regresión como cualquier dimensión de puntuación que descienda más de un 5 % por debajo de la línea base o la puntuación media de cualquier categoría que descienda por debajo de un mínimo estricto. Las regresiones deben bloquear el despliegue y generar una alerta para el equipo. Las mejoras pueden aprobarse automáticamente.

def detect_regression(current: dict, baseline: dict, threshold_pct: float = 5.0) -> dict:
    regressions = []
    for metric in ['correctness', 'helpfulness', 'clarity']:
        delta_pct = (current[metric] - baseline[metric]) / baseline[metric] * 100
        if delta_pct < -threshold_pct:
            regressions.append({
                'metric': metric,
                'baseline': baseline[metric],
                'current': current[metric],
                'delta_pct': round(delta_pct, 1)
            })
    return {'has_regression': len(regressions) > 0, 'regressions': regressions}

Integración con CI/CD

Añada la suite de evaluación como un paso de CI que se ejecute en cada pull request. El pipeline de CI llama a su sistema de staging, ejecuta el evaluador, almacena los resultados y comprueba si hay regresiones. Si se detecta una regresión, el paso de CI falla y bloquea la combinación del PR. Añádalo como comprobación de estado obligatoria en GitHub o GitLab para que nadie pueda omitirlo. Mantenga el tiempo de ejecución de la evaluación por debajo de 10 minutos utilizando un subconjunto de 50 a 100 casos para las comprobaciones de los PR.

# .github/workflows/eval.yml
# name: LLM Quality Evaluation
# on: [pull_request]
# jobs:
#   eval:
#     runs-on: ubuntu-latest
#     steps:
#       - uses: actions/checkout@v4
#       - name: Run eval suite
#         run: python eval/run_suite.py --commit $GITHUB_SHA --mode pr
#         env:
#           OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
#       - name: Check for regressions
#         run: python eval/check_regression.py --run-id $EVAL_RUN_ID

Ejecuciones completas de evaluación programadas

Además de las comprobaciones de los PR, ejecute diariamente la suite completa de evaluación (los más de 300 casos) contra producción. Esto detecta una degradación gradual de la calidad que ningún cambio aislado provoca; por ejemplo, si la recuperación de la base de datos vectorial se degrada a medida que se añaden más documentos o si el proveedor de LLM actualiza su modelo silenciosamente. Las ejecuciones completas diarias proporcionan una serie temporal de la calidad que hace visibles las tendencias.

# Separate eval modes:
EVAL_CONFIGS = {
    'pr_check': {
        'test_cases': 'eval/test_set_core_100.json',
        'target': 'staging',
        'max_runtime_min': 8
    },
    'nightly': {
        'test_cases': 'eval/test_set_full_350.json',
        'target': 'production',
        'max_runtime_min': 30
    },
    'weekly_deep': {
        'test_cases': 'eval/test_set_full_350.json',
        'target': 'production',
        'include_pairwise': True,
        'max_runtime_min': 90
    }
}

Alertas por degradación de la calidad

Configure alertas cuando las tendencias de las métricas superen los umbrales de advertencia y críticos. Una caída del 3 % en la corrección media durante los últimos 7 días activa una advertencia. Una caída del 10 % en una sola ejecución activa una alerta inmediata. Envíe las advertencias a un canal del equipo en Slack y las alertas críticas a PagerDuty. Incluya en cada mensaje de alerta el análisis de la regresión, un enlace al panel de evaluación y el git blame de los cambios recientes.

import httpx

def send_regression_alert(regression_report: dict, webhook_url: str):
    regressions = regression_report['regressions']
    blocks = [{
        'type': 'section',
        'text': {'type': 'mrkdwn', 'text': '*LLM Quality Regression Detected*'}
    }]
    for r in regressions:
        blocks.append({
            'type': 'section',
            'text': {'type': 'mrkdwn',
                     'text': f'*{r["metric"]}*: {r["baseline"]} -> {r["current"]} ({r["delta_pct"]}%)'}
        })
    httpx.post(webhook_url, json={'blocks': blocks})

Gestión de la ampliación del conjunto de pruebas

Amplíe continuamente su conjunto de pruebas a partir de fallos reales en producción. Cuando un usuario informe de una respuesta incorrecta, añada esa pregunta (anonimizada si es necesario) al conjunto de pruebas junto con una respuesta esperada verificada por una persona. Así se asegura de que la suite de evaluación refleje las necesidades reales de los usuarios en lugar de casos hipotéticos. Trate el conjunto de pruebas como un documento vivo y revíselo trimestralmente para eliminar los casos obsoletos.

def add_to_test_set(question: str, reference_answer: str, category: str,
                    source: str, test_set_path: str):
    import json, uuid
    with open(test_set_path, 'r') as f:
        test_set = json.load(f)
    test_set['cases'].append({
        'id': f'user_report_{uuid.uuid4().hex[:8]}',
        'category': category,
        'question': question,
        'reference': reference_answer,
        'source': source,  # 'user_report', 'regression', 'manual'
        'added': '2026-06-21'
    })
    with open(test_set_path, 'w') as f:
        json.dump(test_set, f, indent=2)

Visualización de las tendencias de calidad a lo largo del tiempo

Construya un panel de calidad sencillo que represente sus métricas clave a lo largo del tiempo: puntuación media de corrección, tasa de aciertos de caché, latencia p95 y coste por consulta. Utilice una media móvil semanal para suavizar el ruido producido por tamaños de muestra pequeños. Un gráfico de tendencias hace inmediatamente visible la deriva de la calidad: una disminución gradual del 3 % durante seis semanas puede pasar desapercibida en los informes de ejecuciones individuales, pero resulta evidente en un gráfico de series temporales. Grafana o incluso un script sencillo de Python con matplotlib funcionan bien para esto.

import matplotlib.pyplot as plt
import pandas as pd

def plot_quality_trend(eval_history: list):
    df = pd.DataFrame(eval_history)
    df['date'] = pd.to_datetime(df['evaluated_at'])
    df = df.sort_values('date')
    # 7-day rolling average
    df['score_ma7'] = df['mean_correctness'].rolling(window=7).mean()
    plt.figure(figsize=(12, 4))
    plt.plot(df['date'], df['mean_correctness'], alpha=0.3, label='Daily')
    plt.plot(df['date'], df['score_ma7'], label='7-day avg', linewidth=2)
    plt.axhline(y=4.0, color='r', linestyle='--', label='Min threshold')
    plt.legend()
    plt.title('LLM Answer Quality Over Time')
    plt.savefig('quality_trend.png')

Comprobación rápida

Compruebe su comprensión de los pipelines de evaluación continua para aplicaciones de LLM.

Resumen de la lección

En esta lección ha aprendido que los pipelines de evaluación continua ejecutan comprobaciones automatizadas de calidad en cada PR y diariamente para detectar pronto las regresiones; la detección de regresiones compara las puntuaciones actuales con una línea base y bloquea el despliegue si la calidad disminuye; y la ampliación del conjunto de pruebas a partir de fallos reales mantiene la suite de evaluación centrada en las necesidades reales de los usuarios. A continuación clasificaremos los modos de fallo de los agentes y diseñaremos estrategias de recuperación.

Gratis para empezar

Aprende Python con un tutor de IA — gratis

Escribe y ejecuta código real en tu navegador, obtén ayuda instantánea de un tutor de IA disponible 24/7 y continúa donde lo dejaste en la web o en la aplicación.

Cursos
30
Lecciones
120

Preguntas frecuentes

¿La lección «Creación de un pipeline de evaluación continua» es gratis?

Sí — el texto completo de «Creación de un pipeline de evaluación continua» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de AI Engineering Academy, actualiza a CoddyKit PRO. El curso de AI Engineering Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Creación de un pipeline de evaluación continua»?

Integre la evaluación mediante LLM-as-judge en su pipeline de CI/CD para que cada cambio en un prompt o modelo se evalúe automáticamente con un conjunto de pruebas de regresión antes del despliegue. Practicas AI Engineering Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar AI Engineering Academy?

No se requiere experiencia previa. AI Engineering Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.

¿Cuánto tiempo toma la lección «Creación de un pipeline de evaluación continua»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de AI Engineering Academy?

Sí. Cada lección de AI Engineering Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. El patrón LLM como juez
  2. Evaluación puntual y por pares
  3. Calibración de modelos juez frente a evaluadores humanos
  4. Creación de un pipeline de evaluación continua
← Volver a AI Engineering Academy