Un sistema AI che funzioni davvero: memoria, ragionamento, azioni e misurazione
Ho visto apparire una fattura da 200$ su un account AWS durante la notte.
Non perché il sistema sia andato in crash.
Un agente ha girato in loop per sei ore senza condizioni di arresto, chiamando l'API di OpenAI a ogni iterazione.
Ogni dashboard di monitoraggio diceva che tutto andava bene.
Nessuno se n'è accorto fino all'arrivo della fattura il mattino dopo.
Ecco cosa succede quando costruisci sistemi AI senza capire come funzionano davvero.
La maggior parte delle persone impara l'ingegneria AI al contrario.
Installa una libreria. Segue un tutorial. Chiama un'API. Ottiene qualcosa che funziona. Sembra un progresso.
Poi qualcosa si rompe in un modo che non ha senso.
Cambiano numeri a caso finché non si ferma.
Non è ingegneria. È speranza con una tastiera.
Ecco i 6 concetti che risolvono tutto questo.
La frase che spiega tutto in una riga
Ogni sistema AI, non importa quanto complesso, è solo:
Memoria (RAG) + Ragionamento (LLM + Token) + Azioni (Agenti) + Misurazione (Eval)
…assemblati attraverso Context Engineering.
Questo è l'intero campo.
Tutto ciò che segue è solo spiegare cosa significa realmente ogni parte.
1. Token e Finestra di Contesto
Gli LLM non leggono parole. Leggono blocchi chiamati token.
"ingegneria" → 1 token
"incredibile" → 2 token Anche spazi e punteggiatura contano.
Ogni modello ha una finestra di contesto — un limite massimo di token che può contenere contemporaneamente.
→ Claude: 200.000 token
→ GPT-5: 400.000 token
Pensala come una lavagna in una sala riunioni.
Il modello lavora solo con ciò che è attualmente sulla lavagna.
Quando la lavagna si riempie, le vecchie note vengono cancellate per fare spazio.
Il modello non perde la capacità di pensare.
Perde l'accesso alle informazioni precedenti.
Perché rompe i sistemi in produzione:
→ I token costano denaro — ogni chiamata API fattura per token di input e output
→ Le cronologie chat lunghe riempiono velocemente la finestra
→ Quando il contesto si riempie, le istruzioni precedenti vengono silenziosamente eliminate
→ Cosa entra nel contesto è una decisione ingegneristica, non un'impostazione predefinita
Il fallimento che lo dimostra:
Un team ha costruito un agente di supporto clienti con l'intera cronologia chat di 12 mesi come contesto per ogni richiesta.
Funzionava perfettamente nei test con 5 interazioni.
In produzione, dopo 50 interazioni, l'agente ha iniziato a ignorare il proprio system prompt.
Le istruzioni erano ancora lì.
Erano sepolte sotto 80.000 token di cronologia conversazione.
Il modello aveva effettivamente smesso di prestarvi attenzione.
La soluzione non è stata un modello migliore.
È stato riassumere la cronologia più vecchia per mantenere la finestra focalizzata.
La verità scomoda:
La maggior parte dei "fallimenti del prompt engineering" sono in realtà fallimenti di token e finestra di contesto mascherati.
Gli ingegneri incolpano il prompt quando il vero problema è che l'istruzione critica è alla riga 3 di un contesto di 500 righe, e il modello ha smesso di darle peso.
2. Embedding e Ricerca Vettoriale
Gli embedding trasformano il significato in numeri in modo che la "similarità" possa essere calcolata matematicamente.
Il problema che risolvono:
Hai 50.000 documenti. Un utente fa una domanda. Hai bisogno dei 3 più rilevanti — senza leggere tutti i 50.000 ogni volta.
La ricerca per parole chiave fallisce qui.
Se il documento dice "automobile" e l'utente chiede "macchine", la ricerca per parole chiave non li trova.
Non perché la risposta non sia lì. Perché le parole non corrispondevano.
Gli embedding risolvono questo diversamente.
Un modello di embedding converte il testo in un vettore — un elenco di numeri che rappresentano il significato in uno spazio matematico.
Testo semanticamente simile → vettori numericamente simili.
"auto" e "automobile" → vicini
"auto" e "fotosintesi" → lontani
Come funziona realmente la ricerca vettoriale:
- Ogni documento viene convertito in un vettore e memorizzato
- La domanda dell'utente diventa anch'essa un vettore
- Il sistema trova i vettori memorizzati più vicini al vettore della domanda
- Quelli sono i tuoi documenti più rilevanti
Non è magia approssimativa. È geometria.
La similarità è una proprietà matematica reale che puoi calcolare.
Dove si manifesta in produzione:
→ Ricerca semantica in qualsiasi sistema documentale
→ Trovare prodotti, articoli, profili utente simili
→ Il passo di recupero in RAG (prossimo concetto)
→ Memoria negli agenti AI
3. RAG (Retrieval-Augmented Generation)
Invece di addestrare un modello sui tuoi dati, recuperi i dati rilevanti al momento della query e li fornisci al modello come contesto.
Il problema che RAG risolve:
Gli LLM sanno molte cose. Non sanno i tuoi dati.
I documenti interni della tua azienda. Il tuo database prodotti. La tua cronologia di supporto clienti.
Niente di tutto ciò era nel set di addestramento.
Due opzioni: addestrare un modello sui tuoi dati (costoso, lento, diventa obsoleto all'istante) o dare al modello i tuoi dati esattamente quando ne ha bisogno.
RAG è la seconda opzione, fatta sistematicamente.
Il pipeline in 3 passaggi:
→ RECUPERA:
la domanda diventa un vettore → il database vettoriale trova i documenti memorizzati più simili → recuperati i primi 3-5 chunk
→ AUMENTA:
i documenti recuperati vengono aggiunti al contesto del modello → il prompt diventa "usando questo contesto, rispondi a questa domanda"
→ GENERA:
il modello risponde basandosi sui tuoi dati reali — non allucinati
Dove RAG fallisce:
→ Recupero scadente = risposta scadente. Il modello può lavorare solo con ciò che riceve
→ Una suddivisione in chunk inadeguata separa la risposta dal suo contesto
→ Il modello può ancora allucinare se il recupero non trova nulla di utile
Un vero fallimento di RAG:
Un team ha costruito un assistente di conoscenza interna per un manuale tecnico di 500 pagine.
Funzionava perfettamente nelle demo. In produzione, le risposte erano vaghe e talvolta errate.
Il problema: la dimensione dei chunk.
Avevano diviso il manuale in chunk da 1.000 token basati sul conteggio grezzo dei caratteri.
Le tabelle si spezzavano a metà riga. Le istruzioni passo-passo si spezzavano a metà.
Il recupero trovava l'area generale giusta — ma mancava la risposta effettiva.
Dimezzare la dimensione del chunk e aggiungere sovrapposizione ha risolto l'80% dei problemi in una notte.
L'opinione schietta:
RAG è sopravvalutato quando il tuo recupero è scadente.
L'LLM non può riparare un recupero scadente. Può solo allucinare attorno ad esso.
Se vedi risposte errate, smetti di modificare il prompt.
Inizia a misurare la precisione del tuo recupero.
È lì che si trova la risposta.
4. Il Loop Agentico
Gli agenti funzionano scegliendo ripetutamente un'azione, eseguendola, osservando il risultato e decidendo cosa fare dopo — fino al completamento dell'attività.
Una normale chiamata LLM è stateless. Chiedi, risponde, fine.
Un agente è stateful. Agisce, osserva, decide, ripete.
Il loop in parole semplici:
- Riceve un obiettivo
- Decide la prossima azione
- La esegue — cerca, scrive codice, legge un file
- Osserva il risultato
- Decide la prossima azione in base a ciò che ha imparato
- Ripete fino al completamento dell'obiettivo
- Restituisce la risposta finale
Gli strumenti sono ciò che dà potere agli agenti.
Senza strumenti, un LLM risponde solo con testo.
Con gli strumenti, può cercare sul web, leggere file, scrivere codice, chiamare API, attivare qualsiasi azione tu definisca.
Tre cose che i principianti sbagliano sempre:
→ Gli agenti senza condizioni di arresto girano per sempre. Devi definire quando fermarsi — limite di passi, limite di tempo o condizione di obiettivo
→ Più strumenti ≠ prestazioni migliori. Troppi strumenti confondono il modello su quale usare
→ Gli errori degli strumenti richiedono una gestione esplicita. Un fallimento silenzioso fa sì che l'agente produca con sicurezza spazzatura
Il fallimento da 200$ in una notte, nei dettagli:
L'agente non aveva un numero massimo di passi. Il suo obiettivo: ricercare un argomento e produrre un riassunto.
Uno dei suoi strumenti di ricerca web ha restituito un risultato vuoto.
L'agente non sapeva come fermarsi.
Continuava a cercare, riprovare, generare riassunti intermedi — ognuno innescando un'altra ricerca.
Sei ore dopo: 847 chiamate LLM. 2,1 milioni di token consumati. Un riassunto dall'aspetto coerente ma completamente circolare. Una fattura da 200$.
La soluzione è stata tre righe: un contatore massimo di passi, un gestore esplicito per risultati vuoti, un percorso di escalation quando la confidenza era bassa.
Lo stesso agente ora completa in meno di 12 chiamate in media.
L'opinione che devi sentire:
La maggior parte degli agenti fallisce non perché il modello sia scadente — ma perché gli ingegneri trattano il loop come se fosse autogestito.
Non lo è.
Barriere di protezione, condizioni di arresto, gestori di errori — costruiti dall'inizio, non aggiunti dopo il primo incidente.
5. Eval (Valutazione)
Gli eval sono come sai se il tuo sistema AI sta effettivamente funzionando — e se una modifica lo ha migliorato o peggiorato.
Questo è il concetto che la maggior parte dei tutorial salta perché non è affascinante.
È anche ciò che separa gli ingegneri che costruiscono demo dagli ingegneri che costruiscono sistemi in produzione.
Il problema senza eval:
Modifichi il tuo prompt. Aggiorni la logica di recupero. Passi a un modello più recente.
È migliorato?
Non lo sai. Potresti controllare manualmente alcuni esempi — ma è una sensazione, non una prova.
Come sono fatti realmente gli eval:
→ Un dataset aureo: 25-50 input reali con output corretti noti, che coprono i casi d'uso principali più 5 casi limite difficili noti
→ Metriche binarie dove possibile:
— Il sistema RAG ha recuperato il documento corretto? Sì/No
— L'agente ha completato senza errori? Sì/No
— La risposta conteneva le informazioni richieste? Sì/No
→ Punteggi aggregati tracciati nel tempo:
— Precisione recupero: 89% → modifica apportata → 84%. Regressione trovata.
— Tasso di completamento attività: 76% → nuova versione agente → 81%. Miglioramento confermato.
Il ciclo di eval:
Distribuisci → Misura con eval → Trova fallimenti → Aggiungi fallimenti al dataset aureo → Risolvi → Esegui eval di nuovo → Confronta punteggi → Rilascia solo se i numeri sono migliorati
La verità onesta:
"Utilità: 3,7/5" non ti dice nulla di utilizzabile.
"Documento corretto recuperato: l'84% delle volte" ti dice esattamente dove si trova il problema e quanto una soluzione lo ha migliorato.
Un sistema AI senza eval non è un prodotto.
È una demo che non puoi modificare con fiducia.
6. Context Engineering
La disciplina di decidere esattamente quali informazioni entrano nella finestra di contesto del modello, come sono strutturate e cosa viene escluso.
Ecco l'opinione che mette a disagio le persone:
Il Context Engineering conta più del prompt engineering.
Un prompt mediocre in un contesto ben curato supera un prompt brillante sepolto nel rumore — ogni singola volta.
La maggior parte dei team spende l'80% del loro sforzo di ottimizzazione sul prompt e quasi nulla sul contesto.
I risultati lo riflettono.
L'approccio ingenuo fallisce:
Includi tutto. Tutta la cronologia. Tutti i documenti recuperati. Ogni descrizione di strumento. Il system prompt. Il messaggio utente. Tutto quanto.
Questo fallisce per una ragione coerente: il modello si confonde su cosa conta di più.
C'è un effetto documentato chiamato "perso nel mezzo" — le informazioni sepolte in profondità in un contesto lungo hanno meno probabilità di essere utilizzate.
Cosa implica realmente il Context Engineering:
→ Selezione: quali documenti, fatti o cronologia servono a questa decisione specifica?
→ Compressione: le parti più vecchie della conversazione possono essere riassunte per risparmiare token?
→ Ordinamento: le istruzioni critiche vanno all'inizio e alla fine — non nel mezzo
→ Potatura: cosa può essere rimosso senza influenzare la qualità dell'output?
→ Struttura: intestazioni, separatori, sezioni etichettate influenzano quanto affidabilmente il modello usa le informazioni
Un esempio pratico:
Un agente è in esecuzione da 45 minuti. Ha accumulato 80.000 token di cronologia conversazione. La sua finestra è di 128.000.
Non vuoi perdere l'obiettivo e i vincoli originali, anche mentre la cronologia riempie la finestra.
Context Engineering: comprimere output di strumenti più vecchi, riassumere ragionamenti precedenti, mantenere la definizione dell'attività prominente per tutta la sessione.
Il prompt engineering è scrivere buone istruzioni.
Il Context Engineering è costruire l'ambiente in cui quelle istruzioni vengono effettivamente seguite.
Come questi 6 concetti formano un unico sistema
MEMORIA → RAG + Embedding (cosa sa il sistema)
RAGIONAMENTO → LLM + Token + Finestra di Contesto (come ragiona con ciò che sa)
AZIONI → Loop Agentico + Strumenti (cosa può fare nel mondo)
MISURAZIONE → Eval (come sai che funziona)
COLLANTE → Context Engineering (cosa decide cosa fluisce tra tutto quanto sopra)
Un semplice chatbot è solo Ragionamento.
Un agente di supporto clienti è Memoria + Ragionamento + Azioni.
Un sistema di produzione affidabile aggiunge Misurazione.
La sofisticatezza sta in quanto bene sono collegati i pezzi.
Il flusso per ogni singola richiesta:
Domanda utente
→ Context Engineering decide cosa includere
→ Embedding recuperano la Memoria rilevante (RAG)
→ Token determinano quanto spazio c'è nella finestra
→ LLM ragiona sul contesto assemblato
→ Loop Agentico decide se sono necessarie più informazioni
→ Eval misurano se l'output era effettivamente corretto
Da dove iniziare
Non devi padroneggiare tutti e sei contemporaneamente.
→ Inizia con token e finestre di contesto — influenzano tutto ciò che costruisci → Aggiungi embedding quando hai bisogno di ricerca semantica o memoria
→ Impara RAG quando devi radicare un modello nei tuoi dati
→ Impara il loop agentico quando hai bisogno di automazione
→ Aggiungi eval prima di distribuire qualsiasi cosa in produzione
→ Applica Context Engineering quando tutto il resto diventa intuitivo
Quella sequenza non è arbitraria.
Ogni concetto rende il successivo apprendibile.
La considerazione finale onesta
La maggior parte dei team che fatica con l'AI in produzione non sta lottando con il modello sbagliato o la libreria sbagliata.
Stanno lottando perché hanno saltato uno di questi sei concetti.
L'agente va in loop per sempre perché nessuno ha pensato alle condizioni di arresto.
Le risposte RAG sono sbagliate perché nessuno ha misurato il recupero.
Il prompt smette di funzionare nelle sessioni lunghe perché nessuno ha capito come si riempie la finestra di contesto.
Non sono problemi sofisticati.
Sono problemi di base, travestiti da vocabolario tecnico.
Gli strumenti cambiano ogni sei mesi.
Questi sei concetti sono come funzionano gli strumenti.
Impara i concetti, e non sarai mai confuso da un nuovo strumento.
Più importante — non spenderai mai 200$ a guardare un agente in loop tutta la notte, chiedendoti cosa sia andato storto.
Se questo è stato utile:
→ Ripubblica per condividerlo con ogni ingegnere AI che conosci
→ Segui @sairahul1 per altri sistemi e analisi come questa
→ Aggiungi ai segnalibri — lo consulterai la prossima volta che qualcosa si rompe in produzione
Scrivo di AI, costruzione di prodotti e sistemi che funzionano mentre dormi.
