Valutazione LLM online vs offline: quale ti serve (e quando)

Valutazione LLM online vs offline: quale ti serve (e quando)

La valutazione LLM online vs offline è una decisione unica, non due, e la nostra suite promptfoo lo ha dimostrato martedì scorso: un system prompt riscritto, 47 test case, faithfulness crollata da 0,91 a 0,74 in circa 90 secondi di CI. Il controllo offline ha intercettato quella regressione prima del merge; il monitoraggio in produzione l'avrebbe incontrata più tardi, travestita da ticket di supporto. Offline o online, il verdetto è lo stesso: due corsie, lavori diversi.

La valutazione LLM offline esegue il modello contro un dataset fisso prima del deploy, dimostrando che una modifica non ha rotto la qualità misurata. La valutazione online assegna punteggi al traffico di produzione reale dopo il lancio, facendo emergere ciò che il dataset non ha mai contenuto. La maggior parte dei team ha bisogno di entrambe, in sequenza: l'offline fa da gate al deploy, l'online intercetta il drift.

Punti chiave

• La valutazione offline gira su un dataset fisso prima del deploy; quella online assegna punteggi al traffico reale dopo il lancio.
• La maggior parte dei team ha bisogno di entrambe: l'offline fa da gate ai deploy, l'online cattura ciò che al dataset è sfuggito.
• L'offline intercetta regressioni dei prompt e rotture di formato; l'online intercetta drift, latenza sotto carico e stranezze di integrazione.
• Collega gli eval offline come gate di merge in CI; riversa i punteggi online dalle trace di produzione nel tuo eval set.

In cosa differiscono davvero la valutazione online e quella offline? (9 dimensioni)

Le due modalità differiscono su nove assi, ma quello decisivo è la fonte dei dati: la valutazione offline assegna punteggi a un dataset fisso e versionato prima del deploy, mentre quella online assegna punteggi al traffico reale dopo il lancio. Ogni altra differenza, dai costi alla latenza, dal rischio alla governance, discende da questa separazione.

Il learning center di Label Studio inquadra le due modalità come complementari, non come rivali, e noi concordiamo. La tabella estende quell'inquadratura con metriche specifiche per gli LLM che la loro versione generica per il ML non copre.

La nostra interpretazione: la colonna offline risponde a «questa modifica ha rotto qualcosa?», la colonna online risponde a «la produzione si sta allontanando da ciò che abbiamo testato?». La riga dei tipi di metriche è quella dove le due divergono di più; la nostra guida alle metriche di valutazione LLM le analizza una per una.

Cosa cattura ciascuna modalità, e cosa sfugge a entrambe?

Ciascuna modalità possiede una classe di fallimenti privata che l'altra non può vedere. L'offline cattura le modifiche che hai fatto tu; l'online cattura le modifiche che il mondo ha fatto intorno a te. I fallimenti più costosi, quelli che sopravvivono a entrambe le reti, richiedono un revisore umano. Questa tassonomia è una nostra sintesi di ciò che ciascuna modalità riporta, non uno standard pubblicato.

Il quadrante solo-offline è dove i gate CI si guadagnano lo stipendio: un prompt riscritto che fa scendere in silenzio la conformità del formato dal 99% al 91% è invisibile in code review e ovvio in una suite da 47 casi. Il quadrante solo-online è più insidioso. Gli utenti reali formulano frasi che il tuo golden set non ha mai visto, le API di terze parti vanno in timeout con tempistiche che lo staging non incontra mai, e qualcuno darà in pasto al tuo chatbot un prompt da 40.000 caratteri solo per vedere cosa succede. Per quel versante, la nostra guida su come valutare gli agenti in produzione copre lo scoring di traiettorie multi-step, non solo dei singoli output.

La riga in fondo è quella che i team saltano, ed è quella che li brucia. I fallimenti che ti costano gli utenti sono quelli che nessuna delle due modalità cattura da sola. Serve un umano nel loop.

Come si collegano gli eval offline a un gate CI? (La config che nessuno mostra)

Aggiungi un eval runner come check di stato obbligatorio su ogni pull request che tocca un prompt, un modello o una config di retrieval. Asserisci una soglia. Blocca il merge sotto di essa. promptfoo documenta esattamente questo pattern CI, ed è quello che usiamo noi.

Lo step GitHub Actions

Una versione ridotta del gate che usiamo oggi:

name: llm-eval-gate

on:
  pull_request:
    paths: ["prompts/**", "evals/**", "src/rag/**"]

jobs:
  faithfulness-gate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - name: Run offline evals, fail the PR on regression
        run: npx promptfoo@latest eval --config evals/support-agent.yaml
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}  # LLM-as-judge

La config YAML dichiara i test case e le asserzioni; eval esce con codice diverso da zero quando la suite scende sotto soglia, GitHub segna il check obbligatorio come fallito e il pulsante di merge diventa grigio. Il filtro paths conta: una modifica al README non dovrebbe bruciare token del judge.

Cosa cattura davvero il gate

La versione live valuta la nostra catena RAG del support agent contro 47 casi golden su ogni PR che tocca i prompt. Un run completo richiede circa 90 secondi di tempo CI, e il merge si blocca automaticamente se la faithfulness scende sotto 0,82. In tre mesi ha intercettato due regressioni che altrimenti sarebbero andate in produzione: la riscrittura di un system prompt che ha spinto la faithfulness da 0,91 a 0,74, e una modifica al retriever che ha raddoppiato la lunghezza del contesto e trascinato l'answer relevancy sotto soglia. Nessuna delle due sembrava pericolosa in review.

Un gate di faithfulness in CI costa 90 secondi per PR. Una regressione di faithfulness in produzione ti costa un thread di supporto e un rollback.

Abbiamo confrontato i runner che puoi inserire in questo pattern, promptfoo, DeepEval e gli altri, nella nostra rassegna degli strumenti di valutazione LLM.

Quali tool eseguono quale modalità? (Matrice tool-modalità)

Nessun singolo tool copre entrambe le corsie in modo pulito. promptfoo e DeepEval sono runner offline-first che possono valutare dati di produzione esportati su base schedulata; Langfuse e LangSmith sono trace store online-first che innestano scorer LLM-as-a-judge sulle trace acquisite. La matrice è la nostra lettura della documentazione di ciascun vendor: interpretazione, non vangelo.

Scegli promptfoo o DeepEval se la tua prima esigenza è un gate di merge che blocchi i prompt scadenti in CI. Scegli Langfuse o LangSmith se la tua prima esigenza è valutare il traffico live, e il nostro confronto Langfuse vs LangSmith entra nel merito di quella scelta. OpenAI Evals resta l'outsider: un runner offline in stile registry senza un versante produzione.

promptfoo fa da gate ai tuoi PR. Langfuse valuta le tue trace di produzione. Nessuno dei due sostituisce l'altro.

Come trasforma il feedback loop i fallimenti online in test offline?

Campiona le trace di produzione con punteggio basso, etichettale e committale nell'eval set offline. La suite di regressione così cresce a ogni sorpresa che la produzione ti riserva, e il deploy successivo passa dal gate su un set ampliato. L'inquadratura a volano è nostra; è la parte che la maggior parte dei team non costruisce mai.

Il ciclo, come lo eseguiamo noi:

1. Gli scorer online segnalano le trace sotto un punteggio judge di 0,7.
2. Campioniamo da 20 a 30 trace segnalate a settimana.
3. Un umano etichetta ciascuna: output atteso più classe di fallimento.
4. I casi etichettati entrano nell'eval set offline come nuovi esempi golden.
5. Il PR successivo gira sulla suite ampliata, e il loop riparte.

Il campionamento parte dal tuo livello di osservabilità LLM, perché le trace sono la materia prima. Sulla cadenza: settimanale batte mensile, perché il drift si accumula. Noi etichettiamo da 10 a 15 casi a settimana, e il set è «abbastanza grande» quando le nuove etichette smettono di muovere il tasso di successo, tra 150 e 250 casi per un support agent stretto. Il confine tra le modalità continua a sfumare: Deepchecks riporta che gli ingegneri di Union.ai schedulano i loro eval «offline» ogni pochi minuti, trasformandoli di fatto in controlli quasi in tempo reale.

Il tuo eval set non è un artefatto fisso. Cresce ogni settimana che la produzione ti sorprende.

Quando servono entrambe? (Valutazione LLM online vs offline per fase)

Servono entrambe dalla settimana di lancio in poi, ma l'equilibrio cambia per fase: l'offline porta da solo il lavoro pre-deploy, la settimana di lancio aggiunge lo scoring shadow o canary, lo stato stazionario si appoggia sul monitoraggio online con riesecuzioni offline periodiche, e un alert di drift dovrebbe concludersi con un test offline riprodotto più un eval set più grande.

Il pre-deploy è il posto più economico dove essere rigorosi: un merge bloccato costa minuti; un rilascio sbagliato costa fiducia. La settimana di lancio è dove i team sotto-investono, eppure lo scoring shadow su una piccola fetta di traffico costa poco e rivela se il golden set ha mentito. Lo stato stazionario è dove subentra la compiacenza, quindi metti a calendario la rivalutazione.

E l'EU AI Act?

Gli obblighi per i sistemi ad alto rischio dell'EU AI Act entrano in vigore gradualmente fino ad agosto 2026, con il calendario completo delle scadenze pubblicato su EUR-Lex, e il pattern di conformità si mappa in modo pulito sulle due modalità. L'evidenza offline documentata mostra che il sistema rispettava gli obiettivi di qualità prima del rilascio; il monitoraggio online continuo mostra che continua a rispettarli dopo. La nostra lettura è che un audit trail ha bisogno di entrambi gli artefatti, perché i log offline da soli non provano che il sistema sia rimasto conforme, e le dashboard da sole non provano che sia stato lanciato conforme. Questa è interpretazione, non consulenza legale; il nostro pilastro sulla pipeline di valutazione LLM mappa l'intero insieme di requisiti.

La valutazione offline è la tua prova. La valutazione online è il tuo sistema di allerta precoce. I regolatori vogliono entrambe.

Sull'autore: Mert Batur è Co-Founder di Techsy.io, dove il team rilascia agenti AI, sistemi di automazione e pipeline voce/SDR per clienti B2B. Scrive dello stack di tooling LLM che il team Techsy usa davvero in produzione. Seguilo su LinkedIn.

Domande frequenti

Cos'è la valutazione LLM offline?

La valutazione LLM offline esegue un modello o un prompt contro un dataset fisso e versionato prima del deploy. I controlli tipici includono faithfulness al contesto recuperato, answer relevancy, conformità del formato e punteggi di benchmark. Poiché il dataset non cambia mai durante l'esecuzione, i risultati sono ripetibili e confrontabili, ed è esattamente per questo che le suite offline funzionano come gate di merge in CI.

Cos'è la valutazione LLM online?

La valutazione LLM online assegna punteggi al traffico di produzione reale dopo il lancio. Uno scorer LLM-as-a-judge valuta le trace campionate per allucinazioni, tono o correttezza delle tool call, e i punteggi confluiscono in una dashboard. Assorbe anche segnali che i test offline non possono vedere: latenza sotto carico, feedback degli utenti e quanto le query reali differiscono dal tuo golden set.

Quando dovrei usare la valutazione LLM offline vs online?

Usa la valutazione offline come gate per i deploy: ogni modifica a prompt, modello o retrieval dovrebbe superare la suite prima del merge. Usa la valutazione online per monitorare ciò che va in produzione. La maggior parte dei team le usa in sequenza invece di sceglierne una: prima l'offline, l'online dalla settimana di lancio in poi, con i fallimenti di produzione che rifluiscono nel set offline.

Un esempio di valutazione LLM online vs offline?

Esempio offline: una suite promptfoo esegue 200 domande di supporto golden su ogni pull request e blocca il merge se la faithfulness scende sotto 0,82. Esempio online: Langfuse valuta il 10% delle trace live con un controllo LLM-as-a-judge sulle allucinazioni e lancia un alert quando la media settimanale cala. Stessa rubrica, fonte dei dati diversa.

Come si inserisce l'human-in-the-loop nella valutazione LLM?

Gli umani chiudono il divario che nessuna delle due modalità copre: edge case inediti, giudizi di qualità soggettivi e deriva del brand voice. Una cadenza pratica è etichettare da 10 a 20 trace campionate con punteggio basso a settimana e committare i casi etichettati nell'eval set offline. La coda di revisione è un input della pipeline, non un progetto parallelo.

Come funzionano le valutazioni di Langfuse per lo scoring online?

Langfuse acquisisce le trace dalla tua applicazione, poi aggancia evaluator LLM-as-a-judge che valutano ciascuna trace contro una rubrica: allucinazioni, rilevanza, tossicità o un prompt personalizzato. I punteggi finiscono su una dashboard indicizzata per sessioni e utenti. I team esportano le trace con punteggio persistentemente basso in un dataset offline per i test di regressione. La nostra rassegna delle piattaforme di osservabilità confronta i trace store che alimentano questo pattern.

Come aggiungo gli eval offline a una pipeline CI/CD?

Aggiungi un eval runner come check di stato obbligatorio sulle pull request che toccano prompt, modelli o config di retrieval. promptfoo e DeepEval girano entrambi headless ed escono con codice diverso da zero quando un'asserzione fallisce, il che blocca il merge automaticamente. Il gate YAML che hai visto prima in questo post è un template funzionante; parti con 30-50 casi.

L'EU AI Act richiede la valutazione offline o quella online?

Di fatto, entrambe. Per i sistemi ad alto rischio, l'Act si aspetta evidenza documentata che gli obiettivi di qualità fossero rispettati prima del rilascio, cioè artefatti offline, più un monitoraggio continuo dopo il deploy, cioè telemetria online. Le sue scadenze graduali arrivano fino ad agosto 2026 secondo EUR-Lex. Questa è la nostra lettura del pattern di conformità, non consulenza legale.

L'LLM-as-a-judge può girare sia in modalità offline che online?

Sì, e dovrebbe, perché la rubrica si trasferisce. Offline, il judge valuta in batch ogni output dell'eval set durante la CI. Online, lo stesso prompt del judge valuta le trace di produzione campionate quasi in tempo reale. Mantenere una rubrica unica tra le due modalità è ciò che rende la tua baseline offline comparabile con il tuo segnale di drift online.

Quali metriche differiscono tra valutazione offline e online?

Le metriche offline misurano la qualità dell'output rispetto alla ground truth: faithfulness, answer relevancy, conformità del formato, punteggi di benchmark. Le metriche online aggiungono segnali operativi e comportamentali: latenza p95, tasso di errore, tasso di allucinazione sul traffico live, punteggio di drift e soddisfazione degli utenti. L'elenco offline chiede «è buono?» e l'elenco online chiede «è ancora buono?».

La versione breve

• La valutazione offline e quella online sono corsie complementari, non un aut-aut: una fa da gate a ciò che rilasci, l'altra sorveglia ciò che hai rilasciato.
• Parti con il gate CI questa settimana, aggiungi lo scoring delle trace online al lancio e collega il feedback loop prima che il tuo eval set invecchi.
• Il loop è il sistema. Un golden dataset statico marcisce; uno che cresce produce interessi composti.

Se vuoi un secondo paio di occhi sulla tua pipeline di eval, richiedi una consulenza gratuita.