Large Language Model (LLM): cosa sono, come funzionano e a cosa servono

Un Large Language Model, abbreviato in LLM, è un modello di machine learning addestrato su grandi quantità di dati per elaborare sequenze di token e generare nuovi output in base al contesto ricevuto. Nei sistemi generativi più comuni, questo significa prevedere progressivamente quale token è plausibile che venga dopo quelli già presenti.

È il meccanismo alla base di molte funzioni che ormai usiamo per scrivere, sintetizzare documenti, tradurre, programmare, analizzare informazioni o conversare con un assistente AI. Ma qui c’è una distinzione importante: un LLM non coincide con ChatGPT, Claude, Gemini o con un agente AI. Il modello è uno dei componenti del sistema; il prodotto che utilizzi può aggiungere memoria, ricerca, file, strumenti, API, regole e altri livelli di orchestrazione.

Capire questa differenza aiuta anche a evitare molti equivoci sugli LLM: non sono database che recuperano semplicemente una risposta memorizzata, non imparano automaticamente da ogni conversazione e una risposta molto convincente non è necessariamente vera.

Vediamo quindi cosa significa davvero LLM, come un prompt diventa una risposta e perché oggi il modello linguistico va considerato come una parte di un sistema AI più ampio.

Cosa sono i Large Language Model (LLM)

Un Large Language Model è una rete neurale addestrata a modellare il linguaggio su larga scala. Il termine appartiene al campo del Natural Language Processing, anche se i modelli moderni hanno esteso le proprie capacità ben oltre la sola elaborazione del testo.

La parola language indica che il modello apprende regolarità presenti nelle sequenze linguistiche. Model significa che non conserva semplicemente una copia consultabile di tutto ciò che ha visto: durante l’addestramento modifica un grande insieme di parametri numerici per rappresentare pattern e relazioni utili a produrre nuove previsioni.

Il termine large, invece, non identifica una soglia universale. Non esiste un numero di parametri oltre il quale un modello diventa ufficialmente un LLM. La scala riguarda una combinazione di dimensione del modello, dati, capacità computazionale e complessità dell’addestramento.

Cosa significa LLM e perché questi modelli vengono definiti “large”

LLM è l’acronimo di Large Language Model, traducibile in italiano come modello linguistico di grandi dimensioni o grande modello linguistico.

La dimensione è importante perché aumentando opportunamente capacità del modello, dati e calcolo possono emergere competenze che modelli più piccoli gestiscono con maggiore difficoltà. Ma “più grande” non equivale automaticamente a “migliore”.

Un modello con molti più parametri può essere più costoso e lento senza offrire un vantaggio significativo sul compito concreto. Per questo il numero di parametri, da solo, è un criterio sempre meno utile per scegliere un modello.

Anche l’espressione “modello di linguaggio” può essere oggi un po’ stretta. Diverse famiglie contemporanee elaborano anche immagini, audio, video e documenti. Meta, per esempio, ha descritto Llama 4 come una famiglia nativamente multimodale basata anche su architettura Mixture-of-Experts. In casi simili, parlare esclusivamente di modello “linguistico” descrive bene l’origine tecnologica, ma non necessariamente l’intero perimetro delle capacità moderne. Meta descrive qui l’architettura multimodale di Llama 4.

LLM, foundation model, chatbot e sistema AI non sono la stessa cosa

Questa distinzione è una delle più utili per capire l’AI generativa attuale.

Livello	Che cos’è	Esempio di funzione
Modello	La rete neurale che elabora il contesto e genera output	Predire e generare token
Foundation model	Modello pre-addestrato generale adattabile a diversi compiti	Testo, codice, immagini o più modalità
Assistente/prodotto	Applicazione attraverso cui interagisci con uno o più modelli	Chat, file, ricerca, memoria
Tool	Funzione esterna che il sistema può invocare	Ricerca, database, API, calcolo
Agente	Sistema che orchestra modello, strumenti, stato e più passaggi	Completare autonomamente un workflow

Per esempio, GPT è una famiglia di modelli, mentre ChatGPT è un prodotto che utilizza modelli e altre funzionalità. Nel caso di Claude e Google Gemini, lo stesso nome viene utilizzato in contesti differenti per indicare famiglie di modelli e relativi prodotti.

Lo stesso principio vale per Kimi AI: Kimi è la piattaforma utilizzata dall’utente, mentre K3, K2.7 Code e K2.6 sono modelli con ruoli differenti.

Questa separazione diventa essenziale quando si parla di ricerca sul web, memoria o azioni automatiche. Non è detto che sia il modello, da solo, a possedere quelle capacità: spesso è l’applicazione a collegarlo agli strumenti necessari.

Come funziona un LLM, dal prompt alla risposta

Quando scrivi un prompt, il modello non prende la frase come un blocco indivisibile e non cerca nel proprio archivio la risposta più simile.

Il processo, semplificando, segue un’altra logica:

input → token → rappresentazioni numeriche → Transformer → probabilità sui token successivi → generazione

La documentazione didattica di Google sui Large Language Model descrive i Transformer come l’architettura alla base della maggior parte degli LLM moderni e distingue inoltre le diverse configurazioni encoder, decoder ed encoder-decoder.

Tokenizzazione ed embedding: come l’input viene rappresentato dal modello

La prima trasformazione riguarda i token.

Un token non è necessariamente una parola. A seconda del tokenizer utilizzato può rappresentare:

• una parola intera;
• una parte di parola;
• punteggiatura;
• caratteri o altre unità codificate.

Per questo una frase di dieci parole non corrisponde necessariamente a dieci token.

Ogni token viene associato inizialmente a una rappresentazione numerica, chiamata embedding. È un vettore: una serie di valori che permette alla rete neurale di lavorare matematicamente sull’input.

Dire semplicemente che “parole simili hanno coordinate vicine” aiuta a intuire il concetto, ma è incompleto. L’embedding iniziale è soltanto il punto di partenza. Attraversando i layer del Transformer, la rappresentazione del token viene modificata in funzione del contesto.

Prendi la parola “rete”:

• “rete neurale”;
• “rete da pesca”;
• “rete aziendale”.

Il token può essere identico, ma ciò che conta per il modello cambia in base alle parole che lo circondano.

Transformer e self-attention: come il modello usa il contesto

Il Transformer ha cambiato profondamente il modo in cui le reti neurali elaborano le sequenze.

Uno dei suoi meccanismi centrali è la self-attention, che permette al modello di calcolare quanto le diverse parti dell’input siano rilevanti l’una per l’altra durante l’elaborazione.

Non significa che il modello “presti attenzione” come una persona. Significa che calcola relazioni numeriche tra rappresentazioni dei token e usa questi valori per costruire rappresentazioni contestuali più informative.

Questo permette, per esempio, di interpretare meglio un pronome in relazione al nome a cui si riferisce oppure una parola ambigua in base al resto della frase.

Un’altra correzione importante rispetto a molte spiegazioni semplificate riguarda encoder e decoder. Non tutti i Transformer sono necessariamente encoder-decoder. Esistono modelli encoder-only, decoder-only e architetture che utilizzano entrambe le componenti. Molti LLM generativi sono principalmente autoregressivi e decoder-based.

Il modello deve inoltre rappresentare l’ordine dei token. Le implementazioni moderne possono farlo con tecniche diverse di informazione posizionale: non è corretto assumere che ogni LLM utilizzi esattamente lo stesso schema.

Predizione dei token e inference: come viene generata una risposta

Quando un LLM generativo produce testo, calcola una distribuzione di probabilità sui possibili token successivi.

Se l’input fosse:

La capitale d’Italia è…

il modello assegna probabilità differenti ai token candidati. Il sistema di decoding seleziona un token, lo aggiunge alla sequenza e ripete il calcolo per quello successivo.

La risposta viene quindi costruita passo dopo passo, non recuperata come un paragrafo già pronto.

Questa fase di utilizzo di un modello addestrato viene chiamata inference.

Proprio perché la generazione passa attraverso una distribuzione di probabilità sui token, alcuni sistemi possono incorporare un watermark statistico nei testi AI intervenendo in modo controllato sulle scelte tra alternative plausibili. Il segnale non richiede quindi una scritta nascosta nel documento: può emergere dalla distribuzione delle scelte effettuate durante la generazione.

Parametri e strategie di decoding possono modificare il comportamento della generazione. Un output più deterministico privilegia maggiormente le alternative ad alta probabilità; configurazioni più esplorative possono aumentare varietà e imprevedibilità.

Questo spiega anche una parte del fenomeno che chiamiamo “ragionamento”. Un LLM può produrre passaggi intermedi, decomporre un problema e mantenere relazioni complesse nel contesto, ma non è corretto trasformare automaticamente queste capacità nella prova che ragioni nello stesso modo di un essere umano.

Come viene addestrato e adattato un Large Language Model

Il comportamento che osservi durante una chat è il risultato di processi avvenuti prima dell’interazione.

La fase fondamentale è il pre-training, durante il quale il modello ottimizza i propri parametri utilizzando grandi quantità di dati.

Successivamente possono esistere fasi di post-training progettate per rendere il modello più utile, controllabile o adatto a determinati compiti.

La parola importante è possono: il fine-tuning non è una seconda fase universalmente obbligatoria per definire qualcosa come LLM.

Pre-training: cosa apprende davvero il modello

Nel pre-training il sistema affronta enormi quantità di esempi e modifica progressivamente i pesi della rete per ridurre l’errore rispetto al proprio obiettivo di apprendimento.

Per molti modelli generativi autoregressivi l’obiettivo è legato alla predizione del token successivo sulla base dei token precedenti.

Il masked language modeling, in cui alcune parti dell’input vengono nascoste e il modello deve ricostruirle, è invece associato storicamente soprattutto a modelli encoder come BERT. Presentarlo come il meccanismo universale di addestramento di tutti gli LLM generativi sarebbe quindi fuorviante.

Attraverso il training, il modello incorpora nei parametri regolarità linguistiche e statistiche che possono rappresentare anche relazioni tra concetti, strutture, formati, codice e conoscenze incontrate nei dati.

Ma c’è un limite decisivo: ottimizzare la previsione linguistica non equivale a costruire un database verificato di fatti.

Il modello può apprendere una relazione frequente anche quando i dati di origine sono incompleti, contraddittori, datati o falsi.

Instruction tuning, fine-tuning e preference optimization

Dopo il pre-training, un modello di base può essere ulteriormente adattato.

L’instruction tuning utilizza esempi costruiti per insegnare al modello a seguire meglio istruzioni e richieste. La documentazione Google lo descrive esplicitamente come un ulteriore passaggio possibile, non come una condizione necessaria per l’esistenza dell’LLM.

Il fine-tuning può invece modificare i pesi del modello usando dati più mirati per adattarne comportamento o capacità a uno specifico dominio o task.

Esistono inoltre tecniche di preference optimization, utilizzate nel post-training per orientare meglio il comportamento del modello rispetto a preferenze umane, obiettivi o policy.

Sono livelli differenti. Raggrupparli tutti sotto “fine-tuning” fa perdere una distinzione operativa importante.

Perché il fine-tuning non è l’unico modo per adattare un LLM

Se un’azienda vuole far lavorare un modello sulla propria documentazione, non deve necessariamente riaddestrarlo.

Può intervenire su livelli differenti:

1. definire meglio prompt e istruzioni;
2. inserire informazioni pertinenti direttamente nel contesto;
3. recuperare dati da fonti esterne tramite RAG;
4. collegare strumenti e API;
5. utilizzare memoria applicativa;
6. effettuare fine-tuning quando modificare i pesi offre un vantaggio reale.

La scelta dipende dal problema.

Se devi permettere a un assistente di rispondere usando un manuale che cambia ogni settimana, addestrare nuovamente il modello ogni volta sarebbe spesso poco pratico. Recuperare i passaggi aggiornati quando arriva la domanda può essere una soluzione molto più adatta.

Perché un sistema AI moderno fa più del solo LLM

Molte delle capacità che oggi attribuiamo agli LLM dipendono in realtà dalla combinazione tra modello e infrastruttura esterna.

È qui che entrano RAG, function calling, strumenti, memoria e agenti.

Il modello resta centrale, ma non lavora necessariamente da solo.

RAG: collegare il modello a informazioni esterne

RAG significa Retrieval-Augmented Generation.

Il principio è semplice: prima di chiedere al modello di rispondere, il sistema cerca informazioni rilevanti in una fonte esterna e inserisce nel contesto i passaggi recuperati.

Nel lavoro originale sulla Retrieval-Augmented Generation, il modello generativo viene combinato con una memoria non parametrica recuperabile, separando quindi parte della conoscenza dalla sola informazione incorporata nei pesi.

In un’applicazione aziendale il flusso potrebbe essere:

domanda → ricerca nella knowledge base → documenti rilevanti → contesto dell’LLM → risposta

Questo offre un vantaggio pratico: aggiornare i documenti non richiede necessariamente modificare i pesi del modello.

RAG, però, non garantisce automaticamente una risposta vera. Se il retriever trova documenti sbagliati, se le fonti sono inaffidabili o se il modello interpreta male il materiale recuperato, l’errore resta possibile.

Tool use e function calling: dal testo alle azioni

Un modello può anche essere collegato a funzioni esterne.

Il function calling permette al sistema di mettere a disposizione una serie di strumenti con parametri definiti. Il modello può determinare quale funzione utilizzare e produrre una richiesta strutturata; sarà poi l’applicazione a eseguire realmente l’azione e restituirgli il risultato.

La documentazione Gemini sul function calling lo descrive precisamente come il collegamento tra il modello e strumenti o API esterne.

Per esempio:

“Qual è lo stato del mio ordine?”

Il modello, da solo, non conosce necessariamente l’ordine. Il sistema può invece:

1. identificare l’intento;
2. chiamare un’API dell’ecommerce;
3. ricevere lo stato dell’ordine;
4. inserire il risultato nel contesto;
5. formulare una risposta comprensibile.

Lo stesso principio può essere applicato a database, CRM, calendari, motori di ricerca, sistemi di pagamento o applicazioni aziendali.

Multimodalità, contesti lunghi e workflow agentici

Tre evoluzioni rendono ancora più evidente il confine tra “LLM” e “sistema AI”.

Multimodalità. Alcuni modelli lavorano ormai su testo, immagini, audio, video o documenti. Non tutti gli LLM sono multimodali e non ogni modello multimodale è descritto correttamente come semplice modello linguistico.

Context window. Il modello può elaborare una quantità limitata di token per ogni interazione o workflow. Una finestra di contesto più ampia permette di fornire più materiale, ma non equivale a memoria permanente e non significa che il modello abbia imparato quei dati nei propri pesi.

Workflow agentici. Un agente combina normalmente un modello con strumenti, stato e un ciclo di esecuzione. La documentazione Anthropic definisce un agente come un’applicazione capace di completare un task pianificando passaggi e utilizzando strumenti.

Protocolli come il Model Context Protocol possono poi standardizzare il modo in cui applicazioni AI accedono a strumenti e risorse.

Il punto da ricordare è questo:

LLM ≠ agente.

L’LLM può essere il motore decisionale o linguistico dell’agente, ma l’autonomia deriva dall’intero sistema che gli consente di osservare risultati, scegliere azioni e proseguire il workflow.

Cosa può fare un LLM: applicazioni ed esempi

Una delle ragioni per cui i Large Language Model sono così versatili è che molti compiti digitali possono essere rappresentati come trasformazioni di sequenze.

Un modello generalista può essere utilizzato per:

• generare e riscrivere testi;
• sintetizzare documenti;
• tradurre;
• estrarre informazioni;
• classificare contenuti;
• rispondere a domande;
• generare o analizzare codice;
• trasformare informazioni in formati strutturati;
• confrontare testi o documenti;
• supportare interfacce conversazionali.

Non significa che svolga tutti questi compiti con la stessa affidabilità.

Un modello molto valido nella programmazione può non essere la scelta migliore per estrarre dati con latenza minima; uno più piccolo può essere sufficiente per classificare ticket; un sistema con retrieval può superare un modello più grande quando servono informazioni aziendali aggiornate.

Scrittura, sintesi, traduzione, analisi e codice

La generazione di testo è l’applicazione più evidente, ma spesso le funzioni a maggior valore operativo sono quelle meno spettacolari.

Per esempio, un LLM può trasformare:

• una conversazione lunga in un riepilogo;
• un documento in una serie di campi strutturati;
• una richiesta dell’utente in parametri per un’API;
• una descrizione funzionale in una prima bozza di codice;
• informazioni disordinate in una classificazione coerente.

La qualità dipende però dal contesto, dal modello, dalle istruzioni e dai controlli che circondano la generazione.

Per questo in un processo reale conviene giudicare l’intero workflow invece della risposta più impressionante ottenuta in una demo.

GPT, Claude, Gemini e Llama sono esempi, non sinonimi di LLM

Nella pratica i nomi più conosciuti possono creare confusione.

GPT, Claude, Gemini e Llama indicano famiglie o ecosistemi sviluppati rispettivamente da OpenAI, Anthropic, Google e Meta, ma hanno modelli di distribuzione e prodotti differenti.

Non esiste quindi “il comportamento degli LLM” come se tutti i modelli fossero equivalenti.

Cambiano:

• architettura;
• capacità;
• dati e post-training;
• modalità supportate;
• context window;
• strumenti;
• costi;
• latenza;
• licenza;
• possibilità di deployment;
• policy e condizioni d’uso.

Quando confronti due sistemi AI, assicurati inoltre di sapere se stai confrontando i modelli o i prodotti che li contengono.

Dove sbagliano gli LLM e perché non “sanno” tutto

La fluidità del linguaggio è una delle qualità più utili degli LLM, ma è anche una delle fonti principali di fraintendimento.

Una risposta ben scritta può dare un’impressione di certezza molto maggiore di quella giustificata dai dati.

Il modello è ottimizzato per produrre sequenze coerenti rispetto al contesto. La verità fattuale è un requisito differente.

Allucinazioni e risposte plausibili ma false

Una AI hallucination si verifica quando un sistema genera informazioni prive di adeguato fondamento, anche se l’output appare plausibile.

Può inventare:

• nomi;
• date;
• riferimenti;
• funzioni software;
• fonti;
• dettagli tecnici;
• relazioni tra fatti.

Il fenomeno non significa semplicemente che il software “si è rotto”. È collegato alla natura probabilistica della generazione e al fatto che plausibilità linguistica e correttezza fattuale non coincidono.

Abbiamo approfondito cause e strategie di mitigazione nella guida dedicata alle AI hallucination.

Retrieval, ricerca, tool e verifiche esterne possono ridurre il problema in determinati workflow, ma non lo eliminano per definizione.

Bias, dati, contesto e conoscenza

Le prestazioni di un modello dipendono anche dai dati e dalle procedure utilizzate per addestrarlo e valutarlo.

Bias, lacune, contenuti datati o rappresentazioni sbilanciate possono influenzare gli output.

Esiste poi un altro errore frequente: confondere tre cose differenti.

Conoscenza parametrica: ciò che il training ha codificato nei pesi.

Contesto: ciò che viene fornito al modello durante la richiesta.

Memoria applicativa: informazioni che il prodotto conserva esternamente e può reinserire nelle interazioni successive.

Quando racconti oggi al modello un’informazione nuova, normalmente non stai modificando automaticamente i suoi parametri. Stai fornendo nuovi token nel contesto oppure usando una funzione di memoria gestita dall’applicazione.

Questa distinzione spiega perché una conversazione possa sembrare adattiva senza che il modello stia effettuando un nuovo training dopo ogni messaggio.

Privacy, prompt injection e rischi dei sistemi basati su LLM

La sicurezza diventa più complessa quando il modello può leggere dati esterni o utilizzare strumenti.

La prompt injection, per esempio, può tentare di alterare il comportamento del sistema attraverso istruzioni malevole contenute direttamente nel prompt oppure in contenuti che il sistema recupera.

Altri rischi riguardano informazioni sensibili, supply chain, output non controllati e livello eccessivo di autonomia concesso agli agenti. L’iniziativa OWASP Top 10 for LLM and GenAI mantiene una tassonomia aggiornata dei principali rischi delle applicazioni basate su LLM, GenAI e sistemi agentici.

Il punto operativo è che la sicurezza non appartiene solo al modello.

Se un LLM può chiamare un sistema di pagamento, leggere documenti riservati o modificare un database, autorizzazioni, isolamento, validazione degli input e degli output e principio del minimo privilegio diventano parte dell’architettura.

LLM vs SLM: quando un modello più piccolo può essere la scelta migliore

Un Small Language Model (SLM) segue principi simili a quelli di un LLM ma punta a una scala e a requisiti computazionali inferiori.

Anche qui non esiste una soglia universale che separi formalmente “small” e “large”.

La differenza interessante è operativa.

Criterio	LLM più grande	SLM / modello più piccolo
Compiti generalisti complessi	Spesso avvantaggiato	Più variabile
Requisiti hardware	Generalmente maggiori	Generalmente inferiori
Latenza	Può essere maggiore	Può essere inferiore
Costo di inferenza	Tendenzialmente maggiore	Può essere più contenuto
Edge/on-device	Più difficile	Più adatto in molti scenari
Specializzazione	Molto versatile	Può funzionare molto bene su task circoscritti
Privacy	Dipende dal deployment	Può facilitare deployment locale
Efficienza	Dipende da modello e workload	Potenzialmente superiore su task mirati

Un modello piccolo non è automaticamente più privato o più sicuro: dipende da dove e come viene eseguito.

Allo stesso modo, un modello grande non è automaticamente la scelta migliore per un’applicazione aziendale.

Se devi classificare migliaia di ticket in dieci categorie note, un modello più piccolo e controllabile potrebbe offrire un rapporto costo/prestazioni migliore.

Se invece il task richiede analisi complessa di documenti eterogenei, uso flessibile di strumenti e forte generalizzazione, una famiglia più capace può avere senso.

La domanda corretta non è quindi “qual è il modello più potente?”, ma:

qual è il modello più piccolo che riesce a soddisfare in modo affidabile i requisiti del mio task?

Come valutare un LLM senza guardare soltanto il numero di parametri

Confrontare Large Language Model sulla sola dimensione è poco utile.

Un framework di valutazione deve partire dal lavoro reale che il sistema dovrà svolgere.

Anche iniziative come HELM di Stanford adottano una valutazione multidimensionale dei foundation model invece di ridurre il confronto a una singola metrica.

Qualità e affidabilità sul task reale

La prima domanda è semplice:

il modello riesce a svolgere bene il compito per cui vuoi utilizzarlo?

Un benchmark generale può aiutare a orientarsi, ma non sostituisce una valutazione costruita sui tuoi casi reali.

Per un sistema di customer care potresti misurare:

• correttezza della classificazione;
• rispetto delle policy;
• frequenza delle escalation;
• qualità delle risposte;
• stabilità su richieste ambigue.

Per un workflow di estrazione dati, invece, conteranno di più:

• precisione dei campi estratti;
• rispetto dello schema;
• comportamento quando un dato manca;
• ripetibilità.

Il benchmark giusto dipende dal task.

Costo, latenza, context window e deployment

Una risposta leggermente migliore può essere una cattiva scelta se costa dieci volte di più o arriva troppo lentamente per l’applicazione.

Conviene quindi misurare almeno:

Costo per task. Non solo prezzo per token, ma spesa necessaria per completare effettivamente il lavoro.

Latenza. Quanto tempo passa prima di ottenere l’output utile.

Throughput. Quante richieste il sistema riesce a sostenere.

Context window. Quanto materiale può essere elaborato nella singola interazione.

Requisiti di deployment. Cloud del vendor, API esterna, infrastruttura propria, edge o dispositivo.

Sono elementi che possono cambiare completamente il verdetto tra due modelli teoricamente simili.

Tool, multimodalità, privacy, licenza e disponibilità

Per i sistemi moderni la valutazione deve andare oltre la sola generazione testuale.

Chiediti:

• supporta gli strumenti necessari?
• restituisce output strutturati affidabili?
• può lavorare sulle modalità di input che ti servono?
• il modello può essere eseguito nell’ambiente richiesto?
• quali condizioni di licenza si applicano?
• come vengono trattati dati e log?
• il modello o la feature sono realmente disponibili per il tuo account, piano e Paese?
• l’architettura permette di applicare i controlli di sicurezza necessari?

Questi criteri spiegano perché non esiste un “miglior LLM” universale.

La scelta corretta emerge dall’intersezione tra qualità, affidabilità, costo, velocità, integrazione e vincoli del progetto.

Conclusione

Un Large Language Model è più semplice da capire quando smettiamo di descriverlo come una “mente artificiale” e lo osserviamo per ciò che fa realmente: elabora rappresentazioni numeriche di sequenze, usa un’architettura neurale come il Transformer e genera nuovi token sulla base del contesto e di ciò che ha appreso durante l’addestramento.

Da questa base possono emergere capacità molto sofisticate. Ma il modello non coincide con l’intero sistema AI.

RAG può portargli informazioni esterne. I tool possono permettergli di interrogare API ed eseguire azioni. Una memoria applicativa può conservare dati tra sessioni. Un agent loop può trasformare una singola risposta in un workflow composto da più passaggi.

Questa è probabilmente la distinzione più utile da portarsi via:

modello, conoscenza esterna, strumenti e orchestrazione sono livelli differenti.

Capirli separatamente permette di valutare meglio anche limiti e opportunità. Un output fluido non garantisce la verità, una context window ampia non equivale a memoria permanente e un modello più grande non è necessariamente la soluzione migliore.

Se devi scegliere un LLM per un progetto, parti quindi dal task reale: che cosa deve fare, con quale affidabilità, a quale costo, con quali dati e con quali strumenti?

La risposta a queste domande vale molto più del numero di parametri scritto nella scheda tecnica.