LLM Wiki-underhåll: Drift, motsägelsefullheter och granskning

En LLM-wiki misslycks när gamla fakta fortfarande verkar plausibla, motsägelser blir polerade och genererade sammanfattningar drar iväg från sina källor.

Underhåll är den verkliga produkten i varje sammanställt kunskapssystem. Det är enkelt att skapa wikisidor, men det är betydligt svårare att hålla dem trovärdiga över månader med inmatning, redigering, omskrivningar och nya källor.

Denna artikel behandlar den operativa sidan av LLM-wikisystem: driftupptäckt, kontroll av motsägelser, citeringsdisciplin, lintering, Git-granskning och underhållsarbetsflöden. Den utgår från att du redan förstår det grundläggande mönstret som beskrivs i LLM Wiki - Sammanställd kunskap som RAG inte kan ersätta: råa källor sammanställs i hållbara Markdown-sidor som människor och agenter kan fråga senare. Den lugna men bestämda synen är att en LLM-wiki utan underhåll bara är en snyggare utseende kunskapsgravrums.

Vad som gör LLM-wikunderhåll unikt

Traditionella wikis ruttnar eftersom människor slutar uppdatera dem. RAG-system drar iväg eftersom korpusen ändras, chunkar blir föråldrade, metadata är svag och hämtning fortsätter att hitta plausibla men föråldrade fragment. Den djupare anledningen är att hämtning och representation löser olika problem: hämtning kan köras mot färsk data, men en representation du redan har sammanställt måste aktivt hållas ärlig.

En LLM-wiki har ett annat misslyckandemönster. Den kan se ren ut även när den är felaktig.

Sidorna kan vara väl formaterade. Länkarna kan fungera. Sammanfattningarna kan låta balanserade. Men under den prydliga ytan kan systemet ha tappat viktiga fakta, slagit ihop inkompatibla koncept, citerat sammanfattningar istället för källor eller bevarat ett gammalt beslut som om det fortfarande gällde.

Det är därför LLM-wikunderhåll måste kontrollera både struktur och mening.

Målet med underhållet

Målet är inte att göra varje sida perfekt. Det är för dyrt och leder oftast till övergivna system.

Målet är att hålla wikin användbar, granskbar och återställbar.

En underhållen LLM-wiki bör göra det enkelt att besvara dessa frågor:

• Vilka källor stödjer detta påstående?
• När granskades denna sida senast?
• Har detta koncept ändrats?
• Finns det motsägande sidor?
• Är denna sammanfattning fortfarande aktuell?
• Skrev agenten om mer än den borde?
• Kan vi rulla tillbaka en dålig uppdatering?
• Kan en människa förstå varför sidan säger vad den säger?

Om svaret är nej, är problemet inte bara innehållskvaliteten. Det är systemdesignen.

En enkel underhållsslinga

En användbar LLM-wiki behöver en uppreplig slinga. Slingan bör vara enkel nog att köra ofta och strikt nog att fånga drift innan den blir osynlig.

Denna slinga är inte glamorös. Det är hela poängen.

Ett kunskapssystem blir hållbart genom tråkigt underhåll: källbevarande, explicit granskning, förutsägbar struktur och små säkra uppdateringar. Samma instinkt driver evergreen-notes: en anteckning eller en wikisida ökar bara i värde om någon fortsätter att förfinar den istället för att låta den ruttna efter första utkastet.

Typer av drift i en LLM-wiki

Kunskapsdrift är inte en ting. Olika typer av drift kräver olika kontroller. Ett bra underhållssystem bör namnge dem tydligt.

Källdrift

Källdrift inträffar när underliggande källmaterial ändras.

Till exempel släpper ett verktyg en ny version, en policy uppdateras, en API ändras eller en leverantör avvecklar en gammal funktion. Den gamla wikisidan kan fortfarande vara korrekt för den tidigare versionen, men felaktig för nuvarande användning.

Källdrift är farlig eftersom det gamla påståendet fortfarande kan vara sant i ett historiskt sammanhang. Problemet är inte att påståendet är falskt. Problemet är att det inte längre besvarar den aktuella frågan.

Underhållsrespons:

• Registrera källdatum
• Registrera senaste granskningsdatum
• Markera versionspecifika sidor tydligt
• Länka gamla sidor till ersättande sidor
• Undvik att bland gamla och nya versioner utan etiketter

Konceptdrift

Konceptdrift inträffar när betydelsen av en term ändras över tid.

Detta är vanligt inom AI och mjukvaruarkitektur. Termer som “agent”, “minne”, “RAG”, “arbetsflöde”, “verktygsanvändning”, “strukturerad output” och “kontextengineering” kan förändra betydelse snabbt.

En wiki kan oavsiktligt bevara flera betydelser av samma term utan att förklara skillnaden. Det skapar förvirrande sidor som låter sammanhängande men kombinerar inkompatibla idéer.

Underhållsrespons:

• Underhåll glosarysidor
• Lägg till avsnitt “betydelse i denna wiki”
• Separera överbelastade koncept i distinkta sidor
• Länka relaterade betydelser explicit
• Undvik att låta modellen tyst slå ihop termer

Terminologidrifting

Terminologidrifting är mindre än konceptdrift men ändå skadlig.

Det inträffar när wikin använder flera namn för samma sak: “LLM Wiki”, “sammanställd kunskapsbas”, “AI-underhållen wiki”, “agentunderhållen wiki” och “Markdown-kunskapsbas”.

Viss variation är okej. För mycket variation bryter sökning, länkning och granskning.

Underhållsrespons:

• Definiera kanoniska sidnamn
• Håll alias i frontmatter eller sidmetadata
• Omdirigera dubbletsidor
• Linta för nästan dubbletttitlar
• Använd konsekvent ankrings text i interna länkar

Beslutsdrift

Beslutsdrift inträffar när ett tidigare beslut förblir dokumenterat men inte längre speglar nuvarande praxis.

Till exempel kan en sida säga att projektet använder vektor-RAG för all dokumentsökning, medan nyare sidor beskriver ett LLM-wikiarbetsflöde. Båda påståendena kan vara historiskt sanna, men wikin måste visa vilket som är aktuellt.

Detta är viktigt för arkitekturanteckningar, ingenjörsprocesser, innehållsstrategi och intern verktyg. Samma disciplin gäller för beslutsregister i AI-driven utveckling: en beslutsida är endast trovärdig om ersatta val markeras som ersatta snarare än tyst skrivna över.

Underhållsrespons:

• Markera beslut som föreslagna, accepterade, ersatta eller avvisade
• Håll beslutsdatum
• Länka ersatta beslut till ersättningar
• Bevara historisk kontext
• Undvik att radera gamla beslut utan spår

Citeringsdrift

Citeringsdrift inträffar när en sida citerar en källa, men påståendet inte längre matchar vad källan säger.

Detta kan hända efter en omskrivning. Citeringen finns kvar på plats, men meningen runt den ändras. Sidan ser fortfarande källad ut, men citeringen stödjer inte längre påståendet.

Detta är en av de allvarligaste misslyckandemödrarna för LLM-wikis eftersom det skapar falsk tillit.

Underhållsrespons:

• Kontrollera citeringsstöd på påståendenivå
• Undvik att endast citera sammanfattningar
• Behåll råa källor
• Kräv källhänvisningar för viktiga påståenden
• Flagga stycken med källor men inget direkt stöd
• Granska citeringsändringar i Git-diffar

Strukturdrift

Strukturdrift inträffar när wikin långsamt förlorar navigerbarhet.

Nya sidor skapas istället för att uppdatera gamla. Indexsidor hänger efter. Dublett-sidor dyker upp. Vilda sidor ackumuleras. Relaterade sidor slutar länka till varandra.

Wikin innehåller fortfarande användbar kunskap, men det blir svårare att hitta och lita på den.

Underhållsrespons:

• Linta för vilda sidor
• Underhåll indexsidor
• Upptäck dubblettämnen
• Kräv baklänkar för kanoniska sidor
• Arkivera istället för att sprida
• Håll mapproller klara

Kernunderhållsfiler

En LLM-wiki bör inte förlita sig på minne, känslor eller upprepade prompter. Den behöver driftfiler som säger åt människor och agenter hur den ska underhållas.

En praktisk struktur kan se ut så här:

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

De exakta namnen spelar ingen roll. Rollerna gör det.

Wikin behöver källförvaring, komplicerade sidor, granskningsartefakter och regler som överlever mellan sessioner.

AGENTS.md

AGENTS.md bör förklara hur agenten får arbeta.

Den bör besvara frågor som:

• Bör agenten uppdatera befintliga sidor innan den skapar nya?
• När bör den be om granskning?
• Hur bör den citera källor?
• Kan den organisera om mappar?
• Kan den skriva om gamla sidor?
• Vad bör den göra med motsägelser?
• Vad bör den aldrig radera?

En användbar regel är:

Föredra små, källbackade uppdateringar framför breda omskrivningar.

Den meningen förhindrar många dåliga underhållsvanor. Den drar också en användbar gräns i förhållande till agentminne: minnet formar hur en agent beter sig i ögonblicket, medan wikins regelfil formar vad agenten får ändra i den delade kunskapsbasen.

schema.md

schema.md bör definiera sidstrukturen.

Till exempel:

# Sidtitel

## Sammanfattning
Kort aktuell sammanfattning.

## Viktiga påståenden
- Påstående med källreferens.
- Påstående med källreferens.

## Aktuell status
Aktuell, historisk, ersatt, utkast eller osäker.

## Detaljer
Huvudsaklig sammanställd förklaring.

## Relaterade sidor
Interna länkar.

## Källor
Råa källreferenser.

## Granskningsanteckningar
Senast granskat datum och granskare.

Ett schema behöver inte vara styvt. Men utan ett schema blir wikin en hög med inkonsistenta essäer. Schemat ger agenten något att bevara.

citation-policy.md

Citeringspolicyn bör säga vad som kräver en källa. Kräv som minimum källhänvisningar för:

• Tekniska påståenden
• Jämförelser
• Produktbeteende
• Versionspecifik påståenden
• Benchmarkresultat
• Prissättning
• Juridiska eller compliance-påståenden
• Påståenden om aktuell status
• Påståenden kopierade eller härledda från en källa

En bra citeringspolicy säger också vad man inte ska göra. Citera inte en sammanställd sida som om den vore den ursprungliga källan. Fäst inte citeringar till stycken de inte stödjer. Behåll inte en citering efter att ha skrivit om ett påstående om inte källan fortfarande stödjer det.

Citeringsdisciplin är skillnaden mellan en användbar LLM-wiki och dekorativ tillit.

source-policy.md

Källpolicyn bör definiera hur råa källor lagras.

Till exempel:

• Behåll originalfiler när möjligt
• Bevara URL:er och åtkomstdatum
• Lagra kopierade anteckningar separat från genererade sammanfattningar
• Registrera källtyp
• Markera källor med låg tillit
• Undvik att skriva över råmaterial
• Behåll ersatta källor när de förklarar historiska beslut

Denna policy skyddar wikin från ett vanligt misstag: sammanfatta en källa, kasta bort originalet och behandla sedan sammanfattningen som bevis.

Det är inte kunskapsförvaltning. Det är förlustkompression.

Vad en LLM-wikilinter bör kontrollera

En linter bör kontrollera struktur först. Strukturmässiga problem är lättare att automatisera och avslöjar ofta djupare semantiska problem.

Användbara strukturella kontroller inkluderar:

• Trasiga interna länkar
• Vilda sidor
• Dubbeltitlar
• Saknade källavsnitt
• Saknade granskningsdatum
• Sidor utan baklänkar
• Tomma eller platshållaravsnitt
• Mycket långa sidor utan avsnittsstruktur
• Sidor utan inkommande länkar från ett index
• Inkonsistenta namngivningskonventioner
• Ogiltig frontmatter
• “Aktuella” sidor som är äldre än en gränströskel för granskning

Dessa kontroller bevisar inte att kunskapen är sann. De bevisar att wikin fortfarande är underhållbar. Det är en nödvändig utgångspunkt.

Semantiska kontroller

Semantiska kontroller är svårare men mer värdefulla.

Användbara semantiska kontroller inkluderar:

• Påståenden utan direkt källstöd
• Två sidor som gör inkompatibla påståenden
• Gamla beslut presenterade som aktuella
• Dubbeltkoncept med olika namn
• En konceptsid som blandar flera betydelser
• Sammanfattningar som utelämnar kända begränsningar
• Påståenden om “bäst” eller “rekommenderat” utan kriterier
• Versionspecifik påståenden utan versionsetiketter
• Sidor som motsäger nyare källor

Dessa kontroller bör inte automatiskt skriva om wikin. De bör vanligtvis producera en rapport för granskning.

Det säkrare mönstret är:

Upptäck automatiskt.
Förklara tydligt.
Uppdatera medvetet.
Granska riskfyllda ändringar.

Motsägelseupptäckt

Motsägelseupptäckt är inte bara att fråga en LLM om två sidor motsäger varandra.

Det kan hjälpa, men det är för vagt. Ett bättre tillvägagångssätt är att jämföra påståenden.

Ett arbetsflöde för motsägelser kan se ut så här:

Detta fungerar bättre eftersom många skenbara motsägelser inte är verkliga motsägelser.

En sida kan beskriva version 1.0 och en annan version 2.0. En sida kan beskriva personlig användning och en annan företagsanvändning. En sida kan beskriva designmålet och en annan implementeringsverkligheten.

Motsägelse-rapporten bör inkludera:

• Motsägande påståenden
• Inblandade sidor
• Källreferenser
• Datum- eller versionkontext
• Trolig förklaring
• Föreslagen lösning
• Om mänsklig granskning krävs

Låt inte agenten tyst lösa motsägelser genom att blanda båda påståendena till ett vagt kompromiss. Det skapar slät nonsens.

Hur man löser motsägelser

Det finns flera giltiga sätt att lösa en motsägelse.

• Om ett påstående är föråldrat, markera det som ersatt och länka till den nyare sidan.
• Om båda påståendena är sanna i olika sammanhang, dela upp kontexten tydligt.
• Om källorna oeniga, bevara oenigheten och förklara den.
• Om wikisidan uppfunnit eller övergeneraliserat ett påstående, ta bort eller begränsa påståendet.
• Om motsägelsen speglar ett verkligt olöst beslut, skapa eller uppdatera en beslutsida.

Målet är inte att ta bort all spänning. Viss spänning är användbar. En bra wiki visar var kunskapen är avgjord och var den fortfarande är osäker.

Granskning av föråldrade sidor

Varje sammanställd sida bör ha en granskningsstatus.

En enkel metadata-block kan vara tillräcklig:

status: current
last_reviewed: 2026-07-10
review_after: 2026-10-10
source_confidence: medium

För snabbt rörliga ämnen, använd korta granskningsfönster. För stabila koncept, använd längre fönster.

Intervall är mindre viktigt än vanan. En sida utan granskningsdatum är en sida som till slut kommer att ljuga tyst.

Källmedvetna uppdateringar

När en ny källa kommer, bör agenten inte bara skriva en ny sammanfattningssida.

Den bör fråga:

• Uppdaterar detta ett befintligt koncept?
• Ersätter det en tidigare källa?
• Motsäger det en befintlig sida?
• Lägger det till en ny entitet eller term?
• Ändrar det en rekommendation?
• Kräver det en indexuppdatering?
• Påverkar den beslutsidor?

Ett bra inmatningsarbetsflöde uppdaterar wikin som en graf, inte som en hög med isolerade sammanfattningar.

Det är därför en källa kan röra vid många sidor. Det är normalt. Underhållsutmaningen är att göra dessa uppdateringar små, granskbara och spårbara.

Granskning med Git-diffar

Git är ett av de bästa underhållsverktygen för en LLM-wiki.

Inte för att Git är modernt, utan för att genererad kunskap behöver granskbar ändringshistorik. En Git-diff visar vad agenten ändrade, raderade, flyttade eller omformulerade.

Använd Git för att granska:

• Nya sidor
• Raderade avsnitt
• Ändrade påståenden
• Ändrade citeringar
• Omdöpta sidor
• Indexuppdateringar
• Länkändringar
• Statusändringar
• Breda omskrivningar

Den viktigaste granskingsvanan är att inspektera raderingar. LLM:er tar ofta bort detaljer medan de gör prosan renare.

Ren prosa är inte alltid bättre kunskap.

Säker commit-strategi

Undvik jättelika commits som:

Uppdatera wiki

Använd commits som förklarar operationen:

ingest: lägg till källanteckningar för Qwen embedding-släpp
maint: markera gammal vektorlagringsjämförelse som ersatt
lint: fixa trasiga interna länkar i RAG-sidor
review: uppdatera LLM Wiki-sidciteringar
refactor: dela upp agentminnekoncept från långtidsminne

Detta ger framtida människor och agenter en användbar historik.

Commit-meddelanden är en del av kunskapssystemet. De förklarar varför wikin ändrades.

Granskningsnivåer

Inte varje sida behöver samma granskningsnivå. Använd riskbaserad granskning.

Låg-risk-ändringar:

• Fixa trasiga länkar
• Formateringsstädning
• Lägg till baklänkar
• Lägg till indexposter
• Korrigera stavfel
• Lägg till alias

Medel-risk-ändringar:

• Lägg till källsammanfattningar
• Skapa nya konceptsidor
• Uppdatera rekommendationer
• Slå ihop dublett-sidor
• Ändra sidstatus

Hög-risk-ändringar:

• Radera påståenden
• Skriva om kanoniska sidor
• Ändra beslutsregister
• Uppdatera säkerhets-, juridiska-, prissättnings- eller benchmark-påståenden
• Lösa motsägelser
• Markera innehåll som aktuellt eller ersatt

Hög-risk-ändringar bör få mänsklig granskning. Det kan vara du, en underhållare eller en ägare för domänen.

Agenten kan förbereda ändringen, men den bör inte alltid vara den slutliga auktoriteten.

Ett underhållsdashboard

Ett enkelt underhållsdashboard kan leva i Markdown.

Exempel:

# LLM Wiki Underhållsdashboard

## Behöver granskning
- wiki/concepts/agent-memory.md - granskning fördröjd
- wiki/projects/search-index.md - motsägande påståenden hittade

## Föråldrade sidor
- wiki/tools/ollama.md - senast granskad för 120 dagar sedan
- wiki/concepts/rag.md - snabbt rörligt ämne, granskning förfallen

## Trasiga länkar
- wiki/index.md -> wiki/concepts/old-page.md

## Vilda sidor
- wiki/entities/vendor-x.md

## Motsägelse-rapporter
- reports/contradictions/2026-07-10-agent-memory.md

## Nyligen inmatade
- raw/sources/2026-07-09-new-paper.md

Detta är inte en fancy admin-panel. Det är en arbetsyta.

För många solo- eller småteamsystem räcker ett Markdown-dashboard.

Mätningar för en frisk LLM-wiki

Du kan spåra wikins hälsa utan att överingenjörera den.

Användbara mätningar inkluderar:

• Antal sidor
• Sidor utan källor
• Sidor utan granskningsdatum
• Sidor efter granskningsdatum
• Trasiga interna länkar
• Vilda sidor
• Dubbeltitlar eller alias
• Öppna motsägelse-rapporter
• Lösta motsägelse-rapporter
• Genomsnittlig sidålder per kluster
• Råa källor som inte ännu inmatats
• Sidor ändrade utan mänsklig granskning
• Kanoniska sidor ändrade de senaste 30 dagarna

Dessa mätningar är inte vanitetsnummer. De säger dig om systemet blir lättare eller svårare att lita på.

En växande wiki med ökande vilda sidor och föråldrade granskningar komprimerar inte kunskap. Den komprimerar underhållsskuld.

Underhållsprompter

Underhållsprompter bör vara smala. Bredda prompter producerar breda omskrivningar.

Strukturlint-prompt

Granska wikistrukturen.

Kontrollera för:
- trasiga interna länkar
- vilda sidor
- dubbelt eller nästan dubbelt sidtitlar
- sidor som saknar källavsnitt
- sidor som saknar last_reviewed metadata
- indexsidor som inte länkar till nya sidor

Skriv inte om innehåll.
Producera en Markdown-rapport med fynd och föreslagna fix.

Citeringsgranskningsprompt

Granska citeringar för den valda sidan.

För varje viktigt påstående:
- identifiera den stödjande källan
- kontrollera om källan direkt stödjer påståendet
- flagga påståenden med svagt, saknat eller felmatchat stöd
- skriv inte om sidan än

Returnera en tabell med:
påstående, aktuell citering, stödnivå, problem, föreslagen åtgärd.

Motsägelsekontrollprompt

Kontrollera denna sida för motsägelser mot relaterade sidor.

Steg:
1. Extrahera huvudpåståendena från sidan.
2. Hitta relaterade sidor genom länkar, baklänkar, alias och sökning.
3. Extrahera potentiellt motsägande påståenden.
4. Klassificera varje konflikt som:
   - verklig motsägelse
   - versionskillnad
   - räckviddsskillnad
   - terminologisk skillnad
   - olöst osäkerhet
5. Rekommendera en lösning.

Redigera inte filer förrän motsägelse-rapporten har granskats.

Granskningsprompt för föråldrade sidor

Granska denna sida för föråldring.

Kontrollera:
- datum
- versionspecifik påståenden
- verktygsbeteende
- rekommendationer
- länkar till ersatta sidor
- källor nyare än sidans granskningsdatum
- påståenden markerade som aktuella utan nyligen stöd

Returnera:
- behåll aktuell
- uppdatering behövs
- markera som historisk
- markera som ersatt
- dela upp i versionsmärkta sidor

Säker uppdateringsprompt

Uppdatera den valda wikisidan med den tillhandahållna källan.

Regler:
- bevara befintlig användbar struktur
- ta inte bort källbackade påståenden om inte källan är ersatt
- lägg till citeringar för nya påståenden
- markera osäkerhet explicit
- uppdatera relaterade sidor endast när nödvändigt
- lägg till en granskningsanteckning som förklarar vad som ändrades
- håll diffen liten

Dessa prompter är inte magi. De är skyddsräcken. Det verkliga värdet kommer från att göra underhållsåtgärden explicit.

Vanliga underhållsmistag

Det första misstaget är att låta agenten skriva om för mycket.

Stora omskrivningar känns produktiva eftersom de gör sidor smidigare. De gör det också svårare att se vad som ändrades och lättare att förlora vassa detaljer.

Det andra misstaget är att behandla genererade sammanfattningar som källor.

En sammanfattning kan vara användbar, men den är inte beviset. Behåll råa källor och citera dem när påståenden är viktiga.

Det tredje misstaget är att skapa nya sidor istället för att uppdatera gamla.

Detta producerar dubbeltkoncept, motsägande rekommendationer och sökförvirring. Agenten bör söka först, uppdatera andra och skapa nya sidor endast när konceptet är genuint nytt.

Det fjärde misstaget är att radera historisk kontext.

Gamla beslut, misslyckade experiment och ersatta rekommendationer kan vara värdefulla. Markera dem tydligt istället för att radera dem.

Det femte misstaget är att glömma index.

En sida som inte är länkad från rätt plats är halvförlorad. Indexunderhåll är inte skriftligt arbete. Det är navigationsarkitektur.

Det sjätte misstaget är att använda samma granskningspolicy för varje sida.

En stabil konceptsid och en snabbt rörlig verktygsjämförelse bör inte ha samma granskningschema.

Arkivera, ersätt eller radera

De flesta föråldrade sidor bör inte raderas omedelbart.

En ersatt sida bör länka till ersättningen.

Till exempel:

Status: ersatt
Ersatt av: wiki/concepts/agent-memory-architecture.md
Anledning: Denna sida använde en äldre definition av agentminne innan projektet separerade sessionsminne, användarminne och sammanställd kunskap.

Detta bevarar kontext och minskar förvirring.

Radering bör vara sällsynt och granskbar. Kunskapssystem behöver beskärning, men osynlig beskärning är farlig.

Kanoniska sidor behöver extra omsorg

Varje LLM-wiki utvecklar till slut kanoniska sidor.

Detta är sidor som definierar kärnkoncept, arkitekturval, arbetsflöden eller projektvokabulär. De är viktigare än vanliga anteckningar eftersom många andra sidor beror på dem.

Exempel:

• Vad är LLM Wiki
• RAG vs sammanställd kunskap
• Agentminne
• Källpolicy
• Granskningsarbetsflöde
• Projektarkitektur
• Glosary
• Index

Ändringar i kanoniska sidor bör kräva striktare granskning.

Ett litet fel på en obskyra sida är lokalt. Ett litet fel på en kanonisk sida kan förvränga hela wikin.

Hur ofta bör du köra underhåll

För en aktiv LLM-wiki, kör litet underhåll ofta och djupt underhåll ibland.

Schema bör matcha risk. En personlig forskningswiki kan vara lättare. En wiki använd för teknisk publicering, kundsupport eller ingenjörsbeslut behöver mer disciplin.

Använda en LLM-wiki för teknisk publicering

För en teknisk blog eller dokumentationssida kan LLM-wikis bli kunskapslagret bakom artikelplanering.

Den kan spåra:

• Kanoniska förklaringar
• Upprepade definitioner
• Möjligheter för interna länkar
• Föråldrade jämförelser
• Artikelmål
• Ämneskluster
• Källanteckningar
• Beslut om struktur
• Påståenden som behöver verifiering

Detta är användbart, men det höjer underhållsstaven.

Om wikin matar publicerade artiklar, kan föråldrade wikisidor bli föråldrat offentligt innehåll. Om wikin innehåller motsägelser, kan dessa motsägelser läcka in i artiklar. Om citeringar är svaga, kommer genererade utkast att ärva den svagheten. De avgränsade sammanfattningarna, schema-baserade extraktion och mänskliga granskningslooper som beskrivs i AI för kunskapsförvaltning: Verkliga arbetsflöden som håller är en bra mall för att hålla den redaktionella pipeline ärlig.

För publiceringsarbetsflöden, behandla LLM-wikis som ett redaktionellt system, inte bara ett privat anteckningsblock. En digital trädgård gör detta explicit genom att visa läsare vilka sidor som fortfarande växer och vilka som är mogna, vilket är exakt den typ av statusignal en välunderhållen LLM-wiki också bör exponera.

Underhåll är inte valfritt

En LLM-wiki är attraktiv eftersom den lovar komprimerande kunskap.

Men komprimering fungerar bara om gammal kunskap förblir användbar. Annars komprimerar systemet brus, inte insikt.

Underhållsbördan försvinner inte för att en agent är inblandad. Den ändrar form.

Människor behöver inte göra varje tråkiga uppgift. Agenter kan kontrollera länkar, hitta föråldrade sidor, jämföra påståenden, utkasta rapporter och föreslå uppdateringar. Men människor behöver fortfarande sätta policy, granska riskfyllda ändringar och besluta vad wikin får betyda.

Det är den verkliga affären.

Slutsats

LLM-wikunderhåll handlar om att hålla sammanställd kunskap ärlig.

De viktiga prakticerna är inte komplicerade: bevara källor, citera påståenden, håll index aktuella, upptäck motsägelser, granska Git-diffar, markera föråldrade sidor och undvik breda ogranskade omskrivningar.

En bra LLM-wiki påstår inte att vara magiskt självkorrigerande. Den gör korrigering lättare.

Det är standarden värd att sikta på: inte perfekt kunskap, utan granskbar kunskap som kan granskas, repareras och litas på över tid.