I to år var standardsvaret på “hvordan giver jeg en LLM min viden?” RAG. Byg en vektordatabase. Chunk dine dokumenter. Embed dem. Kør nearest-neighbor-søgning ved forespørgselstidspunkt. Sy resultaterne tilbage i prompten.

Det virkede. Et stykke ad vejen. Alle der faktisk har shippe et RAG-system, kender fejltilstandene: chunks der mister kontekst, embeddings der henter det forkerte afsnit, uigennemsigtige rankinger, ingen proveniensdata, mærkelige edge cases når brugeren spørger om noget, indekset ikke var tunet til.

I april 2026 postede Andrej Karpathy en workflow, der gør næsten intet af det og fungerer bedre til personlig viden. Han kalder det LLM Knowledge Bases. Arkitekturen er bare en mappe med markdown-filer, en LLM med filsystemadgang og en vane. VentureBeat kaldte det “et udviklende markdown-bibliotek vedligeholdt af AI” — en beskrivelse der fanger, hvad der faktisk er nyt.

Post-RAG-mønstret er her. Denne artikel forklarer, hvad det er, hvorfor det virker, og hvordan Save Vault gør det tilgængeligt uden nogen udviklerkonfiguration.

Hvad RAG forsøgte at løse

Det oprindelige problem: LLM’er har et fast kontekstvindue, din vidensbase er større end vinduet, så du har brug for en måde at hente den relevante del til hvert spørgsmål.

I 2023 var vektorer det oplagte svar. Embed alt, søg ved similaritet, injicer de øverste k chunks. Det komponerede pænt med de små kontekstvinduer i GPT-3.5 og Claude 1. Hele “AI-startup”-mønstret var “RAG over X.”

Tre ting ændrede sig.

Kontekstvinduer eksploderede. Claude shippede 1M-token kontekst i år. Gemini og GPT-5 er lignende. En million tokens er omtrent 750.000 ord — nok til at holde en lille wiki helt i hukommelsen.
Filsystem-MCP shippede. LLM’er kan nu åbne filer på disk direkte. De behøver ikke præ-indekserede chunks. De kan navigere, læse og genlæse som et menneske.
LLM’er blev bedre til at læse. Claude Opus 4 kan indlæse hundredvis af filer i én session og ræsonnere på tværs af dem kohærent. Flaskehalsen flyttede fra “hentningskvalitet” til “hvad brugeren faktisk har brug for.”

Når de tre ting var sande, begyndte RAG at se ud som en workaround for begrænsninger, der ikke længere eksisterer.

Sådan ser Markdown-wiki-mønstret ud

Karpathys opsætning, forenklet:

Raw-mappe. Hver webside han vil beholde, gemmes som en .md-fil i en raw/-mappe. Han bruger Obsidian Web Clipper til dette.
Kompileringspas. Periodisk læser en LLM-agent (Claude Code i hans tilfælde) alt i raw/, genererer konceptsider, skriver resuméer og skaber backlinks. Dette producerer en struktureret wiki oven på råmaterialet.
Forespørgselsloop. Når han har et spørgsmål, spørger han LLM’en. Den søger i wikien, åbner de relevante filer og svarer ved hjælp af indholdet.
Lint-pas. Lejlighedsvis scanner LLM’en wikien for inkonsistenser, manglende data eller nye forbindelser værd at registrere.

Hans nuværende research-wiki er ~100 artikler og ~400K ord. Han stiller komplekse spørgsmål og får kildeangivne svar tilbage.

Ingen vektordatabase. Ingen embedding-model. Ingen chunking-strategi. Ingen hentningsranking. Bare markdown-filer, en mappestruktur og en LLM, der kan læse dem.

Hvorfor det virker bedre end RAG (til dette formål)

Wiki-mønstret har strukturelle fordele, som RAG ikke kan matche uden selv at blive en wiki.

Proveniensdata er gratis. Hvert svar citerer en fil. Du kan åbne den, læse den, redigere den, slette den. Ingen “embedding sagde det.”

Redigering er trivielt. En markdown-fil er tekst. Åbn den i enhver editor. Ret en stavefejl. Tilføj en note. Slet et afsnit. Den næste forespørgsel afspejler ændringen øjeblikkeligt. Der er intet genindekseringstrin.

Struktur akkumulerer. Når LLM’en kompilerer wikien, bygger den backlinks og konceptsider. Wikien bliver bedre, jo mere du gemmer, fordi LLM’en har mere kontekst til at forbinde nye indgange. Et vektorindeks bliver bare større.

Portabilitet er total. En mappe med .md-filer fungerer i Obsidian, VS Code, GitHub, Logseq, vim eller cat. En vektordatabase er en sort boks, du har brug for et specifikt runtime til at læse.

Du kan selv læse den. Det lyder oplagt, men det er den største fordel. Nogle gange vil du gerne vide, hvad der er i din vidensbase. Med RAG er det en rapporteringsforespørgsel. Med markdown er det ls.

Den ærlige afvejning: RAG vinder stadig, når du har millioner af dokumenter, multi-tenant adgang eller hårde latenskrav (tænk kundeservicechatbots over et korpus med millioner af hjælpeartikler). Til personlig viden — din læsning, din forskning, dit domæne — er wiki-mønstret nu strengt bedre.

Det manglende stykke: Indtagelse

Karpathys mønster har en stille antagelse: at det er nemt at få rent markdown ind i raw/-mappen. For udviklere, der allerede bruger Obsidian Web Clipper, er det stort set det. For alle andre er dette det trin, hvor workflow’en dør.

Web Clipper kan have problemer med sider bag betalingsmure, JavaScript-tunge sites, videoindhold, X-tråde og alt dynamisk. Folk gemmer rodet HTML, giver op og konkluderer “wiki-tingen er ikke til mig.”

Save-udvidelsen eksisterer specifikt til at løse dette trin. Den bruger Gemini til at udtrække rent indhold fra vilkårlige sider, herunder:

Artikler bag betalingsmure, du har adgang til
YouTube-videoer (fuld transskription + AI-resumé)
X/Twitter-tråde
Instagram-reels og TikTok-undertekster (transskriberet)
Reddit-diskussioner
Dokumentation med kodeblokke intakt
Dynamiske SPAs, som traditionelle clippers kvæler på

Ét klik. Rent markdown ud på den anden side. Drop det i mappen.

Det andet manglende stykke: MCP-opsætning

Karpathys mønster antager også, at du kan konfigurere en MCP-server. For Claude Code-brugere er det en one-line cd. For alle der bruger Claude Desktop, betyder det redigering af en JSON-konfigurationsfil og genstart af appen — og at få stien rigtigt, og huske at gøre det igen, når du flytter mapper.

Save Vault samler begge manglende stykker i én app:

Save-udvidelsen feeder rent markdown ind i Save Vault automatisk
Save Vault skriver til ~/Documents/Save Vault/ organiseret i videnbaser (undermapper)
En indbygget MCP-server eksponerer list_knowledge_bases, list_files, read_file og search for Claude
“Forbind til Claude”-knappen i menulinjen forbinder MCP-serveren til Claude Desktop og Claude Code, ingen JSON-redigering

Resultatet er Karpathy-mønstret med de skarpe kanter slebet af. Gem en side → den lander i dit vault → Claude kan besvare spørgsmål om det. Ingen vektordatabase, ingen chunking, ingen embeddings.

Sådan ser det ud i praksis

Forestil dig, at du undersøger en konkurrent.

Dag 1. Du gemmer deres prisside, tre blogindlæg og en Hacker News-tråd om deres seed-runde. Fem filer i din Competitors KB.

Dag 5. Du spørger Claude: “Hvilke prisændringer har dette firma foretaget i det seneste år, og hvordan har kunder reageret?” Claude søger i din Competitors KB, læser de relevante filer, citerer prissiden, fremhæver HN-trådens sentiment og svarer — alt kildeangivet.

Dag 30. Du har 40 filer på tværs af Competitors, Customers og AI Research. Du beder Claude om at kompilere hver KB til en wiki. Den skriver konceptsider, linker dem, markerer modsigelser. Nu har du tre levende wikier, du kan forespørge som søgemaskiner, men bedre — fordi de kun indeholder det, du kuraterede.

Dag 90. Dine wikier er større end nogen analytikerrapport, du ville købe, mere aktuelle end nogen konsulentpræsentation og helt dine egne. Hvert påstand er kildeangivet til en fil, du gemte.

Det er, hvad en personlig vidensbase faktisk føles som, når friktionen er væk. RAG var ment til at levere dette og gjorde det ikke. Karpathy-mønstret gør — når indtagelses- og MCP-stykkerne er konfigureret for dig.

Prøv det

Installer Save Chrome-udvidelsen
Installer Save Vault fra savemarkdown.co
Slå Forbind til Claude til i menulinjen
Gem 10 ting, du har haft i tankerne at læse
Åbn Claude og stil et spørgsmål, der syr dem sammen

Det er post-RAG-workflow’en. Den erstatter allerede vektordatabaser til personlig viden. Det eneste, der er tilbage, er at begynde at bygge din.

Save Vault er gratis. Save-udvidelsen er gratis for 3 gemmer om måneden, 3,99 $/måned ubegrænset. savemarkdown.co.