Indice degli argomenti
Inizia con questo articolo una serie di approfondimenti a cura di Giuseppe Ciuni sugli aspetti funzionali e tecnici, ma senza complicazioni, relativi al funzionamento delle intelligenze artificiali. L’autore è un profondo conoscitore delle tecnologie digitali, sviluppatore di codice e analista di sistemi, la sua organizzazione ha sede nel sud della Sicilia e lavora con clienti di tutto il mondo e qui sulle pagine di Startupbusiness condivide la sua conoscenza dei sistemi che normalmente definiamo come di intelligenza artificiale.
Cosa sono davvero gli LLM
Negli ultimi diciotto mesi l’adozione dell’IA in azienda è passata da una fase sperimentale a quella operativa vera e propria.
Chi lavora nel settore ha attraversato fasi ben riconoscibili: prima lo stupore: “ma che è sta roba, sembra magia!”, poi la domanda concreta: “ma è possibile imbrigliare tutto questo potere e integrarlo nella mia azienda o nel mio prodotto?”.
Da quel momento le startup e le aziende in genere hanno iniziato a integrare l’IA, nello specifico gli LLM, nei loro prodotti e processi.
Alcune integrazioni portano risultati concreti e misurabili, altre no. La discriminante è spesso una sola: la comprensione precisa di cosa fa davvero un LLM.
Non un database né un motore di ricerca
Un LLM non recupera informazioni da un archivio, non indicizza documenti come Elasticsearch né interroga un database come PostgreSQL. Quello che fa è più strano e capirlo cambia completamente il modo in cui si progetta un sistema IA. Proviamo ad andare un po’ più in profondità.
Un LLM è un simulatore statistico di testo
Durante il pre-training il modello viene esposto a trilioni di token estratti dal web (pagine web, libri, codice, forum, ecc.) e addestrato a fare una cosa sola: prevedere quale token viene dopo dato un contesto. Nient’altro.
Andrej Karpathy ex head of AI di Tesla e uno dei ricercatori più influenti nel campo descrive il modello base risultante come un sistema che non risponde a domande ma completa sequenze di testo in modo statisticamente coerente con ciò che ha visto durante l’addestramento.
Questa distinzione ha conseguenze dirette su cosa ci si deve aspettare da un modello LLM e in particolare da un LLM applicato a un contesto aziendale.
Microgpt, un GPT in 200 righe
Nel febbraio 2026 Karpathy ha pubblicato Microgpt, un file Python di 200 righe, zero dipendenze che implementa l’intero ciclo di training e inferenza di un GPT.
Il progetto include dataset, tokenizer, motore di autograd costruito da zero, architettura GPT-2 semplificata, ottimizzatore Adam e loop di training.
Il modello viene addestrato su 32mila nomi propri e impara a generarne di nuovi statisticamente plausibili.
Tutto ciò che serve per capire un LLM è lì leggibile in un pomeriggio ed è composto da queste parti:
Dataset + tokenizzazione + rete neurale Transformer + backpropagation + ottimizzazione.
Da notare che la distanza tra Microgpt e GPT-4 è di ordini di grandezza in parametri, dati e operazioni di calcolo ma l’algoritmo fondamentale è identico.
Come si può vedere un LLM non è magia: è matematica applicata su scala industriale.
LLM: il tokenizer
Il testo “grezzo” non può entrare direttamente in una rete neurale dato che la rete neurale lavora solo con numeri, serve una conversione. Tale conversione viene fatta dal tokenizer.
La scelta più ovvia per la conversione sarebbe processare carattere per carattere, “ciao” (che diventa [c, i, a, o]) oppure parola per parola.
Entrambe le scelte però hanno dei problemi:
- i caratteri producono sequenze troppo lunghe e perdono struttura
- le parole creano vocabolari enormi e non gestiscono bene parole rare o termini tecnici mai visti.
Bisogna trovare qualcosa di meglio che non faccia perdere struttura e che comprima in maniera intelligente le parole, mantenendo vocabolari di dimensioni controllate. Ci viene in aiuto l’algoritmo di byte pair encoding.
Ecco un esempio di funzionamento dell’algoritmo BPE:
- parte dai singoli caratteri di una frase;
- identifica iterativamente le coppie di simboli che appaiono più frequentemente nel testo e le fonde in un unico token, per esempio:
“th” appare spesso in inglese → diventa un token.
“the” appare ancora più spesso → diventa un token.
- Il processo si ripete finché non si raggiunge la dimensione di vocabolario desiderata.
Le parole molto frequenti (come “the”, “home”, “cat”) vengono salvate come token unici. Le parole rare vengono invece spezzate.
Questa rappresentazione in token ha conseguenze pratiche: il modello non “vede” le parole come le vediamo noi, certi errori apparentemente banali (come sbagliare a contare le lettere in una parola) derivano direttamente da questo livello di rappresentazione, non dalle capacità del modello.
Nota: Gli LLM più conosciuti (chatGPT, Claude, Gemini ecc), i modelli sono addestrati su dataset in lingua inglese, a parità di significato e di lunghezza del testo l’italiano consuma molti più token rispetto all’inglese (tra il 30% e il 50% in più).
Conviene quindi scrivere i prompt in inglese.
La mappa delle capacità reali di un LLM (cosa sa fare bene)
Gli LLM sono in grado di creare testo, di elaborare dati e fare tante altre attività. Bisogna però capire come attribuire un parametro qualitativo (una forma di ROI) ai risultati ottenuti.
Ecco tre esempi in un cui LLM si comporta bene in ambito aziendale:
Trasformazione di testo non strutturato in una struttura
Dato un documento, un contratto, un’email ecc, si vuole estrapolare dati organizzati (ad esempio un JSON o una tabella). Il modello funziona bene perché non deve “sapere” nulla che non sia già nel testo che gli si fornisce: legge quello che c’è, riconosce i pattern, li organizza nel formato che gli hai chiesto. È il caso d’uso più affidabile in assoluto.
Generazione di bozze
Il modello scrive una prima versione di un documento (per esempio di una specifica tecnica o una mail commerciale) partendo da input strutturati che gli si forniscono.
Il risultato non è l’output finale ma una bozza che un umano dovrà rivedere. Il valore della generazione di bozze consiste nel comprimere il lavoro dell’umano da ore a minuti.
La condizione necessaria è che il processo preveda esplicitamente la revisione umana, non come opzione ma come step obbligatorio.
RAG
Quando si interroga un LLM, ad esempio su dati aziendali proprietari, è molto probabile che si ottenga una risposta errata o ‘allucinata’. Il problema della risposta allucinata non è dovuta alla qualità del modello in uso, ma che i dati richiesti non sono presenti all’interno del modello (fase di pre-training)
Il RAG risolve questo problema a monte: invece di chiedere al modello di ricordare qualcosa – he non può conoscere – gli si fornisce l’informazione nel momento stesso in cui serve.
Il meccanismo è semplice: il sistema cerca nella knowledge base aziendale i documenti pertinenti alla domanda, li inserisce nel contesto della chiamata e risponde basandosi esclusivamente su quel materiale. Il risultato pratico è che le allucinazioni su dominio proprietario si riducono drasticamente.
Potenziali errori che potrebbero far bruciare budget
Il modello usato come oracolo
Se si chiede a un modello informazioni su dati interni all’azienda (per esempio: prezzi aggiornati, specifiche tecniche proprietarie, disponibilità a magazzino) il modello non ha accesso a queste informazioni.
Durante il pre-training ha letto miliardi di documenti dal web: tutto quello che ha imparato è stato compresso nei suoi parametri che sono fissi dopo il training. Non sa cosa è successo ieri, non conosce i dati aziendali, non ha accesso al tuo database clienti.
La risposta che produce sarà linguisticamente fluente e tonalmente sicura (perché ha imparato ad usare le parole, vedi le parole di Kharpathy) ma il contenuto sarà generato statisticamente, non recuperato da una fonte reale.
Questo è il meccanismo dell’allucinazione: non è un bug ma il comportamento atteso di un sistema che produce la continuazione statisticamente più plausibile anche in assenza di informazione reale.
La soluzione non è cercare un modello più preciso in assoluto ma progettare un’architettura corretta come prima accennato.
Due approcci consolidati che usano normalmente sono i seguenti:
- con il RAG: invece di chiedere al modello di ricordare si fornisce al modello l’informazione nel momento in cui ne ha bisogno. Il sistema recupera i documenti rilevanti da una knowledge base, li inserisce nel contesto della chiamata e il modello risponde basandosi esclusivamente su quel materiale;
- con il tool use: il modello viene equipaggiato con strumenti che può invocare durante la generazione: una chiamata API al gestionale, una query al database, una ricerca. Quando arriva una domanda sulla disponibilità a magazzino, il modello non ci “pensa”, chiama lo strumento, riceve la risposta reale e la incorpora. In entrambi i casi il modello fa quello che sa fare bene, ossia ragionare su testo fornito, strutturare una risposta, estrarre informazioni rilevanti senza essere costretto a inventare ciò che non sa.
Prompt senza architettura
Un prompt che funziona in un manuale non è un’integrazione, è solo un esperimento.
Portare quel prompt in produzione richiede di ragionare come per qualsiasi sistema software: validazione dell’input, parsing e validazione dell’output, gestione degli errori, logging, test. Senza una pipeline strutturata i risultati restano potenzialmente incoerenti e difficili da misurare.
Scegliere il modello sbagliato per il task
Non tutti i task richiedono i modelli più potenti e costosi. Per classificazione, estrazione strutturata su testo breve per esempio non serve prendere il miglior LLM in circolazione ma modelli eseguibili in locale che producono risultati comparabili ai top del momento con una frazione del costo.
Il vantaggio di questo approccio è triplo:
- costi più bassi
- privacy
- compliance GDPR
Tre implementazioni concrete e replicabili con un LLM
Caso d’uso 1: helpdesk automatico su knowledge base proprietaria
Cosa serve:
- un modello cloud piccolo e poco costoso es. Claude Haiku, GPT-40 mini
- un layer RAG costruito su un vector database (Qdrant o pgvector su Postgres esistente), integrazione nel canale di supporto già in uso.
Il risultato misurabile è la riduzione delle richieste che arrivano agli operatori umani per domande già risposte nella documentazione. Il ROI si calcola in ore/uomo risparmiate per ticket. Tempo realistico da zero a produzione: tre-quattro settimane con un team che conosce già l’infrastruttura.
Caso d’uso 2: pipeline di analisi contratti
Un ufficio legale interno o uno studio professionale riceve contratti da analizzare:
Cosa serve:
- estrarre clausole specifiche (penali, rinnovo automatico, limitazioni di responsabilità, foro competente), strutturarle in un JSON validato,
- produrre un report sintetico.
È un task in cui i modelli attuali sono affidabili se il prompt è ben costruito e l’output è validato contro uno schema. Il costo di inference per documento è nell’ordine di centesimi. Il risparmio di tempo per documento è nell’ordine di mezz’ora di lavoro qualificato.
Caso d’uso 3: classificazione e instradamento automatico di documenti in ingresso.
Un ufficio acquisti o qualsiasi funzione aziendale che riceve volumi elevati di documenti eterogenei (es. fatture, ordini ecc) può costruire una pipeline che classifica ogni documento in ingresso, estrae i campi rilevanti e lo instrada al processo corretto senza intervento umano.
Cosa serve:
- un modello LLM economico per la classificazione e l’estrazione (es. GPT-40 mini, Claude Haiku)
- un layer di validazione dell’output da confrontare con uno schema JSON
- integrazione con il gestionale o il sistema documentale esistente
Il costo di inference per documento è nell’ordine di centesimi.
Prima di qualsiasi investimento, tre domande
- Qual è il task specifico che si vuole affrontare con input e output definiti in modo preciso?
- L’output è verificabile in modo automatico o richiede revisione umana?
- Il valore generato giustifica il costo del modello, di integrazione e di manutenzione nel tempo?
Chi ha risposte chiare a queste tre domande ha già identificato un caso d’uso potenzialmente solido
Nel prossimo numero di ‘Inside the machine’ si illustrerà l’autograd, ossia il meccanismo usato nella rete neurale per imparare dagli errori, il concetto di gradiente, il modello base ed il modello instruct. (foto di Igor Omilaev su Unsplash
© RIPRODUZIONE RISERVATA
