“E se mettessimo l’intelligenza artificiale su questo?”. Questa frase circola nelle dimostrazioni da tre anni. Funziona ovunque perché è possibile inserire un LLM in qualsiasi cosa. Collegabile non significa utile. Nella maggior parte dei casi in cui viene utilizzato, una regex, una regola aziendale o un join SQL hanno già fatto il lavoro, meglio e con un costo mille volte inferiore.

Cinque situazioni in cui vedo progetti di IA che non avevano ragione di essere.

Classificazione quando le categorie sono stabili

Il vostro servizio clienti riceve le e-mail e deve indirizzarle ai reparti giusti. Un rappresentante di vendita vi offre un LLM per classificare le e-mail.

La domanda è: le categorie sono stabili e ben definite? Se è così, un classificatore addestrato su 200-500 esempi etichettati (o anche un insieme di regole basate su parole chiave) fa il lavoro con un’accuratezza del 90-95%, praticamente senza costi di inferenza e con una totale spiegabilità (si sa esattamente perché un’e-mail è stata classificata in una particolare categoria).

Un LLM costa da 10 a 100 volte di più a richiesta per un risultato simile. E si ha meno controllo sul comportamento dei confini.

L’IA generativa è utile per la classificazione quando le categorie sono vaghe, numerose o cambiano frequentemente. Per categorie stabili e ben definite, le soluzioni tradizionali sono migliori.

Estrazione di dati strutturati da un formato noto

Estrarre importi, date e nomi dai documenti.

Una regex o un parser strutturato lo fanno perfettamente su formati noti. È prevedibile, testabile e deterministico. Anche un LLM può farlo, ma con il rischio di allucinare valori numerici precisi (date, importi) e a un costo maggiore.

L’eccezione è rappresentata da documenti non strutturati in formati molto variabili (contratti scritti in linguaggio naturale, e-mail). È qui che LLM aggiunge valore. Per le fatture o i moduli con un formato noto, un parser strutturato è superiore.

Ricerca in un database già ben strutturato

Il vostro catalogo prodotti ha 10.000 referenze. Qualcuno suggerisce di aggiungere un LLM a scopo di ricerca.

Se i vostri riferimenti sono in un database relazionale con attributi ben definiti (categoria, colore, dimensione, prezzo), una ricerca SQL o Elasticsearch è più veloce, più precisa, più trasparente e infinitamente più economica.

LLM apporta valore alla ricerca in linguaggio naturale su contenuti non strutturati (documentazione, articoli, e-mail). Per le ricerche su attributi strutturati, vince il motore di ricerca classico.

Generare contenuti ad alto volume senza revisione umana

Il vostro team di marketing vuole “generare descrizioni dei prodotti con l’intelligenza artificiale” per accelerare la produzione.

Uso legittimo quando un umano corregge le bozze prima della pubblicazione. Un caso d’uso rischioso quando l’output viene messo direttamente online. La differenza tra i due casi non sta nello strumento, ma nel processo di correzione che può esistere o meno a valle. Senza questa fase, si pubblicano errori di fatto sui propri prodotti, senza nemmeno saperlo.

L’insidia: misurare l’aumento di produttività della generazione senza misurare il costo della revisione e delle correzioni. Spesso il guadagno netto è inferiore a quello suggerito dalla demo.

Il chatbot RAG su una documentazione già poco curata

“Mettiamo un chatbot nella nostra knowledge base, così i dipendenti possono trovare le informazioni più facilmente”

Se la base di conoscenza è ben strutturata e mantenuta, un motore di ricerca efficiente (Elasticsearch, Typesense) è spesso più preciso, meno costoso e più prevedibile di un RAG. I chatbot RAG sono utili quando la documentazione è voluminosa e varia e le domande sono aperte. Sono meno utili quando le domande sono concrete e le risposte si trovano in documenti chiaramente identificabili.

E se la vostra base di conoscenze non è ben curata, il chatbot RAG riprodurrà e amplificherà le incongruenze. È un problema di organizzazione, non di tecnologia.

L’IA come soluzione di ultima istanza

L’IA è la soluzione di ultima istanza. Non per una questione di principio: per una questione di disciplina di audit. Prima di firmare un progetto, è necessario aver eliminato due alternative. La regola aziendale deterministica, che ha funzionato per trent’anni con lo stesso tipo di problema. E la riorganizzazione dei processi, che a volte risolve il problema senza una sola riga di codice. Se queste due opzioni sono state esaminate ed escluse, allora vale la pena parlare di LLM. Altrimenti, si sta facendo IA per l’IA e si paga due volte: il conto delle API e il debito tecnico per non aver cercato qualcosa di più semplice.