Un ticket WordPress non deve per forza partire subito verso un modello cloud. Se contiene nomi, email, dettagli di un preventivo o frammenti di log, il primo passaggio può avvenire in locale: classificare la richiesta, togliere il rumore e inoltrare fuori solo ciò che richiede davvero un modello più forte. È un uso concreto per i modelli compressi, soprattutto quando il volume è ripetitivo e il dato merita un confine più stretto.

Il problema: usare il cloud anche per il lavoro banale

In molti flussi WordPress ogni richiesta segue la stessa strada: il form crea un ticket, l’automazione copia tutto il testo e un’API esterna decide categoria, priorità e risposta. Funziona, ma significa pagare e trasferire dati anche per compiti semplici come distinguere un problema di fatturazione da un errore del checkout. Il punto non è eliminare il cloud. È smettere di usarlo come primo filtro universale.

PrismML ha pubblicato Bonsai 2 27B, derivato da Qwen3.8 27B. Il pacchetto GGUF PTQ1_0 dichiarato nella model card ufficiale occupa 5,95 GB ed è distribuito con licenza Apache 2.0. Il produttore riporta il 98,2% del punteggio medio del modello FP16 sui propri benchmark. È un dato interessante, ma non è la prova che il modello capisca i ticket della tua azienda: quella va costruita sui casi reali.

La soluzione: un filtro locale con un compito stretto

Non chiedere al modello locale di scrivere la risposta definitiva. Dagli un incarico limitato e verificabile: restituire JSON con categoria, priorita, dati_sensibili e richiede_cloud. Le categorie devono essere poche e definite prima, per esempio accesso, pagamenti, bug e commerciale. Se l’output non rispetta lo schema, l’automazione non improvvisa: manda il ticket alla revisione umana.

Il vantaggio operativo sta nella separazione dei ruoli. Il modello locale esegue triage e minimizzazione; il modello cloud interviene solo sui casi complessi, possibilmente dopo che email, numeri d’ordine e altri identificativi sono stati mascherati. È lo stesso criterio che conviene usare quando si valuta un agente AI locale rispetto a una API cloud: prima si decide quale dato può uscire, poi si sceglie il modello. La dimensione ridotta rende la prova accessibile, non automaticamente sicura.

I passaggi essenziali per una prova che dica qualcosa

Prendi 30 ticket già chiusi, anonimizzali e assegna a mano la categoria corretta. Dividili in 20 casi di prova e 10 casi di controllo, senza riutilizzare gli stessi esempi nel prompt. Avvia il modello con il runtime indicato dal progetto, imposta temperatura bassa per ridurre la variabilità e chiedi soltanto l’oggetto JSON. Poi misura tre cose: categoria corretta, JSON valido e falsi negativi sui dati sensibili. Non basta leggere cinque risposte che sembrano buone.

La regola di instradamento deve restare esplicita. Un esempio: se dati_sensibili=true, il testo viene mascherato; se la priorità è alta o la confidenza scende sotto la soglia definita sul campione, il ticket passa a una persona; negli altri casi può essere inoltrato al workflow successivo. Salva input anonimizzato, output e decisione finale. Dopo una settimana puoi confrontare errori, tempo risparmiato e quota di richieste rimaste in locale, invece di discutere in astratto sulla qualità del modello.

L’errore da evitare e la take finale

L’errore più facile è scaricare il file e aprirlo con una build standard di llama.cpp. La model card specifica che i formati ternari PTQ1_0 e PQ2_0 richiedono il fork di PrismML con i kernel dedicati. Una build non compatibile può rifiutare il modello; nel caso Q2_0, la documentazione avverte che può anche caricarlo producendo output errato. Va quindi fissata una versione nota del runtime, verificato l’hash del file e conservato un test automatico con output atteso prima di collegare WordPress.

La mia take è semplice: il modello locale non deve vincere una gara generale contro il cloud. Deve togliere al cloud un compito ripetitivo, misurabile e sensibile ai dati. Se sui 10 ticket di controllo sbaglia le categorie critiche o non riconosce gli identificativi, non entra in produzione. Se passa, diventa un filtro economico e controllabile. Il criterio di successo non è “gira sul portatile”, ma “riduce dati in uscita senza aumentare gli errori operativi”.