LLM-wikin i skala: Token-kostnader, hallucinationskontaminering och second brain-gravgården

Under de fem dagarna efter att Andrej Karpathy postade sin "LLM Knowledge Base"-workflow på X samlade tråden mer än sexton miljoner visningar. Inom en vecka hade GitHub femton-plus implementationer med namn som llm-wiki-compiler och karpathy-wiki. DAIR.AI annonserade ett virtuellt event för att dissekera mönstret. Obsidian-forum fylldes med skärmdumpar av självunderhållande valv. Idén — att en LLM kan kompilera dina råa inputs till en länkad, linted, frågbar markdown-wiki — blev, kortvarigt, det mest virala knowledge management-konceptet sedan Roam lanserade block references 2020.

Det mesta som skrivits så här långt är firande. Vi skrev ett av de inläggen själva, och vi står bakom det: arkitekturen är genuint intressant, och anti-RAG-fyndet förtjänar uppmärksamhet.

Men firande är inte analys. Det finns tre saker som nästan ingen säger om Karpathys mönster, och om du är på väg att spendera en helg på att bygga ett sådant själv förtjänar du att höra dem innan du börjar. Det här är skeptikerns genomgång — inte cynisk, inte ett nedgörande, bara de delar av samtalet som hype-cykeln har hoppat över.

1. Problemet med hallucinationskontaminering

Börja med den djupaste tekniska oron, eftersom det också är den som viftas bort snabbast.

När en LLM kompilerar en wiki transkriberar den inte bara. Den fattar redaktionella beslut — vilka koncept som länkar till vilka, vilka påståenden som generaliseras, vilka detaljer som bevaras. Varje sådant beslut är en plats där en hallucination kan komma in i registret. Och när den väl är där är den inte längre märkt som en hallucination. Den är märkt som en rad i dina anteckningar.

Sebastian Raschkas Antigravity-team sa det rakt ut i sin genomgång av mönstret: "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-text gick längre: "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 är: "Det är vad lint-passet är till för." Karpathys workflow inkluderar ett lint-steg där LLM:en sveper genom wikin på jakt efter motsägelser och luckor. I teorin fångas ett kontaminerat påstående vid nästa pass.

I praktiken är lintern samma klass av modell som introducerade hallucinationen. Självgranskning har reella begränsningar. Vi har flera års forskning som visar att LLM:er är sämre på att fånga sina egna fel än på att fånga fel skrivna av ett annat system, och även tvärmodell-granskning lämnar långa svansar av oupptäckta misstag. Om Claude skriver en plausibel-men-falsk korsreferens på måndag är det sannolikt att Claude på onsdag läser den, finner den internt konsistent och certifierar den.

Det finns också ett olöst problem under allt detta: citationsprecision. En bra mänsklig wiki låter dig spåra ett påstående tillbaka till "sida 47, stycke 3" i källan. En LLM-kompilerad wiki har ingen inbyggd mekanism för att producera den länken. Du kan be den bifoga citat, och det gör den — men citatet självt kan vara fel, och vid den punkten granskar du granskaren.

Steph Ango, Obsidians medgrundare, gav ett råd som läses annorlunda när du sitter med kontamineringsproblemet. Han föreslog att hålla allt AI-genererat innehåll i ett separat valv så att AI:n kan "make a mess in their own space". Det är ingen konstig preferens. Det är någon som förstår markdown-kunskapsbaser djupt som berättar för dig att outputen från de här systemen ännu inte är pålitlig nog att blandas med dina riktiga anteckningar.

Den praktiska implikationen är viktig och ofta förbisedd: kontamineringsrisken är ungefär okej för personligt kunskapsarbete, där nedsidan av ett strö-fel är liten. Den är meningsfullt farlig i varje sammanhang där någon senare kommer att agera på wikin som om den vore sanning — juridisk forskning, medicinska anteckningar, reglerade affärsbeslut, allt som involverar andras pengar eller säkerhet. Karpathy-mönstret är inte ett kunskapslager för hög insats. Inte än.

2. Token-kostnaden ingen publicerar

Här är en märklig lucka i diskursen. Karpathys inlägg nämner att hans wiki har vuxit till ungefär hundra artiklar och fyrahundratusen ord. Det säger ingenting om vad det kostar att underhålla. Det gör inte heller de flesta entusiastiska genomgångar. Inte heller GitHub-repona.

Låt oss göra den matematik ingen annan verkar vilja göra, med den tydliga brasklappen att det är baksidan-av-kuvertet och dina siffror kommer att variera.

En typisk ingest i det här mönstret är inte billig. När ett nytt dokument anländer måste LLM:en läsa dokumentet, dra upp de tio till femton befintliga wiki-sidor som sannolikt berörs mest, bestämma vilka korsreferenser som ska uppdateras, skriva om de berörda sektionerna och skicka ut diffen. Om varje berörd sida i snitt är runt tretusen tokens, plus en fem-tusen-tokens system prompt, plus resonemangs-overhead, tittar du på ungefär trettiofemtusen tokens för en enda ingest. Det är för ett nytt input.

Lägg nu till lint-passet. Linting är en hel-wiki-sveping i Karpathys inramning, vilket betyder att den skalar med din wikis storlek. En hundra-artikel-wiki på tretusen tokens per artikel är trehundratusen tokens per lint, före något resonemang. Kör den veckovis och du är i multi-miljon-token-territorium bara för hygien.

Till Claude Opus-priser (~15 dollar per miljon input, ~75 dollar per miljon output) kan en aktiv wiki-användare som gör dagliga ingests och veckovisa lints plausibelt spendera någonstans mellan fem och femtio dollar i månaden beroende på hur aggressiv de är. Sonnet kapar det avsevärt. Haiku eller Gemini Flash kapar det mer. Men poängen är att ingen publicerar de verkliga siffrorna. Communityt opererar på tro.

Den enda benchmark som finns — siffran "84 % token-reduktion per session" från ussumant/llm-wiki-compiler — är verklig, men den mäter något annat än vad de flesta tror att den mäter. Det är ett per-query-effektivitetspåstående: när wikin är byggd använder frågor mot den färre tokens än att köra samma fråga över rå-källor. Det är sant och användbart. Det säger ingenting om kostnaden för att bygga och underhålla wikin i första taget, vilket är kostnaden som faktiskt skalar med ditt liv.

Lokala LLM:er är den uppenbara nödutgången. Ollama, LM Studio, llama.cpp — kör en 30B- eller 70B-modell på din egen maskin och den marginella token-kostnaden går till noll. Problemet är kvalitet. Kompileringsuppgifter är svåra. De behöver lång kontext, noggrann instruktionsföljning och konsekvent formatering över många pass. Nuvarande open-weight-modeller kan göra det, men kvalitetsfallet från Sonnet eller Opus är märkbart i exakt de dimensioner som spelar mest roll för en wiki — hallucinationsfrekvens, korsreferensnoggrannhet och stilistisk konsekvens.

Den ärliga sammanfattningen är att ingen än vet vad det här mönstret kostar i uthållig personlig skala, och de som bygger de mest högljudda implementationerna är inte de som betalar räkningen vid månadens slut. Om du bygger en, sätt ett budgettak på din API-nyckel innan du börjar. Du kommer att lära dig mer av att taket slår i än av något blogginlägg.

3. Second brain-gravgården

Det här är avsnittet som borde dämpa den största entusiasmen, eftersom det är den del av samtalet med mest bevis bakom sig. Historien om "lagra allt, hitta vad som helst"-verktyg är inte en historia om triumf. Det är en historia om imponerande lanseringar, stora rundor, entusiastiska tidiga användare och långsam kollaps.

Evernote. En gång värderat till över en miljard dollar, en gång med tvåhundra miljoner användare, en gång flaggskeppsprodukten för hela second brain-eran. Bending Spoons-förvärvet skar ner gratisplanen till femtio anteckningar och drev igenom nästan hundraprocentiga prishöjningar. År 2026 existerar produkten fortfarande, men den dör i offentligheten, och ingen i knowledge management-communityt behandlar den som en destination längre.

Roam Research. Nio miljoner dollar insamlade. "Tools for thought"-darlingen 2020 och 2021. Block references, bidirektionella länkar, en passionerad kult. Mot 2024 var momentumet borta. Femton dollar i månaden med en likgiltig mobilupplevelse och en grundare mer intresserad av filosofi än att skeppa. Aktiva användarantal trendade nedåt. Den existerar fortfarande. Den vinner inte längre.

Skiff. Fjorton miljoner insamlat, två miljoner användare, privacy-forward, en genuint bra produkt. Förvärvad av Notion i februari 2024. Helt nedlagd i augusti 2024. Sex månader från förvärv till borta.

Limitless (tidigare Rewind). Always-on kontextlagret. Ett hänge, en Mac-app, ambitionen att spela in hela ditt liv och låta AI göra mening av det. Meta förvärvade dem den 5 december 2025. Hängesförsäljningen stoppades samma dag. Mac-appen stängdes permanent den 19 december. Tjänsten upphörde helt i EU, Storbritannien och Brasilien — den sista detaljen läses som ett tyst erkännande av att GDPR aldrig riktigt löstes för "spela in allt".

Mem.ai. Tjugonio miljoner dollar ledd av OpenAI:s fond. Positionerad som den AI-native anteckningstagaren som äntligen skulle knäcka automatisk organisation. Kritiker började kalla den "fyrtio-miljoner-dollar-second brain-misslyckandet" när den inte hittade retention. Relanserad som Mem 2.0 i oktober 2025. Bättre. Inte fixad.

Det här är inte en lista över dåliga produkter. De flesta av dessa var välbyggda, välfinansierade och drivna av folk som förstod knowledge management djupt. De misslyckades ändå, och misslyckandemönstret är konsekvent nog att vara värt att namnge.

Produktivitetsfällan

Glasps analys av misslyckande inom knowledge management, som ekar tidigare arbete av APQC, identifierar tool hopping som det enskilt vanligaste misslyckandemodet. Användare cyklar genom Notion, Obsidian, Logseq, Capacities, Tana, Mem, och slutar med "fem halvfyllda system och ingen användbar kunskapsbas". Den andra dödaren är överingenjörskonst: användare spenderar mer tid på att bygga och justera systemet än att göra det kunskapsarbete systemet var tänkt att stödja. "Systemet blir projektet, och det faktiska kunskapsarbetet händer aldrig."

Det bredare sammanhanget är dystert. Ungefär 92 % av SaaS-startups misslyckas inom tre år (myICOR:s longitudinella analys, 2024). Den specifika delmängden "personlig knowledge management"-startups misslyckas på eller över den nivån. Marknaden har försökt och misslyckats lösa det här problemet i ungefär tjugo år.

Inget av detta är skäl till att inte försöka. Men om du läser en viral tråd om Karpathys wiki och känner lusten att bygga om hela ditt informationsliv runt den, bör den lusten sitta precis bredvid minnet av Roam, Mem, Skiff, Limitless och Evernote. De kändes alla oundvikliga också.

Varför det här kan vara annorlunda den här gången

Nu steel-man, eftersom den skeptiska saken inte är ett slutet argument.

Den enskilt tydligaste distinktionen mellan Karpathy-mönstret och varje tidigare second brain-verktyg är denna: de gamla verktygen krävde att du underhöll kunskapsbasen. Det var väggen användare slog i. Du fångade in i Evernote dag ett, organiserade febrilt i två veckor, och sex månader senare hade du tretusen otaggade anteckningar och en vag känsla av skuld. Underhållsbördan, inte fångstbördan, var det som dödade de här systemen.

Karpathy-mönstret är fundamentalt annorlunda i exakt den dimensionen. LLM:en gör underhållet. Den läser, den länkar, den lintar, den skriver om. Du är inte längre ansvarig för kunskapsbasens form — du är ansvarig för inputen och den tillfälliga granskningen. Det är ett meningsfullt annorlunda jobb.

Tool hopping var, i efterhand, rationellt beteende. Användare sökte efter ett verktyg som skulle göra jobbet åt dem, och inget sådant verktyg fanns. AI-agenter är det första som plausibelt kan. Det är inte att användare var nyckfulla. Det är att det de ville ha inte fanns än.

Hallucinationsproblemet är verkligt men avgränsat. Om du håller dina råa källor oföränderliga och behandlar den kompilerade wikin som flyktig och regenererbar — i princip som en cache ovanpå ett betrott källlager — är blast radius för en given hallucination liten. Du kan bygga om wikin från grunden när du tappar förtroende för den. Det är en egenskap inget tidigare anteckningsverktyg hade.

Kostnadsproblemet kan lösa sig själv på en kortare horisont än folk väntar sig. Lokala modeller i Gemma 3-, Llama 4- och Qwen 3-generationen stänger gapet på kompileringsstyrd uppgifter snabbare än de flesta kostnadsanalyser antar. Tolv till arton månader från nu kan matematiken för att köra det här lokalt helt enkelt vara annorlunda.

Och skiftet i värdeerbjudande spelar roll. Den förra vågen handlade om att lagra kunskap och hoppas att den skulle betala sig senare. Den här vågen handlar om att fråga mot en strukturerad version av dina inputs på begäran, och bygga om strukturen när den ruttnar. Det är ett annorlunda avtal med användaren, och det kan vara ett bättre.

Den ärliga frågan som avgör det

Skala bort hype och historia, och den öppna frågan är smalare än den ser ut.

Löser AI-underhållen kunskap faktiskt underhållsbördan, eller flyttar den bara bördan från "organisera anteckningar" till "kurera källor och köra hälsokontroller"?

Det optimistiska svaret: källkurering är ändligt arbete. Du har bara så många källor som du verkligen bryr dig om. Anteckningsorganisation, däremot, är oändlig — varje ny anteckning skapar nya organisatoriska beslut som ackumuleras.

Det pessimistiska svaret: källkurering är också oändlig om du tar det på allvar. Du blir redaktör för din egen mikro-Wikipedia, och redigering är ett heltidsjobb av en anledning.

Det realistiska svaret är att det helt beror på om dina inputs är avgränsade eller oavgränsade. Om du riktar Karpathy-mönstret mot "allt jag läser på internet" kommer du att drunkna. Om du riktar det mot ett specifikt forskningsprojekt, en enskild domän du försöker bemästra, eller en naturligt avgränsad brandslang som dina egna möten, har det en reell chans att fungera — eftersom underhållsproblemet är proportionellt mot inputvolymen, och inputvolymen faktiskt är taket.

Var det lämnar mötestranskript specifikt

Möten råkar ha en egenskap som direkt adresserar ett av "second brain-gravgårdens" misslyckandemoder: inputen är naturligt avgränsad. Du behöver inte bestämma vad du ska fånga. Mötena händer vare sig du vill eller inte, och uppsättningen möten du bryr dig om är ändlig på ett sätt som "intressanta artiklar" eller "tankar jag hade idag" aldrig är.

Det gör underhållsbördan genuint lägre än en fånga-allt-du-läser-wiki. Det gör också hallucinationsrisken lägre på ett subtilt sätt: fullständiga samtalstranskript innehåller mycket kontext per token, så LLM-extraktion är mer grundad än extraktion från en kortfattad anteckning. Det finns mer signal för modellen att hålla sig till. Integritets- och kostnadsfrågorna kvarstår, och de är inte små. Men den strukturella passformen är bättre än de flesta domäner.

Proudfrog är byggt runt denna hypotes — att möten är rätt omfattning för en AI-underhållen kunskapsbas just för att inputen är naturligt begränsad. Huruvida den hypotesen är korrekt är fortfarande en öppen fråga, och vi kommer inte att låtsas annat i en skeptisk artikel om exakt den här typen av hypotes. Vill du ha den mer detaljerade versionen av argumentet gräver möte-till-wiki-gapet och den kompletta workflow-guiden vidare. Vill du se fallet för möten som en knowledge worker-workflow, bor det där.

Vad den smarta skeptikern borde göra

Om du har läst så här långt och fortfarande vill prova, här är den version av experimentet som kommer att lära dig mest med minst bortkastad tid.

• Starta med ett avgränsat användningsfall. Ett specifikt forskningsprojekt, dina möten, ett teams dokumentation. Börja inte med "all min kunskap". Du kommer att förlora.
• Håll råa källor oföränderliga och Git-versionerade. Wikin är en härledd artefakt. Du ska kunna radera den helt och regenerera den utan att förlora något viktigt.
• Behandla wikin som regenererbar, inte dyrbar. I det ögonblick du känner dig beskyddande mot den kompilerade versionen har du börjat bygga samma fälla som den förra generationen byggde.
• Sätt ett hårt budgettak på din LLM-API-nyckel innan du börjar. Inte efter. Att taket slår i är data. Överraskningsräkningar är det inte.
• Granska för hallucinationer veckovis under den första månaden. Plocka fem påståenden slumpmässigt varje vecka och spåra dem tillbaka till källa. Om du inte kan, är det vad du lärde dig.
• Bestäm i förväg när du kommer att sluta. Skriv ner vad som skulle bevisa att experimentet har misslyckats — en kontamineringsfrekvens, en månadskostnad, en tidsbudget för underhåll — och hedra det när du når det. Annars kommer sunk cost att hålla dig kvar i systemet långt efter dess användbara liv, vilket är precis hur den förra generationen second brains slutade som gravgårdar.

Det här är inte cynism. Det är den disciplin som den förra vågen av verktyg inte hade. Karpathy-mönstret kan vara den första knowledge management-arkitekturen som genuint klarar underhållsväggen. Det kanske inte är det också. Det enda sättet att få reda på det är att prova det på det sätt en skeptiker provar saker — avgränsat, granskningsbart, billigt, och med en förutbestämd utgång.

Se hur Proudfrog angriper möteskunskap om den avgränsade-input-versionen av det här argumentet intresserar dig.

---

Vanliga frågor

Är LLM-wiki-ansatsen faktiskt ny, eller bara RAG ompaketerat?

Det är inte RAG. RAG hämtar chunks vid frågetid baserat på likhet; Karpathy-mönstret kompilerar en strukturerad artefakt i förväg och frågar mot artefakten direkt. De löser olika problem. RAG skalar bättre till miljontals dokument. Kompilering fungerar bättre i personlig skala eftersom den bevarar resonemang och explicita korsreferenser som likhetssökning kastar. Nyheten är inte wiki-formatet — markdown-wikis är trettio år gamla — det är att använda LLM:en som den kontinuerliga underhållaren av wikin snarare än som frågemotorn ovanpå råa källor.

Hur mycket kostar det faktiskt att köra en Karpathy-stil-wiki?

Ingen har publicerat en trovärdig siffra. Baksidan-av-kuvertet-matematik antyder att en aktiv användare som gör dagliga ingests och veckovisa hel-wiki-lints kan spendera ungefär fem till femtio dollar i månaden på en frontier-modell som Claude Sonnet eller Opus, beroende på wiki-storlek och användningsintensitet. Billigare modeller kapar det avsevärt, lokala modeller eliminerar den marginella kostnaden men kostar kvalitet. Sätt ett budgettak på din API-nyckel innan du börjar. Behandla alla siffror du ser i blogginlägg som uppskattningar tills någon publicerar en riktig studie.

Vad händer när LLM:en hallucinerar ett faktum och skriver in det i min wiki?

Det stannar där tills du fångar det. Lint-passet ska hitta motsägelser, men lintern är samma klass av modell som introducerade felet, och självgranskning har reella begränsningar. Det bästa nuvarande försvaret är att hålla råa källor oföränderliga och behandla den kompilerade wikin som regenererbar — om du tappar förtroende för wikin, bygg om den från källor. För hög-insats-sammanhang (juridiska, medicinska, finansiella beslut) är hallucinationsrisken just nu hög nog att du inte bör använda det här mönstret som ett primärt kunskapslager.

Varför har så många "second brain"-produkter dött?

Det konsekventa misslyckandemodet är att underhållsbördan så småningom väger tyngre än värdet. Användare fångar entusiastiskt, organiserar några veckor, sen driver de iväg. Tool hopping förstärker problemet — användare cyklar genom system på jakt efter ett som gör jobbet åt dem. Evernote, Roam, Mem, Skiff och Limitless slog alla i någon version av den väggen. Karpathy-mönstret är intressant just för att det direkt riktar sig mot underhållsväggen, genom att låta LLM:en göra underhållet. Huruvida det räcker för att bryta mönstret är fortfarande en öppen fråga.

Är det säkrare med lokala LLM:er?

Säkrare för integritet och kostnad, ja. Säkrare för hallucination, inte direkt — open-weight-modeller i nuvarande generation hallucinerar mer på kompileringsuppgifter än Claude Sonnet eller GPT-klassens modeller, inte mindre. Rätt svar för de flesta användare 2026 är en hybrid: använd en frontier-modell för kompilerings- och lint-passen, använd en lokal modell för avslappnade frågor mot den färdiga wikin. Inom tolv till arton månader kommer lokala modeller sannolikt att vara tillräckligt bra för att hantera kompileringspassen också, och kostnadskalkylen skiftar.

Ska jag bry mig om att prova det här om jag inte är utvecklare?

Förmodligen inte än, om du menar att bygga en själv från Karpathys beskrivning. Community-verktygen är tidiga, workflowsen är sköra, och felsökningen kräver bekvämhet med markdown, shell-skript och prompt engineering. Vill du ha värdet utan att bygga, vänta några månader på att den första vågen av produktifierade versioner ska skaka ut — eller använd ett domänspecifikt verktyg som redan implementerar mönstret för ett avgränsat input som möten, forskningsartiklar eller en specifik kodbas. Idéerna kommer fortfarande att vara här när verktygen kommer ikapp.