>_ DevTrendsnl

Taal

Home

Talen

Secties

Frontend Backend Mobiel DevOps AI / ML GameDev Blockchain Embedded Beveiliging
Tex

Hoe LLM-agents leren om context te onthouden en wetenschappelijke artikelen te reproduceren

Onlangs stuitte ik op de PaperGuru-benchmark, waar de auteurs besloten om een vervelend probleem met autonome agents te onderzoeken. Contextvensters in moderne modellen zijn gegroeid tot een miljoen tokens. Toch falen multi-dagse taken waarbij een agent repositories moet verkennen, tientallen artikelen moet lezen en werkende code moet schrijven nog steeds.

Meestal komt alles neer op geheugen. Vector databases vinden tekstfragmenten via cosine-similariteit, maar missen volledig relaties over tijd. Als een paper is bijgewerkt of een bibliotheek verouderd is geraakt, zal een standaard RAG vrolijk een verouderd fragment in de prompt mengen. In de PaperGuru-Benchmark repository hebben onderzoekers van het AutoTrustAI-team een langetermijngeheugenarchitectuur vrijgegeven met data-levenscyclusbewustzijn (Lifecycle-Aware Memory, of LAM), samen met resultaten van het testen ervan op complexe benchmarks.

Agent performance comparison before and after PaperGuru

Wat is er mis met standaard RAG

Wanneer een agent een grote literatuurstudie schrijft of code reproduceert uit een PDF-paper, struikelt vlakke embedding-zoekopdracht over basiszaken.

Ten eerste wordt informatie verouderd. Als een methode in een recentere paper is weerlegd, weet een vlakke database dat niet.

Ten tweede ligt het benodigde bewijs vaak niet in het fragment dat qua trefwoorden op de query lijkt, maar twee stappen verwijderd in de citatiegraaf.

Ten derde, naarmate het archief groeit, stijgen de zoekkosten en begint de agent te verdrinken in ruis.

De auteurs formuleerden vier regels voor het werken met geheugen:

  1. Inhoudsversiebeheer. Het systeem houdt bewerkingen, deprecaties en intrekkingen van papers bij.
  2. Multi-hop structurele relevantie. Zoeken gaat via de relatiegraaf, niet alleen via vector-similariteit.
  3. Beperkte querykosten met oneindige archiefgroei.
  4. bewijsverificatie. Elke agentclaim is gekoppeld aan een specifieke bron.

Capital Chunk Memory Architectuur

PaperGuru CCM architecture

In plaats van tekst in uniforme chunks te verdelen en ze in Chroma of Pinecone te dumpen, splitst de PaperGuru-architectuur het geheugen in twee lagen. De eerste laag wordt chunk heads genoemd. Dit zijn compacte headers met metadata voor elk artifact, gebruikt voor snelle routing. De tweede laag, chunk contents, slaat ruwe tekst op en wordt lui geladen alleen wanneer het daadwerkelijk nodig is.

De router maakt gebruik van een temporeel artifact-graaf. De graaf bevat twee soorten relaties: structurele (bijvoorbeeld cites, implements, benchmarked-on) en causale (deprecated-by, retracted-by, superseded-by).

Memory pipeline

Het generatiepipeline bestaat uit vier stappen:

  • Zoeken: snel zoeken naar overeenkomende artifact-headers in het archief.
  • Extraheren: benodigde fragmenten ophalen en zogenaamde evidence cards samenstellen.
  • Redeneren: een generatie- en criticacyclus waarbij het model een concept opstelt en de logica controleert.
  • Verifiëren: finale validatie met bronreferentiecontrole.
Pipeline animation

Wat de tests laten zien

De auteurs testten het systeem op twee veeleisende benchmarks: PaperBench van OpenAI en SurveyBench.

PaperBench evalueert het vermogen van een model om een ML-paper PDF te nemen en een werkende repository te schrijven met experimentreproductie. De menselijke baseline (een ML PhD-student met een budget van 48 uur) is 41%.

Overall PaperBench results

PaperGuru behaalde een gemiddeld resultaat van 66,05% op 23 papers, en versloeg daarmee alle gepubliceerde baseline-oplossingen. Het vorige beste resultaat van andere agents stond op 35,74%.

Results by individual papers

Op 19 van de 20 papers met bekende baselines toonde de nieuwe geheugenarchitectuur significante verbetering. Op de reproductie van de classifier-free guidance-paper groeide het resultaat bijvoorbeeld met 68%. De enige daling deed zich voor bij de PINN-taak (-4,47%), waar de originele baseline handmatige domeinspecifieke heuristieken gebruikte.

Quality improvement distribution

Op SurveyBench, dat de kwaliteit evalueert van het schrijven van grote wetenschappelijke reviews, behaalde het systeem 94,66% op inhoudskwaliteit onder een judge gebaseerd op Claude Opus.

SurveyBench radar chart

Het is de moeite waard om naar de Richness-metriek te kijken. Deze telt niet subjectieve taalmodelbeoordelingen, maar de daadwerkelijke aanwezigheid van gecompileerde grafieken, tabellen, werkende code en correcte citaties in het gegenereerde materiaal.

Structure and content richness

Hier scoorde PaperGuru 43,76%, terwijl de helft van de concurrerende benaderingen nul scoorde, en alleen kale tekst zonder structuur genereerde.

Accepted papers

Wat er in de repository zit

De repository is ongeveer 350 MB en bevat veel praktische materialen:

  • Complete benchmark-infrastructuur met reproduceerbare evaluatiepipelines
  • Vooraf berekende embeddings en graafstructuren voor alle benchmark-papers
  • Baseline-implementaties van LAM-architectuurcomponenten
  • Evaluatiescripts en visualisatietools
  • Kant-en-klare inzendingen voor alle 23 PaperBench-papers

Alle grafieken uit de README kunnen lokaal opnieuw worden opgebouwd. De assets/figures/-map bevat een data.json bestand met alle metrieken en een build-script:

python scripts/rebuild_graphs.py

Voor wie is dit project interessant

Als je agent-systemen bouwt die werken met grote codebases of complexe technische documentatie, biedt deze repository uitstekend studiemateriaal. Het idee van het splitsen van geheugen in lichtgewicht headers en een causale relatiegraaf is gemakkelijk over te zetten naar zakelijke kennisbanken.

Kant-en-klare inzendingen in de PaperBench/submissions/-map zijn nuttig voor degenen die hun eigen codegeneratiepipelines uit papers testen. Daar kun je zien hoe je de reproductie van complexe ML-pipelines moet structureren, wanneer het model niet alleen een enkel script moet uitvoeren, maar een werkende projectboom met afhankelijkheden en tests moet produceren.