I modelli LLM consentono di risolvere alcuni problemi storici dell’incontro tra la domanda e l’offerta di lavoro. Tra questi c’è sicuramente l’orientamento. Come fanno gli orientatori dei centri per l’impiego (CPI), attraverso poche domande, a individuare le professioni più adatte a chi è in cerca di lavoro? E, ancora, come possono orientarsi gli studenti, senza rispondere ai lunghi quesiti dei test di Holland e BigFive, usando il linguaggio naturale. Il mio chatbot fa questo, ma lo fa utilizzando gli strumenti scientifici della statistica ufficiale abbinati all’intelligenzaartificiale. Si tratta di un vero e proprio cambio di paradigma che non credo sia stato ancora compreso a fondo dagli addetti ai lavori: tra non molto, la statistica ufficiale, la scuola, l’università e il mercatodellavoro saranno rivoluzionati. Prova adesso il mio chatbot!
Mese: Settembre 2025
Come “ragiona” l’intelligenza artificiale? Usa la geometria euclidea, ma in pochi lo sanno.

Questo articolo nasce da una duplice esigenza. La prima riguarda la necessità di costruire un agent che non sia “fuffa da convegni”, ma che serva realmente a migliorare la codifica nelle indagini statistiche e I servizi offerti ai cittadini. La domanda a cui deve rispondere questo agent è semplice semplice: cosa accade se un utente scrive “Voglio aprire un’azienda che costruisce pinocchi di legno” e il database in cui è contenuta l’ATECO non contiene la concatenazione delle parole costruzione pinocchio e legno? Semplice, non vengono mostrate risposte, anche se la domanda è pertinente. Discorso analogo vale per le professioni: cosa accade se un utente “cerca fantasmi” e vuole sapere che professione svolge? In altre parole, il mio agent deve essere abbastanza intelligente da fornirmi dei risultati coerenti a prescindere dal linguaggio adottato nelle tassonomie (è evidente che nella classificazione Ateco non esistono i pinocchi di legno e nella Classificazione delle Professioni non esistono i cercatori di fantasmi), risolvendo il problema storico dei falsi risultati negativi e dei falsi risultati positivi. La seconda esigenza riguarda un bisogno personale: fare chiarezza su come funzionino alcuni meccanismi dell’IA, evidenziando che, dietro all’apparente magia, e al pressapochismo di molti pseudoguru improvvisati, c’è bisogno di una solida base scientifica per parlare con consapevolezza di intelligenza artificiale. Insomma, definire intelligente qualcosa che non si conosce è francamente abbastanza stupido.
SPOILER: Per chi avesse poco tempo, o non avesse voglia di leggere, il risultato di questo lavoro, reso possibile grazie all’infrastruttura e ai sistemisti messi a disposizione da INAPP e da IDEA POSITIVO, è disponibile qui:
http://51.75.143.81/assistenteai/
Premetto che in questo documento farò riferimento a PHP e Mysql, ma i concetti sono generalizzabili a qualsiasi linguaggio/database. Perché PHP? Perché è ancora utilizzato nella maggior parte delle applicazioni web. Perché Mysql? Per rendersi conto dei limiti notevoli con l’estensione vettoriale e sostituirlo necessariamente con Postgres. La realizzazione del frontend e del chatbot richiede un po’ di pratica con Nodejs, React e Javascript, ma non è sulle questioni legate allo sviluppo che voglio soffermarmi, piuttosto su quello che molti ritengono “magia”, ovvero le risposte sensate a una certa domanda formulata in linguaggio naturale.
Sfatiamo il primo mito: a dispetto di quanto si pensi, la magia dei modelli linguistici LLM non ha molto in comune con il linguaggio naturale. Le parole, per essere “comprese”, vengono trasformate in qualcosa di matematicamente utilizzabile, ovvero in vettori.
Il vettore, chi ha frequentato il primo anno di una facoltà scientifica lo sa bene, oltre a essere un costrutto alla base della geometria euclidea, in fisica viene usato praticamente ovunque: per rappresentare lo spazio in cui viviamo, per costruire spazi al di fuori dell’esperienza sensibile (il famoso spazio di Hilbert, per esempio), per descrivere i fenomeni quantistici o per spiegare le leggi della fluidodinamica. Se un aereo, sotto certe condizioni, riesce a decollare e ad atterrare senza schiantarsi, è anche merito dei vettori…
Le teorie e le tecniche di calcolo che riguardano i vettori sono molto ampie (si va dalle matrici al calcolo degli autovalori e degli autovettori, dall’ortogonalità alla distanza, dalla notazione di DIrac agli array) e non possono essere esaurite in questo breve articolo. Tuttavia, è possibile chiarire, senza troppi tecnicismi, il motivo per il quale gli spazi vettoriali, quando si tratta di modelli LLM e NLP, sono preferibili agli “spazi semantici”. Il campo di conoscenze a cui faremo riferimento prende il nome di VSM (Vector Spatial model) ovvero l’insieme delle tecniche che utilizzano un modello geometrico-matematico formale per rappresentare e gestire un insieme di informazioni scritte in linguaggio naturale.
In un modello VSM i documenti, intesi come insiemi di parole scritte in linguaggio naturale, e le query sono trattati come vettori di uno spazio n-dimensionale, in cui le parole rappresentano gli assi orto-normalizzati del sistema di riferimento e le query e i documenti costituiscono i vettori. Attraverso questa schematizzazione è possibile identificare dei documenti rilevanti per la query che possono anche non contenere i termini presenti nella richiesta formulata dagli utenti. La vettorializzazione consente di superare le rigidità dell’SQL, e delle ricerche attraverso le clausole LIKE o MATCH AGAINST, fornendo risultati accurati anche quando, per semplificare al massimo il concetto, l’utente non “parla” lo stesso linguaggio dei database ed effettua delle ricerche utilizzando termini diversi da quelli contenuti nei documenti.
Com’è possibile questa “magia”? È possibile attraverso l’utilizzo del prodotto scalare, ovvero misurando i coseni degli angoli formati tra i vettori, che rappresenta il punteggio di rilevanza dei documenti. Se il coseno è pari a 0, il vettore della query e quello del documento sono ortogonali, ovvero il documento non ha nessuna corrispondenza con la query. Il modello VSM è tutt’altro che moderno (risale al 1975) ed esprime un concetto straordinario: è possibile derivare matematicamente il significato di un documento, partendo dalle parole che lo costituiscono.
La figura sottostante mostra il caso pratico di una ricerca all’interno della classificazione ATECO 2025 (Produco pinocchi in legno)

Ovviamente, non si tratta di un modello perfetto, perché ha dei limiti semantici e strutturali. Ad esempio, il prodotto scalare tra vettori che rappresentano documenti molto lunghi assume valori molto piccoli, inadeguati a una misura corretta. Ci sono poi problemi associati alla polisemia e alla sinonimia che ripropongono, seppur sotto un’altra forma, i problemi relativi ai falsi risultati positivi e ai falsi risultati negativi. Per questo, i sistemi più evoluti, utilizzano un modello diverso (IR o Latent Semantic Indexes) che prevede la decomposizione in valori singolari, per ridurre la dimensionalità dello spazio parole-documenti e risolvendo, almeno in parte, i problemi di polisemia e sinonimia.
Non ci addentreremo nei dettagli dei diversi modelli, ma vedremo un approccio pratico per realizzare un’API con PHP, PostgreSQL e un sistema di embedding vettoriale.
OpenAI o Deepseek? FastText!
Esistono diverse soluzioni per gestire l’embedding vettoriale (OpenAi fornisce, a pagamento, I modelli text-embedding-3-large e text-embedding-3-small), ma chi non gradisca l’idea di utilizzare prodotti chiusi e onerosi può scegliere FastText, un modello open source che, seppur sviluppato da Facebook AI Research, garantisce gli standard dei prodotti open.
In tre punti, cosa fa FastText?
1. Gestisce parole rare e varianti linguistiche grazie ai subword embedding.
2. Produce vettori coerenti e di qualità, che catturano sia il significato lessicale che quello concettuale.
3. È leggero e veloce, ideale per essere integrato in applicazioni locali o server PHP senza dipendere da servizi cloud costosi.
Di seguito riporto il confronto fatto da ChatGPT tra I diversi modelli: mi è sembrato abbastanza coerente con le mie considerazioni.

Come costruire un’API “intelligente”
1. Pulizia della querystring
La stringa digitata dagli utenti spesso contiene parole poco utili (stopword) a “definire il senso di una frase”. Per migliorare I risultati, si può scrivere una funzioncina di questo tipo, che utilizzi un’espressione regolare per estrarre le parole di troppo o la punteggiatura.
function qClean(string $q): string {
$stopwords = ['a','ad','al','allo','ai','agli','con','da','di','il','lo','la','e','o'];
$q = mb_strtolower($q, 'UTF-8');
$q = preg_replace('/[^\p{L}\p{N}\s]/u', ' ', $q);
$pattern = '/\b(' . implode('|', $stopwords) . ')\b/u';
$q = preg_replace($pattern, '', $q);
$q = preg_replace('/\s+/u', ' ', $q);
return trim($q);
}
2. EMBEDDING
Il modello di embedding non fa altro che ricevere come input la querystring digitata dall’utente e restituire come output un vettore in formato json.
$q = "sviluppatore frontend"; // query utente
$cleanQ = qClean($q);
$apiUrl = "/link/embed/model";
$queryString = http_build_query(["sentence" => $cleanQ]);
$response = file_get_contents($apiUrl . "?" . $queryString);
$json = json_decode($response, true);
$embedding = $json["vector"] ?? [];
3. Confronto con il database
A questo punto, abbiamo abbandonato completamente lo spazio semantico a favore di uno spazio vettoriale n-dimensionale. In base al tipo di embed, la dimensione dello spazio vettoriale può variare da 300 per FastText a 3072 per text-embedding-3-large. È evidente che la base dati in cui effettuare le ricerche deve essere trasformata in uno spazio vettoriale. A questo punto, si può usare pgvector e scrivere una procedura che faccia tutte quelle operazioni che ai tempi dell’università si facevano a mano.
function toVectorLiteral(array $emb): string {
return '[' . implode(',', array_map(fn($v)=>rtrim(rtrim(sprintf('%.8F',$v),'0'),'.'), $emb)) . ']';
}
$vecLit = toVectorLiteral($embedding);
$stmt = $db->prepare("
SELECT codice, nome,
1 - (embedding <=> :emb) AS similarity
FROM professioni.livelli
WHERE array_length(string_to_array(codice, '.'), 1) = 5
ORDER BY embedding <=> :emb
LIMIT 10
");
$stmt->execute([':emb' => $vecLit]);
$results = $stmt->fetchAll();
4. Output JSON
Se siamo stati bravi, la procedura sarà estremamente precisa e fornirà dei risultati che all’apparenza sembrano semanticamente simili ma in realtà sono vettorialmente vicini.
[{"codice":"01.02.03.04.05","nome":"Sviluppatore Frontend","similarity":0.97}, {"codice":"01.02.03.04.06","nome":"Programmatore Interfaccia Utente","similarity":0.94},
{"codice":"01.02.03.05.01","nome":"Web Designer","similarity":0.89}]
5. Gestione del frontend
Lo rimandiamo al prossimo articolo.
Insomma, non dico sia banale, perché servono delle conoscenze approfondite su diverse tematiche, ma la creazione di agenti AI basati su dati e metadati strutturati, che non restituiscano risultati farlocchi (come spesso accade con ChatGPT), è tutt’altro che impossibile. Basta tener presente che un modello LLM non è qualcosa nato dalla bacchetta magica di Harry Potter, ma dalla mente geniale di un matematico, Euclide, vissuto nel III secolo a.c., e dalle intuizioni di Gerard Salton (1975) e


