Den komplette guide til Karpathys LLM-wiki-workflow

Fem dage efter at Andrej Karpathy skrev om sin "LLM-wiki"-workflow, havde internettet allerede produceret mere end femten fungerende implementeringer, et casestudie fra en dagbog med 2.500 indtastninger og en igangværende diskussion om, hvorvidt det hele bare er RAG med ekstra trin. Tweetet ligger på seksten millioner visninger. Den opfølgende gist har passeret fem tusind stjerner og 1.483 forks. Folk læser ikke dette som en kommentar — de læser det som en instruktion.

Denne guide er til læsere i den anden lejr. Den gennemgår, hvad Karpathy rent faktisk byggede, de præcise værktøjer han nævnte, mappestrukturen der holder hele molevitten sammen, community-implementeringerne der skubber idéen i nyttige retninger, og de steder hvor den stille falder fra hinanden. Den forudsætter, at du vil bygge en selv.

Hvad Karpathy rent faktisk byggede

Den 2. april 2026 udgav Karpathy et kort opslag på X og en længere gist, der beskrev en personlig videnworkflow. Indramningen betød lige så meget som indholdet. Han skrev, at "en stor del af mit seneste token-gennemløb går mindre til at manipulere kode, og mere til at manipulere viden" — en bemærkelsesværdig indrømmelse fra en, hvis offentlige identitet er bygget på at skrive noget af det mest læste deep learning-kode det seneste årti.

Kernebeskrivelsen, fra gisten, er én sætning, der er værd at citere præcist:

"I index source documents into a raw/ directory, then I use an LLM to incrementally 'compile' a wiki, which is just a collection of .md files in a directory structure."

Det er hele mekanismen. Rå inputs lander i én mappe. En LLM læser dem og sender linkede markdown-filer til en anden mappe. LLM'en er ansvarlig for krydsreferencerne, indekset, overskrifterne, formateringen og — kritisk — for at gå tilbage og opdatere tidligere sider, når ny information kommer ind. Mennesket betjener wikien gennem Obsidian, ikke gennem en egen brugerflade.

Karpathy indrammede det som et "vibe-kodet" personligt system, ikke et produkt. Den indramning er en del af grunden til, at det spredte sig: det var åbenlyst reproducerbart for enhver med en terminal og en LLM-nøgle. Inden for 48 timer forkede folk gisten og pushede fungerende repoer. Inden for fem dage havde økosystemet nok variation til at tale om best practices.

De præcise værktøjer Karpathy bruger

Karpathy var specifik omkring sin stack. Det er værd at liste delene i deres helhed, for en stor del af den sekundære kommentar har været sjusket på dette punkt.

• Obsidian — frontend og IDE. Karpathy browser, forespørger og redigerer wikien gennem Obsidians markdown-native brugerflade. Han byggede ikke en egen UI. Dette er en bevidst adskillelse: AI'en skriver filerne, Obsidian læser dem.
• Obsidian Web Clipper — indtagelsesvejen for webartikler. Den konverterer sider til ren markdown, der lander i raw/ uden manuel copy-paste.
• Et eget, vibe-kodet CLI/websøgeværktøj — Karpathy nævner et lille søgelag, han selv skrev til at opdage kildedokumenter. Han offentliggjorde det ikke. Det er en særpræget del, som de fleste reimplementeringer erstatter med ripgrep eller en tredjepartssøgning.
• qmd af Tobi Lütke — Shopifys CEO sendte et hybrid BM25 + vector search-værktøj, som Karpathy fremhævede som skaleringsvejen, når en wiki vokser ud af én enkelt indeksfil. qmd er svaret på "hvad gør jeg, når index.md ikke længere passer i konteksten."
• Marp — markdown til slides. Karpathy bruger sin wiki som sandhedskilde for foredrag. Et slidedeck er bare endnu et kompileret output fra det samme indhold.
• Dataview — et Obsidian-plugin til at forespørge mod frontmatter. Hvis hver side har et confidence: 0.7- eller stale: true-felt, forvandler Dataview vaulten til en forespørgbar database uden at forlade markdown.
• matplotlib — Karpathy lader LLM'en generere Python-plots fra struktureret data i wikien og rendere dem som billeder ved siden af prosaen. Diagrammer er kompilerede, ikke håndtegnede.
• Git — versionering for både raw/ og wiki/. Hver LLM-redigering bliver en commit, hvilket betyder, at du kan diffe, hvad modellen gjorde, og rulle tilbage, når den hallucinerer.

Han navngav ikke en specifik LLM. Men skemafilen i hans gist hedder CLAUDE.md, som er konventionen brugt af Claude Code. Communityet har taget dette som et stærkt hint om, at den primære driver er Claude Code, der opererer på en lokal mappe.

Arkitekturen: raw/ vs wiki/

Mappestrukturen er den bærende idé. Næsten enhver fejl i de tidlige reimplementeringer kan spores tilbage til at sløre de to mapper.

knowledge/
├── raw/           # immutable source documents (never edited by LLM)
│   ├── articles/
│   ├── papers/
│   ├── notes/
│   └── transcripts/
├── wiki/          # LLM-owned markdown (rewritten on every ingest)
│   ├── index.md
│   ├── people/
│   ├── concepts/
│   └── projects/
└── CLAUDE.md      # schema, conventions, instructions for the agent

raw/ er uforanderlig. Du dropper filer ind, LLM'en læser dem, intet skriver tilbage. Hvis du redigerer en rå fil, redigerer du dine kilder, og wikien bliver en løgn. Behandl den som et read-only arkiv. De fleste implementeringer håndhæver dette med en git pre-commit-hook eller et simpelt chmod.

wiki/ ejes af LLM'en. Du redigerer ikke wiki-sider i hånden. Gør du det, vil det næste ingest stille overskrive dine ændringer. Hvis du vil rette noget, så ret enten det underliggende rådokument eller tilføj en instruktion i CLAUDE.md. Det føles strengt, og det er det, men det er den eneste måde, den "selvvedligeholdende" egenskab holder.

CLAUDE.md (eller AGENTS.md) er skemafilen. Den fortæller agenten, hvilke konventioner der gælder: hvordan filer navngives, hvilke frontmatter-felter der kræves, hvilken stil prosaen skal være i, hvordan modsigelser håndteres, hvornår man opretter en ny side kontra opdaterer en eksisterende. Denne fil er det tætteste, workflowen kommer på et konfigurationslag.

Tre operationer kører mod denne struktur:

1. Ingest — en ny fil lander i raw/. Agenten læser den, identificerer hvilke eksisterende wiki-sider den berører, og opdaterer cirka ti til femten sider i ét pas: den nye emneside, indekset, krydsrefererede koncepter, relevante personsider. Dette er den dyre operation. Det er her "kompileringen" sker.
2. Query — du stiller et spørgsmål. Agenten læser wiki/index.md, beslutter hvilke sider der er relevante, åbner disse sider, og syntetiserer et svar. Kritisk er det, at den forespørger mod den kompilerede wiki, ikke mod råarkivet. Kompileringsarbejdet betaler sig her.
3. Lint — køres på skema eller efter behov. Agenten gennemgår wikien for modsigelser ("side A siger X, side B siger ikke-X"), forældreløse sider (som intet linker til), og forældede påstande (hvis kilde i raw/ er blevet afløst). Det er den operation, der forhindrer forfald.

Hvad folk rent faktisk bygger

Inden for fem dage efter det oprindelige opslag havde GitHub mere end femten reimplementeringer. En håndfuld er substansielle nok til at lære af.

Ar9av/obsidian-wiki behandler agentlaget som pluggbart. Den samme wiki kan drives af Claude Code, Codex, Cursor, Windsurf, Copilot eller Gemini, skiftet gennem en skills-baseret arkitektur, der indpakker hver leverandør. Dette er nyttigt, hvis du vil undgå at satse hele opsætningen på én leverandørs priskurve.

nvk/llm-wiki kommer fra NVK, en veteran Bitcoin-udvikler, og er den mest holdningsstærke implementering indtil videre. Den introducerer tre forespørgselsdybdeniveauer (fast, deep, exhaustive), eksplicit confidence-scoring på hver påstand, og dual-linking — hver wiki-side linker både til de råkilder, den er bygget fra, og til andre wiki-sider, den relaterer sig til. Dual-linkingen er idéen værd at stjæle.

ussumant/llm-wiki-compiler offentliggjorde den eneste rigtige benchmark indtil videre. Testet på et korpus med 383 markdown-filer (13,1 MB) rapporterer den cirka 84 % færre tokens pr. forespørgselssession sammenlignet med at indlæse råfilerne direkte — omkring 3.200 linjer kontekst pr. session, der falder til omkring 330. Dette er det empiriske resultat, ingen har fremhævet prominent, og det er det stærkeste kvantitative argument for hele tilgangen.

kenhuangus/llm-wiki kører hele pipelinen på lokale modeller — LM Studio, der serverer Gemma 4 — og tilføjer automatiseret overvågning af arXiv- og CVE-feeds som kontinuerlige ingest-kilder. Ingen sky, ingen API-regninger, og wikien opdaterer sig selv om natten, mens maskinen er tomgang.

iamsashank09/llm-wiki-kit reimplementerer det hele som en MCP-server. I stedet for at køre agenten som et CLI eksponerer den ingest/query/lint som MCP-værktøjer, som Cursor eller Claude Code kan kalde direkte. Det er formodentlig dér, økosystemet er på vej hen.

swarajbachu/cachezero var den første Show HN-lancering i området og solgte sig selv som "Karpathys LLM wiki-idé som én NPM-install." Det er den mindst friktionsfyldte måde at prøve mønsteret på, hvis du vil have en fungerende vault kørende på under ti minutter.

Farzapedia-casestudiet

Det mest slående udøver-eksempel er fra Farza Majeed (@FarzaTV). Farza fodrede cirka 2.500 indtastninger fra sin personlige dagbog, Apple Notes og iMessage-samtaler ind i en Karpathy-stil-pipeline og kaldte resultatet "Farzapedia". Outputtet blev omkring 400 sammenlinkede wiki-artikler, der dækkede venner, tidligere startups, forskningsinteresser og — fordi dette er Farza — flere anime-dybdedyk.

Det, der gør Farzapedia interessant, er kildematerialet. Det er ikke et forskningskorpus. Det er den uordnede omkringliggende data fra et liv: sms'er, smidte noter, daterede dagbogsindtastninger. Kompileringstrinnet trak alt ind i noget navigerbart. Karpathy retweetede det selv og kaldte den resulterende hukommelsesartefakt "eksplicit og navigerbar" — en omhyggelig frase. Pointen er ikke, at wikien ved mere end Farzas noter gjorde. Det er, at wikien kan vandres.

Det er det hidtil mest overbevisende eksistensbevis på, at mønsteret generaliserer ud over Karpathys egen forskningsworkflow.

Best practices der dukkede op på dage

Trods den korte tidslinje har en grov konsensus formet sig om, hvad der virker.

YAML-frontmatter med confidence og staleness. Hver wiki-side får en header som:

---
title: "Pipeline v2 architecture"
confidence: 0.8
last_ingested: 2026-04-06
sources: [raw/notes/2026-03-22-sync.md, raw/articles/pipeline-blog.md]
content_hash: 8f3a...
stale: false
---

Dataview-forespørgsler fremhæver så sider med lav confidence, forældede sider eller forældreløse direkte i Obsidian.

Streng adskillelse mellem raw/ og wiki/. Allerede dækket ovenfor, men det er den praksis, der oftest brydes i tidlige forks, og den med den værste fejlmode.

Steph Angos vault-adskillelsesmønster. Steph Ango (@Kepano), Obsidians CEO, skrev i løbet af ugen, at agenter bør "make a mess in their own space" i stedet for at redigere menneskets personlige vault. Hans anbefaling er at holde dine håndskrevne Obsidian-noter i én vault og pege LLM-wikien mod en separat, ofret vault. Det forhindrer, hvad han kalder hallucinationskontaminering — situationen hvor en model finder på et faktum, skriver det ind i dine betroede noter, og så læser det tilbage næste uge, som om det var sandhed. Når først et hallucineret link er i din graf, bliver det forstærket ved hvert efterfølgende ingest.

Content hash-detektion. Hash hver rå fil ved ingest. Hvis hashen ændres, flag hver wiki-side, der citerede den, som forældet. Det er det billigste mulige lint-trin og fanger det meste af forfaldet.

qmd til at skalere søgning. Single-index-file-mønsteret fungerer op til cirka 100-150 artikler. Derudover bliver index.md selv større end et komfortabelt kontekstvindue, og agenten begynder at hakke. Tobi Lütkes qmd giver dig et hybrid BM25/vector retrieval-lag, som agenten kan kalde som et værktøj, så indekset bliver et API-kald i stedet for en fillæsning. Det er den eneste rene skaleringsvej, nogen har offentliggjort.

Skemafiler som konventioner. CLAUDE.md og AGENTS.md konvergerer som de to filnavne, agenter leder efter. Læg din stilguide, dine påkrævede frontmatter-felter, dine krydslink-regler og dine disambigueringsregler i en af disse filer. Alt andet følger.

Hvor det bryder sammen

Dette er den del af workflowen, som det meste af entusiastdækningen springer over. Mønsteret er godt. Det er ikke færdigt.

Indekset vokser ud af kontekstvinduet. Forbi et par hundrede artikler bliver wiki/index.md uhåndterligt. Du kan komprimere, sharde eller skifte til qmd, men ingen af disse er gratis. Hver skaleringsløsning introducerer retrieval, og retrieval er det, mønsteret skulle erstatte. Ved en eller anden korpusstørrelse bliver workflowen stille til RAG-over-kompileret-markdown, hvilket er forsvarligt, men værd at indrømme.

Citatpræcisionen er svag. Wikien kan sige "denne beslutning blev truffet den 22. marts" og citere raw/notes/2026-03-22-sync.md, men den kan ikke let citere "side 47, afsnit 3". For forskningsarbejde, hvor proveniens betyder noget, er det et hul. Den eneste workaround indtil videre er at præprocessere råfiler til små nok bidder, så filnavnet er præcist nok — hvilket, igen, begynder at ligne chunking.

Hallucinationskontaminering er virkelig. Hvis LLM'en finder på et link ved ingest, består det link. Ved næste ingest vil modellen læse sin egen opfindelse som kildemateriale og forstærke det. Steph Angos separat-vault-mønster afhjælper dette; lint-trin fanger noget af det; men ingen har en principiel løsning. Wikien kan drive væk fra råarkivet, og der er ingen automatisk alarm.

Token-omkostninger i skala er uoffentliggjorte. Ingen der kører en wiki i produktion, har offentliggjort rigtige tal. Ingest-operationen berører ti til femten sider pr. nyt dokument, hver gang fuld læsning-og-omskrivning. Ved Claude Sonnet-priser kunne en travl vidensarbejder brænde meningsfulde penge af pr. måned, men vi ved ikke endnu, om det er ti dollars eller to hundrede. Ussumant-benchmarken handler om besparelser ved forespørgselstid, ikke omkostninger ved ingest-tid.

"Det her er bare RAG"-debatten. En betydelig del af den tekniske kommentar er en eller anden variant af "kompiler markdown og forespørg mod det er bogstaveligt talt retrieval-augmented generation". Den skelnen, der er værd at bevare, er, at kompilering er lossy og holdningsstærk — LLM'en træffer redaktionelle beslutninger ved ingest, som klassisk RAG udsætter til forespørgselstid. Om det tæller som et nyt paradigme eller en omplacering af det samme arbejde, er en definitionsstrid, og det bliver ikke afgjort af et tweet.

Mødetranskript-muligheden

Karpathy opremsede flere kildetyper i gisten. Én linje er værd at citere i sin helhed, fordi den peger på det hul, ingen har fyldt:

"Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. The wiki stays current because the LLM does the maintenance that no one on the team wants to do."

Den sætning indeholder den uudtalte tese for hvert møde-AI-værktøj på markedet. Mødetranskripter er det højeste-udbytte-input for en Karpathy-stil-wiki: de genereres automatisk, de er relationelle, de akkumulerer, og ingen vil vedligeholde dem i hånden. De er præcis den slags dokumenter, der drager fordel af kompilering frem for lagring.

Og alligevel er der, fra denne uge, intet produkt, der automatisk fodrer mødesamtaler ind i en akkumulerende Karpathy-stil-wiki. De nærmeste tilstødende værktøjer stopper ved resuméer pr. møde. Kløften mellem "her er et resumé af dagens opkald" og "her er en vedligeholdt wiki-side for Q3-prisbeslutningen, opdateret på tværs af de syv møder, hvor den kom op" er stor, og den er stadig for det meste tom.

Proudfrog tænker på dette problem, og den tidligere tekst om Karpathys wiki og mødeviden går dybere ind i de arkitektoniske implikationer. For det bredere argument om, hvordan en kompileret mødevidensgraf ser ud i daglig brug, se knowledge worker-workflowen, feature-siden eller pricing.

Kortversionen: Karpathy viste, hvordan destinationen ser ud. Det interessante arbejde nu er at lægge rørene ind i de steder, hvor råmaterialet allerede bliver produceret.

---

Ofte stillede spørgsmål

Hvilken LLM bruger Karpathy til sin wiki?

Karpathy navngav ikke eksplicit en model i det oprindelige opslag eller gist. Men skemafilen i hans offentliggjorte mappestruktur hedder CLAUDE.md, som er konventionen brugt af Anthropics Claude Code. Community-konsensus er, at den primære driver er Claude Code, der kører mod en lokal mappe, selvom implementeringer er blevet offentliggjort med GPT-baseret Codex, Gemini, Cursor og lokale modeller via LM Studio. Workflowen er modelagnostisk — det der betyder noget er, at agenten kan læse og skrive filer i en mappe.

Skal jeg være udvikler for at bygge min egen LLM-wiki?

Du skal være komfortabel med en terminal, git og en LLM-kodeagent som Claude Code eller Cursor. Du behøver ikke skrive kode fra bunden — flere reimplementeringer (cachezero, llm-wiki-kit, obsidian-wiki) installeres på få minutter og giver dig en fungerende vault. Det løbende arbejde er at kuratere skemafilen, beslutte hvad der skal i raw/, og gennemgå hvad agenten skriver. Tænk på det som at betjene et system snarere end at bygge et.

Hvordan adskiller dette sig fra RAG?

Klassisk RAG chunker dokumenter, embedder dem og henter lignende chunks ved forespørgselstid. Hentningen er lighedsbaseret og sker, når du stiller et spørgsmål. Karpathys wiki kompilerer rådokumenter til struktureret, linket markdown ved ingest-tid, og LLM'en træffer redaktionelle beslutninger — hvad der betyder noget, hvad der linker til hvad, hvad der skal opdateres — før noget spørgsmål stilles. Ved forespørgselstid læser modellen den kompilerede wiki, ikke råarkivet. Forbi et par hundrede artikler bliver skelnen mere sløret, fordi indekset selv skal søges, men i personlig skala bærer kompileringstrinnet meningsfuld information, som ren lighedssøgning kasserer.

Hvad sker der, når wikien bliver for stor til kontekstvinduet?

Single-index-file-mønsteret brydes omkring 100-150 artikler, når wiki/index.md holder op med at passe komfortabelt i konteksten. Den reneste skaleringsvej, der er offentliggjort indtil videre, er qmd af Tobi Lütke, et hybrid BM25- og vector search-værktøj, som agenten kalder som et retrieval-trin. Derudover begynder du at sharde wikien efter emne eller tidsperiode. Det er det ærlige sted, hvor mønsteret genindfører retrieval, og det er værd at planlægge for, hvis dit korpus vokser.

Kan jeg bruge dette med mine mødetranskripter?

I princippet ja — drop transkripter i raw/transcripts/ og lad agenten kompilere dem. I praksis er mødetranskripter støjende, taler-tilskrevne og tidsstemplede, og en generisk wiki-agent ved ikke, hvordan den skal vægte beslutninger, udtrække action items eller af-duplikere gentagne diskussioner. Det er det hul, Proudfrog arbejder på. For en dybere behandling af, hvordan en møde-native kompileret wiki ville se ud, se Karpathys LLM-wiki og hvad det betyder for mødeviden.

Hvad er forskellen mellem raw/ og wiki/?

raw/ holder dine kildedokumenter — artikler, papers, noter, transkripter — og er uforanderlig. LLM'en læser fra den, men skriver aldrig tilbage. wiki/ holder kompileret markdown, som LLM'en ejer fuldstændigt: den opretter, opdaterer og omstrukturerer sider, efterhånden som nye kilder ankommer. Du redigerer ikke wiki/-filer i hånden, fordi det næste ingest vil overskrive dem. Hvis du skal rette noget, så ret den underliggende kilde i raw/ eller opdater reglerne i CLAUDE.md. At holde de to mapper strengt adskilt er den enkeltvis vigtigste konvention i workflowen, og det er den, der oftest brydes i tidlige forks.