Nei sistemi che utilizzano LLM, ci sono 15 passi tra "funziona" e "affidabile in production". L'automazione marketing produce output Markdown con Claude API, la segmentazione del customer journey utilizza GPT — ma quando modifichi il prompt, come sai di non aver introdotto una regressione? In ingegneria del software, il versionamento, la copertura dei test e la CI/CD sono standard; nelle operazioni LLM, senza questa disciplina, ogni deployment è una scommessa.

Strumenti come Promptfoo e LangSmith forniscono questa disciplina: versionamento dei prompt, valutazione deterministica, A/B test, tracking delle metriche. Questo articolo mostra come costruire il controllo di qualità in un sistema LLM in production — non a livello di codice, ma a livello di infrastruttura.

L'Illusione che il Prompt Non Sia Codice

La maggior parte dei team vede il prompt come un "file di configurazione" — un editor nell'interfaccia, documentazione in Notion, nodo di testo hardcoded nel workflow n8n. In realtà, il prompt è una specification eseguibile che definisce il comportamento del sistema. Ma non c'è versionamento, niente diff, niente rollback.

Un commit Git con messaggio "fix typo" può cambiare il tono dell'output del modello e abbassare le metriche. Specialmente negli scenari di structured output (schema JSON, frontmatter Markdown, query SQL), una singola parola che rompe il formato crea errori a cascata. Esempio: scrivere OUTPUT FORMAT: JSON invece di OUTPUT FORMAT: Valid JSON fa sì che il modello talvolta aggiunga paragrafi esplicativi — il parser downstream crasha, gli alert si attivano, debugging per 3 ore.

La disciplina del versionamento deve rispondere a queste domande:

  • Quale versione del prompt è attualmente in production?
  • Qual è la differenza di performance tra la versione di due settimane fa e quella attuale?
  • Quale variante nell'A/B test ha aumentato la conversione dell'8%?

Se non riesci a rispondere a queste domande, non stai facendo "operazioni AI", stai conducendo esperimenti manuali.

Pipeline di Valutazione: I Tre Livelli della Misurazione dell'Output

Valutare l'output di un LLM sembra soggettivo, ma nei sistemi in production è possibile costruire metriche deterministiche. La valutazione funziona su tre livelli: sintassi, semantica, risultato di business.

Livello di sintassi — conformità del formato:

  • Il JSON viene parsato correttamente?
  • Il frontmatter Markdown è valido?
  • Sono presenti i campi previsti?

In Promptfoo, si controlla con un'asserzione javascript:

assert: [
  {
    type: "javascript",
    value: "JSON.parse(output).title.length <= 60"
  },
  {
    type: "is-json",
    value: true
  }
]

Livello di semantica — qualità del contenuto:

  • La risposta è rilevante all'argomento? (similarità embedding, distanza coseno > 0,85)
  • Sono presenti parole vietate? (regex, token filtering)
  • Il tono è corretto? (modello classifier, sentiment score)

In LangSmith, valutatore personalizzato:

from langsmith import evaluate

def check_brand_compliance(run, example):
    forbidden = ["esperto", "leader", "rivoluzionario"]
    output = run.outputs["text"].lower()
    violations = [w for w in forbidden if w in output]
    return {"score": 0 if violations else 1, "violations": violations}

evaluate(
    dataset_name="marketing_blog_posts",
    evaluators=[check_brand_compliance]
)

Livello di risultato di business — l'impatto reale:

  • Il CTR è cambiato?
  • La conversione è diminuita?
  • Il bounce rate è aumentato?

Questo livello si collega alla telemetria in production — nel sistema di First-Party Data & Architettura di Misurazione, la versione del prompt viene aggiunta ai metadati del tracking degli eventi, unita in BigQuery, il modello dbt calcola il conversion rate di ogni versione.

Promptfoo: Costruire una Suite di Test Deterministica

Promptfoo è un framework di evaluation basato su YAML che gira localmente. L'obiettivo: verificare con test di regressione prima di ogni modifica del prompt.

Configurazione semplice:

prompts:
  - file://prompts/marketing_blog_v1.md
  - file://prompts/marketing_blog_v2.md

providers:
  - anthropic:messages:claude-3-5-sonnet-20241022

tests:
  - vars:
      topic: "Server-side GTM"
      category: "tech"
    assert:
      - type: is-json
      - type: javascript
        value: "output.title.length <= 60"
      - type: similar
        value: "server-side tracking architecture"
        threshold: 0.8
      - type: not-contains
        value: "rivoluzionario"

Con il comando promptfoo eval, tutte le varianti vengono testate e la tabella delle metriche viene restituita:

PromptPass RateLatenza MediaCosto
v192%2,3s$0,012
v298%2,1s$0,014

In v2 il pass rate è aumentato ma il costo è salito del 17% — il conteggio dei token aumenta, è necessario controllare nel dettaglio. Senza vedere questo tradeoff, il deploy avrebbe fatto esplodere il budget mensile.

A/B Test: Confrontare le Varianti dei Prompt in Production

La suite di evaluation è verde, ora servono dati di traffico reali. L'A/B test in un sistema LLM funziona così:

  1. Variant routing — scegli la versione del prompt in base all'ID utente/sessione (% split)
  2. Metadata tagging — aggiungi prompt_version a ogni API call
  3. Metric tracking — mantieni le informazioni sulla variante negli eventi downstream
  4. Significatività statistica — quando viene raccolta una quantità sufficiente di campioni (min 385 osservazioni per variante, 95% di confidenza), prendi una decisione

Esempio di workflow n8n:

// Selezione variante A/B
const userId = $json.user_id;
const variant = (userId % 100 < 50) ? 'v1' : 'v2';
const promptUrl = `https://raw.githubusercontent.com/roibase/prompts/main/${variant}.md`;

// Aggiungi metadati alla API call
return {
  json: {
    prompt: await fetch(promptUrl).then(r => r.text()),
    metadata: {
      prompt_version: variant,
      experiment_id: 'blog_tone_test_2026_05'
    }
  }
};

Analisi in BigQuery:

SELECT
  metadata.value:prompt_version AS variant,
  COUNT(DISTINCT user_id) AS users,
  AVG(session_duration_sec) AS avg_duration,
  SUM(conversion) / COUNT(*) AS cvr
FROM events
WHERE experiment_id = 'blog_tone_test_2026_05'
  AND event_date >= '2026-05-01'
GROUP BY 1

Risultato: la variante v2 ha aumentato il CVR da 0,042 a 0,051 (+21%), p-value 0,003 — può essere portata in production con fiducia.

LangSmith: Observability e Rilevamento di Regressioni a Lungo Termine

Promptfoo fa i test locali, LangSmith fornisce observability in production. Ogni LLM call viene tracciato: input, output, latency, token count, versione del modello, versione del prompt.

Il vantaggio di LangSmith è il tracking delle metriche a lungo termine. Se un bug della versione del prompt di 3 mesi fa viene scoperto oggi tramite feedback, torna alla trace, vedi la differenza input/output, trova quale versione era attiva quel giorno, fai il rollback.

Esempio di trace:

{
  "run_id": "abc123",
  "prompt_version": "v2.1",
  "model": "claude-3-5-sonnet-20241022",
  "input": {"topic": "Server-side GTM", "category": "tech"},
  "output": "---\ntitle: \"Server-Side GTM...\"",
  "latency_ms": 2341,
  "tokens": {"input": 1842, "output": 1523},
  "cost_usd": 0.0137,
  "feedback": {"score": 4, "comment": "il titolo è troppo lungo"}
}

Ciclo di feedback: gli editor danno un punteggio 1-5 a ogni blog, LangSmith lega questi punteggi alla trace, il rapporto settimanale avvisa "la versione v2.3 ha ridotto il punteggio medio a 3,2". Rollback immediato → diff del prompt → identifica il problema → correggi.

Gestione dei Dataset: Tenere il Golden Set Sotto Controllo di Versione

Il cuore della pipeline di evaluation è il golden dataset — coppie input/output conosciute, il riferimento del comportamento previsto. Mantenere questo dataset in Notion, aggiornarlo manualmente in Google Sheets è un rischio di regressione.

LangSmith dataset sotto controllo di versione:

from langsmith import Client

client = Client()

dataset = client.create_dataset("marketing_blog_golden_v3")

# Aggiungi gli esempi golden
examples = [
    {
        "inputs": {"topic": "Server-side GTM", "category": "tech"},
        "outputs": {"title": "Server-Side GTM: Misurazione Dopo i Cookie"},
        "metadata": {"expected_h2_count": 5, "expected_word_count": 1500}
    },
    # 50+ esempi...
]

for ex in examples:
    client.create_example(**ex, dataset_id=dataset.id)

Test ogni modifica del prompt contro questo dataset. Se il pass rate scende, non fare deploy. Aggiungi nuovi edge case al dataset (i bug che trovi in production), evita regressioni.

Tradeoff: Metriche Deterministiche vs Output Creativo

La forza dell'LLM è la non-determinismo — lo stesso input produce output diversi. Ma in un sistema in production, questo potere è un rischio: il cliente vede markdown diverso ogni volta che ricarica la pagina, alcuni sono errati.

Temperatura 0 aumenta il determinismo, ma l'output diventa monotono. Tradeoff:

  • Temperatura 0: ideale per le suite di evaluation, monotono in production
  • Temperatura 0,3-0,5: varietà ragionevole, comunque coerente
  • Temperatura 0,7+: creativo, ma sorprese in production anche se l'evaluation è verde

Soluzione: temperatura 0 nell'evaluation, 0,4 in production, nel golden set conserva 5 output accettabili diversi per ogni input (controllo di range).

Un altro tradeoff: latency vs qualità. Un prompt più lungo dà output migliore ma il costo dei token di input aumenta, la latency sale. In Promptfoo, se la metrica di latency supera 2,5s fai un alert — non rovinare l'esperienza utente.

Checklist di Production: Prima di Deployare il Sistema LLM

Checklist di controllo prima del deploy:

  • Il prompt è in git repo, la storia dei commit è pulita
  • La suite di evaluation Promptfoo ha pass rate > 95%
  • Il golden dataset ha min 50 esempi
  • Il piano di A/B test è pronto, la sample size è calcolata
  • LangSmith trace è attivo, la API key è in production
  • Il ciclo di feedback è implementato (scoring da editore, join BigQuery)
  • La procedura di rollback è definita (su quale calo di metrica tornare indietro automaticamente)
  • Il monitoring dei costi — daily token spend threshold $X
  • SLA di latency — p95 < 3s

Se non completai questa lista, non stai fornendo un "servizio AI", sei ancora presto. Senza versionamento, evaluation e observability, le operazioni LLM in production non sono una disciplina ingegneristica, sono caos controllato.

Il versionamento dei prompt è una questione di disciplina — non per la velocità, ma per l'affidabilità. In tattiche come Generative Engine Optimization, la qualità dell'output è direttamente collegata al risultato di business. Senza una pipeline di evaluation, ogni deployment rischia la performance precedente. Promptfoo fornisce la sicurezza locale, LangSmith la visibilità in production. Insieme, portano le operazioni LLM agli standard dell'ingegneria del software.