La vostra casella di supporto riceve tre messaggi: « Non trovo la mia fattura », « Il download fallisce » e « Potete presentarmi la vostra offerta? ». Prima di redigere una risposta, bisogna decidere a quale team inoltrarli. Questa prima fase è una classificazione: scegliere una categoria da un elenco definito. Clef, annunciato da Cloudflare il 1° ottobre, invita a trattare questa scelta come un compito a sé stante. Ecco come preparare la sua valutazione su un supporto fittizio, con errori visibili e una correzione umana.
Iniziare con la decisione attesa
Nel nostro esempio dimostrativo, le categorie sono fatturazione, tecnica e commerciale. Una quarta categoria, fuori ambito, accoglie le richieste a cui questa organizzazione non sa rispondere. Accanto a queste categorie, l'applicazione possiede uno stato di trattamento: accettato o da rivedere. La categoria descrive la richiesta; lo stato descrive ciò che autorizzate a farne.
Questa separazione aiuta a comprendere una richiesta ambigua: «Il mio abbonamento è pagato, ma non riesco più ad accedere ai miei file.» Il modello può proporre una soluzione tecnica, mentre la vostra politica impone una verifica perché il messaggio riguarda anche un pagamento. Non è necessario costringere un solo tag a sopportare tutta la complessità dell'intervento.
Definite cosa resta fuori dal primo pilota: rimborso, chiusura del conto, modifica dei diritti o risposta inviata al cliente. Il classificatore proposto qui suggerisce un orientamento. Non attiva nessuna di queste azioni. Per un primo test, le persone continuano a lavorare normalmente mentre confrontate i suggerimenti con le decisioni prese.
Ciò che Cloudflare mette a disposizione
In l'annuncio del 1° ottobre 2026, Cloudflare presenta Clef e Clef-flash come modelli di decisione con uscite strutturate, disponibili in Workers AI. L'adattamento ai compiti dei clienti inizia con un accompagnamento umano; una piattaforma di fine-tuning self-service è annunciata per più tardi. Il fine-tuning consiste nell'adattare un modello a partire da esempi di un compito particolare.
La scheda ufficiale Clef su Hugging Face, consultata il 6 ottobre, mostra una licenza Apache-2.0 e descrive gli artefatti del modello. Questo non dimostra il suo funzionamento sul vostro hardware. La scheda contiene anche un tipo insolito in un esempio: non riprendiamo questo esempio come un contratto di integrazione validato.
Queste informazioni aprono due piste di prova da qualificare: un servizio ospitato o un'esecuzione dei pesi disponibili. La scelta dipende dai vostri vincoli di dati, dal vostro hardware e dal tempo di utilizzo. Prima di promettere una prova locale riproducibile, bisognerebbe fissare la revisione degli artefatti, le dipendenze e la configurazione hardware, quindi eseguire un test. Questo articolo non presenta né un'installazione eseguita né una chiamata fatturata.
I confronti pubblicati nell'annuncio sono quelli del fornitore. La nostra decisione di test non si basa sul loro ranking: il risultato interessante sarebbe un migliore orientamento delle vostre richieste, con un costo di errore accettabile. Diverse pagine dello stesso editore non costituiscono una conferma indipendente della qualità su un supporto francese.
Scrivere un contratto semplice per l’applicazione
Il contratto qui sotto è una proposta interna Partitech, indipendente dallo schema ufficiale di Clef. Descrive ciò che la vostra applicazione deve ricevere e verificare. Nessun nome di campo è presentato come parametro dell’API del fornitore.
| Elemento concettuale | Ruolo nel pilota | Verifica da prevedere |
|---|---|---|
| Identificativo di dimostrazione | Collegare ingresso e decisione | Presenza, unicità nel lotto |
| Testo autorizzato | Contenuto da classificare | Non vuoto, dimensione limitata, assenza di segreto |
| Versione delle categorie | Definire le scelte possibili | Versione riconosciuta dall'applicazione |
| Categoria proposta | Orientamento suggerito | Valore presente nella lista consentita |
| Punteggio eventuale | Aiutare a valutare l’accettazione | Formato atteso e interpretazione documentata |
| Stato di trattamento | Accettare o chiedere una revisione | Regola aziendale distinta dal modello |
Potete verificare il contratto con alcuni messaggi sintetici. Per «La fattura di dimostrazione non è trovata», l'etichetta di riferimento scelta per l'esercizio sarebbe fatturazione. Per «Il download del mio documento di dimostrazione si interrompe», sarebbe tecnica. Un messaggio pubblicitario senza richiesta riceverebbe fuori ambito. Questi esempi servono a verificare il cablaggio e le categorie; non misurano la qualità su clienti reali.
Prevedete i casi di rifiuto: testo assente, categoria sconosciuta, punteggio illeggibile, risposta incompleta e tempo scaduto. Il comportamento atteso è un intervento umano o un fallimento esplicito, mai un orientamento silenzioso verso una categoria predefinita. Una risposta ben formata può ancora contenere una decisione errata; i controlli di formato e di qualità restano separati.
Costituire un set di test che rivela gli errori
Il protocollo seguente è proposto da Partitech e non è stato eseguito. Iniziate con una linea guida di annotazione: cosa significa ogni classe, come trattare i messaggi con più argomenti e quando considerare fuori dal perimetro? Fate rileggere i casi ambigui da una seconda persona. Se gli annotatori non sono d’accordo, il modello non può risolvere da solo l’imprecisione della vostra organizzazione.
Separate quindi tre usi dei dati. Un lotto serve eventualmente ad adattare il modello. Un altro serve a scegliere le impostazioni e le soglie. Il set di test finale rimane congelato fino al confronto. Se si aggiusta una direttiva dopo aver visto i suoi errori su quest'ultimo set, esso diventa un set di sviluppo; preparate allora una nuova valutazione indipendente.
Evitate anche le copie tra lotti: due messaggi dello stesso filo, un modello di e-mail riprodotto o varianti quasi identiche possono dare l’impressione di generalizzazione. Per il nostro supporto fittizio, una separazione per conversazione e una revisione dei duplicati sarebbero controlli pertinenti. Conservate i messaggi autorizzati, riducete al minimo le informazioni identificative e non inviate alcun dato dei clienti senza un quadro già stabilito.
Includete le difficoltà reali: frasi molto brevi, francese approssimativo, richieste che mescolano due argomenti e vocabolario nuovo. Conservate la loro frequenza e natura. In questo modo potrete spiegare se un metodo riesce soprattutto nelle richieste evidenti e rimanda tutte le altre a una persona.
Contare gli errori in base alle loro conseguenze
Una matrice di confusione è una tabella che incrocia la categoria attesa con quella proposta. Permette di vedere dove il sistema sbaglia. Nel nostro esempio, classificare una richiesta commerciale come tecnica fa perdere tempo; classificare un problema di accesso come commerciale può ritardarne ulteriormente la risoluzione. Lo stesso numero di errori non produce quindi lo stesso costo aziendale.
Definite questo costo con le persone che trattano le richieste. Per il pilota, potreste contare il numero di riassegnazioni, il tempo di revisione e i casi urgenti mal indirizzati. Se utilizzate una scala numerica, indicate che si tratta di una scelta del vostro team e conservate le sue ragioni. Una ponderazione decisa dopo aver visto i risultati favorevoli renderebbe difficile difendere il confronto.
Un punteggio alto non significa automaticamente « decisione affidabile ». La calibrazione descrive la corrispondenza tra un livello di fiducia dichiarato e la frequenza delle decisioni corrette in casi comparabili. Per verificarla, raggruppate le decisioni per intervalli di punteggio, contate i casi e confrontate la fiducia con la correzione osservata. Un intervallo con pochissimi esempi fornisce poche informazioni: mostrate il suo numero piuttosto che dare un verdetto netto.
L'astensione merita anch'essa una misurazione. Se richiedete una revisione per tutti i messaggi difficili, le assegnazioni accettate possono sembrare eccellenti mentre il team umano mantiene l'essenziale del lavoro. Contate la quota delle richieste accettate, la quota da rivedere e il tempo di recupero. Esaminate i risultati per categoria e per tipo di difficoltà.
Confrontare prima di adattare
Il vostro punto di partenza, chiamato baseline, può essere una regola semplice: alcuni termini di fatturazione, un elenco di errori tecnici e un recupero in caso di conflitto. Aggiungete se utile un modello generalista con un output limitato. Confrontate queste soluzioni con Clef sugli stessi input, con le stesse categorie e le stesse regole di convalida. Un adattamento specializzato è giustificato solo dopo questo confronto.
| Misura proposta | Regole semplici | Modello generalista | Clef | Clef-flash |
|---|---|---|---|---|
| Errori per categoria | Da misurare | Da misurare | Da misurare | Da misurare |
| Costo aziendale degli errori | Da misurare | Da misurare | Da misurare | Da misurare |
| Da rivedere | Da misurare | Da misurare | Da misurare | Da misurare |
| Tempo di risposta | Da misurare | Da misurare | Da misurare | Da misurare |
| Costo e tempi di ripresa | Da misurare | Da misurare | Da misurare | Da misurare |
Misurate il tempo del percorso completo, inclusa la validazione e l’eventuale ripresa. Annotate la configurazione, la versione del modello e la data. Non sostituite una casella vuota con un risultato dell’annuncio: questa tabella deve descrivere il vostro test. Una soluzione più veloce nel formulare una previsione può restare meno utile se richiede più correzioni.
Autorizzare un pilota che si può fermare
Iniziate osservando, senza modificare automaticamente i file di supporto. Confrontate il suggerimento con l'orientamento umano, poi esaminate i disaccordi. Essi possono rivelare un errore del modello, un riferimento errato o una categoria da precisare. Risolvete queste cause prima di ricominciare un test con un protocollo esplicito.
Decidete in anticipo i criteri di accettazione: errori critici tollerati, carico massimo di revisione e categorie coperte. Prevedete un ritorno immediato al trattamento umano se le uscite diventano invalide, se gli errori critici aumentano o se il vocabolario cambia fortemente. Per questo esempio, il passo successivo utile è quindi stabilizzare le categorie e il set di test. La scelta del modello viene dopo questo contratto di business.
Fonti e data di verifica
Pagine primarie riaperte e lette il 6 ottobre 2026 : Cloudflare, lancio di Clef, 1 ottobre ; Cloudflare, scheda ufficiale Clef su Hugging Face. Il corpus sintetico, i contratti e le tabelle sono proposte Partitech. Nessun benchmark interno, addestramento o chiamata ospitata è stato effettuato per questo articolo.