LLM-wikien i skala: Token-kostnader, hallusinasjonskontaminering og second brain-gravlunden

I de fem dagene etter at Andrej Karpathy la ut sin "LLM Knowledge Base"-arbeidsflyt på X, samlet tråden mer enn seksten millioner visninger. I løpet av en uke hadde GitHub femten-pluss implementasjoner med navn som llm-wiki-compiler og karpathy-wiki. DAIR.AI annonserte et virtuelt arrangement for å dissekere mønsteret. Obsidian-forumtråder fyltes med skjermdumper av selvvedlikeholdende vaults. Ideen — at en LLM kan kompilere de rå inputtene dine til en lenket, lintet, spørrbar markdown-wiki — ble, kortvarig, det mest virale knowledge management-konseptet siden Roam lanserte block references i 2020.

Det meste som er skrevet så langt, er feiring. Vi skrev en av de tekstene selv, og vi står bak den: arkitekturen er genuint interessant, og anti-RAG-funnet fortjener oppmerksomhet.

Men feiring er ikke analyse. Det er tre ting nesten ingen sier om Karpathys mønster, og hvis du er i ferd med å bruke en helg på å bygge en slik selv, fortjener du å høre dem før du starter. Dette er skeptikerens gjennomgang — ikke kynisk, ikke en nedriving, bare de delene av samtalen hypesyklusen har hoppet over.

1. Problemet med hallusinasjonskontaminering

Start med den dypeste tekniske bekymringen, fordi det også er den som blir avvist raskest.

Når en LLM kompilerer en wiki, transkriberer den ikke bare. Den tar redaksjonelle beslutninger — hvilke konsepter som lenker til hvilke, hvilke påstander som generaliserer, hvilke detaljer som skal bevares. Hver av disse beslutningene er et sted der en hallusinasjon kan komme inn i registeret. Og når den først er inne, er den ikke lenger merket som en hallusinasjon. Den er merket som en linje i notatene dine.

Sebastian Raschkas Antigravity-team sa det rett ut i gjennomgangen sin av 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 gikk 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 arbeidsflyt inkluderer et lint-steg der LLM-en sveiper gjennom wikien på jakt etter motsigelser og hull. I teorien fanges en kontaminert påstand ved neste pass.

I praksis er linter-en samme klasse modell som introduserte hallusinasjonen. Selvsjekking har reelle begrensninger. Vi har flere års forskning som viser at LLM-er er verre til å fange sine egne feil enn til å fange feil skrevet av et annet system, og selv kryssmodell-sjekking etterlater lange haler av uoppdagede feil. Hvis Claude skriver en plausibel-men-falsk kryssreferanse på mandag, er det sannsynlig at Claude på onsdag leser den, finner den internt konsistent, og sertifiserer den.

Det finnes også et uløst problem under alt dette: sitatpresisjon. En god menneskelig wiki lar deg spore en påstand tilbake til "side 47, avsnitt 3" i kilden. En LLM-kompilert wiki har ingen innebygd mekanisme for å produsere den lenken. Du kan be den legge ved sitater, og det gjør den — men sitatet selv kan være feil, og på det punktet reviderer du revisoren.

Steph Ango, Obsidians medgrunnlegger, ga et råd som leses annerledes når du sitter med kontamineringsproblemet. Han foreslo å holde alt AI-generert innhold i et separat vault slik at AI-en kan "make a mess in their own space". Det er ingen rar preferanse. Det er noen som forstår markdown-kunnskapsbaser dypt som forteller deg at utdataen fra disse systemene ikke er pålitelig nok ennå til å blandes med de ekte notatene dine.

Den praktiske implikasjonen er viktig og ofte oversett: kontamineringsrisikoen er omtrent ok for personlig kunnskapsarbeid, der nedsiden av en strøfeil er liten. Den er meningsfullt farlig i enhver kontekst der noen senere vil handle på wikien som om den var sannhet — juridisk forskning, medisinske notater, regulerte forretningsbeslutninger, alt som involverer andres penger eller sikkerhet. Karpathy-mønsteret er ikke et høy-innsats kunnskapslager. Ikke ennå.

2. Token-kostnaden ingen publiserer

Her er et rart hull i diskursen. Karpathys innlegg nevner at wikien hans har vokst til omtrent hundre artikler og fire hundre tusen ord. Det sier ingenting om hva det koster å vedlikeholde. Det gjør heller ikke de fleste entusiastiske gjennomgangene. Heller ikke GitHub-repoene.

La oss gjøre regnestykket ingen andre ser ut til å ville gjøre, med det tydelige forbeholdet at det er baksiden-av-konvolutten og dine tall vil variere.

En typisk inntak i dette mønsteret er ikke billig. Når et nytt dokument kommer, må LLM-en lese dokumentet, hente opp de ti til femten eksisterende wiki-sidene som mest sannsynlig blir påvirket, bestemme hvilke kryssreferanser som skal oppdateres, skrive om de berørte seksjonene, og sende ut diffen. Hvis hver berørte side i snitt er rundt tre tusen tokens, pluss en fem-tusen-tokens system prompt, pluss resonnementsoverhead, ser du på omtrent trettifem tusen tokens for en enkelt inntak. Det er for ett nytt input.

Legg nå til lint-passet. Linting er en hel-wiki-sveip i Karpathys innramming, som betyr at den skalerer med størrelsen på wikien din. En hundre-artikkels wiki på tre tusen tokens per artikkel er tre hundre tusen tokens per lint, før noe resonnement. Kjør den ukentlig og du er i multi-million-token-territorium bare for hygiene.

Til Claude Opus-priser (~15 dollar per million input, ~75 dollar per million output), kan en aktiv wiki-bruker som gjør daglige inntak og ukentlige lints plausibelt bruke hvor som helst fra fem til femti dollar i måneden avhengig av hvor aggressiv de er. Sonnet kutter det betydelig. Haiku eller Gemini Flash kutter det mer. Men poenget er at ingen publiserer de ekte tallene. Communityet opererer på tro.

Den ene benchmarken som finnes — "84 % token-reduksjon per sesjon"-tallet fra ussumant/llm-wiki-compiler — er reell, men den måler noe annet enn det de fleste tror den måler. Det er en per-spørring-effektivitetspåstand: når wikien er bygd, bruker det å spørre mot den færre tokens enn å kjøre samme spørring over rå kilder. Det er sant og nyttig. Det sier ingenting om kostnaden ved å bygge og vedlikeholde wikien i utgangspunktet, som er kostnaden som faktisk skalerer med livet ditt.

Lokale LLM-er er den åpenbare rømningsluken. Ollama, LM Studio, llama.cpp — kjør en 30B- eller 70B-modell på din egen maskin og den marginale token-kostnaden går til null. Problemet er kvalitet. Kompileringsoppgaver er vanskelige. De trenger lang kontekst, nøye instruksjonsfølging, og konsistent formatering over mange pass. Nåværende open-weight-modeller kan gjøre det, men fallet i kvalitet fra Sonnet eller Opus er merkbart i akkurat de dimensjonene som betyr mest for en wiki — hallusinasjonsrate, kryssreferansenøyaktighet og stilistisk konsistens.

Den ærlige oppsummeringen er at ingen ennå vet hva dette mønsteret koster i vedvarende personlig skala, og de som bygger de mest høylytte implementasjonene er ikke de som betaler regningen på slutten av måneden. Hvis du bygger en, sett et budsjettak på API-nøkkelen din før du starter. Du vil lære mer av at taket slår i enn av noe blogginnlegg.

3. Second brain-gravlunden

Dette er avsnittet som bør dempe mest entusiasme, fordi det er den delen av samtalen med mest bevis bak seg. Historien til "lagre alt, finn hva som helst"-verktøy er ikke en historie om triumf. Det er en historie om imponerende lanseringer, store runder, entusiastiske tidlige brukere, og langsom kollaps.

Evernote. En gang verdsatt over en milliard dollar, en gang med to hundre millioner brukere, en gang flaggskipsproduktet for hele second brain-æraen. Bending Spoons-oppkjøpet skjar gratisplanen ned til femti notater og presset gjennom nesten-hundreprosents prisøkninger. I 2026 eksisterer produktet fortsatt, men det dør offentlig, og ingen i knowledge management-communityet behandler det som en destinasjon lenger.

Roam Research. Ni millioner dollar hentet. "Tools for thought"-darlingen i 2020 og 2021. Block references, toveis lenker, en lidenskapelig kult. Innen 2024 var momentumet borte. Femten dollar i måneden med en likegyldig mobilopplevelse og en grunnlegger mer interessert i filosofi enn å skipe. Aktive brukertall trendet nedover. Den eksisterer fortsatt. Den vinner ikke lenger.

Skiff. Fjorten millioner hentet, to millioner brukere, personvern-forward, et genuint godt produkt. Kjøpt av Notion i februar 2024. Fullstendig lagt ned innen august 2024. Seks måneder fra oppkjøp til borte.

Limitless (tidligere Rewind). Always-on kontekstlaget. Et anheng, en Mac-app, ambisjonen om å spille inn hele livet ditt og la AI gi det mening. Meta kjøpte dem 5. desember 2025. Anheng-maskinvaresalg stoppet den dagen. Mac-appen ble permanent stengt ned 19. desember. Tjenesten opphørte helt i EU, Storbritannia og Brasil — det siste detaljen leses som en stille innrømmelse av at GDPR aldri egentlig ble løst for "spill inn alt".

Mem.ai. Tjueni millioner dollar ledet av OpenAIs fond. Posisjonert som den AI-native notattakeren som endelig skulle knekke automatisk organisering. Kritikere begynte å kalle den "førti-millioner-dollar-second brain-svikten" da den ikke fant retention. Relansert som Mem 2.0 i oktober 2025. Bedre. Ikke fikset.

Dette er ikke en liste over dårlige produkter. De fleste av disse var velbygde, velfinansierte, og drevet av folk som forsto knowledge management dypt. De feilet likevel, og feilmønsteret er konsistent nok til å være verdt å navngi.

Produktivitetsfellen

Glasps analyse av knowledge-management-feil, som ekkoer tidligere arbeid av APQC, identifiserer tool hopping som den enkelt vanligste feilmodusen. Brukere sykler gjennom Notion, Obsidian, Logseq, Capacities, Tana, Mem, og ender med "fem halvfylte systemer og ingen brukbar kunnskapsbase". Den andre drepene er overingeniør-arbeid: brukere bruker mer tid på å bygge og justere systemet enn på å gjøre kunnskapsarbeidet systemet skulle støtte. "Systemet blir prosjektet, og det faktiske kunnskapsarbeidet skjer aldri."

Den bredere konteksten er dyster. Omtrent 92 % av SaaS-startups feiler innen tre år (myICORs longitudinelle analyse, 2024). Den spesifikke undergruppen "personlig knowledge management"-startups feiler på eller over den raten. Markedet har prøvd og feilet å løse dette problemet i omtrent tjue år.

Ingenting av dette er en grunn til ikke å prøve. Men hvis du leser en viral tråd om Karpathys wiki og kjenner trangen til å bygge om hele informasjonslivet ditt rundt den, bør den trangen sitte rett ved siden av minnet om Roam, Mem, Skiff, Limitless og Evernote. De føltes alle uunngåelige også.

Hvorfor denne gangen faktisk kan være annerledes

Nå steel-man-argumentet, fordi den skeptiske saken ikke er en lukket argumentasjon.

Det enkelt tydeligste skillet mellom Karpathy-mønsteret og hvert tidligere second brain-verktøy er dette: de gamle verktøyene krevde at du vedlikeholdt kunnskapsbasen. Det var veggen brukere traff. Du fanget inn i Evernote dag én, organiserte febrilsk i to uker, og seks måneder senere hadde du tre tusen utaggede notater og en vag følelse av skyld. Vedlikeholdsbyrden, ikke capture-byrden, var det som drepte disse systemene.

Karpathy-mønsteret er fundamentalt annerledes i akkurat den dimensjonen. LLM-en gjør vedlikeholdet. Den leser, den lenker, den linter, den skriver om. Du er ikke lenger ansvarlig for formen på kunnskapsbasen — du er ansvarlig for inputtene og den sporadiske revisjonen. Det er en meningsfullt annerledes jobb.

Tool hopping var, i ettertid, rasjonell oppførsel. Brukere lette etter et verktøy som ville gjøre arbeidet for dem, og ingen slikt verktøy eksisterte. AI-agenter er det første som plausibelt kan. Det er ikke at brukere var lunefulle. Det er at det de ville ha, ikke fantes ennå.

Hallusinasjonsproblemet er reelt, men avgrenset. Hvis du holder rå kilder uforanderlige og behandler den kompilerte wikien som flyktig og regenererbar — i hovedsak som en cache over et betrodd kildelag — er blast radius til en gitt hallusinasjon liten. Du kan bygge wikien på nytt fra bunnen når du mister tillit til den. Det er en egenskap intet tidligere notat-verktøy hadde.

Kostnadsproblemet kan løse seg selv på en kortere horisont enn folk venter. Lokale modeller i Gemma 3-, Llama 4- og Qwen 3-generasjonen lukker gapet på kompileringstype-oppgaver raskere enn de fleste kostnadsanalyser antar. Tolv til atten måneder fra nå kan regnestykket for å kjøre dette lokalt rett og slett være annerledes.

Og skiftet i verdiproposisjon betyr noe. Den forrige bølgen handlet om å lagre kunnskap og håpe den ville lønne seg senere. Denne bølgen handler om å spørre mot en strukturert versjon av inputtene dine på forespørsel, og bygge om strukturen når den råtner. Det er en annen avtale med brukeren, og den kan være en bedre en.

Det ærlige spørsmålet som avgjør det

Skrell bort hypen og historien, og det åpne spørsmålet er smalere enn det ser ut.

Løser AI-vedlikeholdt kunnskap faktisk vedlikeholdsbyrden, eller flytter den bare byrden fra "organisere notater" til "kuratere kilder og kjøre helsesjekker"?

Det optimistiske svaret: kildekurering er endelig arbeid. Du har bare så mange kilder du virkelig bryr deg om. Notatorganisering, derimot, er uendelig — hvert nytt notat skaper nye organisatoriske beslutninger som hoper seg opp.

Det pessimistiske svaret: kildekurering er også uendelig hvis du tar det på alvor. Du blir redaktør for din egen mikro-Wikipedia, og redigering er en fulltidsjobb av en grunn.

Det realistiske svaret er at det helt avhenger av om inputtene dine er avgrensede eller uavgrensede. Hvis du peker Karpathy-mønsteret mot "alt jeg leser på internett", vil du drukne. Hvis du peker det mot et spesifikt forskningsprosjekt, et enkelt domene du prøver å mestre, eller en naturlig begrenset brannslange som dine egne møter, har det en reell sjanse til å fungere — fordi vedlikeholdsproblemet er proporsjonalt med inputvolumet, og inputvolumet er faktisk begrenset.

Hvor dette etterlater møtetranskripsjoner spesifikt

Møter har tilfeldigvis en egenskap som direkte adresserer en av "second brain-gravlundens" feilmoduser: inputtene er naturlig avgrensede. Du trenger ikke å bestemme hva du skal fange. Møtene skjer enten du vil eller ikke, og settet av møter du bryr deg om er endelig på en måte som "interessante artikler" eller "tanker jeg hadde i dag" aldri er.

Det gjør vedlikeholdsbyrden genuint lavere enn en fang-alt-du-leser-wiki. Det gjør også hallusinasjonsrisikoen lavere på en subtil måte: fulle samtale-transkripsjoner inneholder mye kontekst per token, så LLM-uttrekking er mer jordet enn uttrekking fra et kortfattet notat. Det er mer signal for modellen å holde seg til. Personvern- og kostnadsspørsmålene gjenstår, og de er ikke små. Men den strukturelle tilpasningen er bedre enn de fleste domener.

Proudfrog er bygget rundt denne hypotesen — at møter er riktig omfang for en AI-vedlikeholdt kunnskapsbase nettopp fordi inputet er naturlig begrenset. Hvorvidt den hypotesen er riktig, er fortsatt et åpent spørsmål, og vi kommer ikke til å late som noe annet i en skeptisk artikkel om akkurat denne typen hypotese. Vil du ha den mer detaljerte versjonen av argumentet, graver møte-til-wiki-gapet og den komplette arbeidsflyt-guiden videre. Vil du se saken for møter som en knowledge worker-arbeidsflyt, bor den der.

Hva den smarte skeptikeren bør gjøre

Hvis du har lest så langt og fortsatt vil prøve, her er versjonen av eksperimentet som vil lære deg mest med minst bortkastet tid.

• Start med et avgrenset bruksområde. Ett spesifikt forskningsprosjekt, dine møter, ett teams dokumentasjon. Ikke start med "all kunnskapen min". Du vil tape.
• Hold rå kilder uforanderlige og Git-versjonerte. Wikien er en utledet artefakt. Du skal kunne slette den helt og regenerere den uten å miste noe viktig.
• Behandle wikien som regenererbar, ikke dyrebar. I det øyeblikket du føler deg beskyttende overfor den kompilerte versjonen, har du begynt å bygge samme felle som forrige generasjon bygde.
• Sett et hardt budsjettak på LLM-API-nøkkelen din før du starter. Ikke etter. At taket slår i, er data. Overraskelsesregninger er det ikke.
• Revider for hallusinasjoner ukentlig den første måneden. Plukk fem påstander tilfeldig hver uke og spor dem tilbake til kilde. Hvis du ikke kan, er det hva du lærte.
• Bestem på forhånd når du vil slutte. Skriv ned hva som ville bevise at eksperimentet har feilet — en kontamineringsrate, en månedskostnad, et tidsbudsjett for vedlikehold — og respekter det når du treffer det. Ellers vil sunk cost holde deg i systemet langt forbi dets nyttige levetid, som er nøyaktig hvordan forrige generasjon second brains endte som gravlunder.

Dette er ikke kynisme. Det er disiplinen forrige bølge av verktøy ikke hadde. Karpathy-mønsteret kan være den første knowledge management-arkitekturen som genuint klarer vedlikeholdsveggen. Det kan også hende det ikke er det. Den eneste måten å finne det ut på er å prøve det slik en skeptiker prøver ting — avgrenset, reviderbart, billig, og med en forhåndsbestemt utgang.

Se hvordan Proudfrog nærmer seg møtekunnskap hvis den avgrensede-input-versjonen av dette argumentet interesserer deg.

---

Ofte stilte spørsmål

Er LLM-wiki-tilnærmingen faktisk ny, eller bare RAG ompakket?

Det er ikke RAG. RAG henter chunks ved spørretid basert på likhet; Karpathy-mønsteret kompilerer en strukturert artefakt på forhånd og spør mot artefakten direkte. De løser forskjellige problemer. RAG skalerer bedre til millioner av dokumenter. Kompilering fungerer bedre i personlig skala fordi den bevarer resonnement og eksplisitte kryssreferanser som likhetssøk forkaster. Nyheten er ikke wiki-formatet — markdown-wikier er tretti år gamle — det er å bruke LLM-en som den kontinuerlige vedlikeholderen av wikien heller enn som spørremotoren over rå kilder.

Hvor mye koster det faktisk å kjøre en Karpathy-stil-wiki?

Ingen har publisert et troverdig tall. Baksiden-av-konvolutten-regnestykket antyder at en aktiv bruker som gjør daglige inntak og ukentlige hel-wiki-lints kan bruke omtrent fem til femti dollar i måneden på en frontier-modell som Claude Sonnet eller Opus, avhengig av wiki-størrelse og brukintensitet. Billigere modeller kutter det betydelig, lokale modeller eliminerer den marginale kostnaden, men koster kvalitet. Sett et budsjettak på API-nøkkelen din før du starter. Behandle alle tall du ser i blogginnlegg som estimater til noen publiserer en ekte studie.

Hva skjer når LLM-en hallusinerer et faktum og skriver det inn i wikien min?

Det blir der til du fanger det. Lint-passet skal finne motsigelser, men linter-en er samme klasse modell som introduserte feilen, og selvsjekking har reelle begrensninger. Det beste nåværende forsvaret er å holde rå kilder uforanderlige og behandle den kompilerte wikien som regenererbar — hvis du mister tillit til wikien, bygg den på nytt fra kilder. For høy-innsats-kontekster (juridiske, medisinske, finansielle beslutninger) er hallusinasjonsrisikoen for øyeblikket høy nok til at du ikke bør bruke dette mønsteret som et primært kunnskapslager.

Hvorfor har så mange "second brain"-produkter dødd?

Den konsistente feilmodusen er at vedlikeholdsbyrden til slutt veier tyngre enn verdien. Brukere fanger entusiastisk, organiserer i noen uker, og så driver de av gårde. Tool hopping forsterker problemet — brukere sykler gjennom systemer på leting etter ett som vil gjøre arbeidet for dem. Evernote, Roam, Mem, Skiff og Limitless traff alle en eller annen versjon av den veggen. Karpathy-mønsteret er interessant nettopp fordi det retter seg mot vedlikeholdsveggen direkte, ved å la LLM-en gjøre vedlikeholdet. Hvorvidt det er nok til å bryte mønsteret, er fortsatt et åpent spørsmål.

Er dette tryggere med lokale LLM-er?

Tryggere for personvern og kostnad, ja. Tryggere for hallusinasjon, egentlig ikke — open-weight-modeller i nåværende generasjon hallusinerer mer på kompileringsoppgaver enn Claude Sonnet eller GPT-klasses modeller, ikke mindre. Riktig svar for de fleste brukere i 2026 er en hybrid: bruk en frontier-modell for kompilerings- og lint-passene, bruk en lokal modell for avslappet spørring mot den ferdige wikien. Innen tolv til atten måneder vil lokale modeller trolig være gode nok til å håndtere kompileringspassene også, og kostnadskalkylen vil skifte.

Bør jeg bry meg med å prøve dette hvis jeg ikke er utvikler?

Trolig ikke ennå, hvis du mener å bygge en selv fra Karpathys beskrivelse. Community-verktøyene er tidlige, arbeidsflytene er skjøre, og feilsøking krever komfort med markdown, shell-skript og prompt engineering. Vil du ha verdien uten å bygge, vent noen måneder på at den første bølgen av produktifiserte versjoner skal riste ut — eller bruk et domenespesifikt verktøy som allerede implementerer mønsteret for et avgrenset input som møter, forskningsartikler eller en spesifikk kodebase. Ideene vil fortsatt være her når verktøyene tar igjen.