Quando scrivi “auto” e “macchina”, per un computer sono due parole diverse. Per un modello con embedding, sono concetti vicini — perché hanno contesti simili in milioni di testi. L’embedding è la traduzione di parole, frasi o interi documenti in vettori numerici che rappresentano il loro significato.

È la tecnologia che permette all’AI di trovare documenti “pertinenti” anche se non contengono esattamente le parole che hai cercato. È alla base del RAG, della ricerca semantica, e di quasi tutto quello che fa sembrare l’AI davvero intelligente — non solo letterale.

Ogni volta che usi un’app basata su AI — un assistente aziendale, un chatbot sul sito di un’azienda, un tool di scrittura — c’è un testo che l’utente non vede e che il modello legge per primo. Si chiama system prompt. Definisce il tono, il ruolo, i limiti, le priorità del modello in quella specifica applicazione.

È la ragione per cui lo stesso modello sottostante può comportarsi in modo completamente diverso da un prodotto all’altro. ChatGPT, Claude e Gemini accettano system prompt: chi costruisce applicazioni su di loro li usa per “modellare” il carattere dell’AI prima che l’utente scriva qualsiasi cosa.

Se chiedi a un modello “quanto fa 127 × 48?” può sbagliare. Se gli chiedi di “ragionare passo dopo passo”, le probabilità di risposta corretta aumentano drasticamente. La chain of thought è esattamente questo: strutturare il prompt — o il comportamento del modello — in modo che produca ragionamento esplicito prima della risposta finale.

Non è magia: è che i modelli generano testo in sequenza, e produrre passaggi intermedi li “costringe” a non saltare a conclusioni affrettate. Molti modelli moderni lo fanno in automatico — il “pensiero” che vedi scorrere prima della risposta in alcuni tool è proprio chain of thought.

Zero-shot significa che descrivi il compito senza fornire esempi, e ti aspetti che il modello capisca. Few-shot significa che fornisci due o tre esempi di input/output prima di fare la tua richiesta vera. Many-shot è quando ne fornisci molti di più.

In pratica: se scrivi “classifica questo testo come positivo o negativo” stai usando zero-shot. Se prima mostri tre esempi di testi già classificati e poi presenti il tuo, stai usando few-shot. Quest’ultimo funziona meglio per compiti che richiedono un formato o un tono precisi — perché l’AI vede concretamente cosa vuoi, invece di interpretarlo.

Un modello senza guardrail risponde a qualsiasi richiesta — incluse quelle pericolose, illegali o semplicemente inappropriate per il contesto. I guardrail sono i meccanismi — tecnici ed etici — che limitano questi comportamenti: filtri sull’input, vincoli sull’output, istruzioni nel training, regole nel system prompt.

Esistono a più livelli: i guardrail del modello base (stabiliti da chi lo ha addestrato), quelli dell’applicazione (stabiliti da chi ci costruisce sopra) e quelli delle policy d’uso. Sono anche il terreno di scontro più acceso nel dibattito sull’AI: chi li vuole più stretti in nome della sicurezza, chi li vuole più larghi in nome della libertà d’uso.

Quando usi un modello AI noti due tempi distinti: quanto aspetti prima che inizi a scrivere (latenza) e quanto impiega a completare la risposta (velocità di generazione). Sono due variabili diverse, ottimizzate in modo diverso. Un modello può avere latenza bassa ma essere lento a completare risposte lunghe, o viceversa.

La latenza dipende da carico dei server, dimensione del modello, complessità della richiesta e distanza geografica dai data center. In applicazioni in tempo reale — assistenti vocali, tool di scrittura collaborativa — è il parametro critico. Per un riassunto da leggere dopo, conta meno.

È la differenza tra un assistente che sembra “istantaneo” e uno che ti fa aspettare abbastanza da interrompere il flusso di lavoro.

Immagina uno studente che memorizza le risposte esatte agli esercizi del libro senza capire i concetti. All’esame, se le domande cambiano anche poco, è perso. L’overfitting è l’equivalente AI: il modello ha “memorizzato” i dati di training invece di estrarne regole generali, e generalizza male su dati nuovi.

Non serve essere data scientist per incontrarlo: succede ogni volta che un sistema impara a memoria invece di capire davvero. È uno dei problemi fondamentali del machine learning, e si combatte con più dati, tecniche di regolarizzazione, e validazione su dati che il modello non ha mai visto. Nei modelli grandi è meno frequente — ma specie nei fine-tuning su dataset piccoli, è un rischio concreto.

Un database tradizionale cerca corrispondenze esatte: cerchi “contratto” e trova “contratto”. Un vector database cerca per similarità semantica: cerchi “accordo commerciale” e trova documenti che parlano di contratti, anche senza usare quella parola. Lo fa confrontando vettori numerici — gli embedding — invece di stringhe di testo.

È il motivo per cui puoi chiedere “cosa dicevamo del contratto con il cliente francese?” e l’AI trova il documento giusto anche senza parole identiche. È l’infrastruttura silenziosa sotto molti prodotti AI enterprise: quando un’azienda interroga i propri documenti in linguaggio naturale, c’è quasi sempre un vector database nel mezzo. Pinecone, Weaviate, Chroma sono tra i più usati.

I modelli standard generano la risposta direttamente dall’input. I reasoning model — come o1 di OpenAI o Claude con extended thinking — producono prima una catena di ragionamento interna, poi la risposta. Questo passaggio intermedio li rende significativamente più capaci su matematica, logica, codice complesso e analisi multi-step.

Il costo: sono più lenti e consumano molti più token. Il guadagno: su problemi dove la risposta “intuitiva” sarebbe sbagliata, ragionano abbastanza a lungo da correggere il tiro. Non sostituiscono i modelli veloci — li affiancano per i task che lo richiedono.

I grandi modelli imparano dalla scrittura umana — articoli, libri, forum, conversazioni. Ma internet si sta riempiendo di testi generati dall’AI stessa. Se i modelli futuri si addestrano su quei testi, assorbono anche gli errori, le semplificazioni e i bias dei modelli precedenti — amplificandoli di generazione in generazione.

Non serve seguire la ricerca tecnica per capirne l’impatto: è il motivo per cui le aziende AI pagano sempre di più per dati umani autentici e verificati. La diversità e l’autenticità dei dati di training non sono un dettaglio tecnico — sono il patrimonio su cui si costruisce la qualità del modello.