I tuoi agenti AI non hanno un problema di memoria. Hanno un problema di selezione

@eng_khairallah1
INGLESE4 settimane fa · 17 giu 2026
427K
257
28
67
480

TL;DR

Gli agenti AI falliscono nelle attività lunghe perché le ampie finestre di contesto portano a errori cumulativi e rumore. L'articolo sostiene che il vero collo di bottiglia sia la selezione — decidere a cosa il modello debba prestare attenzione — piuttosto che la semplice capacità di archiviazione.

Abbiamo dato un milione di token agli agenti nella finestra di contesto, ma ancora non funzionano.

Conserva questo post :)

Affidate a un modello capace alcuni strumenti e un compito lungo. Per i primi quindici passi, è brillante. Concentrato e preciso. Risponde alle domande e interroga bene l'utente.

Tuttavia, quando le conversazioni iniziano a scalare, l'agente inizia a deragliare. L'agente inizia a contraddire le decisioni che aveva preso dieci passi prima. Inizia a inquinare la finestra di contesto con informazioni inventate. Sa che le preferenze dell'utente esistono, ma non riesce a recuperarle in modo affidabile. E tutto questo mentre tu fatichi a capire perché le cose si sono rotte.

Allora finisci per cercare di più. Un modello con una finestra di contesto più grande per mantenere il compito più a lungo. Provare a ottimizzare la pipeline RAG. Setacciare internet alla ricerca di soluzioni di memoria per agenti.

E niente funziona come ti aspetteresti.

Capire il perché di tutto questo ci porta dritti al livello più prezioso e meno compreso dell'intero stack degli agenti.

Il Fallimento è un Ciclo

Il motivo per cui gli agenti degenerano non è una mancanza di capacità. È un ciclo di feedback, composto da quattro anelli. Una volta che li vedi tutti e quattro, le solite soluzioni non sembrano più tali.

Khairallah AL-Awady - inline image

Primo anello: un modello non può usare tutto il suo contesto in modo uniforme, e la situazione peggiora man mano che il contesto si riempie.

Questa è la parte che la maggior parte delle persone non interiorizza mai. La capacità di un modello di usare le informazioni non è uniforme in tutta la sua finestra di contesto. I modelli usano in modo affidabile ciò che si trova all'inizio e alla fine, e sistematicamente prestano meno attenzione alla parte centrale, anche quando sono stati costruiti appositamente per input lunghi. Inserisci di più, e l'affidabilità cala ulteriormente. Questo si manifesta anche in compiti banali come ripetere una lista di parole. Aggiungi un singolo elemento di disturbo, e le prestazioni calano in modo misurabile. Aggiungine diversi, e le cose si complicano.

Quindi il contesto effettivo, la parte su cui il modello può effettivamente ragionare in modo affidabile, è molto più piccolo del numero riportato sulla scatola. E si restringe man mano che ci inserisci più cose.

Ora pensa a cosa fa un agente. Accumula. Ogni risultato di uno strumento, ogni passo della cronologia, ogni appunto viene aggiunto al contesto. Il che significa che l'agente sta costantemente abbassando la qualità di ogni passo che compie. Il contesto in crescita sta producendo errori a ogni passo.

Secondo anello: questi errori a ogni passo non si sommano. Si moltiplicano.

Un piccolo errore per passo sarebbe accettabile se gli agenti facessero solo una manciata di passi. Invece ne fanno decine. E i fallimenti si aggravano piuttosto che accumularsi. Un agente affidabile al 95% per cinque passi non rimane affidabile al 95% per un compito di 20 passi. Fai abbastanza passi, e ti avvicini sempre di più a un lancio di moneta.

Ed è peggio di così, perché gli errori si autoalimentano. Una chiamata a uno strumento che va leggermente fuori rotta rende più probabile che anche la successiva vada fuori rotta. Combina questo con il primo anello, dove il tasso di errore di base sta già aumentando man mano che la finestra si riempie, e ottieni la modalità di fallimento caratteristica degli agenti a lungo termine. Non degenerano gradualmente. Resistono e poi, improvvisamente, crollano.

Terzo anello: il compito è lungo, il modello è senza stato, quindi metti lo stato da qualche parte al di fuori del modello.

I modelli linguistici non conservano nulla tra una chiamata e l'altra. Ogni chiamata parte da zero. L'unica cosa che un modello sa è ciò che gli reimmettono. Quindi per qualsiasi compito lungo, devi esternalizzare lo stato. Blocchi note. File di avanzamento. Punti di controllo. Archivi vettoriali. Livelli di memoria dedicati che estraggono fatti e li ripropongono tra sessioni diverse.

Questo è corretto e necessario. E sembra una soluzione pulita. L'agente non dimentica nulla di importante, perché tutto ciò che è importante vive in un archivio durevole.

Quarto anello: la memoria immagazzinata è inerte, e richiamarla alimenta proprio il problema che avrebbe dovuto risolvere.

Ecco dove il ciclo si chiude. Un modello non può ragionare su un database. Può ragionare solo su ciò che è nella sua finestra di contesto. Quindi la memoria aiuta solo nell'istante in cui viene richiamata. E ogni recupero aggiunge token. Ogni riepilogo che l'agente scrive per tenere traccia dei progressi è un token che dovrà rileggere più tardi. Ogni passo di compattazione che condensa la cronologia per fare spazio è una perdita, e il dettaglio che scarta è spesso quello sottile la cui importanza diventa chiara solo in seguito.

Quindi il sistema di memoria che hai costruito per sconfiggere il limite del contesto finisce per alimentarlo. Più memoria significa più recuperi, che significano più rumore nella finestra, che significa più errori a ogni passo, che si aggravano, che è proprio ciò che ti ha spinto a cercare la memoria in primo luogo.

Il ciclo è reale. E non importa quanto grande sia la tua finestra di contesto.

La Capacità Non è Mai Stata l'Asse Importante

Una volta visto il ciclo, l'inutilità delle soluzioni standard diventa ovvia.

Khairallah AL-Awady - inline image

Una finestra di contesto più grande non lo spezza. Alza solo il limite massimo di quanto decadimento puoi accumulare prima del crollo. Nel frattempo, ogni studio sul contesto effettivo continua a mostrare la stessa cosa: la frazione utilizzabile in modo affidabile cresce molto più lentamente del numero pubblicizzato. Stai comprando capacità che non puoi effettivamente usare.

Più memoria non lo spezza. Aumenta il volume di materiale che compete per rientrare in una finestra che già non può contenere tutto ciò che c'è.

La prossima architettura non lo spezzerà nemmeno. I contendenti che si oppongono all'attenzione, i modelli a spazio di stato come Mamba e i suoi ibridi, vincono comprimendo il passato in uno stato di dimensione fissa invece di mantenere ogni token indirizzabile. Questo acquista un'inferenza a tempo lineare e un'impronta di memoria che non cresce con la sequenza. Non può acquistare una capacità di richiamo. Uno stato di dimensione fissa non può contenere tutto, quindi dimentica per progettazione. Su larga scala, i modelli a puro spazio di stato sono in ritardo rispetto ai transformer esattamente sulla cosa per cui esiste la memoria esterna: recuperare un fatto specifico da un punto arbitrario all'inizio della sequenza. Questo è il motivo per cui gli sforzi seri post-attenzione sono ibridi che mantengono una minoranza di livelli di attenzione per fare il richiamo, cosa che un modello a stato non può fare. Il muro non si sposta quando cambi l'architettura. Lo raggiungi semplicemente dall'altro lato.

Quindi la lezione non è "scegli un numero più grande". È che la capacità non è mai stata il vincolo limitante.

Il vincolo limitante è la qualità della decisione su quali token occupano la finestra in ogni passo.

Questo è il vero gioco. Non il contesto più grande disponibile, ma il più piccolo sufficiente. Pertinenza contro richiamo. Dimenticanza deliberata come operazione di prima classe invece di un incidente di troncamento. La ricerca lo supporta direttamente: il recupero che preserva l'ordine di poche migliaia di token ben scelti batte lo scaricare un'intera finestra di 128K token nel modello. Il vantaggio sta nella scelta di cosa entra, non in quanto può entrare.

E questa è la trappola in cui cadono la maggior parte dei team, perché lo strumento a cui ricorrono per fare la scelta ha la forma sbagliata.

Somiglianza Non È Pertinenza

Il modo predefinito per decidere quale contesto richiamare è la ricerca per somiglianza. Inserisci tutto in embedding, e quando l'agente ha bisogno di contesto, recupera i vettori più vicini alla query corrente.

Ma la somiglianza risponde alla domanda sbagliata. Restituisce ciò che è vicino, non ciò che è correlato. E sono due cose molto diverse.

La domanda a cui un agente ha effettivamente bisogno di rispondere non è mai "cosa è simile a questo". È "dato questo compito e questo stato in questo momento, cosa si collega a ciò che è importante". Questa è una domanda relazionale. Riguarda dipendenze, provenienza, cosa ha sostituito cosa e quale decisione ha causato quale risultato. Un archivio sintonizzato per recuperare vettori simili fornisce al modello un mucchio di quasi-pertinenti. E i quasi-pertinenti sono esattamente gli elementi di disturbo del primo anello, quelli che guidano l'errore a ogni passo che si accumula fino al crollo.

Questo è il motivo per cui la soluzione non può essere una cache sottile davanti a un archivio di embedding. L'intelligenza non sta nella ricerca. Sta nella struttura.

Il Livello Che Nessuno Sta Valutando

Il livello più importante da catturare nello stack degli agenti non è il modello, e non è l'archivio. È il livello intermedio. Quello che decide a cosa il modello presta attenzione.

Khairallah AL-Awady - inline image

E per fare effettivamente questo lavoro, deve essere tre cose.

Deve essere neutrale. Gli interni continuano a cambiare sotto i piedi di tutti. Da transformer a spazio di stato a ibrido. Da un modello all'avanguardia all'altro, con un nuovo leader di rapporto prezzo-prestazioni ogni pochi mesi. Una strategia di contesto saldata a un singolo modello è una scommessa su un bersaglio in movimento. La cosa in cui la tua organizzazione accumula effettivamente valore è il suo contesto, la registrazione strutturata e duramente conquistata di ciò che i tuoi agenti sanno e hanno fatto. Bloccala alle funzionalità di memoria di un singolo fornitore, e hai reso il tuo bene più durevole un ostaggio di una tabella di marcia che non è la tua. Un livello di selezione che vive al di fuori di ogni singolo modello permette allo stesso contesto organizzato di servire ogni modello che esegui, e il prossimo che non hai ancora adottato.

Deve essere orizzontale. Un checkpoint di un framework conosce una singola esecuzione. La memoria integrata di un modello conosce le conversazioni di un singolo modello. Un indice vettoriale conosce un singolo corpus. Nessuno di loro ha il quadro che conta davvero quando esegui carichi di lavoro reali: molti agenti, molte sessioni, molti modelli, tutti bisognosi di una visione coerente e interrogabile del contesto. Questo ruolo di sistema di registrazione non è qualcosa che un'app, un framework o un laboratorio è plasmato per contenere, perché ognuno vede solo la sua fetta. È un livello a sé stante, che si colloca orizzontalmente su tutti loro.

Deve essere strutturata. Questo è ciò che la separa da "solo un database migliore". La selezione è un problema di pertinenza, e la pertinenza è relazionale. La struttura sul contesto, le relazioni e le dipendenze, la provenienza e la sostituzione, è ciò che trasforma il recupero in selezione. Questo è un elemento fondamentale fondamentalmente diverso dall'archiviazione, ed è quello che il ciclo richiede.

"I Laboratori Non Lo Implementeranno Semplicemente?"

L'obiezione ovvia è che i laboratori di modelli assorbiranno questo. Continuano a pubblicare funzionalità di memoria e contesto, e hanno accesso privilegiato all'attenzione del modello stesso.

Lo faranno, e l'obiezione è giusta a metà. Per un singolo modello che avvolge una singola app, lasciare che il laboratorio se ne occupi è spesso sufficiente. Va bene.

Ma l'incentivo dei laboratori è rendere il proprio modello più appiccicoso. Questo è l'opposto della portabilità. Una curation fusa con gli interni di un singolo modello non può servire al caso multi-modello e a livello di organizzazione. Un vero substrato di contesto non compete frontalmente con queste funzionalità. Esiste per la situazione che i laboratori sono strutturalmente non inclini a servire: quella in cui esegui diversi modelli su molti agenti e team, e ti rifiuti di lasciare che il livello che decide a cosa pensano i tuoi agenti sia posseduto dal fornitore il cui modello eseguono oggi.

E la tendenza non fa che accentuare questo. Più capaci diventano i modelli, più vengono usati. Più vengono usati, più agenti un'organizzazione esegue. Più agenti esegue, più un livello di selezione neutrale, orizzontale e strutturato vale.

Chi lo sta costruendo?

È qui che entra in gioco Hydradb. Neutrale, orizzontale e strutturato. Mantiene le relazioni, le dipendenze, la provenienza e la sostituzione che la ricerca per somiglianza appiattisce. È con versione temporale e sensibile alle preferenze, e quindi sa non solo cosa è vero, ma cosa lo ha sostituito. Sblocca la visibilità su ciò che un dato agente ha imparato nel tempo. Quella struttura è ciò che trasforma il recupero in selezione.

Sotto, HydraDB funziona su un archivio a livelli: una cache in-memory calda per il contesto attivo, NVMe per il tiepido, object storage per il freddo. Il contesto viene promosso e declassato in base alla recency e all'importanza, quindi il set di lavoro su cui il modello ragiona rimane volutamente piccolo. Tra il modello e tutto ciò che potrebbe sapere.

La Domanda a Cui Ogni Agente Deve Rispondere

Togli i dibattiti sull'architettura, i prodotti di memoria, la corsa agli armamenti delle finestre di contesto. Sotto tutto questo, ogni agente a lungo termine risponde alla stessa domanda a ogni singolo passo.

Di tutto ciò che sa, a cosa dovrebbe pensare in questo momento?

Una finestra più grande non risponde a questa domanda. Dà solo all'agente più cose da ignorare. Il ciclo è reale, è permanente, e nessuna quantità di capacità lo chiude.

Il settore sta ancora cercando di uscire dal problema comprando capacità. Non può. I team che interiorizzeranno che è sempre stato un problema di selezione spediranno agenti che funzionano, mentre tutti gli altri spediranno agenti che quasi funzionano.

Questa non è mai stata una pura limitazione dei modelli. Tutto ciò che opera con un budget finito deve scegliere a cosa prestare attenzione. La selezione non è una soluzione alternativa per i limiti di oggi. È ciò che il ragionamento sotto limiti ha sempre richiesto.

Se hai trovato utile questo contenuto, seguimi @eng_khairallah1 per altri contenuti di IA come questo. Pubblico analisi, corsi e strumenti ogni settimana.

spero ti sia stato utile, Khairallah ❤️

Salva con un clic

Leggi in profondità gli articoli virali con l’AI di YouMind

Salva la fonte, fai domande mirate, riassumi l’argomentazione e trasforma un articolo virale in note riutilizzabili in un unico spazio di lavoro AI.

Scopri YouMind
Per i creator

Trasforma il tuo Markdown in un articolo 𝕏 pulito

Quando pubblichi i tuoi testi lunghi, formattare immagini, tabelle e blocchi di codice per 𝕏 è una seccatura. YouMind trasforma un'intera bozza Markdown in un articolo 𝕏 pulito e pronto da pubblicare.

Prova Markdown verso 𝕏

Altri pattern da decodificare

Articoli virali recenti

Esplora altri articoli virali