Abbiamo aumentato l’efficienza nell’elaborazione delle richieste di assistenza post-vendita dei clienti di tre volte utilizzando Claude 3, ma abbiamo commesso due errori che non avremmo dovuto commettere.

La scorsa settimana, al termine della raccolta dei dati del Black Friday, i tre sviluppatori del nostro team SaaS per l’e-commerce in Southeast Asia sono rimasti sbalorditi davanti ai dati del backend: gli ordini di assistenza clienti, che in passato richiedevano il lavoro continuo di un intero gruppo di assistenza per tre giorni, sono stati automaticamente gestiti per la maggior parte di quest’anno, con una riduzione diretta del 42% nel numero di reclami da parte dei clienti. L’unica modifica principale apportata è stata quella di sostituire l’intera logica di riconoscimento semantico degli ordini con Claude 3 Opus.

Per chi non ne ha mai sentito parlare, diciamo la verità…

È il terzo modello di linguaggio di grandi dimensioni lanciato da Anthropic nel 2024, e i parametri chiave che abbiamo utilizzato sono molto semplici: con una finestra di contesto di circa 200.000 caratteri, riusciamo a gestire ticket di assistenza tecnica che includono 3 screenshot di prodotti, con un tasso di accuratezza del 18% in più rispetto ai modelli precedenti che utilizzavano parametri simili.

Per un piccolo team come il nostro, i tre benefici sono davvero concreti e significativi in termini di risultati finanziari.

Il primo vantaggio è che non è più necessario effettuare una pre-elaborazione multimodale separatamente. In precedenza, per i prodotti danneggiati caricati dagli utenti o le immagini delle transazioni logistiche, dovevamo prima utilizzare un modello OCR per convertire le immagini in testo, e poi combinare quel testo con le informazioni presenti nelle richieste degli utenti per fornirle al modello principale. La manutenzione di questo processo occupava quasi metà delle risorse del backend. Con l’adozione di Claude 3, invece, è possibile inviare direttamente sia le immagini che il testo, riducendo così i casi di errori o omissioni nella riconoscimento.

Il secondo aspetto è che il tasso di rifiuto delle richieste è così basso da essere quasi trascurabile. I modelli precedenti, di fronte a ticket scritti in modo molto confusionario dagli utenti (ad esempio, in un misto di inglese e lingua locale, con l’uso di abbreviazioni internet), tendevano spesso a rifiutarli immediatamente, costringendo l’utente a rivolgersi a un operatore umano. Abbiamo calcolato che in quel periodo il 27% delle richieste richiedeva l’intervento umano; ora questa percentuale è scesa al 4%.

Il terzo aspetto è che i costi di utilizzo sono molto più bassi di quanto avessimo previsto. Paghiamo in base all’uso effettivo: il giorno di picco del Black Friday, abbiamo gestito in media 12.000 ticket al giorno, con un costo totale di meno di 800 dollari, il che rappresenta un risparmio del 90% rispetto al costo di assumere 10 agenti di assistenza clienti temporanei.

Ma non affrettarti a correre: i due errori che abbiamo commesso sono sufficienti per farti lavorare invano per tutta la settimana.

Il primo problema è quello dell’allineamento tra le diverse lingue. La metà dei nostri utenti parla indonesiano; all’inizio abbiamo lanciato il prodotto senza alcun aggiustamento, e quando si sono verificate espressioni gergali tipiche della lingua locale, il modello interpretava spesso frasi come “Il prodotto è stato inviato nella colore sbagliato” come “L’utente vuole cambiare l’indirizzo di consegna”, causando 17 reclami da parte dei clienti in una sola settimana. Solo dopo aver fornito al modello 3000 esempi di ordini in lingua locale correttamente etichettati, il problema è stato risolto.

Il secondo problema è la perdita di informazioni in contesti lunghi. Se un ticket contiene più di 5 immagini, a volte il modello può tralasciare alcune di esse; ad esempio, se l’utente ha scattato immagini della confezione danneggiata e del prodotto danneggiato, il modello riconosce solo il problema della confezione. Per risolvere questo problema, abbiamo aggiunto una semplice regola di verifica: se ci sono più di 3 immagini, facciamo in modo che il modello mostri i risultati della riconoscimento una per una prima, per poi elaborarli tutti insieme, e da allora non si sono più verificati errori.

A dire il vero, non tutti i team sono adatti all’uso di...

Le situazioni in cui dovresti usarlo:

• La tua attività richiede di gestire contemporaneamente testi, immagini e brevi file audio, e non desideri creare più set di processi basati su modelli diversi.
• Hai requisiti molto elevati in termini di precisione delle traduzioni, soprattutto in scenari come la gestione di ticket o la revisione di contratti, dove un errore può comportare costi significativi.
• Il tuo team ha una carenza di personale e non ha le risorse per mantenere i complessi processi di pre-elaborazione dei modelli.

Situazioni in cui non dovresti sprecare soldi:

• Devi semplicemente eseguire risposte basate su parole chiave e creare testi per la pubblicità, tipiche di compiti leggeri; per questo sono sufficienti modelli economici.
• I tuoi dati aziendali hanno requisiti rigorosi per la memorizzazione localizzata e non è possibile trasferirli agli interfacce di modelli di terze parti.
• Il volume delle tue richieste è particolarmente basso, inferiore a 1000 al mese; quindi lo sviluppo di un nuovo modello comporterebbe costi più elevati rispetto ai benefici ottenuti.

Due consigli pratici per chi inizia per la prima volta

Il primo passo consiste nel testare il sistema in scenari marginali per 7 giorni prima di implementarlo sulle reti principali. All’inizio, abbiamo utilizzato i ticket storici degli ultimi 3 mesi per eseguire test offline; solo quando l’accuratezza ha raggiunto oltre il 95%, abbiamo iniziato a distribuire il 10% del traffico online, aumentando gradualmente fino a coprire l’intero traffico senza causare problemi significativi.

Il secondo consiglio è di non scegliere subito la versione più costosa di Opus. Abbiamo testato che, per gestire ordinari ticket di assistenza senza immagini, la versione Sonnet offre un tasso di accuratezza quasi identico a quello di Opus (con una differenza di meno del 2%) e il costo è solo la metà, il che è più che sufficiente.

Infine, una domanda che tutti pongono spesso: dobbiamo aspettare il prossimo modello? La nostra risposta è che, se il vostro business è già limitato dal problema dell’efficienza dovuta al trattamento multimodale e all’accuratezza insufficiente, è meglio utilizzare quello attuale. Dopotutto, iniziare a usarlo ora permette di risparmiare costi umani, che sono molto maggiori rispetto al piccolo aumento dei costi di chiamata che si avrà con l’attesa del prossimo modello.