Context engineering: oltre il prompt, come dare all’AI le informazioni giuste
Il context engineering sposta l’attenzione dalla singola formula del prompt all’intero ambiente informativo disponibile per il modello. Istruzioni, dati, esempi, memoria, strumenti e cronologia devono essere selezionati e mantenuti come parti di un unico sistema.
Una risposta debole non dipende sempre dal modello o dalle parole usate nella domanda. Spesso il problema è che l’AI riceve informazioni incomplete, ridondanti, obsolete o prive di una gerarchia chiara.
Che cos’è il context engineering
Il context engineering comprende le strategie con cui si decide quali informazioni entrano nella finestra di contesto, in quale forma e in quale momento. L’obiettivo è massimizzare l’utilità dei token disponibili per produrre un comportamento coerente.
Nella guida Effective context engineering for AI agents, Anthropic lo descrive come l’evoluzione naturale del prompt engineering: non soltanto scrivere istruzioni, ma curare tutto lo stato che il modello riceve durante l’inferenza.
Context engineering e prompt engineering
Il prompt engineering lavora principalmente su formulazione, struttura e chiarezza delle istruzioni. Il context engineering include il prompt, ma considera anche:
- messaggi precedenti e stato della conversazione;
- documenti recuperati da una base di conoscenza;
- esempi del comportamento desiderato;
- descrizioni e risultati degli strumenti;
- memoria persistente;
- vincoli, ruoli e autorizzazioni;
- formato dell’output e criteri di verifica.
Il prompt può essere corretto e produrre comunque un risultato scarso se il contesto contiene versioni contraddittorie di una regola o grandi quantità di materiale irrilevante.
Il contesto è una risorsa finita
Una finestra più ampia permette di includere più token, ma non rende ogni informazione ugualmente disponibile all’attenzione del modello. All’aumentare del volume possono comparire perdita di precisione, confusione tra istruzioni e difficoltà nel recuperare dettagli.
La guida di Anthropic utilizza il concetto di attention budget: ogni nuovo elemento consuma parte della capacità con cui il modello mette in relazione i contenuti. La regola operativa diventa quindi cercare il set minimo di token ad alto segnale che consenta di ottenere il risultato.
“Minimo” non significa necessariamente breve. Significa privo di materiale che non contribuisce alla decisione o che può essere recuperato soltanto quando serve.
L’anatomia di un buon contesto
Istruzioni di sistema
Devono definire obiettivo, ruolo, confini e criteri di successo a un livello adeguato. Regole eccessivamente dettagliate possono diventare fragili; indicazioni troppo generiche lasciano ambiguità. Sezioni chiare aiutano a distinguere background, istruzioni, uso degli strumenti e output.
Dati e fonti
Ogni fonte dovrebbe avere provenienza, data, perimetro e livello di fiducia. È preferibile fornire porzioni pertinenti con riferimenti verificabili, evitando di riversare interi archivi nella richiesta.
Esempi
Pochi esempi diversi e canonici comunicano meglio il comportamento atteso di una lunga lista di eccezioni. Devono mostrare casi normali, limiti e formato della risposta senza introdurre regole contraddittorie.
Strumenti
Descrizioni e parametri devono essere specifici. Strumenti sovrapposti o risultati troppo verbosi aumentano incertezza e consumo. Ogni chiamata dovrebbe restituire il minimo necessario per la decisione successiva.
Cronologia e memoria
La conversazione conserva decisioni e preferenze, ma accumula anche tentativi falliti e output non più utili. Bisogna distinguere lo stato operativo da mantenere dal dettaglio che può essere sintetizzato o rimosso.
Precaricare tutto o recuperare just in time
Un approccio tradizionale recupera i documenti prima di chiamare il modello. È rapido quando la ricerca è prevedibile e il materiale è limitato. Nei compiti complessi, però, il modello può aver bisogno di esplorare progressivamente.
Il recupero just in time mantiene nel contesto riferimenti leggeri — percorsi, identificatori, link o query salvate — e carica il contenuto soltanto quando diventa rilevante. L’agente può quindi restringere il problema attraverso più passaggi.
L’approccio ibrido è spesso il più efficace: regole e dati essenziali vengono forniti subito; gli approfondimenti vengono recuperati tramite strumenti. La scelta dipende da latenza, costo, dinamismo delle fonti e rischio dell’attività.
Progettare strumenti che proteggono il contesto
Un tool non è soltanto una funzione: è un contratto informativo tra modello e sistema. Per ridurre rumore e ambiguità dovrebbe avere:
- nome e descrizione inequivocabili;
- parametri con significato preciso;
- scopo distinto dagli altri strumenti;
- errori utili per correggere l’azione;
- risultati sintetici e strutturati;
- paginazione o filtri per grandi volumi;
- autorizzazioni limitate al compito.
Il Model Context Protocol può standardizzare il collegamento con dati e strumenti, ma non decide quali informazioni siano pertinenti né sostituisce i controlli di accesso.
Gestire attività lunghe: compaction e note
Quando una sessione supera la finestra disponibile, continuare ad accumulare cronologia non è possibile. Tre pattern aiutano a preservare coerenza:
- Compaction: riassumere decisioni, stato, problemi aperti e dettagli indispensabili, eliminando ripetizioni e vecchi output degli strumenti.
- Note strutturate: conservare fuori dal contesto obiettivi, attività completate, dipendenze e prossimi passi, richiamandoli quando servono.
- Suddivisione del lavoro: assegnare sottoattività con contesti puliti e restituire al coordinatore soltanto risultati sintetici.
La sintesi va valutata: una compressione troppo aggressiva può perdere una condizione che diventa importante nelle fasi successive.
Un canvas pratico del contesto
Prima di costruire un workflow, è utile compilare una tabella con sei colonne:
- Elemento: istruzione, dato, esempio, memoria o strumento;
- scopo: quale decisione abilita;
- fonte: da dove proviene e chi la aggiorna;
- priorità: obbligatorio, utile o recuperabile;
- durata: valido per la richiesta, la sessione o più sessioni;
- budget: quantità massima di token o risultati.
Se un elemento non ha uno scopo chiaro, dovrebbe essere escluso o reso disponibile su richiesta.
Sicurezza: il contesto non è automaticamente affidabile
Documenti, pagine web e risultati degli strumenti possono contenere errori o istruzioni ostili. Contenuto e comandi devono essere separati, con provenienza visibile e autorizzazioni applicate fuori dal modello.
L’articolo sulla prompt injection approfondisce i controlli per RAG, agenti e tool calling. Aggiungere più contesto senza verificarne la fiducia può ampliare la superficie di attacco.
Come misurare la qualità del contesto
Un test deve mantenere fisso il compito e confrontare diverse configurazioni. Le metriche utili includono:
- accuratezza e completezza del risultato;
- uso corretto delle fonti;
- tasso di scelta dello strumento appropriato;
- numero di chiamate e iterazioni;
- token totali, latenza e costo;
- necessità di correzione umana;
- robustezza a dati mancanti o contraddittori.
È utile partire da una configurazione minima e aggiungere un componente alla volta. In questo modo si identifica quale informazione produce un miglioramento reale.
Errori frequenti
- Inserire interi archivi “per sicurezza”;
- ripetere la stessa regola in più punti;
- conservare output degli strumenti già superati;
- mescolare istruzioni e documenti esterni;
- offrire troppi strumenti simili;
- usare esempi numerosi ma poco rappresentativi;
- trattare la memoria come cronologia completa;
- misurare soltanto il limite massimo di token.
Domande frequenti
Il context engineering sostituisce il prompt engineering?
No. La progettazione del prompt resta una componente del contesto. Il nuovo approccio amplia il lavoro a dati, memoria, strumenti e gestione dinamica dello stato.
Una finestra di contesto più grande risolve il problema?
Non completamente. Può ospitare più materiale, ma pertinenza, aggiornamento e gerarchia restano essenziali. Più token non garantiscono maggiore attenzione.
RAG e context engineering sono la stessa cosa?
No. Il RAG è una tecnica di recupero. Il context engineering decide quando usarla, quali risultati includere e come combinarli con istruzioni, memoria e strumenti.
Come si gestisce il contesto di un agente?
Con informazioni essenziali iniziali, recupero progressivo, risultati degli strumenti sintetici, note strutturate e compaction quando la cronologia cresce.
Oltre il prompt perfetto
Il context engineering sostituisce la ricerca della formula magica con una disciplina di sistema. La qualità dipende da ciò che il modello vede, da ciò che può recuperare e da ciò che viene escluso. Curare il contesto significa proteggere l’attenzione, rendere le fonti verificabili e fornire informazioni utili nel momento in cui servono.