Salta al contenuto
geekandhackGH

AI & Agenti · dal video

Smistare ticket con Ollama Decision Models: metodo e controlli

Come impostare una prova di smistamento ticket con Ollama Decision Models: categorie, set di test, soglie, privacy e limiti.

Di Manu · Pubblicato il

Video collegato

OLLAMA DECISION MODEL →

Il video collegato mostra un Decision Model di Ollama che smista un ticket direttamente sul PC, senza cloud. Questa guida non ripete il video: spiega come impostare una prova di smistamento che si possa controllare, quali errori misurare e quando tenere una persona nel flusso. I tempi e la precisione dipendono da modello, hardware e categorie scelte: nessun numero qui è una garanzia per la tua macchina.

Cosa significa smistare un ticket

Smistare vuol dire assegnare ogni richiesta alla coda giusta: tecnica, amministrativa, commerciale, oppure da verificare. Un chatbot risponde in testo libero; un Decision Model restituisce punteggi sulle alternative definite da te. Il workflow poi applica le tue regole: sopra una soglia agisce, sotto inoltra a una persona.

Prepara categorie che non si sovrappongono

Il primo lavoro è sulle definizioni, non sul modello. Scrivi cosa entra in ogni categoria e, soprattutto, i casi di confine: un sollecito di fattura è amministrativo o commerciale? Un bug segnalato da un cliente pagante ha la stessa priorità di una domanda generica? Se due categorie si sovrappongono, il modello indovinerà dove tu non hai deciso.

  • Una frase di definizione per categoria, con esempi inclusi ed esclusi.
  • Una categoria di fallback per input ambigui o fuori ambito.
  • La regola di instradamento per ogni categoria: chi la riceve e con quale priorità.

Costruisci il set di prova prima di automatizzare

Metti da parte alcune decine di ticket reali (anonimizzati) con la categoria corretta assegnata da una persona. Esegui il modello su questi input e confronta: conta assegnazioni corrette, errori per categoria e casi mandati a verifica. Solo con questi numeri puoi scegliere una soglia invece di inventarla.

{
  "text": "TICKET_DI_PROVA_ANONIMIZZATO",
  "choices": ["tecnico", "amministrativo", "commerciale", "da_verificare"]
}

Soglie diverse per errori diversi

Un falso negativo su un ticket urgente costa più di un falso positivo su una richiesta informativa. Imposta la soglia di azione automatica in base al costo dell'errore per quella categoria, e abbassala (più verifiche umane) dove sbagliare fa male. Registra gli errori reali ogni settimana e rivedi le soglie: una configurazione buona oggi deriva domani.

Privacy: i ticket sono dati delicati

Un ticket contiene nomi, email, dettagli di contratto e a volte dati sensibili. Prima di farli elaborare a un modello, verifica dove gira l'inferenza e chi può accedere ai log: locale sul tuo PC, un server tuo o un servizio esterno cambiano tutto. Anonimizza il set di prova e non usare ticket reali con dati personali finché il percorso non è verificato.

Limiti onesti

Un Decision Model non capisce il tuo business: applica pattern statistici alle categorie che hai definito. Input ambigui, categorie nuove e cambi di tono dei clienti lo mandano fuori strada senza avvisare. Il video correlato riporta nel titolo un tempo osservato in quella specifica prova: consideralo un riferimento a quella configurazione, non una specifica del modello.

Fonti e video

Approfondimento: Video: smistamento ticket mostrato sul PC

Approfondimento: Video: OLLAMA DECISION MODEL

Fonte: API chat di Ollama

Approfondimento: Approfondimento: classificare richieste con output strutturato