Meget nørdet - med nogle detaljer, der kan bruges af alle: Recursive Language Models
Trin 5 — Hvordan du undgår at den hallucinerer
Tre enkle regler gør det markant bedre:
-
Ingen påstand uden sidehenvisning.
-
Hvis der ikke findes støtte i teksten: den skal sige “jeg kan ikke finde det”.
-
Hold evidens-teksten lille: hellere 3–6 præcise citater end 2 sider limet ind.
“ELI5” af Recursive Language Models (RLMs):
Forestil dig, at en almindelig chatbot har et lille skrivebord (sin “context window”). Hvis du giver den en kæmpe bunke papirer, kan den kun have lidt ad gangen på bordet — og jo længere bunken er, jo mere “glemmer”/roder den rundt i det (“context rot”).
RLM-idéen er: Lad være med at smide hele bunken op på skrivebordet.
I stedet lægger man bunken på gulvet (som “miljøet”), og chatten får et værktøj (en lille Python/REPL), så den kan:
kigge i teksten (fx “vis mig linje 1000–1100”)
søge (fx med regex: find alle steder der nævner “festival”)
dele op i bidder (chunking)
og vigtigst: kalde en lille “hjælpe-chatbot” (sub-LLM) på udvalgte bidder, flere gange, og samle svaret til sidst (rekursion).
Hvorfor er det smart?
Den kan håndtere meget længere input (de siger op til 10M+ tokens i tests) uden at skulle have det hele i hukommelsen på én gang.
Den kan være bedre end “bare at opsummere alt”, fordi den kan gå tilbage og hente præcise detaljer i stedet for at erstatte dem med en grov summary.
Den kan ofte gøre det til samme eller lavere pris, fordi den kun læser det nødvendige (men prisen kan variere meget, afhængigt af hvor lang dens “tur” bliver).
En ultra-kort analogi
Normal LLM: “Jeg læser hele bogen på én gang (eller prøver) og svarer.”
RLM: “Bogen ligger ved siden af mig. Jeg bladrer, søger, tager noter, spørger en hjælper om kapitel 7, og samler svaret.”
Hvis du vil, kan jeg også lave en ELI5 af figuren med “REPL-miljøet” (side 2) og forklare præcis, hvad “rekursiv sub-calling” betyder i praksis.
Ja og nej.
Ja: det er forskning i en “ramme/strategi” for, hvordan man kan få LLM’er til at håndtere ekstremt lange input bedre. De kalder det en general inference strategy og skriver eksplicit, at de “proposer Recursive Language Models (RLMs)” som en måde at behandle arbitrært lange prompts ved at lægge prompten i et eksternt miljø og lade modellen undersøge/opfatte den stykkevist og lave rekursive selv-kald.
Nej: det er ikke kun noget “i fremtiden” – de har faktisk implementeret og evalueret det allerede som et system omkring eksisterende modeller. I metoden beskriver de en konkret instans: en Python REPL hvor hele konteksten ligger som en variabel, og hvor modellen kan kalde en sub-LLM via en funktion (altså en orchestrering/scaffolding).
De evaluerer også RLM’er med konkrete modeller (bl.a. GPT-5 og Qwen3-Coder) på flere benchmarks og viser, at de kan håndtere input langt ud over kontekstvinduet (op i 10M+ tokens i deres opsætning).
Så den praktiske konklusion:
Du kan i princippet bruge idéen i dag, hvis du kan bygge en agent/scaffold der giver modellen et miljø (fx REPL), værktøjer til at “kigge” i tekst, og mulighed for at lave sub-kald. Det er netop sådan de gør.
Men det er ikke en standard “feature” i selve modellen; det er en system-arkitektur omkring modellen, og de nævner selv, at den optimale implementering stadig er “underexplored”, og at der er performance-/runtime-issues (fx synkrone subkald er langsomme), og at man måske i fremtiden bør træne modeller specifikt til at være gode RLM’er.
Hvis du fortæller mig, hvad du gerne vil bruge det til (fx “læse 5.000 siders PDF’er”, “kodebase-analyse”, “journal/arkiv”), kan jeg foreslå en simpel “RLM-light” opskrift, der ligger tæt på deres idé men er realistisk i en almindelig IT-organisation.
Super — her er en “RLM-light” opskrift til at læse og spørge til 5.000 siders PDF’er, som du kan bruge i dag uden at skulle vente på ny model-forskning.
Målet
I stedet for at “fodre” hele PDF’en til en LLM (umuligt), bygger du et lille system hvor modellen kan:
søge i materialet
åbne præcis de sider/afsnit den har brug for
samle et svar med sidehenvisninger
Det er i praksis den samme idé som RLM: eksternt miljø + værktøjer + iterativ læsning.
Trin 1 — Gør PDF’en “læsbar”
Du skal have tekst ud pr. side.
Tekstbaseret PDF (kan markere tekst i en PDF-læser): brug fx
pdftotexteller PyMuPDF til at få tekst pr. side.Scannet PDF (billeder): brug OCR (fx Tesseract eller en enterprise OCR-løsning).
Tip: lav OCR pr. side og gem “hvilken side” teksten kommer fra. Det er helt afgørende.
Gem resultatet som fx:
doc_pages/page_0001.txtdoc_pages/page_0002.txt… (én fil pr. side)
Trin 2 — Byg en hurtig “find i hele bogen”
Du vil have noget, der kan returnere de bedste sider til et spørgsmål.
Muligheder (fra simpel til mere robust):
Simpelt/effektivt:
ripgrep/regex søgning i side-tekstfilerne (hurtigt og overraskende godt).Mere struktureret: SQLite med FTS5 (full-text search).
Større/enterprise: Elasticsearch / OpenSearch (I er allerede i den verden, gætter jeg).
Det vigtige er: search("ord eller frase") -> liste af sider + score.
Trin 3 — Giv modellen tre “værktøjer”
Det er her magien sker. Modellen skal kunne kalde funktioner (du kan implementere dem i Python, PowerShell, hvad som helst):
search(query)
Returnér fx top 20 sider + 1-2 linjers snippet hver.open_page(page_no)
Returnér teksten fra den side (evt. + nabo-sider, hvis det er et afsnit der går over sideskift).open_range(page_from, page_to)
Når modellen finder det rigtige kapitel, skal den kunne åbne 5–20 sider i ét hug.
(Det her svarer til “REPL-miljøet” i RLM-papiret, bare i en praktisk udgave.)
Trin 4 — LLM’ens læsestrategi (den “rekursive” del)
Når du spørger: “Hvad siger dokumentet om X?”, skal modellen arbejde sådan her:
Planlæg søgeord (synonymer, forkortelser, danske/engelske varianter)
search() og få relevante sider tilbage
Åbn 3–8 sider og vurder: er det relevant?
Hvis ja: udvid til et side-interval (fx hele afsnittet/kapitlet)
Lav et svar med:
konklusion
nøglecitater (korte)
sidehenvisninger (så du kan verificere)
Det er “rekursion” i praksis: søg → læs lidt → zoom ind → læs mere → konkludér.
Trin 5 — Hvordan du undgår at den hallucinerer
Tre enkle regler gør det markant bedre:
Ingen påstand uden sidehenvisning.
Hvis der ikke findes støtte i teksten: den skal sige “jeg kan ikke finde det”.
Hold evidens-teksten lille: hellere 3–6 præcise citater end 2 sider limet ind.
Trin 6 — To arbejdsmønstre der virker godt
A) “Find politikken/kravet”
Spørgsmål som: “Er X tilladt / krævet / frarådet?”
søg efter: “skal”, “må”, “skal ikke”, “krav”, “shall/must/may”, “procedure”, “ansvar”
find afsnittet og returnér ordlyd + side
B) “Lav overblik over 5.000 sider”
Kør en hierarkisk opsummering:
først: 1 linje pr. 10 sider (500 linjer)
så: 1 linje pr. 50 sider (100 linjer)
så: kapiteloversigt + stikord
derefter: målrettet Q/A med sideopslag
Det giver dig et “kort” over dokumentet, så senere spørgsmål bliver meget hurtigere.
Trin 7 — Helt konkret “prompt-skabelon” til modellen
Du kan bruge noget i stil med:
Opgave: Besvar spørgsmålet kun ud fra dokumentet.
Metode: Brug
search()først, åbn derefter relevante sider medopen_page()/open_range().Krav: Alle vigtige påstande skal have (side X). Hvis du ikke kan finde det, sig det.
Det lyder banalt, men det tvinger modellen ind i den rigtige arbejdsform.
Praktisk anbefaling til dig (IT-hverdagsrealistisk)
Hvis du vil have en “version 1” der kan bygges hurtigt:
tekstudtræk pr. side
ripgrep-baseretsearch()open_page()der returnerer side-tekst + sidetalen lille wrapper (CLI eller web) der lader dig stille spørgsmål og får svar med sidehenvisninger
Hvis du vil, kan jeg skrive en meget lille reference-implementering (fx Python) af de tre værktøjer + en “agent-loop”, som du kan pege på en PDF-mappe og bruge med det samme. Fortæl bare om PDF’erne typisk er scannede eller tekstbaserede, så vælger jeg den rigtige pipeline.
Kommentarer
Send en kommentar