Context engineering: perché conta e come farlo bene
Il context engineering progetta tutto ciò che un modello vede, non solo il prompt. È ciò che rende affidabili gli agenti.
Traduzione generata automaticamente con IA. La versione tedesca è l'originale verificato dalla redazione.
L'affidabilità di un agente IA dipende meno dal modello che da ciò che gli sottoponete. Il context engineering è la pratica di progettare l'intera quantità di informazioni: il system prompt, la memoria, gli strumenti e i dati che recuperate, non solo la domanda. Secondo la nostra esperienza è la leva singola più importante per determinare se un agente funziona in produzione, ed è una disciplina diversa dal prompt engineering (Context Engineering 2.0).
01. OLTRE IL PROMPT
Il prompt engineering perfeziona la domanda. Il context engineering progetta l'ambiente in cui il modello decide. Per un'attività una tantum basta un buon prompt. Per un agente che opera su molti passaggi, legge strumenti e porta con sé la memoria, il prompt è solo una piccola parte di ciò che il modello vede. Il resto, ciò che recuperate, ciò che ricordate, quali strumenti rendete disponibili e come, è contesto, e determina molto di più il risultato. Ecco perché estendere un harness agentico è in gran parte lavoro sul contesto.
02. I QUATTRO SCHEMI DI FALLIMENTO CONTRO CUI SI PROGETTA
La maggior parte dei fallimenti degli agenti risale a uno di quattro problemi di contesto:
- Sovraccarico di contesto. Troppo nella finestra. Il modello perde il filo, e costi e latenza aumentano. Più contesto non significa contesto migliore.
- Avvelenamento del contesto. Un fatto sbagliato o obsoleto entra nella finestra, e il modello lo tratta come verità. Un singolo frammento recuperato male può far deragliare una risposta.
- Gestione dei token. La finestra è finita. Senza un piano su cosa mantenere e cosa scartare, il dettaglio importante viene spinto fuori dal rumore.
- Memoria obsoleta. Gli agenti a esecuzione prolungata accumulano contesto non più valido e agiscono di conseguenza.
Nominare il fallimento è metà della soluzione. Ciascuno ha una contromisura concreta.
03. PRATICHE CHE REGGONO
Alcuni schemi ricorrono nelle architetture che restano affidabili:
- Recuperare, non riversare. Estraete i pochi passaggi rilevanti con un buon retrieval, invece di copiare tutto dentro. È tutto il senso del RAG, ed è context engineering applicato ai dati.
- Sfoltire in modo continuo. Applicate una modifica basata su regole nell'harness per mantenere snella la finestra: scartate ciò che un passaggio non richiede più.
- Riassumere le cronologie lunghe. Sostituite una trascrizione lunga con un riassunto fedele, prima che spiazzi il compito.
- Iniziare in modo semplice, scalare in base alle necessità. Aggiungete memoria e strumenti solo quando un fallimento reale lo richiede, non per impostazione predefinita.
L'istinto di aggiungere di più è la trappola. La disciplina sta nel togliere.
04. PERCHÉ QUESTO È IL VERO ENGINEERING
Un modello più grande raramente risolve un problema di contesto; fallisce solo in modo più costoso. Il lavoro che porta un agente dalla demo all'affidabilità è quasi esclusivamente lavoro sul contesto: cosa vede, quando, e cosa deve dimenticare. Con input molto lunghi conta anche l'architettura del modello, ed è qui che entrano in gioco gli approcci subquadratici, ma per la maggior parte dei team il guadagno sta nel contesto, non nei parametri.
