L'IA generativa spiegata: modelli, recupero, strumenti e applicazioni non sono la stessa cosa

L'IA generativa non è un singolo componente. Un sistema di IA generativa in produzione di solito combina un modello generativo con codice applicativo che fornisce istruzioni e contesto, recupera conoscenza esterna quando necessario, espone strumenti per leggere o modificare sistemi esterni, gestisce lo stato di runtime e i permessi, e trasforma il risultato in un prodotto utilizzabile. Trattare modello, recupero, strumenti, contesto, runtime e applicazione come la stessa cosa nasconde i confini che determinano freschezza, sicurezza, affidabilità, costo e controllo.

Cosa significa realmente “IA generativa”?

A livello di modello, l'IA generativa si riferisce a modelli di IA che generano contenuti sintetici derivati come testo, immagini, audio, video, codice o altro output digitale. NIST AI 600-1 utilizza questo significato orientato al modello e discute separatamente i rischi a livello di modello, sistema, applicazione e caso d'uso.

Questa distinzione è importante perché un modello di IA non è la stessa cosa del sistema di IA completo. Il glossario attuale del NIST definisce un modello di IA come un componente che produce output da input utilizzando tecniche computazionali, statistiche o di machine learning, mentre un sistema di IA può includere software, hardware, applicazioni, strumenti o utilità che operano utilizzando l'IA.

Il modello più semplice e utile di un sistema di IA generativa

Come primo modello mentale, immagina un assistente aziendale che risponde: “Questo cliente può ricevere un rimborso oggi?” Una risposta utile può richiedere diverse responsabilità. Il modello linguistico può interpretare la domanda e scrivere la spiegazione, ma lo stato attuale dell'ordine può provenire da uno strumento di database, la politica di rimborso può provenire dal recupero di documenti, i permessi possono essere applicati dall'applicazione, e l'azione finale può richiedere una chiamata API controllata.

I sistemi reali non seguono sempre esattamente questa sequenza. Il recupero può avvenire prima della prima chiamata al modello, gli strumenti possono essere selezionati durante un ciclo di agente, la logica applicativa deterministica può bypassare completamente il modello, e la validazione può avvenire in diverse fasi. Il punto è separare le responsabilità, non imporre un unico flusso di lavoro universale.

I sei confini che contano

1. Il modello: la generazione è la sua responsabilità principale

Un modello generativo mappa gli input forniti su output generati. Per un modello linguistico, ciò può includere testo in linguaggio naturale, JSON strutturato, codice, classificazioni, riassunti, piani o argomenti per chiamate a strumenti. I modelli generativi multimodali possono lavorare con ulteriori tipi di input e output.

Il modello può contenere una conoscenza appresa sostanziale nei suoi parametri, ma la conoscenza parametrizzata non è un database live. Il modello non conosce automaticamente un documento creato cinque minuti fa, il livello attuale delle scorte, un record privato di un cliente o lo stato di un'applicazione, a meno che tali informazioni non vengano fornite attraverso il percorso di input corrente.

Ecco perché cambiare il modello non risolve automaticamente conoscenza obsoleta, permessi mancanti, recupero non funzionante, proprietà dello stato errata o esecuzione non sicura degli strumenti. Questi guasti spesso appartengono ad altri livelli.

2. Recupero: trovare prove esterne è un'operazione separata

Il recupero seleziona informazioni da una fonte esterna prima o durante la generazione. Il lavoro del 2020 sulla Retrieval-Augmented Generation di Lewis et al. ha reso esplicita la separazione combinando un modello generativo parametrico con una memoria non parametrica recuperata. I sistemi di produzione moderni utilizzano molte varianti di recupero, ma l'idea architetturale rimane: le prove utili possono essere recuperate al momento dell'inferenza invece di affidarsi solo a ciò che il modello ha appreso durante l'addestramento.

Il recupero può utilizzare ricerca lessicale, embedding, ricerca vettoriale, ricerca ibrida, SQL, grafi di conoscenza, filtri sui metadati, API o altri meccanismi di selezione. Un database vettoriale è quindi una possibile componente di recupero, non la definizione di RAG.

3. Strumenti: accesso e azione non sono conoscenza del modello

Uno strumento è un'interfaccia attraverso la quale un runtime AI può richiedere funzionalità esterne al modello. Uno strumento può interrogare un database, cercare sul web, leggere un file, calcolare un valore, chiamare un servizio interno, creare un ticket, inviare un messaggio, modificare un record o attivare un'altra operazione controllata.

L'attuale documentazione di OpenAI sul function calling rende esplicito questo confine: il function calling consente ai modelli di interfacciarsi con sistemi esterni e accedere a dati o azioni forniti dall'applicazione. Il modello può proporre o selezionare una chiamata, ma il sistema esterno esegue l'operazione reale.

L'uso degli strumenti crea quindi due domande separate: il modello può richiedere questa capacità? e l'applicazione la autorizzerà ed eseguirà? Un sistema di produzione non dovrebbe confondere l'intento del modello con il permesso di causare un effetto collaterale.

4. Contesto: ciò che il modello può vedere in questo momento

Il contesto è l'informazione disponibile al modello per un particolare passo di inferenza. La guida di Anthropic sull'ingegneria del contesto descrive il contesto come l'insieme di token inclusi quando si campiona da un LLM. In pratica, quell'insieme può contenere istruzioni di sistema, messaggi utente, cronologia della conversazione, prove recuperate, definizioni di strumenti, risultati di strumenti, riassunti di memoria e stato applicativo selezionato.

Il contesto non è quindi né la base di conoscenza completa né la memoria a lungo termine. Un'azienda può memorizzare dieci milioni di documenti mentre solo una manciata di passaggi entra in una singola chiamata al modello. Un runtime può persistere un anno di cronologia delle conversazioni esponendo solo i pezzi necessari per l'attività corrente.

La finestra di contesto crea anche un vincolo ingegneristico. Aggiungere più testo non garantisce una risposta migliore; informazioni irrilevanti, obsolete, contraddittorie o di bassa autorità possono diluire le prove che contano davvero.

5. Runtime e orchestrazione: coordinare il ciclo

Il runtime o livello di orchestrazione coordina come il modello partecipa a un'attività. A seconda dell'architettura, può gestire sessioni, richieste al modello, scoperta di strumenti, cicli di chiamata di strumenti, tentativi, passaggi di consegne, eventi in streaming, timeout, checkpoint, compattazione o ambienti di esecuzione.

Alcuni runtime sono codice applicativo sottile attorno a un'API del modello. Altri sono harness di agenti completi. Un runtime gestito da un fornitore può possedere parte del ciclo mentre l'applicazione possiede ancora la verità di dominio, l'autorizzazione, gli effetti collaterali aziendali e il ciclo di vita del prodotto.

Questo confine è importante perché dove viene eseguito il runtime e dove viene eseguita l'inferenza sono decisioni separate. Un client o processo agente in esecuzione locale può comunque chiamare un modello remoto, mentre un'applicazione remota può chiamare un modello ospitato su infrastruttura sotto il controllo dell'organizzazione.

6. L'applicazione: dove l'IA diventa un prodotto

L'applicazione è il confine del prodotto attorno ai componenti di IA. Possiede l'esperienza utente, il modello di dominio, lo stato corrente, l'identità, l'ambito del tenant, i permessi, la persistenza, le integrazioni di servizio, la validazione, l'osservabilità, la logica di fatturazione o quota dove rilevante, e le regole che determinano ciò che l'IA è autorizzata a vedere o fare.

Questo è lo strato che trasforma "un modello può produrre output utili" in "un sistema può fornire una capacità affidabile". Lo stesso modello può partecipare a un assistente di ricerca privato, a un flusso di lavoro di supporto, a un agente di codice o a un'applicazione commerciale perché l'applicazione circostante modifica i dati, gli strumenti, le politiche, lo stato e il contratto di esecuzione.

Come le parti lavorano insieme in una richiesta reale

Considera un assistente di supporto a cui viene chiesto: "Rimborsa l'ordine 4711 se è ancora idoneo, e spiega perché". La richiesta combina conoscenza, stato corrente, autorizzazione, ragionamento e un effetto collaterale.

Se l'assistente ha solo il modello linguistico, può discutere di rimborsi ma non può sapere in modo sicuro se l'ordine 4711 è attualmente idoneo o eseguire la transazione. Se ha solo il recupero, può trovare la politica ma manca comunque dello stato dell'ordine in tempo reale. Se ha strumenti senza autorizzazione dell'applicazione, può diventare capace ma non sicuro. L'affidabilità deriva dal comporre gli strati con una proprietà esplicita.

Diversi prodotti di IA usano combinazioni diverse

Questi sono modelli architetturali, non classifiche di maturità. Una funzionalità solo modello può essere il design corretto quando il compito non richiede fatti o azioni esterne. Aggiungere recupero, strumenti, memoria o un ciclo di agente è giustificato solo quando il compito richiede quelle capacità.

Evidenza di implementazione: Aaasaasa AI Client

Aaasaasa AI Client è uno spazio di lavoro IA desktop local-first costruito con Nuxt 4, Electron e TypeScript. Il suo AI Hub separa deliberatamente agente/client, provider, modello, posizione runtime, permessi e client web invece di trattarli come un'unica impostazione "IA".

Questa separazione crea un comportamento concreto. Direct Chat può parlare con i modelli senza strumenti di filesystem o shell. Un agente Codex può usare un workspace selezionato e un profilo di permessi. Ollama può fornire inferenza locale diretta, mentre LM Studio e endpoint configurabili compatibili con OpenAI rappresentano altri percorsi di provider. Un processo Codex in esecuzione locale può comunque usare un modello cloud, quindi l'interfaccia utente e l'architettura non equiparano runtime locale con inferenza locale.

L'implementazione contiene anche supporto Qdrant/vettoriale, capacità di estrazione documenti e un broker MCP di directory autenticato. Questi componenti illustrano un altro confine: l'infrastruttura di recupero e l'accesso agli strumenti possono vivere nello stesso prodotto senza diventare proprietà del modello stesso.

Errori di categoria comuni

Modalità di guasto quando i confini collassano

Gli errori di confine non sono semplicemente problemi di terminologia. Creano guasti di produzione distinti che richiedono correzioni diverse.

Cosa è stabile e cosa è sensibile alla versione?

Le distinzioni architetturali in questo articolo sono intenzionalmente neutre rispetto al fornitore. Gli esempi attuali riportati di seguito sono fatti di implementazione che dovrebbero essere ricontrollati quando le API evolvono.

Un articolo fonte di verità dovrebbe quindi preservare entrambi i livelli: concetti stabili per l'architettura e prove datate per le implementazioni attuali. Mescolare i due fa invecchiare un articolo inutilmente in fretta.

Il test del confine dei componenti IA

Quando si valuta una funzionalità IA, porre le seguenti domande in ordine. Le risposte rivelano quali componenti il sistema ha effettivamente e quali responsabilità sono ancora implicite.

Cosa non è l'IA generativa

L'IA generativa non è sinonimo di LLM, anche se gli LLM sono una classe importante di modelli generativi. Non è nemmeno sinonimo di RAG, di un database vettoriale, di un agente, di un protocollo di strumenti, di un'interfaccia chatbot o di un'applicazione.

Questi concetti possono essere collegati, ma ciascuno risponde a una diversa domanda architetturale. Un LLM chiede come viene prodotto l'output linguistico. Il recupero chiede da dove provengono le prove esterne. Gli strumenti chiedono come vengono esposte le capacità esterne. Il contesto chiede cosa può vedere il modello. Il runtime chiede come viene coordinata l'esecuzione. L'applicazione chiede come la capacità diventa un prodotto controllato.

Dove andare dopo nel grafo della conoscenza

Una volta che questi confini sono chiari, i argomenti più profondi diventano più facili da collocare. RAG appartiene al recupero e alla costruzione del contesto. Il Trigger di Recupero decide quando sono richieste prove esterne. La memoria dell'agente riguarda ciò che persiste nel tempo. La chiamata di strumenti e MCP appartengono all'accesso alle capacità. Gli harness degli agenti appartengono all'orchestrazione del runtime. RBAC, l'isolamento dei tenant e l'autorizzazione del dominio appartengono al confine di sicurezza dell'applicazione e della piattaforma.

Limitazioni

Il modello a sei livelli è una mappa delle responsabilità, non un requisito che ogni prodotto debba distribuire sei servizi separati. Una piccola applicazione può implementare la costruzione del contesto, il retrieval e l'orchestrazione all'interno di un unico processo. Una piattaforma gestita può raggruppare diverse responsabilità dietro una sola API. La distribuzione fisica può essere combinata mentre la titolarità semantica rimane distinta.

Anche la terminologia varia tra fornitori e ricerca. "Agente", "runtime", "memoria", "strumento", "connettore" e "contesto" possono essere definiti in modo diverso. Le definizioni qui scelte servono a rendere espliciti la titolarità operativa e la diagnosi dei guasti, non a sostenere che ogni framework utilizzi un vocabolario identico.

La sezione Aaasaasa AI Client documenta un modello di implementazione. Dimostra che confini espliciti sono praticabili, ma non prova che la stessa disposizione dei componenti sia ottimale per ogni prodotto di IA.

Cosa cambierebbe questa risposta?

La mappa delle responsabilità richiederebbe una revisione se le architetture dei modelli stesse iniziassero a possedere stato esterno autorevole, permessi, effetti collaterali transazionali durevoli e accesso verificabile alle fonti come proprietà intrinseche anziché come capacità fornite da un sistema circostante. Le attuali architetture di produzione non rendono sicura questa assunzione generale.

I singoli esempi di implementazione cambieranno molto prima. Gli strumenti di retrieval ospitati, le API per agenti, le integrazioni MCP, le funzionalità di gestione del contesto e le capacità dei fornitori si evolvono rapidamente. Questi dettagli dovrebbero essere aggiornati senza far collassare le distinzioni di fondo tra generazione, evidenza, accesso alle capacità, contesto, esecuzione e controllo dell'applicazione.

Conclusione

L'IA generativa diventa più facile da progettare una volta che "l'IA" smette di essere trattata come un'unica scatola nera. Il modello è il componente generativo, non il prodotto completo. Il retrieval fornisce evidenze esterne. Gli strumenti espongono capacità. Il contesto porta informazioni selezionate nell'inferenza corrente. Il runtime coordina l'esecuzione. L'applicazione possiede il confine autorevole del prodotto.

Questa separazione è utile più che per la sola spiegazione. Indica agli ingegneri da dove provengono i fatti obsoleti, dove risiede l'autorizzazione, perché un runtime locale può comunque usare l'inferenza cloud, perché RAG non equivale a un database vettoriale, perché le chiamate agli strumenti richiedono validazione e perché cambiare il modello non può riparare ogni guasto del sistema.

La domanda architetturale durevole non è quindi "Quale modello di IA stiamo usando?". È: quale responsabilità possiede ciascun componente, quali evidenze attraversano ciascun confine e quale livello è autorizzato a modificare lo stato reale?

FAQ

Glossario

Fonti primarie ed evidenze di implementazione

Le definizioni stabili di seguito sono ancorate a standard/ricerca; gli esempi di implementazione in rapida evoluzione utilizzano la documentazione ingegneristica ufficiale corrente. Aaasaasa AI Client è una prova di implementazione originale ed è stato verificato rispetto allo stato del suo codice/documentazione datato 26 luglio 2026.