0Pricing
AI Engineering Academy · Lezione

Valutazione, deployment e retrospettiva

Esegua l’intero harness di valutazione, incluse le metriche di retrieval, i punteggi di qualità LLM-as-judge e i test di carico, esegua il deployment su un cloud provider e scriva una retrospettiva con le lezioni apprese.

Valutazione, deployment e retrospettiva è 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.

L’ultimo miglio: valutazione prima del rilascio

Un sistema non è pronto per il rilascio finché non è stato valutato end-to-end in condizioni realistiche. La fase finale di valutazione combina tutte le tecniche apprese in questo percorso: metriche di recupero per verificare che la pipeline RAG trovi i chunk corretti, punteggi LLM-as-judge per verificare la qualità delle risposte, load test per verificare gli SLA di latenza e scansioni di sicurezza per verificare il rafforzamento. Tutti i controlli devono essere superati prima di iniziare il deployment.

Esecuzione dell’intero harness di valutazione

Esegua la suite completa di valutazione nell’ambiente di staging, utilizzando un campione rappresentativo di query simili a quelle di produzione. Registri tutte le metriche: hit rate, MRR e NDCG per il recupero; faithfulness e rilevanza della risposta per la generazione; costo per query; latenza p50/p95/p99. Confronti ogni metrica con i criteri di successo definiti nella fase di architettura. Non proceda al rilascio finché non saranno rispettati tutti i requisiti minimi inderogabili.

async def final_evaluation(system_url: str, test_set_path: str) -> dict:
    test_cases = load_test_set(test_set_path)
    results = []
    for case in test_cases:
        start = time.perf_counter()
        response = await query_system(system_url, case['question'])
        latency_ms = (time.perf_counter() - start) * 1000
        judge_score = await judge(case['question'], response['answer'], case.get('reference'))
        hit = any(case['relevant_doc'] in s for s in response.get('sources', []))
        results.append({'latency_ms': latency_ms, 'score': judge_score, 'hit': hit, 'cost': response.get('cost_usd', 0)})
    return compute_final_metrics(results)

Load test del sistema di produzione

Esegua un load test che simuli il traffico realistico di produzione prima di entrare in funzione. Utilizzi uno strumento come Locust o k6 per raggiungere gradualmente la concorrenza massima prevista, ad esempio 50 utenti simultanei, e misuri come cambia la latenza sotto carico. Verifichi che i circuit breaker non scattino sotto carico normale, che il rate limiter restituisca risposte 429 corrette durante il traffico a raffica e che il tasso di hit della cache semantica rimanga sopra l’obiettivo. Risolva eventuali regressioni prima di procedere.

# Locust load test (locustfile.py)
from locust import HttpUser, task, between
import random

QUESTIONS = [
    'What is the return policy?',
    'How do I cancel my subscription?',
    'Where are you located?',
]

class AIUser(HttpUser):
    wait_time = between(1, 3)  # realistic think time

    @task
    def query(self):
        self.client.post(
            '/query',
            json={'question': random.choice(QUESTIONS), 'tenant_id': 'load_test'},
            headers={'Authorization': 'Bearer test_token'}
        )

# Run: locust -f locustfile.py --headless -u 50 -r 5 --run-time 5m

Deployment in produzione

Esegua il deployment con una strategia blue-green: avvii la nuova versione (green) accanto a quella esistente (blue), esegua gli smoke test su green, quindi sposti gradualmente il traffico da blue a green. Iniziando con il 5% del traffico su green, monitori tassi di errore e latenza per 10 minuti, poi passi al 25%, quindi al 50% e infine al 100%. In questo modo può eseguire immediatamente il rollback a blue in caso di problemi, senza alcun downtime.

# Deployment steps (pseudocode for AWS ECS or K8s):
# 1. Build and push new Docker image
#    docker build -t qa-assistant:v2.0 . && docker push ...
#
# 2. Deploy green (new) version alongside blue (current)
#    kubectl apply -f deploy/green.yaml
#
# 3. Run smoke tests against green
#    pytest tests/smoke/ --base-url https://green.internal
#
# 4. Canary traffic shift (ALB weighted routing)
#    5%  -> green (monitor 10min)
#    25% -> green (monitor 10min)
#    50% -> green (monitor 10min)
#    100% -> green
#
# 5. Decommission blue after 24h stability

Monitoraggio post-deployment

Dopo il deployment, monitori attivamente le metriche chiave per le prime 2 ore. Controlli: tasso di errore (obiettivo <1%), latenza p95 (obiettivo <8s), tasso di hit della cache (obiettivo >20%) e costo per query (obiettivo <$0.05). Configuri un canale Slack war room con tutti gli ingegneri reperibili per il primo deployment. Il superamento di una soglia di warning attiva un’indagine; il superamento di una soglia critica attiva il rollback immediato a blue.

# Post-deploy monitoring dashboard queries:
# (Assuming Grafana + Prometheus)

# Error rate (last 5 min):
# rate(http_requests_total{status=~'5..'}[5m]) / rate(http_requests_total[5m])

# p95 latency (last 5 min):
# histogram_quantile(0.95, rate(query_duration_seconds_bucket[5m]))

# Cache hit rate:
# rate(cache_hits_total[5m]) / rate(queries_total[5m])

# Average cost per query:
# rate(llm_cost_usd_total[5m]) / rate(queries_total[5m])

Redazione della retrospettiva sull’architettura

Dopo una settimana di attività del sistema, scriva un documento retrospettivo che descriva cosa ha funzionato, cosa non ha funzionato e cosa farebbe diversamente. Una buona retrospettiva è onesta riguardo ai fallimenti e precisa sugli insegnamenti ricavati. I lettori futuri, incluso Lei tra sei mesi, trarranno beneficio dalla comprensione delle motivazioni alla base delle decisioni prese sotto pressione e degli ostacoli imprevisti incontrati.

# RETROSPECTIVE.md structure:
#
# ## What Worked Well
# - Hybrid retrieval improved hit rate from 71% to 89%
# - Semantic cache reduced average cost by 31%
# - LangSmith tracing saved 2 days of debugging
#
# ## What Did Not Work
# - Semantic chunking was 4x slower than recursive chunking
#   with only 3% hit rate improvement -- not worth it
# - Cohere reranker had 400ms latency -- too slow for p95 target
#   Switched to BGE-reranker-v2 running locally
#
# ## What We'd Do Differently
# - Start with pgvector, not Pinecone (migration cost 3 days)
# - Add semantic cache BEFORE building the agent, not after

Documentazione dei runbook operativi

Scriva runbook per ogni alert che può attivarsi in produzione. Un runbook è una guida passo passo per diagnosticare e risolvere uno specifico alert. Deve rispondere a queste domande: che cosa significa questo alert, qual è la causa probabile, come posso diagnosticarlo e come posso risolverlo? I runbook riducono il tempo medio di risoluzione (MTTR) da ore a minuti, eliminando la necessità di elaborare i passaggi diagnostici durante un incidente stressante.

# runbooks/latency.md
# ## Alert: p95 Latency > 8000ms
#
# ### Likely Causes
# 1. OpenAI API degraded (check status.openai.com)
# 2. Cohere reranker slow (check Cohere status page)
# 3. pgvector query slow (check DB CPU in CloudWatch)
# 4. Redis cache full (check Redis memory usage)
#
# ### Diagnosis
# curl https://api.openai.com/v1/models -H 'Authorization: Bearer $KEY'
# Check LangSmith traces for which step is slow
# SELECT mean(duration) FROM traces GROUP BY step
#
# ### Fixes
# - If OpenAI slow: circuit breaker should auto-failover to Claude
# - If Cohere slow: disable reranking temporarily (env SKIP_RERANK=1)
# - If DB slow: increase pgvector ef_search from 40 to 20

Misurazione dell’impatto sul business

Dopo un mese in produzione, misurate l'impatto aziendale del sistema andando oltre le metriche tecniche. Per un assistente di domande e risposte: di quanto è diminuito il volume dei ticket dell'assistenza clienti? Qual è il punteggio di soddisfazione degli utenti per le richieste a cui ha risposto l'IA? A quante richieste ha risposto il sistema che in precedenza richiedevano l'intervento degli operatori dell'assistenza? Queste metriche aziendali giustificano l'investimento e guidano le priorità future tra miglioramenti della qualità e nuove funzionalità.

# Business impact metrics (month 1):
# Technical:
# - 12,847 queries served, 11,439 (89%) answered without human
# - Avg query cost: $0.031 (within $0.05 budget)
# - System uptime: 99.94%
#
# Business:
# - Support tickets: 1,840/month -> 1,203/month (-35%)
# - Avg resolution time: 4.2h -> 23 seconds for AI-answered
# - User CSAT on AI answers: 4.1/5.0
# - Cost per resolved query: $12 (human) -> $0.031 (AI)
# - ROI: 157% in month 1 at current volumes

Pianificare la prossima iterazione

Un sistema rilasciato non è mai davvero finito: è una base per un miglioramento continuo. Utilizzate i dati di valutazione, il feedback degli utenti e gli insegnamenti emersi dalla retrospettiva per pianificare la prossima iterazione. Date priorità ai miglioramenti che hanno il maggiore impatto sulle metriche più importanti: se il tasso di hit del retrieval è il fattore limitante, investite in un chunking migliore o in un modello di embedding diverso; se la soddisfazione degli utenti è bassa nonostante un buon retrieval, investite nella qualità dei prompt.

# Next iteration priorities (based on first month data):
NEXT_SPRINT = [
    # High impact / high confidence
    {
        'feature': 'Sentence-window retrieval',
        'expected_impact': 'Hit rate 89% -> 93%',
        'effort': 'medium',
        'evidence': '11% of failures due to answer split across chunks'
    },
    # High impact / medium confidence
    {
        'feature': 'Query decomposition for multi-hop questions',
        'expected_impact': 'Multi-hop correctness 61% -> 78%',
        'effort': 'high',
        'evidence': '23% of failures are multi-hop questions'
    },
    # Low effort quick win
    {
        'feature': 'Extend cache TTL from 1h to 24h',
        'expected_impact': 'Cache hit rate 31% -> 38%',
        'effort': 'trivial',
        'evidence': 'Same questions asked daily by different users'
    }
]

Condivisione delle conoscenze e documentazione

Scrivete la documentazione delle principali decisioni di implementazione non scontate del sistema. Tra queste rientrano: il motivo per cui è stata scelta una determinata dimensione dei chunk (e cosa hanno mostrato gli esperimenti), come è stata calibrata la soglia di similarità della cache semantica, quali pattern di prompt injection rileva attualmente il filtro e quali invece non rileva, e come aggiungere nuovi strumenti all'agente. Una buona documentazione interna riduce il tempo di onboarding dei nuovi collaboratori e impedisce che le decisioni vengano annullate accidentalmente da chi non ne conosce le motivazioni.

# INTERNALS.md — key non-obvious decisions:
#
# ## Chunk Size: 800 tokens with 100 token overlap
# We tested 400, 600, 800, 1200 tokens.
# 800 tokens maximizes hit rate (89%) while keeping context
# small enough for 5 chunks to fit comfortably in 4096 token prompt.
# Larger chunks improved recall but degraded precision.
#
# ## Cache Similarity Threshold: 0.92
# Tested 0.85, 0.90, 0.92, 0.95.
# 0.92 gives 31% hit rate with <2% incorrect cache hits.
# 0.85 gives 41% hit rate but 8% incorrect hits (too aggressive).
#
# ## Reranker Top-N: 3 (from initial 10)
# More than 3 chunks causes context stuffing without quality gain.

Ciò che ha realizzato

Riflettete sul sistema completo che avete realizzato nell'ambito di questo progetto conclusivo: una pipeline RAG ibrida che combina retrieval denso e sparso con reranking, un agente in streaming con chiamata di funzioni e protezioni di sicurezza, una cache semantica che riduce i costi del 30%, circuit breaker che forniscono il failover automatico, una valutazione LLM-as-judge eseguita continuamente nella CI/CD e difese contro la prompt injection che proteggono dagli input avversari. Questa è ingegneria dell'IA in produzione.

# System capabilities summary:
SYSTEM_CAPABILITIES = {
    'retrieval': 'Hybrid BM25+dense with Cohere reranking, 89% hit rate',
    'generation': 'GPT-4o with Claude fallback, circuit breaker, streaming',
    'caching': 'Semantic cache (Redis+embeddings), 31% cache hit rate',
    'security': 'Injection filter (2-stage) + output scanning + tenant isolation',
    'observability': 'LangSmith traces + Prometheus metrics + PagerDuty alerts',
    'evaluation': 'Automated LLM-as-judge in CI, daily full suite, LangSmith evals',
    'reliability': '99.94% uptime, circuit breakers, graceful degradation ladder',
    'cost': '$0.031/query average, model routing saves 67% vs GPT-4o only',
}

Verifica rapida

Mettete alla prova la vostra comprensione del deployment e della valutazione in produzione dei sistemi di IA.

Riepilogo della lezione

In questa lezione avete imparato che: la valutazione finale combina le metriche di retrieval, i punteggi LLM-as-judge, i test di carico e le scansioni di sicurezza prima dell'inizio di qualsiasi rilascio, il deployment blue-green con lo spostamento graduale del traffico consente di eseguire un rollback immediato senza downtime e le retrospettive e i runbook conservano la conoscenza organizzativa, riducendo il tempo necessario per risolvere gli incidenti futuri. Congratulazioni per aver completato il percorso AI Engineering: LLM, RAG and Agents!

Domande Frequenti

La lezione «Valutazione, deployment e retrospettiva» è gratuita?

Sì — il testo completo di «Valutazione, deployment e retrospettiva» è 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 «Valutazione, deployment e retrospettiva»?

Esegua l’intero harness di valutazione, incluse le metriche di retrieval, i punteggi di qualità LLM-as-judge e i test di carico, esegua il deployment su un cloud provider e scriva una retrospettiva c… 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 «Valutazione, deployment e retrospettiva»?

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

  1. Progettazione dell’architettura di produzione
  2. Implementazione delle funzionalità fondamentali di RAG e degli agenti
  3. Rafforzamento: sicurezza, caching e affidabilità
  4. Valutazione, deployment e retrospettiva
← Torna a AI Engineering Academy