LLM‑wiki: Förstå den nya AI‑kunskapsarkitekturen

En LLM‑wiki sammanställer dina källor till en beständig, korslänkad kunskapsbas vid inläsning och svarar sedan utifrån den, i stället för att varje gång på nytt hämta råa textbitar. På så sätt byggs kunskapen upp i takt med att du lägger till källor, i stället för att återskapas från grunden vid varje fråga.

Jag går igenom var idén om LLM‑wiki kommer ifrån, hur den står sig mot Retrieval‑Augmented Generation (RAG) och om den innebär ett verkligt skifte i hur AI‑system hanterar kunskap.

Ursprunget till LLM‑wiki‑konceptet

Idén om LLM‑wiki tog form 2026, presenterad av Andrej Karpathy och plockades upp av ett par open‑source‑projekt som gjorde den körbar i praktiken.

Idén är enkel. AI‑system 2026 lägger mycket tid på att läsa om samma dokument. Du laddar upp en PDF, modellen hämtar textbitar, svarar på en fråga och går vidare. Nästa vecka laddar du upp en annan PDF om samma ämne och modellen gör exakt samma sak. Ingenting förs vidare.

Den största förändringen är att hämtning och sammanställning är olika jobb.

Till exempel:

• Hämtnings‑först‑system hittar relevanta textfragment vid frågetillfället och lämnar dem till modellen som kontext. Modellen arbetar med det som hämtaren tog fram.
• Sammanställnings‑först‑system läser varje källa en gång vid inläsning, plockar ut det som är viktigt och skriver in det i en strukturerad kunskapsbas. Modellen svarar sedan utifrån den basen.

En LLM‑wiki tillhör den andra kategorin. När du lägger till en ny källa läser modellen den, uppdaterar befintliga sidor, skapar nya där det behövs och flaggar motsägelser mot sådant som redan är arkiverat. Kunskapsbasen växer med varje källa du lägger till, och modellen får en bättre grund att svara utifrån varje gång.

Detta är det första konkreta avsteget från hämtnings‑först‑paradigmet som dominerat sedan RAG blev standard. RAG behandlar varje fråga som en ny uppslagning mot råa dokument. En LLM‑wiki ser inläsningen som tillfället då arbetet sker, och frågetillfället som läsning ur en bas som redan är genomtänkt.

Vad är en LLM‑wiki?

En LLM‑wiki är en beständig, AI‑underhållen kunskapsbas som fortlöpande syntetiserar information från källdokument till strukturerade, sammanlänkade sidor.

Tre saker skiljer den från en mapp med filer eller ett vektorarkiv.

• Beständig: Sidor skapas en gång och uppdateras när nya källor kommer. Ingenting behöver härledas på nytt vid frågetillfället eftersom syntesen redan är nedskriven.
• Kontinuerligt uppdaterad: Varje inläst källa triggar redigeringar i hela wikin, till exempel nya sidor för nya entiteter, revideringar av befintliga sammanfattningar, notiser där färska data motsäger äldre påståenden.
• Dubbel målgrupp: Sidorna är läsbara för människor och tillräckligt strukturerade för att AI‑agenter ska kunna resonera över dem. Markdown, korslänkar och en konsekvent layout gör dubbel nytta.

Det avgörande greppet är att wikin blir det primära kunskapslagret. Ursprungliga dokument ligger kvar i rå lagring som revisionsspår, men ingen frågar dem direkt. Chatsystem, agenter och forskningsassistenter läser wikin, för det är där den sammanställda, korsrefererade versionen av kunskapen finns.

LLM‑wikiarkitekturen

Arkitekturen är snarare en trestegs‑pipeline. Källor kommer in, modellen sammanställer dem till wikisidor och AI‑applikationer läser från dessa sidor. 

LLM‑wikiarkitektur

Jag går igenom alla steg.

Källdokument

Allt textbaserat kan läsas in. Till exempel:

• Dokumentation och PDF:er
• Egna anteckningar och mötesutskrifter
• Kodförråd
• Webbinnehåll klippt från artiklar eller skrapat från sajter

Råa källor placeras i oföränderlig lagring. När de väl lästs in läser modellen från dem men ändrar dem aldrig, vilket ger ett rent revisionsspår från varje wikipåstående tillbaka till sin källa.

Kunskapssammanställning

Wikin skapas i detta steg. När en ny källa anländer kör modellen en uppsättning operationer:

• Extrahera begrepp: Entiteter, ämnen, definitioner och påståenden dras ut ur källtexten.
• Uppdatera befintliga sidor: Om en entitet eller ett begrepp redan har en sida reviderar modellen den med den nya informationen och flaggar motsägelser.
• Skapa nya sidor: Sådant som inte passar på en befintlig sida får en egen.
• Länka relaterade ämnen: Korsreferenser läggs till i båda riktningar så att sidorna förblir sammankopplade när wikin växer.

En enda inläst källa kan "uppdatera" 10 till 15 sidor i detta svep. Det är poängen – arbetet med att koppla nytt material till befintlig kunskap sker en gång, vid inläsning, inte vid varje fråga som med RAG.

AI‑applikationer

Wikin är utformad för att läsas av flera typer av konsumenter. Till exempel:

• Chatsystem som besvarar frågor mot den sammanställda kunskapen i stället för mot råa dokument.
• Forskningsassistenter som följer korsreferenser för att bygga upp en bild av ett ämne.
• Programvaruagenter som använder wikin som varaktigt minne i långvariga uppgifter.
• Kunskapssystem i företag som exponerar wikin för interna verktyg, dashboards, or MCP servers.

Wikin är i mitten. Källor matar in från ena sidan, applikationer läser från den andra och sammanställningslagret håller båda ändar i synk.

LLM‑wiki jämfört med traditionell RAG

Den största skillnaden mellan traditionell RAG och en LLM‑wiki är när arbetet sker.

Traditionell RAG

RAG hämtar dokumentfragment vid frågetillfället. Du ställer en fråga, en inbäddningssökning plockar de k mest relevanta fragmenten från ett vektorarkiv och dessa fragment läggs till i modellens kontext tillsammans med din fråga. Modellen genererar ett svar från den tillfälliga kontexten och glömmer allt när svaret är klart.

Kontexten är förbrukningsvara. 

Fragmenten som besvarade din senaste fråga försvinner ur kontext i samma stund som modellen är klar. Ställer du en närliggande fråga i morgon kör hämtaren igen, plockar fragment igen och modellen syntetiserar igen. Ingenting byggs upp mellan frågorna.

LLM‑wiki

En LLM‑wiki sammanställer information vid inläsning. När du lägger till en källa läser modellen den en gång, skriver in det viktiga i strukturerade sidor, uppdaterar korsreferenser och lagrar resultatet som beständig markdown. Frågetillfället handlar sedan om att läsa från den sammanställda basen snarare än att återsyntetisera från råa fragment.

Kunskapen är beständig och den utvecklas. 

Varje ny källa triggar ändringar i hela wikin, så motsägelser flaggas, äldre sammanfattningar revideras och kopplingarna mellan ämnen blir tätare över tid.

Avvägningar

Inget av angreppssätten är universellt bättre. De optimerar för olika saker.

Här är några saker att ha i åtanke:

• Färskhet: RAG har en fördel här eftersom den läser direkt från källdokument vid frågetillfället. Om du uppdaterar underliggande dokument ser nästa fråga ändringen direkt. En LLM‑wiki måste läsa in källor på nytt för att uppdatera sina sidor, så det finns en fördröjning mellan rå sanning och sammanställd kunskap.
• Noggrannhet: En LLM‑wiki vinner när frågor kräver syntes över många källor, eftersom syntesen redan är gjord och genomgången. RAG kan missa kopplingar när relevanta fragment spänner över fler bitar än som får plats i kontextfönstret, eftersom den aldrig ser hela bilden i ett svep.
• Underhåll: RAG kräver nästan inget underhåll när vektorarkivet väl är på plats eftersom indexering är mekanisk. En LLM‑wiki behöver aktiv skötsel, till exempel lint‑svep för att fånga inaktuella påståenden, motsägelsekontroller och ibland genomgångar för att rensa bort övergivna sidor. Avvägningen är att en underhållen wiki blir rikare över tid medan ett RAG‑index förblir platt.
• Skalbarhet: RAG skalar förutsägbart med antalet dokument eftersom hämtning är ett sökproblem. En LLM‑wiki skalar med modellens förmåga att hålla den sammanställda kunskapen koherent när den växer. Förbi en viss storlek behöver wikis egna indexfiler, sökverktyg eller inbäddningslager för att förbli navigerbara.

Här är en sammanfattning sida vid sida:

LLM‑wiki kontra RAG

RAG och LLM‑wikis kompletterar också varandra i praktiken. Vissa implementationer kör RAG över själva wikin när den växer förbi vad en indexfil klarar av.

Varför AI‑agenter gynnas av en LLM‑wiki

AI‑agenter drabbas mer än chatsystem av problemet med ingen ihågkomst. En enskild konversation kan tåla återhämtning, men agenter kan köras i timmar eller dagar och återupptäcka samma fakta över dussintals uppgifter. En LLM‑wiki ger dem en plats att lägga det de lär sig, så att de inte behöver lära sig det igen.

Här är ett par områden där beständig kunskap visar störst potential:

• Programvaruutveckling: En kodningsagent som arbetar med en kodbas över veckor bygger upp kunskap om moduler, konventioner, tidigare buggar och designbeslut. Utan en wiki återskapas det sammanhanget vid varje session. Med en wiki läser agenten de sammanställda sidorna och tar vid där förra sessionen slutade.
• Långsiktig forskning: En agent som följer ett ämne över hundratals artiklar kan inte hålla allt i kontext. En wiki ger den en plats att arkivera sammanfattningar och återbesöka den växande bilden utan att läsa om hela korpusen.
• Företagsassistenter: Assistenter som används i ett företag möter samma frågor från olika anställda varje dag. En wiki låter assistenten svara utifrån sammanställd intern kunskap i stället för att söka igenom samma uppsättning sidor vid varje förfrågan.
• Organisatoriskt minne: Team tappar sammanhang när personer slutar eller möten tar slut. En LLM‑wiki som matas med utskrifter, ärenden och dokument håller sammanhanget intakt.

När den implementeras på rätt sätt ser du att LLM‑wikin ger utdelning på tre ställen:

1. Färre upprepade sökningar: En agent som läser från en sammanställd sida behöver inte köra samma webbsökning eller vektorförfrågan som den körde i går.
2. Rikare kontext: Wikisidor innehåller redan syntetiserad information, så agenten startar varje uppgift med en tätare, bättre sammanlänkad bas än vad råa fragment skulle ge.
3. Kumulativt lärande: Varje session adderar till wikin, och nästa session drar nytta av vad den förra tog reda på. Så får du en agent som faktiskt blir bättre på sitt jobb över tid i stället för att nollställa vid varje prompt.

Att bygga en LLM‑wiki

Arbetsflödet för att bygga en wiki är en loop. Källor kommer in, sidor skrivs och skrivs om, och allt förfinas i takt med att korpusen växer.

Loop för att bygga LLM‑wiki

• Läs in dokument. Första steget är att få in källor i rå lagring. Dokument läses en gång och hålls oföränderliga så att varje efterföljande påstående kan spåras till en specifik källa. Inläsning kan vara en enstaka fil, en batch eller en ström från en mapp som modellen bevakar.
• Identifiera entiteter och begrepp. För varje ny källa extraherar modellen det viktiga – namngivna entiteter, nyckelbegrepp, påståenden, definitioner, relationer. Det är här ostrukturerad text blir något som wikin kan arkivera. Extraktionssvepet kontrollerar också den befintliga wikin för att se vad som redan täcks och vad som är nytt.
• Generera eller uppdatera sidor. Nya entiteter får nya sidor. Befintliga sidor revideras med den nya informationen. Om den nya källan motsäger ett befintligt påstående flaggar modellen det på sidan i stället för att skriva över. En enda inläst källa ändrar ofta 10 till 15 sidor eftersom källor vanligen handlar om mer än en sak.
• Underhåll länkar. Korsreferenser läggs till i båda riktningar så att sidorna förblir sammanlänkade. Om en ny sida om RAG nämner vektordatabaser och en sida om vector databases redan finns, länkas båda sidorna.
• Förfina kunskapen kontinuerligt. Regelbundna lint‑svep fångar problem som byggs upp över tid. Till exempel motsägelser mellan sidor, inaktuella påståenden som nyare källor har passerat, övergivna sidor som ingen länkar till, och viktiga begrepp som nämns i förbifarten men saknar egen sida. Detta steg håller wikin frisk när den skalar.

Detaljerna beror på din stack, men formen är densamma i olika implementationer. Läs in, extrahera, skriv, länka, förfina – och upprepa loopen.

Vanliga funktioner i LLM‑wikisystem

De flesta LLM‑wikiimplementationer har samma uppsättning funktioner. Detaljerna skiljer sig, men byggstenarna delas mellan projekten.

Automatisk kunskapssammanställning

Wikin skriver sig själv. När en källa läses in extraherar modellen det viktiga och arkiverar det på sidor utan mänsklig inblandning. Manuell skötsel tar död på traditionella wikis, eftersom människor tröttnar på att uppdatera korsreferenser och sammanfattningar. Modeller gör inte det, så detta är funktionen som får hela mönstret att fungera.

Länkade sidor

Varje sida kopplas till relaterade sidor genom korsreferenser. När en sida om transformers nämner attention mechanisms länkar båda sidorna till varandra. Resultatet är en navigerbar graf som du kan vandra igenom genom att följa referenser, vilket är hur du hittar kopplingar du inte visste fanns.

Källhänvisning

Varje påstående på varje sida kan spåras till en specifik källa. Råa dokument förblir oföränderliga så att du alltid kan verifiera var informationen kommer ifrån. Detta är viktigt av två skäl – det ger ett revisionsspår när du behöver kontrollera noggrannhet, och det låter modellen dra tillbaka påståenden rent när en källa tas bort.

Kunskapsgrafer

Wikins länkade struktur är i sig en kunskapsgraf. Noderna är sidor, kanterna är korsreferenser och grafens form visar vad korpusen egentligen handlar om. Navsidor dyker automatiskt upp kring viktiga begrepp, övergivna sidor signalerar luckor och täta kluster visar de områden wikin kan bäst.

Beständigt minne

Wikin finns tillgänglig mellan sessioner. Chatkontext försvinner när konversationen tar slut, men wikisidor ligger kvar på disk som markdown. Det är detta som gör en chatmodell till något som kan bära kunskap framåt över dagar, projekt och agentkörningar.

Kontinuerliga uppdateringar

Nya källor triggar revideringar av befintliga sidor, inte bara tillägg. Om en artikel som publicerades förra månaden motsäger vad som skrevs för sex månader sedan flaggar wikin det och uppdaterar de berörda sidorna. Kunskapsbasen närmar sig korrekthet över tid i stället för att ackumulera inaktuella påståenden.

Dessa funktioner är inte oberoende. Det betyder att en wiki utan källhänvisningar inte kan betros. På samma sätt blir en wiki utan kontinuerliga uppdateringar inaktuell, och en wiki utan länkade sidor är bara en mapp med sammanfattningar. Värdet kommer av att alla fungerar tillsammans.

Verkliga användningsområden för LLM‑wikis

Mönstret jag har diskuterat hittills är generellt, så nu går jag igenom några verkliga tillämpningar där LLM‑wiki kan vara användbart, till och med mer användbart än RAG.

Forskningslitteratur

Den som följer ett ämne över dussintals eller hundratals artiklar brottas med samma problem – artiklarna hopar sig snabbare än du kan bearbeta dem. En LLM‑wiki läser varje artikel när den kommer, extraherar påståendena, arkiverar dem under relevanta begrepp och flaggar motsägelser mot sådant som redan lästs. Resultatet är en löpande syntes som ligger i fas med fältet i stället för en mapp med PDF:er du aldrig hinner läsa.

Teknisk dokumentation

Kodbaser har dokumentationsskuld som vanligtvis växer varje sprint. Ofta fattas designbeslut i Slack‑trådar och arkitekturnoteringar lever i någons Notion. Den faktiska koden är den enda källan som garanterat är aktuell. En wiki som matas med kodbasen, kommentarer, pull requests och intern dokumentation kan sammanställa en bild av systemet som hänger ihop med koden. Ingenjörer kan ställa frågor mot wikin i stället för att fråga personen som skrev modulen för tre år sedan.

Företagskunskapsbaser

Företag ackumulerar kunskap över ärenden, mötesutskrifter, produktspecifikationer och interna wikis. En LLM‑wiki kan läsa in från allt detta och sammanställa ett enhetligt kunskapslager som hålls aktuellt. Medarbetare kan fråga en gång i stället för att söka i fyra olika verktyg.

Personlig kunskapshantering

Anteckningsappar har löst lagringsproblemet men inte syntesproblemet. Du har fortfarande hundratals anteckningar, artiklar och markeringar, och du kommer inte att återvända till de flesta. En wiki som matas av din Obsidian‑valv, till exempel, kan omvandla högen av anteckningar till en sammanställd kunskapskropp du faktiskt kan fråga. 

AI‑agenters minne

Agenter som kör i timmar eller dagar behöver någonstans att lägga det de lär sig. Wikin ger dem varaktigt minne som kan användas mellan sessioner – vad som fungerade, vad som inte gjorde det, vilka filer de redan läst, vilka vägar de har prövat. Detta är särskilt användbart för agenter byggda on top of Claude Code or similar tools, där samma kodbas bearbetas över många sessioner och kontexten från tidigare körningar är det som gör den aktuella körningen effektiv.

Aktuella LLM‑wikiimplementationer

LLM‑wikiområdet 2026 är tidigt. Det mesta som finns är open source och byggt av individer eller små team. Det är långt ifrån där RAG är i dag.

Karpathy's original gist is where a lot of implementers started. It describes the pattern in enough detail that anyone with an LLM agent can build their own version by pasting the doc into Claude Code or a similar tool. Most of the current wikis start as personal projects built on top of a shared idea.

Open‑source‑insatser är där idén arbetas fram. Projects like llm-wiki.net publish their code under permissive licenses so others can fork, extend, or adapt them to their own workflows. The advantage is that you can see exactly what the wiki is doing and change it when your needs don't match the default.

Lokalt‑först‑angreppssätt körs helt på din dator. Källor sparas på disk, wikin är en mapp med markdownfiler och modellen läser och skriver via en lokal agent. Obsidian är det vanligaste gränssnittet eftersom det redan är byggt för markdown och korsreferenser. Det ger dig mest kontroll, eftersom källorna inte lämnar din maskin och du kan granska varje sida som modellen skriver.

Hostade implementationer börjar dyka upp men är mindre vanliga. Mönstret passar inte SaaS‑modellen lika bra som RAG gör eftersom wikin är tänkt att vara din – dina källor, dina sidor, dina beslut om vad som ska arkiveras. Hostade varianter fungerar bäst för teamwikis där värdet av delad kunskap överväger kostnaden för att hosta källor på någon annans infrastruktur.

Men i juli 2026 är inget av detta färdigt. Saker håller fortfarande på att mejslas ut, och de flesta projekt som finns i dag är bara prototyper.

Fördelar och begränsningar

Mönstret LLM‑wiki har styrkor och kostnader. Båda är värda att känna till innan du beslutar att bygga en.

Fördelar

• Beständig kunskap: Wikin finns kvar efter slutet av en enskild session. Det modellen tog reda på förra månaden står kvar på sidan i dag, och nytt arbete bygger på det i stället för att börja om.
• Återanvändbar syntes: Arbetet med att koppla källor sker en gång, vid inläsning. Varje fråga därefter läser från det sammanställda resultatet i stället för att återsyntetisera från råtext. Det sparar beräkning och ger bättre svar eftersom modellen redan har gjort tänkandet.
• Färre upprepade hämtningar: En wiki som redan har en sida om ett ämne behöver inte söka i råkorpusen varje gång ämnet dyker upp. Det är viktigt för agenter som kör i timmar och annars skulle köra samma sökningar om och om igen.
• Strukturerad organisering: Sidor och korsreferenser ger något du kan bläddra i och resonera kring, särskilt jämfört med en mapp med PDF:er.

Begränsningar

• Hålla information aktuell: Wikin måste läsas in på nytt när källor ändras. Om ett dokument uppdateras och du inte kör inläsningen igen fortsätter wikin att referera till den gamla versionen. RAG har inte det problemet eftersom den läser livekällor vid frågetillfället.
• Verifieringsutmaningar: Varje påstående på en wikisida har skrivits av en modell. Källhänvisning hjälper, men du måste ändå lita på att modellen sammanfattade källan korrekt.
• Underhåll: Motsägelsekontroller och ominläsning är inte gratis. En wiki som inte underhålls blir inaktuell, och underhåll tar tid och beräkningskraft även när modellen gör jobbet.
• Möjlig kunskapsdrift: Varje inläsning är en chans för modellen att introducera små fel. Över hundratals inläsningar kan dessa ackumuleras. En sida som började korrekt kan bli subtilt fel efter tillräckligt många revisioner.

Vanliga missuppfattningar om LLM‑wikis

Även om LLM‑wiki är ett nytt koncept finns redan några missuppfattningar. Det här är vad de missar.

En LLM‑wiki ersätter RAG

Det gör den inte. De löser olika problem. RAG är för snabba uppslag mot en korpus som ofta ändras. En LLM‑wiki är för att bygga upp en kunskapsmassa över tid. Många verkliga system använder båda – RAG för färskhet mot råkällor, en wiki för sammanställd syntes ovanpå.

Det är bara ännu en vektordatabas

Vektordatabaser indexerar text för hämtning. En LLM‑wiki skriver text som har lästs, förståtts och omorganiserats av en modell. En vektordatabas ger tillbaka de fragment du lade in. En wiki ger tillbaka sidor som inte existerade innan du läste in källan. Utfallet är helt annorlunda.

Kunskapsbasen behöver aldrig uppdateras

Inte sant. Källor förändras, nya källor kommer till och modellen gör misstag som måste fångas. En wiki som inte underhålls blir inaktuell som all dokumentation. Skillnaden är att modellen sköter det mesta av underhållet, inte att underhåll försvinner.

Det gynnar bara AI‑agenter

Agenter är det tydligaste fallet eftersom de kör länge och gynnas mest av varaktigt minne, men människor har också nytta av wikis. Tänk en forskare som följer ett ämne eller en ingenjör som arbetar på en kodbas. Eller egentligen vem som helst som bygger upp en personlig kunskapsbas får samma ackumulerande syntes. 

Kommer LLM‑wikis att bli en ny AI‑arkitektur?

Det är för tidigt att säga, men den sannolika vägen är tydlig: beständig kunskap kommer inte att ersätta hämtnings‑först‑system, den kommer att samexistera med dem, där RAG hanterar liveuppslag och wikis hanterar sammanställd, långvarig kontext. De större öppna frågorna rör validering och skala — ingen har fullt ut löst hur man fångar modellfel som skrivits in i wikisidor, och ingen har stresstestat mönstret på mycket stora wikis ännu. MCP verkar passa naturligt för att exponera wikis för agenter, även om företagsadoption ligger längre fram med tanke på ökade krav på tillit.

Mönstret är inte etablerat än. Om det går vidare beror på om underhålls‑ och valideringsproblemen blir lösta. Fler frågor om detta besvaras i vanliga frågor nedan.

Slutsats

LLM‑wikin är en av de mer intressanta idéerna som kommit ur 2026 hittills, eftersom den ändrar vad ett AI‑system gör när du ger det en källa. I stället för att läsa samma dokument vid varje fråga läser modellen dem en gång och arkiverar dem i en kunskapsbas som bara blir bättre med tiden.

Konceptet är fortfarande under framväxt och de nuvarande implementationerna är tidiga, men idén är lovande och pekar mot något större. AI‑system rör sig från förbrukningskontext till beständig kunskap, och LLM‑wikis är ett av de första seriösa försöken att visa hur det faktiskt kan se ut i praktiken.

Om du vill hålla dig uppdaterad om nya utvecklingar men tycker att det är förvirrande, anmäl dig till vårt AI Fundamentals-spår. Du lär dig jargongen och kan använda AI effektivt i arbetet.