Come insegnare agli agenti LLM a ricordare il contesto e riprodurre articoli scientifici

Recentemente mi sono imbattuto nel benchmark PaperGuru, dove gli autori hanno deciso di approfondire un problema sgradevole degli agenti autonomi. Le finestre di contesto dei modelli moderni sono cresciute fino a un milione di token. Eppure le attività che si estendono su più giorni, in cui un agente deve esplorare repository, leggere decine di articoli e scrivere codice funzionante, continuano a fallire.

Di solito, tutto si riduce alla memoria. I database vettoriali trovano i frammenti di testo tramite similarità coseno, ma perdono completamente le relazioni nel tempo. Se un articolo è stato aggiornato o una libreria è diventata obsoleta, un RAG standard mescolerà allegramente un frammento obsoleto nel prompt. Nel repository PaperGuru-Benchmark, i ricercatori del team AutoTrustAI hanno rilasciato un'architettura di memoria a lungo termine con consapevolezza del ciclo di vita dei dati (Lifecycle-Aware Memory, o LAM), insieme ai risultati dei test su benchmark complessi.

Cosa non funziona nel RAG standard

Quando un agente scrive un'ampia rassegna bibliografica o riproduce codice da un articolo PDF, la ricerca con embedding piatti si blocca su cose basiche.

In primo luogo, le informazioni diventano obsolete. Se un metodo è stato confutato in un articolo più recente, un database piatto non lo sa.

In secondo luogo, le prove necessarie spesso non si trovano nel frammento che somiglia alla query per parole chiave, ma a due link di distanza nel grafo delle citazioni.

In terzo luogo, man mano che l'archivio cresce, i costi di ricerca aumentano e l'agente inizia ad affogare nel rumore.

Gli autori hanno formulato quattro regole per lavorare con la memoria:

1. Controllo delle versioni dei contenuti. Il sistema tiene traccia di modifiche, deprecazioni e ritiri di articoli.
2. Rilevanza strutturale multi-hop. La ricerca attraversa il grafo delle relazioni, non solo la similarità vettoriale.
3. Costi di query limitati con crescita infinita dell'archivio.
4. Tracciabilità delle prove. Ogni affermazione dell'agente è collegata a una fonte specifica.

Architettura Capital Chunk Memory

invece di suddividere il testo in frammenti uniformi e scaricarli in Chroma o Pinecone, l'architettura PaperGuru divide la memoria in due livelli. Il primo livello è chiamato chunk heads. Si tratta di intestazioni compatte con metadati per ogni artefatto, utilizzate per il routing rapido. Il secondo livello, chunk contents, memorizza il testo grezzo e viene caricato in modo pigro solo quando è effettivamente necessario.

Il router si basa su un grafo temporale degli artefatti. Il grafo contiene due tipi di relazioni: strutturali (ad esempio, cites, implements, benchmarked-on) e causali (deprecated-by, retracted-by, superseded-by).

La pipeline di generazione consiste in quattro passaggi:

• Ricerca: ricerca rapida di intestazioni di artefatti corrispondenti nell'archivio.
• Estrazione: estrazione dei frammenti necessari e assemblaggio delle cosiddette schede di evidenza.
• Ragionamento: un ciclo di generazione e critica in cui il modello redige e verifica la logica.
• Verifica: validazione finale con controllo dei riferimenti alle fonti.

Cosa mostrano i test

Gli autori hanno testato il sistema su due benchmark impegnativi: PaperBench di OpenAI e SurveyBench.

PaperBench valuta la capacità di un modello di prendere un PDF di un articolo di ML e scrivere un repository funzionante con la riproduzione degli esperimenti. Il livello umano di riferimento (uno studente PhD in ML con un budget di 48 ore) è del 41%.

PaperGuru ha mostrato un risultato medio del 66,05% su 23 articoli, battendo tutte le soluzioni di base pubblicate. Il risultato migliore precedente di altri agenti era del 35,74%.

Su 19 articoli su 20 con baseline note, la nuova architettura di memoria ha mostrato miglioramenti significativi. Ad esempio, nella riproduzione dell'articolo su classifier-free guidance, il risultato è cresciuto del 68%. L'unico calo si è verificato sul task PINN (-4,47%), dove la baseline originale utilizzava euristiche manuali specifiche del dominio.

Su SurveyBench, che valuta la qualità della scrittura di ampie rassegne scientifiche, il sistema ha ottenuto il 94,66% sulla qualità dei contenuti sotto un judge basato su Claude Opus.

Vale la pena guardare la metrica Richness. Non conta le valutazioni soggettive del modello linguistico, ma la presenza effettiva di grafici compilati, tabelle, codice funzionante e citazioni corrette nel materiale generato.

Qui PaperGuru ha ottenuto il 43,76%, mentre la metà degli approcci concorrenti ha segnato zero, generando testo nudo senza struttura.

Cosa c'è nel repository

Il repository è di circa 350 MB e contiene molti materiali pratici:

• Infrastructure completa del benchmark con pipeline di valutazione riproducibili
• Embedding pre-calcolati e strutture grafiche per tutti gli articoli del benchmark
• Implementazioni di base dei componenti dell'architettura LAM
• Script di valutazione e strumenti di visualizzazione
• Submission pronte all'uso per tutti i 23 articoli di PaperBench

Tutti i grafici del README possono essere ricostruiti localmente. La cartella assets/figures/ contiene un file data.json con tutte le metriche e uno script di build:

python scripts/rebuild_graphs.py

Chi dovrebbe studiare questo progetto

Se stai costruendo sistemi di agenti che lavorano con codebase di grandi dimensioni o documentazione tecnica complessa, questo repository offre un ottimo spunto di riflessione. L'idea di dividere la memoria in intestazioni leggere e un grafo delle relazioni causali si trasferisce facilmente alle basi di conoscenza aziendali.

Le submission pronte nella cartella PaperBench/submissions/ saranno utili per chi testa le proprie pipeline di generazione di codice da articoli. Lì puoi vedere come strutturare la riproduzione di pipeline ML complesse, quando il modello deve produrre non solo un singolo script, ma un albero di progetto funzionante con dipendenze e test.