Creazione di una pipeline di valutazione continua
Integri la valutazione LLM-as-judge nella pipeline CI/CD, così che ogni modifica al prompt o al modello venga valutata automaticamente rispetto a una suite di test di regressione prima del deployment.
Creazione di una pipeline di valutazione continua è una lezione AI Engineering Academy gratuita su CoddyKit. Questa è la lezione 4 di 4. Puoi leggere la lezione completa qui gratuitamente — poi esercitati direttamente nel browser con un editor di codice integrato e un tutor IA disponibile 24/7. Fa parte del percorso di apprendimento AI Engineering Academy, e i tuoi progressi si sincronizzano tra il web e l'app CoddyKit. Il corso AI Engineering Academy include 4 lezioni in totale.
Perché la valutazione deve essere continua
Una valutazione eseguita una sola volta durante il deployment non è sufficiente. La qualità degli LLM può degradarsi silenziosamente: i provider aggiornano i propri modelli, le modifiche al prompt di sistema possono sfuggire ai controlli, la qualità del recupero cambia con la crescita del corpus di documenti e la distribuzione delle richieste degli utenti varia nel tempo. Una pipeline di valutazione continua esegue la stessa suite di valutazioni a ogni modifica e secondo una pianificazione, così da rilevare le regressioni della qualità nel giro di ore, non di settimane.
Componenti principali della pipeline
Una pipeline di valutazione continua ha cinque componenti: un dataset di test (domande curate con gli output attesi), un system runner (che chiama la pipeline LLM per ogni domanda di test), un giudice (che assegna un punteggio a ogni risposta), un results store (un database o un archivio di serie temporali per le metriche storiche) e un livello di reporting (dashboard e avvisi). Ogni componente può essere aggiornato indipendentemente.
# 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 notificationStrutturare il dataset di test
Salvi il set di test per la valutazione come file JSON o YAML versionato nel repository. Ogni elemento contiene una domanda, la categoria (fattuale, procedurale, fuori ambito) e, facoltativamente, una risposta di riferimento. Versioni il set di test separatamente dal codice: aggiungere nuovi casi di test è una modifica compatibile con le versioni precedenti, mentre rimuovere casi può nascondere regressioni. Punti ad avere 200-500 casi distribuiti tra tutte le categorie pertinenti.
# 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
# },
# ...
# ]
# }Eseguire la suite di valutazione
Il runner di valutazione chiama il sistema in produzione (o una versione di staging) per ogni caso di test e registra la risposta e i metadati. Associ a ogni esecuzione della valutazione un ID univoco, lo SHA del commit che l'ha attivata, il timestamp e la versione del set di test. In questo modo è possibile confrontare esattamente le esecuzioni e diagnosticare quale modifica al codice abbia causato una regressione.
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}Archiviare e interrogare le metriche storiche
Renda persistente nel database il risultato di ogni esecuzione della valutazione. È sufficiente una semplice tabella eval_results con i campi run_id, commit_sha, case_id e score. Interroghi i punteggi aggregati per run_id per calcolare le metriche di ogni esecuzione. Confronti l'esecuzione corrente con l'ultima esecuzione riuscita sul ramo principale per rilevare le regressioni. Un database di serie temporali come InfluxDB funziona bene per il monitoraggio continuo.
-- 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);Rilevare automaticamente le regressioni
Dopo ogni esecuzione della valutazione, confronti i punteggi aggregati con la baseline (l'ultima esecuzione del ramo principale approvata manualmente). Una regressione è definita come una delle seguenti condizioni: una qualsiasi dimensione del punteggio scende di oltre il 5% rispetto alla baseline, oppure il punteggio medio di una categoria scende al di sotto di un minimo rigido. Le regressioni devono bloccare il deployment e inviare un avviso al team. I miglioramenti possono essere approvati automaticamente.
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}Integrare con CI/CD
Aggiunga la suite di valutazione come passaggio CI eseguito a ogni pull request. La pipeline CI chiama il sistema di staging, esegue il giudice, archivia i risultati e verifica la presenza di regressioni. Se viene rilevata una regressione, il passaggio CI fallisce e blocca il merge della PR. Aggiunga questo controllo come verifica di stato obbligatoria in GitHub o GitLab, così nessuno potrà aggirarlo. Mantenga il tempo di esecuzione della valutazione sotto i 10 minuti usando un sottoinsieme di 50-100 casi per i controlli sulle 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_IDEsecuzioni complete della valutazione pianificate
Oltre ai controlli sulle PR, esegua quotidianamente la suite di valutazione completa (tutti gli oltre 300 casi) in produzione. Questo permette di rilevare un graduale deterioramento della qualità che nessuna singola modifica introduce, ad esempio se il recall del database vettoriale peggiora con l'aggiunta di documenti o se il provider LLM aggiorna il modello senza comunicarlo. Le esecuzioni complete quotidiane forniscono una serie temporale della qualità che rende visibili le tendenze.
# 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
}
}Inviare avvisi sul deterioramento della qualità
Configuri gli avvisi in modo che vengano inviati quando le tendenze delle metriche superano le soglie di attenzione e critiche. Un calo del 3% nella correttezza media negli ultimi 7 giorni attiva un avviso di attenzione. Un calo del 10% in una singola esecuzione attiva immediatamente un avviso. Invii gli avvisi di attenzione a un canale Slack del team e quelli critici a PagerDuty. Includa in ogni messaggio di avviso l'analisi della regressione, un link alla dashboard della valutazione e il git blame delle modifiche recenti.
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})Gestire l'espansione del set di test
Ampli continuamente il set di test in base agli errori reali riscontrati in produzione. Quando un utente segnala una risposta errata, aggiunga quella domanda (anonimizzandola se necessario) al set di test insieme a una risposta attesa verificata da una persona. In questo modo la suite di valutazione riflette le esigenze effettive degli utenti invece di casi ipotetici. Tratti il set di test come un documento in continua evoluzione e lo riveda ogni trimestre per rimuovere i casi obsoleti.
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)Visualizzare le tendenze della qualità nel tempo
Costruisca una semplice dashboard della qualità che rappresenti nel tempo le metriche principali: punteggio medio di correttezza, tasso di hit della cache, latenza p95 e costo per query. Utilizzi una media mobile settimanale per attenuare il rumore dovuto a campioni di piccole dimensioni. Un grafico delle tendenze rende immediatamente visibile il deterioramento della qualità: un calo graduale del 3% nell'arco di sei settimane è invisibile nei report delle singole esecuzioni, ma evidente in un grafico di serie temporali. Grafana o anche un semplice script Python con matplotlib sono strumenti adatti.
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')Verifica rapida
Verifichi la Sua comprensione delle pipeline di valutazione continua per le applicazioni LLM.
Riepilogo della lezione
In questa lezione ha imparato che le pipeline di valutazione continua eseguono controlli automatici della qualità a ogni PR e quotidianamente per rilevare tempestivamente le regressioni, che il rilevamento delle regressioni confronta i punteggi correnti con una baseline e blocca il deployment se la qualità diminuisce e che l'espansione del set di test a partire dagli errori reali mantiene la suite di valutazione ancorata alle esigenze effettive degli utenti. Nel prossimo modulo classificheremo le modalità di errore degli agenti e progetteremo strategie di recupero.
Domande Frequenti
La lezione «Creazione di una pipeline di valutazione continua» è gratuita?
Sì — il testo completo di «Creazione di una pipeline di valutazione continua» è gratuito qui sul web. Per esercitarvi in modo interattivo (un editor di codice integrato e un tutor IA 24/7) e sbloccare il resto del corso AI Engineering Academy, passa a CoddyKit PRO. Il corso AI Engineering Academy include 4 lezioni in totale.
Cosa imparerò in «Creazione di una pipeline di valutazione continua»?
Integri la valutazione LLM-as-judge nella pipeline CI/CD, così che ogni modifica al prompt o al modello venga valutata automaticamente rispetto a una suite di test di regressione prima del deployment. Eserciti AI Engineering Academy con codice pratico che esegui direttamente nel browser, e un tutor IA 24/7 risponde alle tue domande mentre lavori sulla lezione.
Ho bisogno di esperienza per iniziare AI Engineering Academy?
Non è richiesta alcuna esperienza precedente. AI Engineering Academy su CoddyKit è strutturato per principianti e studenti avanzati, quindi puoi iniziare da qui o dall'inizio e procedere al tuo ritmo. Questa è la lezione 4 di 4.
Quanto tempo richiede la lezione «Creazione di una pipeline di valutazione continua»?
La maggior parte delle lezioni CoddyKit richiede circa 5–10 minuti. Ogni lezione è breve e interattiva, quindi fai progressi costanti e riprendi esattamente da dove hai lasciato su web e app.
Posso scrivere ed eseguire codice in questa lezione AI Engineering Academy?
Sì. Ogni lezione AI Engineering Academy include un editor di codice integrato, quindi scrivi ed esegui codice reale direttamente nel tuo browser e ricevi feedback istantaneo dall'IA — nessuna configurazione locale necessaria.
Tutte le lezioni di questo corso
- Il pattern LLM-as-Judge
- Valutazione pointwise e pairwise
- Calibrare i modelli giudice rispetto alle valutazioni umane
- Creazione di una pipeline di valutazione continua