ingegneria AI
C’è un modo molto semplice per capire dove sta andando l’intelligenza artificiale: guardare il percorso che va dai modelli linguistici ai sistemi agentici.
All’inizio c’è il modello.
Poi arriva il prompt.
Poi gli strumenti.
Poi gli agenti.
Poi i team di agenti.
E infine i grafi: la struttura che permette a tutto questo di non collassare in una lunga conversazione senza memoria.
Questa è, in pratica, l’evoluzione dell’ingegneria AI moderna. Non più soltanto “usare ChatGPT meglio”, ma progettare sistemi capaci di leggere, ragionare, agire, coordinarsi e costruire conoscenza nel tempo.
È il passaggio da un LLM come generatore di testo a un’infrastruttura AI completa.
E per capirlo davvero bisogna partire da zero.
0%: LLM da zero, il motore che ha cambiato tutto
Un Large Language Model non è magia. È un sistema statistico addestrato a prevedere il token successivo dato un contesto.
Sembra una definizione riduttiva, ma dentro questa frase c’è quasi tutta la rivoluzione degli ultimi anni.
Un LLM prende una sequenza di testo, la trasforma in token, passa questi token attraverso una rete neurale gigantesca e produce una distribuzione di probabilità sul prossimo token possibile.
Token dopo token, costruisce una risposta.
La parte sorprendente è che, aumentando scala, dati e capacità computazionale, questa semplice operazione produce comportamenti emergenti:
- traduzione;
- sintesi;
- scrittura di codice;
- ragionamento approssimato;
- classificazione;
- estrazione di informazioni;
- pianificazione;
- dialogo multi-turno.
Il punto non è che il modello “capisce” come una persona. Il punto è che ha interiorizzato pattern linguistici, concettuali e operativi presenti nei dati di addestramento.
In termini pratici, un LLM è una macchina generalista per trasformare input in output.
Ma da solo non basta.
Un modello linguistico puro ha tre limiti enormi:
- Non conosce automaticamente i tuoi dati aggiornati
- Non sa agire nel mondo esterno senza strumenti
- Non possiede memoria strutturata e affidabile
Per questo l’ingegneria AI non si ferma al modello. Il modello è il motore. Ma un motore senza telaio, sensori, controllo e memoria non diventa un prodotto.
Diventa solo una demo.
30%: usare davvero i modelli AI
La prima grande differenza tra un utente occasionale e un AI engineer è questa: l’utente parla con il modello, l’ingegnere costruisce un sistema intorno al modello.
Usare realmente un LLM significa progettare almeno cinque livelli.
1. Il modello giusto
Non tutti i modelli servono allo stesso scopo.
Un modello piccolo può essere perfetto per classificare ticket, estrarre campi da documenti o rispondere a domande semplici. Un modello più grande può servire per ragionamento complesso, coding, analisi strategica o generazione multi-step.
La scelta non dovrebbe partire dalla classifica dei benchmark, ma dal caso d’uso:
- latenza richiesta;
- costo per token;
- qualità attesa;
- privacy dei dati;
- supporto a tool calling;
- contesto massimo;
- capacità multimodali;
- facilità di deployment.
Nel mondo reale, il modello migliore non è sempre quello più potente. È quello che risolve il problema con il miglior equilibrio tra qualità, costo e controllo.
2. Il contesto
Un LLM risponde in base a ciò che vede nel contesto.
Se il contesto è povero, la risposta sarà generica.
Se il contesto è disordinato, la risposta sarà fragile.
Se il contesto contiene informazioni contraddittorie, il modello proverà comunque a generare qualcosa di plausibile.
Per questo il context engineering è diventato importante quanto il prompt engineering.
Non basta scrivere una buona istruzione. Bisogna decidere quali dati dare al modello, in quale ordine, con quale formato, con quali vincoli e con quali esempi.
3. Retrieval e RAG
Quando il modello deve rispondere usando dati aziendali, documentazione interna o conoscenza aggiornata, entra in gioco il RAG: Retrieval-Augmented Generation.
Il flusso base è noto:
- prendi documenti, pagine, PDF, ticket, email o knowledge base;
- li dividi in chunk;
- generi embedding;
- li salvi in un vector database;
- alla domanda dell’utente recuperi i chunk più simili;
- passi quei chunk al modello come contesto.
Questo ha reso possibile la prima generazione di chatbot aziendali.
Ma il RAG tradizionale ha un problema: recupera testo simile, non necessariamente conoscenza corretta.
La similarità semantica è utile. Ma non rappresenta relazioni, dipendenze, gerarchie, causalità, provenienza e conflitti tra informazioni.
Ed è qui che i grafi iniziano a diventare fondamentali.
4. Tool calling
Un modello che risponde soltanto con testo è limitato.
Un modello che può chiamare strumenti diventa molto più interessante.
Può:
- interrogare un database;
- leggere file;
- chiamare API;
- creare ticket;
- inviare email;
- eseguire codice;
- cercare informazioni;
- aggiornare un CRM;
- generare report.
Il tool calling trasforma il modello da interfaccia conversazionale a livello di controllo.
Ma aumenta anche il rischio: un sistema che può agire deve essere progettato con permessi, validazioni, logging e limiti chiari.
5. Valutazione
Un sistema AI senza valutazione è un esperimento permanente.
Bisogna misurare:
- accuratezza;
- groundedness;
- hallucination rate;
- latenza;
- costo;
- robustezza ai prompt ambigui;
- qualità del retrieval;
- sicurezza delle azioni;
- coerenza delle risposte nel tempo.
La valutazione è ciò che trasforma un prototipo AI in un prodotto affidabile.
65%: prompt engineering, ma quello serio
Il prompt engineering non è scrivere frasi magiche.
Non è “agisci come un esperto”.
Non è collezionare template virali.
Il prompt engineering serio è progettazione dell’interazione tra modello, contesto, obiettivo e vincoli.
Un buon prompt contiene di solito cinque elementi.
Ruolo
Il ruolo definisce il punto di vista operativo del modello.
Esempio:
Sei un analista tecnico specializzato in sistemi RAG enterprise.
Non serve a “ipnotizzare” il modello. Serve a restringere lo spazio delle risposte plausibili.
Obiettivo
Il modello deve sapere cosa deve produrre.
Analizza il documento e restituisci una lista di rischi tecnici, ordinati per impatto.
Un obiettivo chiaro riduce risposte vaghe.
Contesto
Il contesto è il materiale su cui lavorare.
Può essere un documento, un estratto da un database, una conversazione precedente, una lista di requisiti o un risultato di retrieval.
Il contesto deve essere separato dalle istruzioni, idealmente con delimitatori chiari.
Vincoli
I vincoli impediscono al modello di inventare formato, tono o livello di dettaglio.
Non usare informazioni non presenti nel contesto.
Se un dato manca, scrivi "informazione non disponibile".
Rispondi in massimo 10 bullet point.
Output schema
Quando l’output deve essere usato da un software, il formato conta più dello stile.
{
"rischi": [
{
"titolo": "string",
"impatto": "alto|medio|basso",
"evidenza": "string"
}
]
}
Questo è il punto in cui il prompt smette di essere copywriting e diventa interfaccia.
Un prompt ben progettato è una API testuale.
Dal prompt all’agente
Un agente AI nasce quando un LLM non si limita a rispondere, ma entra in un ciclo operativo.
Il ciclo base è:
Osserva → Ragiona → Agisci → Verifica → Continua
L’agente riceve un obiettivo, valuta lo stato corrente, sceglie uno strumento, osserva il risultato, aggiorna il piano e procede.
Esempio semplice: un agente per analisi documentale.
- Riceve una domanda.
- Cerca nei documenti rilevanti.
- Estrae le sezioni utili.
- Confronta fonti diverse.
- Produce una risposta con citazioni.
- Segnala eventuali incertezze.
A questo punto l’LLM non è più solo generatore. È planner, router, orchestratore e sintetizzatore.
Ma anche qui emerge un limite: un solo agente può diventare troppo generico.
Quando il compito è complesso, serve specializzazione.
100%: una persona che coordina 100 agenti
La direzione più interessante dell’ingegneria AI è il passaggio da singolo agente a sistema multi-agente.
Invece di creare un unico agente enorme che fa tutto, si progettano agenti specializzati:
- un agente ricercatore;
- un agente analista;
- un agente sviluppatore;
- un agente revisore;
- un agente QA;
- un agente sicurezza;
- un agente documentazione;
- un agente project manager;
- un agente data engineer;
- un agente che controlla coerenza e qualità.
La persona non esegue più ogni attività manualmente. Coordina un sistema.
Questo cambia il ruolo dell’essere umano.
Non più operatore di singoli task, ma progettista di workflow.
Non più solo autore, ma supervisore.
Non più solo esecutore, ma direttore d’orchestra.
Il punto chiave è che 100 agenti non significano automaticamente 100 volte più produttività. Senza architettura, 100 agenti producono rumore, duplicazione e conflitti.
Serve coordinamento.
Serve memoria condivisa.
Serve una rappresentazione comune dello stato.
Serve un modo per sapere chi ha fatto cosa, perché, con quali dati e con quale livello di affidabilità.
Ed è qui che entrano i grafi.
Perché i grafi sono il prossimo strato dell’AI engineering
Un grafo è una struttura composta da nodi e relazioni.
Sembra semplice, ma è una delle forme più potenti per rappresentare conoscenza.
In un sistema AI, i nodi possono essere:
- documenti;
- utenti;
- prodotti;
- task;
- agenti;
- decisioni;
- funzioni;
- API;
- ticket;
- concetti;
- metriche;
- eventi.
Le relazioni possono rappresentare:
- dipendenze;
- causalità;
- appartenenza;
- similarità;
- responsabilità;
- versioni;
- contraddizioni;
- prove;
- fonti;
- sequenze operative.
Un vector database ti dice quali testi sono semanticamente vicini.
Un knowledge graph ti dice come le cose sono collegate.
Questa differenza è enorme.
Perché un agente non ha bisogno solo di recuperare frasi simili. Ha bisogno di capire relazioni.
Deve sapere che:
- questo documento aggiorna una policy precedente;
- questa decisione dipende da una metrica;
- questo bug è collegato a una release;
- questo cliente appartiene a un segmento;
- questa risposta è stata generata da un agente e verificata da un altro;
- questa informazione proviene da una fonte più affidabile di un’altra.
Senza grafo, tutto diventa testo nel prompt.
Con un grafo, il sistema costruisce una memoria navigabile.
GraphRAG: quando retrieval e relazioni lavorano insieme
GraphRAG nasce dall’unione tra retrieval aumentato e knowledge graph.
Invece di recuperare soltanto chunk testuali, il sistema può recuperare entità, relazioni, comunità di concetti e percorsi nel grafo.
Il flusso diventa più ricco:
- l’utente fa una domanda;
- il sistema identifica le entità principali;
- cerca nodi rilevanti nel grafo;
- esplora relazioni vicine;
- recupera documenti collegati;
- combina ricerca vettoriale e struttura simbolica;
- passa al modello un contesto più preciso;
- genera una risposta verificabile.
Questo approccio è particolarmente utile quando le domande non sono semplici lookup.
Esempio:
Quali clienti enterprise sono esposti al rischio introdotto dall’ultima modifica API?
Un RAG classico potrebbe cercare documenti simili alla frase.
Un GraphRAG può attraversare relazioni:
Modifica API → endpoint coinvolti → prodotti dipendenti → clienti che usano quei prodotti → contratti enterprise → SLA critici
La risposta non nasce solo da similarità testuale. Nasce da un percorso di conoscenza.
Come costruire grafi per agenti AI
Costruire un grafo utile non significa disegnare diagrammi complessi.
Significa creare una rappresentazione minima ma solida del dominio.
1. Definisci le entità
Parti dalle cose che il sistema deve conoscere.
Per un support agent:
- Cliente
- Ticket
- Prodotto
- Bug
- Release
- Documento
- Soluzione
- Agente
Per un e-commerce:
- Utente
- Prodotto
- Outfit
- Stile
- Occasione
- Colore
- Materiale
- Brand
Per un sistema aziendale:
- Persona
- Team
- Processo
- Documento
- Decisione
- Task
- KPI
- Rischio
2. Definisci le relazioni
Le relazioni sono più importanti dei nodi.
Esempi:
Cliente — ha_aperto → Ticket
Ticket — riguarda → Prodotto
Bug — introdotto_in → Release
Documento — descrive → Soluzione
Agente — ha_verificato → Risposta
Ogni relazione dovrebbe avere un significato chiaro.
Meglio poche relazioni precise che cento relazioni ambigue.
3. Aggiungi provenienza e fiducia
Ogni fatto nel grafo dovrebbe sapere da dove arriva.
Fonte: ticket_1234
Estratto da: agente_analisi_log
Data: 2026-08-07
Confidenza: 0.87
Verificato: sì
Senza provenienza, il grafo diventa un contenitore di affermazioni non verificabili.
Con provenienza, diventa una memoria auditabile.
4. Usa gli LLM per estrarre, non per decidere tutto
Un LLM può aiutare a estrarre entità e relazioni da testo non strutturato.
Ma non dovrebbe avere l’ultima parola su tutto.
La pipeline corretta è:
Documento → LLM extraction → normalizzazione → validazione → inserimento nel grafo
Il modello propone. Il sistema valida.
Questa distinzione è fondamentale se vuoi costruire sistemi affidabili.
5. Collega il grafo agli agenti
Il grafo diventa davvero utile quando gli agenti lo usano per lavorare.
Un agente può:
- leggere lo stato di un task;
- vedere quali documenti sono collegati;
- controllare dipendenze;
- salvare nuove scoperte;
- aggiornare relazioni;
- segnalare conflitti;
- passare contesto ad altri agenti.
A quel punto il grafo non è solo knowledge management.
È infrastruttura operativa per sistemi agentici.
L’architettura completa: LLM, prompt, agenti e grafi
Un sistema AI moderno può essere rappresentato così:
Utente
↓
Interfaccia
↓
Router / Orchestratore
↓
Agenti specializzati
↓
Tool + API + Database
↓
Vector Store + Knowledge Graph
↓
LLM
↓
Valutazione + Logging + Memoria
Il modello genera.
Il prompt istruisce.
Gli strumenti permettono di agire.
Gli agenti organizzano il lavoro.
Il grafo conserva struttura, relazioni e memoria.
La valutazione mantiene il sistema sotto controllo.
Questa è la vera ingegneria AI: non il singolo prompt perfetto, ma l’intero sistema che rende il modello utile, affidabile e scalabile.
Conclusione: il futuro non è un chatbot più lungo
La prossima fase dell’AI non sarà semplicemente avere modelli con più contesto o risposte più fluide.
Sarà costruire sistemi che sanno:
- recuperare informazioni corrette;
- ragionare su relazioni;
- usare strumenti;
- coordinare agenti;
- ricordare decisioni;
- verificare fonti;
- aggiornare conoscenza nel tempo.
Gli LLM hanno aperto la porta.
Il prompt engineering ha insegnato a controllarli.
Gli agenti li stanno trasformando in operatori.
I grafi li renderanno sistemi capaci di lavorare con memoria, struttura e contesto condiviso.
Se vuoi costruire AI che funziona davvero, non partire dalla domanda “quale modello uso?”.
Parti da una domanda più importante:
quale conoscenza deve organizzare il mio sistema per agire in modo affidabile?
La risposta, sempre più spesso, sarà un grafo.