Definizione in una frase
Diseño sistemático de instrucciones, datos, herramientas, memoria y estado que se entregan al modelo en cada paso.
Definizione: progettare le informazioni disponibili per un’attività
L’ingegneria del contesto è la progettazione e la gestione delle informazioni presentate a un modello di IA durante un’esecuzione, per aiutarlo a svolgere un’attività specifica. Può comprendere istruzioni, il messaggio dell’utente, parti della cronologia, esempi, risultati restituiti dagli strumenti, documenti recuperati e dati sullo stato corrente del lavoro. La decisione centrale non riguarda soltanto che cosa dire al modello, ma quali informazioni includere, in quale forma, quando e con quali limiti.
Il termine viene usato in un ambito in evoluzione e non esiste una definizione formale universalmente accettata da tutte le discipline e da tutti i fornitori. È più preciso considerarlo un’espressione pratica per un insieme di decisioni tecniche osservabili: raccogliere informazioni, scegliere quali siano pertinenti, organizzarle in funzione dell’attività e aggiornarle quando cambiano i risultati o lo stato del sistema. Il nome non garantisce che un sistema applichi un metodo specifico né che migliori le proprie prestazioni.
In una conversazione semplice, il contesto può consistere soprattutto di istruzioni e messaggi. In un’applicazione che recupera documenti o usa strumenti, può includere anche risultati esterni. In un agente che lavora in più fasi, una parte delle informazioni può essere conservata al di fuori della conversazione e reinserita quando serve. In tutti i casi, conta ciò che è effettivamente disponibile al modello in quella specifica esecuzione.
Che cosa può far parte del contesto
Le istruzioni definiscono il ruolo, i limiti o il formato atteso. Il messaggio dell’utente esprime l’esigenza immediata. La cronologia può fornire riferimenti a decisioni precedenti, purché i relativi scambi siano ancora pertinenti. Gli esempi mostrano schemi di risposta o di risoluzione, ma la loro utilità dipende dalla loro rappresentatività rispetto all’attività.
I documenti recuperati e i risultati degli strumenti forniscono informazioni esterne al messaggio iniziale. Uno strumento, per esempio, può restituire il contenuto di un file o il risultato di una ricerca. Lo stato del lavoro può registrare che cosa è stato fatto, che cosa resta da fare e quale risultato occorre conservare per il passaggio successivo. Non è necessario che questi elementi siano sempre presenti: includerli senza motivo consuma spazio e può introdurre rumore.
Il contesto non è necessariamente un unico testo scritto da una persona. Può essere una composizione preparata da un’applicazione prima di ogni chiamata al modello. Una parte può provenire da una richiesta; un’altra da una fonte di dati, una ricerca, la cronologia o un’operazione precedente. Per questo, analizzare soltanto il prompt visibile all’utente non sempre permette di sapere quali informazioni abbia ricevuto il modello.
Elementi comuni e domande di controllo
| Elemento | A che cosa può servire | Domanda di controllo |
|---|---|---|
| Istruzioni | Definire l’attività, i vincoli e il formato. | Sono chiare e compatibili tra loro? |
| Cronologia e stato | Mantenere la continuità tra passaggi o turni. | Quale parte è ancora necessaria e aggiornata? |
| Documenti e risultati degli strumenti | Fornire dati per rispondere o agire. | Sono pertinenti, affidabili e sufficienti per questa attività? |
| Esempi | Illustrare uno schema di risposta o di lavoro. | Rappresentano il caso attuale senza indurre un’imitazione inappropriata? |
Come funziona il ciclo di ingegneria del contesto
Una strategia di contesto si può intendere come un ciclo. Per prima cosa si identifica ciò di cui ha bisogno l’attività: per esempio, rispondere a una domanda, modificare un file o confrontare delle fonti. Poi si raccolgono le informazioni disponibili tramite il messaggio, la cronologia, i documenti, gli strumenti o una memoria esterna. Raccogliere dati non significa che vadano inclusi tutti: occorre selezionare quelli pertinenti, verificarne l’attualità ed escludere ciò che non è utile.
In seguito, il materiale viene ordinato e trasformato. Può essere necessario estrarre passaggi, riassumere risultati, distinguere i fatti dalle questioni aperte o strutturare lo stato del lavoro. Le informazioni selezionate vengono quindi inserite nel contesto che il modello vedrà. Dopo la risposta o l’azione, il sistema può verificarne l’esito e aggiornare lo stato: conservare un risultato utile, sostituire informazioni non più attuali o cercare ciò che manca ancora.
Il processo si ripete se l’attività prosegue. La strategia adatta dipende dall’attività, dalle fonti e dalle capacità del sistema; non esiste una ricetta che garantisca un risultato corretto. Una selezione scadente può tralasciare un dato decisivo. Una selezione eccessiva può rendere più difficile per il modello individuare ciò che conta. Conviene quindi progettare il ciclo partendo da esigenze concrete e osservare quali informazioni il sistema usa.
Ciclo di base
- 01Definire che cosa serve per l’attività e quale risultato ci si aspetta.
- 02Raccogliere possibili dati dal messaggio, dalla cronologia, dai documenti o dagli strumenti.
- 03Selezionare, ordinare e trasformare le informazioni pertinenti.
- 04Inserirle nel contesto disponibile al modello.
- 05Esaminare la risposta o l’azione e aggiornare lo stato per il passaggio successivo.
Esempio pratico: un agente di programmazione
Immaginiamo che una persona chieda di correggere un errore in un’applicazione. Caricare subito tutti i file del progetto può essere superfluo. Una strategia più selettiva parte dall’identificazione del messaggio di errore e dall’individuazione dei componenti probabilmente interessati. Il sistema può consultare file, test e documentazione tramite strumenti, poi fornire al modello i passaggi pertinenti insieme ai vincoli della modifica richiesta.
Dopo una modifica, i risultati dei test o le risposte degli strumenti possono entrare nel contesto del passaggio successivo. Se il lavoro deve proseguire in una fase diversa, una nota di stato può riassumere l’obiettivo, le decisioni, i file modificati e le attività ancora da svolgere. Questa nota è una rappresentazione parziale del lavoro, non una trascrizione completa né una garanzia che non sia andato perso qualche dettaglio.
Questo schema mostra perché la gestione del contesto può comprendere sia consultazioni su richiesta sia la conservazione di informazioni tra una fase e l’altra. I sistemi descritti per agenti di lunga durata usano meccanismi di passaggio delle consegne e stati esterni per proseguire il lavoro quando una singola finestra di contesto non è sufficiente. Le modalità concrete di implementazione dipendono dall’agente.
Esempio pratico: assistenza clienti
In un assistente per il servizio clienti, la domanda di una persona potrebbe essere combinata con la policy vigente applicabile al caso e con una parte pertinente della cronologia a cui è autorizzato ad accedere. Per esempio, per chiedere informazioni sullo stato di un reso, il sistema potrebbe aver bisogno della richiesta attuale, della regola pertinente e del dato dell’ordine necessario per identificare l’operazione. È un esempio illustrativo: le fonti disponibili non descrivono un sistema concreto di assistenza clienti configurato in questo modo.
La selezione dovrebbe anche limitare l’accesso alle sole informazioni necessarie. Se un dato personale non aiuta a risolvere la richiesta, non c’è motivo di inserirlo per impostazione predefinita nel contesto. L’applicazione deve stabilire quali informazioni può recuperare, chi può accedervi e per quanto tempo conservarle. Queste decisioni in materia di privacy e autorizzazioni fanno parte della progettazione del sistema; non si risolvono semplicemente aggiungendo istruzioni al modello.
L’assistente dovrebbe inoltre distinguere tra la policy vigente e i messaggi precedenti che potrebbero non essere più aggiornati. Se la risposta dipende da una norma attuale, le informazioni recuperate devono poter essere confrontate con una fonte autorizzata. Il fatto che un documento sia incluso nel contesto non dimostra, di per sé, che sia corretto, aggiornato o applicabile al caso.
Esempio pratico: un agente di ricerca
Un agente di ricerca può suddividere una domanda complessa in più filoni di lavoro e mantenere separati i materiali raccolti per ciascuno. Invece di presentare tutti i documenti a un unico modello a ogni passaggio, può conservare fonti e risultati organizzati per argomento e fornire al coordinatore una sintesi con riferimenti ai materiali pertinenti e alle domande ancora aperte.
Una sintesi facilita il passaggio da una fase all’altra, ma può tralasciare sfumature o riserve. Per questo, lo stato del lavoro dovrebbe distinguere ciò che è stato osservato nelle fonti, ciò che è un’inferenza e ciò che resta da verificare. Se una conclusione dipende da un dettaglio, può essere necessario tornare al documento originale anziché affidarsi soltanto a un riassunto.
Un sistema di ricerca multiagente descritto da Anthropic costituisce un esempio di organizzazione del lavoro tra agenti con contesti separati e sintesi dei risultati per un agente coordinatore. È un caso specifico di progettazione e non dimostra che la stessa architettura sia superiore per ogni tipo di ricerca.
Concetti correlati: prompt, RAG, suddivisione in blocchi, memoria e finestra di contesto
L’ingegneria dei prompt si concentra principalmente sulla formulazione e sull’organizzazione delle istruzioni per orientare la risposta del modello. L’ingegneria del contesto ha una portata più ampia: considera anche come raccogliere, selezionare, ordinare e aggiornare le altre informazioni disponibili. Le due pratiche possono sovrapporsi: una buona istruzione fa parte del contesto, ma da sola non risolve quali documenti recuperare o quale stato conservare.
La generazione aumentata dal recupero, o RAG, è un approccio che combina il recupero di informazioni con la generazione. Può essere un modo per acquisire documenti da inserire nel contesto, ma non è sinonimo di ingegneria del contesto. Un sistema può usare il RAG e dover comunque decidere che cosa recuperare, quali passaggi includere e come trattare i risultati. È anche possibile gestire il contesto senza usare un sistema RAG.
La suddivisione in blocchi, o chunking, consiste nel dividere documenti o altri materiali in unità da archiviare, recuperare o elaborare. Influisce sulle porzioni che possono arrivare al modello, ma non determina da sola se siano pertinenti né come combinarle con le istruzioni e la cronologia. La memoria, invece, indica i meccanismi per conservare e recuperare informazioni tra momenti o attività diverse. Quando recupera informazioni dalla memoria, il sistema dovrebbe valutare se siano ancora pertinenti prima di inserirle nel contesto.
La finestra di contesto è il limite alle informazioni che un modello può elaborare in una singola esecuzione, in base alle caratteristiche del sistema. Non equivale a una strategia per scegliere i contenuti: una finestra ampia non stabilisce che cosa includere né garantisce che ogni parte riceva la stessa attenzione. La cache può riutilizzare contenuti o risultati di elaborazione per ridurre le operazioni ripetute, ma non coincide con la decisione su quali informazioni siano necessarie per una certa attività.
Come distinguere i concetti
| Concetto | Domanda principale | Relazione con l’ingegneria del contesto |
|---|---|---|
| Ingegneria dei prompt | Come formulare le istruzioni? | È una parte della progettazione del contesto, non l’intero processo. |
| RAG | Come recuperare informazioni per generare una risposta? | Può fornire documenti, ma la loro selezione e inclusione vanno comunque gestite. |
| Chunking | Come suddividere i materiali in unità? | Influisce su ciò che può essere recuperato, ma non decide da solo che cosa conviene includere. |
| Memoria | Quali informazioni conservare e recuperare tra momenti diversi? | Può fornire uno stato che va valutato prima di inserirlo nel contesto attuale. |
| Finestra di contesto | Quante informazioni può elaborare una singola esecuzione? | Impone un limite, ma non definisce una politica di selezione. |
Errori comuni e limiti
Un errore frequente è presumere che più contesto sia sempre utile. Gli esperimenti sui modelli con contesti lunghi hanno osservato che la capacità di usare le informazioni può variare a seconda della posizione in cui compare l’evidenza pertinente. Aumentare la quantità di testo o la dimensione della finestra, quindi, non garantisce che il modello individui o usi meglio il dato necessario.
Un altro errore è confondere le informazioni disponibili con quelle effettivamente utilizzate. Il fatto che un documento sia stato incluso non dimostra che abbia influenzato correttamente la risposta. Allo stesso modo, un riassunto non conserva necessariamente tutte le sfumature dell’originale. Durante la compressione si possono perdere condizioni, eccezioni o disaccordi; i dettagli decisivi dovrebbero poter essere verificati confrontandoli con la fonte.
Anche il materiale recuperato può essere incompleto, irrilevante o non più attuale. Inoltre, documenti e pagine web possono contenere istruzioni malevole rivolte all’agente. Se il sistema tratta questi contenuti come istruzioni affidabili, può essere indotto a deviare dall’attività prevista. La prompt injection è un rischio legato all’inserimento di contenuti non attendibili; le misure di difesa devono essere testate e non si può presumere che siano efficaci solo perché sono state implementate.
La selezione del contesto comporta anche decisioni su costi, latenza e privacy. Recuperare o elaborare più informazioni può richiedere ulteriore lavoro, e trasferire dati non necessari ne aumenta inutilmente l’esposizione. Non esiste una quantità di contesto corretta in assoluto: dipende dall’attività, dalla qualità delle fonti, dai vincoli del sistema e dagli errori che si vogliono prevenire.
Come valutare una strategia
Per capire se una strategia è utile, conviene definire attività di prova rappresentative e stabilire in anticipo che cosa si considera un risultato accettabile. Si possono poi confrontare diverse varianti: per esempio, che cosa succede recuperando meno documenti, ordinando le evidenze in modo diverso o conservando un riepilogo di stato più esplicito. Quando possibile, è preferibile modificare una decisione per volta, così da facilitare l’interpretazione dei risultati.
La valutazione può prendere in esame la qualità delle risposte o delle azioni, le omissioni di informazioni rilevanti, gli errori di selezione, la latenza, il costo e la quantità o sensibilità dei dati inclusi. Nei sistemi che usano documenti, è utile verificare anche se le risposte si basino su fonti applicabili e aggiornate. I risultati vanno interpretati in relazione alle attività e ai dati di prova utilizzati: non dimostrano automaticamente che la strategia funzionerà in altri casi.
Per attribuire un miglioramento alla gestione del contesto, occorre confrontare i risultati in modo sistematico e, per quanto possibile, mantenere costanti il modello e le altre condizioni rilevanti. Un’impressione aneddotica o il fatto che una risposta sembri convincente non bastano a dimostrare un rapporto di causa ed effetto. Se emergono errori, analizzare che cosa è stato recuperato, che cosa è stato tralasciato e quali informazioni sono effettivamente arrivate al modello può aiutare a individuare il problema.
Breve lista di controllo per la progettazione
- 01Le informazioni incluse rispondono a un’esigenza identificata dell’attività?
- 02La pertinenza e l’attualità delle fonti sono state verificate?
- 03Il sistema conserva i dettagli critici che un riassunto potrebbe omettere?
- 04I dati personali non necessari vengono esclusi?
- 05Qualità, omissioni, latenza e costo sono stati misurati su attività rappresentative?
- 06Sono stati testati input non attendibili e situazioni in cui il recupero non riesce?
Criteri pratici e concetti correlati
Quando progetti un sistema, inizia precisando l’attività e il dato che potrebbe cambiare la risposta o l’azione. Recupera informazioni soltanto da fonti autorizzate, seleziona quelle pertinenti e mantieni la possibilità di consultare il materiale originale quando una sintesi non è sufficiente. Aggiorna lo stato quando arrivano nuove evidenze, invece di accumulare senza limite una cronologia che potrebbe non essere più utile.
Poi metti alla prova la progettazione con casi normali e casi limite: fonti contraddittorie, informazioni obsolete, richieste ambigue e documenti contenenti istruzioni estranee all’attività. Verifica che cosa arriva al modello, che cosa resta escluso e quale risultato viene prodotto. Se il sistema fallisce, non dare per scontato che abbia bisogno di più contesto: controlla se il problema riguarda il recupero, la selezione, l’organizzazione, l’attualità dei dati o l’interpretazione del modello.
Per approfondire il lessico correlato, consulta le voci del glossario dedicate all’ingegneria dei prompt, al RAG, alla suddivisione in blocchi o chunking e alla memoria, oltre alla pagina generale del glossario. La distinzione pratica è semplice: il prompt riguarda soprattutto le istruzioni; il RAG il recupero di informazioni da usare nella generazione; il chunking la suddivisione dei materiali; la memoria la conservazione e il recupero dello stato. L’ingegneria del contesto considera come combinare questi elementi per una specifica esecuzione.