Andrej Karpathy har delt en ret jordnær idé med et lidt stort navn: en “LLM Knowledge Base”. Kernen er enkel nok til, at den næsten ikke lyder som en nyhed. I stedet for at lade en sprogmodel glemme alt, når en session slutter eller rammer sit loft, bygger man en vedvarende videnbase, som modellen selv er med til at vedligeholde. Det er mindre et nyt buzzword end en arbejdsform.

Og det er faktisk mere interessant, end det først lyder. For det problem, Karpathy går efter, er ikke futuristisk. Det er den meget konkrete frustration, hvor et team igen skal fodre modellen med projektets baggrund, beslutninger, undtagelser og gamle noter, fordi konteksten er væk.

En reaktion på stateless AI

Ifølge VentureBeats gennemgang beskrev Karpathy selv en “LLM Knowledge Bases”-tilgang, som han bruger til at håndtere forskellige forskningsområder. Det nye er ikke bare, at han organiserer noter. Det er, at han beskriver en vedvarende, LLM-vedligeholdt registrering af projekter som svar på et helt konkret problem: AI-sessioner mister kontekst, når de slutter, eller når man rammer brugsgrænser.

Der er også noget befriende i, at han ikke pakker det ind som et opgør med al hidtidig arkitektur. Karpathy bliver i den dokumenterede beskrivelse præsenteret som en, der foreslår noget enklere end den typiske enterprise-model med vector database og RAG-pipeline til mellemstore datasæt. Ikke til alt. Ikke som en universel sandhed. Bare som en enklere vej i de tilfælde, hvor kompleksiteten er begyndt at koste mere, end den giver tilbage.

RAG er stadig nyttigt, men det er også blevet tungt

Det er værd at få proportionerne på plads. Retrieval-augmented generation, RAG, er ifølge VentureBeat blevet den dominerende metode de seneste tre år, når virksomheder vil give sprogmodeller adgang til egne data. Standardopskriften er velkendt: dokumenter deles op i chunks, omdannes til embeddings, lagres i en vector database og hentes senere via similarity search, så relevante bidder kan gives til modellen sammen med brugerens spørgsmål.

Det virker. Ofte ret godt. Men der er også kommet en hel industri af små justeringer oven på de samme fire trin: chunk-størrelse, overlap, embedding-model, retriever-logik, ranking, cachelag, filtre og evaluering. Når det spiller, ser det flot ud på slides. Når det ikke gør, sidder nogen og prøver at forstå, hvorfor det rigtige dokument ikke blev hentet, selv om systemet på papiret var sat korrekt op.

Det er præcis her, Karpathys idé lander. Ikke som dom over RAG, men som en påmindelse om, at nogle vidensproblemer måske ikke behøver en specialdatabase og et matematisk mellemled, hvis datasættet er til at overskue, og hvis modellerne er blevet bedre til at læse struktureret tekst direkte.

Sådan er arkitekturen skruet sammen

Den verificerede kerne i modellen er ret konkret. Rå materiale, for eksempel forskningspapirer, GitHub-repositorier, datasæt og webartikler, lægges ind i en rå mappe. VentureBeat beskriver også, at Karpathy bruger Obsidian Web Clipper til at omdanne webindhold til Markdown-filer, og at billeder lagres lokalt, så modellen i princippet kan referere til dem via synsfunktioner.

Herefter sker det afgørende trin: modellen indekserer ikke bare materialet, den “kompilerer” det. Den læser rådata og skriver en struktureret wiki i Markdown. Det omfatter opsummeringer, identifikation af nøglebegreber, mere leksikale artikler og links mellem beslægtede emner. Altså ikke bare lagring, men aktiv organisering. En slags forskningsbibliotekar, som VentureBeat kalder det.

Og systemet stopper ikke dér. Karpathy beskriver også vedligeholdelsesforløb, hvor modellen laver health checks eller linting. Den scanner efter uoverensstemmelser, manglende oplysninger og nye sammenhænge, som bør forbindes. Det er nok det mest dristige element i idéen, fordi det flytter modellen fra at være en spørgemaskine til at være medredaktør på et levende videnslag.

Markdown er kedeligt, og det er næsten pointen

Markdown er ikke sexet, og det er måske netop derfor, det er interessant. VentureBeat gengiver rationalet ret klart: formatet beskrives som LLM-venligt, kompakt, menneskeligt læsbart og auditerbart. Det sidste betyder mere, end man skulle tro. For når en model svarer på baggrund af en vector embedding, er det sværere at se, hvad den præcist byggede på. Når kilden er en konkret .md-fil, kan et menneske læse den, rette den eller slette den.

Det her er måske lidt niche, men læsbarhed er undervurderet i AI-drift. Når noget går galt, vil de fleste teams hellere kunne åbne en fil og se, hvad der står, end grave i et lag af transformationer og scoringer. Ting, man kan åbne og læse, overlever som regel længere end ting, kun specialister kan forklare.

Er det så bare RAG i ny forklædning

Det oplagte modspørgsmål er, om Karpathy i virkeligheden bare flytter retrieval et andet sted hen. Og ja, lidt. Der er stadig et lag af udvælgelse, struktur og genfinding i spil. Men designprincippet ser anderledes ud. I klassisk RAG er målet ofte at kunne søge effektivt i store, fragmenterede mængder indhold gennem embeddings og vektorsøgning. I Karpathys opsætning er pointen, ifølge den dokumenterede beskrivelse, at modellen i højere grad skal ræsonnere over et kompileret, struktureret tekstlag.

Det er en reel forskel. Ikke nødvendigvis en revolution, men en forskel. Viden bliver ikke først og fremmest gjort søgbar som numeriske repræsentationer. Den bliver gjort læsbar. Det lyder næsten gammeldags, men også sundt.

Samtidig skal man passe på de smarte dødsdomme. RAG er ikke død. For store eller meget ustrukturerede datamængder er vector search stadig stærkt, og det er der intet i kilderne, der rokker ved. Nyheden er ikke et farvel til retrieval. Nyheden er, at et andet mønster begynder at se praktisk ud for en bestemt klasse af problemer.

Hvor det giver mening i virksomheder

Hvis man oversætter idéen til dansk virksomhedsvirkelighed, giver den især mening der, hvor projektviden skifter hurtigt, men ikke er enorm i volumen. Et produktteam med mange beslutningsnoter, ændringer i krav og tekniske kompromiser kunne være et oplagt sted. I stedet for at have informationen spredt over chats, tickets, mødenoter og halvdøde dokumenter, kunne en AI-vedligeholdt Markdown-base fungere som et fælles arbejdslager, som både mennesker og modeller kan læse.

Et andet oplagt område er analyse- og compliance-arbejde. Ikke fordi regulering pludselig bliver nem, men fordi sporbarhed betyder noget. Hvis en model opsummerer en politik eller peger på et tidligere notat, er det en fordel, at kilden ligger i en konkret fil med versionshistorik.

Konsulenthuse og andre miljøer med mange parallelle cases er også et godt eksempel. Der opstår hurtigt et rod af genbrugte prompts, gamle analyser og halvglemte beslutninger. Her kunne et kompileret Markdown-lag gøre det lettere at fastholde, hvad der faktisk blev besluttet i et projekt, og hvad der bare blev sagt i en chat.

Det kræver stadig disciplin

Skeptikerne har også nogle fair indvendinger. En AI-vedligeholdt Markdown-base vedligeholder ikke sig selv på magisk vis, selv om formuleringen kan friste. Hvis modellen skriver dårlige opsummeringer, bygger svage links eller overser vigtig kontekst, får man bare et mere læsbart rod. Og rod i Markdown er stadig rod.

Derfor er det vigtigt at holde fast i, hvad kilderne faktisk viser. VentureBeat dokumenterer Karpathys forslag og beskriver arkitekturen, men leverer ikke brede benchmark-resultater. Der er ingen verificerede tal i materialet, som viser lavere fejlrate, lavere totalomkostning eller bedre præcision på tværs af virksomheder. Den del ved vi simpelthen ikke endnu.

Det er også her, Snilld-perspektivet er nyttigt: Idéen er praktisk interessant, men implementeringen afgør, om det bliver robust drift eller bare en pæn demo. Governance, versionskontrol, evaluering og adgang til data forsvinder ikke, bare fordi videnslaget bliver mere læsbart.

Det store spørgsmål er drift, ikke teori

Det mest interessante ved historien er egentlig ikke selve teknikken. Det er, hvor meget den peger væk fra AI som ren modeldiskussion og hen mod noget mere lavpraktisk: hvordan viden faktisk vedligeholdes over tid. Mange teams har brugt enorm energi på modelvalg og alt for lidt på, hvordan beslutninger, kilder og domæneforståelse bliver gemt, rettet og genbrugt. Karpathy prikker til det problem uden at gøre det større, end det er.

Hvis modellerne virkelig bliver bedre til at ræsonnere over struktureret tekst, som VentureBeat beskriver som en central præmis i hans forslag, kan det få betydning for, hvordan mellemstore AI-løsninger bliver bygget fremover. Måske bliver den bedste løsning ikke altid mere retrieval-infrastruktur. Måske er det nogle gange en roligere opsætning med filer, links, versionsstyring og en model, der kan hjælpe med at holde orden.

Og nej, man skal ikke smide sin nuværende RAG-arkitektur ud i morgen. Men man bør nok kigge ærligt på sit videnslag og spørge, om det er blevet tungere, end opgaven kræver. Hvis svaret er ja, så er Karpathys Markdown-idé ikke bare en kuriositet fra X og VentureBeat. Den er et ret konkret tegn på, at AI-arbejde er ved at bevæge sig fra flotte arkitekturskitser til noget, folk faktisk kan holde ud at drive.

Kilder

• Karpathy shares 'LLM Knowledge Base' architecture that bypasses RAG with an evolving markdown library maintained by AI
• Andrej Karpathy shares 10 LLM use cases – LinkedIn
• Software 2.0 easily automates what you can verify.
• AI and AGI: Insights from Andrej Karpathy and Scott Hanselman
• Andrej Karpathy
• Andrej Karpathy is leaving Tesla after 5 years with the company
• Andrej Karpathy Is in Trouble – by Dan Meyer – Mathworlds