Che cos'è l'ingegneria del contesto? Ciò che il modello riceve prima di rispondere

L'ingegneria del contesto è la progettazione di quali informazioni un modello linguistico riceve al momento dell'inferenza, in quale forma, in quale ordine e per quanto tempo. È più ampia dell'ingegneria dei prompt perché il contesto del modello può includere istruzioni di sistema, messaggi dell'utente, documenti recuperati, risultati di strumenti, memoria, stato corrente dell'applicazione, esempi, dati strutturati e artefatti intermedi. L'obiettivo non è massimizzare il numero di token, ma costruire il più piccolo contesto utile che preservi le informazioni, i vincoli e le prove necessarie per l'attività corrente.

Cosa significa realmente ingegneria del contesto

Ogni chiamata al modello avviene in un ambiente di lavoro temporaneo: le istruzioni correnti, i messaggi, le prove recuperate, gli output degli strumenti e lo stato che rientrano nella finestra di contesto attiva. L'ingegneria del contesto è la disciplina di costruire deliberatamente quell'ambiente.

La parola chiave è deliberatamente. Un sistema ingenuo concatena semplicemente tutto ciò che ha: cronologia completa, tutti i documenti recuperati, ogni risposta degli strumenti e grandi prompt di sistema. Un sistema progettato con ingegneria del contesto decide quali informazioni sono necessarie per la decisione corrente e quali dovrebbero rimanere fuori dalla finestra fino a quando non servono.

Questo rende l'ingegneria del contesto in parte un problema di architettura dell'informazione, in parte un problema di runtime e in parte un problema di valutazione. La progettazione deve decidere cosa può entrare nel contesto, da dove proviene, quale versione è corrente, come vengono risolti i conflitti, quanto dettaglio viene mantenuto e come viene testato il risultato.

L'esempio più semplice

Immagina un assistente di supporto interno. Un utente chiede: "Questo cliente può cancellare senza penale?"

Il modello potrebbe aver bisogno di cinque cose: la politica di cancellazione corrente, il tipo di contratto corrente del cliente, la data effettiva del contratto, le regole di eccezione pertinenti e l'ambito di autorizzazione dell'utente.

Non ha necessariamente bisogno dell'intero database dei clienti, dell'intero archivio delle politiche, di ogni conversazione precedente o di ogni ticket di supporto. L'ingegneria del contesto è il processo che seleziona e assembla i cinque pezzi utili escludendo le informazioni non pertinenti.

Dove si ferma l'esempio semplice

I sistemi reali sono più difficili perché le informazioni necessarie per un passaggio potrebbero non essere note prima dell'inizio dell'esecuzione. Un agente può scoprire nuovi fatti tramite strumenti, creare file intermedi, ricevere uno stato esterno mutevole o estendersi su un'attività più lunga di una finestra di contesto.

L'ingegneria del contesto diventa quindi dinamica. Il contesto per il passaggio 12 non dovrebbe essere semplicemente il contesto del passaggio 1 più undici strati di output accumulato. Dovrebbe riflettere lo stato corrente dell'attività, le decisioni che contano ancora e le prove necessarie per l'azione successiva.

Cosa può entrare in un contesto del modello?

Context engineering vs prompt engineering

Anthropic descrive esplicitamente il context engineering come la naturale evoluzione del prompt engineering per i sistemi in cui il modello deve lavorare con strumenti, dati esterni, cronologia dei messaggi e stato di agenti a esecuzione prolungata. La distinzione pratica è utile perché un prompt scritto perfettamente non può compensare dati autorevoli mancanti o un contesto inquinato da uno stato contraddittorio.

Context engineering vs retrieval

Il retrieval seleziona informazioni candidate da un corpus o da una fonte esterna. Il context engineering decide cosa accade dopo e attorno a quel retrieval.

Il retriever può restituire 30 passaggi. Un reranker può ridurli a 10. Il livello di contesto può selezionare quattro passaggi, rimuovere i duplicati, allegare metadati di fonte/versione, combinarli con lo stato corrente dell'applicazione e posizionarli dopo le istruzioni di sistema.

Ecco perché un sistema RAG può recuperare il passaggio corretto e rispondere comunque male: l'errore può verificarsi durante l'assemblaggio del contesto anziché nel retrieval.

Context engineering vs memoria

La memoria è l'informazione conservata al di fuori dell'invocazione immediata del modello, così da poter essere riutilizzata in seguito. Il contesto è l'informazione effettivamente caricata nell'invocazione corrente.

Un sistema di memoria può contenere migliaia di fatti, note o decisioni precedenti. Il context engineering seleziona quali di essi devono essere reintrodotti per il compito corrente. Caricare tutta la memoria a ogni turno vanifica lo scopo di avere un livello di memoria esterno.

La distinzione diventa cruciale per lo stato volatile. Uno stato di progetto o una preferenza utente ricordati possono essere utili, ma lo stato autorevole corrente potrebbe dover essere riletto prima di una decisione consequenziale.

Context engineering vs stato dell'applicazione

Lo stato dell'applicazione è la condizione corrente del sistema esterno: saldo del conto, stato del ticket, versione del file, fase del flusso di lavoro, stato del deployment o avanzamento del compito.

Lo stato può essere riassunto nel contesto, ma il riassunto non è lo stato stesso. Per operazioni consequenziali, il runtime potrebbe dover rileggere il sistema autorevole immediatamente prima dell'azione anziché fidarsi di un'istantanea precedente visibile al modello.

La progettazione degli strumenti fa parte dell'ingegneria del contesto

Gli strumenti fanno più che fornire capacità agli agenti. I nomi, le descrizioni, gli schemi e i risultati degli strumenti diventano informazioni visibili al modello che ne plasmano le decisioni.

Le attuali linee guida di Anthropic sull'ingegneria del contesto enfatizzano strumenti efficienti in termini di token e mettono in guardia contro set di strumenti sovradimensionati con funzionalità sovrapposte. Un catalogo di strumenti difficile da distinguere per un essere umano è anche difficile da instradare in modo affidabile per un modello.

Anche gli output degli strumenti necessitano di disciplina del contesto. Restituire un intero log di 20.000 righe quando l'agente ha richiesto una singola condizione di errore consuma attenzione e può seppellire la prova decisiva.

Contesto just-in-time vs contesto precaricato

Anthropic descrive un modello ibrido in cui parte del contesto stabile viene precaricato mentre gli agenti recuperano informazioni aggiuntive a runtime. Questo è un utile modello architetturale perché non ogni fatto importante merita una residenza permanente nella finestra di contesto.

Il contesto è un budget, non un sistema di archiviazione

Una finestra di contesto definisce la capacità. Non garantisce che ogni token venga utilizzato ugualmente bene. Il modello deve distribuire l'attenzione tra istruzioni, cronologia, prove, strumenti e stato intermedio.

L'obiettivo pratico quindi non è "riempire la finestra". È massimizzare l'utilità del budget di attenzione limitato.

Anthropic formula un principio simile come trovare il più piccolo insieme di token ad alto segnale che massimizza la probabilità del comportamento desiderato. Anche le linee guida di OpenAI sulla gestione del contesto avvertono che una cronologia non curata, risultati di strumenti ridondanti e un recupero rumoroso possono sopraffare anche finestre di grandi dimensioni.

Perché più contesto può essere peggio

Contesto aggiuntivo può introdurre informazioni irrilevanti, stato obsoleto, prove duplicate, istruzioni contraddittorie o competizione posizionale. Può anche causare sistemi di compattazione che scartano dettagli che diventano importanti in seguito.

Il classico studio Lost in the Middle ha dimostrato che i modelli a contesto lungo possono utilizzare le informazioni in modo diverso a seconda di dove appare il contenuto rilevante, con prestazioni che spesso peggiorano quando le informazioni decisive sono posizionate al centro di input lunghi.

Questo non significa che il contesto lungo sia intrinsecamente negativo. Significa che la disponibilità all'interno della finestra non è la stessa cosa di un utilizzo affidabile.

L'ordinamento del contesto dovrebbe essere intenzionale

La costruzione del contesto è anche un problema di ordinamento. Istruzioni critiche, stato corrente, prove decisive e vincoli specifici del compito non dovrebbero essere concatenati arbitrariamente.

Non esiste un ordinamento perfetto universale per ogni modello e compito. L'architettura dovrebbe quindi verificare se riordinare le prove cambia la correttezza e se le informazioni importanti rimangono robuste attraverso variazioni realistiche del contesto.

Una risposta stabile che cambia drasticamente quando due passaggi ugualmente validi si scambiano di posizione indica una sensibilità al contesto che dovrebbe essere misurata anziché ignorata.

Il contesto in conflitto richiede una precedenza esplicita

Un modello può ricevere una vecchia policy e una nuova policy, una preferenza memorizzata e un'istruzione esplicita corrente, oppure uno stato in cache e un risultato API in tempo reale. Il sistema non dovrebbe aspettarsi che il modello inferisca la precedenza dallo stile del testo.

L'ingegneria del contesto dovrebbe codificare la precedenza attraverso la selezione delle fonti, i metadati, l'ordinamento o istruzioni esplicite: lo stato autoritativo corrente prevale sulle copie obsolete; un'istruzione esplicita corrente dell'utente prevale su una preferenza inferita precedente; una policy approvata sostituisce le bozze superate.

La compattazione è trasformazione del contesto, non archiviazione senza perdita

I sistemi a esecuzione prolungata alla fine devono ridurre, riassumere o compattare la cronologia. La compattazione crea una nuova rappresentazione del contesto precedente, così l'agente può continuare senza riprodurre ogni token.

Gli esempi di gestione del contesto di OpenAI usano il trimming e la compressione per sessioni a esecuzione prolungata. Anthropic descrive la compattazione come una tecnica primaria per mantenere la coerenza quando un'interazione si avvicina al limite del contesto.

La parte difficile è decidere cosa non può essere rimosso in sicurezza: attività irrisolte, identificatori, vincoli dell'utente, confini di sicurezza, decisioni architetturali, eccezioni, provenienza delle fonti e le condizioni che rendono valida una conclusione precedente.

Preserva i confini di validità

Le conclusioni importanti dovrebbero portare con sé le condizioni alle quali restano supportate: versione, data, ambito, assunzioni, autorità della fonte e disaccordo irrisolto.

L'ingegneria del contesto è quindi collegata all'Answer Validity Boundary. L'assemblatore del contesto non dovrebbe rimuovere i metadati che determinano se le prove sono ancora applicabili.

L'ingegneria del contesto è anche un confine di sicurezza

I dati che raggiungono il modello hanno attraversato un confine di sistema importante. L'assemblaggio del contesto deve quindi rispettare l'autorizzazione, l'isolamento dei tenant, la riservatezza e le regole di minimizzazione dei dati.

Un retriever può tecnicamente trovare un passaggio a cui l'utente corrente non può accedere. Il design corretto è impedire che quel passaggio entri nel contesto del modello, anziché affidarsi al modello per ignorarlo.

Anche gli output degli strumenti possono contenere istruzioni non attendibili o contenuti ostili. L'ingegneria del contesto dovrebbe preservare la distinzione tra istruzioni dell'applicazione e dati esterni, così il testo recuperato non può acquisire silenziosamente autorità di istruzione.

Un'architettura pratica di context engineering

L'assemblatore di contesto è concettualmente importante anche quando nessun modulo ha esattamente quel nome. In una piccola applicazione può essere normale codice applicativo. In una grande piattaforma di agenti può combinare gestione della sessione, retrieval, memoria, middleware dei tool, compattazione e applicazione delle policy.

Una policy pratica di costruzione del contesto

Come valutare il context engineering

L'assemblaggio del contesto è un livello di fallimento RAG distinto

Una pipeline RAG può avere successo nel retrieval e fallire comunque a valle. La fonte rilevante può comparire al rango 2, ma l'assemblatore di contesto può scartarla, troncarla, combinarla con materiale contraddittorio obsoleto o superare il budget di token.

Ecco perché le tracce di retrieval dovrebbero essere confrontate con il contesto effettivo inviato al modello. Senza quel confronto, i fallimenti di contesto vengono facilmente diagnosticati erroneamente come fallimenti di embedding o del modello.

Evidenza di implementazione originale

Source of Truth Research Engine: ricerca limitata invece di contesto illimitato

Il Source of Truth Research Engine separa scoperta, acquisizione, estrazione, verifica, analisi delle contraddizioni e sintesi in fasi di ricerca limitate, invece di inviare un unico enorme task di ricerca e tutto il materiale accumulato in una singola chiamata al modello.

Il suo modello di evidenza memorizza Sources, Artifacts, Claims, Relations, Contradictions e provenienza fuori dal contesto del modello. Il modello può ricevere il sottoinsieme necessario per la fase di ricerca corrente mentre l'evidenza durevole rimane nell'archivio esterno.

Questo è un pattern concreto di context engineering: lo stato di ricerca durevole vive fuori dalla finestra del modello; il contesto attivo del modello viene ricostruito per la fase corrente.

Aaasaasa AI Client: runtime, permessi e contesto sono preoccupazioni separate

Aaasaasa AI Client separa la selezione di provider/modello, la posizione di runtime, i permessi del workspace, le risorse locali e l'accesso agli strumenti. Questo impedisce che il contesto del modello diventi il proprietario dell'autorizzazione o dello stato dell'applicazione.

Direct Chat e i runtime agentici possono avere capacità di strumenti diverse. I profili di permesso del workspace sono applicati dal runtime anziché essere semplicemente descritti nel contesto in linguaggio naturale. Questa distinzione è importante: il contesto può dire a un modello cosa dovrebbe fare, mentre il runtime deve comunque applicare ciò che è effettivamente consentito fare.

L'evidenza implementativa qui è la separazione architetturale, non l'affermazione che ogni tecnica avanzata di gestione del contesto descritta in questo articolo sia già implementata.

Modalità di fallimento comuni nel context engineering

Idee sbagliate comuni

Una sequenza pratica di context engineering

Checklist di context engineering

Casi limite e limitazioni

Alcune attività sono abbastanza semplici che il context engineering si riduce a un breve prompt di sistema e a un singolo messaggio utente. Aggiungere recupero, memoria e compattazione introdurrebbe solo architettura non necessaria.

Alcune attività richiedono un alto richiamo e possono includere intenzionalmente più contesto prima della sintesi successiva. Ricerca, scoperta e revisione legale possono preferire l'evitamento dell'omissione rispetto al conteggio minimo di token.

Alcune informazioni non dovrebbero mai essere riassunte prima dell'uso. Contratti esatti, codice, materiale crittografico, registri numerici e testi normativi possono richiedere un recupero verbatim o strutturato dove la compressione potrebbe alterare il significato.

Il comportamento del contesto lungo varia sostanzialmente tra i modelli. Una strategia validata su un modello, una lunghezza di contesto o un harness di strumenti non dovrebbe essere trasferita automaticamente a un altro.

Il modello può comunque ignorare o interpretare male un contesto eccellente. L'ingegneria del contesto migliora l'ambiente informativo; non garantisce la correttezza del ragionamento.

Cosa cambierebbe questa risposta?

I modelli futuri potrebbero diventare più robusti ai contesti lunghi, agli effetti posizionali e alle informazioni contrastanti. Ciò potrebbe ridurre la quantità di curatela manuale necessaria.

La distinzione architetturale rimarrebbe comunque utile perché permessi, freschezza, persistenza della memoria, autorità della fonte e stato applicativo esterno esistono al di fuori del modello indipendentemente dalla dimensione della finestra di contesto.

L'equilibrio raccomandato tra contesto precaricato e contesto just-in-time cambia anche in base ai requisiti di latenza, all'affidabilità degli strumenti, alla dimensione del corpus, al costo del modello e a quanto sono dinamiche le informazioni sottostanti.

Conoscenza canonica correlata

L'ingegneria del contesto si colloca tra il recupero e la generazione. RAG spiega come viene recuperata la conoscenza esterna; R01 separa embedding, ricerca vettoriale e reranking; l'ingegneria del contesto spiega cosa raggiunge effettivamente il modello.

L'architettura Source-of-Truth risponde a una domanda diversa: non quali informazioni sono presenti nel contesto, ma quale fonte è autorizzata a stabilire un'affermazione.

L'articolo esistente Perché più contesto può peggiorare le risposte dell'IA è il complemento diagnostico a questa definizione canonica. Si concentra su inquinamento del contesto, effetti posizionali, crescita del top-k, perdita da compattazione e degrado delle risposte, piuttosto che ridefinire l'ingegneria del contesto stessa.

Domande frequenti

Glossario

Conclusione

L'ingegneria del contesto è lo strato che decide cosa il modello può vedere prima di rispondere. Questo la rende più ampia del prompting e a valle del recupero, pur rimanendo distinta dalla memoria durevole e dallo stato applicativo autorevole.

Una solida architettura del contesto non tratta la finestra di contesto come un database. Mantiene stato e conoscenza durevoli al di fuori del modello, carica ciò che è necessario per la decisione corrente, preserva autorità e provenienza, rimuove il rumore non necessario e aggiorna le informazioni volatili quando necessario.

L'obiettivo pratico non è quindi il contesto massimo. È il contesto minimo sufficiente, ad alto segnale, correttamente autorizzato e che preserva la validità per la prossima decisione del modello.

Fonti primarie e linee guida attuali

Le fonti seguenti supportano la terminologia attuale dell'ingegneria del contesto, il comportamento del contesto lungo e i modelli operativi di gestione del contesto. Le sezioni del progetto sono esplicitamente prove di implementazione piuttosto che affermazioni universali.