Mantenere gli agenti AI a terra: Strategie di ingegneria del contesto che prevengono il marciume del contesto usando Milvus

Se avete lavorato a conversazioni LLM di lunga durata, probabilmente avete vissuto questo momento di frustrazione: a metà di una lunga discussione, il modello inizia ad andare alla deriva. Le risposte diventano vaghe, il ragionamento si indebolisce e i dettagli chiave scompaiono misteriosamente. Ma se si inserisce la stessa identica richiesta in una nuova chat, improvvisamente il modello si comporta in modo concentrato, accurato, concreto.

Non si tratta di "stanchezza" del modello, ma di un'alterazione del contesto. Man mano che una conversazione cresce, il modello deve destreggiarsi tra più informazioni e la sua capacità di stabilire le priorità diminuisce lentamente. Gli studi di Antropic mostrano che quando le finestre di contesto passano da circa 8K token a 128K, l'accuratezza del recupero può diminuire del 15-30%. Il modello ha ancora spazio, ma perde di vista ciò che conta. Finestre di contesto più grandi aiutano a ritardare il problema, ma non lo eliminano.

È qui che entra in gioco l 'ingegneria del contesto. Invece di dare al modello tutto in una volta, modifichiamo ciò che vede: recuperando solo i pezzi che contano, comprimendo ciò che non ha più bisogno di essere verboso e mantenendo i prompt e gli strumenti abbastanza puliti da permettere al modello di ragionarci sopra. L'obiettivo è semplice: rendere disponibili le informazioni importanti al momento giusto e ignorare il resto.

Il recupero gioca un ruolo centrale in questo senso, soprattutto per gli agenti di lunga durata. I database vettoriali come Milvus forniscono le fondamenta per recuperare in modo efficiente la conoscenza pertinente nel contesto, consentendo al sistema di rimanere ancorato alla base anche quando i compiti crescono in profondità e complessità.

In questo blog analizzeremo come avviene la rotazione del contesto, le strategie che i team utilizzano per gestirla e i modelli architettonici - dal reperimento alla progettazione dei prompt - che consentono agli agenti di intelligenza artificiale di mantenere la lucidità nei flussi di lavoro lunghi e in più fasi.

Perché si verifica la rotazione del contesto

Spesso si pensa che fornire a un modello di intelligenza artificiale un contesto più ampio porti naturalmente a risposte migliori. Ma in realtà non è così. Anche gli esseri umani hanno difficoltà a gestire input lunghi: la scienza cognitiva suggerisce che la nostra memoria di lavoro contiene circa 7±2 pezzi di informazioni. Se ci spingiamo oltre, iniziamo a dimenticare, confondere o interpretare male i dettagli.

Gli LLM mostrano un comportamento simile, ma su scala molto più ampia e con modalità di fallimento più drammatiche.

Il problema principale deriva dall'architettura stessa di Transformer. Ogni token deve confrontarsi con ogni altro token, formando un'attenzione a coppie sull'intera sequenza. Ciò significa che la computazione cresce O(n²) con la lunghezza del contesto. Espandere il prompt da 1K token a 100K non fa sì che il modello "lavori di più", ma moltiplica il numero di interazioni tra i token di 10.000×.

C'è poi il problema dei dati di addestramento. I modelli vedono molte più sequenze brevi che lunghe. Quindi, quando si chiede a un LLM di operare in contesti estremamente ampi, lo si spinge in un regime per il quale non è stato addestrato. In pratica, il ragionamento su contesti molto lunghi è spesso fuori distribuzione per la maggior parte dei modelli.

Nonostante questi limiti, i contesti lunghi sono ormai inevitabili. Le prime applicazioni di LLM erano per lo più compiti a turno singolo: classificazione, riassunto o semplice generazione. Oggi, oltre il 70% dei sistemi di intelligenza artificiale aziendali si basa su agenti che rimangono attivi per molti cicli di interazione, spesso per ore, gestendo flussi di lavoro ramificati e in più fasi. Le sessioni di lunga durata sono passate da eccezione a regola d'arte.

La domanda successiva è: come mantenere viva l'attenzione del modello senza sovraccaricarlo?

Approcci di recupero del contesto per risolvere il problema del Context Rot

Il recupero è una delle leve più efficaci per combattere il marciume del contesto e, nella pratica, tende a manifestarsi in modelli complementari che affrontano il marciume del contesto da diverse angolazioni.

1. Recupero just-in-time: Ridurre il contesto non necessario

Una delle cause principali del context rot è il sovraccarico del modello con informazioni di cui non ha ancora bisogno. Claude Code, l'assistente di codifica di Anthropic, risolve questo problema con il recupero Just-in-Time (JIT), una strategia in cui il modello recupera le informazioni solo quando sono rilevanti.

Invece di inserire intere basi di codice o insiemi di dati nel suo contesto (il che aumenta notevolmente la possibilità di deriva e dimenticanza), Claude Code mantiene un piccolo indice: percorsi di file, comandi e link alla documentazione. Quando il modello ha bisogno di un'informazione, recupera quell'elemento specifico e lo inserisce nel contesto nel momento incui è importante, nonprima.

Ad esempio, se chiedete a Claude Code di analizzare un database di 10 GB, non cercherà mai di caricarlo tutto. Lavora più come un ingegnere:

1. Esegue una query SQL per ottenere sintesi di alto livello del set di dati.

2. Utilizza comandi come head e tail per visualizzare i dati di esempio e comprenderne la struttura.

3. Conserva solo le informazioni più importanti, come le statistiche chiave o le righe di esempio, all'interno del contesto.

Riducendo al minimo ciò che viene conservato nel contesto, il recupero JIT evita l'accumulo di token irrilevanti che causano il marciume. Il modello rimane concentrato perché vede solo le informazioni necessarie per la fase di ragionamento corrente.

2. Pre-recupero (ricerca vettoriale): Prevenire la deriva del contesto prima che cominci

A volte il modello non può "chiedere" informazioni in modo dinamico: l'assistenza clienti, i sistemi di domande e risposte e i flussi di lavoro degli agenti hanno spesso bisogno di avere a disposizione le conoscenze giuste prima dell' inizio della generazione. È qui che il pre-recupero diventa fondamentale.

La rotazione del contesto avviene spesso perché al modello viene consegnata una grande pila di testo grezzo e ci si aspetta che selezioni ciò che conta. Il pre-recupero ribalta la situazione: un database vettoriale (come Milvus e Zilliz Cloud) identifica i pezzi più rilevanti prima dell' inferenza, assicurando che solo il contesto di alto valore raggiunga il modello.

In una tipica configurazione RAG:

• I documenti sono incorporati e memorizzati in un database vettoriale, come Milvus.

• Al momento dell'interrogazione, il sistema recupera un piccolo insieme di pezzi altamente rilevanti attraverso ricerche di similarità.

• Solo questi pezzi vengono inseriti nel contesto del modello.

In questo modo si evita il marciume in due modi:

• Riduzione del rumore: il testo irrilevante o debolmente correlato non entra mai nel contesto.

• Efficienza: i modelli elaborano un numero molto inferiore di token, riducendo la possibilità di perdere traccia di dettagli essenziali.

Milvus è in grado di ricercare milioni di documenti in millisecondi, rendendo questo approccio ideale per i sistemi live in cui la latenza è importante.

3. Recupero ibrido JIT e vettoriale

Il pre-recupero basato sulla ricerca vettoriale risolve una parte significativa della rotazione del contesto, garantendo che il modello parta da informazioni ad alto segnale piuttosto che da testo grezzo e sovradimensionato. Ma Anthropic mette in evidenza due sfide reali che i team spesso trascurano:

• La tempestività: Se la base di conoscenza si aggiorna più velocemente di quanto venga ricostruito l'indice vettoriale, il modello può basarsi su informazioni obsolete.

• Accuratezza: prima dell'inizio di un'attività, è difficile prevedere con precisione ciò di cui il modello avrà bisogno, soprattutto nel caso di flussi di lavoro multi-fase o esplorativi.

Per questo motivo, nei carichi di lavoro del mondo reale, un'applicazione ibrida è la soluzione ottimale.

• Ricerca vettoriale di conoscenze stabili e ad alta affidabilità

• Esplorazione JIT guidata dagli agenti per le informazioni che si evolvono o che diventano rilevanti solo a metà dell'attività.

Combinando questi due approcci, si ottiene la velocità e l'efficienza del recupero vettoriale per le informazioni note e la flessibilità del modello per scoprire e caricare nuovi dati ogni volta che diventano rilevanti.

Vediamo come funziona in un sistema reale. Prendiamo ad esempio un assistente alla documentazione di produzione. La maggior parte dei team alla fine sceglie una pipeline a due fasi: Ricerca vettoriale alimentata da Milvus + recupero JIT basato su agenti.

1. Ricerca vettoriale alimentata da Milvus (pre-recupero)

• Convertire la documentazione, i riferimenti API, i changelog e i problemi noti in embeddings.

• Memorizzateli nel database vettoriale di Milvus con metadati come l'area del prodotto, la versione e l'ora di aggiornamento.

• Quando un utente fa una domanda, eseguite una ricerca semantica per prendere i primi K segmenti pertinenti.

Questo risolve circa l'80% delle domande di routine in meno di 500 ms, dando al modello un punto di partenza forte e resistente al contesto.

2. Esplorazione basata su agenti

Quando il reperimento iniziale non è sufficiente, ad esempio quando l'utente chiede qualcosa di molto specifico o sensibile al tempo, l'agente può chiamare strumenti per ottenere nuove informazioni:

• Utilizzare search_code per individuare funzioni o file specifici nella base di codice.

• Utilizzare run_query per prelevare dati in tempo reale dal database.

• Utilizzare fetch_api per ottenere lo stato più recente del sistema

Queste chiamate richiedono in genere 3-5 secondi, ma assicurano che il modello funzioni sempre con dati freschi, accurati e pertinenti, anche per le domande che il sistema non poteva prevedere in anticipo.

Questa struttura ibrida garantisce che il contesto rimanga tempestivo, corretto e specifico per l'attività, riducendo drasticamente il rischio di rotazione del contesto nei flussi di lavoro degli agenti di lunga durata.

Milvus è particolarmente efficace in questi scenari ibridi perché supporta:

• Ricerca vettoriale + filtraggio scalare, che combina la rilevanza semantica con vincoli strutturati.

• Aggiornamenti incrementali, che consentono di rinfrescare le incorporazioni senza tempi morti.

Questo fa di Milvus la spina dorsale ideale per i sistemi che necessitano sia di una comprensione semantica che di un controllo preciso su ciò che viene recuperato.

Ad esempio, si potrebbe eseguire una query come:

# You can combine queries like this in Milvus
collection.search(
    data=[query_embedding],  # Semantic similarity
    anns_field="embedding",
    param={"metric_type": "COSINE", "params": {"nprobe": 10}},
    expr="doc_type == 'API' and update_time > '2025-01-01'",  # Structured filtering
    limit=5
)

Come scegliere l'approccio giusto per gestire il Context Rot

Con il pre-recupero a ricerca vettoriale, il reperimento Just-in-Time e il reperimento ibrido, la domanda naturale è: quale utilizzare?

Ecco un modo semplice ma pratico per scegliere, in base alla stabilità delle conoscenze e alla prevedibilità delle esigenze informative del modello.

1. Ricerca vettoriale → migliore per i domini stabili

Se il dominio cambia lentamente ma richiede precisione - finanza, lavoro legale, conformità, documentazione medica - allora una base di conoscenza alimentata da Milvus con pre-recupero è di solito la soluzione giusta.

Le informazioni sono ben definite, gli aggiornamenti sono poco frequenti e la maggior parte delle domande può trovare risposta recuperando in anticipo i documenti semanticamente rilevanti.

Compiti prevedibili + conoscenza stabile → Pre-recupero.

2. Recupero Just-in-Time → Ideale per flussi di lavoro dinamici ed esplorativi.

Settori come l'ingegneria del software, il debugging, l'analisi e la scienza dei dati comportano ambienti in rapida evoluzione: nuovi file, nuovi dati, nuovi stati di distribuzione. Il modello non può prevedere ciò di cui avrà bisogno prima dell'inizio dell'attività.

Attività imprevedibili + conoscenza in rapida evoluzione → Recupero Just-in-Time.

3. Approccio ibrido → Quando entrambe le condizioni sono vere

Molti sistemi reali non sono né puramente stabili né puramente dinamici. Ad esempio, la documentazione degli sviluppatori cambia lentamente, mentre lo stato di un ambiente di produzione cambia di minuto in minuto. Un approccio ibrido consente di:

• caricare conoscenze note e stabili utilizzando la ricerca vettoriale (veloce e a bassa latenza)

• Recuperare informazioni dinamiche con strumenti ad agente su richiesta (accurate e aggiornate).

Conoscenza mista + struttura mista dei compiti → Approccio di recupero ibrido.

Cosa succede se la finestra di contesto non è ancora sufficiente?

L'ingegneria del contesto aiuta a ridurre il sovraccarico, ma a volte il problema è più fondamentale: l'attività non è sufficiente, anche con un'attenta riduzione.

Alcuni flussi di lavoro, come la migrazione di una grande base di codice, la revisione di architetture multi-repository o la generazione di rapporti di ricerca approfonditi, possono superare le 200K finestre di contesto prima che il modello raggiunga la fine dell'attività. Anche con la ricerca vettoriale, alcuni compiti richiedono una memoria più persistente e strutturata.

Recentemente, Anthropic ha proposto tre strategie pratiche.

1. Compressione: Preservare il segnale, eliminare il rumore

Quando la finestra di contesto si avvicina al limite, il modello può comprimere le interazioni precedenti in riassunti concisi. Una buona compressione mantiene

• Decisioni chiave

• Vincoli e requisiti

• Problemi in sospeso

• Esempi o campioni rilevanti

E rimuove:

• Output di strumenti prolissi

• Registri irrilevanti

• Passi ridondanti

La sfida è l'equilibrio. Se si comprime in modo troppo aggressivo, il modello perde informazioni critiche; se si comprime in modo troppo leggero, si guadagna poco spazio. Una compressione efficace mantiene il "perché" e il "cosa", mentre scarta il "come siamo arrivati qui".

2. Prendere appunti strutturati: Spostare le informazioni stabili fuori dal contesto

Invece di tenere tutto all'interno della finestra del modello, il sistema può memorizzare i fatti importanti in una memoria esterna, undatabase separato o un archivio strutturato che l'agente può interrogare quando necessario.

Ad esempio, il prototipo di agente Pokémon di Claude memorizza fatti durevoli come:

• Pikachu leveled up to 8

• Trained 1234 steps on Route 1

• Goal: reach level 10

Nel frattempo, i dettagli transitori - registri di battaglia, output di strumenti lunghi - rimangono al di fuori del contesto attivo. Questo rispecchia il modo in cui gli esseri umani usano i taccuini: non conserviamo ogni dettaglio nella nostra memoria di lavoro; memorizziamo i punti di riferimento all'esterno e li consultiamo quando necessario.

L'annotazione strutturata evita il marciume del contesto causato da dettagli ripetuti e non necessari, fornendo al modello una fonte affidabile di verità.

3. Architettura a sub-agenti: Dividere e conquistare grandi compiti

Per compiti complessi, è possibile progettare un'architettura multi-agente in cui un agente principale supervisiona il lavoro complessivo, mentre diversi subagenti specializzati gestiscono aspetti specifici del compito. Questi subagenti scavano in profondità in grandi quantità di dati relativi ai loro sottocompiti, ma restituiscono solo i risultati concisi ed essenziali. Questo approccio è comunemente utilizzato in scenari come i rapporti di ricerca o l'analisi dei dati.

In pratica, è meglio iniziare utilizzando un singolo agente combinato con la compressione per gestire il compito. L'archiviazione esterna dovrebbe essere introdotta solo quando c'è la necessità di mantenere la memoria tra le sessioni. L'architettura multi-agente dovrebbe essere riservata ai compiti che richiedono realmente l'elaborazione parallela di sotto-compiti complessi e specializzati.

Ogni approccio estende la "memoria di lavoro" effettiva del sistema senza far saltare la finestra del contesto e senza innescare la rotazione del contesto.

Le migliori pratiche per progettare un contesto che funzioni davvero

Dopo aver gestito l'overflow del contesto, c'è un altro aspetto altrettanto importante: il modo in cui il contesto viene costruito. Anche con la compressione, le note esterne e i subagenti, il sistema farà fatica se il prompt e gli strumenti stessi non sono progettati per supportare ragionamenti lunghi e complessi.

Anthropic offre un modo utile di pensare a questo aspetto: meno come un singolo esercizio di scrittura di un prompt e più come la costruzione di un contesto su tre livelli.

Prompt di sistema: Trovare la zona Goldilocks

La maggior parte dei suggerimenti di sistema fallisce agli estremi. Troppi dettagli - elenchi di regole, condizioni annidate, eccezioni codificate - rendono il prompt fragile e difficile da mantenere. Troppo poco strutturato lascia il modello a indovinare cosa fare.

I migliori prompt si collocano nel mezzo: abbastanza strutturati da guidare il comportamento, ma abbastanza flessibili da permettere al modello di ragionare. In pratica, questo significa dare al modello un ruolo chiaro, un flusso di lavoro generale e una guida leggera per lo strumento: niente di più, niente di meno.

Per esempio:

You are a technical documentation assistant serving developers.
1. Start by retrieving relevant documents from the Milvus knowledge base.  
2. If the retrieval results are insufficient, use the `search_code` tool to perform a deeper search in the codebase.  
3. When answering, cite specific documentation sections or code line numbers.
## Tool guidance

search_docs: Used for semantic retrieval, best for conceptual questions.
search_code: Used for precise lookup in the codebase, best for implementation-detail questions.

…

Questo prompt stabilisce una direzione senza sovraccaricare il modello o costringerlo a destreggiarsi tra informazioni dinamiche che non gli competono.

Progettazione degli strumenti: Meno è meglio

Una volta che il prompt del sistema stabilisce il comportamento di alto livello, gli strumenti portano la logica operativa vera e propria. Una modalità di fallimento sorprendentemente comune nei sistemi con strumenti è semplicemente quella di avere troppi strumenti, o di avere strumenti i cui scopi si sovrappongono.

Una buona regola empirica:

• Uno strumento, uno scopo

• Parametri espliciti e non ambigui

• Nessuna sovrapposizione di responsabilità

Se un ingegnere umano esiterebbe su quale strumento usare, lo farà anche il modello. Una progettazione pulita degli strumenti riduce l'ambiguità, diminuisce il carico cognitivo ed evita che il contesto sia ingombrato da tentativi di strumenti non necessari.

Le informazioni dinamiche devono essere recuperate, non codificate in modo rigido

L'ultimo livello è il più facile da trascurare. Le informazioni dinamiche o sensibili al tempo, come i valori di stato, gli aggiornamenti recenti o lo stato specifico dell'utente, non dovrebbero mai comparire nel prompt del sistema. Inserirle nel prompt garantisce che diventino stantie, gonfie o contraddittorie nel corso di lunghe attività.

Invece, queste informazioni dovrebbero essere recuperate solo quando sono necessarie, attraverso il recupero o gli strumenti dell'agente. Mantenere i contenuti dinamici fuori dal prompt del sistema evita la putrefazione del contesto e mantiene pulito lo spazio di ragionamento del modello.

Conclusione

Man mano che gli agenti di intelligenza artificiale entrano negli ambienti di produzione di diversi settori, si trovano ad affrontare flussi di lavoro più lunghi e compiti più complessi che mai. In questi contesti, la gestione del contesto diventa una necessità pratica.

Tuttavia, una finestra di contesto più grande non produce automaticamente risultati migliori; in molti casi, fa il contrario. Quando un modello viene sovraccaricato, alimentato con informazioni stantie o obbligato a rispondere a richieste massicce, l'accuratezza si allontana silenziosamente. Questo lento e sottile declino è ciò che oggi chiamiamo context rot.

Tecniche come il recupero JIT, il pre-recupero, le pipeline ibride e la ricerca semantica alimentata da database vettoriali mirano tutte allo stesso obiettivo: fare in modo che il modello veda le informazioni giuste al momento giusto - né più né meno - in modo che possa rimanere con i piedi per terra e produrre risposte affidabili.

Milvus, un database vettoriale open-source ad alte prestazioni, è al centro di questo flusso di lavoro. Fornisce l'infrastruttura per archiviare le conoscenze in modo efficiente e recuperare le parti più rilevanti con una bassa latenza. Abbinato al recupero JIT e ad altre strategie complementari, Milvus aiuta gli agenti di intelligenza artificiale a rimanere precisi anche quando i loro compiti diventano più profondi e dinamici.

Ma il recupero è solo un pezzo del puzzle. Un buon design dei prompt, un set di strumenti pulito e minimale e strategie di overflow sensate - che si tratti di compressione, note strutturate o subagenti - lavorano insieme per mantenere il modello concentrato durante le sessioni di lunga durata. Questo è l'aspetto di una vera ingegneria del contesto: non si tratta di ingegnosi hack, ma di un'architettura ponderata.

Se volete agenti di intelligenza artificiale che rimangano precisi per ore, giorni o interi flussi di lavoro, il contesto merita la stessa attenzione che dedichereste a qualsiasi altra parte fondamentale del vostro stack.

Avete domande o volete un approfondimento su una qualsiasi funzionalità? Unitevi al nostro canale Discord o inviate problemi su GitHub. È anche possibile prenotare una sessione individuale di 20 minuti per ottenere approfondimenti, indicazioni e risposte alle vostre domande attraverso Milvus Office Hours.