Under två år var standardsvaret på “hur ger jag en LLM min kunskap?” RAG. Bygg en vektordatabas. Dela upp dina dokument. Bädda in dem. Kör nearest-neighbor-sökning vid frågetid. Sy ihop resultaten i prompten.

Det fungerade. Ungefär. Alla som faktiskt har levererat ett RAG-system känner till felmönstren: bitar som förlorar kontext, inbäddningar som hämtar fel passage, ogenomskinliga rankningar, ingen härkomst, konstiga kantfall när användaren frågar något som indexet inte var inriktat på.

I april 2026 lade Andrej Karpathy upp ett arbetsflöde som gör nästan inget av det och fungerar bättre för personlig kunskap. Han kallar det LLM Knowledge Bases. Arkitekturen är bara en mapp med markdown-filer, en LLM med filsystemsåtkomst och en vana. VentureBeat kallade det “ett evolverande markdown-bibliotek underhållet av AI” — en beskrivning som fångar vad som faktiskt är nytt.

Post-RAG-mönstret är här. Den här artikeln förklarar vad det är, varför det fungerar och hur Save Vault gör det tillgängligt utan någon utvecklarinställning.

Vad RAG försökte lösa

Ursprungsproblemet: LLMs har ett fast kontextfönster, din kunskapsbas är större än fönstret, så du behöver ett sätt att hämta den relevanta delen för varje fråga.

2023 var vektorer det uppenbara svaret. Bädda in allt, sök efter likhet, injicera top-k-bitarna. Det komponerade bra med de små kontextfönstren hos GPT-3.5 och Claude 1. Hela “AI-startup”-mönstret var “RAG över X.”

Tre saker förändrades.

Kontextfönster exploderade. Claude levererade 1M-token-kontext i år. Gemini och GPT-5 är liknande. En miljon tokens är ungefär 750 000 ord — tillräckligt för att hålla en liten wiki helt i minnet.
Filesystem MCP lanserades. LLMs kan nu öppna filer på disk direkt. De behöver inte förindexerade bitar. De kan navigera, läsa och läsa om som en människa.
LLMs blev bättre på att läsa. Claude Opus 4 kan ta in hundratals filer i en session och resonera sammanhängande om dem. Flaskhalsen förflyttades från “hämtningskvalitet” till “vad behöver människan egentligen.”

När dessa tre saker var sanna började RAG se ut som en omväg för begränsningar som inte längre finns.

Hur Markdown-wiki-mönstret ser ut

Karpathys upplägg, förenklat:

Råmapp. Varje webbsida han vill behålla sparas som en .md-fil i en raw/-katalog. Han använder Obsidian Web Clipper för detta.
Kompileringspass. Regelbundet läser en LLM-agent (Claude Code i hans fall) allt i raw/, genererar konceptsidor, skriver sammanfattningar och skapar bakåtlänkar. Detta producerar en strukturerad wiki ovanpå råmaterialet.
Frågeslinga. När han har en fråga frågar han LLM:en. Den söker i wikin, öppnar relevanta filer och svarar med hjälp av innehållet.
Lintpass. Ibland skannar LLM:en wikin efter inkonsekvenser, saknade data eller nya kopplingar värda att anteckna.

Hans nuvarande forskningswiki har ~100 artiklar och ~400 000 ord. Han ställer komplexa frågor och får källhänvisade svar tillbaka.

Ingen vektordatabas. Ingen inbäddningsmodell. Ingen uppdelningsstrategi. Ingen hämtningsrankning. Bara markdown-filer, en mappstruktur och en LLM som kan läsa dem.

Varför det fungerar bättre än RAG (för detta)

Wiki-mönstret har strukturella fördelar som RAG inte kan matcha utan att bli en wiki själv.

Härkomst är gratis. Varje svar citerar en fil. Du kan öppna den, läsa den, redigera den, ta bort den. Ingen “inbäddningen sa det.”

Redigering är trivialt. En markdown-fil är text. Öppna den i valfri redigerare. Rätta ett stavfel. Lägg till en anteckning. Ta bort ett avsnitt. Nästa fråga återspeglar ändringen omedelbart. Det finns inget om-inbäddningssteg.

Struktur förstärks. När LLM:en kompilerar wikin bygger den bakåtlänkar och konceptsidor. Wikin blir bättre ju mer du sparar, eftersom LLM:en har mer kontext att koppla nya poster till. Ett vektorindex växer bara.

Portabilitet är total. En mapp med .md-filer fungerar i Obsidian, VS Code, GitHub, Logseq, vim eller cat. En vektordatabas är en svart låda som du behöver en specifik körningsmiljö för att läsa.

Du kan läsa den själv. Det låter självklart, men det är den största fördelen. Du vill ibland veta vad som finns i din kunskapsbas. Med RAG är det en rapportfråga. Med markdown är det ls.

Den ärliga avvägningen: RAG vinner fortfarande när du har miljontals dokument, flertenantåtkomst eller hårda latenskrav (tänk kundsupport-chatbots över ett korpus av miljontals hjälpartiklar). För personlig kunskap — din läsning, din forskning, din domän — är wiki-mönstret nu strikt bättre.

Den saknade biten: Inmatning

Karpathys mönster har ett tyst antagande: att det är enkelt att få ren markdown in i raw/-mappen. För utvecklare som redan använder Obsidian Web Clipper är det ungefär så. För alla andra är det här steget där arbetsflödet dör.

Web Clipper kan ha svårt med betalväggsidor, JavaScript-tunga sajter, videoinnehåll, X-trådar och allt dynamiskt. Folk sparar rörig HTML, ger upp och drar slutsatsen att “wiki-grejen är inte för mig.”

Save-tillägget finns specifikt för att fixa det här steget. Det använder Gemini för att extrahera rent innehåll från godtyckliga sidor, inklusive:

Artiklar bakom betalväggar du har tillgång till
YouTube-videor (fullständig transkription + AI-sammanfattning)
X/Twitter-trådar
Instagram-reels och TikTok-texter (transkriberade)
Reddit-diskussioner
Dokumentation med kodblock intakta
Dynamiska SPA:er som traditionella klippare fastnar på

Ett klick. Ren markdown ut på andra sidan. Lägg i mappen.

Den andra saknade biten: MCP-inställningen

Karpathys mönster förutsätter också att du kan konfigurera en MCP-server. För Claude Code-användare är detta ett cd på en rad. För alla som använder Claude Desktop innebär det att redigera en JSON-konfigurationsfil och starta om appen — och få sökvägen rätt, och komma ihåg att göra om det när du flyttar mappar.

Save Vault komprimerar båda saknade bitarna till en app:

Save-tillägget matar ren markdown in i Save Vault automatiskt
Save Vault skriver till ~/Documents/Save Vault/ organiserat i kunskapsbaser (undermappar)
En inbyggd MCP-server exponerar list_knowledge_bases, list_files, read_file och search till Claude
“Anslut till Claude”-växeln i menyraden kopplar MCP-servern till Claude Desktop och Claude Code, utan JSON-redigering

Resultatet är Karpathy-mönstret med de grova kanterna slipade bort. Spara en sida → den landar i din vault → Claude kan svara på frågor om det. Ingen vektordatabas, ingen uppdelning, inga inbäddningar.

Hur det ser ut i praktiken

Föreställ dig att du forskar om en konkurrent.

Dag 1. Du sparar deras prissida, tre blogginlägg och en Hacker News-tråd om deras såddfinansiering. Fem filer i din Konkurrenter-KB.

Dag 5. Du frågar Claude: “Vilka prisändringar har det här företaget gjort det senaste året, och hur har kunderna reagerat?” Claude söker i din Konkurrenter-KB, läser relevanta filer, citerar prissidan, lyfter fram HN-trådens sentiment och svarar — allt källhänvisat.

Dag 30. Du har 40 filer över Konkurrenter, Kunder och AI-forskning. Du ber Claude kompilera varje KB till en wiki. Den skriver konceptsidor, länkar dem, flaggar motsägelser. Du har nu tre levande wikis som du kan fråga som sökmotorer, men bättre — eftersom de bara innehåller vad du kuraterat.

Dag 90. Dina wikis är större än någon analysrapport du skulle köpa, mer aktuell än någon konsultpresentation och helt din. Varje påstående är källhänvisat till en fil du sparade.

Det här är hur en personlig kunskapsbas faktiskt känns när friktionen är borta. RAG skulle leverera detta och gjorde det inte. Karpathy-mönstret gör det — när inmatnings- och MCP-bitarna är kopplade ihop åt dig.

Prova det

Installera Save Chrome-tillägget
Installera Save Vault från savemarkdown.co
Aktivera Anslut till Claude i menyraden
Spara 10 saker du velat läsa
Öppna Claude och ställ en fråga som väver ihop dem

Det är post-RAG-arbetsflödet. Det ersätter redan vektordatabaser för personlig kunskap. Det enda som återstår är att börja bygga din egen.

Save Vault är gratis. Save-tillägget är gratis för 3 sparningar i månaden, $3,99/månad obegränsat. savemarkdown.co.