LLM parameters: cosa cambia tra pesi e impostazioni

L'espressione «LLM parameters» indica due decisioni diverse: quale modello usare e come richiederne l'output. Un modello linguistico di grandi dimensioni (LLM) da 70B ha circa 70 miliardi di parametri appresi; impostare la temperatura a 0.2 cambia il modo in cui un'API compatibile campiona la risposta, senza modificare il numero di pesi del modello. Prima si sceglie il modello adatto al compito, poi si configurano soltanto i controlli supportati dalla specifica API e dalla versione in uso.

Verificato sulla documentazione ufficiale aggiornata dei fornitori il 25 ottobre 2026. Questa distinzione conta più di un tempo: alcune API attuali rifiutano i controlli di campionamento, altre li accettano ma li ignorano. Copiare una configurazione predefinita può quindi causare un errore oppure non avere alcun effetto.

LLM parameters: due significati, due decisioni

I parametri del modello appartengono al modello addestrato. I parametri di generazione appartengono alla richiesta che gli viene inviata. Modificare i secondi non riaddestra i primi.

Pensiamo a un edificio. La struttura portante determina ciò che può sostenere; i frangisole regolabili cambiano il modo in cui si usa lo spazio. Ruotare un frangisole non aggiunge un piano. Allo stesso modo, cambiare la temperatura non trasforma un modello piccolo in uno più grande.

Che cosa sono i parametri di un LLM?

Quando si parla delle dimensioni di un modello, i parametri sono valori numerici appresi, principalmente pesi, che ne determinano i calcoli. L'addestramento modifica questi valori sulla base dei dati. Nel contesto delle API, però, la parola «parametri» indica anche le impostazioni che influenzano la generazione dell'output. La spiegazione di IBM distingue i valori appresi dalla configurazione esterna.

Un fornitore che dichiara «il nostro modello ha più parametri» sta parlando del modello. Uno sviluppatore che propone di «cambiare i parametri per estrarre i dati dalle fatture» probabilmente si riferisce alle impostazioni della richiesta. Prima di interpretare una delle due affermazioni come un'indicazione sulle prestazioni, bisogna chiarire a quale significato si riferisce.

Che cos'è un singolo parametro di un LLM?

Un parametro appreso è un numero usato all'interno della rete: per esempio, un peso che modifica quanto un segnale interno contribuisce a un altro. Non è un fatto etichettato con precisione, un documento o una parola conservata in un cassetto dedicato.

Esiste poi una categoria distinta: gli iperparametri di addestramento, impostazioni come il tasso di apprendimento che regolano il processo di addestramento. Un'applicazione aziendale che interroga un modello esistente normalmente non controlla né queste impostazioni né i pesi appresi.

I token sono un'altra cosa ancora. Sono le unità in cui vengono suddivisi input e output, spesso frammenti di parole. Aggiungere token a un prompt non aumenta i parametri del modello. La guida ai token nell'IA spiega questa unità; la guida al system prompt mostra come le istruzioni orientino il comportamento senza modificare i pesi appresi.

Prima parte: i parametri del modello ne indicano la scala

Il numero di parametri aiuta a stimare lo spazio di archiviazione e il carico di calcolo, ma non basta a scegliere il modello migliore per un'attività aziendale. È un punto di partenza per pianificare l'infrastruttura. La scelta va completata con una valutazione sul compito specifico.

Che cosa significano i miliardi di parametri di un LLM?

La «B» sta per billion, cioè miliardo di valori appresi. Un modello indicato come 70B ha circa 70 miliardi di parametri; la «T» sta per trillion, cioè mille miliardi. I nomi pubblicati possono essere arrotondati: per una stima precisa dei requisiti di esecuzione servono il checkpoint effettivo e il suo formato di archiviazione.

Due modelli con lo stesso numero di parametri possono differire per architettura, dati e metodi di addestramento, oltre che per specializzazione. Anche lo stesso modello può occupare quantità di memoria molto diverse a seconda della precisione con cui viene memorizzato ciascun peso.

Per chi acquista un servizio in azienda, la domanda utile è se il modello rispetti i criteri di accettazione: estrae il totale corretto della fattura, conserva l'identificativo del cliente, produce una patch che supera i controlli richiesti? Un numero più grande non risponde a queste domande.

Quanta memoria occupano i pesi di un modello da 70B?

Lo spazio occupato dai soli pesi si calcola moltiplicando il numero di parametri per i byte necessari a ciascuno. La tabella usa un modello ipotetico con esattamente 70 miliardi di pesi: sono calcoli, non misurazioni di un sistema in esecuzione.

Si tratta di gigabyte decimali. Il valore di 140 GB corrisponde a circa 130.4 GiB, l'unità binaria mostrata da alcuni strumenti di monitoraggio della memoria. La conversione cambia l'unità di misura, non il modello.

Hugging Face documenta come la quantizzazione, che memorizza i pesi con una precisione inferiore, ne riduca il fabbisogno di memoria cercando di preservare l'accuratezza. La nostra guida alla quantizzazione degli LLM approfondisce formati e compromessi.

Anche prompt più lunghi e richieste simultanee modificano il carico del sistema che serve il modello. La documentazione dello strumento di stima della memoria di Hugging Face distingue esplicitamente il caricamento del modello dall'inferenza, cioè il processo che genera le risposte.

Che cosa dice il numero di parametri su costi e qualità?

A parità di condizioni, più pesi richiedono generalmente più risorse per essere memorizzati e utilizzati. Ma «a parità di condizioni» è una precisazione sostanziale. Precisione, architettura, hardware, raggruppamento delle richieste in batch e quantità di testo elaborato incidono sul risultato.

Per chi ospita il modello sulla propria infrastruttura, il numero di parametri aiuta a individuare l'hardware adatto. Per un'API gestita dal fornitore, invece, non permette di calcolare la spesa: contano le regole di fatturazione e il carico di lavoro. Un modello che richiede tentativi ripetuti o molte correzioni umane può inoltre rivelarsi una scelta operativa poco conveniente, anche se sembra efficiente.

Quanto alla qualità, le dimensioni sono un indizio sulle capacità, non un punteggio. Un documento di acquisto dovrebbe richiedere risultati su input rappresentativi, casi di errore e condizioni di valutazione. Una stima non pubblicata del numero di parametri di un modello chiuso non è una prova da accettare.

Parametri totali e attivi nei modelli MoE

I parametri totali descrivono l'intero modello; quelli attivi descrivono il percorso di calcolo dichiarato per un token. Entrambi i valori contano in un modello mixture-of-experts, di solito abbreviato in MoE.

Un MoE contiene sottoreti esperte e un router che seleziona quali elaboreranno ciascun token. Questi «esperti» sono componenti matematici, non specialisti da assegnare alla contabilità o all'ufficio legale. Attivare un sottoinsieme più piccolo può ridurre il calcolo rispetto all'attivazione dell'intero modello, ma gli altri pesi devono comunque risiedere da qualche parte. La spiegazione dei MoE di PyTorch descrive l'instradamento e le comunicazioni necessarie.

L'espressione «104B attivi» ha un esempio concreto pubblicato dal produttore: nell'annuncio di Kimi K3.1 Pro, Moonshot AI dichiara 2.8T parametri totali e 104B attivi. Convertendo il totale in 2,800B si ottiene 104 ÷ 2,800, ossia circa il 3.7% di parametri attivi. Questa percentuale deriva dal nostro calcolo sui valori annunciati: non misura un aumento di velocità e non è una classifica di qualità.

Un secondo esempio è la scheda del modello Qwen3-235B-A22B di Qwen, che riporta 235B parametri totali e 22B attivati. Nell'illustrazione le stanze inattive restano visibili perché lo spazio necessario a memorizzare i pesi non scompare quando un token segue un altro percorso.

Per pianificare l'esecuzione, occorre capire come viene memorizzato e distribuito l'intero modello, come sono collocati gli esperti sull'hardware e quali prestazioni si ottengono con il numero effettivo di richieste simultanee. Il numero di parametri attivi non è una specifica della memoria necessaria alla GPU, l'unità di elaborazione grafica. La guida ai mixture-of-experts approfondisce questo aspetto infrastrutturale.

Seconda parte: i parametri di generazione orientano la risposta

Le impostazioni di generazione modificano la selezione dei token e le condizioni di arresto, entro le capacità del modello. L'API è l'interfaccia che l'applicazione chiama per richiedere una risposta. Le sue impostazioni non possono fornire fonti mancanti, correggere un'istruzione ambigua o garantire una risposta corretta.

Temperatura LLM: quanto si concentrano le scelte?

La temperatura modifica la distribuzione di probabilità usata per selezionare il token successivo. Valori più bassi favoriscono maggiormente le scelte più probabili; valori più alti ammettono più varietà. È utile per scegliere tra formulazioni coerenti e una gamma più ampia di bozze.

In un flusso di lavoro sulle fatture, la varietà è raramente l'obiettivo. Per proporre titoli alternativi di una campagna, invece, può essere utile. Ma una temperatura bassa non rende vero un numero di fattura inventato, e una temperatura alta non aggiunge conoscenze.

Nemmeno una richiesta con temperatura zero garantisce sempre la riproducibilità. Il glossario di Anthropic avverte esplicitamente che input identici possono produrre risultati diversi anche a temperatura zero. La riproducibilità va valutata sull'intero sistema che serve il modello.

Top-p negli LLM: quali candidati restano in gioco?

Top-p, o nucleus sampling, limita l'insieme dei candidati in base alla probabilità cumulativa. È una soglia di probabilità, non il numero di candidati e nemmeno una percentuale del vocabolario.

Consideriamo, a scopo illustrativo, una distribuzione di probabilità del token successivo pari a 0.60, 0.25, 0.10 e 0.05. Una soglia top-p di 0.9 richiede i primi tre candidati: i primi due sommano 0.85, mentre i primi tre arrivano a 0.95. Sono numeri di un esempio didattico, non output osservati di un modello.

La temperatura rimodella le probabilità; top-p restringe l'insieme dei candidati ammissibili. Per una prima configurazione aziendale, conviene modificare un solo controllo di campionamento alla volta. È anche la raccomandazione di OpenAI nel riferimento di Chat Completions.

Limite di token: un tetto, non una lunghezza richiesta

Il limite di token di generazione impone un tetto alla risposta. Non chiede al modello di usare esattamente quel numero di token e non ne amplia la finestra di contesto, cioè la capacità di gestire la conversazione.

Un limite troppo basso può interrompere un oggetto JSON, una frase o una patch di codice. Un tetto elevato non rende automaticamente utile la risposta. La lunghezza desiderata va indicata nel prompt, lasciando poi margine sufficiente sotto il limite per ottenere un risultato completo.

Il ragionamento richiede un'ulteriore distinzione. Il riferimento di Responses di OpenAI specifica che il tetto di output comprende sia i token visibili sia quelli di ragionamento. Anche il riferimento di Messages di Anthropic conteggia i token di thinking in max_tokens. Il budget di una richiesta con ragionamento non va quindi calcolato come se tutti i token consentiti comparissero nella risposta finale.

Sequenze di arresto: fermarsi nel punto giusto

Una sequenza di arresto termina la generazione quando compare una stringa prestabilita. Va usata solo se l'applicazione dispone di un delimitatore affidabile, come un marcatore finale esplicito che non possa comparire legittimamente nel contenuto.

Un ritorno a capo non è una buona sequenza di arresto generica per un report su più righe. Una parentesi graffa chiusa non lo è per un JSON annidato: la prima corrispondenza può interrompere la risposta troppo presto. Per l'estrazione strutturata, è preferibile usare il meccanismo di schema supportato dal fornitore e validare i campi restituiti.

Di norma, il punto di partenza più sensato è omettere le sequenze di arresto personalizzate. Restano comunque necessari un tetto ai token di output e la validazione.

Penalità: ridurre le ripetizioni con cautela

La presence penalty tiene conto del fatto che un token sia già comparso. La frequency penalty tiene conto di quante volte è comparso. Le penalità positive ne scoraggiano il riutilizzo; quelle negative possono favorirlo, se l'endpoint supporta questi valori.

Una ripetizione non è sempre un difetto. Un codice prodotto, il nome di un cliente, una chiave JSON o un identificatore nel codice possono dover ricomparire esattamente uguali. Penalizzarli può ostacolare il compito.

Per l'estrazione di dati e il codice, conviene iniziare senza penalità di ripetizione. Nella scrittura di bozze, prima va corretta un'eventuale istruzione che induce una struttura ripetitiva. Solo dopo ha senso valutare una piccola penalità supportata e verificare che migliori il testo senza alterare la terminologia richiesta. Il riferimento sulla generazione di Google avverte inoltre che penalità di frequenza negative possono innescare cicli di token ripetuti.

Intervalli e valori predefiniti delle API: OpenAI, Anthropic e Google

Sono l'endpoint, il modello e la versione dell'API a determinare quali impostazioni si possono inviare. Il fatto che un campo abbia lo stesso nome in un SDK non dimostra che tutti i fornitori implementino lo stesso controllo.

La tabella si riferisce a Chat Completions per OpenAI, a Messages API versione 2026-10-21 per Anthropic e a generateContent della Gemini Developer API per Google. Non estende a quest'ultima le impostazioni di Vertex AI o dell'Interactions API di Google.

NS significa che la documentazione attuale del campo citato non specifica un intervallo numerico o un valore predefinito. Non significa zero, illimitato o non supportato. L'indicazione «omettere» è un consiglio applicativo, non un valore predefinito attribuito al fornitore.

Fonti: schema delle richieste OpenAI, schema delle richieste Anthropic, migrazione di versione Anthropic, schema di generazione Google, metadati dei modelli Google e intervallo top-p di Google.

La tabella generale di risoluzione dei problemi di Google indica per la temperatura un intervallo più ristretto rispetto al riferimento del campo di generazione. Occorre usare quest'ultimo insieme a maxTemperature del modello scelto; per i valori specifici del modello si consultano Model.temperature, Model.topP e Model.outputTokenLimit. Una richiesta di esempio non va scambiata per un valore predefinito documentato.

OpenAI: prima verificare la compatibilità con il ragionamento

L'attuale guida a GPT-6 di OpenAI richiede di rimuovere temperature e top_p quando il livello di ragionamento è diverso da none. GPT-6 Astra e GPT-6.1 Sol non supportano none; GPT-6 Sol e GPT-6 Luna sì. È una limitazione di compatibilità, non l'indicazione di una temperatura numerica fissa.

Conta anche l'endpoint. Responses usa max_output_tokens, il cui minimo nello schema attuale è 16; lo stesso schema non indica un valore numerico predefinito né un massimo universale. Lo schema di creazione della richiesta non espone i campi stop, presence_penalty o frequency_penalty di Chat Completions. Nel riferimento di Chat Completions, stop è esplicitamente indicato come non supportato per o3 e o4-mini, mentre max_tokens è deprecato a favore di max_completion_tokens.

La regola pratica è costruire la richiesta per l'endpoint scelto e poi applicare le regole di compatibilità del modello. Non bisogna copiare tutta la tabella in un'unica richiesta.

Anthropic: la versione dell'API può eliminare un controllo

La guida alla migrazione del 21 ottobre di Anthropic specifica che inviare temperature, top_p o top_k con la versione API 2026-10-21 produce un errore 400, anche se si invia un valore predefinito. Quando i campi vengono omessi, il comportamento include una temperatura di 1.0.

Usare una versione precedente dell'API non restituisce automaticamente flessibilità su ogni modello. La documentazione sul thinking di Anthropic afferma che modelli tra cui Claude Sonnet 5.5 rifiutano valori di campionamento diversi da quelli predefiniti, indipendentemente dall'attivazione del thinking. Per questi modelli indica un top-p predefinito di 0.99 e precisa che il valore 1 viene rifiutato. Un vecchio intervallo generico non può prevalere sulla regola del modello.

Per generare effettivamente una risposta, bisogna fornire un budget max_tokens positivo entro il limite del modello. Il minimo documentato di zero serve a preparare la cache senza produrre una risposta; non è una configurazione utile per l'estrazione.

Google: un'impostazione accettata può non avere effetto

La guida alla migrazione a Gemini 3.6 Flash e 3.5 Flash-Lite di Google afferma che questi modelli ignorano le impostazioni deprecate di temperatura, top-p e top-k. Chiede agli sviluppatori di rimuoverle e specifica che le future generazioni di modelli le rifiuteranno con un errore 400.

Il problema è diverso da quello di una richiesta rifiutata: l'applicazione può sembrare accettare una modifica della temperatura mentre il modello continua a comportarsi esattamente come prima. Prima di considerare una risposta riuscita come prova dell'efficacia di un controllo, bisogna verificare la documentazione del modello scelto.

Impostazioni ragionevoli per le attività aziendali

Si parte dal comportamento supportato dal fornitore e da una definizione misurabile del risultato atteso. I numeri che seguono sono nostre proposte iniziali per endpoint regolabili: non sono valori predefiniti dei fornitori, impostazioni ottimali misurate o configurazioni trasferibili ovunque. Le regole di compatibilità appena descritte hanno la precedenza.

Estrazione: preservare i valori esatti

Per i campi delle fatture, la classificazione dei ticket di assistenza o i metadati dei contratti, si può provare una temperatura di 0 o 0.2, solo dove supportata. Lasciare top-p invariato. Omettere le sequenze di arresto personalizzate e le penalità di ripetizione; su un modello compatibile con OpenAI Chat Completions, impostare esplicitamente entrambe le penalità a 0 è un altro modo per definire una configurazione di riferimento senza penalità.

Nelle richieste Anthropic attuali e per i modelli Gemini Flash citati, i controlli di campionamento vanno omessi. Servono definizioni esplicite dei campi, categorie consentite, esempi di dati mancanti e la funzionalità di output strutturato supportata dal fornitore. Il risultato va validato indipendentemente dalla sua formattazione.

Per un breve record estratto, un tetto iniziale di 1,000 token di output può essere un esperimento di partenza su una richiesta compatibile senza ragionamento. Non è un limite universale: bisogna controllare eventuali troncamenti e consumo effettivo, e prevedere separatamente il budget di ragionamento quando necessario. Meglio chiedere un marcatore per i valori mancanti che un numero di fattura inventato.

Criterio di accettazione: tutti i campi richiesti sono presenti, i valori corrispondono alla fonte e le informazioni assenti restano tali. Superare la sola validazione JSON non basta.

Scrittura: variare la forma, preservare i fatti

Per un'email di primo contatto o una descrizione di prodotto, si parte dal comportamento predefinito supportato dal modello. Su un endpoint regolabile, lo si confronta con una temperatura di 0.7, lasciando top-p invariato. Nel prompt vanno specificati pubblico, lunghezza, tono, fatti da includere e affermazioni da evitare.

All'inizio si omettono le penalità. Se un modello compatibile con OpenAI Chat Completions continua a ripetere formule indesiderate, una penalità di frequenza di 0.2 è un esperimento contenuto, entro l'intervallo documentato. Va mantenuta solo se la revisione mostra un miglioramento; i nomi dei prodotti richiesti devono restare intatti.

Per i modelli che eliminano i controlli di campionamento, si possono chiedere esplicitamente approcci diversi, per esempio una bozza concisa e fattuale e una bozza narrativa. Le differenze si giudicano sui testi prodotti.

Criterio di accettazione: una varietà utile senza nuove affermazioni fattuali. «Più sorprendente» non equivale a «migliore testo aziendale».

Codice: lasciare spazio per finire e verificare il comportamento

Per una patch circoscritta su un endpoint regolabile, una temperatura di 0 o 0.2 è un ragionevole termine di confronto. Per un modello di ragionamento, bisogna seguire la configurazione supportata e omettere i campi di campionamento incompatibili. Penalità di ripetizione e sequenze di arresto personalizzate vanno escluse, salvo che un protocollo verificato le richieda.

Occorre fornire il codice pertinente, i vincoli e il comportamento atteso. Il budget di output deve consentire una patch completa. Se la risposta raggiunge il tetto, il risultato va considerato incompleto, senza presumere che la porzione visibile sia sicura da applicare.

Criterio di accettazione: la patch rispetta la specifica e supera i controlli appropriati. Nel codice è normale ripetere gli identificatori, e una risposta dall'aspetto plausibile non dimostra che funzioni.

Che cosa non garantiscono né i parametri né le impostazioni

La promessa esagerata è che un solo numero possa sostituire una valutazione. Non può farlo, che si tratti del numero di pesi o della temperatura.

Un modello più grande non è automaticamente migliore nel proprio flusso di lavoro specifico. Un numero più basso di parametri MoE attivi non significa che l'intero modello occupi quella quantità di memoria. Una temperatura bassa non garantisce la verità. Un tetto di output elevato non garantisce un'argomentazione completa, e una chiamata API riuscita non dimostra che tutte le impostazioni inviate siano state applicate.

Le prove utili sono un input rappresentativo, una condizione di successo definita e un risultato verificato. Per un acquisto, si chiede al fornitore di dimostrare il flusso di lavoro con la configurazione che verrà effettivamente usata. Per lo sviluppo, si registrano modello, endpoint, versione dell'API, prompt e impostazioni, così da capire che cosa è cambiato quando cambia il comportamento.

Le prossime mosse per chi acquista, gestisce e sviluppa

Chi acquista deve confrontare i risultati; chi gestisce deve definire gli errori; chi sviluppa deve eliminare le impostazioni non supportate. Queste responsabilità convergono sullo stesso piccolo insieme di casi di valutazione.

Chi sceglie un servizio gestito può procedere anche senza conoscere il numero di parametri, se il servizio dimostra di ottenere i risultati richiesti. Per acquistare hardware su cui ospitare il modello, invece, occorre attendere il dimensionamento completo del checkpoint, della precisione e del carico di lavoro. Chi ha già un flusso funzionante non deve sostituirlo solo perché un altro modello pubblicizza un numero più alto.

Chi cambia modello o versione dell'API deve verificare subito la compatibilità. Per chi usa un'interfaccia gestita che non espone controlli di generazione, la sintassi dei campi della richiesta ha un impatto limitato; resta comunque necessario validare l'output.

1. 1

   Raccogliere i casi che devono riuscire

   Lunedì prossimo, raccogliere 20 esempi rappresentativi di un flusso di lavoro, includendo input incompleti, ambigui e insolitamente lunghi. Scrivere il risultato atteso o i criteri di revisione prima di confrontare i modelli.

2. 2

   Esplicitare la configurazione della richiesta

   Registrare endpoint, modello e versione dell'API. Verificare quali controlli sono supportati, eliminare gli altri e scegliere un budget di output che consenta un risultato completo. Nel prompt vanno mantenuti la terminologia richiesta e il comportamento da adottare quando mancano dati.

3. 3

   Cambiare una cosa e valutare il risultato

   Confrontare la configurazione di riferimento con una sola modifica supportata. Per l'estrazione, verificare la corrispondenza con la fonte; per le bozze, l'accuratezza dei fatti e l'utilità; per il codice, il comportamento e i controlli. Mantenere la configurazione più semplice, salvo che la modifica dimostri un vantaggio.

Domande frequenti

Come funziona il parametro temperatura negli LLM?

Modifica quanto è concentrata la distribuzione di probabilità del token successivo. Valori più bassi favoriscono le scelte probabili; valori più alti consentono più varietà. Agisce sul campionamento, non sui pesi appresi, e alcune API attuali rifiutano o ignorano questa impostazione.

Quanto spazio occupa indicativamente un modello da 70B?

Con esattamente 70 miliardi di pesi, lo spazio per i soli pesi è di circa 140 GB a 16-bit, 70 GB a 8-bit o, nel caso ideale, 35 GB a 4-bit. Questi valori decimali escludono la memoria di esecuzione e l'overhead della quantizzazione. I requisiti effettivi dipendono dal checkpoint e dal carico di lavoro.

Quali sono i quattro tipi di parametri?

Per gli LLM non esiste una classificazione universale in quattro tipi. Una distinzione utile separa parametri appresi del modello, impostazioni dell'architettura, impostazioni di addestramento e impostazioni di generazione. Sono categorie che aiutano a comprendere il sistema, non un'affermazione secondo cui ogni API avrebbe quattro controlli.

Qual è la differenza tra GPT e LLM?

LLM significa large language model, cioè modello linguistico di grandi dimensioni, ed è la categoria generale. GPT significa generative pretrained transformer e identifica una particolare famiglia di modelli e un approccio all'interno di quella categoria. Anche altre famiglie di modelli linguistici sono LLM.

Quali sono i quattro tipi di LLM?

Non esiste un unico elenco standard di quattro tipi. La distinzione tra densi e mixture-of-experts riguarda l'architettura; quella tra pesi aperti e chiusi riguarda la disponibilità. Rispondono a domande diverse e non vanno combinate in una presunta classifica di qualità.

ChatGPT è un LLM o un'IA?

ChatGPT è un'applicazione di IA che usa modelli. Occorre distinguere l'applicazione, il modello selezionato al suo interno e le impostazioni API disponibili agli sviluppatori: sono livelli diversi.

Quali sistemi di IA non sono LLM?

L'IA comprende molto più dei modelli linguistici. Un classificatore antifrode o un sistema di visione artificiale possono usare metodi di machine learning senza ricorrere a un LLM. Nemmeno il numero di parametri è una caratteristica esclusiva dei modelli linguistici.

Qual è l'LLM più intelligente?

Il numero di parametri non può dare una risposta valida a prescindere dal compito. I modelli vanno confrontati su esempi rappresentativi del lavoro, con gli stessi criteri di accettazione e una configurazione documentata. Un risultato su un benchmark non risolve la scelta per ogni attività aziendale.

A quale ramo dell'IA appartengono gli LLM?

Gli LLM sono modelli di deep learning usati per elaborare e generare linguaggio. I parametri appresi appartengono al modello; la temperatura e gli altri controlli della richiesta riguardano il modo in cui l'applicazione lo usa.

Per spiegazioni pratiche sui sistemi di IA e sulle decisioni che li riguardano, iscriviti alla newsletter.