Anthropic: L'ingegneria del contesto efficace per gli agenti AI

Dopo alcuni anni in cui la prompt engineering è stata al centro dell'attenzione nell'IA applicata, un nuovo termine è emerso con prepotenza: l'ingegneria del contesto. La costruzione con i modelli linguistici sta diventando meno una questione di trovare le parole e le frasi giuste per i prompt, e più una questione di rispondere alla domanda più ampia: «quale configurazione di contesto è più probabile che generi il comportamento desiderato dal nostro modello?»

Il contesto si riferisce all'insieme di token inclusi durante il campionamento da un modello linguistico di grandi dimensioni (LLM). Il problema di ingegneria in questione è ottimizzare l'utilità di questi token rispetto ai vincoli intrinseci degli LLM al fine di raggiungere costantemente un risultato desiderato. Gestire efficacemente gli LLM richiede spesso di pensare in contesto – in altre parole: considerare lo stato olistico disponibile all'LLM in un dato momento e quali potenziali comportamenti tale stato potrebbe produrre.

In questo post, esploreremo l'arte emergente dell'ingegneria del contesto e offriremo un modello mentale raffinato per costruire agenti governabili ed efficaci.

Ingegneria del contesto vs. Ingegneria dei prompt

In Anthropic, consideriamo l'ingegneria del contesto come la naturale progressione della prompt engineering. La prompt engineering si riferisce ai metodi per scrivere e organizzare le istruzioni degli LLM per risultati ottimali (vedi le nostre documentazioni per una panoramica e strategie utili di prompt engineering). L'ingegneria del contesto, invece, si riferisce all'insieme di strategie per curare e mantenere l'insieme ottimale di token (informazioni) durante l'inferenza dell'LLM, includendo tutte le altre informazioni che possono trovarsi lì al di fuori dei prompt.

Nei primi giorni dell'ingegneria con gli LLM, il prompting era la componente più grande del lavoro di ingegneria dell'IA, poiché la maggior parte dei casi d'uso al di fuori delle interazioni di chat quotidiane richiedeva prompt ottimizzati per la classificazione one-shot o per compiti di generazione di testo. Come suggerisce il termine, l'obiettivo principale della prompt engineering è come scrivere prompt efficaci, in particolare i prompt di sistema.

Tuttavia, mentre ci muoviamo verso l'ingegneria di agenti più capaci che operano su più turni di inferenza e orizzonti temporali più lunghi, abbiamo bisogno di strategie per gestire l'intero stato del contesto, che include elementi come:

• istruzioni di sistema
• strumenti
• Model Context Protocol (MCP)
• dati esterni
• cronologia dei messaggi
• e molto altro.

Un agente che opera in un ciclo genera sempre più dati che potrebbero essere rilevanti per il turno successivo di inferenza, e queste informazioni devono essere ciclicamente raffinate. L'ingegneria del contesto è l'arte e la scienza di curare ciò che andrà nella finestra di contesto limitata da questo universo di informazioni possibili in costante evoluzione. In contrasto con il compito discreto di scrivere un prompt, l'ingegneria del contesto è iterativa e la fase di curatela avviene ogni volta che decidiamo cosa passare al modello.

Perché l'ingegneria del contesto è importante per la costruzione di agenti capaci

Nonostante la loro velocità e la capacità di gestire volumi di dati sempre più grandi, abbiamo osservato che gli LLM, come gli esseri umani, perdono la concentrazione o sperimentano confusione a un certo punto. Studi su benchmark di tipo "ago nel pagliaio" hanno rivelato il concetto di context rot (deterioramento del contesto): all'aumentare del numero di token nella finestra di contesto, la capacità del modello di richiamare accuratamente le informazioni da quel contesto diminuisce.

Mentre alcuni modelli mostrano un degrado più dolce di altri, questa caratteristica emerge in tutti i modelli. Il contesto, pertanto, deve essere trattato come una risorsa finita con rendimenti marginali decrescenti. Come gli esseri umani, che hanno una capacità di memoria di lavoro limitata, gli LLM hanno un "budget di attenzione" a cui attingono quando analizzano grandi volumi di contesto. Ogni nuovo token introdotto esaurisce questo budget in una certa misura, aumentando la necessità di curare attentamente i token disponibili per l'LLM.

Vincoli architetturali degli LLM

Questa scarsità di attenzione deriva dai vincoli architetturali degli LLM. Gli LLM si basano sull'architettura transformer, che consente a ogni token di prestare attenzione a ogni altro token nell'intero contesto. Ciò si traduce in n² relazioni a coppie per n token. All'aumentare della lunghezza del suo contesto, la capacità di un modello di catturare queste relazioni a coppie si affievolisce, creando una naturale tensione tra la dimensione del contesto e la focalizzazione dell'attenzione.

Inoltre, i modelli sviluppano i loro schemi di attenzione da distribuzioni di dati di addestramento in cui le sequenze più brevi sono tipicamente più comuni di quelle più lunghe. Ciò significa che i modelli hanno meno esperienza e meno parametri specializzati per le dipendenze a livello di contesto. Tecniche come l'interpolazione dell'encoding posizionale consentono ai modelli di gestire sequenze più lunghe adattandole al contesto più piccolo originariamente addestrato, sebbene con un certo degrado nella comprensione della posizione dei token.

Questi fattori creano un gradiente di performance piuttosto che un brusco calo: i modelli rimangono altamente capaci con contesti più lunghi ma possono mostrare una precisione ridotta per il recupero delle informazioni e il ragionamento a lungo raggio rispetto alle loro prestazioni su contesti più brevi. Queste realtà significano che un'attenta ingegneria del contesto è essenziale per costruire agenti capaci.

L'anatomia di un contesto efficace

Dato che gli LLM sono vincolati da un budget di attenzione finito, una buona ingegneria del contesto significa trovare il più piccolo insieme possibile di token ad alto segnale che massimizzano la probabilità di un certo risultato desiderato. Implementare questa pratica è molto più facile a dirsi che a farsi, ma nella sezione seguente, delineiamo cosa significa questo principio guida nella pratica attraverso le diverse componenti del contesto.

Prompt di sistema

I prompt di sistema dovrebbero essere estremamente chiari e utilizzare un linguaggio semplice e diretto che presenti le idee all'altitudine giusta per l'agente. L'altitudine giusta è la zona "riccioli d'oro" tra due comuni modalità di fallimento. A un estremo, vediamo ingegneri che codificano in modo rigido logiche complesse e fragili nei loro prompt per ottenere un comportamento agentico esatto. Questo approccio crea fragilità e aumenta la complessità di manutenzione nel tempo.

All'altro estremo, gli ingegneri a volte forniscono indicazioni vaghe e di alto livello che non riescono a dare all'LLM segnali concreti per gli output desiderati o assumono erroneamente un contesto condiviso. L'altitudine ottimale raggiunge un equilibrio: abbastanza specifica da guidare efficacemente il comportamento, ma abbastanza flessibile da fornire al modello forti euristiche per guidare il comportamento. A un estremo dello spettro, vediamo prompt rigidi con logica "if-else" codificata, mentre all'altro estremo troviamo prompt eccessivamente generici o che assumono erroneamente un contesto condiviso.

Raccomandiamo di organizzare i prompt in sezioni distinte e di utilizzare tecniche come il tagging XML o le intestazioni Markdown per delineare queste sezioni. Alcuni esempi di sezioni utili includono:

• <background_information> (informazioni di sfondo)
• <instructions> (istruzioni)
• ## Tool guidance (guida agli strumenti)
• ## Output description (descrizione dell'output)

Sebbene il formato esatto dei prompt stia probabilmente diventando meno importante man mano che i modelli diventano più capaci.

Indipendentemente da come decidiate di strutturare il vostro prompt di sistema, dovreste puntare all'insieme minimale di informazioni che delinea completamente il vostro comportamento atteso. (Nota che 'minimale' non significa necessariamente breve; è comunque necessario fornire all'agente informazioni sufficienti in anticipo per garantire che aderisca al comportamento desiderato.) È meglio iniziare testando un prompt minimale con il miglior modello disponibile per vedere come si comporta nel vostro compito, e quindi aggiungere istruzioni ed esempi chiari per migliorare le prestazioni in base alle modalità di fallimento riscontrate durante i test iniziali.

Strumenti

Gli strumenti consentono agli agenti di operare con il loro ambiente e di richiamare nuovo contesto aggiuntivo mentre lavorano. Poiché gli strumenti definiscono il contratto tra gli agenti e il loro spazio di informazione/azione, è estremamente importante che gli strumenti promuovano l'efficienza, sia restituendo informazioni che sono efficienti in termini di token sia incoraggiando comportamenti efficienti dell'agente.

In Writing tools for AI agents – with AI agents, abbiamo discusso la costruzione di strumenti che siano ben compresi dagli LLM e che presentino una sovrapposizione minima di funzionalità. Similmente alle funzioni di una codebase ben progettata, gli strumenti dovrebbero essere autonomi, robusti agli errori ed estremamente chiari riguardo al loro uso previsto. I parametri di input dovrebbero essere analogamente descrittivi, non ambigui e sfruttare i punti di forza intrinseci del modello. Uno dei modi di fallimento più comuni che osserviamo è costituito da set di strumenti eccessivamente gonfi che coprono troppe funzionalità o sono poco specifici.