LLM-wikien i skala: Token-omkostninger, hallucinationskontaminering og second brain-kirkegården

I de fem dage efter at Andrej Karpathy lagde sin "LLM Knowledge Base"-workflow op på X, samlede tråden mere end seksten millioner visninger. Inden for en uge havde GitHub femten-plus implementeringer med navne som llm-wiki-compiler og karpathy-wiki. DAIR.AI annoncerede et virtuelt event for at dissekere mønsteret. Obsidian-forumtråde fyldtes med skærmbilleder af selvvedligeholdende vaults. Idéen — at en LLM kan kompilere dine rå inputs til en linket, lintet, forespørgbar markdown-wiki — blev, kortvarigt, det mest virale knowledge management-koncept siden Roam lancerede block references i 2020.

Det meste der er skrevet indtil videre, er fejring. Vi skrev en af de tekster selv, og vi står bag den: arkitekturen er genuint interessant, og anti-RAG-fundet fortjener opmærksomhed.

Men fejring er ikke analyse. Der er tre ting, næsten ingen siger om Karpathys mønster, og hvis du er ved at bruge en weekend på at bygge et selv, fortjener du at høre dem, før du begynder. Dette er skeptikerens briefing — ikke kynisk, ikke en nedrivning, bare de dele af samtalen, som hype-cyklussen har sprunget over.

1. Problemet med hallucinationskontaminering

Start med den dybeste tekniske bekymring, fordi det også er den, der vinkes væk hurtigst.

Når en LLM kompilerer en wiki, transskriberer den ikke bare. Den træffer redaktionelle beslutninger — hvilke koncepter der linker til hvilke, hvilke påstande der generaliserer, hvilke detaljer der skal bevares. Hver af disse beslutninger er et sted, hvor en hallucination kan komme ind i registret. Og når den først er inde, er den ikke længere mærket som en hallucination. Den er mærket som en linje i dine noter.

Sebastian Raschkas Antigravity-team sagde det lige ud i deres gennemgang af mønsteret: "If the LLM hallucinates a connection between two concepts, that false link now lives in your wiki and could influence future queries." Sergey Lyapustins Your Second Brain Has Amnesia-tekst gik videre: "When an LLM makes up a meeting that didn't happen, or puts the wrong words in someone's mouth from your own notes, the failure mode is not that you catch it — it's that you might actually believe it."

Standardsvaret er: "Det er det, lint-passet er til for." Karpathys workflow inkluderer et lint-trin, hvor LLM'en fejer gennem wikien på jagt efter modsigelser og huller. I teorien fanges en kontamineret påstand ved næste pass.

I praksis er linteren den samme klasse model, der introducerede hallucinationen. Selv-tjek har reelle begrænsninger. Vi har flere års forskning, der viser, at LLM'er er dårligere til at fange deres egne fejl end til at fange fejl skrevet af et andet system, og selv krydsmodel-tjek efterlader lange haler af uopdagede fejl. Hvis Claude skriver en plausibel-men-falsk krydsreference om mandagen, er det sandsynligt, at Claude om onsdagen læser den, finder den internt konsistent, og certificerer den.

Der er også et uløst problem under det hele: citatpræcision. En god menneskelig wiki lader dig spore en påstand tilbage til "side 47, afsnit 3" i kilden. En LLM-kompileret wiki har ingen indbygget mekanisme til at producere det link. Du kan bede den vedlægge citater, og det gør den — men citatet selv kan være forkert, og på det punkt reviderer du revisoren.

Steph Ango, Obsidians medstifter, gav et råd, der læses anderledes, når du sidder med kontamineringsproblemet. Han foreslog at holde alt AI-genereret indhold i en separat vault, så AI'en kan "make a mess in their own space". Det er ikke en sær præference. Det er nogen, der forstår markdown-vidensbaser dybt, der fortæller dig, at outputtet fra disse systemer endnu ikke er troværdigt nok til at blandes med dine rigtige noter.

Den praktiske implikation er vigtig og ofte overset: kontamineringsrisikoen er omtrent okay for personligt videnarbejde, hvor nedsiden af en strøfejl er lille. Den er meningsfuldt farlig i enhver kontekst, hvor nogen senere vil handle på wikien, som om den var sandhed — juridisk forskning, medicinske noter, regulerede forretningsbeslutninger, alt der involverer andres penge eller sikkerhed. Karpathy-mønsteret er ikke et højindsats-videnslager. Ikke endnu.

2. Token-omkostningen ingen offentliggør

Her er et sært hul i diskursen. Karpathys opslag nævner, at hans wiki er vokset til cirka hundrede artikler og fire hundrede tusind ord. Det siger ingenting om, hvad det koster at vedligeholde. Det gør de fleste entusiastiske gennemgange heller ikke. Heller ikke GitHub-repoene.

Lad os lave det regnestykke, ingen anden ser ud til at ville lave, med det tydelige forbehold, at det er bag-på-konvolutten, og dine tal vil variere.

Et typisk ingest i dette mønster er ikke billigt. Når et nyt dokument ankommer, skal LLM'en læse dokumentet, trække de ti til femten eksisterende wiki-sider op, der mest sandsynligt bliver påvirket, beslutte hvilke krydsreferencer der skal opdateres, omskrive de berørte sektioner, og sende diff'en ud. Hvis hver berørt side i gennemsnit er omkring tre tusinde tokens, plus en fem-tusinde-tokens system prompt, plus ræsonnement-overhead, kigger du på cirka femogtredive tusinde tokens for et enkelt ingest. Det er for ét nyt input.

Læg nu lint-passet til. Linting er et helt-wiki-sweep i Karpathys indramning, hvilket betyder, at den skalerer med størrelsen på din wiki. En hundrede-artikel-wiki ved tre tusinde tokens pr. artikel er tre hundrede tusinde tokens pr. lint, før noget ræsonnement. Kør den ugentligt, og du er i multi-million-token-territorium bare for hygiejne.

Ved Claude Opus-priser (~15 dollars pr. million input, ~75 dollars pr. million output) kunne en aktiv wiki-bruger, der laver daglige ingests og ugentlige lints, plausibelt bruge hvor som helst fra fem til halvtreds dollars om måneden afhængigt af, hvor aggressiv de er. Sonnet skærer det betydeligt. Haiku eller Gemini Flash skærer det mere. Men pointen er, at ingen offentliggør de rigtige tal. Communityet opererer på tro.

Den ene benchmark, der findes — tallet "84 % token-reduktion pr. session" fra ussumant/llm-wiki-compiler — er reel, men den måler noget andet end det, de fleste tror, den måler. Det er en per-forespørgsel-effektivitetspåstand: når wikien er bygget, bruger forespørgsler mod den færre tokens end at køre den samme forespørgsel over rå kilder. Det er sandt og nyttigt. Det siger ingenting om omkostningen ved at bygge og vedligeholde wikien i første omgang, hvilket er den omkostning, der faktisk skalerer med dit liv.

Lokale LLM'er er den åbenlyse nødudgang. Ollama, LM Studio, llama.cpp — kør en 30B- eller 70B-model på din egen maskine, og den marginale token-omkostning går til nul. Problemet er kvalitet. Kompileringsopgaver er svære. De har brug for lang kontekst, omhyggelig instruktionsfølgning og konsistent formatering på tværs af mange pass. Nuværende open-weight-modeller kan gøre det, men faldet i kvalitet fra Sonnet eller Opus er mærkbart i præcis de dimensioner, der betyder mest for en wiki — hallucinationsrate, krydsreferencenøjagtighed og stilistisk konsistens.

Det ærlige resumé er, at ingen endnu ved, hvad dette mønster koster i vedvarende personlig skala, og de, der bygger de mest højlydte implementeringer, er ikke dem, der betaler regningen ved månedens udgang. Hvis du bygger en, så sæt et budgetloft på din API-nøgle, før du begynder. Du vil lære mere af, at loftet rammer, end af noget blogindlæg.

3. Second brain-kirkegården

Dette er afsnittet, der bør dæmpe den største entusiasme, fordi det er den del af samtalen med mest bevis bag sig. Historien om "gem alt, find hvad som helst"-værktøjer er ikke en historie om triumf. Det er en historie om imponerende lanceringer, store runder, entusiastiske tidlige brugere, og langsom kollaps.

Evernote. Engang værdiansat over en milliard dollars, engang med to hundrede millioner brugere, engang flagskibsproduktet for hele second brain-æraen. Bending Spoons-opkøbet skar gratis-planen ned til halvtreds noter og pressede næsten-hundrede-procents prisstigninger igennem. I 2026 eksisterer produktet stadig, men det dør offentligt, og ingen i knowledge management-communityet behandler det som en destination længere.

Roam Research. Ni millioner dollars rejst. "Tools for thought"-darlingen i 2020 og 2021. Block references, tovejs links, en passioneret kult. I 2024 var momentum væk. Femten dollars om måneden med en ligegyldig mobiloplevelse og en grundlægger mere interesseret i filosofi end at sende. Aktive brugertal faldt. Den eksisterer stadig. Den vinder ikke længere.

Skiff. Fjorten millioner rejst, to millioner brugere, privatliv-forward, et genuint godt produkt. Opkøbt af Notion i februar 2024. Helt lukket ned i august 2024. Seks måneder fra opkøb til væk.

Limitless (tidligere Rewind). Always-on kontekstlaget. Et vedhæng, en Mac-app, ambitionen om at optage hele dit liv og lade AI give det mening. Meta opkøbte dem den 5. december 2025. Vedhæng-hardwaresalg stoppede den dag. Mac-appen blev permanent lukket ned den 19. december. Tjenesten ophørte helt i EU, Storbritannien og Brasilien — den sidste detalje læses som en stille erkendelse af, at GDPR aldrig rigtig blev løst for "optag alt".

Mem.ai. Ni og tyve millioner dollars ledet af OpenAIs fond. Positioneret som den AI-native note-taker, der endelig ville knække automatisk organisering. Kritikere begyndte at kalde den "fyrre-millioner-dollar-second brain-fiaskoen", da den ikke fandt retention. Relanceret som Mem 2.0 i oktober 2025. Bedre. Ikke fikset.

Dette er ikke en liste over dårlige produkter. De fleste af disse var velbyggede, velfinansierede, og drevet af folk, der forstod knowledge management dybt. De fejlede alligevel, og fejlmønsteret er konsistent nok til at være værd at navngive.

Produktivitetsfælden

Glasps analyse af knowledge management-fiasko, der ekkoer tidligere arbejde af APQC, identificerer tool hopping som den enkeltvis mest almindelige fejlmode. Brugere cykler gennem Notion, Obsidian, Logseq, Capacities, Tana, Mem, og slutter med "fem halvt-fyldte systemer og ingen brugbar vidensbase". Den anden dræber er overingeniørarbejde: brugere bruger mere tid på at bygge og justere systemet end på at lave det videnarbejde, systemet var ment at understøtte. "Systemet bliver projektet, og det egentlige videnarbejde sker aldrig."

Den bredere kontekst er dyster. Cirka 92 % af SaaS-startups fejler inden for tre år (myICORs longitudinelle analyse, 2024). Den specifikke delmængde af "personlig knowledge management"-startups fejler ved eller over den rate. Markedet har prøvet og fejlet at løse dette problem i omkring tyve år.

Intet af dette er en grund til ikke at prøve. Men hvis du læser en viral tråd om Karpathys wiki og føler trangen til at genopbygge hele dit informationsliv omkring den, bør den trang sidde lige ved siden af mindet om Roam, Mem, Skiff, Limitless og Evernote. De føltes alle uundgåelige også.

Hvorfor denne gang faktisk kunne være anderledes

Nu steel-man-argumentet, fordi den skeptiske sag ikke er et lukket argument.

Det enkeltvis tydeligste skel mellem Karpathy-mønsteret og hvert tidligere second brain-værktøj er dette: de gamle værktøjer krævede, at du vedligeholdt vidensbasen. Det var muren, brugere ramte. Du fangede ind i Evernote dag ét, organiserede febrilsk i to uger, og seks måneder senere havde du tre tusinde utaggede noter og en vag følelse af skyld. Vedligeholdelsesbyrden, ikke capture-byrden, var det, der dræbte disse systemer.

Karpathy-mønsteret er fundamentalt anderledes i præcis den dimension. LLM'en laver vedligeholdelsen. Den læser, den linker, den linter, den omskriver. Du er ikke længere ansvarlig for vidensbasens form — du er ansvarlig for inputtene og den lejlighedsvise revision. Det er et meningsfuldt anderledes job.

Tool hopping var, set i bakspejlet, rationel adfærd. Brugere søgte efter et værktøj, der ville gøre arbejdet for dem, og intet sådant værktøj eksisterede. AI-agenter er den første ting, der plausibelt kan. Det er ikke, at brugere var lunefulde. Det er, at det, de ville have, ikke eksisterede endnu.

Hallucinationsproblemet er reelt, men afgrænset. Hvis du holder rå kilder uforanderlige og behandler den kompilerede wiki som flygtig og regenererbar — i bund og grund som en cache oven på et betroet kildelag — er blast radius for en given hallucination lille. Du kan genopbygge wikien fra bunden, når du mister tillid til den. Det er en egenskab, intet tidligere note-værktøj havde.

Omkostningsproblemet kan løse sig selv på en kortere horisont, end folk forventer. Lokale modeller i Gemma 3-, Llama 4- og Qwen 3-generationen lukker kløften på kompileringsstil-opgaver hurtigere, end de fleste omkostningsanalyser antager. Tolv til atten måneder fra nu kan regnestykket for at køre dette lokalt simpelthen være anderledes.

Og skiftet i værditilbud betyder noget. Den forrige bølge handlede om at gemme viden og håbe, at det ville betale sig senere. Denne bølge handler om at forespørge en struktureret version af dine inputs på forespørgsel og genopbygge strukturen, når den rådner. Det er en anden aftale med brugeren, og det kan være en bedre.

Det ærlige spørgsmål, der afgør det

Skræl hypen og historien væk, og det åbne spørgsmål er smallere, end det ser ud.

Løser AI-vedligeholdt viden faktisk vedligeholdelsesbyrden, eller flytter den bare byrden fra "organisere noter" til "kuratere kilder og køre sundhedstjek"?

Det optimistiske svar: kildekuration er endeligt arbejde. Du har kun så mange kilder, du virkelig bekymrer dig om. Noteorganisering, derimod, er uendelig — hver ny note skaber nye organisatoriske beslutninger, der hoper sig op.

Det pessimistiske svar: kildekuration er også uendelig, hvis du tager det alvorligt. Du bliver redaktør for din egen mikro-Wikipedia, og redaktion er et fuldtidsjob af en grund.

Det realistiske svar er, at det helt afhænger af, om dine inputs er afgrænsede eller uafgrænsede. Hvis du peger Karpathy-mønsteret mod "alt jeg læser på internettet", vil du drukne. Hvis du peger det mod et specifikt forskningsprojekt, et enkelt domæne, du forsøger at mestre, eller en naturligt begrænset brandslange som dine egne møder, har det en reel chance for at virke — fordi vedligeholdelsesproblemet er proportionalt med input-volumen, og input-volumen er faktisk begrænset.

Hvor dette efterlader mødetranskripter specifikt

Møder har tilfældigvis en egenskab, der direkte adresserer en af "second brain-kirkegårdens" fejlmoder: inputtene er naturligt afgrænsede. Du behøver ikke beslutte, hvad du skal fange. Møderne sker, om du vil det eller ej, og sættet af møder, du bekymrer dig om, er endeligt på en måde, som "interessante artikler" eller "tanker jeg havde i dag" aldrig er.

Det gør vedligeholdelsesbyrden genuint lavere end en fang-alt-du-læser-wiki. Det gør også hallucinationsrisikoen lavere på en subtil måde: fulde samtaletranskripter indeholder meget kontekst pr. token, så LLM-udtrækning er mere jordet end udtrækning fra en kortfattet note. Der er mere signal for modellen at holde sig til. Privatlivs- og omkostningsspørgsmålene består, og de er ikke små. Men den strukturelle pasform er bedre end de fleste domæner.

Proudfrog er bygget omkring denne hypotese — at møder er det rigtige omfang for en AI-vedligeholdt vidensbase præcis fordi inputtet er naturligt begrænset. Hvorvidt den hypotese er korrekt, er stadig et åbent spørgsmål, og vi vil ikke foregive andet i en skeptisk artikel om præcis denne slags hypotese. Vil du have den mere detaljerede version af argumentet, graver møde-til-wiki-kløften og den komplette workflow-guide videre. Vil du se sagen for møder som en knowledge worker-workflow, bor den der.

Hvad den smarte skeptiker bør gøre

Hvis du har læst så langt og stadig vil prøve, er her versionen af eksperimentet, der vil lære dig mest med mindst spildt tid.

• Start med et afgrænset brugsscenarie. Ét specifikt forskningsprojekt, dine møder, ét teams dokumentation. Start ikke med "al min viden". Du vil tabe.
• Hold rå kilder uforanderlige og Git-versionerede. Wikien er en afledt artefakt. Du bør kunne slette den helt og regenerere den uden at miste noget vigtigt.
• Behandl wikien som regenererbar, ikke dyrebar. I det øjeblik du føler dig beskyttende over for den kompilerede version, er du begyndt at bygge den samme fælde, som den forrige generation byggede.
• Sæt et hårdt budgetloft på din LLM-API-nøgle, før du begynder. Ikke bagefter. At loftet rammer, er data. Overraskelsesregninger er det ikke.
• Revider for hallucinationer ugentligt den første måned. Vælg fem påstande tilfældigt hver uge og spor dem tilbage til kilde. Hvis du ikke kan, er det, hvad du lærte.
• Beslut på forhånd, hvornår du vil stoppe. Skriv ned, hvad der ville bevise, at eksperimentet er fejlet — en kontamineringsrate, en månedsomkostning, et tidsbudget for vedligeholdelse — og respektér det, når du rammer det. Ellers vil sunk cost holde dig i systemet langt forbi dets nyttige liv, hvilket er præcis, hvordan den forrige generation af second brains endte som kirkegårde.

Dette er ikke kynisme. Det er den disciplin, den forrige bølge af værktøjer ikke havde. Karpathy-mønsteret kan være den første knowledge management-arkitektur, der genuint klarer vedligeholdelsesmuren. Det er måske heller ikke. Den eneste måde at finde ud af det på er at prøve det, som en skeptiker prøver ting — afgrænset, reviderbart, billigt, og med en forudaftalt udgang.

Se hvordan Proudfrog griber mødeviden an, hvis den afgrænsede-input-version af dette argument interesserer dig.

---

Ofte stillede spørgsmål

Er LLM-wiki-tilgangen faktisk ny, eller bare RAG genpakket?

Det er ikke RAG. RAG henter chunks ved forespørgselstid baseret på lighed; Karpathy-mønsteret kompilerer en struktureret artefakt på forhånd og forespørger mod artefakten direkte. De løser forskellige problemer. RAG skalerer bedre til millioner af dokumenter. Kompilering virker bedre i personlig skala, fordi den bevarer ræsonnement og eksplicitte krydsreferencer, som lighedssøgning kasserer. Nyheden er ikke wiki-formatet — markdown-wikier er tredive år gamle — det er at bruge LLM'en som den kontinuerlige vedligeholder af wikien snarere end som forespørgselsmotoren oven på rå kilder.

Hvor meget koster det faktisk at køre en Karpathy-stil-wiki?

Ingen har offentliggjort et troværdigt tal. Bag-på-konvolutten-matematik antyder, at en aktiv bruger, der laver daglige ingests og ugentlige helt-wiki-lints, kan bruge omkring fem til halvtreds dollars om måneden på en frontier-model som Claude Sonnet eller Opus afhængigt af wiki-størrelse og brugsintensitet. Billigere modeller skærer det betydeligt, lokale modeller eliminerer den marginale omkostning, men koster kvalitet. Sæt et budgetloft på din API-nøgle, før du begynder. Behandl alle tal, du ser i blogindlæg, som estimater, indtil nogen offentliggør en rigtig undersøgelse.

Hvad sker der, når LLM'en hallucinerer et faktum og skriver det ind i min wiki?

Det bliver der, indtil du fanger det. Lint-passet er ment at finde modsigelser, men linteren er den samme klasse model, der introducerede fejlen, og selv-tjek har reelle begrænsninger. Det bedste nuværende forsvar er at holde rå kilder uforanderlige og behandle den kompilerede wiki som regenererbar — hvis du mister tillid til wikien, genopbyg den fra kilder. For højindsats-kontekster (juridiske, medicinske, finansielle beslutninger) er hallucinationsrisikoen i øjeblikket høj nok til, at du ikke bør bruge dette mønster som et primært videnslager.

Hvorfor er så mange "second brain"-produkter døde?

Den konsistente fejlmode er, at vedligeholdelsesbyrden i sidste ende opvejer værdien. Brugere fanger entusiastisk, organiserer i nogle uger, og driver så væk. Tool hopping forstærker problemet — brugere cykler gennem systemer på jagt efter ét, der vil gøre arbejdet for dem. Evernote, Roam, Mem, Skiff og Limitless ramte alle en eller anden version af den mur. Karpathy-mønsteret er interessant netop fordi det retter sig direkte mod vedligeholdelsesmuren, ved at lade LLM'en lave vedligeholdelsen. Hvorvidt det er nok til at bryde mønsteret, er stadig et åbent spørgsmål.

Er dette sikrere med lokale LLM'er?

Sikrere for privatliv og omkostning, ja. Sikrere for hallucination, egentlig ikke — open-weight-modeller i den nuværende generation hallucinerer mere på kompileringsopgaver end Claude Sonnet eller GPT-klasses modeller, ikke mindre. Det rigtige svar for de fleste brugere i 2026 er en hybrid: brug en frontier-model til kompilerings- og lint-passene, brug en lokal model til afslappet forespørgsel mod den færdige wiki. Inden for tolv til atten måneder vil lokale modeller formentlig være gode nok til også at håndtere kompileringspassene, og omkostningskalkulen vil skifte.

Skal jeg bøvle med at prøve dette, hvis jeg ikke er udvikler?

Formentlig ikke endnu, hvis du mener at bygge en selv fra Karpathys beskrivelse. Community-værktøjerne er tidlige, workflows er skrøbelige, og fejlfinding kræver komfort med markdown, shell-scripts og prompt engineering. Vil du have værdien uden at bygge, så vent et par måneder på, at den første bølge af produktificerede versioner ryster ud — eller brug et domænespecifikt værktøj, der allerede implementerer mønsteret for et afgrænset input som møder, forskningsartikler eller en specifik kodebase. Idéerne vil stadig være her, når værktøjerne indhenter.