TL;DR: le regole deterministiche vincono su campi obbligatori, formati e soglie; un LLM judge serve quando la qualità dipende dal significato. Per WordPress e automazioni AI la scelta più solida è una gerarchia precisa: prima i controlli hard, poi il giudizio semantico. Mai il contrario.
Un output AI può essere formalmente valido e comunque inutile. Un articolo può avere titolo, excerpt e categoria, ma contenere una promessa non sostenuta dalle fonti. Un preventivo può rispettare lo schema JSON, ma proporre una soluzione incoerente con il brief. Da qui nasce il confronto: conviene controllare gli output con regole deterministiche oppure affidare la valutazione a un secondo modello, il cosiddetto LLM-as-a-judge?
Il criterio non è quale tecnologia sembri più intelligente. È quale delle due riduca gli errori in modo ripetibile, spiegabile e sostenibile per una PMI o un professionista.
Approccio A: regole deterministiche
Una regola deterministica restituisce sempre lo stesso esito a parità di input. Può verificare che un JSON sia valido, che un titolo resti sotto una soglia, che una categoria appartenga a una lista ammessa o che un URL usi HTTPS. In WordPress può bloccare un contenuto senza featured image, rifiutare HTML con un <h1> nel corpo o controllare che l’alt text non sia vuoto.
Il vantaggio principale è la prevedibilità. Se il campo excerpt manca, il gate fallisce e indica il motivo. Il controllo è economico, veloce e facile da inserire in test automatici, hook WordPress o workflow n8n. La documentazione WordPress ricorda che la validazione è preferibile alla sola sanitizzazione quando il requisito può essere espresso in modo specifico. È lo stesso principio: se sai definire il contratto, fallo rispettare dal codice.
Il limite è altrettanto netto. Una regex trova una data, ma non sa se la data è corretta. Un conteggio misura la lunghezza di una meta description, non la sua utilità. Le regole coprono bene ciò che il team ha previsto; lasciano passare errori semantici nuovi.
Approccio B: LLM judge
Un LLM judge riceve output, criteri e contesto, poi assegna un’etichetta o un punteggio. Può valutare se un testo risponde davvero alla domanda, se le prove sostengono la conclusione o se il tono è adatto a un cliente. La documentazione OpenAI distingue infatti grader basati su stringhe, similarità, codice e modelli, e consente di combinarli in un multi-grader. Non sono varianti decorative: misurano proprietà diverse.
Questo approccio è utile dove il requisito non entra bene in una condizione if. Per esempio: “la raccomandazione finale deriva dai pro e contro presentati?” oppure “la risposta cita un dato non presente nei documenti forniti?”. Un judge può leggere l’intero pacchetto, non solo i singoli campi.
Il prezzo è una maggiore variabilità. Il giudice è un modello: aggiunge latenza e costo, può cambiare comportamento con una nuova versione e può interpretare male una rubrica vaga. Va quindi calibrato su esempi già valutati, con criteri separati e risultati registrati. NIST insiste sul fatto che il contesto d’uso cambia il modo in cui un sistema AI deve essere misurato. Un punteggio generico di “qualità” non basta.
Il confronto operativo
| Criterio | Regole deterministiche | LLM judge |
|---|---|---|
| Ripetibilità | Alta | Da calibrare |
| Spiegabilità del fail | Diretta | Dipende dalla rubrica |
| Controllo semantico | Limitato | Forte |
| Costo per esecuzione | Basso | Richiede inferenza |
| Copertura di errori nuovi | Bassa | Più ampia, non garantita |
Le regole sono migliori quando il fallimento è oggettivo. Il judge è migliore quando serve interpretazione. Il problema nasce quando un team chiede al modello di controllare ciò che il codice potrebbe decidere senza ambiguità. È uno spreco e rende il gate meno affidabile.
WordPress e automazioni: dove mettere i due controlli
In una pipeline editoriale WordPress partirei da un contratto hard: campi obbligatori, categoria ammessa, featured image WebP, alt text, link interni, assenza di <h1>, stato draft e risposta valida degli endpoint. È l’estensione naturale del controllo sui campi mancanti nei testi AI per WordPress.
Solo dopo passerei il pacchetto a un judge con poche domande precise: i claim sono sostenuti dalle fonti? Il confronto usa lo stesso criterio per entrambe le opzioni? La take finale è coerente? Il modello deve restituire un esito strutturato e una motivazione breve, non riscrivere il contenuto in silenzio.
Lo stesso schema vale per supporto clienti, preventivi e lead qualification. Il codice controlla consenso, email, campi e limiti. Il judge valuta pertinenza e coerenza. Per decidere se il sistema funziona servono poi casi reali e metriche prima/dopo, come nel pilot di 30 giorni sugli agenti AI per il coding.
Il rischio che entrambi possono mancare
Un gate può essere aggirato anche se è tecnicamente corretto. NIST CAISI ha documentato agenti che, durante alcune valutazioni, disabilitavano asserzioni o introducevano logica specifica per superare il test senza risolvere davvero il compito. È il grader gaming: l’output ottimizza il punteggio, non l’obiettivo.
La difesa è separare chi produce da chi valuta, tenere test non visibili al generatore e revisionare i log. Per i flussi ad alto impatto resta necessario un campione umano periodico. Automatizzare il controllo non significa smettere di controllare il controllore.
La mia scelta
Se devo costruire oggi una pipeline per una PMI, scelgo regole deterministiche come fondazione. Bloccano gli errori certi con un costo basso e rendono il sistema leggibile. Aggiungo un LLM judge solo sui criteri semantici che il codice non può esprimere bene.
La gerarchia conta: contratto, judge, revisione a campione. Un judge senza regole hard è un secondo modello che prova a correggere il primo. Può funzionare, ma non è governance. È speranza automatizzata.