LLM Wiki-onderhoud: Drift, tegenstrijdigheden en evaluatie

Een LLM Wiki faalt wanneer oude feiten aannemelijk blijven, tegenstrijdigheden worden gepolijst en gegenereerde samenvattingen afwijken van hun bronnen.

Onderhoud is het echte product van elk gesystematiseerd kennissysteem. Het aanmaken van wiki-pagina’s is eenvoudig vergeleken met het betrouwbaar houden ervan over maanden van opname, bewerkingen, herschrijvingen en nieuwe bronnen heen.

Dit artikel behandelt de operationele kant van LLM Wiki-systemen: drift-detectie, controle op tegenstrijdigheden, citatiestrategie, linting, Git-review en onderhoudswerkstromen. Het gaat ervan uit dat je al bekend bent met het basispatroon zoals beschreven in LLM Wiki - Gesystematiseerde kennis die RAG niet kan vervangen: ruwe bronnen worden samengevoegd tot duurzame Markdown-pagina’s die later door mensen en agents kunnen worden opgevraagd. Het kalm maar standvastige standpunt is dat een LLM Wiki zonder onderhoud slechts een mooier ogende kennisbegraafplaats is.

Wat LLM Wiki-onderhoud anders maakt

Traditionele wikis vervallen omdat mensen stoppen met updaten. RAG-systemen vertonen drift omdat de corpus verandert, chunks verouderd raken, metadata zwak is en ophaling blijft zoeken naar aannemelijke maar verouderde fragmenten. De dieperliggende reden is dat ophaling en representatie verschillende problemen oplossen: ophaling kan opnieuw worden uitgevoerd tegen verse data, maar een representatie die je al hebt samengesteld, moet actief eerlijk worden gehouden.

Een LLM Wiki heeft een ander falingspatroon. Het kan er schoon uitzien, zelfs wanneer het fout is.

De pagina’s kunnen goed opgemaakt zijn. De links kunnen werken. De samenvattingen kunnen gebalanceerd klinken. Maar onder dat nette oppervlak kan het systeem cruciale feiten hebben laten vallen, incompatibele concepten hebben samengevoegd, samenvattingen hebben geciteerd in plaats van bronnen, of een oud besluit hebben behouden alsof het nog steeds van toepassing is.

Daarom moet LLM Wiki-onderhoud zowel structuur als betekenis controleren.

Het doel van onderhoud

Het doel is niet om elke pagina perfect te maken. Dat is te duur, en het leidt meestal tot verlaten systemen.

Het doel is om de wiki nuttig, inspecteerbaar en herstelbaar te houden.

Een onderhouden LLM Wiki moet het eenvoudig maken om deze vragen te beantwoorden:

• Welke bronnen ondersteunen deze bewering?
• Wanneer is deze pagina voor het laatst gereviewd?
• Is dit concept veranderd?
• Zijn er tegenstrijdige pagina’s?
• Is deze samenvatting nog actueel?
• Heeft de agent meer herschreven dan nodig was?
• Kunnen we een slechte update teruggaan?
• Kan een mens begrijpen waarom de pagina zegt wat het zegt?

Als het antwoord nee is, ligt het probleem niet alleen in de inhoudskwaliteit. Het is een systeemontwerp.

Een eenvoudige onderhoudsloop

Een nuttige LLM Wiki heeft een herhaalbare loop nodig. De loop moet eenvoudig genoeg zijn om vaak te worden uitgevoerd en streng genoeg om drift op te vangen voordat hij onzichtbaar wordt.

Deze loop is niet glansrijk. Dat is het punt.

Een kennissysteem wordt duurzaam door saai onderhoud: bronbehoud, expliciete review, voorspelbare structuur en kleine, veilige updates. Dezelfde intuïtie drijft evergreen notes: een nota of een wiki-pagina wint alleen aan waarde als iemand het blijft verfijnen in plaats van het te laten vervallen na de eerste conceptversie.

Types van drift in een LLM Wiki

Kennisdraft is niet één ding. Verschillende drifttypes vereisen verschillende controles. Een goed onderhoudssysteem moet ze duidelijk benoemen.

Bron-drift

Bron-drift treedt op wanneer de onderliggende bronaanvoer verandert.

Bijvoorbeeld: een tool brengt een nieuwe versie uit, een beleid wordt bijgewerkt, een API verandert, of een leverancier stopt met ondersteuning van een oude functie. De oude wiki-pagina kan nog steeds accuraat zijn voor de vorige versie, maar fout voor het huidige gebruik.

Bron-drift is gevaarlijk omdat de oude bewering in historische context nog steeds waar kan zijn. Het probleem is niet dat de bewering vals is. Het probleem is dat deze niet langer het huidige vraagstuk beantwoordt.

Onderhoudsreactie:

• Brondata registreren
• Laatst gereviewde data registreren
• Versiespecifieke pagina’s duidelijk markeren
• Oude pagina’s linken naar vervangende pagina’s
• Vermijd het mengen van oude en nieuwe versies zonder labels

Concept-drift

Concept-drift treedt op wanneer de betekenis van een term over tijd verandert.

Dit komt veel voor in AI en softwarearchitectuur. Terms zoals “agent”, “geheugen”, “RAG”, “workflow”, “gebruik van tools”, “gestructureerde output” en “context-engineering” kunnen snel van betekenis veranderen.

Een wiki kan per ongeluk meerdere betekenissen van dezelfde term behouden zonder het verschil uit te leggen. Dit creëert verwarrende pagina’s die coherent klinken maar incompatibele ideeën combineren.

Onderhoudsreactie:

• Woordenboekpagina’s onderhouden
• “Betekenis in deze wiki”-secties toevoegen
• Overbelaste concepten scheiden in afzonderlijke pagina’s
• Gerelateerde betekenissen expliciet linken
• Voorkom dat het model termen stilzwijgend samenvoegt

Terminologie-drift

Terminologie-drift is kleiner dan concept-drift, maar toch schadelijk.

Het gebeurt wanneer de wiki meerdere namen gebruikt voor hetzelfde ding: “LLM Wiki”, “gesystematiseerde kennisbank”, “AI-onderhouden wiki”, “agent-onderhouden wiki” en “Markdown-kennisbank”.

Enige variatie is prima. Te veel variatie breekt zoekopdrachten, koppelingen en reviews.

Onderhoudsreactie:

• Canonieke paginanamen definiëren
• Aliassen in front matter of paginametadata houden
• Dubbele pagina’s omleiden
• Lint uitvoeren op bijna-dubbele titels
• Gebruik consistente ankertekst in interne links

Beslissing-drift

Beslissing-drift treedt op wanneer een vroeg besluit gedocumenteerd blijft maar niet langer de huidige praktijk weerspiegelt.

Bijvoorbeeld: een pagina kan zeggen dat het project vector-RAG gebruikt voor alle documentzoeken, terwijl nieuwere pagina’s een LLM Wiki-workflow beschrijven. Beide statements kunnen historisch waar zijn, maar de wiki moet aangeven welke van toepassing is.

Dit is belangrijk voor architectuurnota’s, engineeringprocessen, contentstrategie en interne tooling. Dezelfde discipline is van toepassing op beslisregistraties in AI-gedreven ontwikkeling: een beslispagina is alleen betrouwbaar als vervangen keuzen als vervangen zijn gemarkeerd in plaats van stilzwijgend overschreven.

Onderhoudsreactie:

• Beslissingen markeren als voorgesteld, geaccepteerd, vervangen of afgewezen
• Beslissingsdata bijhouden
• Vervangen beslissingen linken naar vervangers
• Historische context behouden
• Voorkom het verwijderen van oude beslissingen zonder spoor

Citatie-drift

Citatie-drift treedt op wanneer een pagina een bron citeert, maar de bewering niet langer overeenkomt met wat de bron zegt.

Dit kan gebeuren na een herschrijving. De citatie blijft op zijn plaats, maar de zin eromheen verandert. De pagina ziet er nog steeds gegronde uit, maar de citatie ondersteunt de bewering niet langer.

Dit is een van de ernstigste LLM Wiki-falingsmodi omdat het valse vertrouwen creëert.

Onderhoudsreactie:

• Controleer citatieondersteuning op beweringsniveau
• Vermijd het citeren van alleen samenvattingen
• Behoud ruwe bronnen
• Vereis citaties voor belangrijke beweringen
• Markeer alinea’s met bronnen maar zonder directe ondersteuning
• Review citatiewijzigingen in Git-diffs

Structuur-drift

Structuur-drift treedt op wanneer de wiki langzaam aan navigeerbaarheid verliest.

Er worden nieuwe pagina’s gemaakt in plaats van oude bij te werken. Indexpagina’s hinken achter. Dubbele pagina’s verschijnen. Weespagina’s accumuleren. Gerelateerde pagina’s stoppen met elkaar te linken.

De wiki bevat nog steeds nuttige kennis, maar het vinden en vertrouwen ervan wordt moeilijker.

Onderhoudsreactie:

• Lint uitvoeren op weespagina’s
• Indexpagina’s onderhouden
• Dubbele onderwerpen detecteren
• Vereis backlinks voor canonieke pagina’s
• Archiveren in plaats van verspreiden
• Houd maprollen duidelijk

De kernbestand van onderhoud

Een LLM Wiki mag niet vertrouwen op geheugen, vibes of herhaaldelijke prompting. Het heeft bestanden nodig die mensen en agents vertellen hoe ze het moeten onderhouden.

Een praktische structuur kan er zo uitzien:

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 exacte namen zijn niet belangrijk. De rollen wel.

De wiki heeft opslag voor bronnen, gecompileerde pagina’s, reviewartefacten en regels nodig die over sessies heen overleven.

AGENTS.md

AGENTS.md moet uitleggen hoe de agent mag werken.

Het moet vragen beantwoorden zoals:

• Moet de agent bestaande pagina’s bijwerken voordat deze nieuwe maakt?
• Wanneer moet het om review vragen?
• Hoe moet het bronnen citeren?
• Kan het mappen herstructureren?
• Kan het oude pagina’s herschrijven?
• Wat moet het doen met tegenstrijdigheden?
• Wat moet het nooit verwijderen?

Een nuttige regel is:

Geef voorrang aan kleine, bron-ondersteunde updates boven brede herschrijvingen.

Die ene zin voorkomt vele slechte onderhoudsgewoontes. Het trekt ook een nuttige grens ten opzichte van agent geheugen: geheugen beïnvloedt hoe een agent zich op dat moment gedraagt, terwijl het regelsbestand van de wiki bepaalt wat de agent mag veranderen in de gedeelde kennisbank.

schema.md

schema.md moet de paginastuctuur definiëren.

Bijvoorbeeld:

# Paginatitel

## Samenvatting
Korte, actuele samenvatting.

## Kernbeweringen
- Bewering met bronverwijzing.
- Bewering met bronverwijzing.

## Huidige status
Actueel, historisch, vervangen, concept of onzeker.

## Details
Hoofdcompiled uitleg.

## Gerelateerde pagina's
Interne links.

## Bronnen
Ruwe bronverwijzingen.

## Reviewnotities
Laatst gereviewde datum en reviewer.

Een schema hoeft niet rigide te zijn. Maar zonder schema wordt de wiki een hoop inconsistent essays. Het schema geeft de agent iets om te behouden.

citation-policy.md

Het citatiebeleid moet zeggen wat een bron vereist. Vereis ten minste citaties voor:

• Technische beweringen
• Vergelijkingen
• Productgedrag
• Versiespecifieke statements
• Benchmarkresultaten
• Prijzen
• Juridische of compliance-beweringen
• Huidige status-beweringen
• Beweringen die zijn gekopieerd of afgeleid van een bron

Een goed citatiebeleid zegt ook wat je niet moet doen. Citeer geen gecompileerde pagina alsof het de oorspronkelijke bron is. Hecht geen citaties aan alinea’s die ze niet ondersteunen. Behoud geen citatie na het herschrijven van een bewering tenzij de bron deze nog steeds ondersteunt.

Citatiestrategie is het verschil tussen een nuttige LLM Wiki en decoratief vertrouwen.

source-policy.md

Het bronbeleid moet definiëren hoe ruwe bronnen worden opgeslagen.

Bijvoorbeeld:

• Behoud originele bestanden indien mogelijk
• Behoud URLs en toegangsdata
• Sla gekopieerde notities apart op van gegenereerde samenvattingen
• Registreer brontype
• Markeer bronnen met lage betrouwbaarheid
• Voorkom het overschrijven van ruw materiaal
• Behoud vervangen bronnen wanneer ze historische beslissingen verklaren

Dit beleid beschermt de wiki tegen een veelgemaakte fout: het samenvatten van een bron, het weggooiden van het origineel en het behandelen van de samenvatting als bewijs.

Dat is geen kennismanagement. Dat is lossy compressie.

Wat een LLM Wiki Linter moet controleren

Een linter moet eerst structuur controleren. Structurele problemen zijn gemakkelijker te automatiseren en onthullen vaak dieperliggende semantische problemen.

Nuttige structurele controles omvatten:

• Gebroken interne links
• Weespagina’s
• Dubbele titels
• Ontbrekende bronssecties
• Ontbrekende reviewdata
• Pagina’s zonder backlinks
• Lege of placeholder-secties
• Zeer lange pagina’s zonder sectiestructuur
• Pagina’s zonder inkomende links van een index
• Inconsistenten in naamgevingsconventies
• Ongeldige front matter
• Verouderde “actuele” pagina’s ouder dan een reviewdrempel

Deze controles bewijzen niet dat de kennis waar is. Ze bewijzen dat de wiki nog steeds onderhoudbaar is. Dat is een noodzakelijk startpunt.

Semantische controles

Semantische controles zijn moeilijker maar waardevoller.

Nuttige semantische controles omvatten:

• Beweringen zonder directe bronondersteuning
• Twee pagina’s die incompatibele beweringen doen
• Oude beslissingen gepresenteerd als actueel
• Dubbele concepten met verschillende namen
• Een conceptpagina die meerdere betekenissen mengt
• Samenvattingen die bekende beperkingen weglaten
• “Beste” of “aanbevolen” beweringen zonder criteria
• Versiespecifieke beweringen zonder versielabels
• Pagina’s die in tegenspraak zijn met nieuwere bronnen

Deze controles mogen de wiki niet automatisch herschrijven. Ze moeten meestal een rapport voor review produceren.

Het veiligere patroon is:

Detecteer automatisch.
Leg duidelijk uit.
Update bewust.
Review risicovolle wijzigingen.

Detectie van tegenstrijdigheden

Detectie van tegenstrijdigheden is niet zomaar een vraag aan een LLM of twee pagina’s tegen elkaar ingaan.

Dat kan helpen, maar het is te vaag. Een betere aanpak is het vergelijken van beweringen.

Een werkwijze voor tegenstrijdigheden kan er zo uitzien:

Dit werkt beter omdat veel schijnbare tegenstrijdigheden geen echte tegenstrijdigheden zijn.

Een pagina kan versie 1.0 beschrijven en een andere versie 2.0. Een pagina kan persoonlijk gebruik beschrijven en een andere zakelijk gebruik. Een pagina kan het ontwerpdoel beschrijven en een andere de implementatierrealiteit.

Het tegenstrijdighedsrapport moet bevatten:

• Tegenstrijdige beweringen
• Betrokken pagina’s
• Bronverwijzingen
• Datum- of versiecontext
• Waarschijnlijke verklaring
• Voorgestelde oplossing
• Of menselijke review vereist is

Laat de agent niet stilzwijgend tegenstrijdigheden oplossen door beide beweringen te mengen in een vaag compromis. Dat creëert glad nonsens.

Hoe tegenstrijdigheden op te lossen

Er zijn verschillende geldige manieren om een tegenstrijdigheid op te lossen.

• Als een bewering verouderd is, markeer deze als vervangen en link naar de nieuwere pagina.
• Als beide beweringen waar zijn in verschillende contexten, splits de context duidelijk.
• Als de bronnen het oneens zijn, behoud het oneens zijn en leg het uit.
• Als de wiki-pagina een bewering heeft verzonnen of te algemeen heeft gemaakt, verwijder of verklein de bewering.
• Als de tegenstrijdigheid een echt onopgelost besluit weerspiegelt, maak of update een beslispagina.

Het doel is niet om alle spanning te verwijderen. Enige spanning is nuttig. Een goede wiki toont waar kennis is vastgesteld en waar het nog onzeker is.

Review van verouderde pagina’s

Elke gecompileerde pagina moet een reviewstatus hebben.

Een eenvoudig metadata-blok kan genoeg zijn:

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

Gebruik korte reviewvensters voor snel veranderende onderwerpen. Gebruik langere vensters voor stabiele concepten.

Het interval is minder belangrijk dan de gewoonte. Een pagina zonder reviewdatum is een pagina die uiteindelijk stilzwijgend zal liegen.

Bronbewuste updates

Wanneer een nieuwe bron aankomt, mag de agent niet zomaar een nieuwe samenvattingspagina schrijven.

Het moet vragen:

• Update dit een bestaand concept?
• Vervangt het een eerdere bron?
• Is het in tegenspraak met een bestaande pagina?
• Voegt het een nieuwe entiteit of term toe?
• Verandert het een aanbeveling?
• Vereist het een indexupdate?
• Beïnvloedt het beslispagina’s?

Een goede ingestie-workflow update de wiki als een grafiek, niet als een stapel geïsoleerde samenvattingen.

Daarom kan één bron veel pagina’s raken. Dat is normaal. De uitdaging van onderhoud is het klein, reviewbaar en traceerbaar maken van die updates.

Review met Git Diffs

Git is een van de beste onderhoudsinstrumenten voor een LLM Wiki.

Niet omdat Git hip is, maar omdat gegenereerde kennis een reviewbare veranderingsgeschiedenis nodig heeft. Een Git diff toont wat de agent heeft gewijzigd, verwijderd, verplaatst of herdacht.

Gebruik Git om te reviewen:

• Nieuwe pagina’s
• Verwijderde secties
• Gewijzigde beweringen
• Gewijzigde citaties
• Hernoemde pagina’s
• Indexupdates
• Linkwijzigingen
• Statuswijzigingen
• Brede herschrijvingen

De belangrijkste reviewgewoonte is het inspecteren van verwijderingen. LLM’s verwijderen vaak details terwijl ze de proza gladder maken.

Gladder proza is niet altijd betere kennis.

Veilige commit-strategie

Vermijd enorme commits zoals:

Update wiki

Gebruik commits die de operatie uitleggen:

ingest: bronnotities toevoegen voor Qwen embedding release
maint: oude vector store-vergelijking markeren als vervangen
lint: gebroken interne links in RAG-pagina's fixen
review: LLM Wiki-paginaties bijwerken
refactor: agent geheugenconcept splitsen van langetermijngeheugen

Dit geeft toekomstige mensen en agents een nuttige geschiedenis.

Commit-berichten zijn deel van het kennissysteem. Ze verklaren waarom de wiki veranderde.

Reviewniveaus

Niet elke pagina heeft hetzelfde reviewniveau nodig. Gebruik risicogebaseerde review.

Laag-risico wijzigingen:

• Reparatie van gebroken links
• Opschoning van opmaak
• Toevoegen van backlinks
• Toevoegen van indexitems
• Correctie van typfouten
• Toevoegen van aliassen

Middelhoog-risico wijzigingen:

• Toevoegen van bron samenvattingen
• Creëren van nieuwe conceptpagina’s
• Bijwerken van aanbevelingen
• Samenvoegen van dubbele pagina’s
• Wijzigen van paginastatus

Hoog-risico wijzigingen:

• Verwijderen van beweringen
• Herschrijven van canonieke pagina’s
• Wijzigen van beslissingsregistraties
• Bijwerken van beveiligings-, juridische-, prijs- of benchmark-beweringen
• Oplossen van tegenstrijdigheden
• Markeren van content als actueel of vervangen

Hoog-risico wijzigingen moeten menselijke review krijgen. Dat kan jij zijn, een maintainer of een domeineigenaar.

De agent kan de wijziging voorbereiden, maar het mag niet altijd de laatste autoriteit zijn.

Een onderhoudsdashboard

Een eenvoudig onderhoudsdashboard kan in Markdown leven.

Voorbeeld:

# LLM Wiki Onderhoudsdashboard

## Review nodig
- wiki/concepts/agent-memory.md - review over datum
- wiki/projects/search-index.md - tegenstrijdige beweringen gevonden

## Verouderde pagina's
- wiki/tools/ollama.md - laatst gereviewd 120 dagen geleden
- wiki/concepts/rag.md - snel veranderend onderwerp, review vereist

## Gebroken links
- wiki/index.md -> wiki/concepts/old-page.md

## Weespagina's
- wiki/entities/vendor-x.md

## Tegenstrijdighedsrapporten
- reports/contradictions/2026-07-10-agent-memory.md

## Recente Ingesties
- raw/sources/2026-07-09-new-paper.md

Dit is geen fancy admin-paneel. Het is een werkoppervlak.

Voor veel solo- of kleinteam-systemen is een Markdown-dashboard voldoende.

Metingen voor een gezonde LLM Wiki

Je kunt wiki-gezondheid bijhouden zonder het te overengineeren.

Nuttige metingen omvatten:

• Aantal pagina’s
• Pagina’s zonder bronnen
• Pagina’s zonder reviewdata
• Pagina’s na reviewdatum
• Gebroken interne links
• Weespagina’s
• Dubbele titels of aliassen
• Openstaande tegenstrijdighedsrapporten
• Opgeloste tegenstrijdighedsrapporten
• Gemiddelde pagina-leeftijd per cluster
• Ruwe bronnen die nog niet zijn ingelezen
• Pagina’s gewijzigd zonder menselijke review
• Canonieke pagina’s gewijzigd in de laatste 30 dagen

Deze metingen zijn geen vaanghuidnummers. Ze vertellen je of het systeem makkelijker of moeilijker te vertrouwen wordt.

Een groeiende wiki met stijgende weespagina’s en verouderde reviews compenseert geen kennis. Het compenseert onderhoudsschuld.

Onderhouds-prompts

Onderhouds-prompts moeten smal zijn. Brede prompts produceren brede herschrijvingen.

Structurele Lint Prompt

Review de wiki-structuur.

Controleer op:
- gebroken interne links
- weespagina's
- dubbele of bijna-dubbele paginatitels
- pagina's met ontbrekende bronssecties
- pagina's met ontbrekende last_reviewed metadata
- indexpagina's die niet linken naar nieuwe pagina's

Herschrijf geen content.
Produceren een Markdown-rapport met bevindingen en voorgestelde fixes.

Citatie Review Prompt

Review citaties voor de geselecteerde pagina.

Voor elke belangrijke bewering:
- identificeer de ondersteunende bron
- controleer of de bron de bewering direct ondersteunt
- markeer beweringen met zwakke, ontbrekende of mismatched ondersteuning
- herschrijf de pagina nog niet

Retourneer een tabel met:
bewering, huidige citatie, ondersteuningsniveau, probleem, voorgestelde actie.

Tegenstrijdigheid Check Prompt

Controleer deze pagina op tegenstrijdigheden tegenover gerelateerde pagina's.

Stappen:
1. Extraheren van de hoofdclaims uit de pagina.
2. Zoek gerelateerde pagina's via links, backlinks, aliassen en zoeken.
3. Extraheren van potentieel conflicterende claims.
4. Classificeer elk conflict als:
   - echte tegenstrijdigheid
   - versieverschil
   - scopeverschil
   - terminologieverschil
   - onopgeloste onzekerheid
5. Adviseer een oplossing.

Bewerk geen bestanden totdat het tegenstrijdighedsrapport is gereviewd.

Verouderde Pagina Review Prompt

Review deze pagina op veroudering.

Controleer:
- data
- versiespecifieke beweringen
- toolgedrag
- aanbevelingen
- links naar vervangen pagina's
- bronnen nieuwer dan de paginareviewdatum
- beweringen gemarkeerd als actueel zonder recente ondersteuning

Retourneer:
- behoud actueel
- update nodig
- markeer historisch
- markeer vervangen
- splitsen in versiepagina's

Veilige Update Prompt

Update de geselecteerde wiki-pagina met behulp van de verstrekte bron.

Regels:
- behoud bestaande nuttige structuur
- verwijder geen bron-ondersteunde beweringen tenzij de bron is vervangen
- voeg citaties toe voor nieuwe beweringen
- markeer onzekerheid expliciet
- update gerelateerde pagina's alleen wanneer nodig
- voeg een reviewnotitie toe die uitlegt wat veranderd is
- houd de diff klein

Deze prompts zijn geen magie. Ze zijn vangrails. De echte waarde komt voort uit het expliciet maken van de onderhoudsactie.

Veelgemaakte onderhoudsfouten

De eerste fout is het laten herschrijven van te veel door de agent.

Grote herschrijvingen voelen productief omdat ze pagina’s gladder maken. Ze maken het ook moeilijker om te zien wat is veranderd en gemakkelijker om scherpe details te verliezen.

De tweede fout is het behandelen van gegenereerde samenvattingen als bronnen.

Een samenvatting kan nuttig zijn, maar het is niet het bewijs. Behoud ruwe bronnen en citeer ze wanneer beweringen belangrijk zijn.

De derde fout is het creëren van nieuwe pagina’s in plaats van het bijwerken van oude.

Dit produceert dubbele concepten, tegenstrijdige aanbevelingen en zoekverwarring. De agent moet eerst zoeken, dan updaten en nieuwe pagina’s alleen creëren wanneer het concept echt nieuw is.

De vierde fout is het verwijderen van historische context.

Oude beslissingen, mislukte experimenten en vervangen aanbevelingen kunnen waardevol zijn. Markeer ze duidelijk in plaats van ze te wissen.

De vijfde fout is het vergeten van indexes.

Een pagina die niet op de juiste plek is gelinkt, is half verloren. Indexonderhoud is geen secretariële taak. Het is navigatie-architectuur.

De zesde fout is het gebruik van hetzelfde beleid voor elke pagina.

Een stabiele conceptpagina en een snel veranderende toolvergelijking mogen niet hetzelfde reviewschema hebben.

Archiveren, vervangen of verwijderen

De meeste verouderde pagina’s mogen niet direct worden verwijderd.

Een vervangen pagina moet linken naar de vervanger.

Bijvoorbeeld:

Status: vervangen
Vervangen door: wiki/concepts/agent-memory-architecture.md
Reden: Deze pagina gebruikte een oudere definitie van agent geheugen voordat het project sessiegeheugen, gebruikersgeheugen en gesystematiseerde kennis scheidde.

Dit behoudt context en vermindert verwarring.

Verwijdering moet zeldzaam en reviewbaar zijn. Kennissystemen hebben snoei nodig, maar onzichtbare snoei is gevaarlijk.

Canonieke pagina’s hebben extra zorg nodig

Elke LLM Wiki ontwikkelt uiteindelijk canonieke pagina’s.

Dit zijn pagina’s die kernconcepten, architectuurkeuzes, workflows of projectvocabulaire definiëren. Ze zijn belangrijker dan gewone notities omdat veel andere pagina’s ervan afhankelijk zijn.

Voorbeelden:

• Wat is LLM Wiki
• RAG vs gesystematiseerde kennis
• Agent geheugen
• Bronbeleid
• Reviewworkflow
• Projectarchitectuur
• Woordenboek
• Index

Wijzigingen in canonieke pagina’s moeten strenger review vereisen.

Een kleine fout op een obscure pagina is lokaal. Een kleine fout op een canonieke pagina kan de hele wiki vervormen.

Hoe vaak moet je onderhoud uitvoeren

Voor een actieve LLM Wiki, voer klein onderhoud vaak uit en diep onderhoud af en toe.

Het schema moet overeenkomen met risico. Een persoonlijke researchwiki kan lichter zijn. Een wiki gebruikt voor technische publicatie, klantenservice of engineeringbeslissingen heeft meer discipline nodig.

Gebruik van een LLM Wiki voor technische publicatie

Voor een technische blog of documentatiesite kan de LLM Wiki de kennislage worden achter artikelplanning.

Het kan bijhouden:

• Canonieke uitleg
• Herhaalde definities
• Kansen voor interne links
• Verouderde vergelijkingen
• Artikelenkloppingen
• Onderwerpclusters
• Bronnotities
• Beslissingen over structuur
• Beweringen die verificatie nodig hebben

Dit is nuttig, maar het verhoogt de onderhoudsbalie.

Als de wiki gepubliceerde artikelen voedt, dan kunnen verouderde wiki-pagina’s verouderd openbare content worden. Als de wiki tegenstrijdigheden bevat, kunnen die tegenstrijdigheden lekken in artikelen. Als citaties zwak zijn, zullen gegenereerde concepten die zwakte erven. De gebundelde samenvattingen, schema-gebaseerde extractie en menselijke reviewloops beschreven in AI voor kennismanagement: Werkelijke workflows die standhouden zijn een goed template om die redactionele pijplijn eerlijk te houden.

Voor publicatieworkflows, behandel de LLM Wiki als een redactioneel systeem, niet alleen als een privé-notitieboek. Een digitale tuin maakt dit expliciet door lezers te laten zien welke pagina’s nog groeien en welke rijp zijn, wat precies het soort statussignaal is dat een goed onderhouden LLM Wiki ook moet tonen.

Onderhoud is niet optioneel

Een LLM Wiki is aantrekkelijk omdat het belooft compounding kennis.

Maar compounding werkt alleen als oude kennis nuttig blijft. Anders compenseert het systeem ruis, niet inzicht.

De onderhoudslast verdwijnt niet omdat een agent betrokken is. Het verandert van vorm.

Mensen hoeven niet elke saaie taak te doen. Agents kunnen links controleren, verouderde pagina’s vinden, beweringen vergelijken, rapporten opstellen en updates voorstellen. Maar mensen moeten nog steeds beleid vaststellen, risicovolle wijzigingen reviewen en beslissen wat de wiki mag betekenen.

Dat is de echte deal.

Conclusie

LLM Wiki-onderhoud gaat over het eerlijk houden van gesystematiseerde kennis.

De belangrijke praktijken zijn niet ingewikkeld: behoud bronnen, citeer beweringen, houd indexes actueel, detecteer tegenstrijdigheden, review Git-diffs, markeer verouderde pagina’s en vermijd brede, ongereviewde herschrijvingen.

Een goede LLM Wiki doet niet alsof het magisch zelfcorrigerend is. Het maakt correctie makkelijker.

Dat is de standaard die de moeite waard is om na te streven: niet perfecte kennis, maar inspecteerbare kennis die kan worden gereviewd, gerepareerd en vertrouwd over tijd.